Crawl your site the way an engine sees it, JavaScript executed
Most audit tools read the code your server returns. A search engine displays the page before deciding what it contains. Between the two there is sometimes all of your content, and that gap is what we crawl, page by page, on every run.
Access opens in waves: we email you when yours is ready.
The report is green, the pages never land
A technical audit that does not render the page describes a site the engine cannot see. It is the most expensive failure mode precisely because everything looks fine: the URLs respond, the tags are there, and the content is missing.
-
01
Your app returns nothing in the first byte
React, Vue or Next rendered client-side: the server response is an empty shell. A crawler that stops there finds no headings and no internal links, so no path to crawl at all.
-
02
Nobody knows what changed since the last audit
A February report and a June report are not comparable: different scope, different settings. Every fix shipped in between is invisible to both.
-
03
Findings arrive a quarter too late
A redirect chain introduced on a Tuesday surfaces when somebody re-runs an audit by hand. In the meantime it has cost something on every engine visit.
What we measure
What each run records
A crawl produces a complete, dated state of the site that can be compared with the previous one, provided both come from the same campaign. That is precisely why campaigns exist.
- The real rendering of every page (the engine loads the page, executes its JavaScript, then analyses what the browser actually built. The initial HTML stays available alongside it: the gap between the two is a finding in itself.)
- Structure and responses (status codes, redirect chains, canonicals, titles and descriptions, headers, click depth from the home page. An unreachable page is reported as unreachable, never as missing.)
- A comparison between two runs (what appeared, what disappeared, what degraded. An interrupted crawl is marked as truncated and excluded from comparisons rather than discarded: comparing a partial state with a complete one would invent a change.)
- A reusable configuration (same scope, same rules, same depth, on every scheduled run. That is the condition for a difference between two crawls to be attributable to the site rather than to the settings.)
Further reading
JavaScript SEO: getting a single-page app crawled
The tutorial: getting a single-page application crawled, step by step.
Read ComparisonNessFlow vs Screaming Frog
What a desktop crawler does very well, and what it does not keep from one run to the next.
Read GlossaryGlossary
Indexation, click depth, JavaScript rendering: the technical vocabulary, defined.
ReadOther modules
Frequently asked questions
What does a rendered crawl see that an initial-HTML crawl does not?
Everything your application builds in the browser: content loaded afterwards, links injected by a component, titles set by the router, tags rewritten client-side. On a client-rendered application the gap is not a detail: the initial HTML may contain none of your internal links, and therefore no path by which an engine would reach your deep pages.
How many pages can I crawl?
The scope is the one you give the campaign, and the run deadline is proportional to that budget. A crawl that hits its limit is marked as truncated: it stays fully readable, and it is excluded from comparisons. We publish no volume figure we have not measured ourselves, a claim of that kind has already been removed from this site for exactly that reason.
Are two crawls always comparable?
Only if they come from the same campaign and neither is truncated. Comparing a complete run with a partial one would produce “disappearances” that are nothing more than the edge of the sample, the kind of false finding that costs a team a day.
Do I need to install anything?
No. The crawl runs from our servers against your public domain, with an identifiable agent you can allow or restrict in your own rules. Log analysis and the Search Console connection do require access, which you grant explicitly and can revoke.
How far this crawl goes
A crawl describes a state. It fixes nothing, promises nothing, and replaces no editorial decision. The right-hand column is deliberate, not a backlog item.
What we cover
- Pages reachable from your domain, JavaScript rendering included
- A dated comparison between two runs of the same campaign
- Exhaustive exports, on every results screen
Stated limits
- No automatic fixes to your code: we report, you decide
- No absolute grade sold as a truth, a score is read together with the axes that produced it
- No volume promise we have not measured on a real site
- No access to anything behind authentication, unless you configure it explicitly
Run a first crawl on your own domain
You will see what rendering changes on your pages before having to take our word for it. It is the only demonstration that concerns you.
Access opens in waves: we email you when yours is ready.