Welcome to the Q&A Forum

Unfortunately, it is very situational and tough to tell without seeing the sites. I tend to agree with Marcus that it generally makes me a little nervous, but Zachary is right - sitewide links aren't necessarily bad. They just tend to be associated with quality issues, especially on large scale. Still, one site is one site. Worst case, those links are probably just being devalued (in other words, Google is turning down the volume on them).

If you're sharing content across the two sites, you might want to try a cross-domain canonical tag instead. It really depends on the degree of the duplication. Still, a link bank from each piece of content to the original content is generally a good idea.

Any sitewide links, like footer links, on top of that, are probably very low value. Whether I'd remove, nofollow, or leave them alone, though, really depends a lot on the quality and the relationship between the two sites.

Unless I'm misunderstanding, I think of "search results" pretty broadly - and category pages would apply. Each category page is a set of links to products (patio umbrellas, in this case), right? If you're talking about something totally different, please elaborate, because I may be missing something.

Sorry, my answer makes it sounds like link-juice would be completely cut-off, which isn't correct. If you have a NOINDEX,FOLLOW'ed path, some (most?) link-juice will travel down it. So, if there are links to Page 1 of search, and Pages 2-10 are NOINDEX,FOLLOW, then there are product pages, the product pages will get link juice.

I'm not 100% sure, though, what happens with links directly to NOINDEX,FOLLOW pages - I've heard some people suggest that it can disrupt link-juice flow. I suspect that may only be partial, but I've never seen much in the way of data.

Practically, I think people worry a bit too much about that, as it's very rare to get links to page 2+ of search results (people link to either the top-level pages or the deep, product pages). Theoretically, though, you're absolutely right.

I haven't had a lot of problems with NOINDEX, FOLLOW leaking link-juice (in that pages below it ranked), but it's nearly impossible to ever test it both ways and measure which is better. The theoretically advantages of rel=prev/next are:

(1) Less link-juice disruption, as you said.

(2) That Google can choose to rank a different page in the series (like page 3 of results) if that page is more applicable.

I think, honestly, that rel=prev/next was really designed more for paginated articles, which have similar META data but unique content. Paginated search is a bit messier.

I think (2) - the canonical tag - is a solid solution if just a few URLs are out of whack, but if you're using the mixed-case version internally, then you may need to change your structure as well. If you change your structure, then I'd probably look at a full-scale system of 301-redirects to preserve inbound link-juice.

It sounds like you're linking to mixed-case internally, so you may need to set up the redirects. Make sure that, depending on your platform, the case-specific redirects work properly (and don't create an endless loop). There is some risk to making the switch, so I'd probably only do it if you're seeing this happen a lot. Unfortunately, mixed-case URLs are often more trouble than they're worth.

Michel is right - Google doesn't care that they're one template - if both URLs are being crawled, then they'll see that as two "pages". Every unique, crawlable URL can become an indexed page. That's why duplicate content problems are so common.

The good news is that you can put a canonical tag on just the one template/file and it will cover all of the paths/URLs that land on that file. The tag goes in your section and looks like:

I'd check the internal links, though, and see if you're linking to both versions. It's best to use one, consistent URL in your internal links for any given page.

If Google is changing the rules, it doesn't really matter if you make changes or not, in some cases. For example, we've seen issues recently where Google tweaked domain diversity and gave more spots to the same domains. In some cases, that pushed other people down, even though those other people didn't do anything wrong. In many cases, Google seems to test changes and then adjust, so you can see ups and downs.

In other cases, I've seen situations where Google pumped up "freshness" (QDF), either overall or for certain queries. So, sites with new or updated content suddenly got a boost, and sites with older content got pushed down, even if those sites didn't do anything.

Of course, it's also always possible that your competition has made changes. Even if you change nothing, other people are constantly changing their sites.

Now, if only you are bouncing around, and the rankings are otherwise pretty consistent, then it is possibly a sign of a problem. You could be facing a potential penalty, for example, or some of your links or content are being devalued. This can range from something simple and no fault of your own (a site that used to link to use no longer does) to a full-scale penalty brewing. It can be really tough to diagnose "bounce", but it's much more common than I suspect most people think it is.

