Pagination breaks sites in slow, invisible ways. Splitting a blog or a product catalog across numbered pages creates dozens of near identical URLs. Search engines have to crawl all of them, work out which ones matter, and figure out how they connect. Get that wrong and good pages never get found at all.
We see this on almost every site we take over. The homepage ranks fine. The three most popular blog posts rank fine. Then we crawl the archive and find that page four onward was never indexed, so every post sitting on those pages was invisible to search the whole time.
The fix is rarely complicated. Most pagination problems trace back to three small decisions: how the URLs are built, where the canonical tag points, and whether a real link exists for a crawler to follow. We will take each one in turn.
Pagination means splitting one long list of content across a numbered sequence of pages. A blog archive with page one, page two, and page three is paginated. So is a product category showing twelve items at a time. Each of those pages is a separate URL that Google can crawl and index on its own.
That word "separate" is where most teams go wrong. People think of page two as a different view of page one. Google does not see it that way. Google sees a distinct URL with distinct content on it, and it makes a distinct decision about whether to index that URL.
This matters because paginated pages are almost never the pages you want to rank. They are the roads that lead to the pages you want to rank. A blog archive page will rarely win a search result, but it is often the only path Googlebot has to the article sitting on page seven.
Google no longer uses the rel="next" and rel="prev" link tags at all. Google's own pagination documentation states it plainly: "Google no longer uses these tags, although these links may still be used by other search engines." The markup is not harmful. It simply does nothing for your rankings in Google.
For years these tags were treated as the correct way to tell a search engine that a set of pages formed one sequence. Plenty of older SEO advice still recommends them, and plenty of plugins still output them. If you already have them on your site, leaving them in place costs nothing, and Bing may still read them.
What replaced them is simpler than what came before. Google now works out the sequence from ordinary signals: the internal links between pages, the URL pattern, and the content itself. Your job is no longer to declare the relationship in markup. Your job is to make the relationship obvious through plain HTML links.
No, and this is the single most common pagination mistake we find. Google's pagination documentation is direct about it: "Don't use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL." Pointing page five at page one tells Google to ignore page five completely.
Think about what that instruction actually does. A canonical tag says this page is a duplicate of that page, so index the other one instead. Page five is not a duplicate of page one. It holds entirely different articles or products. When you canonicalise it away, you are asking Google to drop the only link path to that content.
The correct setup is a self referencing canonical on every page in the sequence. Page one points at page one, page two points at page two, and so on down the line. If canonical tags are new territory for you, we broke down the full logic in our guide to canonical URLs and duplicate content, which covers the cases where consolidation genuinely does help.
Give every page in the sequence a real, unique URL. Google's guidance is to "Give each page a unique URL. For example, include a ?page=n query parameter." It also warns against fragments: "Don't use URL fragment identifiers (the text after a # in a URL) for page numbers." A fragment is not a separate page to a crawler.
Both of the common patterns work fine. A path based URL like /blog/page/2 and a query based URL like /blog?page=2 are equally crawlable. What matters is that you pick one and stay consistent, because two URL patterns serving the same page two is a duplicate content problem you created for yourself.
The rule we hold to on every build is that page two must return a 200 status code when you load it directly, with no JavaScript running. If you can paste the URL into a fresh browser tab with scripts disabled and still see the right items, a crawler can too. Our notes on URL structure for SEO go deeper on picking a pattern you will not regret later.
Infinite scroll is risky on its own and perfectly fine when paired with real URLs. The problem is mechanical, not philosophical. Google's documentation notes that "Google's crawlers don't 'click' buttons and generally don't trigger JavaScript functions that require user actions." Content that only appears after a scroll or a tap may never be seen.
The same applies to a load more button, which is the pattern most marketing sites reach for. It feels modern and it tests well with users. But if the second batch of items only exists after a click, and no crawlable link points to those items, they are effectively hidden from search.
The honest answer is that you can have both. Build the infinite scroll for people, then back it with a paginated set of real URLs that a crawler can walk. Google's own guidance points the same direction, suggesting a sitemap file to help it find products that a scroll pattern would otherwise bury.
For most sites, it does not. Google's crawl budget documentation scopes that advice to "Large sites (1 million+ unique pages) with content that changes moderately often (once a week)" and "Medium or larger sites (10,000+ unique pages) with very rapidly changing content (daily)". Below those numbers, crawl budget is rarely your bottleneck.
We raise this because crawl budget gets blamed for a lot of problems it did not cause. A 200 page marketing site with unindexed blog posts does not have a crawl budget problem. It has a linking problem or a canonical problem, and those are the things worth fixing first.
Where pagination genuinely does inflate crawling is on ecommerce catalogs with faceted navigation, where filters and sort orders multiply against page numbers until one category produces thousands of URLs. Google's advice there is to "Eliminate duplicate content to focus crawling on unique content rather than unique URLs". If your site is in that territory, our guide to crawl budget and SEO covers how to triage it.
Usually not. Adding a noindex tag to page two and beyond feels tidy, and some SEO tools still suggest it. The trouble is that it removes the discovery path to everything sitting on those pages. We leave the numbered sequence indexable by default and only make exceptions when there is a specific reason.
Google's documentation reserves noindex for a narrower case. It suggests the tag, or a robots.txt rule, for the variations that support filters and alternative sort orders rather than for the core numbered sequence. A sorted by price view of page three is genuinely disposable. Page three itself is not.
Our position is that a paginated page earns its place by being a route, not a destination. Nobody searches for "blog page four". But Googlebot walks it, follows the links on it, and finds the article you actually want ranking. Remove that page from the index and you remove the route.
Webflow handles the fundamentals correctly out of the box. Turning on pagination for a Collection List produces a query parameter URL for each page, and the previous and next controls render as ordinary anchor tags in the HTML. Those are the two things that matter most: real URLs and crawlable links.
We checked this against Webflow's own blog while writing this piece, since that site is built in Webflow. The next page control is a plain anchor tag pointing at a query parameter, exactly the shape a crawler can follow without running any JavaScript. That is a better default than a lot of platforms manage.
Where you want more control, the Finsweet List Load attribute extends Webflow Collection Lists with load more, infinite load, render all, and its own pagination mode. It is a genuinely useful tool. The same rule applies as anywhere else, though: if you switch a list to load items on scroll, make sure a crawlable paginated path still exists underneath it.
Start with a crawl. Point Screaming Frog or Ahrefs at your site, filter for paginated URLs, and check three things. Does each page carry a self referencing canonical? Is each page reachable through a real anchor tag? Does page two return a 200 with JavaScript disabled? Most sites fail at least one of those.
If the crawl comes back clean, leave pagination alone and spend your time on the pages you actually want to rank. If it comes back messy, fix the canonical tags first, because that one change usually recovers more indexed pages than everything else put together. Then confirm the recovery in Google Search Console rather than guessing.
We work through this on almost every site we rebuild, and it is never the dramatic part of the project. It is quiet, unglamorous plumbing that decides whether half your content exists in search or not. If you are not sure what your pagination is doing, we are happy to take a look and walk you through it. You can find us at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.