42 schema types on one site: which ones actually did anything

The accounting

Forty-two schema.org types, roughly 2,100 URLs, most pages carrying three or four types at once. Here is what each group actually did.

Produced a visible result

BreadcrumbList. Replaces the URL in the search result with a readable path. Visible, immediate, cheap, and it works on every page below the root. If you ship one type, ship this one.

Product with Offer. Price and availability in the result. Only relevant if you sell something, and mandatory if you do.

FAQPage. Narrower than it was. Rich results appear for a subset of sites now, and the remaining value is answer extraction rather than presentation. Still worth it, with the visibility rule below.

Article with dateModified. The freshness signal a crawler can read without diffing the page. The effect is on recrawl cadence rather than on how the result renders.

That is four.

Produced nothing measurable

SoftwareApplication. Correct on a tool page. No observed effect on presentation.

Service. Correct. Invisible.

DefinedTerm and DefinedTermSet. No rich result. Kept anyway, because it is the correct description of a glossary and because answer engines quote definitions.

SpeakableSpecification. Nothing measurable. Kept for a reason that has nothing to do with markup: you cannot point a CSS selector at a short self-contained answer unless the page has one. Adding it forces that discipline on every page you add it to, and that discipline is worth more than the tag.

Person, ProfilePage, ImageObject, ItemList, CollectionPage, WebPage, and about thirty others. No visible change. Kept, because they are how a crawler resolves one entity across 2,100 pages rather than seeing 2,100 unrelated documents.

The thing that mattered more than any individual type

One <script type="application/ld+json"> per page, holding one @graph, with stable @id anchors that cross-reference rather than duplicate.

With separate script tags, every page ships its own Organization node and a crawler has no way to know the 2,100 copies are the same organisation. With a graph and stable identifiers, one entity is asserted 2,100 times from 2,100 pages, all pointing at the same @id.

That architectural choice did more than any single type on the list, and it does not show up in any rich results test.

Two rules learned the hard way

Omit optional fields, never emit them empty. "author": "" asserts that the author is nothing. Omission asserts nothing at all, which is both honest and valid. Ten lines of a recursive compactor applied to every factory output prevents the entire class of defect.

Every FAQ in schema must be visible on the page. Marking up questions that are not rendered is a documented manual action trigger, and the sites that get caught are almost never cheating: they built an accordion that mounts its content on click, so the crawler sees an empty container. A native <details> element puts the content in the HTML whether the disclosure is open or closed, and needs no JavaScript at all.

What I would do differently

Start with the graph architecture, not with the type list. Adding types to a well-anchored graph is trivial. Retrofitting @id anchors onto 42 types already deployed across 2,100 pages is a week.

Every type, with a complete example and its three most common mistakes, is documented at /schema. The schema graph chapter covers the composer and the integrity test that catches a dangling reference before it ships.