An Agent Found, Fixed, and Verified a Real SEO Defect on Our Site

One page on trustgrowth.ai was shipping two H1 elements instead of one — here's the exact audit, PR, and re-audit that closed it.

This is not a conceptual thought piece about what SEO agents could theoretically do. It's a record of one completed Groundcrew run against TrustGrowth's own site, covering a single defect class on a small number of pages. Nothing here should be read as a claim about rankings, traffic, or generalized autonomous SEO capability.

What this post shows — and what it does not

This post documents one real defect, detected and closed on TrustGrowth's own site — not a synthetic demo, and not a stand-in for every SEO issue an agent might encounter. The scope is narrow and specific: detect the issue, diagnose the root cause, open a pull request, deploy it, and re-audit to confirm closure.

Here's what this run does not claim. It does not claim the fix changed rankings or traffic — no such data is presented, and none exists yet for this defect. It does not claim this generalizes to other defect types or other sites. It is one run, one defect pattern, one site environment.

The evidence sources named throughout this article are: the Groundcrew audit output, direct HTML source inspection of the affected page, the GitHub pull request and merge record, and a fresh re-audit run. Where an artifact exists only as an internal operator record rather than a public URL, that's stated explicitly rather than implied. For more on how TrustGrowth separates verified findings from softer heuristics, see what TrustGrowth measures and what it can't.

The defect we found on our site

Defect summary

The issue was a duplicate H1 defect: two <h1> elements rendering on the same page instead of one. It was found on a live blog post — https://trustgrowth.ai/blog/open-groundcrew-skills-for-seo-workflows-what-trustgrowth-publishes-and-how-to-inspect-it — and on a second published blog page sharing the same underlying template. We're using the URL above as the primary before/after evidence anchor in this article.

TrustGrowth’s multiple_h1 rule expects one page-level <h1> and measured two on the affected page. That is the specific structural defect documented in this run.

Why this issue mattered

The measured issue here is structural HTML consistency, not traffic: TrustGrowth’s multiple_h1 rule expects one page-level H1 and found two.

We are not claiming a traffic or ranking impact from this specific defect — no Google Search Console performance data is presented in this post, because none was used to verify this fix. The impact claim here is limited to structural HTML correctness, confirmed by direct inspection.

The evidence that confirmed the defect existed

The audit output flagged the pattern as multiple_h1 with a match count of 2 on the affected page, matching two literal <h1> tags in the rendered page source. You can verify this class of defect on any page yourself: view page source (or rendered DOM in dev tools), search for <h1, and count the results.

If you want to see how TrustGrowth distinguishes a confirmed structural match like this from a lower-confidence heuristic, read not every warning is the same kind of evidence.

How Groundcrew detected it in a real run

Starting conditions

The audit ran against the live production site, crawling published blog templates as part of a routine structural check. This particular run did not involve Google Search Console cross-checking — the multiple_h1 check is a direct source-inspection rule, not a GSC-report-derived signal.

Detection workflow step by step

Groundcrew's sequence on this run was straightforward: crawl the target template, parse the rendered HTML, count heading-level elements, and flag any page with more than one <h1> match. The finding surfaced as a structured audit record identifying the affected URL and a match count of 2, not as a paraphrased summary.

The finding did not auto-trigger a merge. The supported record shows the structured finding, CI, merge, deployment, and re-audit events. For a broader look at how these detection sequences are structured and where you can inspect them, see how to inspect Groundcrew workflows.

Why this was flagged as actionable, not just informational

The severity logic here is simple: a literal count of 2 <h1> elements against an expected count of 1 is direct evidence, not a hypothesis. It's the kind of finding TrustGrowth's site health score treats as a fixable structural defect rather than an advisory note, precisely because it's binary and independently checkable.

Diagnosis: what the root cause actually was

Technical root cause

The root cause was a template-level markup issue: the blog post template rendered a second <h1> element in addition to the page's intended primary heading. This is a component-level bug in how the template assembles heading markup, not a content-authoring mistake.

How we validated the diagnosis before changing code

Validation was done by inspecting the rendered page source directly and confirming two literal <h1> tags existed in the DOM, then tracing which template component emitted the second one. No CMS plugin conflict or third-party script was implicated in this diagnosis — the cause was isolated to the template markup itself.

The fix: PR, code changes, and deployment

The PR that fixed it

The fix shipped in pull request #535, which removes the redundant <h1> element from the affected blog template so each page renders exactly one primary heading. The PR merged at commit 0de96fc6.

