Area
Rendering and JavaScript
How Google renders JavaScript pages, what keeps content out of the rendered HTML, how to debug it, and how embedded apps fit in.
Topics in this area 5
69 claims · 5 sessions
How Google renders pages
Google renders nearly all pages with headless Chromium to index what users see, said it would miss most of today's web without it, and, extending Day 1's point that Gemini uses Google's crawling, said pages are rendered the same way for Gemini training (said at the event, not in Google's docs). Rendering is a detached, expensive system that fetches JavaScript, CSS and API calls, but not images or videos, through the crawler; Google's documentation queues every page that returns 200 unless it carries noindex, and content missing from the final DOM cannot be indexed. The renderer does not scroll or click and lacks permission-based browser APIs and WebGL; Google said it renders in a viewport about 10,000 pixels tall instead, a figure its documentation does not give (it speaks of a 'viewport expansion' that can miss infinite content). The documentation sets no upper limit on the render-queue wait (a community speaker said seconds to a couple of minutes), and Google said content can be missing because it has not appeared in time; a community speaker added that slow APIs can leave unresolved placeholders in the snapshot. Author’s view: Erin Sparling's remark that content indexable without JavaScript 'can pass through without rendering' does not mean such pages skip rendering; it means content in the raw HTML does not wait for the slower rendering pass. Day 3 put rendering in time: Google renders a page either right after crawling or later through a queue, so content added by JavaScript is typically seen by indexing within a few hours and at worst within weeks, and Google said its logs show everything in the queue rendered within weeks (said at the event). Google's own speaker also said he would not claim that Google renders every URL on the internet (not in Google's docs). Author’s view: Google's JavaScript guide says every page returning 200 is queued for rendering, and queued is not rendered, so critical content belongs in the server HTML. Day 1's second recording added that Google renders JavaScript-heavy pages from their HTML, CSS and JavaScript as a browser would, with the latest Chromium. A second recording of Day 2 confirmed Natalia Venditto's point that a server-rendered app reframed into the host page is fully indexable (said at the event), and John Mueller said Google drops a page with a noindex in its HTML without processing its JavaScript, while Google's guide says it may skip rendering.
Day 1Day 2Day 3
124 claims · 8 sessions
JavaScript SEO pitfalls and fixes
Google's four common JavaScript indexing problems were content missing from the rendered HTML (the most common), # URLs, soft 404s and blocked resources; content goes missing when Googlebot cannot access the JavaScript, when it waits for a click or other DOM event, when it needs a disabled browser API, or when it appears too late. Single-page apps that return 200 for unknown routes create soft 404s, extending Day 1's soft 404 problem; Google's documented fixes are a real 404 or, where that is impractical, a JavaScript redirect to a URL that returns 404 or a noindex added with JavaScript, whereas removing a noindex with JavaScript does not work. Blocking script or API paths in robots.txt, on the page's host or on a separate API host, stops the renderer running them; Google recommended fast-rendering JavaScript, server-side or hybrid rendering, fallbacks, differential serving and polyfills, and called renderable content important today and tomorrow as AI systems increasingly ground answers, which extends Day 1's advice to keep content crawlable for AI tools. Community speakers added blind spots Google's documentation does not cover: prices and offers that differ between raw and rendered HTML, timeout placeholders that hit different pages each time, Content Security Policy blocks, pages that render blank while the raw HTML looks fine, and per-session-billed tools that also run for bot renders, which one speaker said can cost a high-traffic site thousands of euros a month. One community speaker urged putting everything you want AI systems to cite into server-rendered HTML, because some cannot render JavaScript yet. Day 3 put the delay in numbers: content added by JavaScript is typically seen by Google's indexing within a few hours and at worst within weeks, and Google's own speaker doubted that every URL gets rendered (said at the event). Author’s view: Google's JavaScript guide says every page returning 200 is queued for rendering, but queued is not rendered, so critical content, links and meta tags belong in the server HTML. A second recording of Day 2 confirmed several of these points: a client-rendered page that renders empty for Google is seen as thin content before it becomes a soft 404, the product links in the debugging example sat behind onclick handlers, and when the JavaScript is not accessible parts of a page may render while the main content is absent. John Mueller added that when Google finds a noindex in the HTML it drops the page without processing its JavaScript, so robots meta tags belong in the HTML exactly as intended; Google's guide says it may skip rendering. In the retail example the rendered page promised a bigger newsletter discount than the raw HTML (the two recordings disagree on the figures), and a community speaker warned that a Content Security Policy blocking a video on a key landing page could hurt a purely online business badly. In the Day 1 Q&A, captured by an audio recording, Google said as a fun fact that JavaScript was used for the language-consolidation redirects in its own site migration, because it was the only option available to the person doing it. Author’s view: Google's redirects guide says Google Search follows JavaScript redirects only after rendering and may never see one if rendering fails, so use them only when server-side or meta refresh redirects are impossible.
Day 1Day 2Day 3
19 claims · 2 sessions
Lazy loading and content behind interactions
Day 2 confirms Day 1's point that Google's crawlers do not click and adds that they do not scroll either: content that loads only after a click or a scroll is not in the DOM when Google renders the page, so it cannot be indexed. What counts is presence in the DOM, not visibility: tab or accordion content hidden with CSS or the hidden attribute can be indexed, while tab content fetched from an API on click does not exist for Google. Instead of scrolling, Google renders in a tall viewport, about 10,000 pixels according to Google's speaker (a figure not in the documentation, which calls it viewport expansion and warns it can miss infinite content), so content loaded when an element enters the viewport, for example with an Intersection Observer, loads while scroll-event listeners never run. For infinite scroll, Google's lazy-loading guide asks for paginated loading, with a persistent URL for each chunk, sequential links between them and the History API updating the displayed URL, a concrete pattern to go with Day 1's caution that 'load more' pagination is risky.
Day 2
43 claims · 2 sessions
Debugging rendering
Day 2's advice on debugging rendering came mostly from community lightning talks: compare a page's raw HTML with its rendered HTML, and treat the rendered HTML in Search Console's URL Inspection tool or the Rich Results Test as the closest view of what Google indexes. Google's documentation adds two limits: the live test runs in real time and can differ from the indexed version, and a valid live test shows only that Google can access the page, not that it will be indexed. To trace missing content, community speaker Rebecca Yu filtered Chrome DevTools' Network tab to Fetch/XHR, checked whether each request runs, is blocked or is disallowed in robots.txt, then searched the source for a string from the missing content; another advised reading browser console messages at scale, where Content Security Policy violations show up. Because placeholder failures from rendering timeouts come and go between pages, a community speaker recommended archiving each page's full HTML and resources during audits, and monitoring the rendered output of sites that build their content by rendering. Google's Erin Sparling suggested putting AI agents on rendering problems only after your own due diligence. Google's documentation also says its renderer may skip non-essential requests such as analytics and error reporting, so client-side analytics may not give a full or accurate picture of Googlebot's activity. Sören Bendig, who opened the community talks, said JavaScript-heavy sites share common blind spots because these features break in subtle ways, that none of the problems he showed on established brands' sites had been fixed promptly, and advised checking rendering at scale with a modern crawler as well as in Chrome DevTools.
Day 2
40 claims · 2 sessions
Embedding apps safely: Web Fragments
Web Fragments came from a community lightning talk by Natalia Venditto (Adobe), not from Google: a library for embedding apps, including AI-generated ones, in a host page without global JavaScript collisions, CSS bleed or fate sharing, where an error in the embedded app breaks the host. Her comparison slide said an iframe isolates scripts and styles but is walled off from the page's DOM, navigation and layout, shadow DOM isolates styles but shares JavaScript globals, and a rewrite means isolating by hand; Web Fragments meets all three criteria but needs browser patches today. It runs the embedded app's JavaScript in a hidden iframe, places its DOM in a shadow root of the host page, loads assets through a gateway from a standalone endpoint and virtualizes APIs such as document, history and location; the team backs the ShadowRealm standard proposal, which she said was at stage 2.7 at the time of the talk. None of this is in Google's documentation, which says Google flattens shadow DOM when rendering and generally, but not always, indexes iframe content as part of the embedding page. Author’s view: content in a fragment's shadow root can be indexed with the host page only if it shows in the rendered HTML, so test such pages in URL Inspection and keep the fragment's asset URLs crawlable. A second recording of Day 2 made her deployment advice clear: she recommended server-rendering web fragments, said a server-rendered app reframed into the host page is fully indexable, and reported an enormous performance increase (no figure given) when an app is reframed inside a fully client-side host, because it is rendered and interactive immediately (all said at the event).
Day 2
Across days 34
- Stage D2-C118 Day 2 · Lightning session D: Rendering and JavaScript
To train Gemini models, Google renders every page just as it does for Search, so a page that renders correctly for Search also works for Gemini training, provided the site allows its content to be used for training.
extendsD1-C039 Day 1 · How Search works and where's AI?Gemini is not part of Search, but it uses crawlers for data, shares some technologies such as tokenization and deduping, and grounds on the Search index.
- Stage D2-C124 Day 2 · Lightning session D: Rendering and JavaScript
Google's simple solution for the extra time of live page reads is to make JavaScript-generated content render quickly and efficiently, or to use server-side rendering.
extendsD1-C056 Day 1 · How Search works and where's AI?Myth: your website is no longer relevant. Google's answer: keep content crawlable, well structured, fast and easy to read, for readers and for AI tools.
- D2-C127 Day 2 · Lightning session D: Rendering and JavaScript
A Google pipeline diagram ran from the crawl queue to the crawler, then through HTML parsing to processing, which passes pages to rendering and gets them back, and then to the index; rendering fetches its JavaScript and CSS through the crawler.
extendsD1-C063 Day 1 · How crawling worksThe crawl pipeline runs from a crawl queue to a scheduler to the crawler, which fetches from the internet and passes the fetch reply to indexing.
- Stage D2-C134 Day 2 · Lightning session D: Rendering and JavaScript
Google urged sites to make sure their JavaScript content can be crawled, rendered and indexed, calling this important today and also tomorrow, as AI systems increasingly ground answers to user requests.
extendsD1-C056 Day 1 · How Search works and where's AI?Myth: your website is no longer relevant. Google's answer: keep content crawlable, well structured, fast and easy to read, for readers and for AI tools.
- Stage D2-C136 Day 2 · Lightning session D: Rendering and JavaScript
Many SEOs still treat everything beyond the raw HTML as the developers' business, but developers often do not handle rendering problems, a community speaker warned.
extends - Stage D2-C139 Day 2 · Lightning session D: Rendering and JavaScript
A community speaker strongly advised putting everything you want cited into the raw, server-side rendered HTML, especially for AI systems that cannot render JavaScript yet.
extendsD1-C056 Day 1 · How Search works and where's AI?Myth: your website is no longer relevant. Google's answer: keep content crawlable, well structured, fast and easy to read, for readers and for AI tools.
- D2-C167 Day 2 · Lightning session D: Rendering and JavaScript
The diagram from Google's JavaScript SEO basics page shows a URL going from the crawl queue to the crawler, the crawled HTML going to processing, then the render queue and the renderer, whose rendered HTML returns to processing before the page reaches the index.
extendsD1-C063 Day 1 · How crawling worksThe crawl pipeline runs from a crawl queue to a scheduler to the crawler, which fetches from the internet and passes the fetch reply to indexing.
- Docs D2-C169 Day 2 · Lightning session D: Rendering and JavaScript
Google's JavaScript SEO basics guide says Googlebot extracts links twice, from the HTML response before rendering and again from the rendered HTML, so links injected with JavaScript can be found if they use crawlable <a href> markup.
extendsD1-C040 Day 1 · How Search works and where's AI?URL discovery works through links: a homepage links to section pages, which link to further pages.
- Stage D2-C173 Day 2 · Lightning session D: Rendering and JavaScript
Google's renderer is a headless Chromium that runs the page's JavaScript.
extendsStage D1-C206 Day 1 · How Search works and where's AI?Google renders JavaScript-heavy pages from their HTML, CSS and JavaScript as a browser would, using the latest version of Chromium.
- D2-C184 Day 2 · Lightning session D: Rendering and JavaScript
Google follows links in <a href> elements; a link that only runs an onclick handler, or a hash pseudo-link such as href=#/products, may be invisible to Google.
extendsDocs D1-C115 Day 1 · session not recordedGoogle's crawlers do not click buttons. Each page in a series needs its own URL and an <a href> link to the next page, should not use page 1 as its canonical, and rel=next and rel=prev are no longer used.
- Stage D2-C190 Day 2 · Lightning session D: Rendering and JavaScript
In single-page apps, a missing page often shows a custom 404 page while the server returns HTTP 200, because the front-end router, not the server, handles the 404.
extendsDocs D1-C073 Day 1 · How crawling errors affect SearchA soft 404 is a page that returns a success code while its content looks like an error or an empty page. It is kept out of the index but continues to be crawled, wasting crawl budget.
- D2-C195 Day 2 · Lightning session D: Rendering and JavaScript
Content that loads only after a user action such as a click or a scroll is not in the DOM while Google renders the page, so Google cannot index it.
extendsDocs D1-C115 Day 1 · session not recordedGoogle's crawlers do not click buttons. Each page in a series needs its own URL and an <a href> link to the next page, should not use page 1 as its canonical, and rel=next and rel=prev are no longer used.
- D2-C197 Day 2 · Lightning session D: Rendering and JavaScript
Lazy loading triggered by a scroll event listener, such as window.addEventListener('scroll', loadMoreProducts), never runs for Googlebot because Googlebot does not scroll.
extends - D2-C201 Day 2 · Lightning session D: Rendering and JavaScript
Tab or accordion content fetched from an API only when a user clicks the tab, as in tab.onclick = () => fetch('/api/specs'), does not exist for Google until someone clicks.
extendsDocs D1-C115 Day 1 · session not recordedGoogle's crawlers do not click buttons. Each page in a series needs its own URL and an <a href> link to the next page, should not use page 1 as its canonical, and rel=next and rel=prev are no longer used.
- D2-C204 Day 2 · Lightning session D: Rendering and JavaScript
Blocking JavaScript or API resources in robots.txt is a classic rendering mistake: if Google's renderer cannot fetch a resource, it cannot run it.
extendsD1-C064 Day 1 · How crawling worksThe crawler has multiple tasks: fetch from the internet, ensure it doesn't break the internet, and enforce robots.txt policies. Fetched data is sent for indexing.
- Analysis D2-C208 Day 2 · Lightning session D: Rendering and JavaScript
A robots.txt carve-out works because Google applies the most specific matching rule, so Allow: /api/products/ beats Disallow: /api/ for product endpoints only; re-test a rendered page after every robots.txt change to script or API paths.
extendsDocs D1-C081 Day 1 · How Google interprets robots.txtWhen matching rules to a URL, Google uses the most specific rule by path length. If rules conflict, it uses the least restrictive one.
- Analysis D2-C210 Day 2 · Lightning session D: Rendering and JavaScript
An API or CDN on its own host needs its own robots.txt check: a blanket Disallow there, or a robots.txt that returns 5xx errors, can stop Google fetching the data a page renders from.
extendsDocs D1-C074 Day 1 · How crawling errors affect SearchIf robots.txt returns a 5xx error, Google stops crawling the site for the first 12 hours, then uses the cached copy for up to 30 days.
- Stage D2-C213 Day 2 · Lightning session D: Rendering and JavaScript
A page that renders empty for Google, such as a client-side product page hit by these mistakes, is seen as thin content and ends up treated as a soft 404 even though users see a full page.
extendsDocs D1-C073 Day 1 · How crawling errors affect SearchA soft 404 is a page that returns a success code while its content looks like an error or an empty page. It is kept out of the index but continues to be crawled, wasting crawl budget.
- Stage D2-C268 Day 2 · What is Google friendly JavaScript
Content that loads only when a user clicks an element is not supported in the way Google renders pages for indexing.
extendsDocs D1-C115 Day 1 · session not recordedGoogle's crawlers do not click buttons. Each page in a series needs its own URL and an <a href> link to the next page, should not use page 1 as its canonical, and rel=next and rel=prev are no longer used.
- Stage D2-C271 Day 2 · What is Google friendly JavaScript
Google does not scroll a page when it renders it for indexing, so content that infinite scroll loads on scroll-depth triggers works for users but is never loaded for Google.
extends - Stage D2-C271 Day 2 · What is Google friendly JavaScript
Google does not scroll a page when it renders it for indexing, so content that infinite scroll loads on scroll-depth triggers works for users but is never loaded for Google.
extends - Docs D2-C276 Day 2 · What is Google friendly JavaScript
To make infinite scroll indexable, Google's lazy-loading guide says to support paginated loading: give each chunk its own persistent, unique URL, link sequentially to those URLs, and update the displayed URL with the History API when a new chunk becomes the main visible element.
extendsDocs D1-C115 Day 1 · session not recordedGoogle's crawlers do not click buttons. Each page in a series needs its own URL and an <a href> link to the next page, should not use page 1 as its canonical, and rel=next and rel=prev are no longer used.
- Stage D2-C291 Day 2 · What is Google friendly JavaScript
In JavaScript single-page apps, soft 404s typically arise because the server returns the app with a 200 status for every URL, so when the app shows a 'not found' message for a URL that does not exist, no error is reported.
extendsDocs D1-C073 Day 1 · How crawling errors affect SearchA soft 404 is a page that returns a success code while its content looks like an error or an empty page. It is kept out of the index but continues to be crawled, wasting crawl budget.
- Stage D2-C296 Day 2 · What is Google friendly JavaScript
If robots.txt blocks JavaScript that client-side code needs to render, Google cannot render the content that the JavaScript would produce.
extendsD1-C064 Day 1 · How crawling worksThe crawler has multiple tasks: fetch from the internet, ensure it doesn't break the internet, and enforce robots.txt policies. Fetched data is sent for indexing.
- Stage D2-C303 Day 2 · What is Google friendly JavaScript
Combining schema-based interfaces with web standards such as WebMCP lets a site expose tools to AI agents, which can then operate the interfaces, for example to test them.
extendsStage D1-C281 Day 1 · Lightning session A: Automation and AIA community speaker presented WebMCP (Web Model Context Protocol) as a way for a site to declare the actions it offers to AI agents, for example booking an appointment in a calendar, so an agent does not have to scrape the interface; the speaker called it faster, easier and cheaper.
- D2-C336 Day 2 · Understanding what's on a page
Google listed four common causes of soft 404s: pages that look like errors but are not, thin or empty content, server or CMS misconfigurations, and JavaScript-dependent content that fails to load.
extendsDocs D1-C073 Day 1 · How crawling errors affect SearchA soft 404 is a page that returns a success code while its content looks like an error or an empty page. It is kept out of the index but continues to be crawled, wasting crawl budget.
- Stage D3-C626 Day 3 · How long does it take to..?
Google renders pages in two ways: immediately after crawling, or later through a queue-based process that runs elsewhere.
extendsD2-C170 Day 2 · Lightning session D: Rendering and JavaScriptAfter processing, an indexable page is placed in Google's render queue to wait for rendering.
- Stage D3-C627 Day 3 · How long does it take to..?
Content that JavaScript adds to a page is typically seen by Google's indexing system within a few hours, and at worst within weeks.
extendsDocs D2-C172 Day 2 · Lightning session D: Rendering and JavaScriptGoogle's JavaScript SEO basics guide says a page may wait in the render queue for a few seconds but that it can take longer, and it gives no upper limit.
- Stage D3-C628 Day 3 · How long does it take to..?
Gary Illyes said Google keeps saying it renders every URL on the internet and that he would say this is not true, though it is what he was told; he went on to say that Google's logs show the rendering queue cleared within weeks.
extendsStage D2-C256 Day 2 · What is Google friendly JavaScriptGoogle renders nearly all of the web by replicating what a browser does, using a real browser's rendering engine.
- Analysis D3-C676 Day 3 · How long does it take to..?
The stage doubt that every URL gets rendered sits beside Google's JavaScript guide, which says every page with a 200 status is queued for rendering unless a robots rule blocks indexing: queued is not the same as rendered, so do not rely on rendering for critical content.
extendsDocs D2-C131 Day 2 · Lightning session D: Rendering and JavaScriptGoogle's JavaScript SEO guide says Googlebot sends every page with a 200 HTTP status code to the rendering queue, whether or not it contains JavaScript, unless a robots meta tag or header tells Google not to index it, and Google uses the rendered HTML to index the page.
- D2-C040 Day 2 · How is HTML interpreted
Google cannot extract a link from an a element that only has an onclick handler, because Googlebot does not click, so the JavaScript is never triggered.
repeatsDocs D1-C115 Day 1 · session not recordedGoogle's crawlers do not click buttons. Each page in a series needs its own URL and an <a href> link to the next page, should not use page 1 as its canonical, and rel=next and rel=prev are no longer used.
- Stage D2-C126 Day 2 · Lightning session D: Rendering and JavaScript
Google renders pages with Chromium, the browser technology that also underlies Chrome, Edge and other Chromium-based browsers.
repeatsStage D1-C206 Day 1 · How Search works and where's AI?Google renders JavaScript-heavy pages from their HTML, CSS and JavaScript as a browser would, using the latest version of Chromium.
- D2-C264 Day 2 · What is Google friendly JavaScript
Google's slide defined a soft 404 in a JavaScript application as a page that serves a 'Not Found' message but returns a 200 HTTP status code.
repeatsDocs D1-C073 Day 1 · How crawling errors affect SearchA soft 404 is a page that returns a success code while its content looks like an error or an empty page. It is kept out of the index but continues to be crawled, wasting crawl budget.
- D2-C284 Day 2 · What is Google friendly JavaScript
URL fragments (#) are often ignored by crawlers: a fragment exists only in the browser, so Google cannot request it.
repeatsDocs D1-C101 Day 1 · How Google thinks about crawl budgetGoogle's faceted navigation guide prefers prevention: disallow filter URLs in robots.txt and keep crawlable only item pages plus one unfiltered listing page, or use URL fragments, which Google generally does not crawl. rel=canonical and nofollow are weaker, slower options.