Video: SEO Pagination By Google

Mar 13, 2012 • 8:14 am | comments (7) by twitter Google+ | Filed Under Google Search Engine Optimization
 

Maile Ohye GoogleBack in September of last year, Google came out with their solution for pagination issues in SEO and search - view all & rel="next" and rel="prev".

It is a pretty complex topic for non-technical SEOs but yet it can be super helpful for large sites with a lot of pagination.

Maile posted a recent video on the Webmaster YouTube channel explaining how this all works in clear English so almost anyone can understand it.

Here is the new video:

Here is the full transcript:

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

For more details, see these two posts.

Forum discussion at Google+.

Previous story: Daily Search Forum Recap: March 12, 2012
 

Comments:

Louis Rix

03/13/2012 01:30 pm

Ok  So lets say my site is all about cars and i have a "Used Audi" page with 1000 Audi's for sale. There are 10 used audi cars on each page so there's 100 pages in the series. If i start to utilise Rel="prev" and rel="next" should i set page 2 onwards as "index,follow" or "noindex,follow"? The content on Page 2 all the way to 100 only changes ever so slightly as different cars will be for sale on different pages but from a "Panda" point of view the pages are incredibly similar as they'd hold the same meta data as page 1 in the series along with duplicate reviews & news etc. I want Page 1 in the series as the "Main" page for Google to send users too and i don't see the point in Google indexing page 2 > 100.  What's everyone's view on this? Lastly with the rel="canonical" tag should page 2 to 100 all point back to page 1 in the series or the individual page itself? E.G: /used-audi/page-3/ Feedback would be massively appreciated.  Thank you.     

Jeremy Myers

03/13/2012 02:14 pm

I have the same exact questions as @twitter-232283244:disqus. I see the benefits of the main page, but it is going to create lots of duplicate content. What is the recommended way to avoid Panda penalties?

Jonathan Morales

03/13/2012 04:22 pm

I had a similar issue with my Vbulletin forum when I added VBSEO....I went alittle different and flipped the page # to be before the page title in the serps starting from the 2nd page on and it seems to really have turned around my forum threads (since most of the threads turn into multiple pages)   Anyone interested can search nj mustang gears, or something else related to nj mustangs, and you'll see how it's working....I'm actually getting extra links to the pages before it in the same serp!!! :)

Seo

03/15/2012 10:50 am

Great information there, I have always wondered the right way to go about this, thanks for showing me! Some of them points are really straight forward but all too often you will over look them in video.

Guest

01/27/2013 06:20 pm

If there is a view all version then what is the purpose of splitting the pages into multiple components and using prev and next?

Radiate

01/30/2013 05:39 pm

Some reasons are, load time. View-all might take a long time to load if you have tons of content. This can make users not want to wait for it to load. Also, content. If you have valuable content that you want indexed from all the pages, and keywords, then using prev and next might be the best option. I can see the value for seo, since you can have 2-3 target keywords for each page vs only 2-3 target keywords for the whole article or products page. If you have multiple products being sold on your website, the prev and next might be a better option. Anyways I still get your point, it is a good question.

Ash Trick

02/13/2014 04:38 pm

Can I add rel="next" using jquery / javascript ? As I have got different jsp files, 1 for head and 1 for body (body does the search and only then it knows if there are more pages). Can i add link tag to head using jquery and will Google pick that up?

blog comments powered by Disqus