HOW IT WORKS

Five stages. Two places it stops and asks you.

Most tools end at a report. This one runs a loop, and closes it by measuring again, which is the part that tells you whether any of it worked.

The loop

Same shape as a pull request you already review every week, except this one writes itself, verifies itself, and waits for your call twice.

  1. 01

    Measure

    The crawler fetches your pages the way Googlebot and the AI crawlers do (no browser, no patience for a framework to boot) and runs all 129 checks against what actually came back. Every check resolves to pass, fail, or unmeasured, and the third one is never rounded up.

    Output: A score, eight category scores, and the coverage behind each of them.

  2. 02

    Audit

    Each failing check becomes a finding attached to the specific page it was found on, with the evidence that produced it and a statement of how it was decided: a deterministic rule, a graph analysis, a third-party API, or a model judgement.

    Output: A findings list you can argue with, because each one shows its working.

  3. 03

    Plan

    waits for you

    Findings are ranked by severity multiplied by the number of pages affected, so a low-severity problem across two hundred pages outranks a high-severity one on a single page. The ranked plan is presented, and the loop stops.

    Output: A ranked remediation plan, waiting on you. Nothing proceeds until you approve it.

  4. 04

    Remediate

    Only the approved items are worked. Each check declares who is allowed to fix it: Auto means the engine produces the change, Assist means it drafts and a person decides, Human means only a person can. The engine does not overrule that classification.

    Output: A set of proposed changes, each one verified as far as your access allows.

  5. 05

    Deliver

    waits for you

    The changes are packaged for however much access you have granted, and the loop stops a second time. Nothing reaches your site until you approve this too.

    Output: A pull request, a set of drafts, or a patch file, and your decision.

Then it measures again

After a delivery lands, the next scan re-runs the same checks against the same pages. If a fix did not move its check from fail to pass, that gets flagged rather than quietly forgotten. This is the part almost no tool in the category does, and it is the only way to tell a change that worked from a change that merely shipped.

It is also the reason the score is worth watching over time rather than screenshotting once. A single number from a single crawl is a snapshot. The same number across four crawls, with the fixes in between marked, is evidence.

What the two gates are for

They are a design decision, not a limitation. The engine is capable of generating a plan and generating changes without stopping; it stops because an unsupervised agent editing a production site is a different product with a different risk profile, and not the one being built here.

  • The plan gate is where you decide what is worth doing. Approving everything is a valid answer; so is approving three items and ignoring the rest.
  • The delivery gate is where you decide whether a specific change is correct. You are looking at a diff, not a description of a diff.

Crawld is explicitly not for teams who want a fully autonomous agent with no review step. If that is what you are shopping for, the gates will feel like friction, and they are not going away.

How changes reach your site

How much can be verified depends on how much access you grant, and the labelling follows the access rather than the marketing.

Mode What we get How changes arrive Verification Status
A · Repo write A connected repository we can push a branch to Opens a pull request. You review the diff and merge it. Build-verified Not built yet
B · Read-only repo Read access, plus somewhere to push Pushes to a fork or a branch you own. Build-verified Not built yet
C · Cloud mirror A one-time snapshot or export Works on a clone in our cloud, returns a patch or a PR. Build-verified (mirror) Not built yet
D · CMS drafts OAuth into a hosted CMS Writes unpublished drafts. You publish them. Preview-verified Not built yet
E · URL only Nothing: a public URL A scorecard and a patch you apply yourself. Advisory only Available now

Build-verified means a build actually ran. It applies to modes A, B and C and to nothing else. A hosted CMS has no build to run, so mode D is preview-verified and mode E is advisory. Those labels are never blurred, because the honesty of the verification is the product.

What runs today

The free scorecard is Mode E and it is live: give it a URL, it crawls a capped slice of public HTML, scores it against the full rubric, and reports what it could not measure. It writes nothing and it verifies nothing, because it has no access to anything.

The connected modes, the ones that open a pull request or write CMS drafts, are the delivery model the product is built around, not connectors you can switch on this afternoon. The table above marks which is which.

Run the free scan How the scoring works