Website-Toolkit.co.uk | Useful Tools for Freelancers & Agencies

The audit finds forty-three things wrong with a site. You open the report, read the first broken link, alt-tab to your editor, fix it, alt-tab back, tick it off. Then the second one. Somewhere around item twelve you stop ticking things off, because the ticking is now slower than the fixing.

If you're already using an AI assistant to do the fixing — Claude Code in your editor, say — then it's doing the work with one hand tied behind its back. It can't see the audit. You're copying issues into a chat window one at a time, and it has no way to tell you which ones it actually finished.

This release closes that loop. Your assistant can now read the audit directly, work through the outstanding items, and mark each one off as it goes — so the report empties out as the site gets fixed, and what's left in the list is genuinely what's left to do.

Why this, and why now

Every part of this toolkit exists to connect two things that obviously belong together but usually aren't: the crawl and the checklist, the alert and the to-do item, the project and the hours it took. An AI assistant fixing a site is the same shape of problem. The audit knows exactly what's broken and where. The assistant is the thing capable of fixing it. Between them sat a human, copying text from one window into another.

There's also a subtler reason. When you paste issues into a chat by hand, nothing records what got fixed. The assistant says "done" and you take its word for it. Now, when it closes an item, that's written into the same audit record the report reads — so "done" is a thing you can look at, in the report, next to everything still outstanding.

Two ways in, one set of rules

There are two ways to connect, depending on what you're using.

MCP — for Claude Code and Claude Desktop. MCP (Model Context Protocol) is the standard way these tools connect to outside systems. You add the server once and your assistant gets a set of audit tools it can use whenever you ask.

A REST API — for everything else. Scripts, n8n, Zapier, CI pipelines, your own code. Same URLs, same token, plain JSON.

They're the same thing underneath — MCP is a wrapper over the API, not a separate system — so both behave identically and neither can drift out of step with the other.

One token covers both, and it's scoped to your account: your assistant can only ever see and change the domains on it. Not other clients', not the wider server.

Setting it up

Two minutes, once.

1. Generate a token. In your client portal, on the Domains page, find the API access panel and hit Generate token. That's it — the token appears, along with a pre-filled setup command.

2. Connect your assistant. The panel shows you the exact command with your token already in it. Copy it and run it:

claude mcp add --transport http wsc-crawler https://eu2.website-toolkit.co.uk/mcp \
  --header "Authorization: Bearer your-token-here"

Now ask your assistant something like "what's outstanding on the latest audit for example.com?" and it'll tell you.

Treat the token like a password — anyone holding it has this access. If it leaks, hit Rotate in the same panel and the old one stops working immediately. Turn off revokes access entirely; you can generate a new one whenever you like.

What it can actually do

Seven things, and it's worth knowing where the edges are.

Read your audits. List the domains on your account, see recent audits for any of them, and pull the results — pages, issues, broken links, images, CSS, scripts, SEO warnings. By default, asking for issues gives you the ones still outstanding, which is almost always what you want.

Close items off. Mark an issue fixed and it drops off the active list. This is the same "mark fixed" state as the button in the audit report, so the report and your assistant always agree on what's done. It can also undo one, if it closed something prematurely.

Add a domain. Put a new site on your account so it can be audited.

Start an audit. Kick off a basic or a full audit on any domain you own. It returns straight away with an ID — the crawl itself takes minutes to hours, so it's not something to sit and wait on.

What it deliberately can't do: permanently dismiss an issue. The audit report has an "ignore" feature that suppresses something across all future crawls — useful when you know a warning doesn't apply to your site. That stays a human decision. An assistant wrongly ignoring something would hide it forever, and you'd never find out. Marking something fixed is the safer version of the same gesture, and here's why.

Why "fixed" resets on the next audit

This is the design decision most worth understanding, because it looks like a limitation and is actually the point.

When your assistant marks an issue fixed, that applies to that audit. Run a new one and the site gets checked from scratch — and if the fix didn't really land, the issue comes back.

That's deliberate. An AI assistant marking its own homework is exactly the situation where you want a real check rather than a promise. If it fixed the broken link, the next crawl won't find a broken link and the item stays gone. If it thought it did but the change never deployed, the item reappears and you find out. Nothing quietly stays "fixed" on a site that's still broken.

So the honest workflow is a loop: read what's outstanding, fix it, mark it off, then run a fresh audit to confirm. The last step is what turns "I fixed it" into "the site is fixed."

The one thing to know: issue IDs belong to the audit they came from. Every crawl assigns fresh ones, so an ID from Monday's audit means nothing in Friday's. Your assistant is told this and handles it, and the server refuses an ID that doesn't match — but it's worth knowing if you're scripting against the API yourself.

A real loop

What this looks like on an actual site:

Ask what's outstanding. "Pull the latest audit for example.com and show me what's still open." You get the active list — the things nobody has dealt with yet.
Let it work. "Fix the broken internal links and the missing meta descriptions." It has the URLs, the recommendations, and the pages each issue was found on, so it can go straight to them.
It ticks them off as it goes. Each fix it completes gets marked off. Ask for the outstanding list again and it's shorter.
Deploy.
Verify with a fresh crawl. "Start a full audit for example.com." A few minutes later, ask what's outstanding again. Anything that comes back is something that wasn't really fixed. Anything gone is genuinely gone.
Open the report. Everything your assistant did is right there, in the same audit view you'd normally use — no separate log, no parallel record.

The interesting part is step 5. Without it you have an assistant's word for it; with it you have a crawl's.

Using the REST API directly

If you're not on an MCP client, everything above is available over plain HTTP with the same token:

# What's still outstanding on the latest audit?
curl -H "Authorization: Bearer $TOKEN" \
  "https://eu2.website-toolkit.co.uk/api/client-api/v1/example.com/latest/issues"

# Mark issue 42 fixed
curl -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"issueId": 42}' \
  "https://eu2.website-toolkit.co.uk/api/client-api/v1/example.com/$CRAWL_ID/issues/resolve"

# Start a full audit
curl -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"mode": "advanced"}' \
  "https://eu2.website-toolkit.co.uk/api/client-api/v1/example.com/audit"

mode is basic or advanced — "advanced" is the full audit, the same one the Run full audit button triggers. Pass anything else and it tells you rather than guessing.

Issue queries accept status=active (the default), fixed, ignored, or all, and everything paginates with page and pageSize.

Putting it together

The audit already knew what was wrong. Your assistant was already capable of fixing it. The only thing missing was a way for the two to talk without you in the middle, retyping.

Let Your AI Assistant Read the Audit — and Tick Items Off as It Fixes Them