It's always hard to talk in generalities about complex issues like this, but it sounds like a situation where cross-domain canonicals might make sense. I guess it really boils down to whether you're having issues with the duplicates and what the scope is (are there 3 of each or 300). In some cases, those duplicates just mean that one site will win, and Google will pick the winner. In other cases, the main site could actually be harmed by the duplicates. In some cases, honestly, multiple sites might rank fine. It really varies wildly.

The cross-domain canonicals would help prevent any kind of duplicate penalty (like being hit by Panda), but it would also mean that the non-canonical versions would no longer rank. So, you'd be protecting the strongest site for each listing, but possibly cutting off the smaller sites.

I haven't seen an implementation where different sites were canonical for different listings/articles/etc., at least not on large-scale, so that's a bit tougher to predict. If you have sites A-Z, and A is canonical for one listing, B for another, C for another, etc., that could get a bit tricky. I know large organizations, like newspapers, who syndicate content, have had good results in many cases with cross-domain canonical.

There is also a syndication-source tag, but that's really a weaker tag, and I haven't seen much data on it. The other option, traditionally, would be a solid link-back strategy (the non-canonical versions link to the canonical version). Unfortunately, at large scale, that could start to make you look like a link network, so I think that gets risky in this case.

Unfortunately, I don't know the Twylah system, but Google is indexing 138 pages from your main site and 1,650 (about 12X your main site) from the "tweets." sub-domain. I strongly suspect that this is going to look like thin content, and when it's overpowering your main site's content, you could see really SEO problems.

I'm not sure what the goal is, but I doubt the gains from this system will offset the losses. If it's valuable to users, no problem. From an SEO perspective, though, I strongly doubt this is beneficial.

Google's official advice is that rel=prev/next should include the additional parameters, but then you should rel-canonical to the non-parameterized URL for that individual page. Setting it up properly, unfortunately, is difficult and I feel that it's too confusing to be adopted by most sites.

You can META NOINDEX pages 2+ and sorts and see how it works, or you can also block parameters in Google Webmaster Tools (or tell them those parameters are for pagination). Unfortunately, the "right" answer often depends on the size of the site and the scope of the problem. In some cases, I've found that the by-the-book approach works fine, and in others we had to throw out Google's book and improvise. I wish I could tell you that there's a one-sized-fits-all answer, but there doesn't seem to be, in my experience.

It can be a bit tough without seeing the domain (since these situation can vary a lot), but I tend to agree with Matthew - the masking can cause a lot of strange side-effects, for search and visitors. One thing I'd definitely do is so how Google is indexing your content. You can just use the "site:" operator:

site:example.com

(with your domain, and leave off the "www") - if your correct domain is showing up with indexed pages, and there aren't a ton of duplicates, you're probably doing ok. If your posts aren't being indexed and are only showing up under the Blogger domain, then your set-up is sub-optimal at best.

If you're coming to MozCon, you'll get the full version of this answer during my presentation Let me just say that, while we only track a few major events (like Penguin), Google has made 500+ changes/year since at least 2010 (and probably similar numbers prior to that). The algorithm changes almost 1-1/2 times/day, in other words.

For the last two weeks, rankings flux has been incredibly high - the Panda 3.7 rollout lasted 5 days, or something happened along with it. We think of rankings as static, but they aren't - some keywords Top 10 rankings can completely and permanently change within a week or so (in other words, every site in the Top 10 is replaced).

This isn't rotation, per se - it's constant tweaking and re-tweaking of the algorithm. Add to that things like freshness and personalization/localization, and rankings are changing faster and faster every day. Whether we like it or not, this is the future of Google.

If you only changed the URL, I wouldn't worry about it too much. Your 301-redirect seems to be working properly. It can take time to kick in fully (both for us and for Google), but we also base PA on an overall model of the links, so we transfer less through the 301 (especially in the short-term) than Google does. I don't think you have any reason to worry here.

The only issue would be if you changed the overall site architecture, and not just the URLs. Then, it is possible that the new page is getting less internal link "juice".

I'm seeing a lot of duplicates in your forum pages - I think the issue is that any attempts to click into the forum go to the login page, but the URL stays the same. You may want to block those from crawlers somehow (META NOINDEX, for example), since Google can't log into member areas.

They don't seem to be currently in the Google index, but there is potential to dilute your site's ranking ability and for Google to think that your content is "thin". I do think it's a problem you should address.

Just following up on Matthew's comment. The reason for the canonical to Page 2, in that example, is to cover any kind of additional duplicates, like sorts. For example, if you had URLs like:

