Google Product Forums

Re: Questions about pagination, rel="next" and rel="prev", or view-all in search results?

Maile Ohye Oct 18, 2011 9:29 PM
Posted in group: Webmaster Central Help Forum

Categories: Crawling, indexing & ranking :

Thanks for even more questions!

@everyone: rel=”next” and rel=”prev” can be still used when there are a large number of component pages in the series. It’s unnecessary to fear that “this article is too large” or “this category is too large” for rel=”next” and rel=”prev” markup. If anything, more content with accurate markup means more helpful signals to properly index your information. And proper indexing means we’ll likely return more relevant results to users and more targeted traffic to your site.

@kb0000: If your paginated content remains on the same URL, you won’t need to use rel=”next” and rel=”prev” markup. However, if you’re using AJAX, you might want to get an idea of whether search engines can crawl and index your content displayed through JavaScript. Perhaps check the cached version of a page in search results or turn off JavaScript and CSS and see what content remains. Playing it safe, you can assume that the remaining content is what most less-capable browsers and bots will also be able to understand.

@kb0000, @abrahamcovelo, @Jarrod1937: With regard to extending this feature within the <body> section of a page, we completely understand your request, however, we’re concerned that links in the <body> section make it possible for spammers to find less secure user-generated content (UGC) sites and then inject irrelevant links totally unbeknownst to the webmaster.

@Jarrod1937: Thanks for your feedback. It’s probably helpful to think of prioritizing pagination markup relative to the other improvements you might make on your site (e.g., performance, adding more content, or creating unique titles from duplicates). There are costs and tradeoffs with most features, but you seem in a great position to understand your users’ needs.

@Emanuele: In regard to using rel=”next” and rel=”prev” for entries in your blog that “are not strictly correlated (but they are just time-sequential),” pagination markup likely isn’t the best use of your time -- time-sequential pages aren’t nearly as helpful to our indexing process as semantically related content, such as pagination on component pages in an article or category. It’s fine if you include the markup on your time-sequential pages, but please note that it’s not the most helpful use case.

@kgraves: In the case of an e-commerce site with paginated content that also has some duplicate text within each component page, rel=”next” and rel=”prev” would still be the better choice over rel=”canonical.”

@Spyderweb: It sounds like your real estate rental site encounters many of the same issues that e-commerce sites face. First of all, your idea of a “view-all sequence of pages” isn’t the same as our definition of view-all page, where we mean that users can see the entire contents of the page by only navigating locally. Here are some ideas on your situation:

1. It’s great that you are using the Webmaster Tools URL parameters feature to more efficiently crawl your site.

2. It’s possible that your site can form a rel=”next” and rel=”prev” sequence with no parameters (or with default parameter values). It’s also possible to form parallel pagination sequences when users select certain parameters, such as a sequence of pages where there are 15 records and a separate sequence when a user selects 30 records. Paginating component pages, even with parameters, helps us more accurately index your content.

3. While it’s fine to set rel=”canonical” from a component URL to a single view-all page, setting the canonical to the first page of a parameter-less sequence is considered improper usage. We make no promises to honor this implementation of rel=”canonical.”

@wotaewer: It’s fine to use rel=”next” and rel=”prev” on a series of search result pages, or even on a series of content that’s auto-generated. Perhaps the larger question is whether these pages provide value to the user. Most often, Google users dislike performing a search, then clicking on a result only to be taken to a site with more search results. We recommend making sure that pages on your site, especially the search result pages, provide unique value. For pages with very little or no value, until you’re able to add good content, using noindex is a viable option.

@cristina: Detection of rel=”next”/rel=”prev” and/or a view-all page is already implemented by our Indexing team, and the effects are live in search results. However, there’s no change to the user interface in search results (i.e., there isn’t a new visual display) that indicates this indexing capability.

@katty22: One thing I’d like to mention is that for interchangeable/filterable options, it’s more search engine friendly to keep the options as parameters, not as subdirectories. For example, we’d prefer this URL:
rather than:

URL parameters with standard encoding helps us both crawl your site more efficiently (especially with proper setttings in Webmaster Tools’ URL parameters), as well as better understand your content from an indexing standpoint. This is further explained in our blog post:

Back to your question, you proposed the configuration:

->Main URL is "A". "B"to"D" are not necessarily need to be appeared in search result. ]

Of your options, we would advocate for your second choice of self-referential canonicals:
[ 2. Put next/previous tag in all pages, and put canonical tag in "A" to "D" from 1st page to n.
Canonical URL of 1st page is "".
Canonical URL of 2nd page is "". ]

This means that URL B,, could also have:
Canonical URL of 1st page is
Canonical URL of 2nd page is

Because URLs A, B, C, D will likely contain different items according to how they’re sorted, it’s likely you’ll be unable to rel=”canonical” from B to A, or C to A, or D to A (even though A is your “main” URL).

@estrik: We support rel=”next” and rel=”prev” in the HTTP header. For example, for page=2 of an article, you could respond with the HTTP header:

Link: <>; rel="prev"
Link: <>; rel="next"

@competitions: Yes, it’s absolutely fine to have:
<link rel="prev" href="" />
<link rel="next" href="" />
rather than:
<link rel="prev" href="" />
<link rel="next" href="" />

@TiggerFish: We really appreciate your effort to help the webmaster community. Such an effort is part of what makes working in Search so rewarding. :) In regard to Wordpress’ current non-standard use of rel=”next” and rel=”prev,” we’re very aware of the Wordpress issue (thanks also to the heads-up from fellow webmasters like Joost de Valk). Our indexing team already implemented heuristics to test/verify webmaster-provided rel=”next” and rel=”prev” pagination annotations, and we’re confident that with these heuristics were not erroneously detecting subsequent Wordpress blog entries as a series. Thanks again!