Structured-data evidence and maintenance
Retire stale values when the real offer changes.
A generator can keep working while the facts it emits become false. Maintain the source and effective period for each changing property, and update visible content and structured data as one record.
Attach evidence to the individual property.
Record the node ID, property path, entry, unit, currency or market, controlling source, observation date and evidence owner. One page can mix a stable legal name with a changing price and availability status. A template’s technical health cannot establish that any one entry remains true.
Map the property to the visible passage or component that expresses the same fact. If the page no longer supports it, investigate the change before retaining the machine-readable assertion. A missing review, unknown stock level or unavailable price source should stay unknown; do not substitute a fabricated rating, zero price or active offer.
Keep product, content and source versions distinct.
A product version, the version of the source record, the template release and the date the page was checked are different fields. State which product or service the entry belongs to and which record supports it. A software release can change compatibility without changing an organization’s legal name.
When sources disagree, compare subject, market, effective date and authority. A newer document about another product is not the controlling record for this offer. Keep the unresolved conflict attached to the affected property and involve its factual owner. The technical maintainer should not invent a commercial decision to complete a release.
Use an expiry rule and an event trigger.
An offer may have a defined end date; another entry may need review on a product release, price change, policy change or evidence withdrawal. Use a calendar reminder as a backstop, and let an earlier source event override it. There is no universal annual or monthly interval that makes every property current.
Classify changing values by consequence and likely change, then choose a proportionate check. Record what happens when the review is missed: recheck, remove an unsupported property, hold an affected node, or preserve a clearly dated historical statement. If removing a required property leaves an invalid feature candidate, hold that candidate rather than output a misleading half-record.
Worked example: retire a discontinued offer in both places.
The following offer and dates are fictional teaching records. A page for Northbank Archive includes an active “Starter monthly offer” atEUR 19. Its structured data has an Offer node with price 19, currencyEUR and active availability. The authorized product record states that new purchases of that offer end on 30 September 2026; the product information page will remain as an explanation for existing users.
Before the end date, the page can state the supported offer conditions and effective period. At retirement, replace the active sales sentence with: “The Starter monthly offer ended on 30 September 2026 and is no longer available to new purchasers.” Remove the active purchase route. Keep any existing-user support route separate and verify that it does not sell the retired offer.
Remove the discontinued active Offer node and its dangling references from current sales markup. Preserve the supported product description when it remains accurate. Do not replace the price with zero, invent a successor, or label an unverified successor as equivalent. If the real product is merely temporarily out of stock, that would require a different factual decision.
| Property/component | Before retirement | After authorized retirement |
|---|---|---|
| Visible offer text | Starter monthly offer, EUR 19, available to new buyers | Dated end notice; no active purchase promise |
| Offer price/currency | 19/EUR tied to active offer | Retired active Offer omitted, not converted to a free offer |
| Product offers reference | Points to active Offer node | Removed when that offer is removed; no dangling reference |
| Purchase destination | Permits new purchase | Retired sales action removed; verified support route can remain |
| Evidence record | Offer terms plus authorized end date | Retirement record, approval, observation date and affected pages |
Propagate the change through shared output and caches.
Find every copy: product page, pricing comparison, reusable card, landing page, feed, brief template and schema generator. Update the source system and its consumers rather than only the paragraph where the mistake was noticed. Review the effective date and market in each location.
Inspect the normal response and rendered output after cache invalidation where needed. Confirm that neither a theme nor a plugin reintroduces the old Offer. Check graph references, visible wording, purchase controls and metadata together. A saved editor draft is not evidence that every public representation changed.
Define a safe response when current evidence is missing.
If the source becomes unavailable, first determine if it moved, expired or was withdrawn. An archive can document an earlier offer but does not prove it is still for sale. Hold the current claim when its truth cannot be established. Ask the commercial owner to resolve the status rather than keep a confident stale price.
Use the smallest truthful fallback. A stable product explanation can remain while an unsupported offer is omitted. A historical price can appear in a clearly dated discussion when useful and properly scoped; do not present it as a live transaction. Reintroduce current fields only after fresh evidence and relevant checks are complete.
Assign the review cadence to the source owner.
Agree who monitors product, pricing, legal or event records and who changes the website. A short review interval can help with volatile data, but reliable source events may be more useful than repeatedly inspecting stable identity. Record the next date, trigger and fallback for each property class.
Automated alerts can detect a changed entry or missed date; they cannot by themselves resolve ambiguous identity or commercial authority. Keep the human decision, source version and accepted state in the record. A page’s general modified date should not imply that every price, review and availability field was reverified.
Close the maintenance record with evidence.
Keep the prior entry, new decision, effective period, controlling source, factual owner, technical owner, affected page set and final check. Distinguish confirmed, updated, removed, historical and held. Reopen on a later release or policy event rather than treating the first pass as permanent.
Google’s general structured-data policies require up-to-date, representative content; automated parsing alone cannot establish that a retired offer is still valid. Search-feature display remains a separate decision. The maintenance record protects truthful output without promising indexing, rich results or commercial performance.
Sources and related learning
Google structured data policies. Schema.org data model.
The worked scenarios are fictional teaching records. They do not report live tests, client work or measured search outcomes.
Continue with semantic SEO learning and schema and entity identity. Maintain dated claims and corrections. Repeat validation after a change.