This article is part of an SEO series from WooRank. Thank you for supporting the partners who make SitePoint possible.
If you’ve got a large site, or even a smaller site that has some pages with longform content, you’ve probably had to deal with pagination at some point. There are several reasons you’d want to paginate your content: You’ve got a series of related articles, a page with lots of search results, your ecommerce site has a large list of products in a category or you’ve got a discussion forum housing several comment threads. In this article we’ll go over some best practices for implementing pagination for SEO, some common problems that arise from pagination and how to resolve those problems.
Pagination Best Practices
When to Paginate
Human usability is the main reason you would want to paginate your content. When you get beyond a few pages worth of links, it starts to get daunting for users. Plus, these pages can take a long time to load, which is a big no-no for both user experience and SEO. The other main reason to paginate content is to limit the number links on one page. It’s generally considered best practice to keep the number of links on a page to 100 or fewer (even though Google dropped this guideline a few years ago), although that’s far from a hard limit. Some reasons to keep the number of outbound links below that number include:
- Having a large number of links on a page affects robots’ crawl efficiency, and could result in having more valuable pages passed over in favor of less important pages. You can guard against this using sitemaps, but those aren’t ironclad.
- Link juice is divided evenly among all the links on a page. So the more links you have, the less each one passes. Since you can’t use “nofollow” links anymore to direct link juice, limit the number of links on a page to maximize the value each one passes.
- Pages with lots of links generally have pretty thin content and aren’t the most legitimate-looking pages on the web. That doesn’t mean your pages are spam, or that search engines will automatically come to that conclusion, but paginating long lists of links will help show that your page is legitimate.
View More/Less Results & View All Page
You can also avoid the whole pagination duplicate content altogether by using the “noindex” meta robot tag and a View All page. Add the noindex tag to your paginated pages’
<head> like this:
<meta name="robots” content=”noindex”/>
Then, add the robots meta tag to your view all page, with “index” as the content value. This technically isn’t necessary as it’s the default unless otherwise indicated, but giving crawlers a push in the right direction doesn’t hurt. Test and submit your sitemap via Google Search Console’s sitemap tool.
Use HTML5’s History API to change the URL as new pages are loaded. So when a user reaches the bottom of page two, the page two URL would switch to the page three URL when that content has loaded. The same is true for the opposite: Scrolling up to load page two content will switch the URL back.
Using infinite scroll is a popular way of dealing with content, particularly for long articles and social media pages. It’s also really useful for mobile pages and very user friendly, but it’s not so friendly for search engines. However, there are some ways you can offset that unfriendliness so you can use infinite scroll without hurting your SEO too much.
If your paginated content uses separate URLs, include them in your sitemap. This will ensure that search engines find, crawl and index your content, including the pages loaded via infinite crawl that they otherwise couldn’t access.
Use rel=”prev”/”next” to Avoid Duplicate Title Tags & Meta Descriptions
When properly implemented, pagination generally doesn’t result in duplicate page content (unless you’ve decided to use view more/less and/or view all features). However, it can cause problems with two very important SEO factors: title tags and meta descriptions. Use Google Search Console to find instances of duplicate title tags. Find all your duplicate title tags and meta descriptions in the HTML Improvements section under Search Appearance.
The rel=”prev”/”next” tags are implemented in the
</head><head> of the page, and are used to indicate the preceding and succeeding pages in the pagination chain. So, for example, the second page in the chain, example.com/page2, would have the tags implemented like this:
<link rel="prev” href=”www.example.com/page1”/> <link rel="next” href=”www.example.com/page3”/>
These tags will tell search engines that the pages at the indicated URLs are all linked together, so they won’t see their shared title tags and meta descriptions as duplicates. They’ll also consolidate their indexing properties like link juice, and possibly send visitors from search engines to the first page in the series.
If your paginated series uses URL parameters, for example sorting or filtering, you can also use the canonical tag like so:
<link rel="canonical” href=”www.example.com/page2”/> <link rel="prev” href=”www.example.com/page1”/> <link rel="next” href=”www.example.com/page3/>
Common Problems With Pagination
If you’re using rel=”prev”/”next” annotations, implementing pagination is pretty straightforward. However, you can still take a few wrong turns that will impact how search engines crawl and access your content.
Paginated content must maintain an unbroken chain from the first page to the last. That means the “prev” link for the second page must point to the first page, and the “next” link must point to page three. If they don’t, the chain is broken and search engines won’t be able to tell that the rest of the chain is connected to the first part. Each page can only be part of one chain at a time, so you can only have one “prev” and one “next” link per page.
One sneaky way chains are broken is through URL parameters. You can only link URLs with matching parameters. So say you’re using example.com/page3?referrer=facebook in this chain:
<rel ="prev” href=”example.com/page2”> </rel><rel ="net” href=”example.com/page4”>
Using the ?referrer= parameter will break the pagination, so search engines will not be able to link any of the pages after page two. This gets really tricky when you’ve got lists that have lots of sorting and filtering options, like ecommerce listings and online shopping systems. Since URL parameters can break pagination, you need to create a pagination chain for each filter and/or sort option if you want them to run separately, like if you want unique color-filtered lists to rank independently for “green dresses” and “yellow dresses.”
To resolve this, dynamically insert the prev and next links dynamically based on fetched URLs.
Incorrect rel=”canonical” Implementation
People often try to use the rel=”canonical” tag in paginated content to point all incoming link juice to page one. However, when you use the rel=”prev”/”next” tags, this is unnecessary, so what ends up happening is that search engines think all the pages in the chain are just copies of the first page. This means they won’t bother crawling and indexing them, so they’ll miss all of their content and links.
Pagination may seem like such a mundane, minor thing that some people will implement it on their site and not think too much more about it. However, it really is worth extra consideration because it has such a big impact on your site’s usability, and doing it wrong can cause a real issue for your SEO. The good news is that if you do it right, by using the rel=”prev”/”next” and canonical tags, you’ll provide your users with an enhanced experience and protect your site from the duplicate content issues that can potentially come with pagination.