Open your site, right-click, & choose view source. If the main heading & body copy are missing from what you see, you have a JavaScript SEO problem, whether or not it has shown up in your traffic yet.
That view-source output is the initial HTML response. It is what a crawler receives first, & for a long time it was all a crawler received. Search engines now execute JavaScript, but they do it in a second pass, on their own schedule, with their own constraints. Understanding that two-stage process explains almost every JavaScript SEO issue you will encounter.
How crawlers actually process a JavaScript site
The sequence runs roughly like this. A crawler fetches the URL & reads the raw HTML. It extracts any links & metadata it finds there & queues them. If the page appears to need rendering, the URL joins a separate render queue. Later, a headless browser executes the JavaScript, produces the final DOM, & that rendered output is what gets indexed. Any links discovered only at that stage go back into the crawl queue & start the cycle again.
Three consequences follow, & they are the source of most problems:
- Delay. Rendering is not instant. For a news site publishing time-sensitive content, waiting for the render queue can mean missing the window entirely.
- Slower discovery. If your internal links exist only after rendering, each level of your site requires another full render cycle before the next is even found. Deep sites crawl very slowly this way.
- Failure is silent. If a script errors, a third-party API times out, or a resource is blocked in robots.txt, the render produces an incomplete page. Nothing alerts you. The page simply indexes with less content than it should have.
Assume rendering will sometimes fail. Design so that the failure mode is a slightly less rich page, not an empty one.
The failures we find most often
These come up repeatedly in audits, across frameworks.
- Links that are not links. A clickable div with an onClick handler works for users & is invisible to crawlers. Internal links must be anchor elements with a real href. This alone accounts for a large share of orphaned pages on single-page applications.
- Content behind interaction. Copy inside accordions, tabs or modals is generally fine if it exists in the DOM. It is not fine if it is fetched only when the user clicks. Load it into the DOM, hide it with CSS if you must.
- Blocked resources. If robots.txt disallows the directory holding your JavaScript bundle, the renderer cannot build the page. Check this explicitly, because it is invisible in every other test.
- Client-side only metadata. Titles, meta descriptions & canonical tags injected by JavaScript are usually picked up eventually, but they are fragile & often inconsistent. Ship them in the initial HTML.
- Soft 404s. A route that fails to fetch data & renders an empty shell still returns a 200 status. Search engines see a valid but empty page. Return a real 404 status for missing content.
- Infinite scroll with no URLs. If page two of your listings has no addressable URL, its contents cannot be indexed. Pair infinite scroll with paginated URLs behind the scenes.
Choosing a rendering strategy
There is no single correct answer, only a fit between content type & approach.
Static site generation builds HTML at deploy time. It is the strongest option for SEO & speed, & it suits content that changes on a predictable schedule: marketing pages, blogs, documentation, service pages. If your content does not change per user or per minute, this should be your default.
Server-side rendering builds HTML per request. It suits content that is fresh or personalised, such as product listings with live stock or dashboards. It costs more in server resources & needs sensible caching, but crawlers receive complete HTML on the first fetch.
Incremental regeneration sits between the two. Pages are static but regenerate on a defined interval or on demand. For large catalogues that update irregularly, this is often the pragmatic choice.
Pure client-side rendering is appropriate for genuinely application-like interfaces sitting behind a login, where indexation is irrelevant. It is a poor choice for anything you want found in search.
A common & sensible hybrid: render the marketing & content layer statically, & keep the authenticated application client-side. The two have different requirements & there is no reason to force one strategy on both.
How to test properly
Do not rely on a single tool or a single URL. Build a small routine.
- Use the URL Inspection tool in Search Console & read the rendered HTML, not the screenshot. Confirm the heading, body copy, canonical tag & internal links are all present.
- Disable JavaScript in your browser & load a page from each template. Whatever remains is your guaranteed baseline.
- Crawl the site twice with a desktop crawler, once with rendering enabled & once disabled, then compare the URL counts. A large discrepancy tells you exactly how much of your site depends on rendering for discovery.
- Check the browser console on production for script errors. Errors that seem cosmetic to users can be fatal to a renderer.
A note on hydration & interactivity
Server rendering solves discovery but can introduce a responsiveness problem. If the server sends complete HTML & the client then downloads a large bundle to attach event handlers, the page looks ready before it is usable. Users tap & nothing happens. That shows up directly in interaction responsiveness metrics.
Mitigations include splitting bundles by route, deferring hydration for components below the fold, & shipping less JavaScript overall. The last one is unfashionable & remains the most effective.
Where to start
If you are auditing an existing site, work in this order: confirm internal links are anchor elements, confirm metadata is in the initial HTML, confirm scripts are crawlable, then decide whether the template needs a rendering change at all. Many sites need three small fixes rather than an architectural rewrite.
If you are planning a new build, decide the rendering strategy before choosing the framework. Retrofitting server rendering onto a mature client-side application is expensive & rarely done well under deadline pressure.
We work through this with development teams as part of our technical SEO engagements, usually alongside content planning so the structure & the content are designed together. Take a look at our work, or send us your stack & we will tell you where the risk sits.