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 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:

  • www.site.com/products?page=1
  • www.site.com/products?page=2
  • www.site.com/products?page=3

The pagination attributes would be as follows:

Page 1:

<link rel=”next” href=”http://www.site.com/products?page=2″>

Page 2:

<link rel=”prev” href=”http://www.site.com/products?page=1″>

<link rel=”next” href=”http://www.site.com/products?page=3″>

Page 3:

<link rel=”prev” href=”http:// site.com/products?page=2″>

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:

  • www.site.com/products?page=1
  • www.site.com/products?page=2

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:

  • www.site.com/products?page=1
  • www.site.com/products?page=2&referrer=twitter
  • www.site.com/products?page=3

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:

www.site.com/products?page=2&referrer=twitter

The pagination values should be (dynamically inserted as):

<link rel=”prev” href=”http:// www.site.com/products?page=1&referrer=twitter”>

<link rel=”next” href=”http://www.site.com/products?page=3&referrer=twitter”>

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.

Advanced Techniques

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:

Pagination and Sorting

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:

www.site.com/products?page=2&referrer=twitter

Would end up with the following markup:

<link rel=”canonical” href=”http://www. site.com/products?page=2″>

<link rel=”prev” href=”http://www. site.com/products?page=1&referrer=twitter”>

<link rel=”next” href=”http:// www.site.com/products?page=3&referrer=twitter”>

Too Confusing To Implement?

I admit, all of this sounds confusing. But it’s not so bad if you take things step by step:

  1. What is the canonical version of each URL? Add the canonical attribute to the pages.
  2. What is the default view for each paginated series? Add the pagination attributes to these pages.
  3. What views/filters are subsets of broader views? Add the canonical attribute to these pages to point to those broader views.
  4. 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 the article are those of the guest author and not necessarily Search Engine Land.

Related Topics: Channel: SEO | Features: Analysis | Google: SEO | SEO: Duplicate Content | SEO: General | Top News

Sponsored


About The Author: is a Contributing Editor at Search Engine Land. She built Google Webmaster Central and went on to found software and consulting company Nine By Blue and create Blueprint Search Analytics< which she later sold. Her book, Marketing in the Age of Google, (updated edition, May 2012) provides a foundation for incorporating search strategy into organizations of all levels. Follow her on Twitter at @vanessafox.

Connect with the author via: Email | Twitter | Google+ | LinkedIn



SearchCap:

Get all the top search stories emailed daily!  

Share

Other ways to share:
 

