New format
Website pagination: how to build it without hurting SEO
Pagination splits a long list into pages: catalog, blog, search results. Useful for readers, but without rules you easily get thin duplicate pages in the index.
Below: why you need it, how to build it, SEO settings, the link with filters, and audit. Exact attributes like rel prev/next are no longer universal — rely on canonical tags and whether each page is useful.
Why pagination exists
Pagination speeds load, simplifies navigation of large lists, and gives stable URLs for return visits and linking. You need it wherever people compare many similar items.
Numbered pages are crawlable and available without JavaScript. A “Show more” button can complement them, but must not hide content behind JavaScript alone.
Where it shows up:
- online store catalogs
- blog and news feeds
- on-site search
- archives and tags
How to build it on a site
Server or frontend returns a batch of items and navigation: numbers, next/back. Make URLs predictable — `/catalog/page/2/` or `?page=2` — and consistent across the section.
Each existing page needs a correct status code and links to neighbors. Paging past the end must not return an empty 200 as if content exists.
UX practice:
- current page is visible
- large tap targets on mobile
- filters persist across pages
- sort doesn’t reset
- path to first and neighbors exists
SEO setup
Title and H1 on pagination pages must not be meaningless clones. Choose canonical by catalog strategy and usefulness of deep listings — not a blanket “everything to first” template.
In the sitemap, include listings that should index. Separately control filters, sorts, and parameter duplicates: they often hurt more than numbering itself.
Common mistakes:
- thousands of nearly empty page=N in the index
- duplicates with/without slash and different parameters
- 200 on nonexistent pages
- the same SEO text above the list on every page
Pagination vs filters and sorts
Pagination pages through the same set. Filters and sorts create new selections and easily balloon the index to hundreds of thousands of URLs.
Decide ahead: which combinations to index (strong landings), which to close (noindex / robots / canonical). Otherwise pagination SEO won’t save you from a facet explosion.
Split in policy:
- page=N inside a clean category
- filter color + size + brand
- sort by price or newness
- UTM and utility parameters
“Show more” and infinite scroll
Classic numbering is better for a catalog when you need to return to a specific slice. “Show more” cuts clicks, but next-batch URLs must still be available to bots and people.
Infinite scroll fits news feeds, but is worse when people need to return to a position. If you use JavaScript, provide server-rendered output and a no-script path.
Check UX:
- current page or position is visible
- filters persist
- keyboard control exists
- after browser Back, list place isn’t lost
Content on pages 2+
Category SEO copy usually stays on the first page. Copying it onto page 2, 3, and beyond is pointless and strengthens the duplicate feel.
On deep pages a list, navigation, and clear title (“Page 2” / product range — per store template) are enough. What matters is a unique set of cards and correct links.
Good practice:
- unique product/post set per page
- don’t duplicate long SEO text
- internal links to key categories from page 1
- don’t index an empty tail
Indexing page=N (simplified)
| Situation | Common approach |
|---|---|
| Many products, useful listing | Index deliberately |
| Nearly empty tails | Don’t index / keep out of sitemap |
| Strong filter landings | Separate URLs, don’t confuse with page |
| Sort only | Usually not for the index |
Audit after launch
Crawl the section: status codes, canonical, link chain, items per page. Compare desktop and mobile templates.
In Webmaster/GSC watch index and crawl errors. Changing filters or the catalog template can create thousands of URLs — repeat the audit after releases.
Red flags:
- empty pages with 200
- different URLs for the same result set
- parameter duplicates
- content only via JavaScript
- page=N explosion in the index report
FAQ
Do you need pagination instead of “show more”?
Either approach works. Infinite scroll is convenient but worse for sharing deep URLs. Classic ?page=2 is easier to control.
Should page=2, 3… be indexed?
If there’s unique useful content or products — yes, on purpose. If they’re almost empty copies — noindex or canonicalize deliberately.
Does rel=prev/next help?
Google long ago stopped treating them as a hard signal. Canonical, structure, and quality matter more.
What about filters and sorts?
Don’t create indexable filter combos you don’t need — those are facets, not pagination. Give them a separate parameter policy.
How many products per page?
Balance UX and page weight: usually dozens of cards, not hundreds of heavy blocks at once.
Should you always canonicalize to page 1?
Not always — it depends on listing uniqueness. Don’t hide needed cards by blindly canonicalizing everything to page=1.
Should a nonexistent page=100 return 200?
If the page doesn’t exist, return 404 (or a correct “end of list”), not an empty 200.
Do all pages belong in the sitemap?
Not required. Include the listings that should be indexed; a long page=N tail is often extra.
Catalog page=200 in the index — and empty thin listings everywhere?
We’ll set predictable URLs, sensible indexing, and facet rules — without cloning SEO text on every page.
Discuss the task
