Do JavaScript links really slow down Google's discovery process?

What happens exactly when Googlebot encounters JavaScript?

Googlebot operates in two phases: it first retrieves the raw HTML returned by the server, scans the links present, and then — after a JavaScript rendering phase — revisits the content enriched by the client. This second pass can occur several hours later, depending on the rendering queue.

If your strategic links only appear after JS execution (e.g., a menu generated via React, SPA navigation), Google detects them only on the second pass. The observed delay is described as “slightly delayed” by Martin Splitt — a vague formulation that deserves scrutiny.

Why is there a distinction between raw HTML and rendering?

Google favors quick discovery via raw HTML because it is less resource-intensive on servers. JavaScript rendering utilizes CPU, memory, and a dedicated queue – hence the time delay.

For an e-commerce site with product listings added daily, this delay may mean new products remain invisible for several hours. Conversely, on a nearly static showcase site, the impact is negligible: a few hours don’t change the overall SEO.

At what page threshold should we be concerned?

Splitt establishes a threshold between 1 and 10 million pages — a range broad enough to be questionable. Below this, he says, “it generally poses no problem.” Above this, silence.

This assertion remains vague: what is the true impact beyond 10M pages? Does a delay extend from a few hours to a few days? A critical crawl budget loss? [To be verified] — Google provides neither precise numbers nor public case studies.

• Two crawl passes: raw HTML first, then JavaScript rendering a few hours later.
• Declared delay: “a few hours” — an imprecise formulation that does not allow for refined anticipation.
• Risk threshold: between 1 and 10 million pages, but no numerical data on the impact beyond.
• Determining context: frequency of new content addition, SPA or hybrid architecture, allocated crawl budget.
• Crawl budget: a massive site with JS links may saturate its rendering queue before all links are discovered.

Is this statement consistent with real-world observations?

Yes and no. On medium-sized sites, it is observed that JS links eventually get crawled without issues. The delay of some hours corresponds to real-world reports — provided the site has no structural problems (JS timeouts, console errors, chain redirects).

However, on platforms with frequent publication (news, flash e-commerce, aggregators), this delay becomes significant. An article published at 9 AM may only be discovered by 2 PM — directly impacting visibility on Google Discover or Top Stories. [To be verified]: Google never specifies whether this delay is unavoidable or if a well-optimized site can speed it up.

What nuances should be added to this threshold of 1 to 10 million pages?

This threshold raises more questions than it answers. Firstly, there is a factor of 10 between the two bounds — hard to make it an actionable rule. Secondly, the number of pages is just one indicator: a site with 500,000 pages with 80% duplicated or thin content will experience more issues than a well-structured site with 5 million pages.

Concretely, the true criterion is not so much the number of pages but the update frequency and the internal link density generated by JS. A media site with 200,000 articles updated every hour via React will be more impacted than a static product catalog of 2 million listings. Google does not say this — but it is what we observe.

When does this rule not apply at all?

Let’s be honest: if your main navigation, breadcrumb, or pagination links are exclusively in JS, the delay becomes a real problem. Googlebot may ultimately discover everything, but it will do so with a latency that penalizes the indexing of new pages.

Another critical case: sites with infinite scroll using Ajax to load subsequent content. Google does not scroll — if the “next page” link exists only in JS and you have no HTML fallback, part of your content remains invisible. Splitt does not mention this, which is curious for a statement intended to reassure.

What concrete steps should be taken to limit this delay?

First rule: don’t put all your eggs in one basket. If your navigation, pagination, or strategic internal linking can exist in raw HTML, do it. Server-side rendering (SSR) or static site generation (SSG) ensures immediate discovery.

Second instinct: test the raw HTML returned by your server. Perform a curl or use “View Page Source” (not the inspector, which shows the final DOM). Are all your critical links present? If not, you depend on JS rendering — and therefore on the delay mentioned by Splitt.

What mistakes should be absolutely avoided?

Don’t rely on Google’s patience. Even if Splitt says “it generally doesn’t pose a problem,” a poorly optimized site accumulates delays: rendering delays, uncaught JS errors, timeouts, client-side redirects. Result: pages take several days to be discovered, or worse, never crawled if they fall outside the budget.

Another classic pitfall: thinking that an XML sitemap is enough to compensate. The sitemap speeds up URL discovery but does not replace a solid internal linking in HTML. If your internal links exist only in JS, internal PageRank circulates poorly — and no sitemap can correct this.

How can I check if my site is being crawled correctly despite JS?

Use Search Console: the “Coverage” section to spot discovered but non-indexed pages, and “URL Inspection” to visualize the final rendering as seen by Google. Compare the raw HTML and the rendered HTML — if the gap is huge, you are in a risk zone.

Simultaneously, monitor the server logs: how long between the first Googlebot request (raw HTML) and the second (rendering)? If this delay regularly exceeds 24 hours, your rendering queue is likely saturated, or Google considers your site low priority. In such cases, optimize: reduce JS weight, fix console errors, switch to partial SSR.

• Audit the raw HTML returned by the server to verify the presence of strategic links
• Favor server-side rendering (SSR) or static site generation (SSG) for critical areas
• Test Google’s rendering via the “URL Inspection” tool in Search Console
• Analyze server logs to measure the actual delay between HTML crawl and rendered crawl
• Never solely rely on the XML sitemap to compensate for weak internal linking
• Monitor JavaScript errors in production — broken JS blocks discovery