Structured Data Migration: A Checklist for Website Redesigns
A structured data migration involves auditing existing Schema markup, mapping it to the new system and testing the output before launch. The goal is to keep data accurate, consistent with visible content and technically suitable for supported search features.
This checklist helps site owners, project managers, SEOs and developers coordinate a redesign, CMS change, domain move or URL migration. Valid markup does not guarantee unchanged rich results, rankings or AI citations; technical acceptance and search-performance evaluation should be assessed separately.
1. Separate Schema validity from search-feature eligibility
Schema.org provides a vocabulary for describing content and entities. Google supports selected structured data features with their own requirements. A valid Schema type does not automatically have a corresponding rich result.
- Schema Markup Validator: checks markup structure and use of the Schema.org vocabulary.
- Rich Results Test: checks the data types and technical requirements currently supported by Google's tool; it does not validate every Schema type.
- Search Console: provides relevant reports where available. Not every markup type has a dedicated report.
Verified update, November 1, 2026: Google stopped displaying FAQ rich results on May 7, 2026. Restoring this feature should therefore not be an acceptance KPI. FAQPage remains a Schema.org type; retain it only when it accurately describes the content and serves a defined use case.
2. Audit existing markup before changing the site
Identify where markup is generated and who owns each data source before copying anything into the new platform.
- Sample homepages, products, product variants, articles, categories, organization pages and genuine business locations where applicable.
- Archive original HTML, rendered DOM, JSON-LD, microdata and RDFa for each sample, including deployment version and timestamp.
- Identify markup producers: theme, SEO plugin, commerce module, custom code or Google Tag Manager.
- Record types, entities, @id values, URLs, relationships and existing errors or warnings.
- Save available Search Console baselines for relevant page groups and search appearances. Do not invent missing metrics.
Where themes and plugins overlap, a pre-redesign SEO audit can distinguish existing issues from migration regressions.
Issues to document
- Prices, currencies, availability or business information that differ from visible content.
- Conflicting descriptions of the same entity generated by multiple systems.
- Image, logo, author or entity URLs pointing to staging or obsolete locations.
- Markup that depends on user interactions, fails because of JavaScript errors or loads inconsistently.
- Inappropriate types, such as assigning Product to every category page or describing a nonexistent location as LocalBusiness.
3. Map old data to the new model
The mapping should identify backend sources, output properties, transformation rules and missing-data handling. Backend paths below are illustrative.
| Output property | Old source → new source | Validation rule |
|---|---|---|
| Product.name | product.title → product.name | Correct product name matching the page |
| Product.offers.price | pricing.current → pricing.salePrice | Actual price in the correct format; do not substitute zero for missing data |
| Product.offers.priceCurrency | store.currency → market.currency | Appropriate currency code, such as VND, matching the displayed price |
| Article.author | article.byline → author record | Accurate Person or Organization object with verified name and author URL |
| BreadcrumbList.itemListElement | category.path → navigation.breadcrumbs | Names, positions and URLs match the navigation trail |
| Organization/LocalBusiness | company settings → business profile | Accurate identity, URL, logo, contact and applicable location details |
| @id and references | Existing identifiers → approved identifiers | Consistent node relationships; no staging hostnames |
Required and recommended properties depend on the intended feature, such as Product snippets or Merchant listings. Use that feature's current documentation rather than one universal list of required Product properties.
Handle @id changes deliberately
@id identifies a node in the data graph; it is not a ranking guarantee. If a URL-based identifier changes, update references such as publisher, author or brand consistently. Avoid creating new identities for the same organization simply because its template changes. Document which identifiers remain and which are replaced.
4. Choose JSON-LD delivery and control data ownership
Inline JSON-LD and server-rendered JSON-LD are not opposing options. Inline describes placement in a script element on the page; that element can be generated by the server or inserted into the DOM by JavaScript.
- Server-generated output: a practical option when the backend already has the data, making markup available in the initial HTML response.
- JavaScript-generated output: Google can process structured data in the rendered DOM. Test real URLs and do not assume all crawlers render JavaScript identically.
- Rapidly changing products: assess the reliability of JavaScript-dependent prices and availability, and keep markup synchronized with visible content.
- External JSON-LD files: do not assume that linking to a .jsonld file is sufficient for Google. Verify that the relevant data is actually embedded or generated in the rendered page.
A page may contain multiple valid nodes and JSON-LD blocks, including Article, BreadcrumbList and Organization. Remove redundant or conflicting declarations rather than reducing every page to a single type. An @graph with @id references can help organize related entities.
Product-template example: before and after
Before: the theme and plugin generate conflicting Product prices, breadcrumbs contain old URLs, and currency is missing or incorrect.
After: product information has a controlled data source, prices and currencies match the page, breadcrumbs are updated and entity references are consistent. Test the intended feature before expanding deployment; a valid test result does not guarantee a rich result.
5. Test data, page context and entity relationships
| Testing layer | What to check | Acceptance evidence |
|---|---|---|
| Syntax and mapping | JSON parses; values and data types come from the correct source | Automated tests with representative inputs |
| Schema.org semantics | Appropriate types, properties and relationships | Validator output and manual review |
| Google feature requirements | Requirements of the currently supported target feature | Rich Results Test results for relevant samples |
| Rendering and access | Markup in HTML/DOM, accessible resources, no staging references | Response HTML, rendered DOM and URL checks |
| Content and security | Accurate visible-content alignment and safe handling of untrusted input | Content QA and serialization tests |
- Test in-stock/out-of-stock products, promotions, missing images, variants and language versions.
- Distinguish eligibility errors from recommended-property warnings. Do not fabricate values to remove every warning.
- When information is missing, retrieve verified data, omit optional properties or withhold incomplete nodes as appropriate. Never invent prices, reviews, authors or addresses.
- Use a JSON serializer and safe embedding practices appropriate to the framework. Avoid concatenating untrusted content directly into script elements.
Do not expose protected staging solely to run Google's tools. Test code and rendering internally, then validate production URLs after release. Code-input checks do not fully replace JavaScript testing on an actual URL.
6. Release by template and monitor production
Select representative pages, including edge cases, for an initial release. A fixed 1–5% sample is not appropriate for every site: coverage should reflect templates, data variations and monitoring capacity.
- Archive the template version, mapping, plugin settings and pre-release results.
- Release the initial sample and inspect production HTML/DOM, values and references.
- Expand after blocking issues are resolved and the accountable owner approves.
- Review relevant Search Console reports where available, inspect sample URLs and compare business data.
- Record changes by page group, accounting for reporting delays, seasonality, URL changes and other simultaneous releases.
A 14–30-day period may be an initial internal monitoring window, extended as needed. It is not a guaranteed processing or recovery timeline. A decline in total clicks does not by itself establish that Schema caused the change.
7. Define when to roll back
Prefer targeted mapping or configuration fixes when the problem is understood. Roll back when a release introduces widespread inaccurate data, breaks templates or cannot be repaired within the agreed incident window. Do not roll back automatically because rich results have not appeared.
- Restore a verified code or configuration version rather than blindly restoring old data.
- Confirm that restored markup remains compatible with current URLs, prices, availability and content.
- Purge relevant caches and rerun tests on affected templates.
- Record timestamps, scope and findings, and assign root-cause remediation.
Include structured data requirements in your website redesign brief to avoid disconnected fixes after development is complete.
8. Understand what Schema can support in AEO/GEO
Structured data helps describe content and entities, but it is not the single source of truth every answer engine must use. Google AI Overviews and AI Mode do not require a special Schema type; accessible content and applicable search requirements still matter.
- sameAs: use reference pages that clearly identify the same entity, such as an official profile. It is not a general bibliography property.
- Citations: provide source links in visible content. Where appropriate, CreativeWork.citation can describe a citation relationship; do not substitute sameAs.
- FAQ answers: when using FAQPage, use mainEntity → Question → acceptedAnswer → Answer, with text for the answer's content, rather than an invented answerText property.
- Entity consistency: verify brand names, URLs, authors and contact information. Avoid unrelated identity links intended to imply authority.
Quick acceptance checklist for PMs, SEOs and developers
- Representative pages and existing markup archived.
- Markup producers and template owners identified.
- Mapping covers missing data, URLs and @id references.
- Types and properties match page content.
- No conflicting duplicate entities or staging hostnames remain.
- Syntax, semantics, rendering and relevant Google features tested.
- Data variations and safe JSON embedding checked.
- Release, remediation, rollback and monitoring criteria agreed.
Frequently asked questions
Must all markup be converted to JSON-LD during a redesign?
No. Google supports JSON-LD, microdata and RDFa. JSON-LD is often easier to maintain at scale, but accuracy, maintainability and test coverage should guide the decision.
Are multiple JSON-LD blocks an error?
Not automatically. A page can describe several entities. Review conflicting or redundant declarations and ensure relationships are consistent.
Does passing Rich Results Test guarantee a rich result?
No. Technical validation does not guarantee display, which also depends on content, policies and search-system decisions.
Should FAQPage be retained after migration?
Retain it when accurate and useful for a defined purpose. Do not use Google FAQ rich results as an acceptance target because that display feature has been discontinued.
Manage structured data beyond validation
A reliable migration requires accurate values, consistent entity relationships and test evidence from the real site. To discuss template auditing, data mapping or rollout requirements, contact Viet SEO for a project-specific scope.
Questions & Comments
You can ask a question about this article. Viet SEO will review and reply after moderation.