1. http://www.domain.be/product-overview/2/price
2. http://www.domain.be/product-overview/2/rating

...where those pages sorted by price or product rating. Then, you'd want to canonical all sorted versions to "/2". In that case, the rel=prev/next tags should actually include "/price" and "/rating", depending on which page you're currently on. It's a mess, honestly, and I'm not thrilled with Google's implementation, but it seems to work fairly well.

Bing's implementation is limited, unfortunately.

FYI, if there are no other duplicates (just pagination), you don't really need the canonical. It won't hurt you, but it's unnecessary.

A self-referencing canonical isn't necessary, in most cases, but it doesn't seem to cause any practical issues. I'm not sure why our tools are saying that your canonicals weren't set up correctly. We do have a notification if a canonical tag points to a different URL, but that's really just a heads up (in most cases, canonical tags will point to different URLs than the page their on). There's no good way to detect what page should be canonical, so our warnings are a little hyperactive in a few cases.

I would double-check that your internal links match your canonical URL - that's the biggest issue we see (inconsistent signals).

I don't recall why, but I don't think you can use a full (absolute) path for the first part of a "Redirect 301" statement Could you try just:

"Redirect 301 /index.html http://www.abc.com"

Typically, the rewrite command (with flag of "R=301") is much more flexible. The "Redirect 301" syntax has some limitations - it's easier to use, but it only covers a few, simple situations.

I think we were confused about how the actual pages differ? Is the visible content Google is getting different, or is it just source code. Without giving away too many details, can you explain how the content/code is different?

Agreed - if you're talking about source-code order, it can be considered cloaking AND it's not very effective these days. Google seems to have a general ability to parse the visual elements of your site (at least, site-wide, if not page-by-page). In most cases, just moving around a few code elements has little or no impact. It used to make a difference, but general consensus from people I've talked to is that it hasn't for a couple of years. These days, it can definitely look manipulative.

If it's just a few cities, it's probably not a big deal either way, and the search results could give you a landing page. If you really plan to expand down the road, I think I'd go with your alternative approach, at least for now. Keep Google on the main site, and you can let users select their appropriate city page (and cookie that).

If, down the road, you've got a good structure and solid back-links, and you want to open up the city pages to crawlers, you can always change that later. It's not black-and-white, but in 2012 I think it's best to go out narrow and really focus your link profile on your core pages, expanding once you've got the authority and history to make it work.

Agreed - although I think a 301-redirect or canonical tag implementation would probabyl be ok. If there's a database lookup that can translate the DocID into a URL string, the canonical is easy (I write some CF code, so I can at least tell you it's doable). Keep in mind that "article.cfm" is only one template, so if you can find a solution that's data-driven, it's just as easy for 1,000 pages as it is for 10.

You could also create a dynamic 301-redirect via <cfheader>- the core logic is the same. Basically, you look up the URL from the DocID and dynamically create the tag. You just need someone who understands your CMS and data. The actual code is only a few lines, but understanding your setup is the time-consuming part.</cfheader>

Unfortunately, it's a tricky situation, and I'm not sure there's one "right" answer. I think some of the feedback in the comments is definitely accurate, but it depends on the circumstances. There are two big factors to consider:

(1) It's probably best not to spin out hundreds of city pages, if they're just a template with a few geo-targeted words changed around. This used to be common practice to rank for long-tail terms, but since Panda, it's really gotten to be risky. If Google sees hundreds or thousands of thing pages, your entire site could be penalized. Meanwhile, those thin pages don't generally rank well, even best-case.

(2) The 302-redirect is going to leave link-juice at the home-page, but still allow Google to crawl the city-based pages. If you're using geo-location, it probably doesn't matter whether you use a 301 or 302, honestly, because Google is going to come via US IPs and it will never trigger an Australian-based location. So, you need to make sure your solution works for the crawlers and decide where you want them to land.

I looked at your campaign, and you've essentially got two options here:

(1) You could add a unique element to the title tag, like the availability date.

(2) You could canonicalize or de-index the variations.

Keri's warning is correct about the home-page, but it looks like this is a stand-alone page and rel-canonical would be viable. That would clean up your index gradually, but it would also remove the individual availability pages from the search index (and ranking contention), so it does depend a bit on your strategy.

