Content depends on JavaScript rendering
rendered_content_dependencyShort answer
The text in the raw HTML is at most half of what appears after JavaScript runs. Google does execute JavaScript, but in a second step that can fail (a script error, a blocked file, a timeout) — and most other search engines and AI crawlers do not run JavaScript at all. Generate the main content on the server: SSR, static generation or prerendering.
Why it matters
Google's own documentation calls rendering an extra stage with its own queue; pages whose content needs rendering are indexed later and more fragilely. Bing's crawler, most AI search bots (OAI-SearchBot, PerplexityBot, Claude-SearchBot) and link-preview bots read the raw HTML. If your product descriptions, articles or prices arrive only via a client-side fetch, those systems see an empty shell — which also feeds the AI access picture.
How Glimana detects it
When rendering is enabled (automatic for SPA-like sites, or always), Glimana compares the word count of the raw HTML with the rendered DOM. The rule fires when the rendered text is at least twice the raw text; the evidence shows the ratio.
How to fix it
Usually a headless or page-builder setup that injects content with JavaScript. Use the builder's server-rendered output, or prerender with a caching plugin that stores the rendered HTML.
Theme sections are server-rendered; the pattern appears with apps that load product content, reviews or recommendations client-side. Prefer apps that render in Liquid, or accept that the injected part is invisible to non-rendering crawlers.
Next.js/Nuxt/SvelteKit with SSR or static generation; for existing SPAs, a prerender service that serves rendered HTML to bots. Keep the HTML response self-sufficient for the main content; hydrate the rest.
How the fix is verified
Re-crawl with rendering; the task closes when raw and rendered text are within a factor of two.