SEO Deck

Checking a page against its brief, checking its links, checking its search performance and checking whether an answer engine can read it are four separate jobs in four separate places. Search Console in particular makes you pick a property and apply a page filter for every URL, which is a small tax paid dozens of times a day.

The second problem is newer. Teams have years of habit around ranking in a search engine and almost none around being readable by an answer engine. Structured-data gaps, crawler-visible content and robots rules for AI bots are all mechanically checkable, and almost nobody checks them, because the tools that would do it were built for a different era of search.

It started as a folder of loose scripts people pasted into the browser console. Those became an audit extension, shared round the team with install instructions in a Slack thread. Separately, a second extension pulled Search Console data for the current page, because the property picker was the single most repeated piece of friction anyone had.

Two extensions solving halves of one problem is worse than either, so they were merged. Deliberately assembled as a new build rather than grafted onto whichever was larger, because grafting would have inherited the weaker half’s structure permanently.

The old extensions were left exactly where they were, unmoved and unrenamed. Chrome loads an unpacked extension from an exact path, so relocating them would have broken the tools the team used daily, in the middle of building their replacement, for no benefit.

The belief was widely held and sounded right: our pages lazy-load their content, so an AI crawler that does not execute JavaScript sees very little of them. It was approved as the centrepiece of the AI-readiness work.

Measuring it took an afternoon. The raw server HTML held 129% of the word count of the fully rendered page, because the rendered version collapses content into accordions that the raw markup simply contains. The crawlers were seeing more, not less. The premise was not merely overstated, it was backwards.

So the feature was cut and replaced with structured-data gap detection, which targets a defect that measurably is present. The raw-versus-rendered comparison survives as a cheap health check rather than a headline, which is the right size for a thing that confirms a good state.

The measurement stands at a sample of one page, and it is recorded that way. It is enough to disprove a claim made with confidence and not enough to call the good state systemic.

• A double-click was needed on several tools and had been documented to the team as a quirk. The cause was not the tools: a browser popup is destroyed the instant its tab navigates, so nothing survived to act after the reload it had just triggered. Moving the work to the background worker fixed it. Proved by disabling only that listener and watching the bug return exactly.
• The muted text colour used for every description and hint failed accessibility contrast at 3.5:1 against a 4.5:1 requirement. Measured with computed styles and the real luminance formula, not judged by eye. Recalculated to 5.1:1.
• A list of six badges placed in a table cell squeezed its own label to zero width. A screenshot made it look fine; measuring the element’s bounding box did not.
• Segment counts on the link audit disagreed with the rows each filter revealed, because the label and the filter were computed separately. Now derived from the same function, and asserted by clicking each segment and comparing.
• Two links to saved assistants were fabricated. I had typed plausible URLs instead of reading them from the source. They are now extracted by pattern from the original files and never retyped.

Every tool button carried a permanent description line. The feedback was that they ate the popup, which was true: measured, removing them recovered 102 pixels of 446 visible on one tab alone, the difference between everything fitting and needing to scroll.

The obvious fix, hiding them and showing a tooltip on hover, would have removed the descriptions from screen readers too. Instead they were moved into a described-by target and visually clipped rather than hidden, so assistive technology still receives the full text regardless of hover state. Strictly better, not a trade.

The tooltip itself introduced a bug during the build. The first-use hint dismissed on hover, and dismissing it collapsed the banner and shifted every button up a row, so the cursor landed on a different button while the user was still reading the first one. Caught in a real browser, because a synthetic click never reproduces a cursor that stays where it is. Moving the dismiss to click and focus fixed it: a click has already resolved against its pre-shift target, and keyboard focus is not coordinate-based.

It is in daily use by the team it was built for. Three bugs are open and written down rather than quietly carried: two SERP tools depend on a search engine’s result markup and will break when it changes, and the image-weight tool can only time images the browser actually fetched, so on a warm cache it reports fewer than are present. It states the count it measured, which makes the figure partial but honest.

One change stands between this and something anyone could install: each user authorising their own Search Console rather than sharing a connection. That is specified. It also makes onboarding harder, and I have not measured whether correctness costs more adoption than it earns.

• Measure the premise before scoping the feature. The lazy-loading belief survived a long time because it sounded right, and an afternoon of measurement would have saved it being approved as a headline.
• Decide the distribution model before the build rather than after. Sharing one connection made the first version trivial to install and is now the only thing blocking the tool from going anywhere.
• Treat a screenshot as a hypothesis. Three of the bugs above looked fine in a picture and were obvious the moment anything was actually measured.