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

The other posts on this blog each cover one module in depth — the launch companion, migration projects, monitoring. This one is different: it's a single walkthrough of a real launch, front to back, on a paid Website Toolkit plan — the order you'd actually do things in, with the buttons you'd actually click.

If you're a freelancer or small studio taking a site from "still being built" to "live and staying that way," this is the whole loop in one place.

1. Add the domain

Everything starts in your admin area: add the new domain the site will live on. This is the anchor the rest of the workflow hangs off — the audit, the launch project, the feedback widget and, eventually, monitoring all key off this one domain record.

2. Run an initial audit against staging or dev

Before the site is public, point the crawler at wherever it actually lives — usually a staging or dev URL, often behind HTTP Basic Auth. Store the staging URL and its credentials against the domain, then run the crawl. That first pass is your baseline: the full inventory of pages, links, headings, metadata and resources as they stand today, warts and all. You're not expecting a clean report — you're expecting an honest one to work from.

3. Review the quick fixes

The results page surfaces the low-effort, high-value issues first — broken links, missing alt text, redirect chains, the kind of thing that takes thirty seconds to fix and makes the rest of the report shorter. Clear those before you even open the launch checklist, so the project you're about to build reflects the real remaining work rather than noise you could've swept up in five minutes.

4. Start a launch project

Convert to project turns that crawl into a working checklist — Pre-launch, Post-launch, To-do, and Site Content tabs, with the items your audit could verify already ticked off. From there:

Add any custom steps the standard template doesn't cover — a client-specific sign-off, a particular integration to test, whatever this launch needs that isn't generic.
Mark an item "in progress" as you pick it up, so it's visibly the thing being worked rather than just sitting in an undifferentiated to-do pile. The three-state model (not started → in progress → done) exists so a glance at the board tells you what's actually moving, not just what's finished.
Check items off as they're genuinely done — each tick contributes to the completion rings at the top of the project, so progress is something you can show a client without narrating it.

5. Turn on the feedback widget and share it with the client

Add the feedback widget to the site so the client can leave comments directly on the pages they're looking at, rather than in an email thread that loses context. Once it's live:

Enable the review button so you — the site builder — can mark a page as reviewed once you're satisfied with it.
Generate a Client Review URL and send that to the client instead of a bare link. Following it enables scroll tracking for their session automatically — they don't have to remember to open a widget panel first, they just browse the site and every page counts. The link is staging- or live-aware and can be labelled per reviewer, so the review log later shows who looked at what, not just that someone did.

6. Review every page, desktop and mobile

Work through the site on both device sizes, using the widget to mark each page approved as you go. Every approval updates the corresponding box on the project's Site Content tab — the same tab the device checks live on — so the checklist fills itself in as the review happens instead of you cross-referencing a separate log afterwards.

If new pages get added to the site after that first crawl — a client adds a landing page mid-build, say — use Check site map from the launch checklist screen. It diffs the live sitemap against the pages the project already knows about and surfaces anything new, so a late addition doesn't slip through unreviewed just because it wasn't there for the first crawl.

Checking coverage and feedback. The Site Content tab is also where you check how much has actually been reviewed — which pages are covered on which device, and, where scroll tracking is on, how much of each page was actually seen rather than just clicked past. Comments left through the widget surface in the same project, so the audit trail, the device checks, and the client's actual feedback all live in one place rather than three.

7. Test contact forms with the browser extension

Contact forms are the one thing a crawl can't fully exercise on its own — someone has to actually submit them. Install the browser extension and set up a couple of test profiles (a name, email, and the usual form fields) so submitting a test enquiry during the build is a couple of clicks rather than typing the same fake details in every time. Use those profiles to confirm each form on the site actually sends, validates, and redirects the way it should before the site goes anywhere near real visitors. These profiles can also be re-used as part of your monthly site checks, saving a little bit of time each go.

8. Go live

Once the pre-launch tasks are done — quick fixes cleared, checklist ticked, pages reviewed on both devices, forms tested — flip the site live. Work through the Post-launch tab the same way you did pre-launch: re-crawl the live URL, sync it into Site Content, and tick off the post-launch device checks against the real, public site rather than staging.

9. Set up ongoing monitoring

A launch ends; a live site doesn't. Once everything's live and stable, set up a monitoring project on a weekly or monthly cadence, whichever suits how often the site actually changes. Each run re-crawls the site and diffs it against the last one, and two things are worth calling out specifically:

Content changes are checked, not just noted — if a page's content shrinks or a section disappears, that's flagged for approval rather than silently accepted, which is exactly the safety net you want against an accidental deletion during a routine content edit.
The words list catches typos and unintended text changes that a link-and-status check would never see — new unrecognised words appearing on a page are exactly the kind of thing that slips through a "does it 200?" check but embarrasses you in front of a client.

Each run sends an email for your review, so keeping a site right after handover becomes a scheduled five-minute check rather than something you only find out went wrong when the client emails. It's the same crawl-and-verify engine as the launch itself, just pointed at the long tail — and it's a clean, ongoing value-add you can fold into a service plan rather than a launch being the last time you ever look at the site.

10. WordPress sites: tighten the loop with ToggleWP

If the site's built on WordPress, the ToggleWP plugin integrates directly with the crawler to run a single-page check the moment a page is updated or published — rather than waiting for the next scheduled weekly or monthly monitoring run. A client fixes a typo on a Tuesday afternoon and you know within a couple of minutes whether that edit introduced a broken link or knocked out the metadata, instead of finding out at the next full-site check. It doesn't replace monitoring — it fills the gap between edits and the next scheduled crawl, which on a site that gets touched often is most of the value.

Putting it together

Start to finish, one launch:

Add the domain.
Audit staging/dev to get a baseline.
Clear the quick fixes.
Start the launch project — add custom steps, mark items in progress, tick them off as they're done.
Turn on the feedback widget, enable the review button, send the client a Client Review URL.
Review every page on desktop and mobile, marking each approved — Site Content fills in as you go. Use Check site map to catch anything added since the first crawl.
Test contact forms with the browser extension and a couple of saved test profiles.
Go live, then work the Post-launch checks against the real site.
Set up weekly or monthly monitoring — content changes need approval, the words list catches typos, and you get an email to review after every run.
On WordPress, add ToggleWP so edits get checked within minutes instead of waiting for the next scheduled run.

At no point in that list did you retype an issue into a second tool, lose track of which pages were actually reviewed, or find out about a problem from the client instead of from the toolkit. That's the whole point of building the audit, the launch, and the after-launch care on the same engine — it's one continuous piece of work, not three separate ones you have to keep in sync by hand.

Ready to launch your next project with Website Toolkit?

The workflow above is available in full on all our paid plans. Get started today with a 7-day trial of the full module suite, or lock in a lifetime deal while we're in founding member beta.

Launching a Site, Start to Finish, on the Paid Plan