MAILE OHYE: Hi.
I'm Maile Ohye.
I've been at Google now for over six years, working with
Search and with Webmaster Tools.
I'd like to welcome you to my home.
Let's chat about pagination and SEO.
For today's agenda, we'll first start with some
paginated content examples.
Then we'll get into some of the negative side effects of
pagination and why you as a webmaster might want to make
some effort as to not dilute your indexing properties and
to show better results to users.
Then we'll cover your configuration.
And this comes in two parts--
for those of you webmasters with paginated content and a
view-all page available, and then for those of you
webmasters that have paginated content but
without a view-all page.
So there's going to be two types of configurations there.
Then we're going to step back a little bit and talk about
what Google is doing to help users with paginated content
and webmasters as well.
And then last, given your configuration, whether you
have a view-all page available or you have no view-all page
available, we'll look at the options that you have for your
paginated content.
So let's go ahead and start with some
paginated content examples.
Paginated content exists throughout the web, and I'm
going to cover two of those common cases.
One is a paginated article.
So let's say you go to your favorite content site, and you
see the breaking news story.
"New studies prove that cookies are superior nutrition
to vegetables." And that would be quite the story.
But your favorite site might not put this all on one page,
but instead, paginate it into several component pages.
Now this one article has become three, and this is an
example of paginated content articles.
Another example of pagination is for things like a product
category, like what you would see on your favorite
e-commerce site.
So let's say this webmaster is selling shapes.
They're selling six types of shapes.
But rather than have it all on one page, they have divided it
into two component pages, both of them with shapes, creating
pagination again.
So two common ways are with paginated content articles and
with paginated product categories.
Now, what are some of the negative side effects of this?
Well, there's a couple.
So I'd like to highlight two, the first being that indexing
properties, like links and anchor text, can be diluted
into the different component URLs rather than being
consolidated to the one article or to
the one product category.
So that's one of the negative side effects.
The other is that the most relevant page in the series
might not be reflected in search results.
So if you're the webmaster for this e-commerce site, you
might want users to be sent to page one, say, of your series.
But because search engines see this pagination as three
separate entities, searchers might be sent to a different
page that might not be the most relevant.
So those are a few of the negative side effects of
pagination.
Now let's talk more about your situation and the
configuration you have on your site.
We're going to look at this in terms of two different types
configurations.
One is with a view-all page available, and the other is
with no view-all page available.
Now, if your site has paginated content with a
view-all page available, there are a couple of things you
want to make sure you test for.
One is make sure that you have still decent latency on your
site meaning that, if a user clicks on the view-all
version, that it doesn't take them 15 seconds to load
because it's such a long article, or
it's so many products.
But that they still have a good experience--
say, the page only takes four seconds to load.
The second thing to check for if you have a view-all page
available is to make sure that the page remains easily
navigable, meaning that users can still find the content
that they want or the particular product that they
want by easily scrolling or viewing headings.
So that's the configuration of a view-all page available.
And then obviously, without a view-all page available, it's
fairly straightforward.
So think about your site in terms of configuration you
have. But before we go there, let's take a step back and
talk a little bit about what Google is doing.
We're, of course, always working to improve the
experience for searchers.
And one thing that we found through testing is that our
searchers prefer seeing the view-all page in their search
results opposed to an individual component page.
And one reason for this might be because of latency.
So if you take search results and you click on a result to a
view-all page, while that might take, say, three seconds
to load that article that new studies prove that cookies are
superior nutrition to vegetables, that might be
three seconds.
But on the other hand, searchers were less happy when
search results took them to just page one of the article.
While that might have just had two seconds of latency and
then the page loaded, every time that user wanted to click
Next to read more of the article, it caused some
additional load time.
So because of this latency and other reasons, searches prefer
the view-all page.
So given this knowledge, one of our engineers on indexing,
Benjia Li, actually came out with a new feature
in October of 2011.
This is--
"When we detect that a paginated series also contains
a view-all version, we're now making a larger effort to
return the view-all page in search results when
appropriate." So that's great for searchers.
And what's even better for webmasters is that while we
detect this view-all page, we'll also still consolidate
indexing properties, like links, to the view-all page.
So again, this is good for searchers and good for you as
webmasters for all that indexing consolidation.
Now, let's talk about some of the options that you have as a
webmaster with paginated content.
We're first going to look at the situation where webmasters
have paginated the content and a view-all page available.
But for those of you that have no view-all page available,
it's still good if you pay attention because some of
these options will apply to you as well.
So you have a site with paginated content and a
view-all page, you have three good options.
First, you can leave as is.
There's nothing that you have to do if you have other
priorities on your site.
Paginated content exists throughout the web, and search
engines will continue to do an even better
job of handling it.
And as I mentioned earlier, if you have a view-all page
available, Google will automatically try to detect
that, send searchers there, as well as consolidate your
indexing properties.
So option one is a very solid option.
But you also have a second option.
The second option is to actually use rel="canonical"
to explicitly hint to Google what is your view-all page.
So while we try to detect it algorithmically, you can also
tell us by writing rel="canonical" on your
component pages to your view-all version.
And this is kind of a more explicit hint to us about how
your site is configured.
With the rel="canonical," as many of you already know,
we'll of course consolidate the indexing properties from
the component pages with the canonical version.
So things like links will also be transferred.
And then, of course, we'll send users to
the view-all page.
So that's option number two.
The last option is actually done by two of our engineers,
Joachim and Benjia.
And what this is is using the standard HTML markup of
rel="next" and rel="prev" on the component pages in your
series to signal to Google that these are individual
pages, but they all belong to one series.
So by adding this rel="next" and rel="prev" markup, you
connect these individual components into one.
You can do this by adding rel="next" to page one and
then rel="prev" and rel="next" to page two, all the way to
the last page, which only includes a rel="prev".
And then, of course, on your view-all
page, nothing is needed.
rel="next" and rel="prev" is standard HTML markup, and it's
been around for years.
But now, Google is using this markup for webmasters to let
us know about their paginated content.
So let me explain some ways that rel="next"
and rel="prev" work.
With rel="next" and rel="prev," much like you see
with something like rel="canonical," we'll
actually consolidate indexing properties from the component
pages of the series.
And in addition, unlike rel="canonical" that only
shows the view-all page in search results, with
rel="next" and rel="prev," we're going to override that
behavior and send users to only one of
the component pages.
Most likely, this will be page one, because commonly that's
the most relevant page.
So now if you have, say, that product category, selling
shapes, if you use the rel="next" and rel="prev"
markup, it'll tell us that these two pages
belong to one series.
And then most commonly, we'll send users to page one.
Know that rel="next" and rel="prev" is a strong hint.
It's not a mandate by any means.
The last thing I want to say about rel="next" and
rel="prev" is that component URLs in a series should be
consistent with their parameters.
So let's take the article of new studies prove that cookies
are superior nutrition to vegetables.
Now, let's say that these pages contain a session ID.
All of these values for rel="prev" and rel="next"
should also contain the session ID.
And this is because our indexing team looks to
actually link every page in a series with what was declared
previous and what was declared next.
And when they do that, they want to make sure-- say you're
on page two--
that the rel="prev" that states rel="prev" is
page-1&sid=123, they will go to that URL.
But that URL actually has to list page two
with the same sid.
And that's how we can link every page in the sequence.
So be sure to keep parameters throughout your entire series.
So let's recap those three options.
If you have a view-all page available, you
can leave as is.
You could also explicitly state rel="canonical" to your
view-all page.
Or you can override the view-all page behavior by
adding rel="next" and rel="prev." By adding
rel="next" and rel="prev," you will help us consolidate
component pages in a series.
But instead of sending users to a view-all page, we'll then
send searchers to one component page., most likely
page one of your series.
Now, let's talk about the configuration with no view-all
page available.
So for those of you webmasters that have paginated content
and no view-all page, you have two options.
First, of course, you can leave as is.
That's perfectly fine.
And then your second option is also to use rel="next" and
rel="prev." Again, by using rel="next" and rel="prev," it
connects the component pages in the series, and
consolidates indexing properties, and helps us to
send searchers to the most relevant page, which is likely
the first page of the series.
Now I'm going to beat you to the punch and ask one of the
most commonly asked questions about rel="canonical" as well
as rel="next," "prev." And that is why rel="next" and
rel="prev" for a paginated series rather than
rel="canonical" to page one?
Ha!
I bet you were thinking that.
The answer is that rel="canonical" is for
duplicate content.
So let's take that article.
Let's say page two of the article, cookies
are superior nutrition.
If this page actually has a session ID attached, then it
can list as the canonical the same version, the duplicate
conversion, but without a session ID Because
rel="canonical" is for duplicate content, or it's for
content which is a superset.
So here we have page one, page two, and page three, all
linking to the canonical version being
the view-all version.
And that's perfectly fine as well.
The thing about rel="canonical" is that it
only indexes content from the canonical version.
So let's go ahead and take a look at this.
If we have page two and page three, page two says "cookies
are superior nutrition," and page three says "to
vegetables".
But they both add rel="canonical"
just to page one.
And Google's index will then cluster page one, page two,
and page three all together.
But the only thing that we'll have indexed is the content
from page one, the canonical version.
So our index will actually contain "new studies prove
that."
And now by using this rel="canonical" incorrectly,
this webmaster has totally lost the content "cookies are
superior nutrition" and "to vegetables." So that's why
rel="canonical" doesn't work in this case.
But rel="next," "prev" works for a series or
a sequence of content.
So let's take those two paginated examples again.
By using rel="next" and rel="prev," we'll actually, in
Google's index, mark it as a series.
But we'll have page one, page two, and page three all
indexed separately.
So in our index, we know page one refers to "new studies
prove that," page two, "cookies are superior
nutrition," and page three, "to vegetables." And all three
pages will be indexed and marked as one series.
So that's the big difference between rel="canonical" and
rel="next" "prev."
So something to note is that rel="canonical" can actually
be used alongside rel="next" "prev." So let's take a look
at page two again.
And this time, it has a session ID.
This URL can actually list both the canonical version
without a session ID as well as a rel="prev" and rel="next"
with, of course, the same parameters, including that
session ID.
So now let's recap your new pagination toolbox.
Starting with Google, we have two new features for you.
First, we're making a better effort to detect a view-all
page, and then send searchers to that
preferred view-all version.
The second feature is if you want to actually even override
that behavior.
So for those of you with a view-all page available or
without, if you add markup with rel="next" and
rel="prev," it signals to Google that these are
component pages in a series.
We'll then consolidate indexing properties, and send
searchers to the most relevant page, most likely page one.
Now, let's get into the types of
configurations you have available.
So recapping, if you have a view-all page available, you
have three options.
You can leave as is.
You can use rel="canonical" on your component pages, pointing
to your view-all page.
Or you can override all the view-all detection by adding
rel="next" and rel="prev," telling us that these
component pages belong to a series.
And I'd like you, Google, to send searchers to the most
relevant individual page, again, likely page one.
Now, the other part of the pagination toolbox is for
those of you with no view-all available, and
you have two options.
Of course, you can leave exactly as is.
Or again, you can use rel="next" and rel="prev."
This helps you to consolidate all the component pages into
one series and send searchers to the most relevant page.
So the great thing about these pagination features is that
I've been at Google long enough to see the infancy from
when the webmaster community was talking to us about issues
with pagination until now when we have more features
available to you.
So thank you so much to all of you for your helpful feedback
and for being part of this webmaster community.
For more information on pagination, here are some
links available.
And you can, of course, join us at the Webmaster Central
Blog or in the Webmaster Discussion Forum.
Thanks for your time.