Adding another block of structured data is easy. Working out whether it agrees with the blocks already on the page takes more thought.
In July 2026 I reworked my SEO tooling around a shared graph. The page, website, author and publisher could be described once, then connected with stable identifiers. Other components could contribute the specialist information they knew about without printing another unrelated version of the whole story.
Think of it as a set of connected records
A page belongs to a website. An article has an author and a publisher. A breadcrumb trail describes where the page sits. Using an @id gives those records a way to refer to one another without repeating all their details.
That was a maintenance choice as much as an SEO one. If the publisher’s details change, I want one source for them. If two providers describe the same thing, I want a deliberate rule for combining their information.
Specialist plugins still have a job
A general SEO layer does not automatically know more about an event, a product or a job listing than the component that manages it. In the integration work I kept specialist output where it already handled the detail correctly, removed overlapping breadcrumb output and added missing relationships.
I also left potentially overlapping product output opt-in while ownership was being checked. A new integration is not a reason to switch on every possible schema type.
Validate meaning as well as syntax
I added checks that fetched representative pages, parsed their JSON-LD and reported the types present. That catches broken JSON and makes duplicate or missing output easier to notice. It cannot decide by itself whether the description is truthful.
For that, I read the visible page alongside the markup. The author should be the actual author. A product should have the real product details. A page should not acquire a more glamorous type simply because that type appears to offer a search feature.
Google’s structured data policies require the markup to represent the content and make clear that valid markup does not guarantee a rich result. I treat validation as a quality check, not a ranking forecast.
My starting point for an existing site
Inventory what is already emitted, decide who owns each type, agree the identifiers and test a small set of representative pages. Then repeat those checks when a theme or plugin changes. A coherent description is much easier to maintain than a collection of individually impressive snippets.