Schema learning

Make structured data agree with the page people can use

A visible content and schema consistency audit pairs material graph claims with the page experience and evidence that support them. It checks meaning, identity, asserted facts and scope as well as syntax.

Use it after the content and technical setup are assembled, before final release, and again when an offer, entity record, policy or template changes.

Read the assertion comparison

By Kevin Maguire · Published by Semantec SEO

Compare the delivered assertion with its page evidence and observation context.

Open folders with page cards, reference books and page models beside a magnifier. — Inspect content, graph output and normal interaction states as distinct checks.

Compare the delivered experience with the delivered graph

A template can emit valid data while the page shows a different price, author or effective date. Inspect the assembled page, its normal interaction states and the structured data delivered for that same URL and context. A saved editor field alone is an incomplete comparison.

Choose a reproducible page state

Record the URL, observation time, locale, market, device layout and relevant user state. Note currency, tax treatment, plan and version when they affect the assertion. Compare the graph and page from the same context rather than mixing a cached desktop response with a different mobile or regional offer.

Inspect content people can reach

Read the final text and media after normal loading and interactions. Check disclosures with keyboard navigation and the accessibility tree, including answer text and accessible names. Content available only through a broken control or an error state needs repair; the presence of a hidden string in source is weak evidence of a usable answer.

Separate factual claims from technical metadata

Compare material assertions about people, products, prices, dates, answers and actions with the content and sources that support them. Technical identifiers and technical setup metadata do not need to be printed as identical strings on the page. Check the vocabulary and feature documentation instead of inventing a requirement to display every graph field.

Compare meaning and scope

Different wording can express the same supported fact. Matching strings can also refer to different products, authors or offers. Check the node identity, relationship, asserted fact, qualifiers and period together. The goal is a truthful selected description, not an obligation to encode every sentence on the page.

Pair each disputed assertion with its page evidence

This hypothetical audit uses invented prices, people and states. It illustrates a record format and repair decisions; no page, offer or technical setup has been tested. Each pair refers to one stated page context.

Illustrative comparison of rendered content and graph claims
Graph assertion	Accessible page evidence	Finding	Repair and responsible owner
Offer.price = 20 for the displayed plan.	The pricing block for that same plan, currency, market and period says 25.	Conflicting amount.	Pricing/data owner confirms the controlling offer. Update the page or emitter from that source, then compare both outputs again.
author identifies Person A.	The byline identifies Person B; the editorial record does not yet resolve the disagreement.	Identity conflict.	Editorial owner resolves authorship. Hold the disputed assertion instead of copying the convenient name into both places.
An answer is described as part of the page’s questions.	The answer text exists in source, but the disclosure cannot be operated with a keyboard.	Inaccessible support and a user interface defect.	Front end owner repairs normal access; content owner confirms the answer and any feature requirements before retaining the markup.
A price is expressed as applying to every visitor.	The page explains different offers by market and tax status, with no single universal offer.	Broader scope than the page supports.	Offer and graph owners narrow the claim to an evidenced offer or remove the unsupported assertion. Do not invent a universal amount.
A date describes the current version.	The visible note and source concern a superseded version.	Stale or differently scoped support.	Version/content owner establishes the current record, then updates the dependent date and description or preserves them explicitly as history.

A finding can carry more than one label: missing, hidden, inaccessible, broader, narrower, stale, conflicting or differently scoped. Explain the cause rather than choosing a label by appearance alone. A graph that describes only part of a page is not automatically incomplete; a narrower claim becomes a defect when it distorts the subject or fails an applicable requirement.

Keep enough context to reproduce the mismatch

Graph assertion Record the exact node identity, type, property, asserted fact and relationship under review. Identify the emitter, such as a theme, plugin, custom block or connected data source, and retain the saved output.
Visible page support Point to the exact text, media, price block, byline, disclosure or action. Record the interaction needed to reach it and the page state in which it was observed. A screenshot helps locate a finding but does not replace text, interaction or accessibility checks.
Evidence and scope Keep the controlling source, observation date, effective period, market, version and unresolved uncertainty. Preserve both conflicting records until the appropriate owner decides which is supported.
Mismatch and repair State the factual disagreement and its cause. Choose a content update, graph correction, property removal, identity repair or release hold. Do not mark a record accepted merely because the syntax parses.
Owner and next review Name the source owner and technical owner when they differ. Record the accepted state, affected dependencies, retest evidence, next action and event that reopens the review.

Repair the source of the disagreement

Choose the smallest correction that restores a supported claim. A local graph edit can conceal a pricing, authorship or template defect that will return on the next regeneration. Resolve the controlling source before making the page and graph agree.

Find the source and emitter responsible for the faulty assertion.

Confirm the intended fact. Ask the responsible source owner to settle the identity, asserted fact and scope. If neither representation is supported, do not choose one merely to remove the difference. Hold or remove the disputed assertion while the source is resolved.
Repair the appropriate layer. Update the content if the page is wrong, the data mapping if the graph is wrong, and the shared template if the fault repeats across a family. Repair broken disclosure behavior independently of deciding which markup is appropriate.
Follow dependent assertions. Check other nodes, relationships and page variants using the revised assertion. Reuse an accepted entity identity rather than creating another node to conceal a conflict. Keep supported historical states distinct from current claims.
Recheck the assembled result. Regenerate the page and graph, account for caches and page delivery layers, then repeat the comparison in the affected contexts. Confirm the visible text, accessible interaction and emitted assertion now express the same supported meaning.

Two navy archive boxes beside an unnumbered clock and blank record card. — Retain the accepted version and retest record when the page changes.

Retest after changes that can move the evidence

Repeat the audit after material content, offer, policy, identity or template changes. Keep the previous accepted comparison so the next reviewer can tell which assertions changed and which states were tested. A fresh timestamp alone cannot establish that a claim remains supported.

Test representative variants

Include affected layouts, locales, markets and normal interaction states. For personalized content, document which offer and context the graph represents and check the applicable feature rules. One passing screenshot does not settle every state.

Keep checking layers separate

Parsing checks syntax; vocabulary review checks types and properties; evidence review checks truth and scope; rendered review checks the delivered experience. Search feature requirements need their own current documentation check. Passing one layer does not prove another has passed.

Close with review evidence

Keep the saved graph, page observations, controlling source, correction, owner and retest result together. A material unresolved disagreement should stop the affected schema release under the site’s review policy; remove only the unsupported portion when the remaining graph stays truthful.

Reopen shared defects across the family

When a publisher mapping, product feed or template changes, identify typical pages and pages with exceptions that depend on it. Retest after the public response and cache state have updated. Keep unresolved records visible instead of carrying a stale approval forward.

Questions about page and schema consistency

Can an answer inside an accordion support markup?

An answer reachable through a normal working disclosure may support the page description, subject to the relevant vocabulary and search feature rules. Test keyboard access and the delivered text. A broken or inaccessible control is a separate defect; do not infer eligibility from the presence of source text.

Must the page use the exact same wording as the graph?

No. The asserted meaning, entity, asserted fact and scope need to agree. Technical IDs and metadata require the right technical and evidence checks, rather than being copied into visible prose simply to match a string.

Should a missing optional property block the whole page?

Not automatically. Distinguish unsupported markup from a missing fact the reader needs. Omit an unsupported optional assertion when the remaining description is truthful; hold a node or page when the unresolved issue defeats its identity, required technical setup or useful visible content.

Does a clean comparison guarantee a rich result?

No. This review controls consistency and evidence. Search feature eligibility, selection, indexing, rankings, traffic and conversions require separate conditions and are not guaranteed by a matching graph.