Schema Markup Built Into Templates, Not Tag Manager

Structured data earns its place when it changes what a search engine can state about your business without opening the page, and most of what I find installed does not do that. Two failures cover nearly all of it. The first is markup injected by a tag manager, which arrives after render and vanishes from any raw fetch. The second is markup describing things the page does not show — ratings with no reviews beneath them, question blocks that exist only inside the JSON-LD. Both are still being sold. The second is a manual action waiting for someone to file a spam report. How this gets built: JSON-LD, rendered server-side, from the same data object the template already uses for the visible page. When the price changes in the database the markup changes with it, because there is one source and not two. No tag manager, no client-side injection, no hand-maintained JSON blocks that drift away from the copy above them within two releases. The entity graph: Per-page markup is the easy half. The half that gets skipped is making nodes refer to each other. One Organization node defined once at a stable @id URI and referenced by every Article, Service, Product and BreadcrumbList on the site, rather than restated with slightly different values on each template. Authors as Person nodes with their own @id and sameAs links, not strings. For fintech clients this reaches FinancialProduct and LoanOrCredit nodes where every rate and fee attribute has to agree with both the visible page and whatever compliance approved; I will not publish an annualPercentageRate that disagrees with either. For energy and utility properties, Service nodes bound to areaServed for the territory you actually serve, which is the markup that answers the question those sites are asked most. Validation that keeps working: The build fails if the markup does. A check goes into your CI that renders each template against fixture data, extracts the JSON-LD, and asserts required properties and @id integrity before merge. After launch the Search Console enhancement reports are the ground truth for whether Google accepted anything, and I read them at 14 and 45 days. A validator tells you the syntax parsed. It does not tell you the markup was used. What I will not mark up: Reviews and ratings not visible on the page, or aggregated from anywhere other than reviews you collected yourself. Question-and-answer markup sold as a ranking tactic — those results were cut back to government and health sites in 2023, and the rest of the web has been shipping dead weight ever since. HowTo, withdrawn entirely. Speakable outside the news publishers it was scoped to. If your page type has no rich result available I will say so, and we scope the markup to entity clarity for the systems that read your site and nothing more. Not included: Content rewriting, review collection programmes, Merchant Center feed management. If existing markup has already drawn a structured data manual action, removing the cause is in scope and filing the reconsideration request is yours. Who this is not for: Teams whose CMS forbids template edits and whose only insertion point is a tag manager. I cannot do this properly inside that constraint and would rather you spend the budget on the CMS. Also not for anyone whose stated goal is star ratings on a page type that cannot display them. The answer is no, and it is still no in the second meeting. Bilingual sites get inLanguage set per URL and separate nodes per locale, not one shared node with translated strings hung off it.