Why does Google never click on your Load More buttons, and how can you avoid this?

What's the issue with Load More buttons for Googlebot?

Googlebot does not simulate complex user interactions. It does not click on buttons, does not submit forms, and does not scroll to trigger infinite lazy-loads. Its behavior remains that of a classic crawler: it follows the static href links it finds in the rendered DOM.

When your pagination relies exclusively on a <button onclick="loadMore()"> type button, Googlebot sees a dead end. It has no way to discover pages 2, 3, 4 and their associated content. The result is that only page 1 is indexed, everything else disappears from the engine's view.

Why does Martin Splitt emphasize static links with href?

A classic HTML link <a href="/products?page=2"> is universally crawlable: by Googlebot, by competing crawlers, by screen readers, by users without JavaScript enabled. It’s the basis of an accessible and indexable web.

JavaScript can then intercept the click event on this link via event.preventDefault() and load the content via AJAX without page reloading. The user benefits from a modern seamless navigation, Googlebot finds its way. This is the principle of progressive enhancement: HTML first, JavaScript as an enhancement layer.

What is the practical impact on indexing if I keep my buttons?

Content located on subsequent pages will likely never be crawled or indexed. If your e-commerce site displays 20 products per page with a Load More button, Googlebot will only see the first 20 products. The other 200 remain invisible.

Some sites compensate with comprehensive XML sitemaps listing all individual product URLs, but this is a patch. Natural internal linking via pagination remains the most reliable method to pass PageRank and ensure regular crawling.

• Googlebot does not click on buttons — it only follows static href links
• A pagination in classic HTML links remains the only universally crawlable solution
• JavaScript can intercept these links to provide a modern UX without reloading
• Without static links, pages 2+ risk never being indexed
• XML sitemaps do not replace a coherent internal linking

Is this recommendation really new or revolutionary?

Absolutely not. It’s a web architecture principle that every technical SEO has known for at least 15 years. Progressive enhancement is not a trend — it’s the official doctrine of the W3C since the 2000s. What’s interesting is that Google still has to remind this publicly.

This means a significant proportion of sites continue to deploy JavaScript-only paginators inaccessible to crawlers. Modern front-end frameworks (React, Vue, Angular) default to SPA architectures that often neglect bot crawlability. Splitt's reminder is a signal: indexability remains a secondary concern for many modern stacks.

In what cases doesn't this rule strictly apply?

If your paginated content has no SEO value — for example, internal user comments in a SaaS app reserved for logged-in members — you can afford a pure JavaScript Load More. No crawl desired = no constraint.

Another exception: sites using server-side rendering (SSR) or static site generation (SSG) with frameworks like Next.js, Nuxt, SvelteKit. In these architectures, each URL /products?page=2 returns full HTML from the server before any JavaScript execution. Googlebot receives a directly exploitable DOM. But beware — badly configured SSR can mislead. [To verify]: always test with a curl or Screaming Frog crawl to ensure that the raw HTML indeed contains the links.

What nuance should be considered regarding Google's JavaScript rendering?

Google has indexed JavaScript for years, that's true. But the WRS (Web Rendering Service) introduces delays, additional crawl budget costs, and potential bugs. Martin Splitt himself has repeatedly stressed that JS rendering remains a fallback, not a first-choice solution.

In concrete terms: even if Googlebot executes your JS and could theoretically click a button via a script, it does not do so by default. It has no heuristic to guess that a "Load More" button should be clicked. Relying on JS rendering to compensate for a failing architecture is playing Russian roulette with your indexing.

What concrete steps should be taken to correct problematic pagination?

Replace your <button>Load More<\/button> buttons with classic HTML links: <a href="/category?page=2">Next Page<\/a>. If you want to maintain a modern UX, intercept the click with JavaScript to load the content via AJAX without reloading.

Simplified code example: document.querySelectorAll('.pagination a').forEach(link => link.addEventListener('click', function(e) { e.preventDefault(); fetch(this.href).then(...); }));. You keep a seamless navigation for the user, Googlebot follows the hrefs normally. This is the method recommended by all engines.

What critical mistakes should be avoided in implementation?

Do not fall into the trap of the empty JavaScript link type <a href="#" onclick="loadPage(2)">. This is no better than a button — Googlebot sees a href pointing to the same page. It requires a functional href that returns exploitable HTML even without JS.

Another common mistake: forgetting the rel="next" and rel="prev" tags. Even though Google officially stopped using them for indexing in 2019, they remain useful for other engines and for documenting the logical structure of your pagination. Consider them as an optional but clean layer of metadata.

How can I check that my site is compliant after correction?

Use curl or wget in the command line to retrieve the raw HTML of your listing page: curl -A "Googlebot" https://mysite.com/category. Check that the href links to page=2, page=3 appear in the response, before executing any JavaScript.

Run a crawl with Screaming Frog in "JavaScript disabled" mode. If pages 2+ are not discovered, your pagination remains inaccessible to bots. Also validate in Google Search Console that paginated URLs appear in the coverage report — if they remain absent after several weeks, it’s a red flag.

• Replace all Load More buttons with functional <a href> links
• Intercept clicks with JavaScript to maintain a UX without reloading
• Test the raw HTML with curl or wget to confirm the presence of links
• Crawl the site with Screaming Frog in disabled JS mode
• Check in Search Console that the paginated pages are indexed
• Keep rel="next/prev" tags for documentation and compatibility