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
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.
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
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
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
1. It’s great that you are using the Webmaster Tools URL parameters feature to more efficiently crawl your site.
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.
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.”
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.
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).
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:
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!