Write Down Every Search Error Once

01The same warning, two months apart

On 30 October Search Console flagged a structured data error on a new page of a CV product: an invalid object type for a field called isPartOf. I fixed it in minutes, then had the uncomfortable feeling of having done exactly this before. I had. The same error, on the same site, on a different page type, in August. The fix had been correct both times. It had just never been written anywhere a future page could see it. An error you fixed and did not write down is an error you have scheduled.

A sweep of everything

So on 31 October I went through every note I keep on every project and pulled out each search engine warning we had met, where, what caused it and how it was fixed. Five stood out, and three of them had happened twice. The redirect warning caused by addresses inside structured data missing their trailing slash was fixed in the summer on the agency site, then quietly reintroduced in ten places by articles written in September. Meta descriptions too long for Bing were a known rule, and 21 new pages on another site still shipped on 29 October at 164 to 205 characters.

02Fixes live in people, errors live in templates

The template remembers, you do not

Every one of the repeats came from a template or a generator. A component that prints structured data, a script that builds article metadata, a page builder that writes descriptions. When you fix one page, the template that made it is still wrong, and the next page it produces carries the old mistake back in. Fixing a page is a repair; fixing the template is a cure; writing it down is what stops the next template. The schema gap in the schema you did not know was missing was the same story from the other side: the template knew nothing about the page that needed it.

Search engines do not forgive repeats

A single warning costs little. A pattern of the same warnings across a site tells a search engine that the markup is careless, and careless markup is easier to ignore. Rich results get switched off for whole sites, not single pages, when the structured data cannot be trusted. And the assistants that read structured data to understand who you are and what you offer read the broken version too. Structured data is a statement of fact about your page, and a repeated error is a repeated false statement.

03One table, and a build that refuses

The table

The output of the sweep is one shared table with four columns: the warning as the tool states it, where we met it, the cause, and the rule that prevents it. It is short, a few dozen rows, and it is the first thing I read before any page or schema change on any project. Not a wiki of best practices copied from documentation. Only errors we actually caused, in our own words. A list of your own mistakes is worth more than any checklist written for someone else's site. It also separates real errors from statuses that look like errors, the distinction I drew in GSC says page with redirect.

The build that refuses

A table still depends on someone reading it, so each rule that can be checked by a script now is. The page builders measure description length and fail outside 50 to 160 characters. Structured data is parsed after every build and the build fails on the known causes: a Dataset without a license, a Dataset pointing at a web page as its parent, product markup on software, addresses inside the markup that do not match the canonical form. The check runs against the server, not only the public copy, after what I learned in the pages that only existed at the edge.

None of this is sophisticated. It is the discipline of treating a fixed error as the start of a rule, not the end of a task.

Tomorrow: fifty three city pages that rank and that almost nobody searches for.