Pagination vs Load More: Which Pattern Works Better for Agents
Three patterns dominate how sites split long lists of content into manageable chunks: traditional pagination, "Load More" buttons, and infinite scroll. From an AI agent's perspective, these three approaches are not remotely equal. One works reliably. One is tolerable. One is a dead end.
Pagination: The Clear Winner
Traditional pagination with numbered links (?page=1, ?page=2, ?page=3) is the best pattern for AI agent access. Each page has a unique, predictable URL. An agent can request any page directly without visiting the ones before it. It can calculate the total number of pages from the pagination controls and decide whether to check them all or sample specific pages.
The URLs are stable. An agent can bookmark page 7, come back tomorrow, and find the same URL still works. It can make parallel requests for pages 1 through 10 simultaneously, something impossible with sequential interaction patterns.
We tested 60 e-commerce category pages. Sites using traditional pagination allowed agents to access 100% of listed products. The agent could discover the total product count, calculate the number of pages, and systematically request each one. Average time to index a 500-product category: 12 seconds with parallel requests.
Pagination also generates crawlable <a href> links that agents can discover in the DOM. The "Next" and "Previous" links, along with numbered page links, all exist as standard HTML anchors. There's no JavaScript interaction required to find them.
Load More: The Middle Ground
"Load More" buttons sit between pagination and infinite scroll. They're better than infinite scroll because the trigger is a visible, clickable element. An agent can find the button in the DOM and click it. But they come with friction.
Each click loads one batch and typically replaces the button with a loading spinner. The agent has to wait for new content to appear, confirm the button has returned, and click again. For a catalogue with 500 products shown 20 at a time, that's 25 sequential click-wait-confirm cycles. Not impossible, but slow and fragile.
The bigger issue: most "Load More" implementations don't update the URL. After clicking "Load More" fifteen times, the URL still shows /products. If the agent's session drops, it starts over from batch one. There's no way to jump directly to a specific batch. And the agent can't request batches in parallel because each one depends on the previous click.
Some better implementations do update the URL with an offset parameter (/products?offset=60), which helps. But this is rare. We found URL updates in only 18% of the "Load More" implementations we tested.
Infinite Scroll: The Worst Case
Infinite scroll, which we've covered in detail in how infinite scroll breaks AI agent browsing, is the worst option. Content loads only when a scroll event fires. There are no links, no buttons, no URLs. The agent sees the first batch and nothing else.
Even agents capable of simulating scroll events face problems. They need to scroll, wait for content, scroll again, and repeat. Some implementations remove earlier content from the DOM as the user scrolls down, so the agent can't even access items it already passed. There's no way to determine how many total items exist or how far to scroll.
The Hybrid Approach
The best sites offer pagination as the default and use it as the source of truth, while optionally layering on a smoother "Load More" or infinite scroll experience for human users who prefer it.
Here's what that looks like in practice:
- The server renders numbered pagination links in the HTML
rel="next"andrel="prev"link elements appear in the<head>- JavaScript progressively enhances the page with a "Load More" button or scroll-triggered loading for human visitors
- The pagination URLs (
?page=2,?page=3) always work, even if the JS layer overrides them visually
This gives agents the clean URL structure they need while letting human users have whatever browsing experience feels best.
URL Structure Matters
Agents work best with URL patterns they can predict and construct. The difference between these two approaches is significant:
/products?page=3 is predictable. An agent that sees page 1 can guess page 2 and page 3.
/products?cursor=eyJpZCI6MTIwfQ== is opaque. Cursor-based pagination uses encoded tokens that only the server understands. An agent can't construct the next URL without first requesting the current page and extracting the cursor from the response.
If you're building an API that agents will consume, prefer offset-based pagination (?page=N or ?offset=N&limit=20) over cursor-based pagination. Cursors are better for database performance at scale, but they prevent direct page access.
The bottom line: pagination is the friendliest content-splitting pattern for AI agents, and it's also the most accessible for screen readers, the most compatible with search engines, and the easiest to implement. It's progressive enhancement at its simplest: the baseline works for everyone, and you can layer fancier interactions on top.