In March 2026, we stripped 2.8 million programmatic pages to the studs and rebuilt them with real data after Google's spam and core updates landed on our exact architecture (we documented every decision here). Three months later, we ran the follow-up: a full technical SEO and E-E-A-T audit. The difference this time is who ran it. Not a crawler. Not a dashboard. An AI agent that measured the live browser, graded the pages against Google's published policy, edited the codebase, and deployed the fixes — in a single working session. This is what it found.
It measured the browser, not a dashboard
Most SEO audits begin and end in Google Search Console. Search Console is invaluable, but it reports what happened two or three days ago, aggregated and sampled. We wanted to see the page render in real time. So the agent opened a real Chromium session, attached to the DevTools protocol, and captured a live performance trace of the homepage and a representative service page — Largest Contentful Paint, Cumulative Layout Shift, long tasks, and the full network waterfall.
The verdict was reassuring: both pages sit comfortably inside Google's "good" Core Web Vitals thresholds, with zero long tasks blocking the main thread. The only render-blocking resource anywhere was the Google Fonts stylesheet. (These are fast-network, edge measurements; real mobile field data runs slower, which is exactly why the small fixes below still matter.)
Are 30,000 programmatic pages a risk? No — and here is the receipt
The obvious worry for any site with tens of thousands of city-by-service pages is Google's scaled-content and doorway-abuse policy. The agent went to the source. Google's own spam documentation states that programmatic city and service pages, "even across thousands of combinations," are not automatically doorway pages — they are legitimate when each one carries genuine location-specific value.
Then it inspected an actual page. Our Austin HVAC page carries, per page:
- Real metro data — population, median household income, median home price, growth rate, climate
- Category intelligence — local CPC ranges, seasonality, the mistakes that waste budget in that vertical
- A named author with a verifiable, decade-plus track record
- Contextual internal links to nearby cities, related services, and deeper guides
That is enrichment, not a keyword swap. The pages clear the bar today. The audit's recommendation was not "tear it down" — it was "make the local detail even more concrete."
The weight we could not see was never the HTML
People assume a big page is a slow page. Our homepage HTML is large, but it is not the problem. The network
trace told the real story: 12 scripts totaling 389KB, and two of them — served first-party from a
/bkc2/ path — accounted for roughly 326KB on their own. That is Microsoft Clarity's
session-recording payload, proxied first-party, plus React on the homepage.
None of it was render-blocking, so it did not hurt Largest Contentful Paint. But on a mid-range phone, 326KB of analytics JavaScript is real parse-and-execute time and a genuine interaction-latency risk. The fix was not to delete it — every tag still has a job — but to delay it. Tag Manager (and therefore Clarity) now loads on the first user interaction, or 3.5 seconds after the page loads, whichever comes first. Every tag still fires. The 326KB simply leaves the critical path.
What it shipped — in one session
- Fonts un-blocked — the single render-blocking resource now loads asynchronously, site-wide.
- Cache conflict resolved — a duplicate
/shared/*header was forcing year-long immutable caching on files meant to update within minutes. Fixed, so site-wide nav and consent changes actually propagate. - Internal linking — every service page now links to the evergreen guides that match its own pain points (conversion tracking, budget pacing, Smart Bidding).
- Content enrichment — real neighborhoods, landmarks, and category-specific trust signals woven into the programmatic pages (more below).
- Script trim — analytics deferred off the critical path, removing 326KB from first load.
Turning data into local detail
The strongest defense against being mistaken for a doorway page is specificity a national lead-gen reseller could never fake. The audit flagged one line on every page that told readers to "mention neighborhoods and local landmarks" — without naming any. So we added them. The Austin page now references South Congress, East Austin, and the Domain, and Lady Bird Lake. The Chicago page references the Loop, Lincoln Park, and Wicker Park. On top of that, each page now carries a category-appropriate trust signal — licensing and bonding language for home services, credential and board-certification language for healthcare, bar-admission language for legal.
The bigger story: what the tools cannot do
Here is the part worth sitting with. There is a mature, excellent toolset for SEO — Google Search Console, Screaming Frog, SEMrush. We use them. But each one stops at the same place: it hands you a list. Someone still has to interpret it, decide what matters, write the code, and ship it.
| Capability | Search Console | Screaming Frog | SEMrush | ahmeego / Buddy |
|---|---|---|---|---|
| Live in-browser CWV trace | ~ field/CrUX | ~ via PSI | ~ lab sample | ✓ live CDP |
| Technical crawl (links, meta, status) | ✗ | ✓ | ✓ | ✓ |
| Policy judgment (is this a doorway?) | ✗ | ✗ | ✗ | ✓ |
| Implements the fix in your codebase | ✗ | ✗ | ✗ | ✓ |
| Deploys and verifies live | ✗ | ✗ | ✗ | ✓ |
| Aware of your stack and templates | ✗ | ✗ | ✗ | ✓ |
| Typical cost | Free | ~$259/yr | $140+/mo | Built-in |
The distinction is not that the tools are bad — they are superb at their slice. The distinction is where the work ends:
- Search Console tells you what happened.
- Screaming Frog tells you what is broken.
- SEMrush tells you what to consider.
- An agent like Buddy measures, decides, fixes, and ships.
Crucially, the agent did one thing no checklist does: it made a judgment call. "Are these 30,000 pages a doorway violation?" is not a yes/no a crawler can answer — it requires reading the current policy and weighing it against the actual rendered content. That is the work a senior practitioner does. The agent did it, then implemented the consequence.
What it deliberately did not do
Restraint is part of a good audit. The agent left several things alone, on purpose:
- It did not remove React. The homepage runs a substantial React app — not a single widget — so ripping it out would have been a risky rewrite for a marginal gain. It stays.
- It did not gut Clarity. Session-recording data is valuable; deferring the load preserves it while removing the performance cost.
- It did not touch pricing, design, or the font families. Reducing brand fonts is a design decision, not an engineering one, so it un-blocked their loading without changing the look.
- It measured before it changed anything. No optimization theater. The numbers came first; the work followed the evidence.
The takeaway
SEO has never been short on data. It has been short on the connective tissue between knowing and doing — the hours a practitioner spends turning a report into a deploy. That gap is where most audits quietly die in a spreadsheet. Closing it is the whole point of building an agent that lives in the codebase, reads the policy, and ships. We measured ahmeego.com, graded it against Google's current standards, strengthened the programmatic pages with real local detail, took 326KB off the critical path, and pushed it live — in one session. The tools told us where to look. The agent did the work.
This audit was performed on ahmeego.com in June 2026 using a live browser performance trace and Google's published spam and helpful-content policies. All performance figures are from in-browser DevTools measurements. The platform is open source at github.com/itallstartedwithaidea.