What changed, in plain language

Toolkit now has the first enforceable Company OS workstream. A teammate can ask for a full client website audit in plain language and receive one standard cross-platform workflow, with qualified-peer review, protected production gates, standard reporting, and write-back to the originating ticket or Activity Logs. Runs can now pause and resume locally without losing their checklist, evidence, approvals, or completion history. Internal codenames stay out of the normal employee view. Full relaunch and launch-readiness requests now use that complete workflow, including AI-crawler discovery and published tag-management quality evidence before reporting.

Setting up now asks what you do here — read reports, contribute, or maintain the toolkit — and offers the shared design kit (and, for maintainers, the dev kit) to match. Neither is required: everything works exactly the same without them. And the setup check no longer says you are ready when only some of the capabilities are actually installed, or when one of them still needs the one-time install that lets it run — it now prints the command to fix it, for the computer you are on. The Windows installer is fixed too: it could not start at all on the version of PowerShell that ships with Windows. Asking for something the toolkit does not do now says so, instead of answering with eight unrelated things.

A new visual check reads a page the way a person would and reports what looks wrong: photos cropped so the subject is cut off, areas left blank that were meant to hold something, side columns that render empty, cards in a row at different sizes, headings that wrap to four lines, and text sitting on top of other text. None of those were caught by anything before — a page could pass every check we had and still be visibly wrong. That check now also tells deliberate design apart from accidents: a headline over a full-width photo, a before-and-after slider and a row of small accreditation logos are no longer reported as faults, and a page that does not exist is reported as unreachable rather than clean. Toolkit also picked up the medical-vertical knowledge from a retired internal system: what each kind of practice offers, how a credential may safely be described when nobody has verified it, and a wider net for the marketing claims that get a healthcare client in trouble.

The client audit report itself was run against four real client sites and several things it said turned out to be wrong, so those are fixed. It no longer tells a site built on Wix or Squarespace that it has no analytics — those platforms add their tracking after the page loads, where the old check could not see it. It no longer grades a site's XML sitemap or its news feed as if they were web pages. It asks twice before declaring a link dead, because a page that was actually working was reported as missing. And the report itself now says whose site it is on the cover, prints links a recipient can actually open instead of a folder path from the machine that made it, and stops repeating the same line hundreds of times in the copyable summary.

You can now open a local toolkit homepage to see which keys are set, what ran today, and where reports live — no more `cat`-ing files. A nightly “end of day” command can summarize today’s runs, log them to the work log, sync reports to the client’s Shared Drive, and surface tool failures for triage. Gmail and Drive are now reachable as you, via per-person OAuth, without sharing a mailbox as a service account.

Migration projects now keep their site-specific code, evidence, and work queue in their own repository. The shared migration toolkit is smaller and safer to reuse because it no longer carries one customer's old build scripts or assumptions.

a screen-recorded walkthrough can now be turned into a transcript, timestamped screenshots, and a tickable checklist without rewatching it. The same release also captures migrations from a complete mobile-and-desktop record of a live site without turning the old platform's code into the new website, keeps the project-local skill mirror from drifting, adds a shared branded print theme so every deliverable ships on the same letterhead, and gives reviewers a repeatable security check for risky agent-skill instructions and missing evidence.

an in-progress migration can now refresh itself from the live source without throwing away the reviewed clean frontend or silently keeping stale copy. The same release also closes route, metadata, feed-orphan, and transient deployed-crawl gaps learned from the Sherber run.

a migration can no longer trade away the source site's logo, navigation, homepage hierarchy, or link presentation simply to earn perfect technical scores. The original presentation is now a protected input, and release requires both technical quality and an approved brand-preserving comparison.

clean migration builds can now replace common WordPress plug-ins and page-builder markup with owned website features and reviewed responsive presentation. The migration is proven on an immutable Worker preview, stores optimized public media in R2, and keeps production forms and DNS closed until their real credentials and human approvals exist.

the public capability report can no longer silently describe an older toolkit. The normal toolkit gate now checks its skill count and complete roster, while the release manual runs the companion wiki test that owns its evidence calculations before a version is stamped.

