"Load More" Buttons and SEO: Googlebot Doesn't Click Buttons
After switching the post list to a 'Load more' button, only 10 of 49 posts were linked. Why Googlebot doesn't click buttons, checked against Google's docs, and how to reach every post with <a href> links.
All I did was change the list
On Oct 7, this blog redesigned its post list: it shows the first 10 posts, and a "Load more" button reveals 10 more at a time. It looked cleaner, and for readers nothing was wrong.
Then, while investigating indexing in Search Console, I opened the list page's server HTML and found this:
| List | Total posts | Posts linked in the HTML |
|---|---|---|
| Korean (/) | 49 | 10 |
| English (/en) | 17 | 11 |
The rest only appear after clicking "Load more," and Googlebot doesn't click that button. A list that showed 49 posts to people was a 10-post list to the crawler.
Does Googlebot really not click buttons?
"It doesn't click buttons" gets repeated on many blogs, so I checked Google's own docs.
Google reliably follows only links that are <a> elements with an href attribute. It doesn't perform JavaScript actions that need a click to change the content.
| Source | Summary |
|---|---|
| Google Search Central: Link best practices | Generally, Google can only crawl a link if it's an <a> element with an href attribute. It can't reliably extract URLs from elements without href, or from other tags that act as links through script events |
| Google Search Central: Pagination and incremental page loading | Describes "Load more" buttons and infinite scroll as incremental loading, and recommends linking pages sequentially so search engines can find all the content |
| Google Search Central: JavaScript SEO basics | Googlebot renders JavaScript, but finds links in <a> elements with href |
| Search Engine Journal: Googlebot Doesn't Click on Buttons (third-party article) | Covers Google's Martin Splitt saying Googlebot doesn't click buttons, and recommending regular links instead |
One point is easy to get wrong. Googlebot does run JavaScript and render the page. So "Google can't see content made with JavaScript" is false. More precisely, it sees what renders when the page first loads, but not what appears only after a user does something. Posts behind "Load more" are exactly that case.
Button vs link
The same-looking "Load more" can look completely different to a crawler depending on its HTML.
<!-- ❌ No URL for the crawler to follow. Posts only appear on click -->
<button type="button" onclick="loadMore()">Load more</button>
<!-- ❌ Looks like a link, but with no href there's no URL to extract -->
<span class="link" onclick="location.href='/page/2'">Load more</span>
<!-- ✅ The crawler can go to /page/2 and read the next set of posts -->
<a href="/page/2">Load more</a>
This blog's "Load more" was the first case. A <button> performs an action; an element that goes somewhere is <a href>. The difference is also covered in 7 common semantic HTML mistakes.
Check whether your site has the same problem
The simplest way is to count how many post links are in the HTML the server sends.
# Count links to post URLs (/en/...) in the list page's HTML
curl -s https://iambilly-blog.vercel.app/en | grep -o 'href="/en/[^"]*"' | sort -u | wc -l
If that number is much smaller than your total posts, the rest can't be reached through links. For sites rendered with JavaScript, you can also check the HTML Google rendered under URL Inspection → View crawled page in Search Console. Either way, posts that need a button click won't be in it.
Another check is to run a crawler that only follows links. This blog's Nuxt build crawler (nitro.prerender.crawlLinks) follows links from the home page to prerender pages, and before the fix it found only 35 pages. That was even after following every "related posts" link on the post pages.
Three fixes
| Fix | How | Good fit for |
|---|---|---|
| Numbered pagination | Give each page a real URL like /page/2, /page/3, linked with <a href> | Sites with hundreds of posts or more |
| "Load more" as a link | Make "Load more" an <a href="/page/2">, and when JavaScript is available, intercept the click and append posts in place | When you want to keep the current "Load more" UI |
| An all-posts page | One page listing every post as a link, linked from every page | Blogs with dozens to a few hundred posts |
The second fix builds a link that works without JavaScript first, then layers a better experience on top with JavaScript. Visiting /page/2 directly must actually render page 2's posts on the server. A URL with no content behind it is useless to a crawler.
This blog went with the third fix. With 49 posts, everything fits on one page, and the list UI can stay as it is.
- /archive (Korean) and /en/archive (English): every post as a plain link, grouped by year
- A link to that page in every page's footer and under the list's "Load more"
After rebuilding, the crawler reached every post: 49/49 Korean and 17/17 English, and the prerendered pages went from 35 to 159. URL Inspection also confirmed /archive as "URL is on Google."
Isn't a sitemap enough?
This blog's sitemap had every post. So even with the "Load more" problem, Google could still discover posts through the sitemap.
But a sitemap is only a list saying "these URLs exist." A post that isn't linked anywhere inside the site gives Google few clues about how important it is. Google's docs also recommend making all content reachable through links, separately from the sitemap. A sitemap supplements your link structure; it doesn't replace it.
To be clear: this "Load more" problem existed from Oct 7 to Oct 13. This blog's index count was low before that, mostly for other reasons (an earlier sitemap bug, a period of server errors, a URL migration). So I can't say "the Load more button is why posts weren't indexed." But left as it was, newly written posts wouldn't have been reachable through links, so I fixed it as soon as I found it during the investigation.
How to read the Search Console statuses is covered in Search Console "Discovered / Crawled - currently not indexed".
Summary
| Remember | Details |
|---|---|
| What crawlers follow | <a> links with href |
| What crawlers don't do | User actions like clicking buttons or scrolling |
| How to check | Count post links in the server HTML (or the rendered HTML in URL Inspection) |
| The fix | Numbered pagination, a "Load more" link, or an all-posts page, so every post is reachable through a link |
When you change a screen, you change not only what people see but also the HTML crawlers see. After changing anything that leads to other pages, like lists or menus, it helps to count the links once.