How to preserve Yoast SEO data during a WordPress migration

Yoast SEO titles and meta descriptions are often the difference between a rebuild that holds traffic and one that bleeds it. They are stored as post meta — _yoast_wpseo_title, _yoast_wpseo_metadesc, and a dozen related keys — separate from post_content. Copy the content without the meta and Google sees a site full of auto-generated titles on launch day. For agencies, that is not a minor QA miss; it is a client conversation you do not want in week one.

We have run Yoast preservation on everything from ten-page brochure rebuilds to 80-page Elementor migrations where every service page had a hand-crafted title. The principle is always the same: SEO metadata is data, not presentation. It has to travel with the page it belongs to, matched by slug or explicit mapping — not assumed to follow a WXR import or a database clone.

What Yoast data you need to carry over

• arrow_rightSEO title and meta description per page, post and custom post type.
• arrow_rightCanonical URL overrides where you have set them — especially on paginated archives and campaign landing pages.
• arrow_rightNoindex and nofollow flags on pages that should stay out of the index (thank-you pages, internal search, thin tag archives).
• arrow_rightOpen Graph and Twitter title/description overrides for key share pages.
• arrow_rightFocus keyphrase and readability scores — optional for launch, useful for editor continuity.
• arrow_rightYoast Premium redirect rules, if you manage redirects inside Yoast rather than Redirection or server rules.

Why Yoast does not migrate automatically

WordPress's built-in export/import (WXR) does include post meta — so in theory Yoast fields can come across. In practice, rebuilds break the assumptions WXR relies on. New post IDs, restructured page hierarchies, merged pages, and slug changes mean meta attaches to the wrong post or not at all. A theme swap on the same install is simpler; a fresh WordPress build on staging with imported drafts is where metadata silently disappears.

The failure mode is subtle. Pages look fine in the editor. Titles render from the new theme's default pattern — 'Page Name | Site Name' — instead of the optimised string that ranked. Search Console does not flag it immediately. Rankings drift over four to eight weeks. By then the client assumes the rebuild caused the drop, and you are reverse-engineering meta from the Wayback Machine.

Three ways to migrate Yoast SEO data

1. Manual copy (small sites only)

Open old and new pages side by side and copy titles and descriptions from Yoast's sidebar. Viable for under ten pages with stable slugs and a patient project manager. Does not scale, does not survive URL restructuring, and nobody enjoys doing it twice when someone notices a missed page in week two.

2. Database export (developer-led)

Export post meta for Yoast keys and import on the new site, matching posts by slug or a mapping table. Works when post IDs change but slugs stay stable. Fragile when you merge three service pages into one, rename slugs, or switch post types. Requires someone comfortable with wp_postmeta, SQL, or WP-CLI — and a staging environment where a bad import is recoverable.

3. Migration bundle (agency default)

A content migration that maps SEO fields into Yoast (or Rank Math) as part of the import — titles, descriptions and canonicals land on the right page automatically because the bundle carries them per URL. This is how AIRA handles SEO metadata: crawled from the old page, written into Yoast fields on the destination draft alongside ACF block content. Pair with importing an ACF Migrate bundle for the full staging workflow.

Yoast meta keys reference

If you are doing a developer-led meta migration, these are the post meta keys that matter most:

• arrow_right_yoast_wpseo_title — SEO title override.
• arrow_right_yoast_wpseo_metadesc — meta description.
• arrow_right_yoast_wpseo_canonical — canonical URL override.
• arrow_right_yoast_wpseo_meta-robots-noindex / _yoast_wpseo_meta-robots-nofollow — robots flags.
• arrow_right_yoast_wpseo_opengraph-title / _yoast_wpseo_opengraph-description — social overrides.
• arrow_right_yoast_wpseo_twitter-title / _yoast_wpseo_twitter-description — Twitter card overrides.
• arrow_right_yoast_wpseo_focuskw — focus keyphrase (optional).

Global Yoast settings to recreate

Per-page meta is half the job. Global Yoast configuration shapes how every page without an override appears in search results and social shares. Treat these as a checklist, not an afterthought:

