Crawler View
Fetches a URL server-side and shows exactly what a crawler gets before JavaScript executes: the visible words, the headings, the internal links, the structured data, and the signals that a page is really an empty shell waiting to be assembled in the browser.
- Shows the text and links present without JavaScript
- Flags empty mount points and framework payloads
- States plainly what it cannot check
How to use it
- Paste any public URL. The page is fetched server-side, because a browser is not allowed to read another origin’s HTML.
- Read the verdict first: served, partly assembled, or a shell.
- Then check the lists. If a heading, a link or a schema block matters to you and is not there, it is being added by JavaScript.
What the numbers mean
- Shell
- The HTML contains almost no words plus markers of a client-rendered app: an empty mount element, a framework data payload, a stack of scripts. Google will usually still render it, on a second pass and on its own schedule. Every crawler that does not execute JavaScript sees the shell and stops.
- Framework payload
- A blob of JSON in the HTML that the app turns into content. It is content waiting to be rendered rather than content, and a crawler reading raw HTML gets no value from it.
- Structured data in the HTML
- JSON-LD injected after render may be read on a later pass or not at all. If it is not in the raw HTML, it is not there on the crawl that decides how fast you get indexed.
Questions
Does a thin result mean Google cannot see my page?
No, and that is the confident version of this claim that is wrong. Google does render JavaScript, on a second pass, on its own schedule, and not always. A thin result means two narrower things: what every non-executing crawler sees, which now includes most AI answer engines, and what Google gets on the first pass, which is the one that decides how quickly you are indexed.
Why does it not show the rendered page?
Because there is no headless browser behind this, and claiming to render when you do not would be exactly the kind of thing this site exists to argue against. It reports the bytes the server returned, accurately.
Does this store the page it fetched?
No. The fetch endpoint stores nothing, logs nothing and follows only the URL you gave it. It is the same server hop the SERP Audit uses, and it is the only part of this site that touches one.
Guides that use this tool
- Website not showing up on Google: work through this in order
- How long does Google take to index a new page?
- How to get named in AI answers
- The robots.txt mistakes that quietly cost you indexing
- Canonical tags: what they do, and the four ways they backfire
- JavaScript and search: what gets indexed, and what gets deferred
- "Alternative to X" pages, and why they beat comparisons
- Core Web Vitals: small ranking factor, large conversion factor
- Why your Lighthouse score disagrees with your users
- hreflang, and whether you actually need it
- Soft 404s: pages that say 200 and mean nothing
- What to do first, in order, on a site with nothing
- How to see your page the way a crawler does
Other free tools
- Search Console Analyzer: Drop your export, get a verdict
- SERP Audit: Paste a URL, get the fix list in priority order
- Schema Generator: Valid JSON-LD, with the guard rails on
- SERP Preview: Pixel-accurate, not character-counted
- Position Value Calculator: What is rank 4 actually worth?
- Schema Inventory: Which structured data is on which page
- Internal Link Graph: Which pages nothing points at
- OG Image Generator: And what it looks like once each platform crops it
- Noise or Signal: Did that actually do anything?
- Programmatic Set Analyzer: How many of those pages actually work?
- Log File Analyzer: What Googlebot actually crawled