THE FIX QUEUE

Every fix arrives as a diff, not a suggestion.

You don't need to know what a canonical tag is. You need to know whether to click merge, which means the change has to be in front of you, in full, before you decide.

What a queue item contains

Not a description of a change. The change.

  • The diff itself: what is removed, what is added, with line numbers and surrounding context
  • Which check it satisfies, and what that check looks for
  • Which page or pages it applies to
  • Its verification status, honestly labelled for the access you granted
  • Its fix capability: whether a machine wrote this, drafted it, or refused to
src/pages/pricing.astrometa-description-missing · Auto-fix
14<head>
15- <meta name="description" content="">
15+ <meta name="description" content="Compare Crawld plans: free scans, one-time remediation, or a monthly content-ops retainer.">
16</head>
Build verified Mode A · opens PR on merge

Who is allowed to fix what

Every one of the 129 checks declares its fix capability, and the engine does not overrule it. This is what stops a language model from confidently rewriting something it has no basis to rewrite.

Auto

The engine produces the change itself. These are findings with one correct answer: a missing meta description, an absent canonical, a malformed sitemap entry, an image with no alt text where the surrounding content makes the alt obvious.

You still approve the diff. "Auto" describes who wrote it, not who ships it.

Assist

The engine drafts and a person decides. These are findings where the shape of the fix is clear but the content is a judgement call: rewriting a title that is too long without losing what it meant, consolidating two posts that compete for one intent.

The draft arrives as a proposal with the reasoning attached. Editing it before approving is the expected path.

Human

Only a person can decide. Anything requiring knowledge the engine does not have: whether a page should exist, whether a claim is true, whether an author is genuinely an expert on the subject.

The engine will not generate a change here. It reports the finding and stops, rather than guessing convincingly.

How the queue is ordered

The ranking is the useful part, because the list is always longer than the time available.

InputWhat it means
Severity How much this specific problem costs on a page where it occurs.
Pages affected How many crawled pages carry it.
The product of the two A low-severity finding across 200 pages outranks a high-severity one on a single page, because fixing it is worth more. This is the part most audit tools get backwards by sorting on severity alone and handing you 400 rows.

The two gates

The queue sits between them. You approve the ranked plan before anything is generated, and you approve the delivery before anything ships. Both are explicit clicks and neither can be turned off.

A change delivered as a pull request is also one click to revert, which is a property of the delivery mechanism rather than a feature, and a good reason to prefer it where you can.

How changes reach your site

The verification label follows the access, not the marketing. A hosted CMS has no build to run, so a change written into one is never described as build-verified.

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, Mode E, is live. It produces findings and a patch you apply yourself, labelled advisory throughout because it has no access to anything and has never seen a build.

The connected modes above describe the delivery model the product is designed around. They are not connectors you can authorise this afternoon, and the table says which is which rather than leaving you to find out after paying.

See what your site would queue Delivery and integrations