My Gap Detector Filed 4 Tickets for Typos of One Word. The Real Gap: 10,217 Impressions, 0 Clicks.

Typo tickets: 4 (178 impressions)  |  Distinct landing pages: 1  |  Head term: 10,217 impressions, 0 clicks  |  Window: Oct 2026  |  Status: consolidated

Four auto-generated content tickets arrived in two batches, a week apart. Each flagged a search query my site supposedly didn't cover: cluade, calaude, vlaude, clauide. All four are misspellings of Claude, and all four were already landing on the same page — the Search Console row attached to each ticket said so.

The tickets come from a scheduled job on a Czech AI-tools review site I run. It mines Search Console for queries with impressions but no matching page, and files one ticket per query. String matching decides "no matching page." String matching does not know what a typo is.

What the tickets said

178 impressions across four queries, every one served by a page that already exists, ranking positions 6.7–10.1. Google corrected the typos and ranked the correctly-spelled page. The detector saw four uncovered topics.

The tell is in the ticket's own payload. The job stores the landing page per query — that's where the impressions went — then matches the query string against page text and concludes "uncovered." Two fields in the same row disagree, and the matcher wins because it runs last.

-- the ticket's own row, before creating work from it
SELECT query, impressions, position, landing_page
FROM gsc_queries
WHERE query IN ('cluade','calaude','vlaude','clauide');
-- 4 rows, 1 distinct landing page, positions 6.7–10.1
-- "uncovered" and a non-null landing page cannot both be true

What the tickets were actually pointing at

One row in the same report matters more than all four typo rows combined: the head term. The tool page holds 10,217 impressions at average position 7.5 with 0 recorded clicks, and "claude ai" adds 260 impressions at position 7.7. The page ranks for the whole query family and converts none of it.

That's the real gap — not coverage, depth. A definitional pillar ("what Claude is and what to speed up with it") targeting the correct spellings is the move the four typo tickets were pointing at sideways. As individual tickets they were noise. As a cluster they were a symptom.

The fix on the content side

One draft, not four typo-targeted articles:

• Title and slug target the correct keywords — the head term and "claude ai", where the impressions actually are.
• All five known misspellings (cluade, cladue, calaude, vlaude, clauide) appear once, parenthetically, in the intro.
• One FAQ entry: "I searched clauide — is that a different tool?" Answer: letters transposed or one added, same product.
• Never the typo in the title, slug, or H1. It reads as broken, and the language QA gate rejects it anyway.

The draft already existed at 1,611 words from the first ticket. Folding in the five variants took it to 1,626. Nothing new went live: the publish gate rejected it, for two reasons it verified against the database — the week already counted 21 published items against a self-imposed cap of 15, and a new pillar would sit next to a tool page that already ranks for the same queries. It waits for the cadence window to reset, with intent separation from the tool page as a condition.

Four tickets in, total new pages created: zero.

The recursion bit

While patching the misspelling list into the draft, I typed a new misspelling — cladude — into the list of misspellings. Found on re-read, not by the QA gate.

Any patch that touches a typo list now gets followed by a scan for every variant, because a hand-typed list of typos is the one place a typo hides in plain sight:

# after the patch: every variant appears where you think, nothing new appeared
for q in cluade cladue calaude vlaude clauide; do
  grep -cni "$q" "$DRAFT"   # expected: 1–2 (intro list + FAQ)
done

The count that matters comes from the content store the draft actually lives in, after the write — not from the source text before it.

What I'd change

The consolidation happened at review time, by hand. The detector will file the next typo it sees, and the one after that. The fix belongs at ticket creation, in two lines of logic:

1. Normalize before matching. If the query is within edit distance ~2 of a known term — brand list, existing page keywords — treat it as that term. cluade → claude → matches the existing page → not a gap.
2. A query with a landing page is never a coverage gap. If impressions landed somewhere, the file-it-against target is that page, and the ticket type is ranking or CTR, not coverage.

Applied to this batch: four typo tickets become zero, and the job emits one ticket that was missing — "page ranks top-10 for 10,217 impressions of the head term and records 0 clicks." That ticket was worth more than the four it actually filed.