Google renders JavaScript-heavy pages from their HTML, CSS and JavaScript as a browser would, using the latest version of Chromium.
Speaker Cherry PrommawinIn Day 1, 11:45 · How Search works and where's AI?Evidence transcript
Knowledge base v2.13.0 · Community edition · data through 2 October 2026
Topic · Rendering and JavaScript
Google renders nearly all pages with headless Chromium to index what users see, said it would miss most of today's web without it, and, extending Day 1's point that Gemini uses Google's crawling, said pages are rendered the same way for Gemini training (said at the event, not in Google's docs). Rendering is a detached, expensive system that fetches JavaScript, CSS and API calls, but not images or videos, through the crawler; Google's documentation queues every page that returns 200 unless it carries noindex, and content missing from the final DOM cannot be indexed. The renderer does not scroll or click and lacks permission-based browser APIs and WebGL; Google said it renders in a viewport about 10,000 pixels tall instead, a figure its documentation does not give (it speaks of a 'viewport expansion' that can miss infinite content). The documentation sets no upper limit on the render-queue wait (a community speaker said seconds to a couple of minutes), and Google said content can be missing because it has not appeared in time; a community speaker added that slow APIs can leave unresolved placeholders in the snapshot. Author’s view: Erin Sparling's remark that content indexable without JavaScript 'can pass through without rendering' does not mean such pages skip rendering; it means content in the raw HTML does not wait for the slower rendering pass. Day 3 put rendering in time: Google renders a page either right after crawling or later through a queue, so content added by JavaScript is typically seen by indexing within a few hours and at worst within weeks, and Google said its logs show everything in the queue rendered within weeks (said at the event). Google's own speaker also said he would not claim that Google renders every URL on the internet (not in Google's docs). Author’s view: Google's JavaScript guide says every page returning 200 is queued for rendering, and queued is not rendered, so critical content belongs in the server HTML. Day 1's second recording added that Google renders JavaScript-heavy pages from their HTML, CSS and JavaScript as a browser would, with the latest Chromium. A second recording of Day 2 confirmed Natalia Venditto's point that a server-rendered app reframed into the host page is fully indexable (said at the event), and John Mueller said Google drops a page with a noindex in its HTML without processing its JavaScript, while Google's guide says it may skip rendering.
Things in this topic 14
Counts are claims that name the thing. All things
What to do
Google renders JavaScript-heavy pages from their HTML, CSS and JavaScript as a browser would, using the latest version of Chromium.
Speaker Cherry PrommawinIn Day 1, 11:45 · How Search works and where's AI?Evidence transcript
Google's Inside Googlebot post warns that bloated inline base64 images, large blocks of inline CSS or JavaScript, or megabytes of menus can push a page's text or structured data past Googlebot's 2MB cutoff, and advises moving heavy CSS and JavaScript to external files and placing meta tags, the title, the canonical and essential structured data high in the HTML.
Publisher Search Central blog (31 March 2026)Annotates Day 1, 14:05 · How crawling works
Used byrequirement DEV-PRF-04
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
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 SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence slide photo, transcript
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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence slide photo, transcript
After processing, an indexable page is placed in Google's render queue to wait for rendering.
Speaker Rebecca YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence slide photo, transcript
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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence slide photo
Used byrequirement DEV-REN-02
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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence slide photo
Used byrequirement DEV-REN-03
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
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 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
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
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 SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript
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 SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript
Used byrequirement DEV-IDX-11
Google renders pages with Chromium, the browser technology that also underlies Chrome, Edge and other Chromium-based browsers.
Speaker Erin SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 SparlingIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript
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
Google's renderer is a headless Chromium that runs the page's JavaScript.
Speaker Rebecca YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript
Used byrequirement DEV-REN-06
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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence 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 YuIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript
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 said a server-rendered app reframed into the host page is fully indexable.
Speaker Natalia VendittoIn Day 2, 10:40 · Lightning session D: Rendering and JavaScriptEvidence transcript
Used byrequirement DEV-REN-01
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 SparlingIn Day 2, 11:15 · What is Google friendly 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
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
Content that loads only when a user clicks an element is not supported in the way Google renders pages for indexing.
Speaker Erin SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence 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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence slide photo, transcript
Used byrequirements DEV-REN-03, DEV-URL-07glossary term Viewport expansion
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 SparlingIn Day 2, 11:15 · What is Google friendly JavaScriptEvidence transcript
Used byrequirement DEV-REN-08
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
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 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 CentralAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
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 CentralAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
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 CentralAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
Used byrequirements DEV-PRF-02, DEV-REN-01glossary term Render queue
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)Annotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
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
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 CentralAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
Used byrequirement DEV-REN-10glossary term Shadow DOM
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 CentralAnnotates Day 2, 11:15 · What is Google friendly JavaScript
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)Annotates Day 2, 11:15 · What is Google friendly JavaScript
Used byrequirement DEV-URL-07glossary term Viewport expansion
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 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 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 CentralAnnotates Day 2, 11:15 · What is Google friendly JavaScript
Used byrequirement DEV-REN-06
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
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 AnjroAnnotates Day 2, 10:40 · Lightning session D: Rendering and JavaScript
Used byrequirement DEV-REN-10
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
Google estimated that rendering takes seconds when done right away and hours when the page waits in the queue, with an end point of days to weeks.
Speaker Gary IllyesIn Day 3, 15:45 · How long does it take to..?Evidence slide photo, transcript
Used byglossary term Render queue
Google renders pages in two ways: immediately after crawling, or later through a queue-based process that runs elsewhere.
Speaker Gary IllyesIn Day 3, 15:45 · How long does it take to..?Evidence transcript
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
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.
“we keep saying that we render every single URL on the internet. I would say that that's not true”
Speaker Gary IllyesIn Day 3, 15:45 · How long does it take to..?Evidence slide photo, transcript
Used byrequirement DEV-REN-01
According to Google's logs, everything in the rendering queue gets rendered within weeks.
Speaker Gary IllyesIn Day 3, 15:45 · How long does it take to..?Evidence slide photo, transcript
Used byglossary term Render queue
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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, 7 of them in this topic
Have all indexable content in the DOM after load, without clicks, typing or scrolling
Rests on 8 claims, 5 of them in this topic
Do not add, change or remove robots meta tags with JavaScript
Rests on 9 claims, 5 of them in this topic
Make rendering robust: no slow API dependencies and no unresolved placeholders
Rests on 8 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
Lazy-load with native lazy loading or an IntersectionObserver, never with scroll events
Rests on 6 claims, 3 of them in this topic
Back infinite scroll and load-more buttons with paginated URLs
Rests on 6 claims, 3 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, 2 of them in this topic
Keep indexable content out of iframes, and check web components in the rendered HTML
Rests on 4 claims, 2 of them in this topic
Use the Google-Extended robots.txt token to control Gemini training and grounding
Rests on 8 claims, 1 of them in this topic
Monitor Crawl stats and server logs for verified Googlebot traffic
Rests on 13 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
Make JavaScript-generated content render quickly
Rests on 5 claims, 1 of them in this topic
Keep each HTML response well under 2 MB and put the main content and JSON-LD early
Rests on 2 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