Welcome to the Q&A Forum

My gut feeling is that this is very unlikely to be negative SEO. Frankly, it's still very rare, and most cases that are assumed to be negative SEO turn out to be much more complicated. One oddity here is that I'm not seeing a clear penalty-like scenario. You're talking about a very specific case of multiple pages showing up for a single query. This could be as simple as Google tweaking their domain crowding settings. I see this frequently - one day, a single domain will get multiple listings; the next day it will get one. If you look at thousands of SERPs, this actually happens every day.

This could indicate Google saw a change in your signals or signals related to your brand name, but it's unlikely to be due to negative SEO. It's also, honestly, not a huge issue, for the most part. You still rank #1 for your brand, and your brand is just one query. If Google has decided to not show multiple pages from your domain, this may be beyond your control and have little or nothing to do with your SEO efforts.

I do also share Dirk's concerns. A lot of the internal pages are being cached with very little text - Google is indexing them, but the text-only content is showing up as just a few menu items. These pages are going to look thin, and they may be running into some quality problems. This could cause them to compete with each other and fall out of some rankings. While Flash can be used successfully, the implementation here is part of the problem. The load times could also be causing you some issues. At best, it's creating obstacles.

At first glance, your link profile also looks pretty weak. You have a ton of free PR sites and web directories. In small quantities, these are fine, but when they make up a huge swath of your profile, you're getting into danger territory. When I see things like "free link directory" over and over, I start to worry. Add that to technical and on-page problems, and now you're compounding the issues.

I'm also seeing that some of the "links" are actually 301-redirects from a very long, exact-match domain, that you've redirected to the site entirely. I'm seeing a number of serious quality issues in your link profile, to be brutally honest.

I don't think the problems here have anything to do with the competition. I think you have to take a good, hard look at both the technical state of the site, the overall content quality, and the overuse of low-quality link tactics.

The short answer is: Yes We're actually working on collecting the data for a 2013 report, but we don't have a firm ETA at this point. One of our new team members on Data Science is almost full-time on ranking factors - it's a project we take very seriously. Every time we do it, though, it gets a bit harder and more complicated.

Thanks for the reminder! To be honest, I'm not sure we expected the kind of volume that Public Q&A would have after the re-launch. I know the Associates have been working to do a better job of endorsing good answers and generally participating. As you said, though, it's a community effort, and we can't do it without you guys (and gals).

From my own experiences on the private Q&A here and other SEO forums, it seems like you run into two groups:

1. People who are new, trying to absorb everything, and may be misinformed.
2. People who want easy answers.

I admit that I often get frustrated with (2), but I also try to remember that there's a lot of (1)'s in the mix. Many people are just business owners, webmasters who wear multiple hats, marketers who got handed an SEO problem, etc., and there's a mountain of information out there (good and bad), spanning more than a decade of SEO. What often seems "obvious" to us is new to 100s of people every day, and sometimes we have to step back and try to remember that.

I wanted to comment as a long-time community member (and not as a Moz Associate). I used to feel a bit self-conscious about getting credit for my participation, too. I mean, I was learning a ton and felt like I was getting more than I was giving. To get points and rewards on top of that just seemed selfish. I've learned a few things over time, though:

(1) Your participation (in any professional community) is often more valued than you know. I frequently learn even from newcomers, especially when they're willing to more openly share data or take risks that established experts won't take (myself included). It's easy to see everyone else as the teacher and yourself as the student, but we're all learning all the time, and your contributions are essential to that.

(2) It can feel strange to bring game theory into the mix, but it's ok to have fun with it. Will Critchlow and I had a mock feud over MozPoints a couple of years ago - it was ironic, because neither of us are the kind of guy who goes out questing for glory, but we were active and found ourselves climbing the ladder. Over time, though, I think it took our contributions to a new level, and we got to know each other as professionals. If it weren't for the points, that might never have happened.

(3) The community (and the staff) can easily tell the people lusting for points vs. the people who really contribute. It's sometimes hard to code that knowledge and easily fight spam (as we all know in this industry), but it's often transparent to people. People see your responses and the quality of your interaction - not the points.

Unfortunately, if you really have no access at all, there's isn't much you can do. The best alternative to a canonical tag, in most cases, is a 301-redirect, and you'd need some kind of access for that, too (hosting account, server access, .htaccess rights, etc.).

It depends a lot on the situation, of course. If you're just trying to get some bad URLs out of the index, you could try parameter blocking in Google Webmaster Tools. If you have Robots.txt access, that might open up some other options (although it's limited and only an alternative in a couple of cases).

I assume this is some sort of CMS system or a hosted solution?

What are you trying to achieve/solve with the canonical?

Love this discussion. I came into SEOmoz as a contractor (and am still a contractor, although my role has expanded), and one thing I can tell you is that TAGFEE is something the staff takes very seriously. I think about it a lot as a blogger, both here on SEOmoz and on my own sites:

