Three days after we delivered the pre-launch audit, the client's development team responded with two pushback questions. We re-audited the live site to verify every original claim, dropped the ones that didn't survive a second pass, and shipped a 19-item priority list with explicit visibility checks and HTTP probes on every URL. This is what a follow-up audit looks like when you're willing to be wrong out loud.
Companion case study: Pre-launch audit (May 11, 2026).
--ct slugs. The team built them under --ma slugs by mistake. Customers clicking "Simsbury, CT" or "Avon, CT" on the service-areas page get sent to Massachusetts URLs -- the only versions that exist. Root cause: one bulk copy-paste session, never re-slugged.
Most audits don't show their work when they're wrong. Five claims from the original pre-launch audit were either dropped or rewritten in the follow-up:
| Original claim | Verification result | What we did |
|---|---|---|
| "Reviews widget renders empty 124-byte placeholder" | False -- widget IS rendering reviews to real visitors. Headless Playwright probe blocked by Elfsight anti-bot fingerprint. | Apologized to client; downgraded to two SEO-only recommendations (static HTML fallback, aggregateRating schema) |
| "No click-to-call link in header" | False -- tel:413-XXX-XXXX IS in the header. |
Removed from priority list; added as a credit-where-due item |
| "Hash-suffix URLs are duplicate content competing with clean URLs" | Wrong direction -- hash-suffix URLs are the dev's corrected versions of buggy clean originals. | Recommendation flipped: pick canonical, redirect the buggy ones |
| "Wrong city name leak on East Hartford page (Manchester, CT in heading)" | True in HTML, false in user experience -- heading has visibility: hidden CSS. SEO-only bug, not user-facing. Plus Manchester is geographically adjacent to East Hartford anyway. |
Dropped entirely |
| "Agawam page has 2 wrong-city headings, both user-visible" | Partial -- 1 visible, 1 CSS-hidden. Different impact (UX vs SEO). | Answer rewrote to distinguish the two cases |
The verification round didn't just retire false claims -- it surfaced new ones the first-pass probe missed:
| Category | Finding | How we verified |
|---|---|---|
| Missing CT landing pages | 5 Connecticut city pages return 404 at their correct --ct slugs; the team built them under --ma slugs by mistake |
Direct HTTP probes of 10 URL variants (5 cities × 2 slug conventions) |
| Missing MA landing pages | 3 Massachusetts city pages don't exist under either URL convention; service-areas page hard-codes nearest-neighbor fallbacks to mask the absence | Direct HTTP probes of 6 URL variants |
| Visible-vs-hidden DOM distinction | One Agawam H3 is visible to users; one has visibility: hidden and is only readable by Google's crawler. Different audiences, different fix urgency. |
document.body.innerText + getComputedStyle() on element and parent chain |
| Mobile-responsive failure on service-areas page | Mobile viewport shows only drive times in a column with no city names. Switching to "Request Desktop Site" makes the buttons appear correctly. | Live phone screenshot from the business owner |
| 8+ wrong-destination links on service-areas | "Avon, CT" link goes to Massachusetts URL; "Southwick" goes to a Springfield page; etc. | Raw HTML scrape of <a href> attributes |
Without naming specifics -- those go to the client -- the 11 Tier-1 items cluster into three workstreams:
aggregateRating schema in homepage JSON-LDThe case study isn't about the bugs. It's about what happens when an AI-assisted audit is wrong, and how the follow-up handles it.
Most AI-generated audits don't second-pass. They generate one set of findings, hand them off, and disappear. When the client's dev pushes back, the answer is either silence or a defensive doubling-down on the original claim.
This audit's follow-up:
visibility: hidden CSS hides DOM from users but not from Google's crawler).getComputedStyle() visibility check. Every JSON-LD claim got a fresh extraction.The dev didn't need to fight for credibility. The audit gave it back voluntarily where it was due.
To be filled in once client reports shipped fixes -- estimated 1-2 weeks from delivery, 2026-05-14.
| Tier | Items committed | Items shipped | Items deferred |
|---|---|---|---|
| Tier 1 | 11 | pending | pending |
| Tier 2 | 3 | pending | pending |
| Tier 3 | 4 | pending | pending |
Pre/post screenshot diffs and SERP-snippet comparisons will be added here once the dev team's fixes go live.
Companion case study: Pre-launch audit (May 11, 2026).
Pricing is scoped to the size of your site and the depth of the engagement. Every quote is custom; we send one within one business day of your audit request. The pre-launch audit (companion case study, May 11) was a Standard Audit. This follow-up verification round is a Follow-Up + Verification engagement -- $449 flat.
For small businesses wanting a fast health check on a live site without committing to a full audit.
For sites at any launch stage needing a thorough technical and content review. The most common engagement.
For pre-launch sites, platform migrations, or strategic relaunches needing the full stack.
How quoting works. Send a request with your domain and a one-line description of where you are in your launch cycle. We respond within one business day with a tier recommendation and a fixed-fee quote based on site size, complexity, and the depth of detail you want. Nothing starts until you approve the quote.
A typical audit kicks off the same week, delivers the next business day, and saves the client more in pre-launch fixes than the audit itself costs. Every single time.