Fixing Structured Data Lost in a Migration

Why structured data goes missing in a move

Content is migrated deliberately: someone exports posts and products and imports them. Structured data usually is not, because it was never stored as content. It was assembled at page-render time from settings and fields by whatever software ran the old site. Change that software and the output changes with it.

Even when markup survives, it can carry the old site with it. Identifiers such as @id, url, logo and image may still use the old domain or the staging host, which quietly breaks the links between entities.

Building an inventory of the old markup

The migration audit compares structured data before and after, but to restore it you need to know exactly what each type of page carried. Work by template, not by URL: a site with forty thousand pages may have only eight templates.

1. List the templates: home, category, product, article, author, location, contact, FAQ-style help pages and so on.
2. Pick two or three representative URLs for each from the old crawl or a saved copy.
3. For each, record the schema types present, the key properties, whether it was JSON-LD or microdata, and what produced it.

If the old site is already gone, saved crawl exports that included structured data extraction, cached copies in the Internet Archive and old Search Console enhancement reports (which list the types Google detected) will fill most of the gaps.

A short script can pull JSON-LD types from a list of addresses, which makes before-and-after comparisons quick when both versions are still reachable, for example the old site on a backup host.

import json, re, sys, requests

def types(url):
    html = requests.get(url, timeout=20).text
    found = []
    for block in re.findall(r'<script[^>]*application/ld\+json[^>]*>(.*?)</script>', html, re.S):
        try:
            data = json.loads(block)
        except ValueError:
            found.append("INVALID JSON"); continue
        items = data.get("@graph", [data]) if isinstance(data, dict) else data
        found += [str(i.get("@type")) for i in items if isinstance(i, dict)]
    return sorted(found)

for line in open(sys.argv[1]):
    old, new = line.split()
    a, b = types(old), types(new)
    if a != b:
        print(new, "missing:", sorted(set(a) - set(b)), "added:", sorted(set(b) - set(a)))

The script only sees JSON-LD in the HTML the server sends. Microdata and markup added by JavaScript need a crawler that renders pages, or a check in the Rich Results Test, which renders like Google.

Which lost types matter most

Not every missing block has the same effect. Prioritise by what the markup did in search results and what depends on it.

• Product and Offer on shop pages. Price, availability, shipping and returns information feed product snippets and merchant listings. Losing them is usually the most visible loss for a shop.
• Review and AggregateRating. Star ratings shown on product and some other page types. They must describe reviews visible on the page itself.
• BreadcrumbList. Replaces the raw URL with a readable trail in results on many layouts. New URL structures often change the trail, so rebuild it to match the new hierarchy.
• Article with author and dates. Helps search engines understand publication and update dates and connect content to its author.
• Organization or LocalBusiness. The site-wide description of who you are, with logo, contact details and profiles. Usually on the home or about page.
• Event, Recipe, JobPosting, Course and similar. Each drives a specific search feature and needs its required properties.

The fix, step by step

Getting identifiers and URLs right

Modern markup often uses a connected graph: the WebSite, the Organization, the WebPage and the Article each have an @id, and they refer to each other. After a migration those identifiers must be rebuilt on the new domain, and they must be identical everywhere they are used.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.example.co.uk/#organization",
      "name": "Brightwater Garden Supplies",
      "url": "https://www.example.co.uk/",
      "logo": "https://www.example.co.uk/images/logo-512.png"
    },
    {
      "@type": "WebSite",
      "@id": "https://www.example.co.uk/#website",
      "url": "https://www.example.co.uk/",
      "name": "Brightwater Garden Supplies",
      "publisher": { "@id": "https://www.example.co.uk/#organization" }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://www.example.co.uk/tools/pruning/#breadcrumb",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://www.example.co.uk/" },
        { "@type": "ListItem", "position": 2, "name": "Tools", "item": "https://www.example.co.uk/tools/" },
        { "@type": "ListItem", "position": 3, "name": "Pruning", "item": "https://www.example.co.uk/tools/pruning/" }
      ]
    }
  ]
}
</script>

• Use the canonical form of every address. An item that redirects or a logo on the old host still works in a browser but no longer describes the new site cleanly.
• Rebuild breadcrumbs from the new hierarchy. If categories were renamed or flattened, the old trail no longer matches the visible breadcrumb.
• Update sameAs profiles only if they changed. Social profile addresses do not usually move, but check any that used the old brand name.

Where to rebuild it, by platform

WordPress to WordPress (new theme)

Keep the same SEO plugin and export its settings from the old site, so the organisation details, logo and content type settings carry over. Check that the new theme does not add its own conflicting markup; two Organization or Product blocks from different sources is a common result of a redesign.

Moving to Shopify

Themes add basic Product markup, but the level of detail varies. Reviews usually come from an app, which must be reinstalled and connected to the theme. Compare a product page against the inventory, especially offers, availability, brand and identifiers such as GTIN.

Headless and custom front ends

Build a small set of functions that turn CMS fields into JSON-LD for each template, and render the result on the server. Treat the inventory from step one as the specification for that work. The headless migration guide covers rendering checks in more detail.

Keeping it from happening again

• Keep the inventory. The template-by-template record from step one becomes the specification for the next redesign or platform change.
• Test markup before launch. Add structured data comparison to the migration test plan alongside redirects and content, using staging URLs.
• Watch for changes after launch. Theme updates, app updates and CMS upgrades can remove markup long after a migration. A regular comparison, such as the one described in the Schema Drift Guide, catches these early.
• Own the source. Document which plugin, app or template produces each type, so no one removes it without realising.