Knowledge base v2.13.0 · Community edition · data through 2 October 2026
Day 2 · Thursday 1 October 2026 · 10:40
Four parts: a short Google opener by Erin Sparling (Partner Technology Manager, Google), then community talks by Sören Bendig (CEO, Audisto) on rendering blind spots, Rebecca Yu (SEO Manager, JAKALA) on debugging JavaScript rendering, and Natalia Venditto (Principal Software Engineer, Adobe) on Web Fragments.
Google renders pages in order to index what users see: its commitment to reflecting the user experience means understanding what people see when a page loads in a browser and surfacing that in Search.
“Rendering Pages to Index What Users See”
Wording checked against the slide or recording
Speaker Erin SparlingEvidence slide photo, transcript
Used byglossary term Rendering
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.
Speaker Erin SparlingEvidence slide photo, transcript
The first rendering blind spot a community speaker showed was content changes: text, images and recommendations that differ between the raw HTML and the rendered page, illustrated by a shop page whose rendered version had a whole extra section.
Speaker Sören BendigEvidence slide photo, transcript
Used byrequirement DEV-REN-07
A community speaker summarised five rendering blind spots to check: content and markup changes, invisible links, rendering timeouts, Content Security Policy and blocked resources.
Speaker Sören BendigEvidence slide photo
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.
Speaker Rebecca YuEvidence slide photo, transcript
In Google's processing step, links are extracted from the HTML Google already has, before rendering, and the URLs found go back to the crawl queue.
Speaker Rebecca YuEvidence slide photo, transcript
After processing, an indexable page is placed in Google's render queue to wait for rendering.
Speaker Rebecca YuEvidence slide photo, transcript
Used byglossary term Render queue
A community speaker's slide put the usual wait in Google's render queue at seconds to a couple of minutes per page.
“Usually from seconds to a couple minutes.”
Wording checked against the slide or recording
Speaker Rebecca YuEvidence slide photo
Whatever is in the DOM at the moment Google's rendering finishes is what likely gets indexed.
“Whatever is in the DOM at that moment is what likely gets indexed.”
Wording checked against the slide or recording
Speaker Rebecca YuEvidence slide photo, transcript
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.
Speaker Rebecca YuEvidence slide photo, transcript
Used byrequirement DEV-URL-02
The crawlable pattern for single-page app navigation is a real URL in the href, such as <a href=/products>, combined with History API routing (window.history.pushState) instead of hash routes.
Speaker Rebecca YuEvidence slide photo
Used byrequirement DEV-URL-03
A market or language selector built as a button works for users but leaves the whole cluster of alternate-language pages without crawlable links, so the cluster is orphaned for Google.
“The nav works perfectly for users, and the entire alternate-language cluster is orphaned.”
Wording checked against the slide or recording
Speaker Rebecca YuEvidence slide photo
Used byrequirement DEV-INT-06
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.
Speaker Rebecca YuEvidence slide photo, transcript
Used byrequirement DEV-REN-02
For rendering, what matters is whether content is present in the DOM, not whether it is visible on screen: hidden content can be indexed, absent content cannot.
“Not visible versus hidden. Present versus absent in the DOM.”
Wording checked against the slide or recording
Speaker Rebecca YuEvidence slide photo
Used byrequirement DEV-REN-02
Lazy loading triggered by a scroll event listener, such as window.addEventListener('scroll', loadMoreProducts), never runs for Googlebot because Googlebot does not scroll.
“Googlebot doesn't scroll. Never runs.”
Wording checked against the slide or recording
Speaker Rebecca YuEvidence slide photo, transcript
Used byrequirement DEV-REN-03glossary term Lazy loading
Lazy loading should be triggered by an Intersection Observer that watches a sentinel element instead of by a scroll event listener.
Speaker Rebecca YuEvidence slide photo, transcript
Used byrequirement DEV-REN-03glossary term Lazy loading
An Intersection Observer fires when the observed element enters the viewport, and the viewport Google renders with is tall, so content lazy-loaded this way can load during rendering.
“Fires on viewport entry. Viewport is tall.”
Wording checked against the slide or recording
Speaker Rebecca YuEvidence slide photo
Used byrequirement DEV-REN-03
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.
“Doesn't exist until someone clicks”
Wording checked against the slide or recording
Speaker Rebecca YuEvidence slide photo
Used byrequirement DEV-REN-02
Tab and accordion content should be in the DOM from the start and only hidden with CSS or the hidden attribute; Google indexes such hidden content.
“CSS-hidden is fine. Google indexes it.”
Wording checked against the slide or recording
Speaker Rebecca YuEvidence slide photo, transcript
Used byrequirement DEV-REN-02
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.
“If the renderer can't fetch it, the renderer can't run it.”
Wording checked against the slide or recording
Speaker Rebecca YuEvidence slide photo, transcript
Used byrequirement DEV-REN-04
Disallowing a script folder such as /static/js/ or a generic /api/ folder in robots.txt can block the endpoints that supply a page's content, leaving blank modules and missing content after rendering.
Speaker Rebecca YuEvidence slide photo, transcript
If an API folder must stay blocked in robots.txt, allow the endpoints that rendering needs, for example Disallow: /api/ together with Allow: /api/products/.
“Carve out only what rendering needs.”
Wording checked against the slide or recording
Speaker Rebecca YuEvidence slide photo, transcript
Used byrequirement DEV-REN-04
robots.txt rules apply per host, so the rules in example.com/robots.txt do not apply at all to an API served from api.example.com.
Speaker Rebecca YuEvidence slide photo
Used byrequirement DEV-SRV-04glossary term robots.txt
A slide titled Orchestration approaches compared four ways to combine micro-frontends in one page (iframe, Shadow DOM, rewriting everything, and reframing with Web Fragments) on three criteria (JavaScript isolated, styles isolated, part of the page) and named the catch of each.
Speaker Natalia VendittoEvidence slide photo, transcript
An iframe, the long-established way to embed an app, isolates both JavaScript and styles but is not part of the page: it is walled off from the host's DOM, navigation and layout, which Natalia Venditto said brings many problems with accessibility, layout and navigation.
“Walled off from DOM, navigation, layout”
Wording checked against the slide or recording
Speaker Natalia VendittoEvidence slide photo, transcript
Shadow DOM isolates styles and keeps the embedded content part of the page, but it does not isolate JavaScript: the embedded code still shares the host's JavaScript globals.
“Still shares JS globals”
Wording checked against the slide or recording
Speaker Natalia VendittoEvidence slide photo, transcript
Used byglossary term Shadow DOM
Rewriting everything into one application keeps the result part of the page, but JavaScript and style isolation then have to be done by hand.
Speaker Natalia VendittoEvidence slide photo, transcript
The catch the comparison slide gave for rewriting everything was that you cannot rewrite code you did not write; Natalia Venditto explained that AI cannot rewrite code already in place because it does not know its requirements, design system or other constraints.
“Can't rewrite code you didn't write”
Wording checked against the slide or recording
Speaker Natalia VendittoEvidence slide photo, transcript
Reframing with Web Fragments was the only approach on the comparison slide ticked for all three criteria (JavaScript isolated, styles isolated, part of the page); its stated catch is that it relies on browser patches today.
“Needs patches today”
Wording checked against the slide or recording
Speaker Natalia VendittoEvidence slide photo, transcript
A slide set out Web Fragments in five steps: an LLM writes the app and adds a custom element such as <web-fragment fragment-id="some-id"> to the HTML, a standalone HTTP endpoint is set up, the library is imported and initialized with initializeWebFragments(), the fragment is registered in the gateway, and step 5 is a celebration emoji.
Speaker Natalia VendittoEvidence slide photo, transcript
A web fragment is served from its own standalone HTTP endpoint, so the embedded app can be deployed anywhere, separately from the host page.
Speaker Natalia VendittoEvidence slide photo, transcript
Google framed rendering historically: when Google started, most of the web was plain, semantic HTML it could extract directly, but the modern web is built with JavaScript and much content is generated by JavaScript, so Google had to adapt.
Speaker Erin SparlingEvidence transcript
Without its ability to render JavaScript, Google says it would not be able to see most of what is on the web today.
Speaker Erin SparlingEvidence transcript
Compared with other search engines and AI crawlers, Google said its effort to mimic what the user sees is essential to keeping its knowledge of the web up to date and comprehensive; it did not say what the others do.
Speaker Erin SparlingEvidence transcript
Being able to render and read JavaScript matters whether the client fetching a page is a search crawler or an AI system, Google said.
Speaker Erin SparlingEvidence transcript
Google described the mission of its rendering as simply executing JavaScript, while the implementation is complex, expensive and difficult.
“our mission is very simple these days: execute JavaScript”
Speaker Erin SparlingEvidence transcript
AI Overviews and AI Mode are built on top of Search results: they are a different experience of the same content Google already has.
Speaker Erin SparlingEvidence transcript
Used bystory angle A-001
AI Overviews and AI Mode typically do not ground their answers by reading pages live, unlike Gemini when a user asks about a specific page, Google said.
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-PRF-02
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.
“if it works for Search, it works for Gemini for training”
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-IDX-11
When a Gemini user asks about a specific web page (for example, whether it says anything about the ruby HTML tag), the page is read at that moment rather than during crawling and may be used to ground the answer, which takes extra time.
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-PRF-02
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.
Speaker Erin SparlingEvidence transcript
Used byrequirements DEV-PRF-02, DEV-REN-01
Google renders pages with Chromium, the browser technology that also underlies Chrome, Edge and other Chromium-based browsers.
Speaker Erin SparlingEvidence transcript
Used byglossary term Rendering
Although Google's pipeline diagram shows rendering as part of indexing, Google's rendering is a detached system, kept separate because rendering is time-consuming and computationally expensive.
“it shows rendering as part of indexing, but it's actually a detached system”
Speaker Erin SparlingEvidence transcript
After the crawler has fetched a page, Google's rendering system executes it, checks that it loads properly and works out what it looks like at different sizes.
Speaker Erin SparlingEvidence transcript
Google said its pipeline needs to ensure that content indexable without JavaScript can pass through without rendering, while content that appears only through JavaScript and CSS takes a longer rendering pass.
Speaker Erin SparlingEvidence transcript
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.
Speaker Erin SparlingEvidence transcript
After Google's opener, Lightning session D had three community talks: rendering and JavaScript execution blind spots (Sören Bendig), debugging JavaScript rendering for Search (Rebecca Yu) and virtualizing the browser (Natalia Venditto).
Speaker Erin SparlingEvidence transcript
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.
Speaker Sören BendigEvidence transcript
Switching JavaScript off and on in the browser gives a quick first impression of which content on a page depends on rendering.
Speaker Sören BendigEvidence transcript
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.
“everything you want cited, include it in the raw HTML, server-side rendered”
Speaker Sören BendigEvidence transcript
Used byrequirement DEV-REN-01
In a navigation example, the main navigation was in the raw HTML and would survive a rendering failure, but the whole sub-navigation was built by JavaScript, so all of its links would be inaccessible to bots if rendering broke.
Speaker Sören BendigEvidence transcript
When checking which links bots can see, keep in mind that the rendered HTML can change with user actions, a community speaker cautioned.
Speaker Sören BendigEvidence transcript
One site that builds its whole content by rendering also rendered its meta description with HTML tags inside it, which makes no sense and points to a flawed process.
Speaker Sören BendigEvidence transcript
Used byrequirement DEV-HTM-03
Sites that create their content by rendering should have at least basic monitoring to check that the rendered pages come out right, a community speaker advised.
Speaker Sören BendigEvidence transcript
Used byrequirement DEV-MON-05
Browser console messages reveal further problems on a page, Content Security Policy violations among them; few teams analyse console messages at scale, but they should, a community speaker said.
Speaker Sören BendigEvidence transcript
Used byrequirement DEV-REN-09
On a travel site, the number of offers differed between the raw HTML and the rendered page, possibly because the two versions drew on different internal databases or applied extra filters.
Speaker Sören BendigEvidence transcript
On a retail brand's page, the rendered version promised a bigger discount for a newsletter sign-up than the non-rendered version that was served, a mismatch that can hurt customer satisfaction; the two recordings disagree on the figure the rendered page promised.
Speaker Sören BendigEvidence transcript
Offer counts, discounts and other data should always be the same in the raw HTML and the rendered page, a community speaker advised.
Speaker Sören BendigEvidence transcript
Used byrequirement DEV-REN-07
A search engine's renderer does not wait forever before taking its snapshot, so content from slow internal systems or APIs can be missing and unresolved placeholders can end up in the final snapshot, a community speaker said.
Speaker Sören BendigEvidence transcript
Used byrequirement DEV-REN-06
In one shop's example, brand names and product descriptions were rendered from a database; the brand name was missing from the meta description, and the shop sometimes appeared with unresolved placeholders and sometimes as intended.
Speaker Sören BendigEvidence transcript
Unresolved placeholders caused by rendering timeouts are hard to catch because the problem moves around: it is not always the same page that is broken.
Speaker Sören BendigEvidence transcript
Used byrequirements DEV-MON-05, DEV-REN-06
Broken titles and snippets caused by unresolved placeholders may hurt business, especially for e-commerce shops and affiliate-heavy sites, a community speaker warned.
Speaker Sören BendigEvidence transcript
To catch intermittent rendering problems, archive the full HTML and the resources of each page during a site audit and analyse them yourself, a community speaker advised.
Speaker Sören BendigEvidence transcript
Used byrequirement DEV-MON-05
Content Security Policy lowers the risk of cross-site scripting and clickjacking by defining trusted hosts; a resource from a host that is not trusted is not used.
Speaker Sören BendigEvidence transcript
Used byrequirement DEV-REN-09
Content Security Policy is often misunderstood: on a page of a large German banking group, a video that should have been shown was blocked by a CSP violation, which also appeared in the browser console.
Speaker Sören BendigEvidence transcript
Never block a resource that a page needs for rendering with robots.txt, a community speaker said, calling this common sense.
Speaker Sören BendigEvidence transcript
A page can render completely blank while its raw HTML looks fine, so a team checking only the raw HTML thinks all is well; causes include server misconfiguration, overload and bad scripts.
Speaker Sören BendigEvidence transcript
Used byrequirement DEV-MON-05
Because even established brands have these rendering problems and every modern website uses a lot of JavaScript, a community speaker argued that most sites probably have them too and that ignoring rendering is reckless.
Speaker Sören BendigEvidence transcript
A community speaker strongly advised SEOs to use Chrome DevTools more often to understand what happens when their pages render.
Speaker Sören BendigEvidence transcript
Third-party systems billed per session that also run when bots render a page can cost a high-traffic site thousands of euros per month, a community speaker said, adding that he sees this regularly.
Speaker Sören BendigEvidence transcript
Used byrequirement DEV-PRF-03
The second community lightning talk of the rendering block covered debugging JavaScript rendering for Search: how Google renders pages, a step-by-step check, four common mistakes and a worked product page example.
Speaker Rebecca YuEvidence transcript
Google's renderer is a headless Chromium that runs the page's JavaScript.
Speaker Rebecca YuEvidence transcript, slide photo
If a page keeps loading content indefinitely, not all of that content will be indexed, because Google's rendering does not go on forever (this passage of the recording is partly unclear).
Speaker Rebecca YuEvidence transcript
Used byrequirement DEV-REN-06
To check whether JavaScript content is affected, open the URL Inspection tool in Search Console or the Rich Results Test and look for that content in the rendered HTML tab.
Speaker Rebecca YuEvidence transcript
Used byrequirement DEV-MON-02glossary terms Raw HTML and rendered HTML, URL Inspection tool
A community speaker treats the rendered HTML shown in Google's testing tools as the final source of truth, because what Google sees there is what gets indexed.
“I always treat this page as the final source of truth”
Speaker Rebecca YuEvidence transcript
If content is missing from the rendered HTML, find the script responsible in Chrome DevTools: open the Network tab, filter by Fetch/XHR and reload the page.
Speaker Rebecca YuEvidence transcript
For each suspect script or API request in Chrome DevTools, check whether it runs, whether something blocks it and whether robots.txt disallows it.
Speaker Rebecca YuEvidence transcript
If the cause of missing JavaScript content is still unclear after checking the network requests, search the source code for a string related to the missing content.
Speaker Rebecca YuEvidence transcript
A community speaker listed four common but often overlooked JavaScript rendering mistakes: non-crawlable link markup, error pages that return HTTP 200 in single-page apps, content behind user interaction, and JavaScript or API resources blocked in robots.txt.
Speaker Rebecca YuEvidence transcript, 3 slide photos
Used byglossary term Single-page app (SPA)
Non-crawlable link markup, such as onclick links and hash pseudo-links, is common in single-page web apps, and sites that use faceted navigation should check their links for it.
Speaker Rebecca YuEvidence transcript
Used byrequirement DEV-URL-02glossary term Single-page app (SPA)
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.
Speaker Rebecca YuEvidence transcript
Used byrequirement DEV-ERR-02glossary term Single-page app (SPA)
The fix for a client-side soft 404 is to make a missing page end with a real HTTP 404 status code instead of 200.
Speaker Rebecca YuEvidence transcript
Used byrequirement DEV-ERR-02
A community speaker called not hiding content behind user interaction the most important of the four JavaScript rendering mistakes.
Speaker Rebecca YuEvidence transcript
On a product page whose data is fetched client-side, the rendering mistakes described can leave Google seeing no content at all while users still see the price and images.
Speaker Rebecca YuEvidence transcript
In the speaker's product page example, three of the mistakes combine: product links behind onclick handlers keep the product detail pages hidden, the product API is blocked in robots.txt, and some content waits for a user interaction.
Speaker Rebecca YuEvidence transcript
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.
Speaker Rebecca YuEvidence transcript
Used byrequirements DEV-ERR-03, DEV-REN-04
A community speaker summed up JavaScript rendering issues as cases where search engines cannot execute, access or trigger the code needed to display a page's core content.
“JavaScript rendering issues happen when search engines cannot execute, access or trigger the code required to display your core content.”
Speaker Rebecca YuEvidence transcript
To find rendering issues, compare a page's raw source code with its rendered versions, including the rendered HTML that Google's testing tools show; the differences point to the problems.
Speaker Rebecca YuEvidence transcript
Used byrequirement DEV-MON-02glossary term Raw HTML and rendered HTML
Natalia Venditto, a Principal Software Engineer at Adobe, gave a seven-minute community lightning talk on JavaScript and web standards, built around the Web Fragments library.
Speaker Natalia VendittoEvidence transcript
Natalia Venditto opened by saying that Gary had said earlier at the event that everyone can write a standard, and that this is what the Web Fragments work is trying to do.
Speaker Natalia VendittoEvidence transcript
Natalia Venditto said teams are increasingly asked to integrate AI-generated content and applications into existing web applications and want to do so without breaking the host application, a situation she called a typical micro-frontend scenario.
Speaker Natalia VendittoEvidence transcript
Natalia Venditto named three typical failure modes by which an embedded app can break the application hosting it: collisions in the global JavaScript scope and module registry, CSS bleed, and fate sharing.
Speaker Natalia VendittoEvidence transcript
CSS bleed, as Natalia Venditto described it, means styles leak between an embedded app and its host, so that suddenly everything looks like the embedded app or the embedded app takes on the look of the host.
Speaker Natalia VendittoEvidence transcript
Fate sharing means a failure in an embedded app spreads to its host, for example an unhandled exception in the embedded app that ends up breaking the host application.
Speaker Natalia VendittoEvidence transcript
Web Fragments is a lightweight library that puts a hidden iframe in the host page and uses it as an isolated sandbox to run the embedded app's JavaScript, not to render the app.
Speaker Natalia VendittoEvidence transcript
Web Fragments fetches the embedded app's assets from a remote endpoint through middleware that acts as a gateway.
Speaker Natalia VendittoEvidence transcript
Web Fragments reframes the embedded app's DOM by placing it inside a shadow DOM in the host page, while the app's JavaScript runs in the hidden iframe.
Speaker Natalia VendittoEvidence transcript
With Web Fragments the page ends up as a single document in which the host application does not know the embedded app runs inside it and the embedded app does not know it lives in another document.
Speaker Natalia VendittoEvidence transcript
Web Fragments monkey-patches browser APIs to containerize the browser, recreating inside it an architecture similar to Docker containers on the back end.
“we monkey patch the browser to containerize it”
Speaker Natalia VendittoEvidence transcript
The browser APIs Web Fragments patches include document, history and location; Natalia Venditto said they are virtualized rather than hijacked, so controls work exactly as in a normal application.
Speaker Natalia VendittoEvidence transcript
Web Fragments retargets dispatchEvent calls to the fragment's shadow root and resolves DOM calls such as appendChild and element lookups against the main document.
Speaker Natalia VendittoEvidence transcript
Natalia Venditto said Web Fragments suits AI-generated apps because a web fragment used as a custom element sandboxes the app's rendering, avoiding collisions and CSS bleed between the app and its host in either direction.
Speaker Natalia VendittoEvidence transcript
Natalia Venditto said the five Web Fragments steps are all that is needed to run a containerized application fully on the client side.
Speaker Natalia VendittoEvidence transcript
Natalia Venditto said Web Fragments is framework-agnostic and vendor-agnostic and works the same whatever JavaScript framework the embedded app uses.
Speaker Natalia VendittoEvidence transcript
Natalia Venditto recommended that web fragments be server-rendered.
Speaker Natalia VendittoEvidence transcript
Used byrequirement DEV-REN-01
Natalia Venditto reported an enormous performance increase (no figure given) when an application is reframed inside a fully client-side host, because the reframed app is rendered and interactive immediately.
Speaker Natalia VendittoEvidence transcript
Natalia Venditto said a server-rendered app reframed into the host page is fully indexable.
Speaker Natalia VendittoEvidence transcript
Used byrequirement DEV-REN-01
Natalia Venditto said the goal of the Web Fragments team is not to maintain monkey patches but to standardize the approach.
Speaker Natalia VendittoEvidence transcript, slide photo
Natalia Venditto said the case for standardizing Web Fragments is that it already relies on many existing browser APIs, built that way so as not to rewrite much or reinvent the wheel.
Speaker Natalia VendittoEvidence transcript
Natalia Venditto said ShadowRealm, a JavaScript standard proposal, was at stage 2.7 at the time of the talk, which she glossed as meaning that only implementation is missing.
“the only thing missing is implementation”
Speaker Natalia VendittoEvidence transcript
Natalia Venditto said the ShadowRealm proposal would do much of what Web Fragments does today with patches: containerizing and isolating execution.
Speaker Natalia VendittoEvidence transcript
Natalia Venditto said the Web Fragments team supports the ShadowRealm standard proposal.
Speaker Natalia VendittoEvidence transcript
Websites that rely heavily on JavaScript and rendering have common blind spots, because these features often break in subtle ways, a community speaker said.
Speaker Sören BendigEvidence transcript
None of the rendering problems a community speaker showed from established brands' sites had been fixed promptly: some were fixed by the time of the talk and some were still live.
Speaker Sören BendigEvidence transcript
Search engines such as Google and Bing would ignore HTML tags written inside a meta description, a community speaker said.
Speaker Sören BendigEvidence transcript
Used byrequirement DEV-HTM-03
A rendering failure such as a Content Security Policy blocking a video on a landing page that explains how to open a business account could have a drastic impact for a purely online business, a community speaker warned.
Speaker Sören BendigEvidence transcript
Besides using Chrome DevTools more often, a community speaker advised checking rendering at scale with a modern crawler.
Speaker Sören BendigEvidence transcript
Used byrequirement DEV-MON-05
Google's crawler documentation defines grounding in Gemini Apps and in Grounding with Google Search on Vertex AI as providing content from the Google Search index to the model at prompt time, and sites manage whether their content is used for it with the Google-Extended robots.txt token.
Publisher Google
Used byrequirement DEV-IDX-11glossary term Grounding
Google says user-triggered fetchers, which fetch a URL because a user asked for it in a Google product (for example Gemini Notebook fetching URLs users add as sources, or Google-Agent acting on a user's request), generally ignore robots.txt rules.
Publisher Google
Used byrequirement DEV-IDX-11
Google'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.
Publisher Google Search Central
Used byrequirement DEV-REN-01glossary term Rendering
Google says Googlebot and its Web Rendering Service identify resources that do not contribute to essential page content, such as reporting and error requests, and may not fetch them, so client-side analytics may not give a full or accurate picture of their activity.
Publisher Google Search Central
Used byrequirement DEV-MON-04
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.
Publisher Google Search Central
Used byrequirement DEV-URL-01
Google'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.
“The page may stay on this queue for a few seconds, but it can take longer than that.”
Publisher Google Search Central
Used byrequirements DEV-PRF-02, DEV-REN-01glossary term Render queue
Google's URL Inspection help says the tool's live test examines a URL in real time, so its results can differ from Google's indexed version of the page.
Publisher Google Search Console Help
Used byrequirement DEV-MON-02glossary term URL Inspection tool
Google's JavaScript guides say that when client-side routing makes a real 404 status impractical, a single-page app can avoid soft 404s by redirecting with JavaScript to a URL whose server returns 404, or by adding a robots noindex meta tag with JavaScript.
Publisher Google Search Central
Used byrequirement DEV-ERR-02
In Google's March 2023 SEO office hours, John Mueller said Google handles infinite scroll with viewport expansion, rendering a page like a very long phone, which is not very efficient and can miss content, so pagination links are strongly recommended.
“this is done through a technique called "viewport expansion", where we render a page like a very long phone.”
Publisher Google Search Central (SEO office hours transcript, March 2023)
Google says its Web Rendering Service fetches the resources a page references through Googlebot, including JavaScript, CSS and XHR requests to APIs, but not images or videos.
Publisher Search Central blog (3 December 2024), Search Central blog (31 March 2026)
Used byrequirement DEV-REN-04
Google says its systems generally try to index the content of a page embedded with an iframe as part of the page that embeds it, but this is not guaranteed because both pages are also normal HTML pages on their own.
Publisher Google Search Central (SEO office hours transcript, December 2023), Search Central blog (21 January 2022)
Used byrequirement DEV-REN-10
Google's documentation says Google supports web components and flattens shadow DOM and light DOM content when it renders a page, and that content not visible in the rendered HTML cannot be indexed.
Publisher Google Search Central
Used byrequirement DEV-REN-10glossary term Shadow DOM
If Gemini training reuses the rendering done for Search, a site needs no separate rendering work for Gemini; whether its rendered content is used for training is decided with the Google-Extended token in robots.txt, not by rendering choices.
Author Ibrahim Anjro
Used byrequirement DEV-IDX-11
Google documents Gemini grounding only as content from the Search index at prompt time; the live read of a specific page at a user's request, described on stage, is not documented, so it is unclear whether it works like a user-triggered fetcher, which generally ignores robots.txt, or follows Google-Extended.
Author Ibrahim Anjro
For pages people are likely to ask an AI assistant about (product, pricing, documentation and policy pages), server-render the main content so a live, user-triggered read does not depend on client-side JavaScript finishing quickly.
Author Ibrahim Anjro
Used byrequirements DEV-PRF-02, DEV-REN-01
The stage remark that content indexable without JavaScript can pass through without rendering does not mean such pages skip rendering, because Google's guide queues every 200 page for rendering; read it as: content already in the raw HTML does not depend on the slower rendering pass.
Author Ibrahim Anjro
Put everything indexing depends on (title, meta description, canonical, robots meta tag, main text and links) in the raw HTML so it is available without rendering, let JavaScript add enhancements only, and check the rendered HTML in URL Inspection for the rest.
Author Ibrahim Anjro
Used byrequirement DEV-REN-01
Diff the raw and the rendered HTML of each key template for prices, offer counts, links and meta tags, and treat any difference in commercial data as a bug, because bots and users may get different versions.
Author Ibrahim Anjro
Used byrequirements DEV-MON-05, DEV-REN-07
Add a check for unresolved template placeholders (such as {{brand}}, undefined or null) in rendered titles, meta descriptions and visible text to recurring crawls, and render the same URLs more than once, because such failures are intermittent.
Author Ibrahim Anjro
Used byrequirements DEV-MON-05, DEV-REN-06
When something is missing from a rendered page, check both robots.txt and the Content Security Policy: the URL Inspection live test shows the page resources, the JavaScript console output and a screenshot of the rendered page.
Author Ibrahim Anjro
Used byrequirements DEV-MON-02, DEV-REN-09
Compare the session counts that per-session-billed tools (chat, personalisation, testing, session replay) charge for with real user sessions, and load such tools only after a user interaction where they add no content that needs to be indexed.
Author Ibrahim Anjro
Used byrequirement DEV-PRF-03
Check rendering per template rather than per URL: inspect one URL of each page type (product, category, article) in URL Inspection and confirm that the main content, prices and internal links appear in the rendered HTML.
Author Ibrahim Anjro
Used byrequirement DEV-MON-02
Hash-fragment links are a problem only where Google should follow them: product, category and language links need a real URL in an <a href>, while fragments can deliberately keep filter combinations out of the crawl, as Google's faceted navigation guide allows.
Author Ibrahim Anjro
Used byrequirement DEV-URL-08
Build market and language selectors as plain <a href> links to each alternate URL, not buttons or script handlers; otherwise the language versions have no internal links and depend on sitemaps to be found, which is slow.
Author Ibrahim Anjro
Used byrequirement DEV-INT-06
In a single-page app, let the server return 404 for unknown routes where possible; otherwise use one of the two client-side fixes Google documents for error views: a JavaScript redirect to a URL that returns 404, or a robots noindex added with JavaScript.
Author Ibrahim Anjro
Audit tabs, accordions and 'load more' lists for content fetched on click or scroll: put tab content in the initial DOM and hide it with CSS, trigger lazy loading with an Intersection Observer, and give long lists paginated URLs linked with <a href>.
Author Ibrahim Anjro
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.
Author Ibrahim Anjro
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.
Author Ibrahim Anjro
Used byrequirement DEV-SRV-04
Pages that embed third-party or AI-generated apps can share their fate, since an unhandled exception in the embedded code can break the host page; check the rendered HTML and JavaScript console output of such pages in Google's testing tools to make sure the host's own content still renders.
Author Ibrahim Anjro
Used byrequirement DEV-REN-09
Before embedding an app or widget in an iframe, test it with a keyboard and a screen reader as well as for layout and navigation, because the isolation an iframe gives comes at those costs.
Author Ibrahim Anjro
Because Web Fragments monkey-patches core browser APIs such as document, history and location, test pages that use it in Google's rendering (the rendered HTML in Search Console's URL Inspection tool or the Rich Results Test), not only in a normal desktop browser.
Author Ibrahim Anjro
Used byrequirement DEV-REN-10
Make sure robots.txt does not block the URLs from which the browser loads a fragment's assets (the gateway paths on the host page's origin, or the endpoint's own host if assets load from there), because Google does not render JavaScript from blocked files and robots.txt rules apply per host.
Author Ibrahim Anjro
Because Google flattens shadow DOM when it renders, content that Web Fragments places in a shadow root can in principle be indexed with the host page, but only if it appears in the rendered HTML; check that in URL Inspection rather than relying on a library's promise of indexability.
Author Ibrahim Anjro
Used byrequirement DEV-REN-10
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.
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.
When a Gemini user asks about a specific web page (for example, whether it says anything about the ruby HTML tag), the page is read at that moment rather than during crawling and may be used to ground the answer, which takes extra time.
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.
Google's crawler documentation defines grounding in Gemini Apps and in Grounding with Google Search on Vertex AI as providing content from the Google Search index to the model at prompt time, and sites manage whether their content is used for it with the Google-Extended robots.txt token.
Google-Extended is a control token, not a crawler with its own user agent string. It decides whether crawled content may be used to train future Gemini models and to ground Gemini apps and Vertex AI.
Google says user-triggered fetchers, which fetch a URL because a user asked for it in a Google product (for example Gemini Notebook fetching URLs users add as sources, or Google-Agent acting on a user's request), generally ignore robots.txt rules.
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.
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.
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.
The 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.
Although Google's pipeline diagram shows rendering as part of indexing, Google's rendering is a detached system, kept separate because rendering is time-consuming and computationally expensive.
A Google pipeline slide placed processing between the crawler and the index and listed six processing steps: HTML parsing, rendering, deduplication, feature extraction, signal extraction and index selection.
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.
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.
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.
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.
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.
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.
The 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.
In Google's processing step, links are extracted from the HTML Google already has, before rendering, and the URLs found go back to the crawl queue.
URL discovery works through links: a homepage links to section pages, which link to further pages.
In Google's processing step, links are extracted from the HTML Google already has, before rendering, and the URLs found go back to the crawl queue.
Links extracted during processing are sent back to the crawl queue, where scheduling starts again for the newly found URLs.
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.
URL discovery works through links: a homepage links to section pages, which link to further pages.
Google's renderer is a headless Chromium that runs the page's JavaScript.
Google renders JavaScript-heavy pages from their HTML, CSS and JavaScript as a browser would, using the latest version of Chromium.
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.
Google'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.
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.
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.
A market or language selector built as a button works for users but leaves the whole cluster of alternate-language pages without crawlable links, so the cluster is orphaned for Google.
Google'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.
Hash-fragment links are a problem only where Google should follow them: product, category and language links need a real URL in an <a href>, while fragments can deliberately keep filter combinations out of the crawl, as Google's faceted navigation guide allows.
Google'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.
Build market and language selectors as plain <a href> links to each alternate URL, not buttons or script handlers; otherwise the language versions have no internal links and depend on sitemaps to be found, which is slow.
A page with no internal links depends on sitemaps alone to be found, so it is discovered slowly and attracts little crawl demand.
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.
A 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.
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.
Google'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.
Lazy loading triggered by a scroll event listener, such as window.addEventListener('scroll', loadMoreProducts), never runs for Googlebot because Googlebot does not scroll.
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.
Google'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.
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.
The 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.
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.
When matching rules to a URL, Google uses the most specific rule by path length. If rules conflict, it uses the least restrictive one.
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.
If 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.
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.
A 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.
Erin Sparling named server-side or hybrid rendering, fallbacks and not leaving placeholders in the DOM, among other measures, as ways to guard against failed JavaScript rendering.
A search engine's renderer does not wait forever before taking its snapshot, so content from slow internal systems or APIs can be missing and unresolved placeholders can end up in the final snapshot, a community speaker said.
Content is missing from the rendered HTML either because the server does not serve it or because the content has still not appeared after some period of time.
A search engine's renderer does not wait forever before taking its snapshot, so content from slow internal systems or APIs can be missing and unresolved placeholders can end up in the final snapshot, a community speaker said.
Instead of scrolling, Google renders a page in a very tall viewport, around 10,000 pixels high.
An Intersection Observer fires when the observed element enters the viewport, and the viewport Google renders with is tall, so content lazy-loaded this way can load during rendering.
Polyfills work in two directions: they patch backwards where a browser lacks support, or patch forward to build now for a feature expected in the future, as Web Fragments does.
Natalia Venditto said the ShadowRealm proposal would do much of what Web Fragments does today with patches: containerizing and isolating execution.
With the History API, a single-page app can use real links and attach event listeners that intercept the click, rewrite the URL with pushState and load the new content, so Google can follow the links while users avoid full page reloads.
The crawlable pattern for single-page app navigation is a real URL in the href, such as <a href=/products>, combined with History API routing (window.history.pushState) instead of hash routes.
The fix for a client-side soft 404 is to serve a real 404 error page where appropriate; how to detect URLs that do not exist depends on how the app works and where it is hosted.
The fix for a client-side soft 404 is to make a missing page end with a real HTTP 404 status code instead of 200.
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.
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.
Sites need no extra work to appear in AI Overviews and AI Mode: both work on top of the existing web results, so what works for web results also works for the AI features.
AI Overviews and AI Mode are built on top of Search results: they are a different experience of the same content Google already has.
Content inside tabs, for example separate tabs for a product description and a manufacturer description, might be part of a page's main content.
Tab and accordion content should be in the DOM from the start and only hidden with CSS or the hidden attribute; Google indexes such hidden content.
Google renders pages in two ways: immediately after crawling, or later through a queue-based process that runs elsewhere.
After processing, an indexable page is placed in Google's render queue to wait for rendering.
Content that JavaScript adds to a page is typically seen by Google's indexing system within a few hours, and at worst within weeks.
Google'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.
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.
Google'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.
AI Overviews and AI Mode are built on top of Search results: they are a different experience of the same content Google already has.
AI Mode and AI Overviews use the same crawling and the same index as Search. At serving they add grounding on the Search index and query fan-out.
Google says user-triggered fetchers, which fetch a URL because a user asked for it in a Google product (for example Gemini Notebook fetching URLs users add as sources, or Google-Agent acting on a user's request), generally ignore robots.txt rules.
A community speaker pointed out that, according to Google's documentation, user-triggered fetchers, which fetch a page because a user asked for it, generally ignore robots.txt rules.
Google renders pages with Chromium, the browser technology that also underlies Chrome, Edge and other Chromium-based browsers.
Google renders JavaScript-heavy pages from their HTML, CSS and JavaScript as a browser would, using the latest version of Chromium.
Natalia Venditto opened by saying that Gary had said earlier at the event that everyone can write a standard, and that this is what the Web Fragments work is trying to do.
John Mueller encouraged attendees to help write a specification for robots meta tags, saying internet standards groups are made up of ordinary people and need only passion and a willingness to join the discussions.
Content that is not in the final DOM after rendering cannot be seen by Google, so it cannot be indexed.
Whatever is in the DOM at the moment Google's rendering finishes is what likely gets indexed.
Blocked resources, one of Google's four common JavaScript indexing problems, means robots.txt disallowing the crawling of critical JavaScript files or API endpoints.
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.
Content that loads only when a user clicks an element is not supported in the way Google renders pages for indexing.
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.
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.
Lazy loading triggered by a scroll event listener, such as window.addEventListener('scroll', loadMoreProducts), never runs for Googlebot because Googlebot does not scroll.
Content loaded as elements enter the viewport, for example with an Intersection Observer, does load when Google renders a page, because Google's rendering viewport is very tall.
An Intersection Observer fires when the observed element enters the viewport, and the viewport Google renders with is tall, so content lazy-loaded this way can load during rendering.
Google recommends the History API to give single-page apps clean URLs instead of fragment-based routes.
The crawlable pattern for single-page app navigation is a real URL in the href, such as <a href=/products>, combined with History API routing (window.history.pushState) instead of hash routes.
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.
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.
If robots.txt blocks JavaScript that client-side code needs to render, Google cannot render the content that the JavaScript would produce.
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.