Video: Avoid these Pagination ‘Gotchas’
E-commerce sites, with their typically huge number of URLs, are especially susceptible to duplication—even when great efforts are made to avoid it. In this video, I speak to three of the most commonly reported causes of unintentional duplication that occur during the setup of pagination, and what you can do to fix these troublesome ‘gotchas.’
Links to other pagination-related blog posts:
Adam Audette: Hi everyone. Adam Audette, back on the RKG blog. Talking about pagination today and the use of rel=”prev/next” and rel=”canonical”. And this is really effective for pagination on e-commerce sites. It’s a big problem for complex sites that have a lot of pages and a lot of categories because crawling is difficult with so many different URLs and versions of URLs. And indexing is also very, very difficult. It creates a lot of seemingly duplicate content. And actually, really duplicating content based on different versions of URLs firing the same content.
So, here are the three primary problems that we see with rel=”prev/next” and “canonical”. These are common gotchas that are pretty easy to solve, but there’s a pattern that we see of these out in the wild.
The first one is rel=”prev/next” being used where the second page actually references a different version of the first page. And I’ll tell you a little bit more about this. Basically what happens is you’ve got a category. Say it’s “green running shoes” and it’s got ten pages. Page one starts out with rel=”next”. There’s no “prev” because it’s page one, and rel=”next” references page two. All good so far. Page two then, has a rel=”prev” referencing page one, but not the same page one that actually got linked on the site and started the whole series, referencing a different page one instead of the page one that it should. So, what that does is it, that page one then kind of becomes a rogue out there and it’s not part of that whole series of pages, or that whole family. So, you just want to make sure that your page two actually references the actual page one that’s part of that series.
The second thing that happens is the URLs that are used in rel=”prev/next” are canonical URLs, and are not actually the URL that is used in the browser bar to render that page. So, I’ll tell you a little bit more what I mean. When you’re in a page, say you’re in a page four, and you look up at the URL window in the browser bar, that’s the URL that gets put in to rel=”prev” and “next” annotations. That version. It should have tracking IDs if they exist on there, session IDs if they exist on there. It should really just be exactly what is in the browser bar. It shouldn’t be the canonical version of that. Rel=”canonical” is then used to basically clear up the duplication. So you can think of rel=”prev/next” as indexing signals coming together into a series of pages, and rel=”canonical” as clearing up duplication between URLs that fire the same content.
The third is rel=”canonical” being used to reference a view-all page or to reference a page one version of the page. And, again, for rel=”canonical” it should really just be used to reference the canonical version of that URL. And, so taking out session IDs and tracking parameters and things that you don’t want crawled and indexed because they actually don’t change the content of the page.
A lot of detail there. We’ve written more about it in blog posts on the site. They will be linked here. So check that out. And if you have any questions or comments, I would love to hear from you. And any experiences, I’d love to hear that too. Thanks a lot, everyone. And until next time, SEO safe.