Content That Depends on JavaScript

A browser running JavaScript and a crawler reading raw HTML can see two different pages. Most of the time that gap is harmless. Crawl Cove's content-depends-on-js check exists for the times it is not: when something a search engine needs to index only exists after a script runs.

What this finding means

This check compares the raw HTML a no-JavaScript crawler receives against the fully rendered page, and fires when the rendered version differs in a way that matters: structured data that only appears after rendering, a <title> that JavaScript changes or injects, or a large jump in visible text between the two versions. It only runs on pages that actually went through a rendered pass; a page that was never rendered gets no finding at all, rather than a guess.

A real finding looks like this:

rendered DOM added 1 JSON-LD block absent from raw HTML; rendered visible text is 3,842 chars vs 612 raw (+3,230, >= 2x and >= 500 chars)

One finding per page, naming exactly which signal or signals triggered it.

Why it matters

Content that exists only after JavaScript runs depends on a second, slower rendering pass that is not guaranteed to happen the same way every time. Whatever the crawler misses on the fast first pass may be indexed late, indexed incompletely, or in some cases missed entirely, and structured data is especially exposed here: if it only appears after rendering, a system reading raw HTML never sees it at all.

How to fix it

1. Identify what the finding says actually changed: injected structured data, a changed title, or a large text jump are three different problems with the same underlying cause.
2. Move critical content into the initial HTML response. Server-side rendering (SSR) generates the full page, including this content, on the server before it reaches the browser or crawler.
3. If a full SSR rewrite is not practical, pre-render instead. Generating static HTML for content that does not change per visitor gets the same result for search engines without restructuring the whole application.
4. Structured data specifically should be emitted directly in the server-rendered HTML, not injected by a client-side script, since it is exactly the kind of content this check is built to catch.
5. Re-crawl the page once the fix ships to confirm the raw and rendered versions now agree.

False positives and edge cases

• A page that was never rendered gets no finding, never a guessed one. If the render pass did not run (for example, a missing browser dependency), the check returns nothing rather than inventing a result it cannot support.
• Small client-side interactivity is not what this looks for. The check only fires on a large text jump (at least double the raw length and a real character-count minimum), a title change, or new structured data, not on minor DOM tweaks that leave the actual content unchanged.
• This is a risk finding, not proof indexing failed. Modern search engines can render JavaScript; this check flags the pages where the outcome depends on that second pass actually happening, which is a real but not certain risk.

Related reading

For the check that flags a page with very little content at all, a different way a page can under-deliver on what search engines can actually read, see Thin Content.

To check the rest of a site for the same dependency, including the canonical and robots tags this check does not compare, see how to run a JavaScript SEO audit.