Rendering: is the content really there when Google looks?

Google Search runs JavaScript with an evergreen version of Chromium, and processes JavaScript web apps in three phases: crawling, rendering and indexing. Googlebot checks robots.txt, fetches the URL, and queues pages with a 200 status for rendering unless a robots meta tag or header says not to index them. The page may wait in that queue for a few seconds or longer, and a headless Chromium then renders it. Google also notes that server-side or pre-rendering remains a good idea because not all bots can run JavaScript (Understand JavaScript SEO Basics).

Google’s troubleshooting guide lists the traps. The rendering service does not keep cookies, Local Storage or Session Storage across page loads. Googlebot declines permission requests such as camera access. URL fragments cannot be relied on to load different views, so single-page apps should use the History API. Error pages that return 200 can be indexed as soft 404s, so a real error status, or a redirect to one, is needed (Fix Search-Related JavaScript Problems). Lazy-loaded content must load when it enters the viewport, because Google Search does not interact with your page by scrolling or clicking (Fix Lazy-Loaded Website Content).

We cover JavaScript SEO as part of technical SEO. On the technical SEO page it sits under the question of whether the content is really there: JavaScript, lazy loading and blocked resources.

Raw HTML is what the server returns in response to a request. Rendered HTML is what exists after scripts have run. For a classic or server-side rendered page the two are close. Some JavaScript sites use an app shell, where the initial HTML does not contain the content and Google must execute JavaScript to see it (Understand JavaScript SEO Basics). Google parses the rendered HTML for links again, queues what it finds for crawling, and uses the rendered HTML to index the page, so anything that only appears after scripts run depends on rendering succeeding.

Differences matter most for signals that must be unambiguous. Google says the canonical URL is best set in the HTML source, and that JavaScript should not change it to something else. If the canonical can only be set by script, it should be left out of the original HTML (How to Specify a Canonical). The same care applies to anchor text inserted by JavaScript, which Google advises checking in the rendered HTML with the URL Inspection tool (SEO Link Best Practices for Google).

The URL Inspection tool lets you compare the two. A live test shows the raw HTML returned, the HTTP headers, a screenshot of the rendered page, JavaScript console output and the page resources loaded. We cover rendered versus raw HTML as part of technical SEO. When we build, the principle on our web development page is content in the HTML, with JavaScript kept minimal.

Diagnosis starts with Google’s own evidence. URL Inspection reports discovery, crawl and indexing status for a URL, and the Crawl Stats report shows response codes and host status across a property. The status code itself is a signal: 2xx content may be considered for indexing but is not guaranteed to be indexed, 4xx URLs are not indexed and indexed ones are removed over time, and 5xx and 429 responses make Googlebot slow down (How HTTP Status Codes Affect Google’s Crawlers). Google follows up to 10 redirect hops, and treats a 301 as a strong signal and a 302 as a weak one for which URL should be processed.

Mobile parity is a further check. Google uses the mobile version of a site’s content for indexing and ranking, so it recommends using the same robots meta tags on mobile and desktop, not lazy-loading primary content on user interaction, not blocking resources the mobile pages need, and keeping the content equivalent (Mobile-first Indexing Best Practices). A noindex on the mobile page can stop the page being indexed.

We cover technical diagnostics as part of technical SEO, and our approach to it is stated plainly on the site: locate the actual fault, not the symptom the tool reported.

Core Web Vitals measure real-world loading performance (Largest Contentful Paint), responsiveness (Interaction to Next Paint) and visual stability (Cumulative Layout Shift). Google recommends aiming for LCP within 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, and says its core ranking systems seek to reward a good page experience (Understanding Core Web Vitals and Google search results).

Google also puts the weight in context. There is no single page experience signal, and good Core Web Vitals reports do not guarantee top rankings. Google says it always seeks to show the most relevant content, even where page experience is sub-par, and that chasing a perfect score purely for SEO may not be the best use of time (Understanding Google Page Experience). Speed has a separate crawling effect: if a site responds quickly and consistently, Google can raise the crawl capacity limit, and slow responses or server errors lower it (Crawl Budget Management).

We cover performance as part of technical SEO, deliberately as one input among many. Our technical SEO FAQ says performance matters but is one input, and that most serious technical problems sit in crawling, indexing, rendering and architecture. Where performance work means development, it falls under ongoing development.