TL;DR
Before approving structured data, ask where each fact appears on the page, who verified it, and what will trigger its next review. A technically valid description can still identify the wrong location, provider or business. A small, accurate implementation is easier to maintain than an elaborate graph nobody owns.
Start with a fact ledger
Start by asking the implementer which business or page the markup describes. Google recommends an organization type that matches the actual business and properties relevant to it; include a property because it truthfully applies, not merely because a generator offers it. Google’s Organization documentation explains that approach.
For the first review, ask your implementer for a readable export of the proposed properties. Pair it with this ledger:
| Property being described | Evidence to check | Person who can approve it |
|---|---|---|
| Practice name and public URL | Homepage and approved brand information | Practice owner |
| Location address and phone | Visible location page and current office record | Office manager |
| Service provider | Service page and actual delivery arrangement | Operations lead |
| Article author or reviewer | Visible, approved attribution | Editorial owner |
| Publication or revision date | Actual publication or substantive revision record | Content manager |
Leave an unsupported field out while it is being resolved. Do not turn an assumed author, stock image, old office address or generated rating into a published fact.
Separate the organization from each office
If the practice has multiple locations, compare each office’s actual phone, address and appointment calendar with the proposed markup. Do not copy a central phone or a different office’s details into a location description unless those facts accurately apply there.
Ask three questions: Which real entity does this node describe? Which page explains that entity to a visitor? Where is its identity reused elsewhere? Your developer should be able to explain those relationships without relying on the names of software plugins.
This also catches a basic category error: a marketing company that serves healthcare practices should not describe itself as a clinic. A page about a service does not establish that every office provides it.
Review meaning before syntax
Use two review passes. First, compare the proposed facts with visible text and operational evidence. Resolve contradictions before running technical tests. Second, have the implementer validate the markup and inspect what the published page actually renders. A template preview is useful, but a production domain, canonical URL or plugin can change the final output.
Look for duplicate descriptions from multiple plugins. Article nodes with conflicting titles or dates deserve investigation even when the markup produces no syntax error. Record which component owns the final markup so future changes have one responsible maintainer.
Google says its AI search features do not require special schema. Treat markup as accurate description, not a purchased route into AI answers. Google’s AI features guidance makes that distinction clear.
Make updates part of the same job
When an office moves, a provider leaves or a service changes, put visible content and structured data in the same change ticket. Attach the before-and-after facts, approving person, affected URLs and a rendered-page check. Close the ticket only after both descriptions agree. This is an editorial maintenance practice, not a ranking formula.
Frequently asked questions
Should a validator warning make us invent a missing author or image?
No. Determine whether the property applies, obtain truthful information if needed, and understand the consequence of omitting it. A warning is not permission to manufacture attribution.
Can schema fix inconsistent office information elsewhere?
It cannot correct a directory, calendar or visible page by itself. Update each affected source and verify the actual visitor journey.