Read before commenting! We welcome constructive comments and allow any that meet our common sense criteria. This means being respectful and polite to others. It means providing helpful information that contributes to a story or discussion. It means leaving links only that substantially add further to a discussion. Comments using foul language, being disrespectful to others or otherwise violating what we believe are common sense standards of discussion will be deleted. Comments may also be removed if they are posted from anonymous accounts. You can read more about our comments policy here.
  • http://www.tiv.net/ Gregory

    Thank you Vanessa, all very clear and not confusing at all.

    The question is: why do we want Google to index search result pages at all?
    I guess, the content on those pages is a repetition of what’s on individual product pages. So, why not to make all of them “noindex, follow”, and skip all the markup you mentioned?

    … after I wrote that, I started thinking that maybe the best would be both: markup, AND still noindex. So, Google will know how to travel and group, and “pass the juice”. Does that make any sense?

    Thank you!

  • http://ninebyblue.com/ Vanessa Fox

    Definitely for search results, the best bet is to noindex,follow them. This is more for category pages that have product listings. This page, for instance, wouldn’t be considered search results:
    http://www.rei.com/category/4500304

    It would be the page that REI would want to rank for a [snowboards] search.

    Whereas this page would be noindexed:
    http://www.rei.com/search?query=snowboards

  • jrock

    Hi Vanessa,

    Thank you. Your post couldn’t come at a better time. And what a great name by the way. Vanessa Fox. Nice.

    My wife and I are launching a new e-commerce site and many products are very similar and come from the same line from the same brand. There will some duplicate content in some product descriptions. For instance, we have 6 variations of probitoics from one brand.

    Any tips on home some newcomers to e-commerce like us coul I feel like I should jsut forward your blog post to our developers in India and hope they get everything you saying.

  • jrock

    Sorry my son just jumped on keyboard before I could edit my post.

    I was wondering what some good first steps would be to apply pagination. It really seems like we need it.

    Thanks again – great post

    J

  • http://eywu.com Eric Wu 吴 ¯_(ツ)_/¯

    I’m wondering what would be the negative ramifications if you didn’t dynamically insert the query parameters based on the fetched URL?

    While it’s simple for some developers to do this, I could see that it would be more difficult for others. Especially considering that you would have to sanitize the query parameters since the values are being rendered into the HTML, and query parameters could easily be injected by a potentially malicious user.

    Given the example above, assuming you don’t want the “&referrer=twitter” parameters to be indexed, if you dropped the “&referrer=twitter” effectively breaking the chain, would Googlebot fetch the canonical? And then in fetching the canonical it would see the corresponding next/prev that are now correctly in the chain?

    Seems like it might break some of the crawl efficiency, but the trade off in dev hours and maintenance seems like it might be a worthwhile trade-off.

  • http://www.returnondigital.com/about-us/dave-ashworth.php dave_ashworth

    It has been interesting to see how Google have used the rel/prev tags as an issue arises with the use of WordPress as a CMS – we have seen a client site transfer from static site with rankings across many pages for different keywords lose all but home page rankings due to the way in which WP implements the tags – if you set up a series of pages it automatically adds the tags in to aid users with sceren readers/disabilities etc to help navigation.

    The non techies amongst us would be hard pressed to work out why, I did write a blog post about it:

    http://www.returnondigital.com/blog/wordpress-default-canonical-issue-and-how-to-avoid-it

    Would be interesting to know if there was any dialogue between WP and Google to avoid this issue in future versions of WP

  • https://plus.google.com/105720802884434674393?rel=author Kenichi Suzuki; 鈴木謙一

    Thank you for a very helpful post, Vanessa. I have a question.

    You says,
    > The pagination attributes can only link together URLs with matching parameters.

    How about a case like this:
    http://www.site.com/products
    http://www.site.com/products?page=2
    http://www.site.com/products?page=3

    Only the first page has no parameter but pages after it have parameters. Is this use fine?

  • http://ninebyblue.com/ Vanessa Fox

    Eric,

    I talked to Google about this and they said they paginate before they process canonicals. I asked specifically about your scenario, thinking it would make sense to canonicalize, then paginate from a processing perspective. But they told me their backend system doesn’t work that way. So in the case you describe, the &referrer=twitter page wouldn’t be consolidated into the paginated entity.

  • Jerome

    Kenichi > I have exactly the same question !

    What do we do for the first page, that can be accessed either with ?page=1 or with no parameter ?

    On page 2, should we put rel=prev on http://www.site.com/products?page=1, or on http://www.site.com/products ?

    Should page 1 be canonicalized to http://www.site.com/products?page=1, or http://www.site.com/products ?

    Buzbez

  • http://eric eric

    A little late, but hopefully someone will answer my question. My website already has rel=”prev” and rel=”next” added automatically to paginated pages though Yoasts SEO plugin. However, since these pages are not set to noindex they are clogging up the search results with duplicate title tags and creating duplicate title warnings inside google webmaster tools.

    I was under the impression when Google first introduced rel=”prev” and rel=”next” a few months ago, they would follow a similar principle to using a canonical tag and therefore paginated results shouldn’t appear within Google’s search results.

    Am I wrong?

  • http://ninebyblue.com/ Vanessa Fox

    Eric,

    Do you have examples of these search results? You’ll likely see the duplicate titles message in webmaster tools (since they are technically duplicate titles) but you should only see one page from the set (nearly always page 1 unless another page is significantly more relevant) in search results.

    The exception should be if you’re doing a site: or inurl: search. All the pages in the set will likely show up with those, since they are all in the index.

    Kenichi, Jerome -

    In this case, /products is fine because that page will point to page=2 and page2 will point to /products.

  • Pet Assure

    Great and thorough article! One question. You write:
    “A page can’t contain multiple rel=”next” attributes.”

    I am assuming that only means multiple rel=”next” to two separate links, but 2 links to the same page (When on page 2, the number 3 AND Next button will both have rel=”next”) is ok, correct?

  • http://twitter.com/djfriedmann daniel friedmann

    Hi, I’ve been using pagination to bundle UGC in a Q&A forum where users have used the same title for their questions – in order to avoid keyword cannibalization.
    To illustrate, 10 users have posted a question called “How do I do improve SEO”
    which are linked as
    site.com/HowdoIimproveSEO-1.html
    site.com/HowdoIimproveSEO-2.htmlsite.com/HowdoIimproveSEO-3.html….Of course, each questions is somewhat different and so are the answers.Do you think this is an appropriate use for pagination (prev and next)?
    Or would you suggest a different tactic (moderation / curation, noindex on older questions, ?)

Get Our News, Everywhere!

Daily Email:

Follow Search Engine Land on Twitter @sengineland Like Search Engine Land on Facebook Follow Search Engine Land on Google+ Get the Search Engine Land Feed Connect with Search Engine Land on LinkedIn Check out our Tumblr! See us on Pinterest

 
 

Click to watch SMX conference video

Join us at one of our SMX or MarTech events:

United States

Europe

Australia & China

Learn more about: SMX | MarTech


Free Daily Search News Recap!

SearchCap is a once-per-day newsletter update - sign up below and get the news delivered to you!

 


 

Search Engine Land Periodic Table of SEO Success Factors

Get Your Copy
Read The Full SEO Guide