Structured data foundations

Structured data has a reputation problem, caused by how it gets sold.

A team implements it to get stars in a search result. The stars appear or they don't. The whole exercise gets judged on that.

That framing produces exactly the thing markup is worst at: a separate self-contained blob on every page, redeclaring the same company over and over, with nothing connected to anything.

Fragments versus a graph

Here's the pattern on most sites. Every page carries its own JSON-LD. Each one redeclares the company. Each declares an article with an author as a plain text string. Nothing references anything else.

A machine reading that sees an isolated record per page. Then it has to work out, by matching names, whether the company on page one is the company on page two.

The alternative declares each thing once with a stable identifier and points at it:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://evolvelaw.ai/#maestro", "name": "…" },
    { "@type": "Article",
      "@id": "https://example.com/learn/geo/#article",
      "author":     { "@id": "https://evolvelaw.ai/#maestro" },
      "publisher":  { "@id": "https://evolvelaw.ai/#maestro" },
      "reviewedBy": { "@id": "https://evolvelaw.ai/#maestro" } }
  ]
}

Now the relationships are stated rather than inferred, and the company on this page is explicitly the same company as on every other property using that identifier.

Use the canonical identifier

The most common mistake in otherwise good markup is scoping identifiers to the current site. https://thissite.com/#org on one property, https://thatsite.com/#org on another, for the same company.

Each is locally valid. Together they describe two companies.

Pick the canonical one and use it everywhere, including on sites that aren't that entity's own home.

What to mark up, most valuable first

1. Organization and WebSite — once, canonical identifier, plus the profiles you claim.
2. Article on every substantive page, with published date, modified date, author and publisher as references.
3. BreadcrumbList, which also states your hierarchy outright.
4. Type-specific markup — LocalBusiness, Product, Event — where it genuinely applies.

The FAQ rich result is gone

Worth saying loudly, because recommending FAQ markup to win expanded results is still everywhere in SEO advice. Including in an earlier version of this page.

Note the precision, because commentary gets it wrong in both directions. The Search feature was deprecated. The FAQPage type wasn't. It's still valid vocabulary and still a reasonable way to state that a passage is a question and its answer.

What changed is the reason to do it. Question markup covers it fully, including what we changed on this site when we found ourselves over-marking our own pages.

Don't read any of that as evidence FAQ markup wins AI citations. Google's guidance says there's no special schema you need to add, and names over-focusing on structured data among the things that give you no advantage.

The same documentation sweep dropped practice problem markup as a Search feature and clarified that Dataset markup serves Dataset Search rather than ordinary Google Search. The general lesson is the one at the top: schema.org vocabulary and what Google supports as a feature are two different lists, and only the second one moves.

The rule that keeps you out of trouble

Markup has to agree with the visible page.

Marking up a review score the page doesn't show, an author the page doesn't name, or a date that isn't the real modification date is misrepresentation. That's the category of error that earns a manual action.

If the page doesn't say it, the markup shouldn't either.

How we do it

One file holds every entity. The generator emits a single graph per page where the firm and the website are referenced by their canonical identifiers, and the article, breadcrumbs and any question blocks point at them.

Nothing gets declared twice with different identifiers, because there's only one place to declare it.