Indicating paginated content to Google

If you break a single piece of content into multiple pages, you can help Google understand the ordering of those pages, and the fact that they are all parts of one longer article.

 

Sites paginate content for various reasons. For example:

  • News and/or publishing sites often divide a long article into several shorter pages.
  • Retail sites may divide the list of items in a large product category into multiple pages.
  • Discussion forums often break threads into sequential URLs.

If you paginate content on your site, and you want that content to appear in search results, we recommend one of the following three options.

  • Do nothing. Paginated content is very common, and Google does a good job returning the most relevant results to users, regardless of whether content is divided into multiple pages.
  • Implement a View All page. Searchers commonly prefer to view a whole article or category on a single page. Therefore, if we think this is what the searcher is looking for, we try to show the View All page in search results. You can also add a rel="canonical" link to the component pages to tell Google that the View All version is the version you want to appear in search results.
  • Use rel="next" and rel="prev" links or headers to indicate the relationship between component URLs. This markup provides a strong hint to Google that you would like us to treat these pages as a logical sequence, thus consolidating their linking properties and usually sending searchers to the first page.
Note: You should not use this technique merely to indicate a reading list of an article series; you should use this to indicate a single long piece of content that is broken into multiple pages.

Using rel="next" and rel="prev"

You can use either HTML links or HTTP headers to indicate the next or previous article segment when a long article is broken into separate pages.

  1. Decide whether to use HTTP headers or HTML <link> tags
  2. The first page should include only a "next" pointer, pointing to the next article segment.
  3. The last page should include only a "prev" pointer, pointing to the preceding article segment.
  4. All intermediary pages should get both "next" and "prev" pointers to the immediate next and preceding article segments.

Example:

Here is a 3-page article that uses HTML links in the <head> tag:

cats_part_1 cats_part_2 cats_part_3
<link rel="next" href="cats_part_2> <link rel="next" href="cats_part_3>
<link rel="prev" href="cats_part_1>
<link rel="prev" href="cats_part_2>

Syntax

You can indicate next/previous pointers using either HTTP headers or HTML <link> tags.

HTTP headers:

Return one or both of the following HTTP headers in your page response.

  • Link: <www.example.com/cats_part_3; rel="next"> for the next article segment.
  • Link: <www.example.com/cats_part_1; rel="prev"> for the previous article segment.

HTML <link> tags:

Put the appropriate <link> tags inside the page <head> element.

  • <link rel="next" href="next_page_URL"> for the next article segment.
  • <link rel="prev" href="previous_page_url"> for the previous article segment.

Notes

  • rel="prev" and rel="next" act as hints to Google, not absolute directives.
  • Google accepts both rel="prev" and rel="previous"
  • If a page includes parameters that don't change the page's content, such as session IDs, then the URLs specified in next and previous links should also contain those parameters.
  • rel="next" and rel="prev" are compatible with rel="canonical" values. You can include both declarations in the same page. For example, a page can contain both of the following HTML tags:
    <link rel="canonical" href="http://www.example.com/article"/>
    <link rel="next" href="http://www.example.com/article-part2" />
    
  • If Google finds mistakes in your implementation (for example, if an expected rel="prev" or rel="next" designation is missing), we'll continue to index the page(s), and rely on our own heuristics to understand your content.
  • URLs can be either absolute or relative. If you include a <base> link in your document, relative paths will resolve according to the base URL.
Was this article helpful?
How can we improve it?