A website audit and launch companion built for the people doing the launching

Auditing a site and managing its launch have always been two separate jobs, handled with two separate sets of tools. You run a crawl somewhere, export the issues, then copy them by hand into Trello or a spreadsheet and start ticking things off. The audit tool doesn’t know the launch is happening, and the project tool doesn’t know the site exists.

This release closes that gap. The same full-site crawler that powers ToggleWP’s single-page checks now feeds a dedicated launch companion — a checklist that’s built from the crawl, knows the difference between your staging and live URLs, and keeps itself honest as the site changes underneath it.

Where the audit and the project meet

The starting point is a crawl. You submit a URL, confirm your email address, and the crawler does a full-site pass — broken links, redirects, missing metadata, cache behaviour, the usual catalogue. You land on a results page with the findings.

The new part is the button at the top: Convert to project. That turns the crawl into a launch checklist. Pre-launch and post-launch tasks, the items your audit could verify already ticked off for you, and a working surface you can actually run a go-live from.

The problem with generic project tools

Trello doesn’t know what a staging site is. Neither does Asana, or Notion, or a Google Sheet. They’re brilliant at columns and cards, and completely blind to the one thing a site launch actually revolves around: the fact that you’re checking work on one URL and shipping it on another.

The launch companion treats staging and live as first-class settings on the project. You tell it the staging URL, the live URL, and which one a given crawl came from.

Checking a protected staging site

Most staging sites aren’t sitting open on the internet. They’re behind HTTP Basic Auth — the browser username-and-password box — or a holding page. A generic crawler hits that wall and stops.

The companion handles this directly. In the project settings you can store a staging URL and its Basic Auth credentials, then trigger an authenticated crawl of the protected site from inside the project.

The part that actually saves you: future crawls stay covered

You audit staging. You build your checklist. You go through every page on desktop, tablet, and mobile, ticking off the content checks as you go. Then the site goes live, the client adds three new pages the week after, and your carefully-built checklist is now quietly out of date.

The Site Content tab is the answer. It’s a per-page log: every URL the crawl found, with checkboxes for Pre-launch and Post-launch across desktop, tablet, and mobile. When you import or sync from a newer crawl, it adds any URLs you didn’t already have — and leaves every existing tick exactly where it was.