What Is Rendering? How Search Engines Process JavaScript Explained
Rendering is the step in which a search engine processes a page’s HTML, CSS, and JavaScript to build the page a browser would show. It sits between crawling, which fetches the raw HTML, and indexing, which stores what the page says. JavaScript is the part that matters most for search, because sites built with JavaScript frameworks can assemble their content in the browser; a crawler that read only the initial HTML of such a page would find little or nothing to index.
Where Rendering Fits
Google’s JavaScript SEO basics describe three phases, crawling, rendering, and indexing, and how a page moves through them:
- “Googlebot queues all pages with a 200 HTTP status code for rendering, unless a robots meta tag or header tells Google not to index the page.”
- “The page may stay on this queue for a few seconds, but it can take longer than that.”
- “Once Google’s resources allow, a headless Chromium renders the page and executes the JavaScript.”
Google then uses the rendered HTML for indexing. The practical consequence is a dependency: content that exists only after JavaScript runs depends on that rendering step, which can wait in the queue, and it is missing if the scripts fail.
How Up to Date Is Google’s Renderer?
Google’s renderer follows current Chrome. In May 2019 Google announced that “Googlebot now runs the latest Chromium rendering engine (74 at the time of this post) when rendering pages for Search,” and added: “Moving forward, Googlebot will regularly update its rendering engine to ensure support for latest web platform features.” Modern JavaScript is therefore not the obstacle it once was. What remains is that rendering takes resources, happens after crawling, and can fail where a script fails.
Other crawlers differ. Google’s own guidance notes that server-side or pre-rendering “is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.”
Choosing a Rendering Strategy
| Approach | What happens | What it means for search |
|---|---|---|
| Client-side rendering | The browser receives minimal HTML and builds the page with JavaScript | Content depends on the rendering step succeeding |
| Server-side rendering | The server runs the code and sends complete HTML for each request | Content is in the first response; more server work per request |
| Static generation | HTML is built ahead of time and served as files | Content is in the first response; changes need a rebuild |
| Hydration | The server sends rendered HTML and JavaScript then adds interactivity | Content is in the first response and the page stays interactive |
The deciding question is whether organic search matters for the pages in question. An application behind a login, where search visibility is irrelevant, can rely on client-side rendering. A site that depends on search traffic gains from any approach that puts the content in the first HTML response, because the main content no longer waits for client-side JavaScript. Google still renders such pages, but the content it indexes no longer depends on scripts running without errors.
Dynamic Rendering
Dynamic rendering detects crawlers and serves them a pre-rendered version while users get the client-side version. Google’s documentation on dynamic rendering now states: “Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements.” It points instead to server-side rendering, static rendering, or hydration. A site that still uses dynamic rendering runs two rendering paths and should plan to move off it.
Bing took a different position in an October 31, 2018 post, explaining that “it is difficult for bingbot to process JavaScript at scale on every page of every website” and recommending “dynamic rendering as a great alternative for websites relying heavily on JavaScript.” The same post said that serving the same content, rendered on the server for bots and on the client for users, “is acceptable and not considered cloaking.” That post is from 2018; server-side rendering or static generation satisfies both engines without the second path.
Three Rendering Failures to Check
- Blocked resources. If robots.txt disallows the JavaScript or CSS files a page needs, Google cannot render it as users see it.
- Content that waits for interaction. Google’s guidance on lazy-loaded content recommends methods that “don’t rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page.” Use native lazy loading or the IntersectionObserver API instead of scroll or click handlers.
- A 200 status for every route. A single-page application that answers every path, including ones that do not exist, with a 200 status turns error pages into pages Google may index.
Testing What Google Renders
The URL Inspection tool in Search Console shows how Google sees a page. Its rendered view offers “a screenshot of how the Google-InspectionTool sees the page,” and the more info panel lists page resources and JavaScript output, which is where blocked files and script errors appear. The live test has a limit: it “cannot predict whether or not the tested version will be considered canonical.” Use it to confirm that the content you expect is present after rendering, and the indexed view to see what Google has stored.