HubSpot Schema Maintenance

What should a HubSpot schema maintenance checklist cover?

Review affected markup when services, prices, locations or contact routes change, and check the live output after template or integration updates. Use scheduled checks to catch missed changes. Assign an owner so a detected problem becomes a resolved change.

A one-time validation result records a point in time. It does not establish that the page is still accurate after a new offer launches or a shared module changes. The validation guide covers initial checks; this guide explains the ongoing work.

Separate factual changes from technical breakage

Two common problems need different responses. The code may remain valid while describing an old price. Or the approved facts may be correct while a template stops emitting the markup.

Do not treat every detected difference as an error. A business can change intentionally. Compare the difference with an approved change before deciding whether to correct the page or update the expected record.

Keep a baseline that someone can use

For each maintained page, record its canonical URL, main entities, source of markup, fact owner and last verification date. Retain the approved business facts and enough of the published output to explain a later change.

The baseline should answer practical questions: which source owns the company phone number, which template emits the service description, and who approves the delivery area? A screenshot of a green validator result cannot answer all three.

For related entities, keep the small map from the business knowledge graph guide. For repeated public claims, keep the dependency list from the business-facts guide. These records can live in the team's existing tracker or repository.

Review on change, with a scheduled backstop

The most useful review trigger is often an actual business or website change. Add schema and related facts to the release checklist for offer updates, location changes and template deployments. That lets the team correct the description while the change is already being discussed.

Use a scheduled review as a backstop for missed changes. Choose the cadence according to how often the business changes and the consequences of stale information. A frequently changing offer may need closer attention than a stable company description. There is no universal frequency that proves a site is ready for AI.

For an agency retainer, name the covered pages, review cadence, included corrections and escalation path. Distinguish detection from human review and implementation. A monitoring service does not automatically include every repair it identifies.

Turn an observation into a small repair task

Suppose a fictional service page changes from “migration included” to “migration quoted separately,” while a copied JSON-LD description retains the original promise. The repair task should name both claims, the approved answer and the pages affected.

A useful task record contains:

1. The URL, observation date and evidence.
2. The previous expected value and current output.
3. Whether the change was intentional, incorrect or unresolved.
4. The owner who approves the business fact.
5. The source to edit and dependent pages to recheck.
6. The live acceptance check and result.

Fix the source that produces the stale value. Editing a generated output once will not help if the next automated run restores the old version. If two systems compete, use the duplicate-schema workflow to resolve ownership.

What does a completed maintenance task show?

A closed task shows the approved fact, the source repaired and the public verification result. This completed fictional record illustrates evidence to retain; the URLs, dates and events are examples, not a customer case study.

If a public check had not run, the status would remain awaiting verification. If an external listing still contradicted the offer, record it as a separate open correction rather than implying this website repair fixed the listing too.

Verify the repair on the public page

After publication, confirm that the intended content and markup reach the public URL. Compare the business facts, parse the JSON and run the relevant vocabulary or search-feature checks. Recheck representative pages when a shared template was changed.

Record exceptions honestly. “Correction requested from directory” differs from “directory corrected.” “Passed syntax check” differs from “confirmed offer matches approved terms.” Keep failed or untested checks visible until the responsible person resolves them.

Google's structured-data policies require relevant, current information for its rich-result use. Following a maintenance workflow does not guarantee a search appearance; it gives your team a defensible record of what it publishes.

Report maintenance separately from visibility

A useful maintenance report shows the pages covered, changes found, fixes completed, unresolved issues and who owns them. Add before-and-after examples where they clarify the work. Avoid filling the report with repeated tool scores that do not explain a customer consequence.

If you also track AI answers, report that separately: questions sampled, engines, dates, mentions, citations, recommendations and factual accuracy. A repaired page and a new recommendation can occur in the same period without establishing causation. Use the measurement guide to keep those observations comparable.

For agencies, this creates a concrete maintenance proposition: agreed coverage, accountable review and verified corrections. The project-scope guide explains how to separate the initial implementation from that ongoing work.

Explore SuperSchema Managed, or discuss maintaining client sites.