Pagination issues can affect any website: from blogs with a few tag or category pages, to huge e-commerce sites with parameters and user options galore.
And if that’s not enough to leave you faint of heart, then you won’t want to know the possible side-effects of having unwieldy pagination. No, we can’t tell you. It’s just too terrifying. Oh, go on then…
- Duplicate content issues (from separate paginated and view-all versions of the same content).
- Ranking signals (such as backlinks) split between lots of paginated pages.
- Crawl depth too deep on very large categories: Google has to crawl through too many links to get to your pages.
Thankfully, Google is getting better at detecting paginated content and there are also two very good ways (and one not-so-good way) to manage pagination. The option you choose essentially comes down to the size of your site and usability.
Option 1: Canonicalize to a view-all version
If your paginated series has an alternative view-all version, Google will attempt to detect this and de-dupe your paginated pages in favur of your view-all page. However, they also suggest you canonicalize the set of paginated pages to a view-all page if one exists, as this is a more ‘explicit hint’ that your view-all page is the correct one to favur when indexing.
Arguably the easiest option to implement and possibly the most user-friendly option: Google says their research shows that searchers prefer to land on a view-all page. This option also addresses duplicate content issues that may arise from having the same content on two different pages. However…
View-all pages aren’t the best option for all page types. For example, category listing pages and search results pages don’t have a view-all version because they could be ridiculously large.
And even if you do have a view-all page, if it takes an age to load and is impossible to navigate, then it’s not the most user-friendly option after all.
What about ranking signals?
In their pagination guide, Google state that ranking signals (like backlinks) will be consolidated in favour of the view-all page, rather than being spread out among the paginated pages.
Watch out for:
Incorrect canonical tag URLs; mistakenly canonicalising paginated results to page one of the series (only canonicalise when there is a view-all alternative available).
Option 2: Indicate pagination with HTML markup
If you don’t have a view-all option, or you’d rather searchers landed on a paginated page instead, then using the standard rel=”next” and rel=”prev” markup is a better option. Since 2011, Google has used this markup to detect and index paginated content as a series of pages, rather than individual pages.
If you choose this method, Google will crawl and index as many of the paginated pages as possible. They will return the page they think most relevant for a search query, which will usually be page one.
Your paginated pages should have a canonical URL which includes the page number. For example, the paginated page ‘www.example.co.uk/shoes/4’ should have a canonical tag of ‘www.example.co.uk/shoes/4’
A common mistake is to include a canonical tag including the first page as the canonical URL, for example: ‘www.example.co.uk/shoes’. Before the introduction of pagination support, this method was used to consolidate all authority across the set of pages to the first page, but Google now advise against this method.
Better for sites where a view-all version is not available, or where your view-all page is too large to load quickly or navigate.
You might have less control over how your paginated content will be indexed or displayed: Google describe this method as a ‘strong hint, not a mandate’. The page you consider to be most relevant might not be treated as such, or the paginated content might not even be treated as a series.
What about ranking signals?
Ranking signals will be consolidated for the series, rather than one specific page, which should give a ranking advantage.
Watch out for:
Incorrect URLs in pagination tags: they should match the URLs you use in your internal links.
For example, if the URLs to take the user from one paginated page to another are written example.com/page1, /page2, /page3 etc, then the URLs in your pagination tags should be the same.
Incorrect URLs in pagination tags are can be detected by the Deepcrawl ‘Unlinked Paginated Pages’ report – see below for more information.
Broken chains of pagination URLs:
Option 3: No markup or canonicals
And finally, an option for the laziest busiest of SEOs. Google will still try to group paginated pages without any markup, and if you have a view-all option available (still using no rel next/prev markup) then your paginated content might still be indexed in favour of your view-all version.
You have no control over how Google will index and display your content. Use this option at your peril…
What about infinite scrolling?
Sometimes an infinite scroll is used as an alternative to pagination – this is fine for SEO, provided an equivalent paginated page URL exists as well. Search engines can then use this backup paginated URL instead when they crawl the site.
Testing pagination markup with DeepCrawl
DeepCrawl now detects rel next/prev tags as it crawls pages, and we’ve added three new reports to help you keep track of your rel next/prev setup. You can also monitor canonicalized pages and unlinked canonicalized pages in our canonical tag reports.
1. Paginated Pages report
A page with a rel=prev tag is not the first page in the set of results. We call all these pages ‘Paginated’ and now report them separately to Unique Pages.
This means that the unique page count is a more accurate reflection of the valuable pages on your site.
2. First Pages report
Any page with a rel=next but no rel=prev should be the first page in a set of paginated pages. We call these ‘First Pages’. They are treated as Unique Pages but are also included in a new report under Content > Pagination so you can see them.
Any new URLs found in rel next/prev tags will be crawled even if they are not linked from any other page. If they are not linked anywhere on the site then this could be an error so we include them in a new report called Unlinked Paginated Pages.