Is My Old Schema Wrong After a Website Redesign?

What is this review for?

Structured data is machine-readable information associated with a page. The owner does not need to edit it to review its meaning. The useful question is whether the visible page, the underlying description and the business agree.

This guide addresses factual drift during a redesign. For the larger set of decisions, return to the website redesign hub. The distinction here is factual agreement between page and markup, not whether adding more markup improves performance.

Evidence: c-sdc-articlec-ai

What can validation establish?

Google's structured-data guidance requires markup to represent the page and warns against hidden, misleading or irrelevant content. It also explains that a successful technical test does not guarantee a rich result, and some quality problems are not detected automatically. Google structured-data policies.

Our recommendation is to ask for both a technical review and a business-fact review. These reviews answer different questions. The person checking syntax may not know that an office moved or that the business stopped offering a service. The owner may know those facts without knowing where the site generates its markup.

Keep the finding precise. A mismatch is a reason to correct a description. It is not, by itself, proof that an AI system used the old value or that correcting it will cause a citation.

Evidence: c-sdc-articlec-ai

Which changes can create a mismatch?

New service wording

Does the markup describe the service now shown?

Removed questions

Does any generated FAQ description still refer to removed answers?

Updated business details

Do the relevant public descriptions use the accepted facts?

Replaced article image

Does the article's image reference correspond to the current asset?

Evidence: c-sdc-articlec-ai

This table is an owner review aid, not an instruction to add every schema type. The right markup depends on the actual page and applicable platform guidance.

Evidence: c-sdc-articlec-ai

Why can the page look correct while the record is old?

Our recommendation is to ask where each description is maintained. The visible text and the markup may come from different fields or templates. That possibility should be checked on the actual site rather than assumed.

For example, imagine a business that replaces a page about a discontinued service with a description of its current offering. A reviewer sees accurate text, but another field still names the old service. The business needs the discrepancy explained and corrected in the responsible source. This is a hypothetical example, not a claim about a specific website.

A shared template deserves particular care because a finding on one page may raise a question about other pages using it. Ask the technical team to state the scope it checked. Do not infer that every article is correct from one representative result.

Evidence: c-sdc-articlec-ai

What about author names and article dates?

Google's Article documentation includes author, headline, image and date information as descriptions of the article. Google Article guidance.

Our editorial recommendation is to distinguish a website's redesign date from the history of each article. Do not claim an author reviewed an article merely because a template changed. If the article was substantively updated, keep a record of the new body and its review. If only its presentation changed, explain that accurately in the production record.

The same principle applies to images: a new design does not establish the rights, origin or approval of an asset. Ask which asset is actually intended for the article and what evidence accompanies it.

Evidence: c-sdc-articlec-ai

What should a completed review give you?

Ask for the exact page, the mismatched fact, the accepted replacement and the scope of verification. Keep unresolved business questions visible. A technical team should not invent a service description or author attribution to make a field look complete.

Review the visible answer using the content-loss guide, and record what was checked using the post-launch evidence guide. Avoid making markup the only subject of a redesign review when the content itself is incomplete.

Evidence: c-sdc-articlec-ai

How do you build a page-to-field comparison?

Our recommendation is to start with the actual page being accepted, then list the facts its structured description claims to represent. Ask the technical owner to identify where those descriptions are generated. The purpose is to connect a business fact to its visible wording and its machine-readable representation, not to assemble a longer list of schema types.

The following comparison connects each changed fact to its supporting record. Google's structured-data policies and Article guidance supply the platform context; this workflow is our editorial recommendation.

Evidence: c-sdc-articlec-ai

Service description

Does the public description reflect the offering the business currently accepts?

FAQ answer

Does the structured answer agree with the answer a visitor can actually read?

Author attribution

Is the named person genuinely responsible for this article's attributed work?

Article dates

Do the dates accurately describe the article's history rather than a convenient template value?

Article image

Is the referenced image the intended asset for this article, with its own approval record?

Evidence: c-sdc-articlec-ai

For each row, record the accepted fact and the page or source supporting it. Keep unconfirmed fields open rather than filling them from an old template. A technical reviewer can then compare the generated output with a clear business instruction. The result should be a set of factual agreements or specific discrepancies, not a report saying only that markup exists. Keep the original observation alongside the corrected one so a later reviewer can understand both the reason for the change and the scope of the follow-up.

Evidence: c-sdc-articlec-ai

What would a service-description mismatch look like?

