What lands on your desk after a Code4X audit

Each lost point in a Code4X audit comes with its evidence and a fix: a deployable file, a code patch, or written instructions. Patches arrive as pull requests. Nothing reaches production until a re-audit on staging passes and someone on your team approves it.

Rubric v1.4. Last updated .

The 3 kinds of fix in a Code4X audit

Every finding links to its evidence: the URL requested, the response, and the rule it failed. The fix is attached to the finding, in whichever form fits the change.

Deployable files

Files written from your crawl that you can upload as they are, such as robots.txt, sitemap.xml or a JSON-LD block. This one allows AI search crawlers and blocks training crawlers:

robots.txt
User-agent: OAI-SearchBot
User-agent: Claude-SearchBot
User-agent: PerplexityBot
Allow: /

User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Google-Extended
Disallow: /

Code patches

Changes to your own source, written in your codebase's markup and conventions and sent as a pull request. This one gives a form field an accessible name:

templates/contact.html
-  <input name="f4" type="text">
+  <label for="phone">Phone</label>
+  <input id="phone" name="phone" type="tel" autocomplete="tel">

Written instructions

Used where the change depends on a decision only your team can make, such as how a page is rendered. Instructions say what to change, why, and how to check the result yourself:

How to check it
curl -s https://example.com/pricing | grep -c 'data-plan'
Counts plan elements in the HTML as served, without running JavaScript. Demo site.

How Code4X patches fit your stack

The crawl that finds a problem also records what your site runs on, from response headers and page markup. Patches are written for that stack rather than as generic advice.

[COPY TBD: frameworks and CMSs we write patches for, and what happens when a stack isn't supported]

How a Code4X fix reaches production

No fix is written straight to production. Each one is tested on staging and approved by a person on your team.

  1. Branch

    The fix is made on its own branch.

  2. Pull request

    You get a pull request to review, linked to the finding it fixes.

  3. Staging

    The change is deployed to your staging environment.

  4. Re-audit

    The affected checks run again against staging.

  5. Approval

    A person on your team approves the change in the dashboard.

  6. Production

    The change ships, and production is re-audited so the before and after scores are on record.

How the Code4X crawler behaves

The Code4X scanner identifies itself as Code4XBot/1.0 and follows robots.txt and Crawl-delay. It requests public pages only and doesn't log in.

To block it, add this to robots.txt. A scan of a site that blocks Code4XBot returns an error instead of a score.

robots.txt
User-agent: Code4XBot
Disallow: /

Rate limits: [DATA TBD: requests per second per site, and IP ranges]

How our crawler behaves, in full

See what the full audit includes

Questions about your stack? Ask an engineer.

Talk to an engineer Run the free scan