Why this fix was chosen over alternatives

Removing the duplicate heading element at the template level was chosen over patching individual pages, because the defect was template-wide rather than page-specific — a per-page patch would have left the underlying component free to reintroduce the same duplicate on any future post using that template.

Deployment evidence

The fix reached production at SHA d1dcdec2. This deployment record is operator-record evidence — an internal deploy log entry, not a public URL — so we're naming it here rather than presenting it as a clickable artifact.

Re-audit and closure verification

Before vs after evidence

Check Before After Verification method <h1> count, affected page 2 1 Direct HTML source inspection Groundcrew multiple_h1 match count 2 0 Fresh Groundcrew audit Affected pages sharing this pattern 2 0 Fresh Groundcrew audit

Re-audit output

A fresh Groundcrew audit completed at 2026-07-12T22:17:39Z shows a current multiple_h1 count of 0, with both prior matches confirmed fixed. Nothing about this defect pattern remains open on either previously affected page as of that audit run.

This re-audit is operator-record evidence rather than a standalone public URL at this time. For how TrustGrowth defines closure and re-audit freshness generally, see verification, freshness, and score meaning.

What Google Search Console can and cannot confirm here

Google Search Console was not used to verify this specific fix. Duplicate <h1> elements aren't a distinct GSC Index Coverage or Performance report field, so closure here was confirmed through direct source inspection and a fresh audit run, not through a GSC-backed signal. Where GSC data is used elsewhere in TrustGrowth's scoring, it can lag actual page changes by days, and it does not validate every technical fix immediately or at all.

What this run says about agentic SEO work — realistically

What the agent handled well

On this run, Groundcrew reported an exact match count rather than a vague warning and re-checked the same rule after the fix shipped. Those are the specific things this run demonstrates — nothing more.

What the record establishes

The evidence packet establishes the structured finding, CI, merge, production deployment, and fresh re-audit. It does not establish specific human-review actions, so none are claimed here. This evidence-first boundary reflects the anti-slop doctrine TrustGrowth applies to Groundcrew skills.

What this does not prove

This run does not prove autonomous SEO agents can replace human operators, and it does not prove rankings or traffic improved — no such data is presented. It also does not prove every site defect can be safely auto-fixed; this was one defect class, on one template, on one site.

How to inspect the proof yourself

Here's exactly what's independently checkable right now:

• The affected page's rendered HTML source, where you can count <h1> elements yourself using your browser's view-source or dev tools.
• Pull request #535, publicly viewable on GitHub, showing the merged diff at commit 0de96fc6.
• Production SHA d1dcdec2, named here as the deployed commit for this fix.
• The fresh Groundcrew re-audit timestamp 2026-07-12T22:17:39Z, cited here as an operator-record result rather than a linkable public artifact.

Broader examples of how TrustGrowth publishes verifiable findings live on the proof pages.

If you want this kind of audit trail on your own site

TrustGrowth connects to Google Search Console, crawls your site, and scores structural and content evidence into a single report you can cross-check yourself. Not every finding carries this level of certainty — a literal <h1> count is easy to verify directly, while other checks rely on heuristics with lower confidence, as explained in what TrustGrowth measures and what it can't. For an overview of the audit mechanics themselves, see how TrustGrowth audits work.

FAQ

What counts as a verified SEO defect?

A verified defect has direct technical evidence — such as a literal element count in rendered HTML — plus a repeatable method anyone can use to check it, like counting <h1> tags in view-source.

Can Google Search Console confirm every fix?

No. GSC reports lag actual page changes and don't cover every technical check; the duplicate-H1 fix in this post was confirmed through direct source inspection and a fresh audit, not through GSC.

Is one case study enough to judge an SEO agent?

No. This is one inspectable run covering one defect class on one site, and it should be read as exactly that, not as a general claim about agentic SEO capability.

What artifacts should a credible SEO automation case study include?

At minimum: audit evidence showing the defect, a public code diff or pull request, a named deployment reference, and a fresh re-audit confirming closure — with any non-public artifacts labeled as operator-record evidence rather than implied to be linked.

What this means for your site

Open your own blog templates right now and view-source on two or three pages. Search for <h1 and count the matches; anything above one is the same defect class documented here. If you find it, the fix pattern is the same one used in PR #535: remove the duplicate element at the template level, not per page, so it can't reappear on the next post published from that template.