JavaScript rendering test
Enter a URL. seoder fetches it twice, once with no scripts at all and once in a browser engine, then counts what only exists in the second version.
Result
The comparison lands here, with both counts side by side.
Fetching and rendering the page. This takes a few seconds.
The check did not finish.
What the two numbers mean
The raw fetch is a single HTTP request with no scripts executed, which is what a crawler that does not render receives. The rendered fetch loads the same URL in a real browser engine and waits for the page to settle. seoder counts words, links and headings in both, and the gap between them is the verdict. Nothing here is guessed from the framework you use or the shape of your markup.
A small gap is normal and harmless. A cookie banner, a search box, a lazily loaded related-items strip: none of that is the content you want indexed. The number to look at is whether the words that describe the page exist in the raw column. If the raw fetch returns two hundred words and the rendered one returns two thousand, the page ships an empty shell and fills it in later.
Why the gap costs you
Rendering is expensive, so crawlers ration it. Google splits the work into two passes, reading the HTML immediately and queueing the render for later, which means everything that depends on scripts is indexed on a delay you do not control. For a news page or a stock status that delay is the whole value. Most AI crawlers skip the second pass entirely and read whatever the server sent, so a client-rendered page reads as nearly blank to them while looking perfectly fine in your browser.
Links are the part people miss. If your category page builds its product grid in the browser, the raw HTML may contain no links to those products at all, and a crawler that does not render has no route to them. The page itself is fine. The pages underneath it are invisible. That shows up in the test as a large gap between raw links and rendered links, which is worth more attention than the word count.
Fixing it without rewriting the site
Start with the smallest change that puts the important content in the first response. Server rendering the route is the direct answer. Prerendering gets you the same result at build time when the content does not change per request, which covers more pages than teams expect. If the route already renders on the server and the test still reports a gap, the usual cause is a component that fetches its own data after mount, and hydration explains where that boundary sits.
Do not reach for serving different markup to crawlers. It is harder to maintain than server rendering and it puts you a short step from the line this entry describes. When you want the rendering verdict alongside the robots rules and the redirect chain, run the full report, and the method page covers what the render blocks and how long it waits.
Common questions
Does Google run my JavaScript?
Yes, on a second pass with its own queue and its own budget. The first pass reads the raw HTML. Anything that appears only after rendering waits for that second visit, which can be minutes or considerably longer.
Do AI crawlers render?
Most of them do not. They take the HTML the server returns and read that, so a page whose text arrives through client-side fetches reads as close to empty to them, even when the robots rules allow the crawl.
The verdict says the content needs JavaScript. Do I have to rewrite the site?
No. You need the important part of the page in the first response. Server rendering the route, prerendering it at build time, or moving one component out of the client bundle are all smaller changes than a rewrite.
Why does the test block images and analytics?
So the comparison is about content rather than page weight. Blocking them makes the render faster and more consistent, and neither one contributes text, links or headings to the counts being compared.