What Is Pagination?

Pagination is the splitting of a long listing across several screens: the products in a category, the articles on a blog, the results of a search. Each stretch usually has its own address, and links between them let you move on.

It exists for two reasons at once. One is performance: loading ten thousand products on a single screen ruins any page speed and makes the page unmanageable. The other is orientation: an endless list does not let you tell where you are, and that is where a breadcrumb is missing.

For a search engine, discovery comes on top. If pages two, three and onwards have no linked address of their own, the crawler never reaches what is on them, however good it may be. Half the catalog can stay invisible without anything looking broken.

It deserves separating from two things it gets mixed with. Filtering is not the same: a filter changes WHAT is shown, pagination changes HOW MUCH is shown at once. And sorting is not the same: a different order spreads the same items across the same pages, only in another sequence.

The confusion matters because all three usually sit on the same screen and generate addresses at the same time. When filter, sort order and page combine freely in the URL, the number of possible addresses multiplies — and that is exactly the road to index bloat.

In practice there are three ways of spreading a listing, and they differ less in appearance than in what they leave behind. The useful question is always the same: is there an address of its own that a link can reach?

With page numbers the answer is yes and there is nothing more to discuss. With a load more button it depends how it is built: if the button is only a piece of JavaScript, there is nothing to follow; if a real link sits underneath as well, it works as well as the numbers. With infinite scrolling there is no address at all.

And all three coexist without conflict: the comfortable view for whoever is browsing and the numbered URLs underneath, linked so that the crawler walks them. There is no need to choose between user experience and discovery.

One construction detail decides more than it seems: whether the links between pages are real link elements or elements that respond to a click through code. Only the first is a route; the second can work perfectly for the visitor and not exist for whoever walks the site by reading the markup.

And a practical consequence for review: check the delivered HTML, not the screen. A row of numbers can look immaculate and be built without a single real link behind it, and then half the catalog becomes an orphan page with nothing to warn you.

The decision most often got wrong concerns the canonical. Page two is not a version of page one: it holds different products, so its canonical belongs on itself. Pointing them all at the first tells Google the rest does not exist, and the catalog disappears from the index without anyone asking for it.

The second concerns the rel=next and rel=prev markup recommended for years. Google stopped using it in 2019 and the current pagination documentation no longer mentions it; adding it does no harm but solves nothing either, and certainly does not replace ordinary links between pages.

The third concerns titles. If the fifty pages of a category share a title and description, there is no technical error, but to whoever reads the SERP it looks like duplicate content. Putting the number in the title is the minimum, and saying on the first page what the others do not repeat is the sensible thing.

A fourth decision gets discussed less and bears directly on what ends up indexed: what to do with the first page when it exists both with and without a parameter. In many systems the clean category address and the same one with a page-one suffix coexist, both with the same content. That pair is a genuine duplicate, and there the canonical belongs on the clean version.

And a recommendation on internal linking: you do not need to link all fifty pages from each of them. The previous, the next and a few anchor points are enough; a bar listing them all spreads weight across too many destinations and fills the markup with links nobody uses.

There is no correct figure, there is a balance between two costs. With few items per page the listing breaks into many URLs and everything moves further away, which worsens click depth. With many, each page takes longer to load and weighs more on mobile.

A sensible starting point is asking how many pages the split produces. If a category of a thousand products is divided twenty at a time, there are fifty pages, and the last ones sit too many clicks from the start. A hundred at a time makes ten, and those can be walked.

The decision should also not rest on the listing alone. A good internal search, considered filters and themed blocks that jump into the depth of the catalog turn pagination into a side route — and that lowers both depth and the crawl budget spent walking it.

A note on checking whether the chosen split works: look in Search Console at how many of those pages receive impressions. A common and healthy pattern is the first taking almost everything while the rest appear rarely; what should worry you is none appearing beyond a certain number, because that means the crawler no longer gets there.

And a complementary check in the server log: if the higher pages are never requested, they are not underperforming, they are unvisited. Two different findings with different fixes, and only log file analysis separates them with facts.

The most expensive is the canonical to the first page, already mentioned, because it removes from the index exactly what you meant to organise.

The second is putting noindex on pages two and onwards. It looks tidy and produces the opposite of what was intended: products appearing only there stop being discovered, because the crawler tends to visit a page less often once it has been told not to index it.

And the third is a badly built "view all" page. As an option for the user it is fine; as the only indexable URL of a category with a thousand products it is an enormous page nobody finishes loading. If it exists, let it complement the numbered pages rather than replace them.

A fourth mistake shows up in migrations: changing the number of items per page without thinking about the old addresses. Moving from twenty to a hundred, pages thirty to fifty stop existing, and with no move prepared they remain as 404 errors linked from outside. A 301 redirect to the equivalent stretch resolves the whole case.

And the last, the quietest: letting the default sort order drift. If a category is sorted by newest and stock arrives daily, page three holds something different every week. That is not a fault in itself, but it explains why such pages rarely consolidate positions — worth knowing before looking for another cause.