full Screaming Frog exports can now move from evidence to an accountable fix queue without crashing or hiding files. One rule engine decides what matters, migrations require a strict after-crawl, and approved Cloudflare candidate fixes have a dry-run-first, reversible write path before deployment and re-crawl.

the published capability table now matches the toolkit that was actually released. It lists all 78 skills and 256 test pages, and it openly identifies the eight skills that still lack test-page evidence instead of presenting an older, more flattering snapshot.

the migration toolkit now distinguishes a static WordPress extraction from a genuinely rebuilt frontend. Removing WordPress executables is no longer enough to sign off a site: old Divi or other builder markup, styles, JavaScript coupling, and oversized captured CSS all block release until they are rebuilt as owned components. The toolkit can now inventory the original WordPress plugins, map each one to an owned, static, approved external, retired, or manual destination capability, and flag inactive plugins for review without pretending they are automatically safe to delete. A shared WordPress/Wix reference-graph scan also catches code that no page can reach and identical code being shipped twice. A new capability release plan prevents prototype or placeholder features from being mistaken for production integrations and binds every real feature to configuration and proof from the exact candidate. Migrated sites now keep their menus, blog cards, full-width photography, and mobile layouts working without shipping old WordPress plugin code. Mobile sign-off now uses a real touch/mobile browser gate instead of treating a saved screenshot as proof. The next hosting rebuild now has safe tooling: Workers for the app, R2 for controlled media storage, verified media manifests, and dry-run-validated Worker generation, with the existing Pages route retained until the same candidate proves parity. The launch gate catches the subtle case where all blog articles exist but stay invisible because a deleted carousel script never initialized. Full-width images are also regenerated from retained originals at a quality suitable for modern high-density screens instead of accepting an undersized inherited copy. Site-specific interactions now have to pass against the same sealed deployment, and a failed release compile leaves its input candidate untouched. The Sherber and Rau closeouts now feed a stricter release contract: every source route is reconciled, every canonical page is exercised on real iPhone widths, clipped elements cannot hide behind overflow CSS, and stale evidence from older bytes cannot certify a release. PageSpeed sign-off is now equally explicit on mobile and desktop: performance cannot fall below 80, accessibility and best practices must score 100, staging-adjusted SEO must score 100, and every applicable agentic-browsing audit must pass. Two new data tools preserve historical migration value: one builds a reviewed redirect manifest, while the other reconciles search, analytics, crawl, and form evidence before anyone decides what content to keep or rebuild.

the biggest addition is a full WordPress → Cloudflare migration *builder* (`WordPress to Cloudflare migration engine`) — it doesn't just check a migration the way the rest of that lane does, it produces one: crawls the old site, rebuilds every page, rewires the forms, and hands back a deploy-ready bundle, with a go-live report generated from real proof rather than a checklist filled in by hand. `Migration gate` (the pre-launch gate) can now also verify a site *after* it goes live, not just before. Two new content-safety tools — one that checks a draft article's claims are backed by evidence before it goes out (`Draft quality gate`), and one that reviews whether a page is written the way Google's AI Overviews actually pull from (`Google AI Overview readiness`). The medical-content skills (`Draft quality gate`, `Content inventory`, `Content brief`) can now check a page's factual claims against a verified facts sheet before publishing, so a claim like "board-certified" or "FDA-cleared" has to be backed by a real, sourced fact or it gets blocked automatically. Also fixed a real packaging bug: a client's own website data was being accidentally bundled into the distributable toolkit package.

