Googlebot simulator: see a page the way Google renders it, JavaScript included
Paste the address of a public page. The tool loads it with the Googlebot smartphone user agent, runs its JavaScript in Chromium and sets the HTML sent by the server against the rendered HTML. It works much like the old Fetch as Google, on any site, without a verified property.
Rendering in progress…
What the report contains
A full load of the page in Chromium, with network, console and screenshot.
The server response
HTTP status, redirect chain step by step, the headers that matter for indexing such as X-Robots-Tag and Link, how robots.txt reads for Googlebot, and the loading timeline.
Raw HTML against rendered HTML
Title, meta description, meta robots, canonical URL, H1, number of H2s, word count, internal and external links, images and alt attributes, JSON-LD, hreflang, declared language. Every value changed by JavaScript is highlighted. Links that only exist after rendering are listed separately.
What the browser saw
Screenshot of the page at mobile width, resources that failed to load with their status or failure reason, JavaScript errors from the console, and both source codes to read through.
The limits, before you start
The tool simulates Googlebot: same user agent, same browser family, but requests leave from our server and not from Google IP addresses. A site that verifies where Googlebot really comes from will answer differently, often with a 403. The report describes what a bot receives when it loads the page. To know whether the page is in the index, Search Console remains the reference. Only public pages over HTTP or HTTPS on standard ports are accepted. The tool clicks nothing, does not scroll, accepts no banner and picks no language. The screenshot stops at 2600 pixels in height, each source code at one million characters, and the service is limited to eight inspections per hour per connection.
Why compare raw HTML and rendered HTML
JavaScript SEO comes down to one question: is what matters for ranking already in the server response, or does it only appear once the scripts have run?
Google renders pages in two passes
Googlebot first reads the HTML sent by the server, then queues the page to render it with Chromium. Links and text present on the first read are discovered straight away. Anything that depends on a script waits for rendering, and goes missing if the script fails that day.
AI assistants stop at the raw HTML
As of today, most of the bots that feed AI assistants fetch the server response without running any script. A page whose content arrives entirely through JavaScript looks empty to them. This affects visibility in generated answers as much as in classic search.
A rewritten tag creates two versions of the page
A title, a canonical or a meta robots tag changed by JavaScript gives Google two conflicting readings. A noindex in the raw HTML is the riskiest case: Google may skip rendering altogether, and the script meant to remove it never runs.
A blocked resource quietly degrades rendering
A JavaScript file disallowed by robots.txt, a bundle returning 404 after a release, an API that rejects bots: on your machine the page looks complete thanks to the cache, while a bot with no cache gets an incomplete one. The list of failed resources helps you find these cases.
Reading the report, in order
Check that the page can be indexed
Status 200, no unexpected redirect, no noindex in the meta robots tag or the X-Robots-Tag header, address allowed by robots.txt, canonical pointing to the page itself.
Measure the dependence on JavaScript
Compare word and link counts between the two columns. A small gap points to solid server-side rendering. A nearly empty raw HTML points to an application rendered in the browser, which deserves priority on the pages that need to rank.
Look for rewritten tags
A title, a meta description or a canonical that differs between the two columns is worth fixing, even when the rendered version is the right one. Keep one source of truth, in the server response.
Fix at the source, then run it again
Server-side rendering, static generation or prerendering for the content and links that matter. SEO tags belong in the server response. Run the inspection again after the release: the tool cache expires after ten minutes.
Beyond one public page
The page in front of you
For a page behind a password, a staging environment or a local install, in other words wherever an online tool cannot reach. The analysis covers the page as your own browser rendered it.
- Tags, headings and links of the rendered page
- Broken links highlighted in the page
- JSON-LD structured data
- Everything stays in the browser
A whole website
One inspection covers one address. To know how many pages return an error, redirect or point to dead links, the whole site has to be crawled.
- 4XX and 5XX statuses, pages with no response
- Redirects, chains and loops
- Broken internal and external links
- Source page of every failing link
To check the links of a single page without installing anything, the broken link checker works on the same principle. Across the whole site, the technical SEO audit analyses the full crawl: statuses, tags, canonicals, depth.