Pagination and Faceted Navigation SEO: Avoiding Index Bloat
By Kavi, SEO Consultant · Last updated: 3 September 2026
Paginated pages should stay indexable and self-canonical so search engines can discover the items on them. Faceted navigation, filters that combine into large numbers of URLs, should generally be blocked from crawling instead. The distinction is simple: pagination is a path to unique content, facets are usually a path to rearranged content.
What is the difference between pagination and faceted navigation?
Pagination splits one long list across numbered pages: page 1, page 2, page 3. Each page shows different items. Page 4 is the only route to the items on page 4.
Faceted navigation lets users filter and sort a list: by colour, size, price, brand, rating, sort order. Each combination can generate a distinct URL, and combinations multiply. Ten facets with five options each produce millions of possible URLs, nearly all showing rearranged subsets of content that already exists elsewhere.
They get grouped together in technical SEO discussions because both create many similar URLs. They need opposite treatment, and applying the facet solution to pagination is a mistake I see constantly.
Quick facts
| Item | Pagination | Faceted navigation |
|---|---|---|
| Content on each URL | Unique items | Usually a subset of existing items |
| URL growth | Linear | Combinatorial |
| Recommended treatment | Index, self-canonical | Block from crawling |
| rel=”next”/”prev” | Unsupported by Google since 2019 | Not applicable |
| Canonical to page 1 | Wrong; hides deeper items | Not the right tool either |
| Main risk | Deep items never discovered | Index bloat and crawl waste |
How to handle pagination
Google confirmed in 2019 that it no longer uses rel="next" and rel="prev". Plenty of guidance still recommends them. They do no harm, but they do nothing, and you should not build a strategy on them.
The correct approach
- Each paginated page self-canonicalises. Page 3 declares itself canonical, not page 1.
- Keep paginated pages indexable. They are the discovery path to deeper items.
- Use real crawlable links between pages, real anchor tags with href attributes, not JavaScript click handlers. See JavaScript SEO and rendering.
- Give each page a distinct title where the template allows, for example “Running Shoes, Page 3”.
- Keep the sequence unbroken. A gap in the chain orphans everything after it.
- Include page 1 only in your XML sitemap, but let crawlers reach the rest through links.
The mistake worth naming: canonicalising every paginated page to page 1. It sounds tidy and it is actively harmful. It tells Google that pages 2 onward are duplicates of page 1, which means the items that appear only on page 7 have no discoverable route into the index. On a large catalogue this can hide most of your inventory.
View-all pages
If you offer a view-all page and it loads acceptably fast, it is legitimate to canonicalise paginated pages to it, because it genuinely contains all the same items. If it is slow or enormous, do not; a page nobody can load is not a better canonical.
Infinite scroll
Infinite scroll is a user-experience pattern that hides content from crawlers, because Google does not scroll. If you use it, back it with real paginated URLs that work without JavaScript, and link to them. Infinite scroll alone means everything past the first screen is invisible.
How to handle faceted navigation
Facets are the largest single source of crawl waste on ecommerce sites. The strategy is to decide which facet combinations have genuine search demand, make those a small number of real indexable pages, and block everything else.
Step 1: Classify your facets
| Facet type | Example | Treatment |
|---|---|---|
| Has real search demand | “waterproof hiking boots” | Build a real indexable landing page |
| Narrows content meaningfully | Brand, category | Consider indexing selectively |
| Rearranges only | Sort by price, ascending | Block from crawling |
| Combinatorial | Colour plus size plus price plus rating | Block from crawling |
| Session or tracking | ?sessionid=, ?utm_ | Block; self-canonical the clean URL |
| Pure display options | Grid or list view, items per page | Block from crawling |
Step 2: Block the waste in robots.txt
User-agent: *
Disallow: /*?sort=
Disallow: /*?view=
Disallow: /*?price=
Disallow: /*&colour=
Disallow: /*?sessionid=Test every pattern against live URLs before deploying. An over-broad rule can block canonical category pages that happen to carry that parameter. The precedence rules are in robots.txt explained.
Step 3: Promote high-demand combinations to real pages
Where a facet combination matches genuine search demand, do not leave it as a filtered URL. Build it as a proper category page with its own clean URL, unique introductory copy, and internal links from the parent category. That converts crawl waste into a ranking asset.
Step 4: Self-canonicalise the clean version
Every category page should declare its clean, parameter-free URL as canonical, so tracking parameters do not create indexable duplicates. See canonical tags and duplicate content.
Step 5: Consider nofollow on facet links
Adding rel="nofollow" to filter links reduces discovery of those URLs. Since 2019 nofollow is a hint rather than a directive, so treat this as a supporting measure alongside robots.txt, not a replacement for it.
Step 6: Verify in logs
After deploying, check server logs to confirm crawl requests to blocked patterns actually stopped. This is exactly the case log file analysis is best at.
What not to do
| Mistake | Why it fails | Instead |
|---|---|---|
| Canonicalise paginated pages to page 1 | Deep items become undiscoverable | Self-canonical each page |
| Noindex paginated pages | Google eventually stops following their links | Keep them indexable |
| Rely on rel=next/prev | Google dropped support in 2019 | Use ordinary crawlable links |
| Noindex facet URLs instead of blocking | Still crawled; no budget saved | Disallow in robots.txt |
| Block facets that have real search demand | Loses genuine ranking opportunities | Promote them to real pages |
| Infinite scroll with no paginated URLs | Content past the first screen is invisible | Provide paginated fallbacks |
| Over-broad parameter blocking | Blocks real category pages | Test patterns against live URLs |
| Facet links generated only by JavaScript | Inconsistent crawling, hard to control | Server-render the canonical set |
Decision guide
- Blog archive pages: keep indexable and self-canonical. Do nothing clever.
- Small catalogue under 500 products: pagination is enough; facets rarely need blocking.
- Large ecommerce catalogue: block sort, view, and multi-select facets; promote the top demand combinations to real pages.
- A facet with clear search volume: build it as a category page, not a filter URL.
- Already suffering index bloat: block the patterns, then use the Removals tool for a temporary hide while Google drops the URLs naturally.
Checklist
- Paginated pages self-canonicalise, not to page 1
- Paginated pages are indexable
- Pagination links are real anchor tags with href
- No gaps in the pagination sequence
- Infinite scroll backed by paginated URLs
- Sort, view, and display parameters disallowed
- Multi-select facet patterns disallowed
- Every parameter rule tested against live URLs before deployment
- Category pages self-canonical to the clean URL
- High-demand facet combinations built as real pages
- Logs confirm blocked patterns are no longer crawled
- Search Console indexed page count trending towards your real page count
Frequently asked questions
Should paginated pages be noindexed?
No. Noindexed pages are crawled less over time, and Google has indicated it eventually treats long-term noindexed pages as nofollow, which breaks the discovery path to deeper items. Keep them indexable.
Does Google still support rel=next and rel=prev?
No. Google announced in 2019 that it had not used them for some time. They are harmless but inert. Ordinary crawlable links between pages are what matters.
Should I canonicalise page 2 to page 1?
No. This is the most damaging pagination error. Page 2 is not a duplicate of page 1; it contains different items. Self-canonical each page.
What about a view-all page?
If it exists and loads fast, canonicalising paginated pages to it is reasonable because it genuinely contains the same items. If it is slow, keep self-canonicals instead.
Is noindex or robots.txt better for facets?
Robots.txt, when the goal is saving crawl budget, because noindexed pages are still fetched. Details in noindex vs nofollow vs disallow.
How do I know if I have index bloat?
Compare Search Console’s indexed page count against the number of pages you believe you have. A large unexplained excess usually means facet or parameter URLs are being indexed.
Can facet pages rank?
Yes, when they match real search demand and are built as proper pages with unique content and internal links. A raw filtered URL with no unique copy rarely ranks and is usually not worth indexing.
Key takeaways
- Pagination and facets look similar and need opposite treatment.
- Paginated pages: indexable, self-canonical, linked with real anchors.
- Never canonicalise page 2 to page 1.
- rel=next and rel=prev have been unsupported since 2019.
- Facets: block from crawling with robots.txt, not noindex.
- Promote high-demand facet combinations to real category pages.
- Verify the result in server logs, not by assumption.
Conclusion
The rule fits in one sentence: if a URL is the only way to reach unique content, keep it crawlable and indexable; if it only rearranges content reachable elsewhere, keep crawlers out. Apply that test to every parameter on your site and most of these decisions make themselves.
Related articles
- Technical SEO guide
- Crawl budget explained
- Canonical tags and duplicate content
- Robots.txt explained
- Site architecture and URL structure
External references
- Google Search Central: Faceted navigation best practices
- Google Search Central: Pagination and incremental page loading
