Official statement
Other statements from this video 28 ▾
- 1:02 Does Google really render all JavaScript pages, regardless of their architecture?
- 1:02 Does Google really render ALL JavaScript, even without initial server-side content?
- 2:05 How can you ensure that Googlebot is truly crawling your site?
- 2:05 How can you ensure that Googlebot is genuinely Googlebot and not an imposter?
- 2:36 Does Google really limit CPU time during JavaScript rendering?
- 2:36 Is it true that Google actually limits CPU time during JavaScript rendering?
- 3:09 Should we stop optimizing for bots and focus solely on the user?
- 5:17 Does the CSS content-visibility property really affect rendering in Google?
- 8:53 How can you measure Core Web Vitals on Firefox and Safari without native API support?
- 11:00 How long does Google really wait before giving up on JavaScript rendering?
- 11:00 How long does Googlebot really wait for JavaScript rendering?
- 20:07 Why does Google display empty pages even when your JavaScript site is working perfectly?
- 20:07 Does AJAX really work for SEO, or should you think twice before using it?
- 21:10 Can blocking JavaScript really stop Google from indexing all the content on your pages?
- 24:48 Has dynamic prerendering become a trap for indexing?
- 26:25 Could your deleted resources be harming your pre-render indexing?
- 26:47 What does Google really do with your initial HTML before JavaScript rendering?
- 27:59 Is it true that Google ignores JavaScript rendering if your noindex tag appears in the initial HTML?
- 27:59 Could a 404 page with JavaScript lead to the complete deindexing of your site?
- 28:30 Why does Google refuse to render JavaScript if the initial HTML contains a meta noindex?
- 30:00 Does Google really compare the initial HTML AND rendered content for canonicalization?
- 30:01 Does Google really catch duplicate content after JavaScript rendering?
- 31:36 Are GET APIs really cached by Google just like any other resource?
- 31:36 Does Google really ignore POST requests during JavaScript rendering?
- 34:47 Does Google really index all pages after JavaScript rendering?
- 35:19 Does Google really render 100% of JavaScript pages before indexing?
- 36:51 How do your failing APIs sabotage your Google indexing?
- 37:12 Are structured data on noindexed pages really lost to Google?
Google extracts links, HTTP errors, and meta tags from the initial HTML, before even executing JavaScript. Canonicalization starts at this stage but is not fixed: it continues after rendering. In practice, what you place in the static HTML counts immediately for crawling and discovery, while canonicalization remains an evolving process over which you have only partial control.
What you need to understand
What’s the difference between initial HTML and HTML after rendering?
The initial HTML refers to the raw code sent by your server, before the browser (or Googlebot) executes any JavaScript. This is what you see in the "View Source" tab of your browser.
The HTML after rendering is the final result once JavaScript has modified the DOM: adding dynamic content, injecting links, changing meta tags. Google first crawls the initial HTML, then queues the page for JavaScript rendering—a process that can take seconds, hours, or even days depending on the crawl budget and the page's priority.
Why does Google analyze the initial HTML first?
Because it's immediate and resource-efficient. Google doesn't have to mobilize Chromium to read a raw HTML file. This step quickly allows detection of HTTP errors (404, 500, redirects), extracting links to feed the crawl queue, and reading meta directives (canonical, robots, description).
If Google had to wait for JavaScript rendering to discover every new link, crawling would be catastrophically slow. Thus, analyzing the initial HTML serves as a first-instance filter: fast, effective, but partial. That’s why critical links must be in the static HTML, not injected in JS afterward.
Does canonicalization start in the initial HTML—but continue after?
Google reads your <link rel="canonical"> tag from the initial HTML and registers this directive. But it's just one signal among others: redirects, sitemaps, internal links, and even the declared canonical after JavaScript rendering can influence the final decision.
In other words, what you put in the initial HTML matters, but Google reserves the right to reevaluate after rendering. If your JavaScript modifies the canonical or adds client-side redirects, Google will consider that—but with a potential delay and no guarantee that this signal will prevail over others.
- Google first crawls the initial HTML to extract links, HTTP errors, and meta tags
- Links in static HTML are discovered immediately; those injected in JS may wait for days
- Canonicalization starts with the canonical tag in the initial HTML, but is not fixed
- Meta robots directives in the initial HTML are prioritized—no need to wait for rendering to block indexing
- JavaScript rendering is a separate and slower process: don’t rely solely on it for critical signals
SEO Expert opinion
Is this statement consistent with field observations?
Yes, and it’s even a welcome confirmation. For years, we've observed that static HTML links are crawled faster than those injected via JavaScript. Tests with React or Vue.js sites consistently show a delay between initial crawl and post-render crawl—a delay that can range from a few hours to several weeks for low-priority pages.
What's more interesting is that Martin Splitt confirms that canonicalization is not binary. Many SEOs still think a canonical tag in initial HTML is definitive. However, Google reevaluates this directive after rendering and can even ignore it if other signals (redirects, internal links, sitemaps) point to a different URL. [To verify]: the exact priority order between initial HTML canonical, post-render canonical, and other signals remains unclear in this statement.
What nuances should be added to this claim?
The fact that Google reads meta tags in initial HTML doesn’t mean it systematically respects them. A noindex meta tag will generally be honored right from the initial HTML, but a meta description might be replaced by a dynamically generated snippet, even if you've set it in stone.
Another point: Google doesn’t say how long it takes for JavaScript rendering to be taken into consideration. If your canonical is in the initial HTML but your main content is injected via JS, you’re in a gray area—Google might index an empty shell while waiting to render the page, or it might wait for the complete render before indexing. Nothing is guaranteed.
In what cases can this rule cause issues?
If your site is a SPA (Single Page Application) and you're relying solely on JavaScript rendering to define your canonicals, you're taking a risk. Google may index an incomplete version of the page with a wrong canonical from the initial template, even before it has rendered the JS that injects the correct canonical.
Similarly, if you have intermittent HTTP errors (server temporarily returning a 500), Google might detect these in the initial HTML and decide not to queue the page for rendering—you then lose all the JS-injected content. That’s why a stable server is an absolute prerequisite for JavaScript-heavy sites.
Practical impact and recommendations
What practical steps should you take to ensure Google reads your initial HTML correctly?
First priority: place your critical links in static HTML. Pagination, main navigation, links to strategic pages—everything that needs to be crawled quickly should not rely on JavaScript. Use a tool like Screaming Frog in "Text Only" mode to check what Google sees without rendering.
Next, ensure your canonical tags, meta robots, and meta descriptions are present from the initial HTML. If you’re using a JavaScript framework (Next.js, Nuxt, Gatsby), set up SSR (Server-Side Rendering) or SSG (Static Site Generation) so these tags are in the HTML returned by the server, not injected client-side.
What mistakes should you absolutely avoid?
Don’t rely on JavaScript to block indexing. If you want a noindex, put it in the initial HTML—ideally via an HTTP header X-Robots-Tag: noindex, which is read even earlier than the HTML. A noindex injected in JS may never be seen if Google doesn’t render the page.
Another classic error: defining a different canonical between initial HTML and JavaScript rendering. You might think that rendering takes precedence, but Google could well retain the first canonical it read or choose a third URL if the signals are too contradictory. Stay consistent.
How can you check if your configuration is correct?
Use Google Search Console, URL Inspection tab, and compare raw HTML ("More info" tab > "HTML returned") with rendered HTML ("Rendered page" tab). If your canonical tags, meta robots, or critical links differ in both versions, you have a problem.
Also test with curl or a tool like Postman: make a raw HTTP request to your page and check that essential tags are present. If they only appear in the browser, it means JavaScript injects them—and Google will see them later, if it ever sees them.
- Place all critical navigation links in initial HTML, not in JavaScript
- Define canonical, meta robots, and meta description as early as possible in static HTML (SSR/SSG)
- Check with Screaming Frog in "Text Only" mode what Google sees without rendering
- Use the URL Inspection tool from Search Console to compare initial HTML and rendered HTML
- Avoid conflicting canonicals between initial HTML and JavaScript
- Prefer HTTP headers
X-Robots-Tagfor critical directives (noindex, nofollow)
❓ Frequently Asked Questions
Google lit-il la balise canonical dans le HTML initial ou après le rendu JavaScript ?
Les liens injectés en JavaScript sont-ils découverts aussi vite que ceux dans le HTML statique ?
Un meta robots noindex en JavaScript est-il pris en compte par Google ?
Comment savoir si Google a rendu ma page JavaScript ou s'il s'est arrêté au HTML initial ?
Google peut-il détecter une erreur 500 dans le HTML initial même si le contenu se charge ensuite en JavaScript ?
🎥 From the same video 28
Other SEO insights extracted from this same Google Search Central video · duration 46 min · published on 25/11/2020
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.