Rich results implementation that survives your next deploy

Markup that validates and still returns nothing is the normal case, not the exception. Of the last fourteen implementations I inherited, eleven passed the Rich Results Test on the day they shipped and produced no rich result in Search. The cause each time was disagreement between the JSON-LD and the rendered page at crawl time: a price serialised before a currency switcher rewrote it, an aggregateRating counting reviews that loaded behind a tab, an @id regenerated on every build so nothing accumulated across recrawls. This engagement finds that disagreement inside your templates and removes it. What this answers: Whether the rich result you want is available to you at all, and what holding it costs. Several are gated on things no amount of markup fixes. Product pricing eligibility depends on your Merchant Center feed agreeing with the page. Article and author treatment depends on an entity Google has some reason to trust. FAQPage has been restricted to government and health sources since August 2023, so if that is what was promised internally, the honest answer is that it is gone. I put those constraints in writing in week one, in a note you can forward to whoever approved the budget, before any code is written. Who does the work: Me, and only me. Nine years on structured data, four of them owning template sign-off inside a Dutch retail group running eleven country templates, where an @id migration I approved cost about a quarter of Product rich results for six weeks before we traced it. I have argued the wrong side of a schema decision in public and been corrected on the schema.org tracker. You are hiring somebody who has already been wrong at scale and knows the shape of it. What gets built: JSON-LD emitted by your own templates, in your own stack, not injected by a tag manager. Node-level identity first: a stable @id scheme that survives URL changes and locale variants, an Organization node the rest of the graph references rather than repeats, and correct linking between Product, Offer, Review and BreadcrumbList so the crawler reads one entity instead of four unrelated blobs. Then the properties that actually feed the feature, checked against what your page renders after hydration, not against a mock. Every type ships with a fixture and a validation test in your CI, so a front-end change that breaks the markup fails the build instead of failing quietly in Search Console eight weeks later. What is not included: Content writing. Review collection. Merchant Center feed remediation, which is its own discipline and usually its own vendor. Guarantees of a rich result appearing, because eligibility is Google's decision and anybody selling you certainty on it is selling something else. Ongoing monitoring beyond the window in your package. Migration of a headless CMS to make the data available, though I will tell you plainly if that is the real blocker and scope it separately. Who should not buy this: Anyone who wants markup added on top of a page whose data is wrong. If your prices are stale, your availability is guessed, or your ratings come from a source you cannot defend, structured data makes the problem machine-readable and enforceable. Google issues manual actions for exactly this. Also not for teams who cannot give a developer four hours a week during the build, and not for anyone who needs the work routed through an agency that will re-implement it afterwards. How it runs: Week one is templates and constraints, ending with the written note above. Weeks two and three are implementation on a branch against your staging environment, reviewed by your own engineers rather than merged around them. The last stage is deploy, live crawl verification with URL Inspection on a sample of real URLs per template, and the CI gate turned on. I work in your repository, in English or Dutch, on your review process. What you keep at the end: The templates, the fixtures, the CI test, a short document naming every property, why it is there, and which feature it feeds, and a list of the decisions I would revisit if Google changes the documentation. That last list is the part clients tell me they use most, because it is what makes the next person able to maintain this without me.