Knowledge base v2.13.0 · Community edition · data through 2 October 2026
Day 2 · Thursday 1 October 2026 · 11:15
Same speaker as the opener of Lightning session D.
Google listed four common JavaScript problems for indexing: content not present in the rendered HTML, using # in URLs for content changes, soft 404s and blocked resources.
Speaker Erin SparlingEvidence slide photo, transcript
Google's slide called content missing from the rendered HTML the most common JavaScript issue for indexing.
“The most common issue.”
Wording checked against the slide or recording
Speaker Erin SparlingEvidence slide photo, transcript
Used byrequirement DEV-REN-02
Content that is not in the final DOM after rendering cannot be seen by Google, so it cannot be indexed.
“If it's not in the final DOM, Google can't see it.”
Wording checked against the slide or recording
Speaker Erin SparlingEvidence slide photo, transcript
Used byrequirement DEV-REN-02
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.
“Your application serves a "Not Found" message but returns a 200 HTTP status code.”
Wording checked against the slide or recording
Speaker Erin SparlingEvidence slide photo, transcript
Used byrequirement DEV-ERR-02
Blocked resources, one of Google's four common JavaScript indexing problems, means robots.txt disallowing the crawling of critical JavaScript files or API endpoints.
“robots.txt disallowing crawling of critical .js or API endpoints.”
Wording checked against the slide or recording
Speaker Erin SparlingEvidence slide photo, transcript
Used byrequirement DEV-REN-04
Google named three causes of content missing from the rendered HTML: JavaScript inaccessible to Googlebot, JavaScript DOM event triggers and disabled browser APIs.
Speaker Erin SparlingEvidence slide photo, video, transcript
Google said there is no single fix for content missing from the rendered HTML: the solution varies by case, and the advice is to follow best practices.
“Solution: varies by case, but follow best practices.”
Wording checked against the slide or recording
Speaker Erin SparlingEvidence slide photo, transcript
URL fragments (#) are often ignored by crawlers: a fragment exists only in the browser, so Google cannot request it.
“Fragment identifiers (#) are often ignored by crawlers.”
Wording checked against the slide or recording
Speaker Erin SparlingEvidence slide photo, transcript
Used byrequirement DEV-URL-03
Google recommends the History API to give single-page apps clean URLs instead of fragment-based routes.
“Use the History API for clean URLs in SPAs.”
Wording checked against the slide or recording
Speaker Erin SparlingEvidence slide photo, transcript
Used byrequirement DEV-URL-03glossary term History API
Google renders nearly all of the web by replicating what a browser does, using a real browser's rendering engine.
“Google renders nearly all of the internet by replicating browser actions”
Speaker Erin SparlingEvidence transcript
If JavaScript rendering fails, what Google indexes for a page differs from what the page shows once it is rendered.
Speaker Erin SparlingEvidence transcript
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.
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-REN-06
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.
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-REN-06
When the JavaScript is not accessible to Googlebot, Google cannot render the client-side DOM that the page builds asynchronously, so parts of the page may be present while the main content is absent.
Speaker Erin SparlingEvidence transcript
Content that loads only when a user clicks an element is not supported in the way Google renders pages for indexing.
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-REN-02glossary term Lazy loading
Browser APIs that need user permission, such as payments and location, are not supported when Google renders a page.
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-REN-08
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.
Speaker Erin SparlingEvidence slide photo, transcript
Used byrequirements DEV-REN-03, DEV-URL-07
Instead of scrolling, Google renders a page in a very tall viewport, around 10,000 pixels high.
“it renders it in a very tall viewport. Specifically, around 10,000 pixels is what the viewport gets rendered as.”
Speaker Erin SparlingEvidence slide photo, transcript
Used byrequirements DEV-REN-03, DEV-URL-07glossary term Viewport expansion
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.
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-REN-03
WebGL does not work well in Google's rendering: a WebGL shader that makes a page look like it is underwater will not be applied when Google renders the page.
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-REN-08
Erin Sparling recommended differential serving and polyfills to keep a site compatible with Google's rendering engine where it lacks a browser feature.
Speaker Erin SparlingEvidence transcript
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.
Speaker Erin SparlingEvidence transcript
Erin Sparling called URL fragments (the part of a URL after #) the next most common JavaScript issue seen, after rendering problems and blocked rendering.
Speaker Erin SparlingEvidence transcript
Moving a single-page app from fragment-based routes to real paths with the History API keeps the same client-side behaviour and was described as not free but relatively straightforward.
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-URL-03
A link that is an <a> element but does not point to a real URL gives Google something to look at, but Google will not know where the link goes.
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-URL-01
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.
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-URL-03glossary terms History API, Single-page app (SPA)
Real URLs also work as deep links: Android, iOS and desktop operating systems accept full URLs as keys to specific content in an app, so clean URLs simplify the cross-platform user experience, not only indexing.
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-URL-03
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.
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-ERR-02
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.
Speaker Erin SparlingEvidence transcript
In an app routed with the History API, when a user reaches a page that does not exist, Erin Sparling suggested asking how they got there and redirecting to a real 404 page.
Speaker Erin SparlingEvidence transcript
If robots.txt blocks JavaScript that client-side code needs to render, Google cannot render the content that the JavaScript would produce.
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-REN-04
A headless content management system serves its content as an API; even WordPress, often seen as one monolithic application, can be used headless, with only its editor or only its renderer.
Speaker Erin SparlingEvidence transcript
Erin Sparling's practice with a headless CMS is to give an AI agent the content's JSON Schema and have it build a throwaway prototype front end, to see the content before deciding how to render it; the prototype is not meant for launch.
Speaker Erin SparlingEvidence transcript
For headless CMS content, Erin Sparling presented rendering on the server, not only in the browser, as a way to avoid indexing issues.
Speaker Erin SparlingEvidence transcript
When one content schema feeds several front ends (the example was a news UI, then a recipe UI), Erin Sparling had an AI agent add automated browser UI tests and agent controls so the interfaces could be managed and tested.
Speaker Erin SparlingEvidence transcript
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.
Speaker Erin SparlingEvidence transcript
When Search Console reports that content is not rendering, Erin Sparling suggested putting AI agents on the problem, but only after doing your own due diligence.
Speaker Erin SparlingEvidence transcript
To use Search Console to debug what Google can see on a site and why, Erin Sparling said the first step is to get access to the site by verifying ownership (the speaker's words were authorized domains).
Speaker Erin SparlingEvidence transcript
Used byrequirement DEV-MON-01
Erin Sparling showed a Search Console result saying a URL would be indexed only under certain conditions, one of which had not been met, and contrasted it with the result for an available URL whose content loads.
Speaker Erin SparlingEvidence transcript
Google's JavaScript SEO basics says every page with a 200 status code is queued for rendering, whether or not it uses JavaScript, unless a robots meta tag or header says not to index it; for non-200 pages such as 404 error pages, rendering might be skipped.
Publisher Google Search Central
Used byrequirement DEV-REN-05
Google's March 2023 SEO office hours say Google sees infinite-scroll content through viewport expansion, rendering a page like a very long phone, which is not particularly efficient and can miss infinite content.
“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)
Used byrequirement DEV-URL-07glossary term Viewport expansion
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.
Publisher Google Search Central
Used byrequirement DEV-URL-07
For effects that need WebGL, which Googlebot does not support, Google's guide to fixing JavaScript problems suggests skipping the effect or prerendering it with server-side rendering so that the content is accessible to Googlebot.
Publisher Google Search Central
Used byrequirement DEV-REN-08
Google's JavaScript SEO basics recommends differential serving and polyfills when feature detection finds a missing browser API, and warns that some browser features cannot be polyfilled.
“We recommend using differential serving and polyfills if you feature-detect a missing browser API that you need.”
Publisher Google Search Central
Used byrequirement DEV-REN-08
For client-side rendered single-page apps, where meaningful status codes can be impossible or impractical, Google's documentation gives two ways to avoid soft 404s: a JavaScript redirect to a URL that returns a 404 status, or a noindex robots meta tag added with JavaScript.
Publisher Google Search Central
Used byrequirement DEV-ERR-02
Google's introduction to robots.txt says unimportant image, script or style files may be blocked, but resources whose absence makes a page harder for Google to understand should not be blocked.
Publisher Google Search Central
Used byrequirement DEV-REN-04
Google's URL Inspection help says a valid live test only confirms that Google can access a page for indexing; the page must still meet other conditions to be indexed, such as having no manual action, not being a duplicate and being of high enough quality.
Publisher Google Search Console Help
Used byrequirement DEV-MON-02
Google's guide to fixing Search-related JavaScript problems says its Web Rendering Service keeps no state across page loads: local storage, session storage and HTTP cookies are cleared.
Publisher Google Search Central
Used byrequirement DEV-REN-06
Google's guide to fixing Search-related JavaScript problems says the Web Rendering Service may ignore caching headers and so use outdated JavaScript or CSS, and recommends content fingerprinting, which puts a hash of the content in the file name, as in main.2bb85551.js.
Publisher Google Search Central
Used byrequirement DEV-REN-06
Treat the 10,000-pixel viewport as a safety margin, not a target: load lazy content when it enters the viewport (Intersection Observer or native lazy loading, never scroll listeners), and give infinite-scroll content paginated URLs linked with <a href> so anything below the first rendered screen stays reachable.
Author Ibrahim Anjro
Wrap permission-based features (location, payments, camera) and WebGL effects in feature detection with a fallback, so the main content renders when the API is missing or the permission is declined; never make indexable content wait for a permission prompt.
Author Ibrahim Anjro
Used byrequirement DEV-REN-08
Audit a single-page app by searching both the templates and the rendered HTML for href="#..." routes, <a> elements without href and onclick navigation; every view that should rank needs an <a href> link to a real path.
Author Ibrahim Anjro
After moving to real paths, set the server or hosting rewrite rules so a direct request to every valid path returns 200 with the content (ideally server-rendered) and an unknown path returns a 404 status, which removes client-side soft 404s at the source.
Author Ibrahim Anjro
Used byrequirement DEV-ERR-02
Check robots.txt for Disallow rules covering JavaScript bundles, build folders or API endpoints the page calls while rendering, including on separate API or CDN hostnames with their own robots.txt, then confirm in URL Inspection's live test that the rendered HTML contains the main content.
Author Ibrahim Anjro
With a headless CMS, choose the rendering per template before launch (server-rendered or pre-rendered for pages that must rank), and make any agent-built test suite assert that the main content and <a href> links are present in the rendered HTML.
Author Ibrahim Anjro
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.
Content that loads only when a user clicks an element is not supported in the way Google renders pages for indexing.
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 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.
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.
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.
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.
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.
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.
A link that is an <a> element but does not point to a real URL gives Google something to look at, but Google will not know where the link goes.
URL discovery works through links: a homepage links to section pages, which link to further pages.
A link that is an <a> element but does not point to a real URL gives Google something to look at, but Google will not know where the link goes.
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.
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.
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.
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.
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.
If robots.txt blocks JavaScript that client-side code needs to render, Google cannot render the content that the JavaScript would produce.
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.
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.
A 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.
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.
Google renders nearly all of the web by replicating what a browser does, using a real browser's rendering engine.
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.
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.
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.
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.
URL fragments (#) are often ignored by crawlers: a fragment exists only in the browser, so Google cannot request it.
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.
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.