I don't believe that Bing supports the HTTP header version of rel="canonical". They do technically support the link attribute (their comment about it being a "hint" was from 2009) - Duane confirmed that last year (I asked him point blank). Although, honestly, experiences vary and many SEOs claim that their support is inconsistent even for the link attribute.

Honestly, when it comes to canonicalization, when in doubt, try it. The worst that can happen in most scenarios (implemented properly) is that it just doesn't work.

Out of curiosity, why are your trying to use the HTTP Header version. Is it a non-HTML file (like a PDF)?

Is there a crawl path to them currently? One issue I see a lot is that a bunch of pages get indexed, the path is found and cut off, NOINDEX (canonical, 301, etc.) is added, but then the pages never get re-crawled. Since they don't get recrawled, the page-level directive never gets honored.

If there's a URL parameter involved, you could use parameter-handling in GWT - it's not a perfect solution, but it sometimes seems to work without a re-crawl.

The other option would be to create a new XML sitemap with all of the bad/indexed URLs. This may push Google to re-crawl them and then see the tags to deindex. It's a bit safer than re-opening the crawl paths.

If they are being crawled and Google is just ignoring the NOINDEX for some reason, I'd try to 301 or canonical those pages to a primary search page, if that's feasible (probably canonical, since you don't want the users to 301). Sometimes, if a signal isn't working for that long, you just have to shake Google and try a different signal. Even following their exact recommendations, it rarely works as planned at large scale.

There's no perfect answer. Canonical tags would keep the sub-domains from ranking, in many cases. The cross-TLD stuff is weird, though - Google can, in some cases, ignore the canonical if they think that one sub-domain is more appropriate for the country/ccTLD the searcher is using.

Sub-domains can be tricky in and of themselves, unfortunately, because they sometimes fragment and don't pass link "juice" fully to the root domain. I generally still think sub-folders are better for cases like this, but obviously that would be a big change (and potentially risky).

You could try the rel="alternate" hreflang tags. They're similar to canonical (a bit weaker), but basically are designed to handle the same content in different languages and regions:

http://support.google.com/webmasters/bin/answer.py?hl=en&answer=189077

They're basically designed for exactly this problem. You can set the root domain to "en-US", the UK sub-domain to "en-UK", etc. I've heard generally good things, and they're low-risk, but you have to try it and see. They can be a little tricky to implement properly.

It is probably best to create separate profiles in Google Webmaster Tools, because then you can target the sub-domains to the countries in question. At that point, you could also set up separate sitemaps. It'll give you a cleaner view of how each sub-domain is indexed and ranking.

I'm not sure I understand (2) - why wouldn't you include those pages in the sitemap?

I guess the short answer is that Google frowns on this practice, since the pages aren't really duplicates. Since they frown on it, they may choose to simply ignore the canonical, and you'll be left with the problem. I think the general problem is that this requires a lot of extra crawling/processing on their part, so it's not that it's "black at" - it's just a pain for them.

I've typically found putting a NOINDEX on pages 2+ is more effective, even in 2014. That said, I do think rel=prev/next has become a viable option, especially if your site isn't high risk for duplicates. Rel=prev/next can, in theory, allow Google to rank any page in the series, without the negative effects of the near-duplicates.

Keep in mind that you can combine rel=prev/next and rel=canonical if you're using sorts/filters/etc. Google does support the use of rel=canonical for variants of the same search page. It gets pretty confusing and the simple truth is that they've made some mixed statements that seem to change over time.

Google has been non-committal on this, other than to say the new TLDs won't get any special preference (which is a bit vague). We don't really know yet if those domain keywords will provide SEO benefit. I think most of these will be treated generically, and the keyword in the domain may carry limited benefits.

Personally, if you have a choice between a lousy domain on a traditional extension and a really memorable domain on a new extension, I might lean toward the new extension. I'm talking about homebuilder.construction vs. great-homebuilder-construction-company.org or something like that.

There's the usability aspect, too - I think it's going to take people a while to adjust. If you owned chicago.attorney, people might pick up on that, but they're still used to thinking in terms of .com, etc. There's going to be an adjustment period.

If the price is right and there's a good one out there, it may be worth buying, but I don't think there's going to be much of a gold rush on these new domains.

Google is officially supporting some emoticons. I talked to one big-brand SEO last week who has tested it with a fair degree of success. A couple of warnings:

(1) Testing the impact on one title tag is a fair amount of work, so it really has to be a high-impact SERP. This isn't something you want to spend days on across thousands of results.

(2) Make sure the character/symbol really is relevant. People focus on the first two words of a headline, and that emoticon may well take the place of one of those words, so make it count. I wouldn't do this just because you can.

(3) Not all characters render properly on all OSs and devices. Make sure to test.

From an SEO standpoint, I'd say that the URLs generally follow the same principles. Unfortunately, now that Google directly caches and displays your images, image SEO isn't worth quite the effort it used to be.

In most cases, if images are on subdomains, it's for technical reasons unrelated to SEO. People might do this for load-balancing or because they run a 3rd-party CDN, etc. There are more sophisticated ways to do this so that the images all live on one subdomain with the content, but they can be more labor intensive and more costly (and some platforms just don't support them natively).

It's confusing, but best practice is generally no hyphen in the root domain, but hyphens in the sub-folders (so, "www.mydomain.com/my-domain"). Google is good about separating words in root domains, but not always in folder and page names (and they recommend the hyphen as the preferred separator). Traditionally, hyphens in the root domain are also a (small) negative trust signal - people tend to think you couldn't get the non-hyphenated domain.

Agreed - I've seen it cause duplicate content issues with URLs, but I'm not aware of situations where it mattered in on-page keywords. I don't like lower-case page TITLEs, because they look spammy, but that's more a CRO factor.

One minor exception, but I'm not sure it's in play anymore. I once ran into something where acronyms were pulling up different results depending on what case they were in. Google might have been mistaking the acronym in question for a misspelled word, though - it's a really isolated case.

I think there may be an important distinction here - are you talking about potentially registering dozens of domains to rank for long-tail phrases? I think we're all assuming that you mean your primary domain choice.

Registering dozens of exact-match domains to rank for long-tail phrases is a lot less effective than it used to be (and will probably get even less effecting over the next 1-3 years). People abused that tactic, for starters, but it also splits your link-juice, social signals, and typically creates either doorway pages or large-scale duplicate content. The negatives outweigh the positives in most cases.

If you're only talking about one domain, and it really is a very long-tail phrase you want to target, then that's a bit different. In the example you give, most of the keywords are very common and a bit ambiguous, so you're right - a short version might not make much sense. On the other hand, the long version is going to target one very specific phrase that probably gets a small amount of traffic. You could target that phrase through on-page cues, inbound anchor text, etc. (the domain name is just one small piece of the puzzle).