A topic sure to make any
SEO neophyte’s head spin, approaching and handling pagination can seem a daunting prospect at first. Pagination is a wily shapeshifter, rearing its ugly head in contexts ranging from e-commerce, to newspapers, to forums. Bottom line is, if you’re in the business of on-page optimization, it’s not a question of if you’ll have to deal with pagination problems – it’s a question of when. Luckily, we’re here to give you some advice to get you started, and answer some of the more thought-provoking questions that can arise in tricky situations.
So what exactly is pagination, you ask? In a very basic sense, pagination occurs when a website segments content over the span of multiple pages. On an e-commerce site, this will take the form of product and category listings. On a news site, articles may be divided up across multiple pages or arranged in the form of a slideshow. On forums, groups and topic threads will typically span at least 2-3 pages. Even blogs, which tend to feature article previews ordered from latest to oldest, will run into pagination issues on their homepage.
“Big deal”, you may say. “I see this happening all over the place, so what is the problem with paginated content?” From an
SEO perspective, pagination can cause serious issues with Google’s ability to index your site’s content. Let’s explore a few of the potential issues that arise when you paginate your content without taking the proper precautions:
- Crawler Limitations
When Googlebot is crawling your site, the depth (or levels of clicks deeper into the content) it travels will vary depending on the site’s authority and other factors. If you have a tremendous amount of paginated content, the odds that Googlebot will travel through all paginated content to reach and index the final pages decreases significantly.
- Duplicate Problems
Depending on the context of the pagination, it is very likely that some elements across the series of pages may contain similar or identical content. In addition to this, you’ll often find that identical title tags and meta descriptions tend to propagate across a span of paginated content. Duplicate content can cause massive confusion for Googlebot when it comes time to determine which pages to return for search queries.
- Thin Content
In situations (such as the aforementioned news sites) where articles or product reviews tend to be segmented into multiple pages, you run the risk of not providing enough original content for the individual pages to be indexed separately. More importantly, this also creates the risk of running too low on content-to-advertisement ratios, which can set your site up for devastating Panda penalties further down the road.
So how do you deal with Pagination?
Your best option is always optimal site design. There are a number of ways that these problems can be prevented before they begin. When planning the design of an ecommerce or similar site, consider the following measures you can take to cut down on large-scale pagination issues:
- Increasing the number of categories, which will decrease the depth of each paginated series
- Increasing the number of products per page, which will decrease the number of total pages in the paginated series
- Linking to all pages within the now manageable paginated series from the first page, which will alleviate any crawl-depth and link authority flow problems
However, in many real world scenarios, the damage has already been done and a site structure overhaul is not an option. Luckily, Google has given us a variety of methods to better steer the crawlers through our deep crypts of paginated content. As an
SEO, you have three weapons in your arsenal to preemptively deal with any problems that may arise out of pagination:
Option 1: Remove your paginated content from the index
There are many situations where simply taking the paginated content off the table is the best solution. If there are no particular advantages to having this content indexed and searchable, then the easiest solution is to implement a <META NAME="ROBOTS" CONTENT="NOINDEX, FOLLOW"> tag within the <head> section of every page in the paginated series, excluding the first page. You’ll want to make sure to include the “FOLLOW” tag here if this is a listing series of any kind – this will ensure that page authority will travel into the individual destination pages throughout the list, despite the list itself being precluded from Google’s index. Including the “FOLLOW” tag may also help some link authority that is arriving at pages within the paginated series to travel back to the indexed first page and the rest of the site.
| Advantages | Disadvantages |
|---|
| The least complex of all solutions. | While it does solve potential pagination problems, it also eliminates the paginated content from Google’s index. |
| Great for situations in which there is no logical reason to index the paginated content. |
|
Option 2: View-All Page and rel=“canonical”
Google’s preferred first choice for handling most pagination issues is to create a separate “
View-All” page apart from the paginated series and include all of the items within this single page. Once you’ve created the View-All page, you can then place a
rel="canonical" tag within the
<head> section of each paginated component page, pointing to the View-All Page. (e.g.
<link rel="canonical" href="http://www.site.com/view-all-page"/>). This will essentially tell Google to treat each specific page in a paginated series as a segment of the View-All page and queries will return the View-All page as opposed to a relevant segment page of the pagination chain.
Google states that this is their preferred method of guiding Googlebot through paginated content, and that users typically prefer a view-all page. Whether users actually prefer a view-all page is debatable and certainly depends on the context of each situation. There is one large caveat to this method – the View-All page has to be manageable enough to load within a “reasonable amount of time”, which is generally regarded as 2-4 seconds. This makes it a great option for consolidating text-only product and category listings that exist within 5-20 pages of paginated content. Conversely, it makes this a poor choice for consolidating paginated articles with many images and product or category listings with hundreds of pages.
| Advantages | Disadvantages |
|---|
| Relatively simple implementation | Not a solution for massive or image heavy series of paginated content |
| Google’s first choice solution | Some businesses may be unwilling or unable to implement a View-All page for product listings |
| All content within the pagination sequence will be represented on the search engine via the View-All page |
|
| Can present a more user-friendly navigation method. |
|
Option 3: Rel=“prev”/“next”
Our final option for dealing with pagination problems may be the most complicated, but it is arguably the most versatile. Google now recognizes the
rel=“prev” and “next” HTML attributes as a method of indicating a sequence of paginated pages. The implementation can be tricky, and you have to be exceptionally careful when applying this method. Let’s take a look at how this works.
You have four pages of paginated content:
By using
rel="prev"/"next", you’re essentially creating a chain between all sites in the pagination series. You’ll begin the chain with Page 1, adding the following code to the
<head> section of the page’s
HTML:
(Page 1):
<link rel="next" href="http://www.site.com/page2.html">
That’s the only step we have to take for the beginning of the chain. Now we move on to Page 2. Consider that Page 2 is now in the middle of the chain, so we have to attach it both to the page before it, and to the next page in the sequence. Page 2 would have the following code in the <head>:
(Page 2):
<link rel="prev" href="http://www.site.com/page1.html">
<link rel="next" href="http://www.site.com/page3.html">
Now just as you might have assumed, since Page 3 is also in the center of this sequence of linked pages, we have to continue to implement the code in a similar manner:
(Page 3):
<link rel="prev" href="http://www.site.com/page2.html">
<link rel="next" href="http://www.site.com/page4.html">
And so we’ve reached Page 4, the last in our chain of paginated content. The last page should only contain a rel="prev" attribute in the <head>, as there are no further pages within the sequence:
(Page 4):
<link rel="prev" href=" http://www.site.com/page3.html">
Using this complete sequence of rel="prev"/"next", Google is able to consolidate this group of paginated content into a single entry in their index. This essentially tells Google to treat the sequence of paginated content as one entry within their index. Typically, the first page will be returned to the user as it is usually the most relevant to a query regarding the paginated series. However, Google has noted there as scenarios where a more relevant page within the sequence is returned if the query is particularly centered around the content on that page.
| Advantages | Disadvantages |
|---|
| Unparalleled flexibility | Implementation can be complicated |
| Allows resolving pagination issues without use of a View-All page | Requires proper execution of the chain in order to be effective |
| Can be executed properly with only minor changes to HTML |
|
An important thing to note with rel=”prev”/”next” implementations is that they can be used alongside canonical tags. While this will become particularly useful in the advanced concepts section, it is worth noting that if you’re in the practice of using self-referential canonical tags, they will function the same way within a rel=”prev”/”next” chain.
Advanced Pagination Concepts
Now that we’ve tackled the basics, its time to take a look at some of the more interesting questions and scenarios you’ll run into once you start getting comfortable with pagination.
Setting a Benchmark
If you have access to your server logs, it’s fairly simple to determine the success with which Googlebot is currently crawling your unadjusted paginated content. Before any changes are implemented, we recommend choosing a few paginated series within your site and determining how many pages deep into the series Googlebot is crawling. Once you’ve determined this you can then perform search queries to investigate how many of these pages Google is choosing to include in the index.
This will give you a starting point benchmark that will enable you to determine the success of your efforts. After you have implemented your changes, you can revisit the server logs upon Googlebot’s return to determine whether crawl-depth and indexation rates have improved.
AJAX and Javascript scroll setups
You’ve likely ran into infinite scroll setups on ecommerce sites in which the content will continuously load as you scroll towards the bottom of the screen. While this is a nice feature to improve the user experience, AJAX and Javascript reliant navigation functions should always be implemented using Progressive Enhancement.
Ensuring that the site will function properly for users that have Javascript disabled is not only considerate to your users, but it also allows you to implement the pagination solutions discussed in this guide beneath the enhanced user experience features. This will enable Googlebot to properly crawl and index your content while you provide advanced Javascript navigation features for your visitors.
Relevancy Signals: View-All Pages vs. rel=“prev”/“next”
You may find yourself in the fortunate position to be able to choose whether to implement a View-All page orrel="prev"/"next". Although we do have indicators from Google suggesting that View-All is the preferred method for handling these pagination issues, there are certain contexts in which a rel="prev"/"next"implementation could prove more beneficial, as far as relevancy signals are concerned.
Consider for a moment that Google has stated that both View-All Page canonicalization andrel="prev"/"next" sequences consolidate all incoming link authority into the pages that ultimately will rank for queries related to them. The View-All page will naturally consolidate this link authority via the canonical tags pointed towards it and the ranking page in the sequence of rel="prev"/"next" will inherit the link authority via the properties Google uses to link the component pages together in the index.
Now that we’ve established link authority will be similar in both methods, we’re left with one very interesting question: What about the other relevancy signals that affect the page’s ability to rank? What happens to the unique URLs, the title tags, the meta descriptions, the H1/H2s and other factors? We know that the canonicalization that occurs when using the View-All method will effectively register these factors moot – Google knows to look to the canonical page for these items.
But if a series of pages linked together via rel="prev"/"next" contain unique title tags and URLs, and any one of these pages has the opportunity to rank for a query based on them, then they could potentially retain these relevancy signals as opposed to having them washed away via canonicalization.
Clearly, this is not a consideration for a simple paginated product or category listing with similar content across the series of pages. There is no unique relevancy factor to be found with “page1.htm” vs. “page2.htm”, and no ranking advantages to “Dresses Page 1” as opposed to “Dresses Page 2”. But what about a situation like the one below?
The truth is, no one really knows exactly how Google treats the
rel="prev"/"next" sequence within the index. However if we do know that in at least some cases, pages further into the sequence than the first page will be returned in the
SERPS, it’s safe to assume that the
URL, title tag, and other factors will still play some role in determining relevancy to any given query.
Parameters and rel=“prev”/“next”
In some cases when dealing with
rel="prev"/"next", your paginated
URLS will contain parameters that do not change the content of the page, such as unique session ID’s. An experienced
SEO will tell you these are bad news – if you don’t give Google specific instructions on how to deal with these situations you may wind up with duplicate content problems.
You always have the option of just telling Googlebot to not crawl certain
URLS using “
URL Parameters” in Webmaster Tools, but what if you’d like to preserve link authority that is coming in to these parameterized
URLS? We can make that happen, using
rel="prev"/"next" in conjunction with canonical tags.
First, you have to make sure that all pages within a paginated
rel="prev"/"next" sequence are using the same parameter. Second, each parameterized
URL can also canonicalize to the non-parameterized version of the
URL. For example, we’ve got the same 4 pages of paginated content, but this time the user is being tracked via session ID 55:
Filtered Content and rel=“prev”/“next”
Now let’s say you’re working with parameters that filter the content within a paginated series. For example, say we’ve got a parameter on a paginated set of product listing
URLS that filter via brand, such as:
Page 1: http://www.site.com/page1.html?brand=nike
In this situation, the content on each page will depend on this variable. For example:
Page 1: http://www.site.com/page1.html?brand=adidas
Page 2: http://www.site.com/page2.html?brand=adidas
Will be returning a completely different set of products than:
Page 1: http://www.site.com/page1.html?brand=reebok
Page 2: http://www.site.com/page2.html?brand=reebok
If you believe there is value in having each filtered product type in Google’s index, your best plan of action is to create separate paginated sequences for each brand filter. You won’t be using canonical tags in this situation, since the content will be unique depending on the parameter. Here’s an example of how to handle this scenario:
Sorted Content and rel=“prev”/“next”
The last type of parameterized
URL type we’re going to look at is sorted content. You’re more likely to find this type of parameter in a forum or blog type setting, though it will exist frequently on ecommerce sites as well. For example:
When you first arrive at the page, the
URL might read:
Page 1: http://www.news-site.com/page1.html?order=oldest
But there may be an option to view the newest items first, resulting in this URL:
Page 1: http://www.news-site.com/page1.html?order=newest
There’s currently a fair amount of debate in the
SEO community as to how to treat this type of situation. Though some would suggest attempting a separate rel=”prev”/”next” sequence for both “newest” and “oldest” sort method
URLS, in our opinion this would essentially be indicating to Google that you would like them to index multiple paginated sequences of identical content. The only difference between these two paginated groups would be that the content is displayed in a different order, still putting you in dangerous territory for duplicate content.
Ayima recommends taking the safe route on this, and presenting only one sorted paginated sequence to Google for indexing. The default sort method should carry a rel="prev"/"next" pagination method:
The alternate sorting method, in this case newest, should be blocked from indexation. This is most quickly accomplished using
URL Parameters in Webmaster Tools, specifying the parameter and allowing Googlebot to crawl only the default value.
These solutions may seem complicated at first, but they are easily manageable if you address each instance of pagination separately and apply the proper rule for each scenario. It may be helpful to consult this flow chart provided in order to simplify the decision making process:
We’ve seen many situations in which rel="prev"/"next" are implemented incorrectly, so be sure to double-check your chains upon completion. Dealing with these problems can be painful, but with careful planning and thorough implementation you’ll be successfully guiding Google through your site before pagination has a chance to ruin your day.
