Implementing Pagination Attributes Correctly For Google
Google’s latest blog post provides details and a video from Maile Ohye about how they handle the pagination attributes within a page’s source code. You can use these attributes to indicate pages in a series (such as a multi-page article or set of product listings), which enables Google to cluster the pages into a single entity […]
Google’s latest blog post provides details and a video from Maile Ohye about how they handle the pagination attributes within a page’s source code. You can use these attributes to indicate pages in a series (such as a multi-page article or set of product listings), which enables Google to cluster the pages into a single entity and combine their indexing and other properties (such as incoming link value). Using these attributes is trickier than it may seem at first glance, so below, a few tips from the blog post, video, and the recent SMX West session I moderated, which featured Maile. (Keep in mind that currently, only Google supports these attributes.)
How the Pagination Attributes Work
The pagination attributes can be used for any set of content that spans multiple pages. Typical scenarios include multi-page articles, product listings, and forum discussions. Simply use the rel=next and rel=prev attributes to link all pages in a series together. For the following set of pages:
The pagination attributes would be as follows:
When To Use Pagination Attributes Instead of Canonical Attributes
Some sites are set up to use the canonical attributes to point all pages in a series to page one. As Maile points out in the video, this isn’t the correct use of the canonicalization tag (in part because Google only indexes the content on the canonical page, so any content from the rest of the pages in the series would be ignored).
If the paginated content is a subset of the canonical page (such as when you have a view all version or a filtered result set) or is identical (such as when the sort order changes the display but not the content), then use the canonical attribute instead of the pagination attributes.
General Best Practices
Use Absolute URLs
The href values can be absolute or relative (the original version of this article said they had to be absolute, but that version was incorrect). But using absolute URLs is a best practice, both to combat scrapers and in case URLs are duplicated accidentally across directories or subdomains.
The Chain Can’t Be Broken
The rel=”next” and rel=”prev” values must match. If they don’t, the chain is broken. For instance, for the following pages:
The rel=”next” attribute for page=1 must point to page=2 and the rel=”prev” attribute for page=2 must point to page=1.
The pagination attributes can only link together URLs with matching parameters. For instance, the following URLs aren’t considered part of the same series, as the second URL would break the chain:
This means that ideally, you should dynamically insert the pagination values based on the fetched URL. In the case of the above example,when Googlebot fetches the page as:
The pagination values should be (dynamically inserted as):
Each page can be in only one pagination chain
- A page can’t contain multiple rel=”next” attributes.
- Multiple pages can’t have the same rel=”prev”.
- A page that contains a rel=”canonical” attribute to another page can’t be part of the canonical URLs paginated series. It must be paginated with the URLs that match it (and then Google will use the canonical attributes to consolidate each page accordingly). See more on how this works at the end of this article.
Product listings in particular often have additional complexity, such as sort orders and filtered navigation. It’s best to start with the simplest paginated series and then make canonicalization and pagination decisions for each level of complexity. You can’t specify one view/filter as canonical and point all other versions of the paginated series to that default set.
Viewing and Sorting Options
If a set of product listings has multiple view options and those listings span multiple pages, you have to create a pagination set for each view option separately (since the pages aren’t subsets of a default version). For instance, if you provide options to view 20 products at a time or 100 products at a time and to sort by newest, price, and ratings, you would need to implement a separate paginated series for each view option. As you might imagine, this could cause you to end up with a large number of paginated series’. Shown below are just two of the many possible:
Filtering (AKA Faceted Navigation)
Things get even more complex when you introduce filters.
- If the filtered view is a subset of a single non-filtered page (perhaps the view=100 option), you can use the canonical attribute to point the filtered page to the non-filtered one. However, if the filtered view results in paginated content, this may not be viable (as each page may not be a subset of what you would like to point to as canonical).
- If you want the filtered view to rank separately from the default view, you would create a paginated series for each filtered category. You would need to also paginate all of the various sort and view options separately. Take REI.com as an example. The site has a Snowboards section that would likely be paginated and (hopefully) rank for [snowboards] queries. But a filtered view of just Women’s Snowboards, while a subset of the snowboards content would likely be paginated separately in order to rank for [women’s snowboards] queries. (On the other hand, REI probably doesn’t want the filter by size version to rank separately, so that variation could be canonicalized.)
Using the Canonical Attribute in Conjunction with the Pagination Attributes
Each URL that’s paginated separately should also contain a canonical attribute. In the case of the earlier example with the optional referrer parameter, for instance, Google will first consolidate the default paginated series separately, and then the paginated series that contained the referrer=twitter parameter separately, but then use the canonical attribute of the pages to further consolidate the pages to the default version. That means that the URL of:
Would end up with the following markup:
Too Confusing To Implement?
I admit, all of this sounds confusing. But it’s not so bad if you take things step by step:
- What is the canonical version of each URL? Add the canonical attribute to the pages.
- What is the default view for each paginated series? Add the pagination attributes to these pages.
- What views/filters are subsets of broader views? Add the canonical attribute to these pages to point to those broader views.
- What views/filters are not subsets of broader views or you want to rank separately? Add separate pagination attributes to these pages to make each a separate series.
Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.