How Website-Toolkit works
A quick tour of the main jobs you'll do, in the order you'll usually do them: run an audit, review what it found, turn the findings into a tracked to-do list, then spin up a launch or migration project and, when you're ready, add monitoring.
The whole toolkit runs on one crawler with a single idea behind it: the tool that finds the problem is the tool that tracks the fix. Nothing here asks you to retype an issue or copy a URL into a separate app.
During the beta period, the 200-page audit and both project types (launch and migration) are free to use — subject to confirming, by email, that the project should be upgraded.
After 31st Aug, the free 200-page sample audit stays available, but projects will require a paid domain to activate.
Run your first audit
Start on the audit page. Drop in a URL and your email, then click the verification link we send — there's no account, password, or card. The crawler does a full-site pass of up to 200 public URLs, checking for broken internal links, redirects, missing tags, external 404s, and cache behaviour.
When it finishes you get a private Magic Link by email: a password-free results URL you can bookmark or forward to a client as a quality-assurance report. That link is the home base for everything that follows.
Review the results
Open the Magic Link to land on the results dashboard: a site-health score, summary stats, and tabs that group every finding by type — broken links, missing metadata, redirects, external 404s, and so on.
This is where you decide what actually matters. Work through the tabs, expand a category to see the affected pages, and get a feel for the size of the job. You can read it all in the browser or grab the Excel export if you'd rather work from a spreadsheet.
Reviewing the first audit is also where you spot anything worth fixing before you commit to ongoing checks — tidy up the obvious issues now and every later crawl gives you cleaner, more useful results.
Build a to-do list
The audit has its own to-do list, built right on the results page. Add a finding and it becomes a tracked, tickable task — grouped by category, with the affected URL attached — without leaving the audit or creating a project first. You can also add your own tasks for anything the crawl can't see (copy changes, a missing legal page, a client request).
Because the list is built from the crawl rather than typed by hand, it stays tied to the site it came from. No “which page was this again?” a week later.
Mark items as fixed
As you work through the list, tick items off. Marking a task as fixed records that the work is done and keeps your remaining workload honest — the dashboard always reflects what's still outstanding versus what's already handled.
When you re-crawl later (see monitoring below), the toolkit can tell you whether something you marked fixed has actually stayed fixed, or quietly broke again.
Create a launch or migration project
An audit is a snapshot; a project is the working surface you run a go-live or a move from. From the results page, convert the crawl into one of two project types:
- Launch project — for taking a new or rebuilt site live. You get a checklist of pre- and post-launch tasks, with the items your audit could already verify ticked off for you, plus a per-page Site Content log for checking every URL on desktop, tablet, and mobile.
- Migration project — for domain changes, URL-structure rebuilds, or host moves. Same checklist workflow with a pre- and post-migration task set, plus a redirect map that checks each old URL now
301s to the right page on the new site rather than 404ing or bouncing to the homepage.
The project remembers which crawl it came from, so results and checklist stay linked. Open the results again later and it knows a project already exists — it offers to take you there rather than starting a second one. Each project has a private edit link for you and a read-only share link for the client.
Update a project with settings
A project's settings are what make it more than a generic checklist. Open settings to tell it about the environments and how it should behave:
- Staging & live URLs — record both so the project knows which environment a given crawl belongs to. When you go live it can even suggest your live domain from the staging one and ask you to confirm.
- Staging login — store the HTTP Basic Auth username and password for a protected staging site, then trigger an authenticated crawl from inside the project so the version that actually matters gets the full audit. Credentials are saved with the project and never shown again after you save them.
- Share password — optionally put a password on the read-only share link, so a leaked link alone isn't enough to view the project. Your private edit link is never affected.
Re-crawl and sync at any point: new pages get pulled in and flagged as needing checks, while every tick you've already made stays exactly where it was. The checklist keeps pace with the site instead of falling behind it.
Add monitoring
A launch or a migration ends; a live site doesn't. Monitoring re-crawls a site on a schedule and tells you what changed against the baseline you signed off on — a newly broken internal link, a meta description that vanished, a heading dropped in a botched edit, an SSL certificate about to expire. A fresh regression drops into your to-do list, with nothing copied across by hand.
How monitoring is set up: it isn't switched on automatically. Monitoring is requested manually during the earlier phase — once you've reviewed an initial audit, fixed anything that needs fixing, and confirmed the crawl is giving you clean, accurate results worth treating as a baseline. You request your schedule (daily, weekly, whatever suits the site) by email, and Website-Toolkit re-crawls from then on. Setting it up only after that first clean audit means you're monitoring against a baseline you trust, not against noise you've not yet dealt with.
API documentation
Most people will never need this — but if you want to wire Website-Toolkit into your own tooling, there's a full API. It lets you kick off crawls, fetch results, and integrate audits into your own dashboards or build pipelines rather than driving everything by hand. It's the same interface the ToggleWP WordPress plugin uses for its single-page checks.
The full endpoint reference, authentication details, and example requests live on the API Docs page.
Get in touch
Got feedback or a question? I'd genuinely like to hear it — the toolkit gets better the more real-world use it sees.
During the beta period, support and replies are provided on a best-efforts basis — bearing in mind UK working hours and family life. I read every message and will get back to you as soon as I reasonably can.