a new tool for teams that use Google Analytics 4 — read, write, and delete across accounts, properties, custom dimensions and metrics, conversions, and the Measurement Protocol, standalone (it doesn't need a full toolkit checkout to run). Like every write-capable tool here, it previews what it's about to change before it changes anything. Also: a structured map of "what this problem means and how to fix it" that reports can now draw on instead of just naming a finding.

this release is mostly the tools getting more honest about what they can and can't actually see, plus a handful of real defects fixed along the way. Checks that used to return a confident FAIL now recognize when the real situation is "this is a staging preview," "this page needs JavaScript to render and the tool doesn't do that," or "this URL is a feed, not a page" — and say so instead of flagging a false problem. When several scan tools run against the same site at once, they now share one pacing budget instead of each independently overwhelming it. Every write action (updating a WordPress page, writing alt text, and the like) now re-reads what it just wrote and flags a mismatch instead of trusting that the write worked. New: a checker and builder for the llms.txt file some AI crawlers read, and real example reports for two of the tools that you can look at before running anything yourself.

When someone asks us to take a word off a website — a discontinued treatment, an old product name — we search the site for it and edit it out. The search only ever looked at the words a visitor can actually see on the page. A mention hiding in a link, a page title, or the invisible markup underneath counted as clean. That is how a request to remove every mention of something can be signed off while mentions are still on the page, which is exactly what happened. The search now looks in those hidden places too, and tells you which kind of place each mention was found in — because a link you delete and a sentence you rewrite are different jobs.

Alongside it there is now a written procedure for this kind of request, covering both "remove it" and "replace it with something else", with one deliberate rule: the list of every mention and what happens to each one gets approved before anybody edits a live client site. That list doubles as the reply the client should get.

The library of procedures also starts counting something it could not see before: the individual steps inside them that a person still has to do by hand. Previously a procedure was either written or not, all-or-nothing, so a five-step process with one manual step in the middle looked fully automatic. Those hand-offs are now listed, and that list is the honest answer to "what should we build next."

Added a new tool that can actually make changes inside Google Tag Manager — creating and editing tags, triggers and variables, linking them together, and publishing a new live version — instead of just reading what's already there. It signs in with a service account rather than a personal Google login, which suits automated or scheduled use.

Two of the toolkit's own quality checks were switched off without anyone noticing. One of them checks that the sample data the tests run against hasn't been edited by hand; the other checks that every page of the wiki has the things a wiki page is supposed to have. Both were working correctly — nothing was running them. While they were unwatched, a fixture fix got undone three separate times, and the wiki quietly published a page with an internal code name on it, a brand-new tool with no picture and no version number, and four guides missing their one-line description. All of that is fixed, and both checks are now part of the routine that runs before a release, so they can't go quiet again.

Separately, the to-do list got a clear-out. It had grown to the point where nobody could tell what was actually ready to work on — the answer turned out to be "nothing", because dozens of items were waiting on questions that had already been answered months ago in a comment somewhere nobody looks. Twenty-five items are now marked ready and startable. Four were closed because their work was finished, one because it was a rule rather than a task, and one because there was no real reason to build it. Eight design items moved to their own repository. Two big decisions that several items were all waiting on — how the toolkit signs in to Google services, and whether a tool may rewrite the body text of a client's web page — are now written down in one place each, rather than buried in a comment thread, which is exactly how they got lost the first time.

With the backlog actually sorted, a batch of the now-ready items got built. A full site audit checks image weight and gallery quality by default instead of silently skipping images. Reports can be sent as a clean, inbox-safe email instead of only a browser page — and along the way, a report bug that had been silently dropping items from one tool's "what to fix" list, for any tool without its own custom write-up, got caught and fixed. The image optimizer can now tune each image's compression quality automatically against how much it actually needs, instead of one fixed number for everything, so flat graphics come out smaller and detailed photos keep their quality. Font-loading problems get their own specific advice instead of a generic warning. The content-freshness and word-count checks now understand several more page types (procedures, locations, home pages, about pages) instead of guessing with a generic default. A release can now ship a tamper-evident checksum so anyone installing it can verify the files weren't altered in transit. The screenshot tool learned to test dark mode, reduced motion, print layout, and browser zoom — all previously untestable. The ticket QA tool can now post its verdict straight onto the support ticket as an internal note, closing a gap where the result lived in a report nobody reopened instead of next to the ticket it was about — with a real constraint respected rather than papered over: a posted note can never be edited or deleted, so posting one always requires typing the exact ticket number to confirm. The WordPress inventory tool can now list every site's live application-password credentials — name, when it was created, when it was last used — something nobody could check before without opening wp-admin by hand. The meta title and description writer now checks, every time it publishes, that nothing else on the page moved — that used to be a flag you had to remember to add, and now it just happens. Every tool that scans a client site now identifies itself the same way, so a client's own analytics can filter our traffic out instead of counting our scans as real visitors. Connecting a Google account also got easier: the analytics and search-console tools used to only work with a shared service-account key someone had to set up first. Now a person can instead just sign into their own Google account once, the same way they already do for other Workspace tools, and use that instead — or alongside it, since both keep working. That same sign-in also powers a brand-new tool that reads a Tag Manager workspace directly: every tag, including drafts that haven't been published yet and which ones are paused, none of which was visible before without opening Tag Manager's own page by hand. It only reads, for now — it can't create or publish a tag yet. The gallery inventory tool had a bug that quietly mangled almost every image address it captured — anything containing the letter "s" (which is nearly all of them, since web addresses start with "https") lost a character and got scrambled with its neighbor. It shipped with no test checking that it actually worked, which is exactly how it went unnoticed; both are fixed now. There's also a new self-check a tool can run on the actual report it just produced before handing it to someone, catching a broken or non-portable deliverable at the moment it's made rather than whenever someone happens to open it. And a new check makes sure a skill's documentation never points at a file that doesn't exist, or leaves a file nobody's documentation mentions.

The tool that pulls keyword-research data from SEMrush was silently coming back empty on every single search — a real bug nobody had caught because nothing was checking the answer it gave. It's fixed now, and there's a real test in place so it can't quietly break the same way again. The on-page SEO scanner's "long URL" check is now adjustable, and a site-wide scan names the exact long URLs instead of just flagging that some exist, and now also checks the URL's slug for readability — special characters, too many words, filler words, stale-looking dates, and (optionally) whether it contains your target keyword. It can also now check that a page's body copy actually uses that keyword the way good SEO copy should — placed early, not overused, and without heading sections that are basically empty. The meta-title/description writer can now review a whole batch of pages — showing every page's before and after — before publishing any of them. There's also a brand-new **testimonials checker** that renders a page and tells you whether the reviews section actually shows real, current, structured reviews — it catches a review widget that loads but paints nothing, a "testimonials" section full of lorem-ipsum filler, and a wall of five-year-old praise. And two auditors learned to stop crying wolf on legitimate sites: the local-SEO checker no longer flags a practice with **two offices** as having a "wrong address" or "inconsistent NAP" (it treats each directions link as correct if it points at any office the site lists), and the link checker no longer reports a **CareCredit-style Akamai bot-wall** 503 as a broken link. Under the hood, two shared building blocks graduated from the lab: a durable record for a human decision that has to survive a scheduled check or a second session, and a data contract for honestly tying a change to its result — neither changes anything a client-facing report shows today, but future tools will build on them instead of reinventing them.

Installing the toolkit no longer fails silently when a skill's shortcut is broken — it now tells you and fixes it instead. The split between this repo and its companion repos is now complete. Report emails can share one common header, footer and a set of ready-made building blocks (KPI numbers, callout boxes, action lists) instead of every report designing its own from scratch. And the three tools that compare an old site against a new one during a migration have now been proven working against two real, different WordPress sites, closing a gap where they'd only ever been tested against one.

The quality gate that runs before every release was one giant file; it is now split into focused pieces, and the same gate runs automatically on every pull request so a merge can't land on a red check.

- Refactored: the 962-line `verify-toolkit.mjs` is now a thin aggregator over `scripts/gate/` (`shared.mjs`, `skill-checks.mjs`, `repo-checks.mjs`) — output byte-identical, external imports and the `capability-report` scrape unchanged; `wiki-freshness-blocked.test` updated to the new home. - Added: `.github/workflows/gate.yml` reinstates CI — DoD gate + test suite + wiki build on PRs and `main`, plus a fresh-install matrix — the 2026-07-30 removal was reversed because the PR-only merge model otherwise has no automated gate.

In plain terms: A few tools now say which sibling tool to reach for when a request is actually that sibling's job, so an ask like "make me a report" no longer has two equally-plausible answers. Tools that run other tools now declare the dependency, the wiki's composition map reflects that, and two oversized reference documents were split so an agent reads only the part it needs.

- Added: gate check that a skill declares every skill it actually composes via `resolveDep` — it caught Divi audit running Screenshots without declaring it. - Added: `requires: Screenshots` to Analytics & tags, Pre-cutover site archive, Divi audit; routing cross-references between Client report (PDF)/Report builder, SEMrush research/Keyword research & planning, GA4 behaviour series/Search Console series; trimmed 7 descriptions sitting at the 1024-byte cap. - Fixed: WordPress REST inventory now has a captured sample run (clears a verify-toolkit warning). - Fixed: `context-budget.mjs` walks `references/` recursively, so an oversized file can no longer hide from the split warning. - Split: Site crawl (Screaming Frog)'s two 31-48KB reference lookups into 8 files under the 12KB read-whole budget.

In plain terms: Internal tidy-up, with one real fix. The ".env loader" that was copied into dozens of tools is now a single shared helper, several unused files and dated documents are gone, and one credentials check now honours an explicitly-empty setting. Nothing a normal run does has changed, but the wiki builds again and the codebase is easier to keep consistent.

- Refactored: one shared `scripts/lib/env.mjs` replaces the 27 per-skill `loadEnv` copies; `llm.mjs` re-exports it so LLM skills are untouched. - Fixed: `loadWpEnv` no longer fills an explicitly-empty `WP_*` var from `.env`, so an exported empty value actually turns a keyed path off (a credential-less machine stays inert). - Removed: dead `scripts/lib/markdown.mjs` and the leftover `site/docs/Motion & animation audit.js`; archived 11 dated/client-named docs to `docs/history/` — the wiki build gate was failing on them. - Updated: stale counts in `docs/releasing.md` and `AGENTS.md`; `Setup & doctor` now links the live wiki instead of the removed `index.html`.

In plain terms: A multilingual migration can no longer look healthy just because the English pages survived. The gate now counts every language separately, checks that translated links point back to each other, and proves the language selector does not send visitors to a homepage or a 404.

- Added: shared multilingual parsing and migration evidence for per-language coverage, safe URL-map derivation, hreflang reciprocity/self-reference/`x-default`, and language-switcher behavior (issue #226), consumed by Old vs new page parity, Migration gate, and site-wide On-page SEO runs. - Updated: the migration checklist and release documentation now mark the multilingual acceptance rows as built and explain when an explicit URL map is still required.

In plain terms: Reports now say what they are in their folder and filename, while keeping the short tool codename alongside it. A performance report, for example, no longer hides behind a generic `report.html`; it has a name that is understandable in a shared client folder. This is an intentional breaking change for saved report links and any automation that reads the old paths.

- Changed: primary HTML and text reports now use `<friendly-name>-<codename>` for both their output directory and filename, replacing codename-only directories and generic `report.html` / `report.txt` names (issue #362). All affected skills are major-version releases; update saved paths and downstream report readers. - Added: Structured data (schema) delivery validation review-warns when LocalBusiness, Product, or AggregateRating claims have no supporting visitor-visible page evidence (issue #315).

In plain terms: Toolkit can also read a managed WordPress site from the inside, so plugin, theme, user, route, and content facts no longer have to be inferred from public page code.

- Added: `WordPress REST inventory`, a read-only authenticated WordPress REST inventory, intentionally standalone from WP plugins & theme and inert without the existing application-password configuration (issue #310). - Added: opt-in installer-managed Claude `PreToolUse` safety hooks (issue #267). Interactive installs back up and merge `~/.claude/settings.json`; non-interactive and `--target` installs leave it alone.

This release makes large, multi-site changes safer to plan and review, and makes the common page information that many checks need available in one reliable place. Reports now distinguish an automated block from a completed check, so a pipeline cannot quietly treat an unanswered problem as success.

It also improves the day-to-day editing guardrails: shared site headers and footers require explicit approval before they can be changed, and browser challenge pages are reported as access blocks instead of ordinary failures.

- Added: Fleet-tier write doctrine — a stricter gate (target-list confirmation hash + out-of-band approval ref) for plans touching >1 client account, >5 sites in one account, or any irreversible op, plus a 3-state reversibility field (`reversible` / `irreversible-captured` / `irreversible-uncapturable`) replacing the old binary in `write-log.mjs` (issue #256). - Added: `page-artifact` — a shared, cached, versioned page-parse primitive (title/meta/canonical/headings/links/images/JSON-LD/detected tags/dates/readability/NAP), standalone and adopted by nothing yet (issue #444). - Changed: Divi audit now treats global Divi headers and footers as protected scope; a page-content request cannot authorize a Theme Builder edit without the template named and owner approval (#325). - Fixed: Screenshots hung 60s and reported FAILED on a Cloudflare-challenged page instead of settling and reporting BLOCKED (issue #434). - Fixed: Site audit (all-in-one)'s BLOCKED verdict silently exited 0 in CI; added `exitCodeFor()` to `scripts/lib/pipeline.mjs` so BLOCKED now exits 3, per #136's decided mapping (issue #437). - Refactor: Content freshness and Promo expiry scanner now share their date-token extraction (schema dates, `<time>` elements, month-name matching) via new `scripts/lib/dates.mjs`; Promo expiry scanner's promo-classification logic is unchanged (issue #440). - Added: `scripts/lib/html.mjs` — shared attr/metaContent/title/canonical/headings/links/visibleText, adopted by Alt-text writer, Old vs new page parity, Cutover readiness, Link & image checker and On-page SEO in place of their private copies (issue #439).

Two tools were writing their reports somewhere other than where you told them to. One of them ignored the shorthand for "put it here" that every other tool accepts, so the report came out complete and correct in the wrong folder, with nothing to tell you it had happened. The other was doing the right thing all along but its instructions only described one of the four places output can be configured, so a machine set up a while ago looked broken when it was merely configured differently. Where output goes is now written down in one place.

The page that says which checks are proven was written in the vocabulary of the person who built the test bank — every row said the same unreadable sentence, so the column meant to tell you how far to trust each tool got skipped. It now says whether we checked the answer or only checked it runs, in those words. The long table on "At a glance" keeps its column headings visible while you scroll, and the "In action" pages no longer sound like they are scoring points off the reader.

And when a check fails, the report now carries the whole list of what failed rather than the first five with no hint there were more — including in the list you copy and hand to an agent to fix, which is the one place a missing item means the work silently does not get done.

Reports also gain a section that answers the question people were actually opening the raw data to answer: which pages need fixing, and for what. Instead of a list of problems with no addresses, one group per issue with the pages named under it.

A run of fixes to the same underlying mistake, found nine times over: the answer existed and something between it and the report threw it away. A gate that said every check had cleared when several never ran. A crawl that said it produced nothing while its results sat on disk. A plugin audit that reported confirmed vulnerabilities it had no way to confirm. A page counted twice because a redirect overwrote which page it was. In each case the tool had the right answer and lost it on the way out.

And the remote crawler now works on a fresh install. Its address was left blank in the shipped config with nothing explaining what belonged there, so nobody new could run a crawl at all. The address is filled in; the personal token still isn't, because that part genuinely is a secret.

The spell-checker can finally be run against our own wiki. It was flagging every tool codename, every file extension and every British spelling — thousands of them, none of them wrong — so a real typo would have been invisible in the pile. Nine in ten of those are now filtered out, and the house spelling is written down as British for the first time.

There is also a new page recording which audit findings are real and which are our own tools misfiring on our own site — the same handful kept getting re-investigated from scratch every time somebody ran a check.

And the crawl checker can now tell you which of the ~600 files in a Screaming Frog export are real reports and which are duplicates or empty placeholders — most of the folder turns out to be noise, and it will list exactly the ones you can delete.

Release notes are readable again — the last one published as a single 1,400-word paragraph, and now arrives as short sections with headings. And the capability report, the page that says which checks are proven and which are only partly covered, was quietly cutting two of its explanations off mid-sentence and still claiming an old count of the tools; both are fixed, and a test now stops either from happening again.

The report builder had quietly become the hardest tool in the set to find. Nothing on its page told you what to ask for, its example output was missing entirely, and one of its links went nowhere — so the tool whose whole job is making things readable was the one nobody could see. All three are fixed, and each now has a check that stops it happening to any other tool.

The hosting lookup told you to set up a key you had already set up, because it was the one tool that never looked in the shared settings file. And when it genuinely could not show a client's subscription details, it explained why on screen but left that explanation out of the report the client receives — so the gap looked like nothing worth mentioning. Both fixed.

This release is mostly about migrations — making the pre-launch gate harder to fool — plus **three new skills** for finding out where a site is actually hosted, a rebuilt team wiki, and one consistent table style across every report.

Before a migration goes live. The old site now gets archived first, and that archive is scanned for things that should not be kept: leaked passwords or API keys, and photos that might show a patient's face. A found secret blocks the checklist until someone explicitly signs off on why it is safe to proceed. A flagged photo is only noted for a human to look at, because deciding what may be stored is a client and legal call rather than a tool's.

Recording the answers only a human can give. Roughly a third of the migration checklist is questions a person has to answer by hand — where is the backup, was the rollback tested. The tool can now record those answers against the file that proves them, so it stops asking the same question on every run. If that file later changes, the answer automatically stops counting instead of quietly going stale.

Knowing the whole site came across. The checklist now asks the old WordPress site directly how many posts, pages, products and events actually exist, and compares that to what was captured — so it can tell you whether it knows about every page, not just whether the pages it already knew about survived. A page that is a title with nothing real underneath is caught too, even when a before-and-after comparison alone would not notice.

Catching edits made during the migration. A migration takes weeks and clients keep editing their site throughout. The tool can now re-check an earlier snapshot against what is live right now, including pages added since and the one kind of edit that changes no text at all — a purely visual restyle. Before this it would confidently report everything fine from a copy of the site that no longer matched reality.

How the new site was deployed. A new check covers the hosting setup itself, catching six specific ways a perfectly good website still ships broken: a security header that silently vanishes, one oversized file that blocks the whole deploy, a build tool quietly rewriting the page's code, an old cached version served after an update, deploy settings written but never turned on, and a password-protected preview page that turns out to be reachable through a back door.

Whether it still looks the same. Old and new can now be compared page by page, side by side — a different question from whether either changed over time. It reports separately on what you see before scrolling versus further down, names known-noisy pages such as a carousel that is never in the same frame twice rather than relaxing everywhere, and can compare against an earlier snapshot once the old site is gone. The page-by-page spreadsheet gained a visual column, so a page that passes every text check but still looks broken cannot slip through, and a page nobody checked visually says so by name instead of sitting blank.

Leftover WordPress files. The report now says how big each one is, whether it is slowing the page down, and — the useful part — whether the new site still uses it. A stylesheet nothing reads from is safe to delete; one the design still depends on is not, and that difference is now visible rather than guessed. A script still calling a WordPress feature that no longer exists is flagged as a real problem, since anyone submitting that form would hit a dead end. Removing the leftovers only counts as a win if the page still looks the same afterwards — if it does not, that is a failure, not a performance improvement.

Running only part of the gate. You can now ask a narrower question. "Is the new site any good on its own" needs only the new URL with no old site required, while "did everything come across" and "can we launch" run the fuller comparisons. Whichever you run, the report opens with one plain sentence — ready, or not ready and here is what is stopping it — instead of a table you have to interpret yourself.

Forms and leads. The form check goes past "can this be submitted": it can send a real test enquiry, only when you explicitly ask and only against a destination you have already confirmed is safe, then follow it through — did a thank-you page appear, does that page stay out of Google, and did it register as a conversion. It also names which spam-blocking service a form uses and which setting to double-check before launch, since junk leads and wrong-language leads almost always trace back to that one setting rather than a bug. And "was the lead delivered", which used to be one unanswerable yes or no, is now three specific questions: did it reach the real inbox rather than a developer's, was it archived somewhere recoverable, and did it show up as a conversion.

Speed, captured before the switch. The old site's real-world page-speed numbers — the ones from actual visitor data rather than a lab test — are now recorded before the domain moves. That data belongs to whoever hosts the site at the time, so once the domain moves there is no way to prove what the old site's speed was. A site too small for Google to hold that data is marked "not available" rather than silently counted as a pass or a problem.

The team wiki was rebuilt. The twelve write-ups of real jobs the checks caught — one ticket or board card each, and what came back — are readable on the wiki under "In action" instead of existing only as email drafts nobody had sent, and search covers them, so "have we seen this before" finds the time we did. The front page now opens by showing how you ask for a check in plain English rather than with a command to copy, and carries a plain-language "what's new" list. A new "Scenarios" section lists every situation we handle, found by the sentence a client actually said rather than by a tool name, with an honest note on each about what it will not tell you. And anyone handed access for the first time gets a page explaining what this is and what it deliberately does not do, instead of being sent straight to an install command.

Three new skills: Cloudflare, WP Engine and MainWP. Three genuinely new tools you can install and run, one per host. Each answers "where is this site running, and what does the host say about it" directly, without logging into three separate dashboards — and a fourth piece works out which of the three a given domain belongs to, so you can ask the question without knowing the answer first. All three are read-only and stay silent rather than failing when you have not set up a key for them.

One table style everywhere. Reports now share a single table design across the browser, a PDF and an email, instead of fifty-odd tools each inventing their own.

Fixed. Several bugs found by running the migration checklist against a real client site, including one where the tool could silently skip archiving the old site before it went offline — something that can never be redone once it happens. Cookie-banner checks no longer fail when the Accept button cannot be found; that is now reported as "couldn't verify" rather than "broken". Image audits no longer leave stray files in whatever folder you ran them from. Broken-link checks no longer mistake LinkedIn's anti-bot response for a dead link. A crash when every check on a page was bot-blocked is fixed. The dense banner image on the repository front page was replaced with a simpler one.

Before a migration goes live, the old site now gets automatically archived — every page's HTML, screenshots and headers — so if a client asks "what did that page used to say" six months later, there's a real record instead of just a promise. Overnight runs across a whole book of sites can now resume where they left off if interrupted, instead of losing everything and starting over. We can now verify a cookie-consent banner actually blocks tracking scripts until a visitor agrees, not just that the banner shows up on screen. Added checks for: before/after photo galleries breaking during a migration, leftover broken page-builder elements (carousels, popups, tabs) on a rebuilt site, whether site search still works after moving off WordPress, and whether DNS records were captured before a domain switch. Page-coverage checks are more complete too, now pulling in pages that show real traffic in Google Search Console or Analytics even if they were never in the sitemap. Plus a batch of smaller fixes to how the documentation site labels and displays each tool.

Three new tools joined the set: one writes the crawler-facing files a brand-new site needs before it launches, one publishes a finished document straight to the team wiki with its images intact, and one reads our internal work log. Auditing a client's live site got genuinely safer — the limit that was meant to stop us putting load on a site people are actually using turned out to protect almost nothing, and now does what it always claimed to. Accessibility checking got stricter: colours are now checked in their hover and focus states rather than only at rest, and mobile menu buttons are properly recognised instead of being missed. We also started publishing an honest capability report — which checks are proven against a known-answer test and which are only partly proven — generated from the code rather than asserted by hand.

The WordPress-to-Cloudflare migration checklist landed: 117 checks covering what has to be true before a rebuilt site replaces the live one, together with the map explaining how that gate works and who signs off on what. A new tool reads our task boards, so a board's contents can be pulled into a report instead of copied out by hand. Setting the toolkit up got easier too — the guided setup now walks through connecting it to other services, and the whole thing installs as a standard plugin package rather than a bespoke arrangement.

Every tool now ships with a real example of its own output, so you can see what you will get back before running anything. Checking those examples turned up two that were pictures of the tooling failing rather than of the tool working — both fixed, and the process that generates them no longer reports imaginary changes on files nobody touched. A crawl comparison was producing data files but no readable report; it now produces both.

The pre-live migration gate arrived — the set of checks that runs before a rebuilt site replaces the old one, including page speed measured on our own machines against Google's published thresholds. It now judges the new site on its own merits, rather than treating an exact copy of the old one as automatically good enough. Two new checks catch problems that look fine from the outside: a server that quietly returns a normal-looking page instead of a proper "page not found", and image files that are actually error pages wearing a photo's filename. A bug in shared text handling meant certain special characters were being read wrongly everywhere they appeared — found and fixed. Release numbering also moved to being assigned when a release is cut rather than on every single change.

Screenshots now refuse to capture a logged-in admin screen, so a browser session that happens to be signed in cannot leak into a client-facing report. When verifying a change you can now state what you set out to change, and the check will tell you if something else moved instead of what you intended. Guidance for Divi sites now requires a before-and-after comparison rather than merely suggesting one.

The tables in our documentation that describe what each check looks for are now tested against the code itself, so a rule cannot quietly change without its documentation following. Four more tools were brought under that gate, and some stale counts in the release documentation were corrected.

#195 is closed — all five issues. The verdicts a page documents answer to the fixture bank, and the thresholds underneath them answer to the code.