For the site 9K pages, is quite a bit. The other thing you could do is change the system to only create links for dates with available events. I notice you have a lot of blank dates. Linking those serves no purpose, either for users or Google (and is just creating worthless pages, essentially). If you did that, a lot of these would clean up over time.

You might also consider just blocking the calendar links at some point - in other words, go back 3-6 months, but then don't bother. Don't make Google crawl 5 years worth of past dates.

From a "pure" SEO standpoint, here's what I'd say we know about user metrics:

(1) Bing has confirmed using click-through rate (CTR) and "dwell time" as ranking factors. Dwell time is the time it take a visitor to return to search results from a site, so it's related to both bounce rate and time-on-site.

(2) Google has officially said that they do not use bounce rate as a ranking factor. Google historically defines things narrowly, so we don't know if they factor in dwell time. Reading between the lines, they seem to find it unreliable.

(3) I'm not sure if Google has confirmed this, but they very likely factor in CTR.

(4) We don't know for sure how user factors fit into Panda, although people have certainly suggested a connection. My gut reaction is that, if it's part of Panda, it's not a large part.

Of course, looking beyond SEO, reducing your bounce rate and increasing your page-views and time-on-site is great. You've improved your engagement and it will help you. This is in no way wasted effort, and even if it doesn't have a direct, immediate impact on SEO, it will have indirect effects.

You mentioned the CMS spun out a lot of duplicates. If you have text-thin pages AND a ton of duplicates, that certainly could cause some problems. Have you taken steps to control and de-index those duplicates? That would probably be the first place I'd look, from your description of the problem.

Essentially yes - pages 2+ of search just look "thin" to Google. They tend to have similar title tags, META descriptions, etc., and Google honestly isn't all that fond of indexing search pages in the first place (they don't want their search to land on your search). Those 2+ pages also don't tend to attract links or make a lot of sense for someone landing on them. By using META NOINDEX,FOLLOW, Google can crawl those searches to deeper pages, but the actually search pages don't dilute your overall site and search index.

Google's preferred method (or so they say) in 2012 is rel=prev/next, but I find that implementation can be much trickier than META NOINDEX. It's a difficult topic, and I honestly find that the ideal approach varies wildly from site to site. It's important to plan well, implement careful, and measure the results.

Certain characters, like spaces, should generally be encoded in the URL. It's generally just a few characters, and honestly those characters would be better off not in your URLs.

If your site is creating encoded URLs, though, then you should use those URLs everywhere - internal links, canonical tags, etc. There's no real trick to it - it's just that you should use the same URL format everywhere.

Unfortunately, pagination + sorts gets ugly fast. Technically, the rel=prev/next tag should contain the sort parameter AND then you should canonical to the main pagination page. So, for example if you had a page like:

www.example.com/search.php?page=2&sort=asc

You should have tags like:

• Rel=Prev: http://www.example.com/search.php?page=1&sort=asc
• Rel=Next: http://www.example.com/search.php?page=3&sort=asc
• Canonical: http://www.example.com/search.php?page=2

In practice, it's incredibly hard to implement. So, you could do a couple of things:

(1) Block the sort_by parameter with Google Webmaster Tools parameter handling

(2) Use META NOINDEX, FOLLOW on all pages 2+ of search and sort URLs

I don't find Robots.txt works that well, in practice, and 800K blocked URLs can make Google jump. I'm actually confused by how Google is crawling the sorts at all (since they're form-driven). It looks like you put the sorts in your pagination links. Would it be possible to store any sorts in a cookie or session variable and not add those to links?

Given your current situation, and that Google has indexed thousands of sort URLs (from what I can see), I think the Google Webmaster Tools approach might be the safest. This is a complex problem, though, and you may need to consult someone.

(1) DON'T canonical to the first page of results - Google definitely has issues with that. If you've got rel=prev/next in place, then I wouldn't canonical to "View All", either. They're kind of competing signals. You can use rel=prev/next with rel=canonical, but it's a bit complicated. Basically, it's for situations where you have pagination AND some other parameter, like a sort.

(2) If you increase it, just make sure it doesn't negatively impact users or load-times (might be worth A/B testing, honestly). Are you saying that you might end up with a URL like "?page=7" which basically doesn't exist because now you'll have less pages? I think you might be safer just letting that 404 and have Google recrawl the new structure. The odds of having any links to Page 7 of search results (inbound links, that is) are very low, and just letting those pages die off may be safer.