Knowledge base v2.13.0 · Community edition · data through 2 October 2026
Topic · Rendering and JavaScript
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.
Things in this topic 24
Counts are claims that name the thing. All things
What to do
A Google panelist said, as a fun fact, that JavaScript was used for the language-consolidation redirects in Google's own site migration, because it was the only option available to the person doing it (the recording does not make fully clear whether the JavaScript performed the redirects or built the mapping).
Speaker not identifiedIn Day 1, 16:35 · Q&AEvidence transcript
Used byrequirement DEV-CAN-01
Google's redirects guide says Google Search follows JavaScript location redirects only after rendering, may never see one if rendering fails, and should be used only when server-side or meta refresh redirects are impossible; its site move guide asks for server-side permanent redirects (301 or 308) where technically possible. The JavaScript in Google's own migration was a fallback ('my only option'), not a pattern to copy.
Author Ibrahim AnjroAnnotates Day 1, 16:35 · Q&A
Used byrequirement DEV-CAN-01
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.
Speaker Cherry PrommawinIn Day 2, 10:25 · How is HTML interpretedEvidence slide photo, transcript
Used byrequirement DEV-URL-02
A Google slide also listed as not extractable an a element with a routerLink attribute instead of an href, and javascript: URLs such as javascript:goTo('products') or javascript:window.location.href='/products'.
Speaker Cherry PrommawinIn Day 2, 10:25 · How is HTML interpretedEvidence slide photo
Used byrequirement DEV-URL-02
A slide said robots meta rules can be added to a page's HTML with JavaScript, but doing so takes more time.
Speaker John MuellerIn Day 2, 10:30 · Controlling indexingEvidence slide photo, transcript
Used byrequirement DEV-REN-05
Removing a robots restriction such as noindex with JavaScript does not work, a slide said.
“But... it takes more time, and removing restrictions (like "noindex") doesn't work.”
Wording checked against the slide or recording
Speaker John MuellerIn Day 2, 10:30 · Controlling indexingEvidence slide photo, transcript
Used byrequirement DEV-REN-05
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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence slide photo
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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence slide photo
Used byrequirement DEV-URL-03
Lazy loading should be triggered by an Intersection Observer that watches a sentinel element instead of by a scroll event listener.
Speaker Rebecca YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence slide photo, transcript
Used byrequirement DEV-REN-03glossary term Lazy loading
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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence slide photo
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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence slide photo
Used byrequirement DEV-SRV-04glossary term robots.txt
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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence slide photo, transcript
Used byrequirement DEV-URL-03glossary term History API
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.
Speaker Gary IllyesIn Day 2, 11:30 · Understanding what's on a pageEvidence slide photo, transcript
Used byrequirement DEV-ERR-03
Whether a page can load is really important for canonical selection: a broken certificate, failing JavaScript or a page that cannot be loaded counts against a URL, and the slide also listed meta refresh and security.
Speaker John MuellerIn Day 2, 11:55 · Handling web duplicationEvidence slide photo, transcript
Used byrequirement DEV-CAN-02
When Google finds a noindex rule in a page's HTML, it drops the page without even processing its JavaScript, so a script cannot switch the page back to indexable, John Mueller said.
“we will see the noindex and say, oh, we will get rid of this page; we won't even process the JavaScript”
Speaker John MuellerIn Day 2, 10:30 · Controlling indexingEvidence transcript
Used byrequirement DEV-REN-05
John Mueller recommended putting robots meta tags directly in a page's HTML exactly as intended, and adding them with JavaScript only where that is not possible, as in a JavaScript web app.
Speaker John MuellerIn Day 2, 10:30 · Controlling indexingEvidence transcript
Used byrequirement DEV-REN-05
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 SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript
Used byrequirements DEV-PRF-02, DEV-REN-01
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 SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript
Used byrequirement DEV-MON-05
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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript
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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript
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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript
Used byrequirement DEV-REN-06
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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript, 3 slide photos
Used byglossary 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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript
Used byrequirement DEV-ERR-02
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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript
Natalia Venditto recommended that web fragments be server-rendered.
Speaker Natalia VendittoIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 VendittoIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript
Search engines such as Google and Bing would ignore HTML tags written inside a meta description, a community speaker said.
Speaker Sören BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 BendigIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript
If JavaScript rendering fails, what Google indexes for a page differs from what the page shows once it is rendered.
Speaker Erin SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence transcript
Browser APIs that need user permission, such as payments and location, are not supported when Google renders a page.
Speaker Erin SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence transcript
Used byrequirement DEV-REN-08
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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence transcript
Used byrequirement DEV-REN-03
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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence transcript
Used byrequirement DEV-URL-03
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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence transcript
Google's link best practices say Google can generally crawl a link only if it is an a element with an href attribute, and list routerLink without href, href on a span, onclick-only a elements and javascript: URLs as not recommended, while noting that Google may still attempt to parse them.
Publisher Google Search CentralAnnotates Day 2, 10:25 · How is HTML interpreted
Used byrequirements DEV-URL-01, DEV-URL-02
Google's robots meta tag specification says data-nosnippet may be extracted both before and after rendering, so the attribute should not be added to or removed from existing elements with JavaScript.
Publisher Google Search CentralAnnotates Day 2, 10:30 · Controlling indexing
Used byrequirements DEV-IDX-07, DEV-REN-05
Google's meta tags documentation recommends avoiding JavaScript to inject or change meta tags whenever possible and testing the implementation thoroughly when it must be used.
Publisher Google Search CentralAnnotates Day 2, 10:30 · Controlling indexing
Used byrequirement DEV-REN-05
Google's JavaScript SEO basics guide says that when Google encounters a noindex rule it may skip rendering and JavaScript execution, so using JavaScript to change or remove a noindex robots meta tag may not work as expected.
“it may skip rendering and JavaScript execution”
Publisher Google Search CentralAnnotates Day 2, 10:30 · Controlling indexing
Used byrequirement DEV-REN-05
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 CentralAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
Used byrequirement DEV-REN-01glossary term Rendering
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 CentralAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
Used byrequirement DEV-ERR-02
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)Annotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
Used byrequirement DEV-REN-04
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 CentralAnnotates Day 2, 11:15 · What is Google friendly JavaScript
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 CentralAnnotates Day 2, 11:15 · What is Google friendly JavaScript
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 CentralAnnotates Day 2, 11:15 · What is Google friendly JavaScript
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 CentralAnnotates Day 2, 11:15 · What is Google friendly JavaScript
Used byrequirement DEV-REN-04
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 CentralAnnotates Day 2, 11:15 · What is Google friendly JavaScript
Used byrequirement DEV-REN-06
Google's link-extraction slide put routerLink, href on a span, onclick-only links and javascript: URLs under 'can not extract', which is stricter than Google's link documentation saying Google may still try to parse them; either way they are not dependable links for discovery.
Author Ibrahim AnjroAnnotates Day 2, 10:25 · How is HTML interpreted
Audit every template and JavaScript component that outputs links, such as navigation, pagination, filters and product tiles: each needs a real a element with an href, because onclick handlers, routerLink without href, href on a span and javascript: URLs leave the target pages without a link Google can reliably extract.
Author Ibrahim AnjroAnnotates Day 2, 10:25 · How is HTML interpreted
Ship robots rules in the HTML the server sends and never rely on JavaScript to lift a noindex: Google may skip rendering a page that arrives with noindex, so the page can stay out of the index even if a script removes the tag later.
Author Ibrahim AnjroAnnotates Day 2, 10:30 · Controlling indexing
Used byrequirement DEV-REN-05
On stage the rule was absolute (Google won't even process the JavaScript of a page served with noindex), while Google's guide says only that it may skip rendering; either way, a noindex in the served HTML must never be one that JavaScript is expected to lift.
Author Ibrahim AnjroAnnotates Day 2, 10:30 · Controlling indexing
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 AnjroAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
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 AnjroAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
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 AnjroAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
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 AnjroAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
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 AnjroAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
Used byrequirements DEV-MON-05, DEV-REN-06
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 AnjroAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
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 AnjroAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
Used byrequirement DEV-MON-02
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 AnjroAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
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 AnjroAnnotates Day 2, 10:40 · 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.
Author Ibrahim AnjroAnnotates Day 2, 10:40 · 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.
Author Ibrahim AnjroAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
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 AnjroAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
Used byrequirement DEV-REN-09
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 AnjroAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
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 AnjroAnnotates Day 2, 11:15 · What is Google friendly JavaScript
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 AnjroAnnotates Day 2, 11:15 · What is Google friendly JavaScript
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 AnjroAnnotates Day 2, 11:15 · What is Google friendly JavaScript
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 AnjroAnnotates Day 2, 11:15 · What is Google friendly JavaScript
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 AnjroAnnotates Day 2, 11:15 · What is Google friendly JavaScript
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 AnjroAnnotates Day 2, 11:15 · What is Google friendly JavaScript
Return real error status codes for error states, 404 or 410 for missing content and 503 for outages such as a failed database connection, also in single-page apps; a 200 page whose main content is only an error message is treated as a soft 404 even when header and navigation look normal.
Author Ibrahim AnjroAnnotates Day 2, 11:30 · Understanding what's on a page
Used byrequirements DEV-ERR-03, DEV-SRV-03
Content that JavaScript adds to a page is typically seen by Google's indexing system within a few hours, and at worst within weeks.
Speaker Gary IllyesIn Day 3, 15:45 · How long does it take to..?Evidence transcript
Used byrequirements DEV-MON-10, DEV-REN-01
Put critical content, links and meta tags in the server HTML: content that needs JavaScript reaches indexing only after rendering, usually within hours but sometimes weeks, and even Google's own speaker doubted that every URL gets rendered.
Author Ibrahim AnjroAnnotates Day 3, 15:45 · 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.
Author Ibrahim AnjroAnnotates Day 3, 15:45 · How long does it take to..?
Used byrequirement DEV-REN-01
A Google panelist said, as a fun fact, that JavaScript was used for the language-consolidation redirects in Google's own site migration, because it was the only option available to the person doing it (the recording does not make fully clear whether the JavaScript performed the redirects or built the mapping).
Google's redirects guide says Google Search follows JavaScript location redirects only after rendering, may never see one if rendering fails, and should be used only when server-side or meta refresh redirects are impossible; its site move guide asks for server-side permanent redirects (301 or 308) where technically possible. The JavaScript in Google's own migration was a fallback ('my only option'), not a pattern to copy.
A Google panelist said, as a fun fact, that JavaScript was used for the language-consolidation redirects in Google's own site migration, because it was the only option available to the person doing it (the recording does not make fully clear whether the JavaScript performed the redirects or built the mapping).
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
When Google finds a noindex rule in a page's HTML, it drops the page without even processing its JavaScript, so a script cannot switch the page back to indexable, John Mueller said.
Removing a robots restriction such as noindex with JavaScript does not work, a slide said.
John Mueller recommended putting robots meta tags directly in a page's HTML exactly as intended, and adding them with JavaScript only where that is not possible, as in a JavaScript web app.
A slide said robots meta rules can be added to a page's HTML with JavaScript, but doing so takes more time.
On stage the rule was absolute (Google won't even process the JavaScript of a page served with noindex), while Google's guide says only that it may skip rendering; either way, a noindex in the served HTML must never be one that JavaScript is expected to lift.
Ship robots rules in the HTML the server sends and never rely on JavaScript to lift a noindex: Google may skip rendering a page that arrives with noindex, so the page can stay out of the index even if a script removes the tag later.
Search engines such as Google and Bing would ignore HTML tags written inside a meta description, a community speaker said.
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.
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.
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.
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.
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.
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.
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 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.
Server-render the main content and everything indexing depends on (SSR, static generation or hybrid)
Rests on 11 claims, 8 of them in this topic
Do not add, change or remove robots meta tags with JavaScript
Rests on 9 claims, 8 of them in this topic
Return a real 404 for unknown routes in single-page apps, or use a documented client-side fallback
Rests on 7 claims, 7 of them in this topic
Do not block JavaScript, CSS or API endpoints that pages need for rendering in robots.txt
Rests on 7 claims, 7 of them in this topic
Make rendering robust: no slow API dependencies and no unresolved placeholders
Rests on 8 claims, 7 of them in this topic
Route single-page apps with the History API and real paths, not # fragments
Rests on 6 claims, 6 of them in this topic
Run recurring rendering checks: raw versus rendered HTML, placeholders and console errors
Rests on 7 claims, 5 of them in this topic
Feature-detect permission-based APIs and WebGL, and render the content without them
Rests on 5 claims, 4 of them in this topic
Do not navigate with onclick handlers, javascript: URLs, routerLink without href or # pseudo-links
Rests on 6 claims, 4 of them in this topic
Never serve error states, empty results or failed data loads with a 200 status
Rests on 10 claims, 3 of them in this topic
Have all indexable content in the DOM after load, without clicks, typing or scrolling
Rests on 8 claims, 3 of them in this topic
Keep prices, offer counts and other commercial data identical in raw and rendered HTML
Rests on 3 claims, 3 of them in this topic
Use permanent server-side redirects (301 or 308) for moved URLs, straight to the final URL
Rests on 10 claims, 2 of them in this topic
Give every indexable page a unique, descriptive title element in the server HTML
Rests on 7 claims, 2 of them in this topic
Make JavaScript-generated content render quickly
Rests on 5 claims, 2 of them in this topic
Load per-session-billed third-party tools only after a user interaction
Rests on 2 claims, 2 of them in this topic
Lazy-load with native lazy loading or an IntersectionObserver, never with scroll events
Rests on 6 claims, 2 of them in this topic
Monitor JavaScript console errors and Content Security Policy violations on key templates
Rests on 4 claims, 2 of them in this topic
Keep robots.txt reachable on every host: 200 with rules, or 404 if there are none
Rests on 4 claims, 2 of them in this topic
Serve one host over HTTPS with a valid certificate and redirect every other origin to it
Rests on 4 claims, 1 of them in this topic
Use data-nosnippet on a span, div or section to keep one detail out of snippets
Rests on 6 claims, 1 of them in this topic
Rests on 7 claims, 1 of them in this topic
Plan releases and fixes around Google's processing times, and judge results only after them
Rests on 11 claims, 1 of them in this topic
Answer planned maintenance and short outages with 503, for a day or two at most
Rests on 11 claims, 1 of them in this topic
Make every navigational link an <a> element whose href holds a real URL
Rests on 6 claims, 1 of them in this topic