Does your content survive without JavaScript?
Some storefronts put the price, the variants or the whole product block behind JavaScript. A plain fetch then sees a page that looks complete and is not. This loads it in a real browser and compares what the browser builds against the raw HTML.
Runs a real browser on one page and fetches the raw HTML to compare. Costs 5 credits per run; nothing is stored.
How this check works
Shipwork fetches the page the way a crawler without JavaScript does, then loads the same address in a real browser and measures the text each one sees. It reports how much content only appears after JavaScript runs, any JavaScript errors, changes to the status or the title, the transfer weight and the request count.
What the JavaScript rendering SEO check compares
The check fetches the page the way a crawler without JavaScript does, then loads the same address in a real browser and measures the text each one sees. It reads the raw status, title and visible text, then the browser's status, title, request count, transfer weight and any console errors. Finally it compares the two views of the page.
It checks one page per run. Content is treated as JavaScript-only when the browser sees at least 250 more characters than the raw fetch and at least 1.35 times as much. That pair of thresholds keeps small differences from being reported. The run needs the browser, which is why it is the heaviest check and costs credits.
How to read the rendered result
A clean result means the browser and the plain fetch saw the same page: the same status, the same title, no console errors and comparable text. That is the best available evidence that a non-rendering crawler sees your content. It does not prove that every word was indexed, and rendering by search engines is delayed and not guaranteed.
A JavaScript-only finding means a non-rendering crawler would miss the extra content. On a product page that can be the price, the variants or the buy controls. Console errors mean the page throws in a browser, which can stop later content from appearing. A status or title change after JavaScript runs is informational, but worth checking against what you expect searchers to see.
Common causes and why they matter for search
Storefronts often build the product block client-side, inject prices from a script, or load reviews and recommendations after the first paint. A crawler without rendering then sees a page with a title and little else. Even with rendering, late and fragile content is less reliable than content present in the initial HTML.
A page that transfers several megabytes or makes a very large number of requests is flagged as heavy. That affects how quickly the page becomes usable and how much a crawler has to process. The thresholds are fixed and generous, so a flag is a prompt to look rather than a measured score. This check does not report field data or Core Web Vitals.
How to fix JavaScript-only content
Move content that matters into the initial HTML where the platform allows: product name, price, availability and the main description. Render the parts a crawler needs on the server or at build time. Keep client-side scripts for enhancement rather than for the core content. Then rerun the check to confirm the raw and rendered text now match.
On Shopify, theme sections and apps can move content behind JavaScript; test the actual product template and reduce what is injected late. In WooCommerce, check whether a page builder or a lazy-load plugin is holding back the main content. Fix console errors first, since a single error can prevent the rest of a script from running.
When to use related rendering checks
Use the indexability check when a rendered page is still not appearing, and the JavaScript check for a quick look at script-dependent content. Use Core Web Vitals when the concern is loading and interaction rather than crawlability.
For a site-wide view, the deep crawl reads many URLs but does not render them, so pair the two: find the pages at scale, then render the important templates. The JavaScript SEO article explains how rendering fits into crawling.
Questions
Why does JavaScript-only content matter?
How is this different from the free checks?
Why does it cost 5 credits?
How do I check if my content needs JavaScript?
Does Google render JavaScript pages?
Why does the rendered check cost credits?
Why does my title change after JavaScript runs?
Does this check measure Core Web Vitals?
Keep reading
What this reads
- Loads the page in a real browser and compares it against the raw HTML.
- Reports the characters a crawler without JavaScript would miss, plus JavaScript errors.
- Runs from outside your network: the same page a visitor and a crawler each receive.
Cool, just ran an audit and got some insights! Let’s see if I can fix them :)
Whoah! this site is crazy, nothing to roast at all
cool as heck, tried it on my blog and the insights it gave are helpful and not bluff.