Transparent - Whether a business or personal site, I try to be open about my process - data sources, methods, motivations, even the ugly truths from time to time. I think people learn best from honest examples, and that includes the bad bits.

Authentic - On the one hand, I think social media always represents a bit of a mask, but I try to be the same person anywhere I write, regardless of the audience. You may hear a different side of my story, but I'm not going to pretend to be someone I'm not.

Generous - I work hard to give credit where credit is due, and always point out great content, even if it's a competitor or someone I occasionally disagree with. On SEOmoz, I put a lot of effort into participating, because I value the community's contributions (we all do).

Fun - I'm hilarious. Enough said.

Empathetic - Here on SEOmoz, this may be the toughest. When you have 90K readers, you can't always write to everyone, but I think a lot about what our audience wants and how to serve the most people. The best link-bait fits a real need.

Exceptional - Writing for SEOmoz means always raising the bar, especially when you're post side-by-side with people like Rand. It's the most daunting and most exciting part of what I do. Every day, I think about how I can make my next post better or create something no one has seen.

Unfortunately, I don't think there are many reliable options, in the sense that Google will always honor them. I don't think they gauge crawl frequency by the "expires" field - or, at least, it carries very little weight. As John and Rob mentioned, you can set the "changefreq" in the XML sitemap, but again, that's just a hint to Google. They seem to frequently ignore it.

If it's really critical, a 304 probably is a stronger signal, but I suspect even that's hit or miss. I've never seen a site implement it on a large scale (100s or 1000s of pages), so I can't speak to that.

Two broader questions/comments:

(1) If you currently list all of these pages in your XML sitemap, consider taking them out. The XML sitemap doesn't have to contain every page on your site, and in many cases, I think it shouldn't. If you list these pages, you're basically telling Google to re-crawl them (regardless of the changefreq setting).

(2) You may have overly complex crawl paths. In other words, it may not be the quantity of pages that's at issue, but how Google accesses those pages. They could be getting stuck in a loop, etc. It's going to take some research on a large site, but it'd be worth running a desktop crawler like Xenu or Screaming Frog. This could represent a site architecture problem (from an SEO standpoint).

(3) Should all of these pages even be indexed at all, especially as time passes? More and more (especially post-Panda), more indexed pages is often worse. If Googlebot is really hitting you that hard, it might be time to canonicalize some older content or 301-redirect it to newer, more relevant content. If it's not active at all, you could even NOINDEX or 404 it.

I'm with Keri that, in this reality, Roger would never fight Spider-Man. It's just not TAGFEE. Let's say, though, that Spider-Man is infested by the Venom Symbiote and turns temporarily evil, forcing Roger to intervene. How would this play out?

The closest comparison to Roger in the Spider-Man villain entourage is almost definitly Doctor Octopus. Doc Oc has the advantage of having more arms than Roger, but Roger has the advantage of not having a squishy head that can pop. So, I'd call it roughly a toss-up. We know Doc Oc has bested Spider-Man on occasion, so Roger has a fighting chance.

Roger has limited distance attacks, whereas Spider-Man has his web shooters. At best, web shooters would probably only temporarily immobilize Roger. Roger's large eyes are fairly wide apart, and his antenna has additional sensors, so Roger can't be easily blinded with webbing like a humanoid opponent can. Spidey's primary advantage is outdoors surrounded by tall buildings. Being from Seattle, Roger stays indoors, because what's the point of going outside? Also, coffee shops and micro-breweries aren't very tall. So, on home-turf, I think Spider-Man's long-range attack advantages are small, but I'll still lean toward Spidey.

At close range, Roger has one formidable attack. You may know about his Hugs/Destroy switch. What you may not know is that Roger's most powerful attack is also hug-based. His arms, in battle mode, are capable of intense crushing power, roughly equal to 14 Benders from Futurama (see issue #17 of "Adventures in TAGFEE"). If Roger can get Spidey close enough, his close range strength can incapacitate even the Venom Symbiote. Advantage: Roger.

Finally, the Venom Symbiote is vulnerable to sound waves and flame, both of which Roger is impervious to. So, Roger could just crank up his Metallica playlist and set himself on fire. Advantage, Roger.

Some good comments here, and I'll have to come in somewhere in the middle. I think Vahe is right that there can be meaningful benefits, both for SEOs and visitors. It's also true, though, that a site-wide URL change can carry risks. Solid planning and well-implemented 301s can mitigate most of that risk, though.

If it were only to get keywords in the URL and the site is ranking well, I'd probably hesitate. Since these dynamic URLs are creating duplicates, though, I think it's a different situation. Those duplicates could create very real risk to your rankings. If the URL change can solve both problem, I'd be much more inclined to do it.

