Welcome to the Q&A Forum

Yeah, I think Chad has the bases covered - sharing an account is really only an issue if you don't want Google to know that the two sites are connected. For example, if you're cross-linking a lot of sites, you might want to keep their ownership as separate as possible. Most of those cases are at least gray-hat, though, and often Google has other cues.

In general, sharing an account is no big deal. Sharing the same IP address has some minimal risks (in the past, if a site on that IP was penalized, it could cross over), but even that seems to be going down over time. Now that we're running out of IPv4 addresses, shared hosting is a lot more common. Personally, I still like unique IPs whenever possible, but sharing a host is no big deal.

I guess the only other exception would be from an engineering standpoint. If you were running two sites for reliability/up-time (in case one went down), then sharing a host would defeat that purpose. That doesn't sound like what you have in mind, though.

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)?

Just to clarify on a point William raised - do you want the "doorway" page to rank? That's where the trouble usually starts. Vanity URLs and landing pages are fine - if you canonical them, NOINDEX (or even 301-redirect, if you don't care if the URL changes), then Google isn't going to see any attempt at manipulative content.

The other issue is generally relevance. The problem in the past was when people used a doorway page to bring visitors in on one term or set of terms and then that was just a link to a wildly different site. If the landing page is relevant and non-duplicate, it's not nearly as big of a deal.

Personally, I would not do private registration, separate hosting, etc., because that honestly looks like you are trying to hide this page and get away with something. Just don't index the page, and you should be fine. I've used landing pages for paid search on all kinds of URLs, and as long as organic didn't see them, it's no problem at all.

