A schema launch creates an ongoing obligation
A service business launches structured data across its homepage, service pages and articles. Six months later, Google retires a search treatment, a plugin changes its output and the business updates an address. The markup still validates on some pages, Search Console stops reporting one feature, and nobody knows which event requires a release.
Google can change a Search appearance without changing the underlying Schema.org vocabulary. In June 2025, Google announced that it would phase out several structured data features from Search. It said the change wouldn't affect page rankings or uses of those data types outside Google Search. A later update to the same announcement removed related Search Console reporting and Rich Results Test support for several types.
That distinction prevents two poor reactions. One is deleting accurate markup merely because a Google display has gone. The other is leaving misleading or broken markup live because the vocabulary term still exists.
A maintenance programme gives every change the same route: confirm the source, identify the affected layer, assess the deployed impact, choose an action, test the release and close the record. It turns an alarming announcement into owned website work.
Work out which layer changed
“Schema changed” is rarely precise enough to guide a decision. Start by naming the layer.
- Schema.org vocabulary defines types, properties and relationships. Its release history records changes independently of Google Search.
- Google feature support determines which structured data Google currently uses for specific Search appearances. The supported structured data gallery is narrower than the full Schema.org vocabulary.
- Google policy and feature requirements determine whether a page is eligible for a supported treatment. The markup can be syntactically valid and still breach a content or quality rule.
- Search Console reporting shows Google's reporting state for supported features and detected issues. A report can retire even while a vocabulary term remains available.
- Business facts include names, services, people, locations, ratings and dates. They can become inaccurate without either platform publishing an update.
- Site implementation includes CMS fields, plugins, templates, rendering and shared identifiers. A release can break output while the external rules remain unchanged.
Schema.org explains that it develops the vocabulary incrementally through named releases and public change control. Its versioning guidance generally encourages publishers to use the current vocabulary and normal, non-versioned Schema.org URLs. Stable release snapshots remain available when documentation or standards work requires a precise version.
Google's rules answer a different question. Its general structured data guidelines require markup to be relevant, visible, accurate and compliant, and make clear that correct implementation doesn't guarantee a rich result. Keeping these layers separate lets the team respond to the change that actually occurred.
Build a small authoritative watchlist
A useful watchlist is short enough for someone to check. Start with Google's Search documentation update log, the supported feature gallery and the documentation for types your site actually uses. Add Schema.org's release history, relevant Search Console messages and the release notes for any CMS, plugin or deployment layer that generates markup.
Vendor summaries can alert you to a change, but trace their claims back to the platform documentation before changing production. Record the source URL and access date because Google feature pages, requirements and reports can change. For every relevant notice, also record the affected schema type, templates, representative URLs and next review date.
Keep the watchlist focused on changes that intersect with your deployed graph, current backlog or reporting. A business using Organization, Service, BreadcrumbList and Article markup has little reason to create immediate work from an unrelated product vocabulary update.
Triage the change before touching production
First, confirm the announcement or rule in its primary source. Then inventory every template and node that may be affected. Inspect representative public URLs and compare rendered JSON-LD with visible content and approved source facts. Check shared @id values and relationships before treating one node as isolated.
Next, classify the consequence. Is the content false, prohibited or newly ineligible? Has only a display or report retired? Did a plugin change its output? Is Google looking at an older indexed version? These questions determine urgency and ownership.
Use the practical structured data audit for the detailed path through source facts, rendered output, validators and Google-facing evidence. The purpose here is to decide whether a change should enter that diagnostic workflow, not to repeat every tool check.
If a property or relationship changes across the site, inspect the connected schema graph contract. A local template fix can create a second organisation or person identity when shared identifiers aren't considered.
Choose whether to retain revise remove or monitor
Off Piste uses four possible outcomes for change triage.
Retain accurate markup when it still describes the visible page and has a justified machine-readable purpose. A Google feature retirement alone doesn't prove the vocabulary is invalid or the markup is harmful.
Revise when a business fact, supported property, relationship, template rule or policy requirement has changed. Revisit the schema prioritisation framework if the change alters the value, reach or ownership of the backlog.
Remove markup that is misleading, hidden, prohibited or no longer worth its maintenance risk. Removal should be an explicit decision about accuracy, policy or operational value, not a reflex response to a missing search treatment.
Monitor accurate vocabulary when a Google display or report retires and there is no immediate reason to change the page. Record what retired, what remains valid, which evidence supports the decision and what event would reopen it.
This model is a decision aid, not a platform rule. Google demonstrated the need for that restraint in its 2025 retirement announcement. The named search displays and later reporting could disappear without a ranking change, while uses outside Google Search were unaffected.
Test the implementation at the right levels
Testing should follow the reach of the change. Check one representative URL for each affected template and meaningful variant. Compare the rendered markup with its visible source fact. Confirm that required and recommended properties for any current Google feature still match the relevant documentation.
Then test graph relationships. An updated Article template shouldn't silently change the author's @id or create a second publisher. A service template shouldn't replace a stable provider reference with a copied object. The graph guide provides the rules for protecting those shared connections.
Choose regression samples with different risk. Breadcrumb markup is a useful lower-risk template check because it should follow visible site hierarchy. Review markup needs closer policy and evidence review because a false rating or ineligible use can mislead people.
Google's introduction to structured data recommends validating during development and monitoring after deployment, including Search Console checks. Keep build validation, the live rendered page, indexed state and actual search display as separate evidence. A passing test doesn't promise that Google has recrawled the change or will show a rich result.
Assign ownership before the next change arrives
Maintenance fails when everybody receives an alert and nobody owns the decision. Give one person responsibility for watching primary sources and opening a change record. Name a policy or commercial owner who can decide whether the markup remains justified. Assign technical implementation and release verification separately, even when one person performs both roles.
Source data needs an owner too. If an address, author role or service description is wrong in the CMS, a template patch only masks the governance problem. The structured content model guide shows how field contracts connect facts, validation, outputs and responsibility.
As an adjustable default, Off Piste recommends a light monthly review of watched sources, quarterly regression samples for important templates and an event-triggered review after relevant platform, plugin, CMS or business changes. A small stable site may need less. A large site with frequent releases or policy-sensitive markup may need more. The cadence should follow change rate and risk, not create reporting for its own sake.
Keep a maintenance register that leads to action
An alert becomes useful only when it leaves an evidence trail and a clear next step. Keep the register beside the implementation backlog or website release system, where owners can connect a source change to affected templates, a decision and verification.
The register should be compact enough to maintain. These fields give the next owner enough context to understand why work was opened and what will close it.
Close the record when the chosen action is deployed and verified, or when an evidence-backed monitoring decision has a named review trigger. “No action” without a reason or follow-up date isn't a closed decision.
Make maintenance part of the website operating system
Reliable schema markup connects governed facts, stable graph relationships, shared templates and current platform evidence. Treating each announcement as an isolated SEO task breaks those connections. Treating maintenance as part of normal website operations preserves them.
Start with one practical decision. Who will review the watchlist, and where will they record an affected template? If that answer is unclear, establish ownership before expanding the implementation.
Use SEO governance and audit support when the decision spans monitoring, policy, Search Console and several templates. Route repairs in CMS fields, plugin behaviour, rendering or shared templates through website design and development. The result should be an implementation the business can still explain and trust after the next change arrives.