Welcome to the Q&A Forum

Luckily it's disappeared today, which leads me to believe it was a Google-side algo error that was swiftly corrected (nothing we have done will have reflected in the serp so quickly, I doubt)

Thanks for your reply, Gary.  I'm not entirely sure how our (far reaching and lucrative) affiliate tracking/logging works, but I would have thought 301ing all the links to the original page would sabotage it, no?!

The canonical will certainly work but we've only reinstated it on the homepage as we have 6 other sites that have hreflang alternates in place and the canonical seems to interfere with their function.

An odd and slightly scary thing happened today: we saw an affiliate string version of our homepage ranking number one for our brand, along with the normal full set of site-links.

We have done the following:

1. Added this to our robots.txt :

User-agent: *
Disallow: /*?

2. Reinserted a canonical on the homepage (we had removed this when we implemented hreflang as had read the two interfered with each other. We haven't had canonical for a  long time now without issue. Is this anything to do with the algo update perhaps?!

The third thing we're reviewing I'm slightly confused about: URL Parameter Handling in GWT. As advised - with regard to affiliate strings - to the question: "Does this parameter change page content seen by the user?" We have NO selected, which means they should be crawling one representative URL. But isn't it the case that we don't want them crawling or indexing ANY affiliate URLs? You can specify Googlebot to not crawl any of particular string, but only if you select: "Yes. The parameter changes the page content." Should they know an affiliate URL from the original and not index them? I read a quote from Matt Cutts which suggested this (along with putting a "nofollow" tag in affiliate links just in case)

Any advice in this area would be appreciated.  Thanks.

Hi Tom,

It was one of my colleagues that asked the question on my behalf. To clarify, we are actually aware the text is crawlable, what I was wondering is whether the text in title tags on thumbnails would be treated (in terms of exact match keyword weight) the same/grouped together with copy between span tags, for instance.

We have a category page with 75 instances of 'example' and 'examples'  including title tags on thumbnails, anchor text and sales/seo copy (and 325 instances of the keyword in the source code)

So the question is, would we be better to make the thumbnail text uncrawlable to avoid over-optimisation penalisation?  Just a thought

Thanks for you reply.

On a page that lists products (thumbnail text repeating the same word when you sell variations of the same thing) and also has copy at the bottom, are the product names crawlable? Is it better to avoid repeating the keyword in the copy? Can you get penalised for it?

Hi Chiaryn,

Thanks for reply and explanation.  The different colour-specific pages e.g.  Tweed Green and  Olive Green have some different content but it's nothing like enough in cases of two greens, two blues etc. as we simplify colour names for search so when there is an Olive and a Tweed Green they both end up having 'Green' as variable in page title, H1 etc.   Will fix this.

Do you think the reviews at the bottom of the pages will also trigger dupe content warning? i.e. even if we make all other on-page elements unique for each colour url? (page title, H1, H2, prod description etc) The reviews are quite extensive and are the same on all the separate colour specific product page versions of each style and was thinking today whether we should remove them from these colour product pages (OR perhaps let the colour product pages have their OWN reviews)

http://www.woolovers.com/british-wool/mens/tweed-green/wool-countryman-suede-patch-sweater.aspx

Thanks again

Oh, brilliant (re: "See more" aspect)  Thanks for the info. Will let you how we tackle this and the repercussions (!) and look forward to hearing how you get on also!

I infer from what your saying that the amount of people with javascript disabled in 2013 is probably less than negligible. This is a very good point. Looks like we're perhaps trying to fix the engine of a car we should have got rid of a while aqo...!

Thanks, Chiaryn.

That's news to me that changes had been rolled out (last I heard they were on staging and not working - great interdepartmental communication!)

Lawrence

Hi there,

Thanks for your response.

It's not product page A being seen as a duplicate of product page B etc, but several versions of product A seen as duplicate due to pagination, stemming from reviews for the products that span several pages, so making the rest of the content, titles etc different other than the (crawlable) reviews isn't really an option.

Will look more into "noindex, follow" tags in pagination.

We could have a  View All page for indexing showing all reviews (with lots of scrolling!) , with the paginated versions canonicalized  to that version (could still serve the paginated version of product page from site navigation perhaps with  "noindex, follow" meta tag) Text doesn’t take long to load and this approach would consolidate the review content.

http://googlewebmastercentral.blogspot.co.uk/2011/09/view-all-in-search-results.html

Other option is to use rel=”prev” and rel=”next” implementation which shows Google the relationship between the pages (not sure if it will still be flagged as dupe content in SEOmoz though! Depends if they follow the tag). This way individual pages might get indexed (not sure if that's a good thing?!) perhaps if there's something in a review from (say) page 5 of the product reviews.

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

Ideally I'd like to implement all reviews on one page and hide them with a facebook-style 'See more' function. Not sure if that counts as hiding content? Will look into this.

Luckily it's disappeared today, which leads me to believe it was a Google-side algo error that was swiftly corrected (nothing we have done will have reflected in the serp so quickly, I doubt)