Structured data that actually earns rich results

Every other category of front-end defect announces itself. A broken component throws, a failing request logs, a type error stops the build. Structured data does none of this. A malformed block is skipped by the browser, ignored by search engines, and reported by nothing.

The result is that schema tends to be written once, checked manually against one or two pages, and then never looked at again while the site grows to hundreds. Every new page type carries markup nobody verified, and the ones with defects look identical to the ones without.

Spot-checking with a single-URL testing tool does not close this. It tells you about the page you pasted in. The failure mode is systematic — a template with a missing property emits the same defect across every page using it, and you will only catch it if you happen to test that page type.

Across the sites we have audited, the same handful of faults account for nearly all of it.

When we first ran our validator it flagged an organisation node for missing a name and a URL. The markup was correct and the validator was wrong, which is worth explaining because it is the most common way people damage working schema while trying to fix it.

A node carrying an identifier is either a reference to, or an extension of, an entity defined canonically elsewhere in your graph. Search engines merge nodes sharing an identifier. So a page that lists staff can legitimately emit an organisation node containing only the identifier and an employee list — the name and URL live in the canonical definition in your layout, and repeating them adds nothing.

If your validation flags these, fix the validation. Adding the properties back to every reference is not harmful exactly, but it means you have not understood the graph you are building, and the next thing you do to it will be guesswork.

The temptation when adding a required date is to invent one. A case study records the year of the engagement and nothing more, so somebody writes the first of January and moves on.

That is a small dishonesty with a real cost. Publication dates surface in results and inform freshness assessments, and a portfolio where every entry claims the first of January is visibly fabricated to anyone who looks. Date formats support year-only precision, which states exactly what you know and no more.

The same reasoning applies throughout. Structured data is a set of claims about your content, made in a format designed to be trusted. Padding it with plausible-looking values to satisfy a validator inverts the point of the exercise.

The practical answer is a script that crawls every URL in your sitemap, extracts every block, parses it, and asserts the required properties for each type it finds. Ours is about a hundred and fifty lines and runs in a couple of minutes across several hundred pages.

Two design notes from building it. Recurse into nested objects — most real markup is a graph rather than a flat list, and the defects hide in nested nodes. And check the specific conditions that matter for eligibility, not just presence: an FAQ node with an empty answer passes any check that only asks whether the property exists.

Then run it alongside your other regular checks so it fails loudly. The value is not the initial cleanup, satisfying as that is. It is that every page type added afterwards gets verified automatically, by something that does not get bored or assume the template was fine.