Free tools / render-check
Render Check
free · no signupFetch a page with no JavaScript executed and see what the crawler actually receives — title, h1, word count, and whether the body is empty until your scripts run.
Check a page
live check: in build
This check runs on our server, and it has to. Your browser cannot read another site’s HTML — cross-origin responses are unreadable without CORS headers a normal page never sends. Any tool claiming to check your URL privately in your browser is either proxying it anyway or not checking it.
raw fetch · no JavaScript executed
exampleURL
Refetch with a crawler user-agent
Server-side by necessity, not by preference. We fetch the URL you enter and read the bytes that come back. (We do not execute your page’s JavaScript — that is the whole point of the check.)
Why this tool exists
Your visitors run JavaScript. The fetch that decides whether you get cited may not.
A site can be flawless in a browser and close to blank to whatever fetched it. If your page ships an empty <div id=”root”> and builds the content client-side, then a plain HTTP fetch — no browser, no JS engine — receives a shell: a title, some tags, and almost no prose. Everything a reader would call “the page” arrives later, from JavaScript that a plain fetch never runs.
This tool shows you that fetch. Raw HTML, no JavaScript executed, exactly what came back over the wire.
Be clear about what the result means, because most content on this subject is not. Render Check reports the no-JS view. It does not report how ChatGPT, Perplexity, Gemini or anything else renders your page — engines differ, they change, and the ones that have documented their behaviour have documented it thinly.
So treat the no-JS view as the floor. It is the worst case and the cheapest case, which makes it the one to assume: if your content survives a fetch with no JavaScript, every engine can read it, whatever it does. If it doesn’t, whether you get read depends on a rendering decision made inside somebody else’s crawler — not a thing you can influence, log, or appeal.
What “empty pending JS” actually looks like
Not zero words. A client-rendered page usually returns some chrome and none of the content the page is about. That is why these four fields are read together, never alone:
01
Word count, without the scripts
Body text with script, style, noscript and template removed and whitespace collapsed. Forty to two hundred words is the shell signature.
02
A correct title with no h1
Titles are usually server-rendered even on client-rendered apps. A right title above a missing h1 means the heading is being written by JavaScript.
03
A meta description that is the site default
The same sentence on every URL is what a shell serves before the router decides which page you asked for.
04
A canonical pointing at the wrong URL
Or missing entirely. Client-side routers frequently set it after hydration, which is after the fetch ended.
How to read the result
- Compare against what you see in a browser. The gap between the two is the part of your page that only exists after JavaScript runs.
- Check more than one URL. A product page, an article and the homepage are usually three different templates with three different answers.
- A field marked
NOT MEASUREDis not a pass and not a zero — it means the check did not return that field, and the reason is printed next to it. - If the plain fetch is
200and the crawler-user-agent fetch is403, the problem is at your edge, not in your HTML. Start with your CDN or WAF bot rules.
The block robots.txt cannot show you
robots.txt is a request that a well-behaved crawler honours. Your CDN, WAF or bot-management layer sits above it and simply answers 403 — and it can do that to a crawler user-agent while serving your browser normally. Nothing in robots.txt describes this, and nothing in your analytics reports it, because the request never became a session. That is why the second fetch exists: same URL, crawler user-agent, from our server. A 200 on the plain fetch and a 403 on the bot fetch is a real and common pair, and it is invisible to any robots-only checker.
Limitations, stated plainly
We are not the crawler. Our request carries a bot’s user-agent string from our own IP, so an edge rule that filters by verified crawler IP range may treat us differently than the real agent — this catches obvious blocks, not every one. We fetch once; a page behind a slow origin, a rate limiter or geo-routing can answer differently the next minute or from a different country. We read one URL, not the template behind it. And HTML a crawler can read is a precondition for being cited, never a cause of it.
Fair questions.
The same five answers feed this page’s own FAQPage markup — one array, one source.
Can ChatGPT read a JavaScript-rendered website?
That depends on which OpenAI agent fetched the page and how it was configured that day — it is the operator’s decision, it is documented thinly, and it changes. This tool answers the question you can actually control: whether your content is there before any JavaScript runs. If it is, the question stops mattering. If it isn’t, you are relying on someone else’s renderer.
Does this tool tell me how ChatGPT or Perplexity renders my page?
No, and any tool claiming to is guessing. We fetch your URL without executing JavaScript and report what came back. Reading that as “what ChatGPT sees” is the exact overclaim this page refuses to make.
Why does the check run on your server instead of in my browser?
Because a browser cannot read another site’s HTML. Cross-origin responses are unreadable without CORS headers a normal page never sends. Any tool claiming to check your URL “privately in your browser” is either proxying it anyway or not checking it.
My word count is low but the page looks fine — what do I fix?
Move the content into the HTML the server sends. Server-side rendering, static generation, or prerendering for crawlers all get you there; which one depends on your stack. The test is unchanged afterwards: fetch the URL with JavaScript disabled and see whether the page still says what it is about.
Does passing this check mean AI engines will cite me?
No. Readable HTML is a precondition, like crawler access — it removes a blocker, it does not create a mention. Whether an engine quotes you depends on what the page says and whether it answers the question being asked.
Readable is the floor, not the result.
See whether AI actually mentions your brand.