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:
http://www.example.com/item?story=abc&price=up&page=1
rather than:
http://www.example.com/story=abc/price=up/page=1
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:
http://googlewebmastercentral.blogspot.com/2008/09/dynamic-urls-vs-static-urls.html
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 "http://www.example.com/story=abc/price=up/page=1/".
Canonical URL of 2nd page is "http://www.example.com/story=abc/price=up/page=2/". ]
This means that URL B, http://www.example.com/story=abc/price=down/page=1/, could also have:
Canonical URL of 1st page is http://www.example.com/story=abc/price=down/page=1/
Canonical URL of 2nd page ishttp://www.example.com/story=abc/price=down/page=2/
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).
|
|