1. 1Search Appearance templates per post type — title and description patterns for pages, posts, products, custom types.
2. 2Social profiles and default Open Graph image.
3. 3Breadcrumb settings if enabled — markup may change with the new theme.
4. 4XML sitemap inclusion rules — which post types and taxonomies appear.
5. 5Yoast Premium redirects — export before decommissioning the old site.
6. 6Organisation schema and knowledge graph settings if configured.

Yoast Premium redirects

If the old site managed redirects inside Yoast Premium, those rules do not follow a content export. Export them before you lose access to the old install — Yoast Premium has a redirect export under SEO → Redirects. Cross-reference against your redirect map and import into Redirection, Rank Math, or server rules on the new build. Duplicated redirect rules in two plugins cause loops; pick one home for redirects.

Verification workflow on staging

1. 1Export titles and descriptions from the old site via a Screaming Frog crawl (SEO Elements tab).
2. 2Crawl staging with the same tool; diff spreadsheets on URL slug.
3. 3View-source check on the top 20 traffic pages — confirm <title> and meta description match.
4. 4Confirm noindex pages (thank-you, internal search, cart) kept their flags.
5. 5Validate Open Graph tags with Facebook Sharing Debugger or similar.
6. 6Check canonicals on paginated blog archives and WooCommerce category pages.
7. 7Submit staging sitemap in a test Search Console property if available.
8. 8Cross-check with Rank Math guide if switching plugins.

Common Yoast migration mistakes

• arrow_rightAssuming WXR import carried meta correctly — spot-check, do not trust.
• arrow_rightCanonicals still pointing at old-domain URLs after a domain change.
• arrow_rightNoindex flags lost on utility pages that should stay hidden.
• arrow_rightSearch Appearance templates left at Yoast defaults — every page gets the same pattern.
• arrow_rightYoast and Rank Math both active — duplicate meta output.
• arrow_rightRedirects only in Yoast Premium on old site, never exported before decommission.
• arrow_rightSchema conflicts between Yoast, WooCommerce, and a new theme's markup.

Switching from Yoast to Rank Math (or vice versa)

Plugin switches during a rebuild are common — Rank Math's feature set and interface appeal to some agencies; others stay with Yoast because the client has years of editor familiarity. The meta keys are different: _yoast_wpseo_title vs rank_math_title. A raw database copy will not work. Rank Math's Yoast import tool handles whole-site switches when content and slugs are stable. On a restructured rebuild, run the import then verify page by page — the bulk tool maps by post ID, and IDs change on fresh installs.

Never run Yoast and Rank Math simultaneously on production. Both output meta tags and schema — duplicates confuse crawlers and create validation errors. Pick one plugin on staging, migrate meta into it, verify output, then launch with a single SEO plugin active.

Taxonomy and archive SEO

Yoast stores meta on categories, tags and custom taxonomies as well as posts and pages. If the rebuild changes taxonomy structure — merging tags, renaming categories — audit taxonomy meta separately. A category description optimised for 'web design services' does not help if the category was renamed to 'website design' without updating the meta. Crawl taxonomy archive URLs on the old site and include them in your mapping.

• arrow_rightCategory and tag meta descriptions — often hand-written, often forgotten.
• arrow_rightNoindex settings on thin taxonomy archives.
• arrow_rightCanonical on paginated category pages (/category/news/page/2/).
• arrow_rightBreadcrumb settings that change when permalink structure changes.

Post-launch SEO monitoring

Preservation is not a one-time staging task. Monitor for four weeks after cutover: Search Console Coverage/Pages report for unexpected drops, crawl stats for 404 spikes, and manual SERP checks on your top ten queries. Title rewrites sometimes take two to four weeks to reflect in Google. If rankings drift, diff your staging SEO spreadsheet against live crawl results — the gap is usually a missed template or a canonical pointing at the wrong domain.

How this fits the wider SEO rebuild

Yoast preservation is one layer in rebuilding without losing SEO. Redirects catch URL changes. Internal links should point at final destinations, not old paths — see broken internal links. Images need sideloading, not hotlinked old URLs — see broken images after migration. Run the full migration QA checklist on staging before cutover, then post-launch monitoring for four weeks.

AIRA migrates titles, descriptions and canonicals into Yoast or Rank Math as part of the bundle — one less spreadsheet for your project manager. The crawl reads what Google saw on the old site; the import writes it to the right draft on staging.