You lead frontend for a large catalogue site where each template's JSON-LD was hand-written by whoever built it. How do you decide what to mark up, and how do you keep the structured data trustworthy as the site changes?

## The decision is scope before syntax The failure mode at scale is not bad JSON. It is a hundred templates each carrying a slightly different, slowly rotting description of the same company, authored by people who are gone. The lead's job is to decide how much of this the organisation should own at all. The honest framing: structured data makes a page **eligible** for a specific search feature. If no feature consumes a type, marking it up produces no visible outcome and still costs review time on every template change. So the scope test is per type: *which search feature does this unlock, and do we want it?* On a catalogue site that usually lands on `Product` with `Offer`, `BreadcrumbList`, `Organization` for the entity behind the site, and `Article`/`BlogPosting` for editorial. Everything else is speculative. Be candid about volatility too. Search features are narrowed and retired — FAQ rich results, for instance, were restricted to a narrow class of authoritative sites, and every page that had been marked up for them lost the result overnight. A portfolio built on features that may vanish should be small and cheap to maintain. ## One source of truth, mechanically enforced Hand-written JSON-LD is a second copy of the facts, and a second copy always drifts. The structural fix is a serializer per entity type that takes the domain object the page already renders: ```javascript // one function, used by every template that shows a product function productJsonLd(product) { return { "@context": "https://schema.org", "@type": "Product", "@id": productId(product.sku), name: product.title, image: product.images.map(absoluteUrl), brand: { "@id": ORG_ID }, offers: { "@type": "Offer", price: product.displayPrice.amount, // the price the page shows priceCurrency: product.displayPrice.currency, availability: product.inStock ? "https://schema.org/InStock" : "https://schema.org/OutOfStock" } }; } ``` Two things matter here beyond tidiness. First, `product.displayPrice` is deliberately the same field the UI renders — the drift bug that gets sites penalised is a JSON-LD list price beside a promotional price on screen. Second, `productId()` and `ORG_ID` come from shared helpers, so every template mints the same identity and node references resolve instead of quietly splitting one company into several entities. ## Make it testable, then monitor it Structured data fails silently: the page renders perfectly with a broken block. That rules out "we'll notice". Two layers of safety net: **In CI.** A test per template that renders it, extracts the `application/ld+json` blocks, asserts the JSON parses, and asserts the required properties for the feature are present and non-empty. This is cheap and catches the two most common regressions — a refactor that empties a field, and an escaping bug in user-supplied text. **In production.** Search Console reports at the fleet level: enhancement reports per detected type with valid/warning/error counts, the unparsable-structured-data report, and the manual-actions section. A deploy that breaks a template shows up as a step change in error count across thousands of URLs, which no spot-check would find. Give someone the job of looking. ## The organisational half **Ownership.** Structured data spans SEO, frontend and the catalogue team, which is how it ends up owned by nobody. Name an owner for the schema — the entity types, their identifiers, their serializers — and require changes to go through it rather than being edited inline in a template. **Migration.** Legacy microdata scattered through old templates should be finished, not left beside new JSON-LD. Two sources of truth for one entity is a mismatch waiting to be found by a crawler, not a belt-and-braces safety measure. **Expectation setting.** The business will ask what the traffic gain is. The truthful answer is that eligibility is a precondition, not a lever: correct markup lets a richer result be shown, and whether it is shown depends on decisions you do not control. Promise the precondition and the absence of policy risk; do not promise the click-through. ## What separates a principal answer A senior answer fixes the templates. A principal answer decides which markup deserves to exist, makes correctness a property of the build rather than of anyone's diligence, assigns ownership, and states plainly what the investment can and cannot buy — including the possibility that the right call for a rarely-consumed type is to delete it.