Imagine a hypothetical home-service business that previously installed a product but now offers maintenance only. The redesigned page accurately explains maintenance appointments. Its booking path also asks about maintenance. A separate description still refers to installation because that wording survived in a reusable field. This example is not a report about an AE client, and it does not establish that any search system read or acted on that field.

The business reviewer should first confirm the current service scope. If installation is genuinely unavailable, the technical owner needs an accepted replacement description. If installation remains available through a different process, the team needs to decide whether the current page describes that process clearly. The markup review should not settle a business uncertainty by selecting whichever phrase fits the existing field.

Next, identify the source of the old wording. It might be maintained separately, or the generated output might come from a shared component. Those are possibilities to investigate on the actual site, not assumptions about its architecture. Ask the technical owner to explain where the correction belongs and whether other pages use the same source. A change made in the wrong place can leave the underlying disagreement unresolved.

Finally, compare the corrected output with the accepted visible page. Record the page, old statement, accepted statement and observed result. If related pages still need review, list them as an open scope item. The useful conclusion is that a documented factual mismatch was corrected within a stated scope. Claims about recovered citations or inquiries require separate evidence and do not belong in this correction record.

Evidence: c-sdc-articlec-ai

Who should decide when the page and business record disagree?

A disagreement can involve more than an old markup field. The visible page itself may be inaccurate, or the business may have changed its offering without updating any public description. Our recommendation is to assign factual authority before editing. The person authorized to confirm the service should decide the accepted fact; the person responsible for the website should implement and demonstrate the corresponding change.

Do not use a technical test to choose between conflicting business statements. A format validator cannot determine whether the company still accepts a particular job or whether an author actually reviewed an article. Those questions require the appropriate source or person. Equally, a verbal business correction does not establish that the generated page now carries the new information. Each side of the review needs its own evidence.

A useful handoff separates the accepted fact from the implementation instruction. For example: the business confirms that a service has been retired; the technical owner identifies the affected page description and updates it to match the approved visible explanation. If the business instead confirms that the service remains available, the content team may need to restore a missing explanation before markup can accurately describe it.

Keep the reason for the decision with the record. That makes later review easier when someone encounters an old export, a cached observation or a previous screenshot. The objective is to explain which information was accepted and which output was checked, without implying that every external system has already refreshed its copy.

Evidence: c-sdc-articlec-ai

How far should a shared-template review extend?

A shared-template finding should lead to a scope question. Ask which pages use the affected template, which values are shared and which are supplied separately for each article. Do not assume either that the problem affects every page or that fixing one example closes the whole issue. The technical owner should state the actual inventory and the basis for its review.

Our recommendation is to distinguish a shared rule from a page-specific value. If the issue concerns how the template selects an author, the review may need to examine that selection across relevant articles. If a single page has an outdated service description, its local field may be the immediate correction target. A template name alone does not establish the scope; the team needs to connect the behavior with the pages using it.

Ask how exceptions are handled. An article with a replacement image, a revised author attribution or a different publication history might not behave like the first example tested. The business does not need to read the template code to ask for those cases. It needs a clear explanation of what the review included and what remains outside the checked set.

Close the task with a scope statement such as “the affected field was reviewed on the listed service pages,” accompanied by the actual list and observations. That phrasing is a model for a useful record, not evidence that such a review has occurred here. Avoid changing it to “all schema fixed” unless the evidence really supports that broader claim.

Evidence: c-sdc-articlec-ai

What should you do with author and date information you cannot verify?

Keep uncertainty explicit. A missing author record is not an invitation to assign the founder by default, and a redesign date is not evidence of a substantive article review. Our recommendation is to ask who created or accepted the current version and what record supports the attribution. Preserve the distinction between producing a layout, updating wording and reviewing the subject matter.

Google's Article guidance describes author and date fields as article information. It does not supply the history of your own page. Use the actual article record to decide what can be stated truthfully. Where that record is incomplete, identify the missing information and the person who can resolve it. Do not invent a publication event to satisfy a field in a website template.

The same discipline applies to a replacement image. Confirm which asset belongs to the article and whether its origin and permitted use are documented. A screenshot showing an attractive image does not establish those facts. A structured image reference should describe the intended asset, while the supporting production record explains its approval and provenance.

The completed handoff should tell the next reviewer which facts are established and which are pending. A clearly limited record is useful because it prevents unsupported attribution from becoming embedded in future copies. Once the missing facts are resolved, compare the accepted article and its generated descriptions together before closing the item.

Evidence: c-sdc-articlec-ai