If your content loads with JavaScript, most AI crawlers never see it. We render your page the way a browser does, then fetch it again as the crawlers themselves, and show you exactly which blocks never reach them.
This is a real shape of result: the page reads perfectly in a browser, and the part a buyer would ask about is the part that never arrives.
ConsequenceAsked “how much are the Premium Travel Headphones?”, an assistant reading this page cannot answer. It will quote a retailer who publishes the number in HTML instead.
Once the way a browser does, once the way a crawler does. Then we diff them.
A real browser loads the page, runs your JavaScript and waits for it to settle. This is the human view.
The same URL requested as GPTBot, ClaudeBot and PerplexityBot, taking the HTML exactly as your server sends it.
What exists in one and not the other, with a screenshot of each so you can see the gap rather than take our word for it.
bots fetched separately — they do not all behave the same way
screenshots per check, so the difference is visible not just counted
changes needed on your site to run the comparison
The server sends a shell and the framework fills it in.
Someone else's script owns the content, and it loads late.
It exists, but only after a click nothing automated will make.
The visitor gets one thing; an unidentified request gets another.
Run the check on any URL. You get the rendered view, the crawler view, a screenshot of each, and a list of what did not survive the trip.
Google does. This check is not about Google. The systems fetching your page to build an answer largely take the raw HTML response and work with that — no browser, no script execution, no second pass. Whatever is not in that response is not in the answer.
We render the page in a real browser, and separately request the raw HTML as the crawlers themselves. Then we diff the two and show you the specific blocks that exist in one and not the other, with the actual text. You are reading the sentences a crawler will never receive.
No. You have to make sure the content that answers questions about the page is in the HTML response. Server-side rendering, static generation or pre-rendering for those parts is enough; the interactive layer can stay exactly as it is.
It depends where the text lives, not whether it is visible. Markup that is in the HTML and merely hidden by CSS is read fine. Content fetched when the tab is clicked is not there at all for something that never clicks.
They are. Timestamps, cookie banners, personalised greetings and widget state are expected to differ and are not worth acting on. What matters is substantive text — descriptions, specifications, prices, the answer to the question the page exists for.
Then your bot protection served them a challenge page and we captured that instead of your content. It is a real finding, not a glitch: what we received is what a crawler receives. The fix is on the crawlability side — let the crawler through, then re-run this.
Because infrastructure treats them differently. The same page can return your content to one user agent and a challenge to another, and a check that only asked once would report whichever answer it happened to get.
No. This measures whether the words reach a machine at all. Whether they answer anything is a separate question — that is Content Coverage for the topic as a whole, and Prompt Fit for one specific question.
No. Static generation works, pre-rendering the important routes works, and moving a section into the initial HTML often works on its own. Rendering the whole application on the server is the largest option, not the only one.