Website auditing where every finding stays attached to its evidence
A site audit usually means several tools, several exports and a report assembled by hand. CrawlIT runs discovery, inspection, review and export as one job, so the page a finding came from is still there when someone asks you to defend it.
In beta. Crawl scope, reporting format and any custom checks are agreed before the first run.
Website audits break into disconnected evidence
Crawling, rendering, performance testing, structured-data validation and accessibility review normally live in separate tools. Each one needs its own setup, each one produces its own export, and the report is assembled afterwards by hand — which is exactly the point at which the link between a finding and the evidence for it is lost. A crawl graph also changes while teams are still inspecting it, so two people reading the same audit a week apart are not looking at the same site. The result is repeated setup, fragmented context and a report that is difficult to defend when a finding is challenged.
- A crawl, a performance run and an accessibility review that each produce a separate export
- Tool setup repeated for every site, and repeated again for every audit
- A failing rule reported without the page context or the source evidence that explains it
- Inconclusive checks that quietly become passes because nobody recorded the decision
- A crawl graph that has already moved on by the time the findings are read
- Reports assembled by hand from several files, which is where the traceability is lost
Who gets value from this
Engineering and QA teams
You need findings that arrive with the page and the source evidence attached, so a defect report can be acted on without a round of clarification first.
Accessibility reviewers
You need automated findings you can trust as a starting point, and a clear boundary around the checks only a person can settle — with a record of the calls you made.
Agencies and site owners
You need a repeatable audit process across many sites, producing a report you can hand to a client and stand behind when a finding is questioned.
The mechanism
What it actually does, in the order it does it.
Discover — walk the site within its stated scope
The crawl respects the site's own robots rules, follows sitemaps and stays inside the scope the audit was defined against. What was in scope is a property of the run rather than something reconstructed afterwards.
Inspect — evaluate the page as it actually renders
Pages are rendered where the content depends on it, then examined for HTML validity, stylesheet integrity and structural correctness. Findings are attached to the affected page at source level rather than reported as a site-wide count.
Review — route uncertain checks to a person
Deterministic checks are settled automatically. Checks that automation cannot settle are turned into guided review tasks, each with the measurement behind it and an explicit statement of what that measurement cannot establish. The reviewer keeps authority over the verdict, the note and the final status.
Export — report from the record, not from a rebuild
Reports are generated in HTML, JSON or PDF from the same crawl state the findings were recorded against, so the report and the evidence behind it cannot drift apart.
Keep the whole job as one record
Discovery, inspection, review and export are four views of the same audit rather than four tools handing files to each other. The page records, the issues, the review decisions and the report inputs all stay attached to the job that produced them.
What you get
Audit coverage
- Crawl integrity: robots rules, sitemaps, redirects, links and site scope
- Rendering and validation: rendered HTML, markup validity and stylesheet parsing
- Performance: normalised performance scoring per audited page, measured offline or against a hosted service
- Structured data: syntax, vocabulary and field consistency across JSON-LD, Microdata and RDFa
- Accessibility: rule-based results across desktop and mobile viewports
Evidence per finding
- Page records and link records produced by the crawl
- Source-level issues attached to the pages they affect
- The measurement and stated scope of each guided review task
- The reviewer's verdict and note, kept with the finding
- The crawl status each finding was measured against
Reporting
- HTML, JSON and PDF reports generated from the same crawl state
- A record that can be re-read and defended after the fact
What this does not do
Stated plainly, because the alternative is discovering it after you have bought it.
Automation produces evidence, not a compliance claim
A clean result is not a statement of legal compliance and not a claim of full conformance with any accessibility standard. Automated rules can establish that a check passed; they cannot establish that a site is accessible to a person using it. Treating a passing report as certification is the specific misuse this product is designed to make difficult.
Uncertain checks stay uncertain until a human rules on them
The design preserves uncertainty instead of converting every automated signal into a definitive answer. That is deliberate, and it has a consequence: a run is not finished when the crawl finishes. Some findings are only resolved by a reviewer, and a report that skips that step is not an audit — it is a list.
The review queue is real work, and it needs an owner
A documented review sweep on a modest site produced 227 guided review tasks across 15 pages. That is the honest shape of the work: bounded, traceable, and larger than a crawl's runtime suggests. Someone on your side needs the authority to make the judgement calls, or the queue becomes a backlog.
Beta means beta
The product is not generally available. Runs are set up with our engineers involved, which is slower than self-serve and is the honest description of where the product is.
Frequently asked
How is this different from a crawler, a performance test and an accessibility checker?
Those are three tools that each produce an export. The difference here is that all of it runs as one job against one crawl state, and every finding keeps the page and the measurement it came from. In practice that is the difference between a report you can defend and a report you have to reconstruct.
If the audit comes back clean, are we compliant?
No, and we will not say otherwise. Automated checks establish that specific rules passed. They cannot establish legal compliance or full conformance with an accessibility standard, because a meaningful share of accessibility problems require a person to judge them in context. This product is built to make that boundary visible rather than to blur it.
What does the review step actually involve?
In a documented sweep, 227 guided review tasks were raised across 15 pages. Each task carries the measurement behind it and states what that measurement cannot establish. A reviewer confirms a verdict and records a note, and their decision — not the automated signal — is what the report carries.
Why is it labelled beta?
Because it is. Runs are set up with our engineers involved rather than by self-serve, and the scope of each crawl is agreed with you beforehand. Labelling it honestly is both accurate and more useful to a buyer who intends to test the claim.
Related capabilities
Request a website audit
In beta. Crawl scope, reporting format and any custom checks are agreed before the first run.