There are other ways to deal with the duplicates - the canonical tag is probably a good bet here (although I'm not sure how tough it is to implement in Joomla). Blocking duplicate-causing parameters in Google and Bing Webmaster Tools is another option. For example, you could block "Itemid" if it had no unique value (I'm not clear on that from the example).

I'd have to ask about how we specifically measure DA in this case, but the broader answer is "Yes", it can absolutely decrease your authority. There was a time when more pages just mean more opportunities to rank, but that time is long gone, IMO. Even before Panda, there was an increasing risk of dilution - your authority (and even specifically your PageRank) can only spread so thin. If your link profile is relatively weak, and you expand by 100X, each page is going to get less and less authority. You have more theoretical opportunities to rank, but each opportunity has a much smaller chance. Of course, it's more complex than that, but that's the bottom line.

After Panda, the calculation changed a lot. Now, you're not only diluting your content, but if it's thin enough, you risk Google taking action that could harm your entire site. So, EGOL's simple question is critically important. Also, note that "unique" doesn't not mean valuable in Google's eyes (or search users). It's easy to string words together to create something unique, but if that's not adding value it may still be seen as "thin".

I think Harald and James covered the bases here, but a couple of comments on Harald's reply:

(1) Definitely check this. A common cause of indexed https: pages is that a secure section of your site is being crawled (like a shopping cart), and you're using relative navigation links (like ) - when a crawler or visitor hits the nav link from a secure page, the relative link grabs the https: In most cases, you may want to NOINDEX secure pages. Shopping carts and checkout pages have no business in the search index, IMO.

