Most problems that look like an SEO problem are really a rendering problem. The page loads fine in your browser. The headline is right there on the screen. And yet Search Console reports the URL as indexed with almost none of that text, or does not index it at all. The gap is usually JavaScript, and specifically the difference between the HTML your server sends and the HTML that exists after scripts finish running.
This matters more now than it did a few years ago, because so many sites are built on frameworks and page builders that assemble content in the browser rather than on the server. If you are commissioning a redesign, or trying to work out why a new site lost visibility the old one had, this is the first thing worth checking.
Crawling and rendering are two separate steps
Google does not process a page in one pass. A crawler fetches the URL and receives whatever HTML the server returns. That response is parsed, links are extracted, and the page is placed in a queue for rendering. Rendering runs the page in a headless version of Chromium, executes the JavaScript, and produces a final DOM. Only then does the indexing step see the content that scripts generated. Google documents this pipeline directly in its JavaScript SEO basics guidance.
Google has said the render queue is usually fast, and in practice most sites are rendered without drama. But it is still a second pass with its own resource limits, and it can fail in ways the first pass cannot. If a script errors out, times out, or depends on a file the crawler was not allowed to fetch, the render produces a page with a shell and no substance. The crawl succeeded. The content never arrived.
The two-response test anyone can run
You do not need a technical background to see the difference. In Chrome, right-click a page and choose View page source. That is the raw server response, before any script runs. Then open DevTools and look at the Elements panel, which shows the live DOM after scripts have executed. Search both for a distinctive sentence from your main copy.
If the sentence appears in the Elements panel but not in the page source, your primary content exists only after JavaScript runs. That is not automatically fatal, but it means every one of your pages depends on the render step completing correctly, every time, for every crawler. On a site where the source contains nothing but a <div id="root"></div> and a script tag, you have moved your entire content strategy onto a dependency you do not control.
Links that are not links
Google discovers new URLs primarily by extracting href attributes from anchor elements. A <div> or <button> with a click handler that pushes a new route may behave identically for a human visitor, but it leaves no crawlable path behind. Google’s own link best practices are explicit that a link needs an anchor tag with a resolvable href to be followed.
This shows up constantly in three places. Framework navigation menus that route entirely in JavaScript. “Load more” buttons on blog indexes and location listings, where everything past the first batch is reachable only by clicking. And filtered directories, where the useful pages exist but nothing ever links to them in HTML. The pages are live, they are in the sitemap, and they still sit at the back of the queue for months because no internal link points at them.
Titles, descriptions, and structured data added after load
Google can pick up a title or meta description that JavaScript writes into the head, because indexing works from the rendered DOM. The practical risk is what happens in the meantime, and what happens when rendering does not complete. A common pattern in single-page applications is that every route ships the same placeholder title in the server HTML, with the real one swapped in on load. When rendering fails, every page on the site has the same title, and Google has nothing distinguishing to work with.
The same applies to structured data. Markup using the Schema.org vocabulary is read from the rendered page, so JSON-LD injected by a tag manager or a component can be detected. It is also the first thing to disappear when a script fails or a consent tool blocks the tag that writes it. For markup that matters to how your listing appears, putting it in the server response removes an entire category of failure.
Blocked resources quietly break rendering
Rendering only works with the files the crawler is permitted to fetch. If robots.txt disallows the directory holding your JavaScript or CSS bundles, Googlebot renders the page without them. This used to be a common “cleanup” instruction in older SEO advice, and it still lingers in inherited robots.txt files. Blocking a script directory on a site that builds its content client-side is functionally the same as blocking the content.
AI search makes the raw HTML matter again
There is a newer reason to care. Googlebot renders JavaScript; many of the crawlers now feeding AI answer engines generally do not, or do so far less completely. They fetch the HTML response and work from what is in it. A page whose substance appears only after client-side execution can be perfectly indexable in Google Search and still be effectively empty to a system trying to summarize or cite it. If being quotable in AI results is part of your plan, server-rendered content is a prerequisite, not an optimization. We cover the structural side of that in our answer engine optimization work.
How to verify what Google actually received
Search Console’s URL Inspection tool settles the question. Run a live test on the URL, then open the crawled page view to see the rendered HTML, the screenshot of what Googlebot drew, and the list of page resources it could not load. The resource list is the part most people skip, and it is where blocked scripts and failed third-party calls show up. Google documents the tool and how to read its output in Search Console Help.
Two things to look for. First, does the rendered HTML contain your body copy, your title, and your internal links? Second, are there resources listed as not loaded, and are any of them your own scripts? If the answer to the second question is yes, fix that before changing anything else.
Fixes, in order of leverage
Render the primary content on the server. Server-side rendering, static generation, or pre-rendering all get the same result: the important text is in the initial response. Most modern frameworks support this. On WordPress and similar platforms it is the default, which is one reason conventionally built sites tend to have fewer of these problems.
Use real anchors for real destinations. Anything you want crawled and indexed should be reachable by an anchor tag with an href, present in the HTML. This also happens to be what assistive technology needs, since semantic elements are what screen readers expose to users. The W3C’s accessibility guidelines and crawlability point in the same direction here, which is convenient.
Give every route a unique server-side title and description. Even if scripts refine them later, the fallback should never be identical across the site.
Do not hide content behind interaction. Googlebot does not click, scroll indefinitely, or fill in forms. Content that appears only after a user action is content Google will not see. Tabs and accordions are fine when the text is in the DOM and merely hidden by CSS; they are a problem when the text is fetched on click.
Unblock the resources rendering depends on. Check robots.txt against what URL Inspection reports as unloadable.
What to ask before you approve a build
If you are hiring a developer or evaluating a platform, a handful of questions will tell you most of what you need to know. Does the server response contain the page’s main content, or an empty container? Are navigation and pagination built from real anchor tags? Does each URL return its own title and meta description from the server? Will structured data be in the HTML or injected by a tag manager? Is there a staging environment where these can be checked before launch rather than after?
These are not exotic requirements. They are the baseline that makes everything else — content, local pages, link building — actually able to work. A site that renders correctly does not automatically rank, but a site that renders incorrectly caps what any amount of good content can achieve. This is part of what we look at during technical review on every web design project, and it is the first pass in any SEO engagement where a site was recently rebuilt.
If your traffic dropped after a redesign and nobody can explain why, start with View Source. The answer is often visible in the first twenty lines.
