A site built on a JavaScript framework or a website builder can look finished in a browser and still show a thin or blank page to a crawler that has not run the scripts yet. Google publishes exactly how it works through JavaScript pages, and the order of steps is the part most owners miss, because the step that reads your content is not the first one.
How does Google process a JavaScript page?
Google processes JavaScript web apps in three main phases, and Google's JavaScript SEO basics guide names them exactly: "Crawling," "Rendering," and "Indexing." Googlebot fetches a URL from the crawl queue after checking robots.txt, then looks for content in the raw HTTP response. The same guide notes that "crawling a URL and parsing the HTML response works well for classical websites or server-side rendered pages where the HTML in the HTTP response contains all content," but some sites "use the app shell model where the initial HTML does not contain the actual content and Google needs to execute JavaScript before being able to see the actual page content that JavaScript generates." A site builder or framework that renders everything in the browser after load falls into that second group.
When does rendering actually happen?
Rendering happens later, in a separate queue, and the wait is not fixed. Google states: "Googlebot queues pages for both crawling and rendering. It is not immediately obvious when a page is waiting for crawling and when it is waiting for rendering." On timing, the guide says: "The page may stay on this queue for a few seconds, but it can take longer than that." Only once "a headless Chromium renders the page and executes the JavaScript" does Google read the result, and the same page says: "Google also uses the rendered HTML to index the page." Between the crawl and that render, anything that only appears after your scripts run is invisible to the index.
Does Google recommend server-side rendering?
Google frames it as worth doing regardless of the rendering delay above. The basics guide says: "Keep in mind 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." That line applies whether the framework is React, Vue, or a page builder with a JavaScript-heavy theme.
What does Google say about dynamic rendering?
Dynamic rendering is presented only as a stopgap. The dedicated page on dynamic rendering opens with the title itself, "Dynamic rendering as a workaround," and states: "Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements." The setup detects crawlers by user agent and routes them to "a server-rendered version without JavaScript" while people browsing the site still get "the client-side rendered version." Google's own preference is stated directly: "Instead, we recommend that you use server-side rendering, static rendering, or hydration as a solution."
What common problems keep content out of Search?
Google's troubleshooting page lists several patterns worth checking. Single-page apps that handle routing in JavaScript can send a 200 HTTP status code for a missing page instead of a 404, letting broken pages get indexed as real ones. Routing through URL fragments (the part after a #) will not be discovered, since the AJAX-crawling scheme "has been deprecated since 2015." Content held in Local Storage, Session Storage, or cookies from a previous visit will not survive, since the rendering service "does not retain state across page loads." Permission-gated features such as camera access block Googlebot outright, since it never grants prompts. Web components must expose content through a <slot> element, or the flattened HTML Google indexes will leave it out. A paywall that ships full content in the HTML and hides it with JavaScript afterward is not a real restriction.
How do I check my own site right now?
Look at the HTML your server sends before any script runs, either with curl on the page's URL or by using "view source" in the browser rather than the regular inspector. Pick one sentence you know is on the page, a product description, a service line, an address, and search that raw HTML for it. If the sentence is there, it arrived with the initial response. If it is missing, that content only exists after JavaScript runs in a browser, and it depends on the rendering step described above to reach the index at all. Google's own URL Inspection Tool shows the same thing from the rendered side, which is useful for confirming what actually made it through.
Does this apply to other crawlers too?
For PerplexityBot there is no published answer: Perplexity's documentation does not state whether it executes JavaScript. What we can say, as our own reasoning rather than a quote from either company, is that content already present in the initial HTML does not depend on any crawler's ability to run scripts. Fixing the raw-HTML gap for Google removes the same uncertainty for every other bot at once.
Our free GEO audit runs 10 buyer questions three times each through Perplexity and Google AI Overviews, 60 answers in total, and the method includes a rendering check: is the main content in the HTML, or only after JavaScript runs.