[(2)-(5) I believe this does work, but it's very tricky, so please be careful. If anyone has linked to the https: pages, you'll lose the link-juice this way (you'll just cut those pages off). I honestly don't think it's a good choice for most sites.

(8) I actually believe the 301-redirect is simpler in most cases.

As James said, sitewide canonical tags (or on the affect pages, if they're isolated) will also work.](/contact.php)

We've had a few questions regarding the new Keyword Difficulty score used in Keyword Explorer, and how it compares to the old score in our stand-alone Keyword Difficulty tool. Specifically, people want to know why some scores are much lower using the new tool.

There a general discussion of the math behind the tool in this post:

​Keyword Research in 2016: Going Beyond Guesswork

One of the problems we had with the original Keyword Difficulty score is that, because it's based on our Page Authority (PA) score and PA tends toward the middle of the 0-100 range, Difficulty got a bit bunched up. A Difficulty score in the low-to-mid 20s (via the old tool) is actually very low. So, we set out to re-scale the new tool to broaden that score and use more of the 0-100 range. We hoped this would allow more granularity and better comparisons.

While the logic is sound, we're concerned that we may have been too aggressive in this re-scaling, given recent feedback. So, we're going to be analyzing a large set of keywords (anonymously, of course) that people have run through the tool to see if too many Difficulty scores seem too low. If they do, we'll make some adjustments to the math.

In the meantime, please be aware that low scores may appear lower in the new tool and very high scores may appear higher. We wanted to address some of the limitations in V1 and feedback over the years, and so the old and new scores really can't be compared directly in a meaningful way. We're sorry for any confusion that has caused, and we will re-evaluate if necessary.

I think @cgman and @Nakul are both right, to a point. Technically, it's fine. Google doesn't penalize shared IPs (they're fairly common). If you're cross-linking your sites, though, it's very likely Google will devalue those links. That tactic has just been abused too much, and a shared IP is a dead giveaway.

Now, is it worth splitting all these out to gain a little more link-juice? In most cases, probably not. Google knows you own the sites, and may devalue them anyway. Chances are, they've already been devalued a bit. So, I don't think it's worth hours and hours and thousands of dollars to give them all their own homes, in most cases (it is highly situational, though).

The only other potential problem is if one site were penalized - there have been cases where that impacted sites on the same IP, especially cross-linked sites. It's not common, and you may not be at any risk, but it's not unheard of. As @Nakul said, it's a risk calculation.

You've got bigger problems here than 100 links/page (that's just a guideline) - you're cross-connecting enough sites that it looks like a link farm. Having them all in the footer only adds to the problem, and makes the tactic look lower-quality. I'd definitely no-follow these, as you could potentially be penalized.

The nofollow won't really help with the 180 links - it'll still burn up link-juice. It'll just keep these links from getting you into trouble. Realistically, these links are probably already being devalued by the algorithm.

Practically, being in the footer, these links may not have a ton of value for visitors (if you click-mapped the page, I'm betting the CTR is very low). I wonder if there's a way to integrate them. For example, when someone clicks through to a job listing in Kent, having something like "See more jobs in Kent" on that page and link it to: http://www.kentjobsonline.net/.

From an SEO standpoint, these geo-targeted microsites have lost a lot of value over the past couple of years. I've even seen the strategy run into Panda issues. You may want to re-evaluate down the road and consider consolidating.

Don't look at individual URLs - at the scale of 5K plus, look at your site architecture and what kind of variants you're creating. For example, if you know that the show= and sort= parameter are a possible issue, you could go to Google and enter something like:

site:example.com inurl:show=

(warning: it will return pages with the word "show" in the URL, like "example.com/show-times" - not usually an issue, but it can be on rare occasion).

That'll give you a sense of how many cases that one parameter is creating. Odds are, you'll find a couple that are causing 500+ of the 5K duplicates, so start with those.

Search pagination is very tricky - you could canonicalize to "View All" as Chris Hill said, you could NOINDEX pages 2+, or you could try Google's new (but very complicated way):

http://googlewebmastercentral.blogspot.com/2011/09/pagination-with-relnext-and-relprev.html

Problem is, that doesn't work on Bing and it's pretty easy to mess up.

The rel-canonical tag can scoop up sorts pretty well. You can also tell Google in Google Webmaster Tools what those parameters do, and whether to index them, but I've had mixed luck with that. If you're not having any serious problems, GWT is easy and worth a shot.

Brent and Syed are correct - nofollow no longer preserves link-juice. As for the 100-links "rule", it's really just a guideline. I discuss it in depth here:

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

It's really a balancing act - the more links you have, the less love each link gets. It's not just SEOs - it's true for visitors, too (as Ryan pointed out). More options isn't always a good thing.

The trick is that the balance really depends a lot on the site. I've seen sites with 160 links that were well-designed with ample authority to make that work. I've seen others with 80 links where it was a complete mess.

It's also important to note that links to the same Page B on any Page A are discounted by Google - so, if you have a link in the navigation and then a link to that same page in the content and footer, the 2nd and 3rd links are basically ignored. We still count them as part of the 100, but Google doesn't in most cases. It's a little tricky, since Google probably views navigation links differently from contextual (in-page) links, but the rule still generally holds. Only one link to any Page B from Page A is going to get counted.

Just to clarify, the rewrite that Ryan is proposing IS a 301-redirect (see the "R=301") - it's just one way to implement it. Done right, it can be used sitewide.

It's perfectly viable to also use canonicals (and I definitely think they're great to have on the home-page, for example), but I think the 301 is more standard practice here. It's best for search crawlers AND visitors to see your canonical URL (www vs. non-www, whichever you choose). That leads people to link to the "proper" version, bookmark it, promote it on social, etc.

Make sure, too, to use the canonical version internally. It's amazing how often people 301-redirect to "www." but then link to the non-www version internally, or vise-versa. Consistent signals are important.

I think this is borderline and the kind of thing Panda hit in some cases. While the pages aren't true duplicates, they do appear a bit thin - they're basically the same content with a few brand-related keywords swapped out. It really comes down to scope, though - if you spun out 100s or 1000s of these, you could really dilute your index and even creep into potential Panda penalty territory.

With about 600 pages in the index, though, and these accounting for only 19 of them, it seems like your risk is pretty low. It would be great to build out the content and make it more unique, but I don't think you're in any immediate danger. You don't want to NOINDEX or block these pages somehow, because I assume you're trying to get some mileage out of the long-tail keywords. My best advice is to try to beef them up and don't spin out too many variants (100+ of these pages with a 600 page site would be dangerous).

Sounds like SEO Executive has got you covered on the Godaddy front - just wanted to point out a couple of things:

(1) I'm not seeing a preview for your home-page, and I had trouble connecting to it the first time. It seems to be cahced, so this could be a fluke.

(2) Not sure if this is part of the Godaddy code, but there's a really weird tag on the home-page:

name="canonical tag" content=""/>

That might just be a reference, but it doesn't do anything. If it's supposed to actually be a canonical, then something is broken.

It's important to keep in mind that DA and PA are measures of the strength of a link profile and, to some degree, a site's/page's raw ranking ability. Our authority metrics don't have built in spam-detection, though, and they aren't always aware of sites that Google may have devalued. Spam analysis has been in the works for quite a while now, and it's a complicated problem (as Google has proven). We're hoping to improve DA/PA in this regard over time, but for now there are going to be some situations where a site doesn't really have the ranking power that it's DA suggests. If your gut feeling is that the bulk of the site's links come from bad directories and low-quality sources, you may very well be correct.

I have to admit I have mixed feelings about Google's recent advice, because it's very complex (and they've oversimplified it), and it doesn't work well for all scenarios. If you're using this as prevention and don't have any major problems (like a Panda penalty), then I think rel=prev/next is a good bet here.

As Alan said, you should be able to remove the Meta Robots (NOINDEX), and that's probably sending a mixed signal to the crawlers.

For the sorts and other additional parameters, Google recommends you use rel-canonical to the root page. So, a URL like:

http://www.vistastores.com/patio-umbrellas?dir=asc&order=name&p=2

...would have the following tags on it...

In other words, canonicalize to page 2 (with no additional parameters) but then rel=prev/next should reflect the sorts and other parameters of the current URL.

This is the main problem I have with the approach - it's extremely complicated.

Meta Robots (NOINDEX) is very effective for keeping the search pages out of the index and avoiding duplication problems, and it's much easier to implement. The advantage of rel=prev/next is that your other pages (2, 3, etc.) could potentially rank if they're a better fit. For internal search, like product search, I find that's almost never a big issue. It's much more important for article pagination (Google doesn't make this distinction very well in any of their recent statements).

Also, as Alan said, it's approved to just canonical to a "View All" version, if you have one and it's linked/available for users. That can create a huge page, though, so you have to take usability and load times into account.

Sorry, it's very complex - I need to do a write-up on this, as I'm frustrated with Google on the subject. Honestly, I still tell some folks to use NOINDEX, because it's just simpler and it's very effective and preventing duplication problems. Rel=prev/next is more subtle, but it does seem to work, if you can implement it properly.

It's probably true that the subdomain approach is easier, but I lean toward the subfolder these days - it's possible for subdomains to fragment in some cases and not pass all authority to the root domain. The subfolder can help preserve that inbound link value.

Ben and Andrea's comments about the difficulty of subfolders and potential risk of integrating WordPress on to your main servers are certainly valid and worth considering. I'm definitely not an expert on WP migration, and there's more than one way to achieve it. It's possible to actually keep the WP installation on a separate server and then make it act as if it "lives" under the "/blog" subfolder with a reverse proxy, but that's pretty complex:

http://www.apachetutor.org/admin/reverseproxies

No matter which route you go, keep in mind that you'd need to 301-redirect all of the old URLs to either the subdomain or subfolder version. Simply moving the WP installation won't migrate the inbound link-juice or traffic. Both visitors and spiders need to be redirected to the new URLs - that's absolutely critical.

Yeah, my gut reaction (although there's no one-sized-fits-all answer for every site) is in line with @blu42 - it's not so much about the folder-depth here, it's that this structure is inevitably going to create "thin" content, possibly by the truckload. Post-Panda, the days of just spinning out state+city+product are pretty much gone. It used to work great for long-tail search. Now, you risk it not only not working, but actually damaging your entire site.

It would be much better, IMO to have some kind of state/city structure but then land on the same make/model page, regardless of geography. You can get some kind of geo-targeting that way AND landing pages for products, but don't try to cross them on every variation. The tiny amount of long-tail traffic you pick up will probably be dwarfed by the problems you'll have.

Unfortunately, Dr. Matt's out of town, so this answer won't be as thorough as I'd like, but the gist of it is that we factor in both DA and PA to some degree. If a site has very high DA but a very low PA (as in your example), we're going to bias somewhat toward the DA, as we believe Google sometimes does (a virtually unknown page on Wikipedia can rank very well, for example). Likewise, a high-PA page on a site with low DA may pass more through the PA, because (hopefully) that page has some legitimate authority.

It's a bit more complex, because DA and PA are related as well, so they do influence each other to some degree. On larger sites, the influence of any single page's PA is small, but the influence can be more obvious on smaller sites.

Putting aside our math, I think a link from a low-authority page on a high-authority site can be worthwhile. Look at directories, like DMOZ. I think it's important to make sure the low-PA page is indexed (some DMOZ pages aren't, because they're buried so deeply in the link structure), and I wouldn't get hung up on a link from a high-DA site. It's ultimately just one link. I wouldn't dismiss it as useless either, though. There's some amount of site/page balance in the mix and Google doesn't rely on only one type of authority.

Since it's one page and doesn't even exist anymore, I honestly wouldn't lose sleep over it. There's no way to add/patch that return tag, because there's no page to add it to. Your tags on the German and Dutch homepages all seem consistent. I'd consider this a warning at best and not one likely to cause you trouble.

My only caveat - if, for some reason, Google is still indexing a bunch of AJAX-style URLs that don't exist, you may have some general crawl oddity. If this really is the only error like this you're seeing, though, it's more likely something Google just hasn't let go of yet. As Britney said, try to kick Google to reindex/recache, but otherwise I think it's likely harmless.

I've seen some reports in the past couple weeks of similar tests here in the US, but it only seems to be testing for now. Google is also testing new link colors, new "Ad" marker colors and a wider left column in the past two weeks, so they must really be running out of things to do

It's really tough (and even inadvisable) to try to pin a traffic change to an algorithm update based solely on spikes in a graph. On rare occasion, it's pretty clear (Penguin is a good example, I've found), but in most cases there's just a lot of gray areas and the graph leaves out a mountain of data.

The big issue I see here is potentially seasonality and knowing what happened to the site and business. For example, you can look at #6 and #7 and call these dips, but that sort of ignores the spike. Is the dip the anomaly, or is the spike the anomaly? What drove up traffic between #4 and #6? Maybe that simply stopped, was a one-time event, or was seasonal.

Why was there volatility between #7 and #14 and then relative stability after #14? You could call #14 a "drop", but not knowing the timeline, it's hard to see how the curve might smooth in different windows. What it looks like is a period of highly volatile events followed by an evening out.

Without knowing the industry, the business, the history, and without segmenting this data, trying to make claims just based on dips and spikes in the graph is pretty dangerous, IMO. This could have virtually nothing to do with the algorithm, in theory.

This is a great debate and some good comments all around, but I do think it's important to keep in mind that Matt's statements were from 2005 and 2009, and even the 2009 wording was a bit more nuanced. I strongly suspect Google has eased up on this early technical constraint. For example, try a search for "shop ipad" - you'll see this Apple.com URL in the Top 10:

store.apple.com/us/browse/home/shop_ipad/family/ipad/select

Google seems to have no trouble bolding "shop_ipad" as two words.

I still completely agree that, if you were starting fresh, I'd go with hyphens. A sitewide 301-redirect does carry some risk, though, so I think it boils down to this - are your pages ranking now for terms in the URL? If they seem to be ranking and it's just a matter of ranking better, I doubt the change would help much. If they seem to not be ranking at all and you suspect the URL terms are to blame, that's a different story.

Even in a perfect world, keywords in the URL are just one, relatively small factor. I'd want to see the data, but my gut reaction is to leave it alone until you need to make a sitewide URL change for other reasons.

When you say "park on top of" what do you mean, exactly? Typically, the host would be redirecting somehow (or using a CNAME).

For the old, active domains, you should keep the 301-redirects in place for the foreseeable future (at least a year) - the benefits far outweigh the costs. After that, you can probably just keep the domains and redirect them from the registrar directly (in other words, you won't need them hosted and redirected page-by-page).

With the several other domains, do those have active sites with content or are they just registered domains? There's no harm in pointing those domains to your main site, but it doesn't really accomplish much if they never were set up. If they're active sites, it really does depend on the scope and focus. I wouldn't 301-redirect dozens of domains all at once, as that can look suspicious.

Personally, I'm not nearly as fond of microsites as I once was. The benefits are declining, and the costs are increasing. The biggest cost, practically, is just splitting your efforts. At one time, that basically just meant content. Now, it means splitting link profiles, social efforts, etc. It's rarely worth the time and money. There are exceptions, and well-targeted microsites can work. Creating them just to have a few long-tail domains, though, isn't usually worth the trouble, and can create duplication issues.

Ok, well just to confuse the issue, Stefan Weitz at Bing just replied that they DO support cross-domain canonical. So, maybe it's a relatively recent development (?)

You have to keep in mind that, if it's anything like Google, the cross-domain application is only a suggestion. If the engines think that the cross-domain canonical doesn't make sense or the sites really shouldn't be collapsed that way, they may simply ignore it. So, even with general evidence or official sanction, your own application isn't guaranteed. On the other hand, if you're applying it legitimately, there's virtually no risk. Worst case, it doesn't work.

Unfortunately, this is a server-side issue, so the fix is completely different depending on your setup. Basically, the server is trying to compress your pages, most likely (using something like Gzip), and the settings are probably wrong. So, the final encoding isn't quite right.

At first, I was going to say that our crawler might just be finicky on this one, but when I try to load these pages on Google Chrome, I get a temporary error, after which the page loads. This definitely could be causing you some problems.

I tried to check out your setup with BuiltWith, but it's actually choking on the Gzip errors, too:

http://builtwith.com/sussexchef.com

Step 1 might be to just shut the compression/encoding off, and then try to work out the settings. You're probably going to have to pull in your hosting company and/or developer.

They link Corey cites has some good information - I think Matt Cutts' quote is dead on - it's unlikely to be harmed this way, but it's not impossible. I've seen 2 cases in the last year where we ruled out just about everything else and a very aggressive attempt by a competitor seemed to do damage.

So, how do you fix it? Unfortunately, there's no good way to cut a link you don't want, except to cut the page being linked to. Quite often, that's the home-page, unfortunately. I wrote about this in some detail last year:

http://www.seomoz.org/blog/6-ways-to-recover-from-bad-links

In most cases, I'd recommend (1) Wait it out, or (5) Appeal to Google (see the post). Many times, these links are clearly unnatural and built up quickly, and Google will recognize and devalue them appropriately. It might just take them a little time. If they don't you can file for reconsideration.

If you file for reconsideration, explain the problem in detail and provide data. It really adds to your case. Also, be sure that you've cleaned house. If you file for reconsideration for this competitive attack, but then you have 50 paid links, you might be opening a closet you don't want Google to peek into.

I'm endorsing Stephen's idea, because if you really have no choice, I think it's a good potential alternative. THB's comments (which I thumbed up) are very important, though.

If you really have no choice, I do think the 302 is safer here - the canonical tag should override it. There is some risk, though, and it's definitely not ideal.

I'm not clear on the problem, but could you return a 503? It basically says "We've got a temporary problem - come back later" and, if it really is temporary, Google won't de-index the pages. If you're talking a couple of days, this may be a better solution. If you're talking a few weeks, you may have to take Stephen's advice. You might want to pull in expert help, though, because my gut reaction is that there's a better way to fix what's broken here.

Weird... yeah, under normal operations, output buffering shouldn't be on. There probably are legitimate uses for it for more complex sites, but not as a default option.

The so-called "over-optimization" penalty definitely hit hard, sometime between 4/24-4/25. It is possible to see Google make a correction, but it doesn't appear that there were major changes between 4/25-4/26. Of course, this just happened, so we don't have much data.

Given the large scale of the drop and that this is a confirmed algorithm change, I think you have to start there. This is the official post from Google and I see that someone has already linked to Rand's post:

http://googlewebmastercentral.blogspot.com/2012/04/another-step-to-reward-high-quality.html

Look specifically at the terms that dropped. Are you aggressively targeting those terms (with keyword stuff, inbound anchor text, etc.)? I think the "Don't Panic" advice has some merit - if you over-optimize to reverse over-optimize, you've just made even more of a mess. I'm not saying to sit on your hands, but dig deep into the analysis and put together a reasonable plan of attack - don't just start changing things at random.

This is all within the same domain, right? If there's a pattern to how you change them, then you could write rewrite rules to cover the pattern. This is platform-specific, however - Apache is more flexible than IIS, for example.

The other option would be to create a database of the URL changes and reference that (and auto-301) every time a page is called. That's a lot trickier, though, and would take some serious coding.

If there's no clear pattern, I'm afraid it's going to take either the database or manually setting up 301-redirects. If you're doing this frequently, though, I'd strongly consider re-evaluating. Even proper 301s lose some amount of link-juice, and changing your URLs frequently can cause a lot of unintended SEO problems.

I can believe, in theory, that the location extension point is possible - even if the organic algo doesn't take your direct paid search data into account, they may share data sources, including location data (since that shared data doesn't bias one system based on the other). That said, I've met way too many AdWords reps that had no idea what they were talking about and yet, somehow, were happy to spout off misinformation. No offense to your particular rep, but again, I've had too many bad experiences. It's important, for many reasons, that your location data be consistent and accurate, but I don't think location extensions are a huge cause for concern.

There is an argument to be made, though, that working with the rep has benefits, even if the rep isn't always right. Reps tend to dig in, and if you aren't solving something they think is an issue, they may not help you get to other issues or positive traction. I recognize, though, that it can be hard to work across multiple parties, and your options aren't always ideal.

The off-domain landing page issue is a lot more complex. One common impact we see of paid search is the indirect boost it has on organic, based mostly on perception. If I see your brand in organic and the same brand in paid, and if the message is consistent (and, of course, appeals to me), my odds of clicking one or the other go up. This isn't an algorithmic bias, but a human one. Broadly, it also means that your paid ads are contributing to brand-building and name recognition.

If you're using a separate domain and if that domain is visible (and especially if it's confusing) to users, then you may be cannibalizing yourself. It's especially problematic if you've got two domains sharing a common message - this could confuse searchers about which domain is the "real" representative of your brand.

As Andy said, it also means that any links/mentions/etc. you might get to that secondary domain aren't helping you. In most cases, it's rare for ad landing pages to accrue links, but if a landing page is integrated into a site, then people are more likely to click through to other content, which might be shareable, linkable, etc.

Unfortunately, all of this is very speculative, without knowing more about your particular case. I think it's just important to note that there are many indirect interactions between paid and organic.

It's tough - on the one hand (especially pre-Panda), the geo-targeted content could help you rank. On the other hand, all those duplicates pose a real risk. These days, I think the risk is substantially greater than the reward. You could end up seeing the entire site devalued, even the non-geo pages.

Technically, Google could ignore the canonical tag if it thought the pages were actually different. You could use META NOINDEX instead, but here's my question - is it currently hurting you?

In other words, Google is ignoring the canonical in some cases and ranking those pages, but are your rankings overall doing ok? If they choose to ignore the tag, but that's not hurting you, I don't think I'd worry about it much. If you're seeing all the pages re-indexed and the duplicates are harming you again, then you may have to get more aggressive.

When you say "templates", can you explain what you mean? Do all 9 variations have the same content, but with a different wrapper (graphical look and feel)? In that case, I agree with @eyepaq - the canonical tag would be your best bet. It's a bit tough to tell with a specific example, but the key issue is how different the pages are (and if they have search value).

I have to disagree, though, regarding internal duplicate content not being a Panda issue. I think thin and near-duplicate internal content is very much part of the Panda equation. I've also seen large-scale duplication cause massive ranking problems.

Please be careful invoking the names of Google employees, unless you can provide an exact quote or verifiable source. Many of us have contacts at Google, and it's easy to misinterpret what they say, either publicly or privately. A statement like "JM has told me personally..." creates an air of false credibility that can lead people to the wrong conclusions, especially when you're paraphrasing.

I do agree that cross-channel awareness is important and there are many indirect ways in which paid search campaigns can influence (both positively and negatively) organic campaigns, but I don't want people to read this as meaning that paying for ads automatically boosts your organic ranking. That's a myth that too many people rush to believe, IMO.

Matt's statement also implies the changed the codename and/or didn't release the internal codename, so it's really tough to say. Even publicly, they called it the "Webspam update" prior to "Penguin".

I've never seen an issue where a large-scale META NOINDEX caused Google to get suspicious. It's possible to NOINDEX the wrong pages and lose traffic, but Google generally doesn't get jumpy about it like they would a large scale 301-redirect (where you might be PR-sculpting).

If these are really duplicates, canonical tags might be a better bet. Honestly, while I agree with Stephen 99.9%, if there's no glaring current issue, you could ease into it. Start with the worst culprits - obvious, 100% duplicates. That should be an easier sell, too. If you can't sell the larger cut, it's not going to matter.

These aren't regular site-links - you appear to be using the hCalendar microformat. I'm guessing there's just a validation problem. I notice you're not quoting ("") your attributes in the table. While the browser may read that ok, it's probably screwing up the microformat.

You've also got 2 "summary" classes for each event. It can get a bit tricky, and the specific code for any given site is a bit tough to tackle in a Q&A, but I'd see if you can add back the quotes and simplify the structure a bit. I strongly suspect your code isn't validating and the microformat is being parsed wrong.

Mark beat me to the punch Sorry, yeah that was a code change necessitated by some DOM changes Google made around early December. Unfortunately, they were subtle, and we didn't detect them initially.

I'm happy to answer any specific questions/concerns in this thread.

Read your additional comment (to @Highland). If you canonical from a known page (indexed and linked to, internally and/or externally) to an unknown page with no links, it would act a bit like a 301-redirect, in theory. The target page (of the canonical) would start ranking as if it were the source page.

The problem is that that page isn't really canonical. You have a tag saying "This is the page" but every single other cue (internal links, inbound links, etc.) says that the non-canonical page is really canonical. In other words, your canonical tag says the opposite of everything else you're saying. That's generally not a good situation. If you want a page to be canonical, treat it that way. Sending Google mixed signals can get messy fast.

Looks like they may have a ton of links to deep pages on sub-domains (like forums.tentonhammer.com), so we're not reporting the count right across the root domain. Once I dig in and export data, it's making more sense.

They're also doing something weird on the root domain - tentonhammer.com seems to redirect to www.tentonhammer.com, if you type it in, but then header checkers read it as a 200. So, we don't seem to be consolidating those links, either. I suspect that 220 number is way low.

Sorry, had an email glitch in Q&A. I'm pretty confident there was some kind of update around 5/5-5/6, and I'm equally confident that it wasn't Pengun. Panda is in "everflux" now, so I don't expect we'll see any more typical Panda updates (although it's hard to say).

There were some change reported to local search, and Google also rolled out or at least tested a number of new features. My gut feeling right now is that there are a lot of small things going on that, collectively, had a sizable impact. Unfortunately, the data isn't very clear. Overall, though, I saw enough reports from webmasters, industry people, and other flux-tracking systems, that the volatility during this period seems real.

Interesting - I've very rarely had issues with GWO, but if a new URL was created and someone linked to it, I can see where you might have a problem.

(1) None of these things are absolute, I'm afraid, but typically, yes - a rel=canonical to a different page should keep the first page out of the index.

(2) Usually, but it depends. The problem here may be that Google just isn't crawling the test variant very often, so they may not be processing the rel=canonical yet.

If it's just a couple of pages, I'd give it time - it's probably not an emergency situation. Again, you could just tell Google to remove them in GWT. I think you're doing the right thing with the canonical tags, but it can take Google time to process them the way you want to, in practice.

Historically, I've seen two cases where it went wrong:

(1) On rare occasions, if one site on an IP was penalized, it could carry to other sites - not always, or even usually, but it's happened.

(2) If the sites are cross-linked, those links are more likely to be devalued. A link network on one IP isn't exactly a master stroke of black-hattery.

I suspect (but can't prove) that (1) is less common these days. The simple reality is that we're out of IPv4 address space, so shared IPs are much more common now than they were a few years ago. Google understands that. The purist in me still says get your own IP whenever possible, but the SEO repercussions in 2013  are probably small in most cases.