I do not like that 303-redirect setup. It looks like Google is indexing pch.com, but the cache is empty, and title/snippet match the non-redirected page. This could look like an odd form of cloaking, and landing on "/urecognized" seems like a recipe for trouble (it's a really bad URL from a UX perspective, too - it sounds like an error page).

I'd also argue that the page for new visitors looks like a giant ad. It needs some explanatory content. Yes, many people know who you are, but we don't know what the site does or why we should care. What's "obvious" internally is completely opaque to the average visitor. Richer content on this page would serve both SEO and conversion.

Could you serve up the home-page dynamically - display member content if they're logged in but generic content if they're not, and avoid the redirect entirely? That's not quite like your (1) or (2), and I think it's safer than (2). If not, then (3) would be preferable, worst-case. Once a member is logged in and knows the site, a redirect is no problem.

Especially post-Panda, duplicates can create a real mess. At best, it's a matter of dilution. The more pages in you have in Google's index that are "thin", the more thinly your internal link-juice (authority, basically) is spread. So, each page just gets less of it. In extreme cases, though, the entire site can suffer.

Canonicalization is tricky, and it's tough to be 100% sure from sample URLs, but my gut reacionts:

(1) Yes, I think you could safely use rel=canonical here. It's slightly odd, since these search pages are actually showing different lists of products, but your only real choices are rel=canonical or blocking the "prices=" parameter in Google Webmaster Tools. You could NOINDEX anything with "prices=" in it as well. I think canonical will work, though.

(2) This is definitely a case where you should use rel=canonical. There are true duplicates. Actually, the best case here is not to create these URLs, but I realize that's not always an option.

You could use GWT for #1, if development is an issue, but to solve (2) you're going to need some kind of page-level directive (like rel=canonical). There's no good way to get around the coding.

It's hard to gauge the impact, but I've definitely seen cases where the consequences of large scale duplicates were severe, and where large ranking/traffic improvements (as much as 3X, although it's not usually that dramatic) have occurred when the problem was fixed. To be aware that it's not instantaneous. It can take a few weeks to really see the impact.

I'm gonna disagree mildly. It is common to have color variation pages, and it is perfectly useful to end-users. So, you're not doing anything wrong, in that sense. However, these pages don't look very different to Google (minor variations in title and content), and so we do flag them as near duplicates because Google might consider them "thin". At large scale, that could dilute your ranking ability.

If you have 100s or 1000s of these pages and a relatively weak link profile, it might be worth considering canonical tags here. The trade-off is that you would consolidate your ranking power, but one variation would fall out of search results. So, it really depends not only on the scope of the problem, but the strength of the site, and how important these long-tail color-based searches are to your current traffic. There's no one-sized-fits-all answer.

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.

This is an increasingly common, and often frustrating, problem. Google will take liberties with title tags, especially to show brand information. This most likely explains the second result. You could try shortening that home-page title a bit, removing the duplication of "Flower(s)" and putting the brand at the end. Google might be seeing that title as a little bit keyword-heavy. It's not a penalty sort of thing, but it makes them more likely to rewrite.

The other example, though, for the French site, is definitely odd. Could you tell us what search you're running when you see that? Is it on Google.fr?

Endorsing George for the full thread. Technically, Google does allow relative URLs, but I've heard of some odd issues, so I think it's better to use full URLs. Your home-page version isn't really either an absolute or relative URL - you really should have the "http://" (protocol) in that URL. If you're being nitpicky, that's an improper URL, and Google could end up interpreting it as something like:

http://www.ccisolutions.com/www.ccisolutions.com

Now, odds are, they won't, but with these tags it's really best to do it by the book.

That should work - it's possible your implementation isn't 100% correct (can't tell from the example), but it's possible that we're not handling this completely right. I'm going to ping the product team and see what they can tell us.

I'd generally agree with (and thumbed up) Adam - it's harmless and can sometimes help sweep up any stray URLs. I find it especially useful for the home-page, which naturally has a lot of variants.

I'd only add that you often see this in place not so much because it's strategic but because it's easier to implement, especially in a CMS. Telling the system to add a canonical to every version but the canonical URL is a lot more of a pain, so most people don't do it. Originally, Google and Bing suggested this was their preferred method, but it was so immediately obvious that it's easier to put the tag on all versions that I think they completely reversed that.

I've never seen it cause any harm, and I've seen it help a bit more than once.

I wrote about this a while back - I think it 98% still applies today:

http://www.seomoz.org/blog/how-many-links-is-too-many

It's really a question of dilution - the more thinly you spread your internal link "juice" (PR, basically), the less each page gets. So, it's often a balancing act. There's rarely one right answer, but I find that less is often more.

I think Istvan's point about users is important, too. It's easy for people to get overloaded with options. I've seen sites with 500+ links that presented them very well, but that's rare. At the same time, those were big brand sites with a lot of inbound links and authority, so they can play by different rules.

Is your site relatively new? I currently show no pages in the Google index at all, which makes the duplicate content issue a bit moot (at least in the short-term). The search filters and pagination are a bit different issues. You could META NOINDEX any pages with the filter parameters active, or rel-canonical them to the unfiltered version (as @Steve25 said). Since no pages are indexed yet, you could also just "nofollow" the filter links ("Title", etc.), which should help prevent those filtered versions getting crawled. Pagination (pages 2+ of search) is a trickier issue, but it might be best to just NOINDEX, FOLLOW those. You could also let Google know in Google Webmaster Tools that that page= parameter is for pagination (I've had that be hit-or-miss, but it is easy, relative to other solutions). For the empty profiles, it really depends on the scope. If you have a lot, I'd ideally want to code them to have META NOINDEX if they're empty. You can lift the NOINDEX once they have content posted. You'd have to do that dynamically, but it shouldn't be too tricky. That way, Google would see new pages only once they have some content in place.

Yeah, I think Matthew's right about the duplication - it looks like these are basically landing on the same results. It's not a disaster, but it's certainly going to look like thin content. I guess I'd want to step back and ask if these two paths are really necessary - could they converge on one URL if you're really serving up exactly the same products? The best canonicalization solution is ultimately not to have multiple URLs.

The canonical tag is slightly odd here, just because the pages aren't 100% duplicates, but it's probably fine. Honestly, a lot of it boils down to how many search pages you've got across the site and how many are duplicated. If you're talking about half-a-dozen, it's probably not worth worrying about. If you're talking about hundreds of pages, then cleaning up your architecture and removing these duplicates could have real dividends for SEO (and possibly make life easier for your visitors, too).

It is funny how often, in internal communications, we'll say something like "Is this TAGFEE?" or "Hey, that's not TAGFEE!"? We should just wear wristbands that say WWRD

OMG, now I'm picturing a Lance Armstrong style wristband that says "TAGFEE". Someone get on that, stat!

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.

I learned that they'll print one word on each side, and so a test batch of wrist-bands with "TAGFEE" on one side and "WWRD" on the other side is in production. I'm ridiculously excited about seeing how they turn out.

With products, it's a bit hard to say. Cross-domain canonical could work, but Google can be a bit finicky about it. Are you seeing the pages on both sides in the Google index, or just one or the other? Sorry, it's a bit hard to diagnose without seeing a sample URL.

If this were more traditional syndicated content, you could set a cross-domain canonical and link the copy back to the source. That would provide an additional signal of which site should get credit. With your case, though, I haven't seen a good example of that - I don't think it would be harmful, though (to add the link, that is).

If you're talking about 80K links, then you've got 80K+ near-duplicate product pages. Unfortunately, it could go beyond just having one or the other version get filtered out. This could trigger a Panda or Panda-like penalty against the site in general. The cross-domain canonical should help prevent this, whereas the links probably won't. I do think it's smart to be proactive, though.

Worst case, you could META NOINDEX the product pages on one site - they'd still be available to users, but wouldn't rank. I think the cross-domain canonical is probably preferable here, but if you ran into trouble, META NOINDEX would be the more severe approach (and could help solve that trouble).

Joram and Adam are essentially correct. MozRank is built to emulate PageRank, and so it does take into account the MR of the incoming links, not just the total count. It is in essence, though, a measure of quantity - just a complex one. Links from sites with more links count more, so that's a quality signal, in an abstract way, but we don't take into account the relevance of the links or spam factors.

Domain Authority is much more complex and is a machine-learning model based on observed Google rankings. Essentially, it's an attempt to predict the ranking power of a site.

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?

So, keep in mind that "cheating" Page Authority isn't really very useful - we're just creating a predictive metric. We have no control over whether you actually rank. PA is a machine-learning model designed to predict the ranking ability of a page, but it's far from complete or perfect (no one number can be, although we're trying to improve it all the time).

Sub-domains are tricky animals. Sometimes, they inherit a lot of power from the root domain. Sometimes, they get fragmented and essentially act like entirely separate domains. Our PA model doesn't really account for all of that complexity. It's a best guess, ultimately. There are certainly cases, though, where a sub-domain ranks well without many unique links, solely based on the power of the root domain. That's far from guaranteed, though.

Yeah, the diplomacy is the hard part. I had a client who I literally spent about 4 hours of CRO work on (as a test project) with surprisingly good results, and they didn't care. They then went out and spent $10K on a new logo (I'll save my opinions about that project).

Middle ground - could you create 1-2 vanity metrics of your own. Take all the keywords tracked, show how many your beating the competition in right now, and try to get that number, up, for example. Or create some derivative of organic traffic (put it on a 100 point scale, with 100 being the best-of-all-possible worlds goal). Obviously, these paths can be dangerous, too, and any one metric can always be misleading. I'm just thinking that, if you have to pick one, better for you to pick it than him.

If you want to DM me the domain (or email peter@seomoz.org), I'll take a look. There are a lot of factors that can impact the count, so it's really tough to say without seeing what you're looking at. Total links can sometimes explode based on a single site-wide link (even from one domain), for example.

If you're willing to piece together multiple sources, I can definitely give you some starting points:

(1) First, dropping from 21K pages indexed in Google to 240 definitely seems odd. Are you hitting omitted results? You may have to shut off filtering in the URL (&filter=0).

(2) You can also divide the site up logically and run "site:" on sub-folders, parameters, etc. Say, for example:

site:example.com/blog

site:example.com/shop

site:example.com/uk

As long as there's some logical structure, you can use it to break the index request down into smaller chunks. Don't forget to use inurl: for URL parameters (filters, pagination, etc.).

(3) This takes a while, but split up your XML sitemaps into logical clusters - say, one for major pages, one for top-level topics/categories, one for sub-categories, one for products. That way, you'll get a cleaner could of what kind of pages are indexed, and you'll know where your gaps are.

(4) Run a desktop crawler on the site, like Xenu or Screaming Frog (Xenu is free, but PC only and harder to use. Screaming Frog has a yearly fee, but it's an excellent tool). This won't necessarily tell you what Google has indexed, but it will help you see how your site is being crawled and where problems are occurring.

I wrote a mega-post a while back on all the different kinds of duplicate content. Sometimes, just seeing examples can help you catch a problem you might be having. It's at:

http://www.seomoz.org/blog/duplicate-content-in-a-post-panda-world

Unfortunately, we don't currently track rel=prev/next - definitely on the list for next steps. As best I can tell, your rel=prev/next tags are properly implemented, and they are a good bet for paginated search results like this.

There is one issue, though - your category pages within the blog have the same title as the blog home-page. It would really be a good idea to make those unique. Otherwise, they could slightly cannibalize each other.

I don't want to give examples, sine this is a public question, but hopefully you know which pages I mean.

Keep in mind, too, that a lot of duplicate content is accidental. Google doesn't care about pages, per se - they care about unique URLs. So, if you have 300 unique pages, but something about your CMS translates that into 5,000 crawlable URLs, then you could definitely have problems.

When you say "drop", what kind of movement are we talking about? Could you give a before/after example without naming the site?

The DA/PA algorithm is based on machine learning, so even if the link-graph remained static, it is recalibrated from time to time. Of course, on top of that, the link-graph never stays static. If you're talking about something like 62->60, it probably wouldn't mean much at all. If you're talking about 60->40 and consistently large-scale drops, that would more likely indicate problems with your link-building strategy across all of the sites.

It's a little tricky. While Andrea is right about Robots.txt - it's not great for removal once pages/domains are indexed, you can block the sub-domain with robots.txt and then request removal in Google Webmaster Tools (you need to create a separate account for the sub-domain itself). That's often the fastest way to remove something from the index, and if it has no search value, I might go that route. Just proceed with caution - it's a delicate procedure.

Doing 1-to-1 canonicalization or adding 301 redirects may be the next strongest signal (NOINDEX is a bit weaker, IMO). However, Google will have to re-crawl the sub-domain to do that, so you'll need to keep the paths open.

We don't have much useful data (i.e. we have a lot of data, but can't see any clear patterns) around the January core algo updates, other than knowing that they occurred. It's hard to pin down from the graph, and I'm not sure what the scope of your traffic and page count is, but my first guess would be that you lost ranking on some long-tail pages that weren't contributing much in the way of traffic.

It's possible these were low-value pages or even some pages that shouldn't have been indexed (like duplicates), in which case this could be fine. It's also possible that these pages had quality issues that knocked them out of ranking contention, which wouldn't be so good.

It's not an easy problem to solve, but the first step I'd take is to try to pin down: (a) what those pages were, and (b) if they have any relationship. If you lost traffic to 500 completely different pages, that's going to be tough to interpret. More likely, though, there's a pattern. Maybe these are mostly product pages, or blog posts, or internal search results, etc. If you can find their commonality, that's your best chance of knowing what went wrong.

It looks like the site was indexed at some point in the past, but I can't find it currently. Unfortunately, that could be a sign of quality problems and even potentially a past penalty. It's very hard to prove that from limited information, though.

I agree with Sha that the parked domain issue can be a problem. In the past year, Google has worked to de-index more and more parked domains and try to clean up sites they consider to have no value. Some parked domains still get listed - that's true - but that number is declining all the time. If you want the site to have a fighting chance, I'd put some kind of placeholder page up with at least basic copy and META data. Then submit that to GWT and at least set up your social profiles, etc.

Truthfully, without that, why does it even matter if Google has indexed the site? You're not going to rank for anything useful on a default parked-domain page, and no one could do anything even if they did find you.

I'd agree with the general consensus that, while a nofollow on the links could cut the crawl path, it's no guarantee that deeper pages won't be followed or indexed. Any stray internal links, inbound links, etc. could trigger a crawl, or Google could just go exploring and then not be certain about your indexation signals on the deeper pages.

Nofollow'ing the "/product" level could definitely disrupt link-juice flow to the "/product/review" level and may impact rankings. I'm having a hard time envisioning how you're set up, but I suspect there's a way to block the affiliate links without blocking the entire "/product" level. My gut reaction is that this isn't set up quite right.

Generally agree with everyone (well, everyone so far ) - there's no need to remove authorship in general. Google isn't penalizing sites with authorship - they're just showing authorship thumbnails less often, as they found they were overdoing it (at least in the eyes of users).

The only exception I'd give is to be careful about applying authorship tags to every page on a site - home page, search results, product pages, etc. Some CMSs go crazy, unfortunately. This is technically against Google authorship guidelines. Again, most likely, they'll just ignore your authorship mark-up (it's not a penalty situation), but if you want that mark-up to appear in SERPs, then use it appropriately.

Even Google's reps don't seem to agree on whether reconsideration works for Penguin, but I've seen a fair amount of evidence that disavow won't solve any problems without reconsideration, so I actually think you do have to file reconsideration in these cases.

"Creative" 301-redirects are very dangerous and do not work like they did 2+ years ago. At best, you'll see a temporary uptick and end up in a worse position down the road. I've even seen some folks suggesting (on limited evidence) that Penguin 2.0 clamped down harder on bad, redirected links. We've absolutely seen 301s carry penalties, both manual and algorithmic, over the past couple of years.

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.

To the best of my knowledge, this is a test. Google has run multiple experiments with formatting #1+Site-links, and all of them involve some kind of bounding box. Interesting that Firefox triggered it, but I don't think it's specifically a browser thing. I expect Google is going to keep messing with this for a few weeks or months and then roll something out to everyone. At that point, any #1+Site-links site should get the new look.

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).

Agree with others - that style tag should be fine. May I ask, though - why does it matter? If you italicize the text in the header, what's wrong with having it italicized in the SERP snippet? It might actually stand out (in a good way).

This happens more than you'd think, and it can be frustrating. It can, on occasion, be a sign that Google is on the fence about your category page. In other words, it could signal quality issues, although that's not always the case.

Could you tell me what search you were running when this originally happened? There are ways to see how Google is viewing the pages on your site that match that search.

There's no perfectly clean break with any domain for one important reason - back-links. If the side project has solid back-links and then you disconnect it (break the 301, essentially), you'll lose the positive impact of those links. There's no easy way around that.

At the same time, the new owner will potentially benefit from those links. The only way to disconnect that benefit is to individually request that the linking sites switch their links to your site. If the new site changes ownership and drastically changes content, then Google will eventually see those links as irrelevant and devalue them, but that's probably going to take a while.

I'd worry more about your loss of benefit than about the new owner getting some unearned but probably temporary benefit, honestly. The other issue would be any brand awareness around the secondary domain - since that's tied to the name/domain, you can't really cut that loose.

Since it's a side project, I suspect this isn't a big risk, but it's really tough to know without more details.

DA and PA are modeled somewhat independently, if memory serves, and they aren't scaled against each other (only other metrics of their kind), so it is possible for you to have a DA that's lower than your PA. Typically, that would mean that the majority of your strength is rooted in the home-page, as Martijn said. Unless there's a big discrepancy, it's generally not any cause for alarm.

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.

Here's the official info on review snippets, if you don't have them set up:

https://support.google.com/webmasters/answer/146645?hl=en

Keep in mind that setting up the microdata is not always sufficient. Google is still going to look at the authority/quality/etc., of the page, and rich snippets are often query-dependent (you don't get them on every search just because you got them on one search). For most sites, though, the microdata is a good start.

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).