Migrating SEO fields between WordPress plugins

Migrating SEO fields between WordPress plugins is not simply a matter of installing a new SEO plugin and deactivating the old one. Titles, meta descriptions, canonical URLs, robots directives, focus keyphrases, social metadata and schema settings may be stored in plugin-specific database fields that another plugin does not automatically understand.

The visible WordPress content can remain completely unchanged while important SEO metadata quietly disappears from the rendered page.

A careless migration can therefore turn this:

Existing SEO plugin
↓
custom title
custom description
canonical URL
indexing rules
social metadata
schema settings

into this:

New SEO plugin
↓
empty fields
↓
fallback metadata
↓
changed search output

The safer approach is to inventory the existing metadata, understand how the source and destination plugins store it, create an explicit field mapping, test the conversion on staging and verify the final HTML before removing the old system.

What does migrating SEO fields actually mean?

WordPress itself stores the main content of a post separately from most plugin-specific SEO configuration.

A post may contain:

post title
post content
excerpt
slug
publication status
author
taxonomy relationships

while an SEO plugin may add its own metadata for:

• SEO titles;
• meta descriptions;
• focus keyphrases;
• canonical URLs;
• robots directives;
• Open Graph titles;
• Open Graph descriptions;
• social images;
• Twitter/X metadata;
• schema types;
• breadcrumb configuration;
• redirect information;
• analysis scores.

Those values commonly live in WordPress metadata, plugin options or dedicated plugin tables.

The destination plugin may use completely different storage keys and structures.

The content can survive while the SEO configuration does not

This distinction is important.

Suppose a WordPress page contains:

Title:
WordPress Backup Guide

Content:
3,000 words

Slug:
/wordpress-backup-guide/

Changing SEO plugins does not normally delete those core WordPress values.

But the old plugin may separately store:

SEO title:
WordPress Backup Guide: Complete Tutorial

Meta description:
Learn how to create, store and test WordPress backups...

Canonical:
https://example.com/wordpress-backup-guide/

Robots:
index, follow

If those plugin-specific values are not migrated, the new plugin may generate different output from WordPress defaults.

SEO metadata is not standardized across WordPress plugins

WordPress provides a general metadata API, but SEO plugins are free to design their own storage models.

One plugin might store a title under a key conceptually similar to:

_plugin_a_seo_title

while another expects:

_plugin_b_title

Another system may store several properties together in an option or custom table.

The names above are illustrative rather than real plugin keys, but the architectural problem is real:

same SEO concept
≠
same database representation

Do not guess metadata keys

If you are performing a manual or scripted migration, determine the actual storage structure used by the versions of the plugins installed on the site.

Do not copy database keys from an old forum post and assume they remain current.

Plugin storage implementations can change between versions.

Start with a complete backup

Before modifying SEO metadata in bulk, create a recoverable backup of the site.

At minimum, protect the database because that is where most SEO metadata will live.

For a broader migration, also preserve:

• WordPress core configuration;
• plugins;
• themes;
• uploads;
• custom code;
• server configuration where relevant.

TheOneWP’s Backup Manager can provide a recovery point before performing high-impact database or configuration changes.

A backup should be restorable

Having a ZIP file somewhere is comforting, but it is not the same thing as knowing recovery works.

For important production sites, verify the recovery process before performing a large metadata conversion.

Use a staging environment

SEO migrations are excellent candidates for staging-first work.

A staging copy lets you:

• inspect the existing database;
• install the destination plugin;
• run import tools;
• test custom conversion scripts;
• compare metadata;
• inspect rendered HTML;
• find unsupported fields;
• repeat the migration if necessary.

For the wider workflow, see WordPress Staging Site Best Practices.

Do not let staging become indexable

A staging environment used for SEO testing should not accidentally compete with the production website.

Protect staging appropriately and verify that search engines are not being invited to index a duplicate copy of the site.

Inventory the current SEO system

Before moving anything, determine what the source plugin currently controls.

Create an inventory of:

• post and page metadata;
• custom post type metadata;
• taxonomy metadata;
• homepage SEO settings;
• archive settings;
• robots directives;
• canonical URLs;
• XML sitemap settings;
• schema configuration;
• social metadata;
• breadcrumbs;
• redirects;
• site verification codes.

The migration scope is larger than the two fields labelled “SEO title” and “meta description.”

Separate content-level and global SEO settings

SEO configuration usually exists at more than one level.

Content-level values may include:

post 123
→ SEO title
→ description
→ canonical
→ robots
→ social image

Global configuration may include:

title templates
taxonomy templates
archive indexing
sitemap configuration
schema defaults
social profiles
verification codes
breadcrumb settings

A migration tool that imports post metadata may not migrate global configuration.

Build a field mapping before writing data

The core of a controlled migration is a mapping table.

Conceptually:

Source field
             → Destination field

SEO title
             → SEO title

Meta description
             → Meta description

Canonical URL
             → Canonical URL

Robots index
             → Robots index

Robots follow
             → Robots follow

Social title
             → Social title

Social description
             → Social description

Social image
             → Social image

Do not begin bulk conversion until you understand how each important source value maps to the destination.

Some fields have no direct equivalent

A source plugin may support a feature that the destination plugin handles differently or does not support.

Possible examples include:

• plugin-specific SEO scores;
• content analysis history;
• multiple focus keyphrases;
• advanced schema graphs;
• special breadcrumb metadata;
• redirect groups;
• social-network-specific settings.

When no equivalent exists, decide explicitly whether the data should be:

converted
preserved
recreated
ignored
archived

Do not silently discard it.

Not every SEO field deserves migration

Some plugin metadata is operational rather than part of the final search output.

For example, an SEO analysis score may simply describe how the source plugin evaluated the page at a particular moment.

That score may have no useful meaning inside another plugin.

The important distinction is:

metadata affecting frontend/search output

versus

metadata used only by the old plugin's interface

Prioritize output-affecting metadata

Fields that deserve particular attention include:

• SEO titles;
• meta descriptions;
• canonical URLs;
• robots directives;
• social metadata;
• schema configuration;
• redirects where managed by the SEO plugin.

These can directly alter what crawlers and social platforms receive.

SEO titles need careful migration

A custom SEO title may differ intentionally from the WordPress post title.

For example:

WordPress post title:
How WordPress Backups Work

SEO title:
WordPress Backups Explained: Files, Database & Restore

If the custom value disappears, the destination plugin may fall back to:

How WordPress Backups Work | Example Site

That is not necessarily bad, but it is a change.

A migration should preserve intentional metadata rather than changing it accidentally.

Understand title templates

Some SEO systems store explicit page titles while also supporting variables or templates.

A conceptual template might resemble:

%%title%% %%sep%% %%sitename%%

Another plugin may use different variable syntax.

Copying the literal template string without translating its variables can produce broken titles.

Rendered output matters more than stored syntax

When comparing systems, ask:

What title reaches the final HTML?

not merely:

Does the destination database contain
the same string?

Different systems can store different representations while producing equivalent output.

Meta descriptions are usually simpler, but still verify them

Custom descriptions are generally straightforward text values, but migration problems can still include:

• missing fields;
• HTML entities;
• template variables;
• truncated values;
• encoding problems;
• incorrect post associations.

Compare representative descriptions before and after migration.

Empty fields need an explicit policy

Suppose the source plugin contains no custom description for a page.

The destination might:

• leave the description absent;
• generate one from the excerpt;
• use a global template;
• generate a description dynamically.

Those behaviors are not equivalent.

Determine how empty source values should behave after migration.

Canonical URLs are high-risk fields

Canonical tags tell search engines which URL is preferred among duplicate or similar pages.

A custom canonical can therefore be more consequential than a missing focus keyphrase.

For example:

<link rel="canonical"
      href="https://example.com/preferred-page/">

If that custom value disappears, the new plugin may generate a self-referencing canonical instead.

That changes the signal.

For the underlying concept, see WordPress Canonical URLs Explained.

Do not blindly migrate malformed canonicals

A migration is also an opportunity to discover bad historical data.

Source values may contain:

• staging domains;
• HTTP instead of HTTPS;
• obsolete domains;
• redirected URLs;
• 404 URLs;
• relative paths where absolute URLs are expected.

Preserving metadata faithfully does not mean preserving known mistakes indefinitely.

Audit custom canonicals before importing them

Classify them:

valid and intentional
invalid
obsolete
unnecessary
requires manual review

Then migrate only the values you actually want to keep.

Robots directives require semantic mapping

Different SEO plugins may represent indexing directives differently.

One may conceptually store:

index = true
follow = true

another:

robots = "index,follow"

and another may inherit global defaults unless a page-level override exists.

The migration therefore needs to preserve meaning, not merely copy raw values.

Pay particular attention to noindex

An accidental indexing change can affect important content.

After migration, inspect pages that intentionally use:

noindex

and important pages that should remain:

index

A migration that reverses either group is a problem.

Inheritance complicates robots migration

Suppose the source plugin stores no page-level value because the page inherits:

global default → index

The destination plugin might interpret an empty value differently.

Migration logic should distinguish:

explicit index
explicit noindex
inherit default

when the source system makes that distinction.

Focus keyphrases are usually editorial metadata

A focus keyphrase is commonly used by an SEO plugin’s analysis interface rather than emitted directly into the HTML.

Losing it does not automatically remove rankings.

However, it may still be valuable editorial data because it records what query or topic the page was optimized around.

If the destination supports an equivalent field, migrating it can preserve the editorial workflow.

Do not confuse focus keyphrase migration with ranking preservation

Search engines do not require access to a plugin’s private focus-keyphrase database field.

What matters externally is the actual page:

• content;
• title;
• links;
• metadata;
• structured data;
• indexing directives;
• overall site architecture.

The focus field is primarily a tool for the editor.

Social metadata may be separate

SEO plugins can store custom values for social sharing.

These may include:

Open Graph title
Open Graph description
Open Graph image

Twitter/X title
Twitter/X description
Twitter/X image

If custom social values exist, determine whether the destination plugin can import them.

Check the rendered social tags

After migration, inspect output such as:

<meta property="og:title"
      content="...">

<meta property="og:description"
      content="...">

<meta property="og:image"
      content="...">

Do not assume the settings screen accurately represents every frontend tag.

Social images need special attention

A plugin may store a social image as:

• an attachment ID;
• a full URL;
• structured metadata;
• an inherited featured image.

Copying the wrong representation can leave the destination field technically populated but functionally broken.

Schema migration can be substantially more complicated

Structured data is not always represented as one simple post-meta field.

An SEO plugin may build schema from:

• global defaults;
• post type configuration;
• page-level overrides;
• custom fields;
• user information;
• organization settings;
• plugin integrations.

A one-to-one field copy may therefore be impossible.

Compare final structured data, not only settings

Before and after migration, inspect representative pages and compare the generated structured data.

Google’s Rich Results Test can help inspect supported rich-result markup, while Schema.org Validator can be useful for broader schema validation.

Redirects may belong to the SEO plugin too

Some SEO plugins include redirect management.

If the source plugin does, identify whether redirects are part of the migration.

Do not deactivate the source system and discover afterward that several hundred legacy URLs depended on it.

If redirects are moving to another system, preserve:

• source path;
• destination;
• status code;
• query handling where relevant;
• regular-expression behavior if used;
• disabled/enabled state.

Test redirects independently

After migration:

old URL
↓
expected HTTP status
↓
correct destination

should be verified directly.

TheOneWP’s Redirect Manager can manage 301, 302 and 410 responses when redirects are being consolidated into TheOneWP.

XML sitemap configuration may change

The source SEO plugin may currently decide which content appears in the sitemap.

Switching systems can change inclusion rules for:

• posts;
• pages;
• custom post types;
• categories;
• tags;
• custom taxonomies;
• author archives;
• other archives.

After migration, compare the old and new sitemap structures.

What Is an XML Sitemap, and Why Does It Matter? explains what the sitemap does and how inclusion decisions relate to the site’s indexing strategy.

A sitemap is not a substitute for canonical and robots checks

These systems communicate different signals.

A URL being present in an XML sitemap does not automatically prove that:

canonical is correct
robots are correct
page is indexable
page returns 200
page should be indexed

Review them together.

Custom post types are easy to overlook

Do not test only ordinary Posts and Pages.

A production site may also contain:

• products;
• portfolio items;
• properties;
• events;
• documentation;
• recipes;
• team members;
• other custom content types.

SEO metadata for these objects may use the same storage model but different global templates or indexing defaults.

See WordPress Custom Post Types and SEO for the broader relationship between custom content structures and search visibility.

Taxonomy metadata needs its own audit

Categories, tags and custom taxonomy terms may have SEO fields separate from post metadata.

Possible values include:

• custom titles;
• descriptions;
• canonical URLs;
• robots directives;
• social metadata.

A migration that handles posts perfectly can still leave taxonomy archives behind.

Author archives and date archives may also have configuration

Check whether the source system controls:

• author archive indexing;
• date archive indexing;
• search-result indexing;
• attachment URLs;
• pagination behavior.

These settings may be global rather than individual metadata records.

Homepage SEO can be a special case

WordPress can use either:

latest posts

or

static front page

SEO plugins may handle homepage metadata differently depending on that configuration.

Explicitly verify the homepage after migration.

Inspect the database before designing a custom migration

WordPress exposes metadata through APIs such as get_post_meta() and update_post_meta().

For post-level SEO data stored in standard metadata, these APIs are usually preferable to blindly modifying database rows with raw SQL.

Why use WordPress metadata APIs?

They provide the application-level interface for metadata operations.

For example:

$value = get_post_meta(
    $post_id,
    '_source_key',
    true
);

if ( '' !== $value ) {
    update_post_meta(
        $post_id,
        '_destination_key',
        $value
    );
}

This example is intentionally generic.

The actual keys must come from verified source and destination plugin implementations.

Do not copy example keys into production

The following:

_source_key
_destination_key

are placeholders.

They are not real SEO-plugin fields.

Determine actual keys from current documentation, source code, export tools or database inspection.

Build the migration script around explicit mappings

A simple conceptual mapping might be:

$mapping = [
    'source_title'       => 'destination_title',
    'source_description' => 'destination_description',
    'source_canonical'   => 'destination_canonical',
];

Then process each field intentionally rather than copying every source-plugin metadata key indiscriminately.

Why copying every prefixed field is dangerous

A plugin may store internal data such as:

• analysis caches;
• scores;
• migration flags;
• UI state;
• schema internals;
• version markers;
• serialized settings.

The destination plugin does not necessarily need or understand any of them.

Use batches on large websites

A site with tens or hundreds of thousands of posts should not necessarily migrate every metadata record in one browser request.

Large conversions can encounter:

• PHP execution limits;
• memory limits;
• database locks;
• HTTP timeouts;
• partial completion;
• unclear recovery state.

Batch processing makes progress easier to monitor and retry.

Make migration scripts idempotent where practical

An idempotent migration can be run again without corrupting already migrated records.

Conceptually:

read source
↓
validate
↓
check destination state
↓
write expected destination value
↓
record result

This is safer than a script that blindly appends or transforms values differently every time it runs.

Log migration results

For bulk conversions, record useful information such as:

post ID
source field
destination field
status
warning
error

A summary might report:

8,420 posts inspected
6,103 custom titles migrated
5,871 descriptions migrated
214 custom canonicals migrated
37 unsupported values flagged
4 errors

Now you know what happened instead of merely hoping the progress bar had good intentions.

Do not delete the source data immediately

During migration, it is often safer to:

read source metadata
↓
write destination metadata
↓
verify
↓
switch output
↓
monitor
↓
remove obsolete source data later if desired

Deleting source metadata during the first conversion removes an easy rollback path.

Old metadata is usually harmless once the old plugin is inactive

Inactive plugin metadata may remain in the database without affecting frontend output.

It can be cleaned later after the new system has been validated.

Do not combine:

migration
+
cleanup
+
database optimization

into one irreversible operation unless there is a compelling reason.

Serialized data needs special care

Some plugin settings may be stored as PHP-serialized values.

A serialized value contains structural information, including string lengths.

Naively changing text inside it can corrupt the structure.

For the detailed problem, see Why Serialized Data Breaks Naive WordPress Migrations.

Do not use naive SQL replacement on serialized settings

A command conceptually similar to:

UPDATE wp_options
SET option_value =
REPLACE(option_value, 'old', 'new');

can damage serialized values when replacement lengths differ.

Use serialization-aware migration methods where serialized structures may be present.

WP-CLI can help with controlled database work

WP-CLI search-replace is serialization-aware and useful for appropriate database replacement operations.

That does not mean every SEO migration should be implemented as search-and-replace.

Field mapping remains preferable when the source and destination data models differ.

Search-replace and field conversion solve different problems

Search-replace answers:

Where does this value occur,
and how should it change?

SEO field migration answers:

What does this source field mean,
and where does that meaning belong
in the destination system?

The second problem is semantic.

Use plugin-native importers when appropriate

If the destination SEO plugin provides an importer for the exact source plugin and version family you are using, evaluate that before writing a custom converter.

A native importer may already understand:

• field names;
• value transformations;
• robots semantics;
• taxonomy metadata;
• global settings;
• schema mappings.

But “import completed” should still be followed by verification.

Never assume the importer covers every field

Read its documentation.

Determine what it migrates and what it intentionally ignores.

A tool may import:

titles
descriptions
focus keyphrases

while leaving:

schema
redirects
social metadata
global templates

untouched.

Run the importer on staging first

After import, compare representative content across several categories.

Do not test only the homepage and declare victory.

Build a representative test set

Include examples such as:

• homepage;
• normal post;
• normal page;
• custom post type;
• category archive;
• tag or custom taxonomy archive;
• page with custom SEO title;
• page with custom description;
• page with custom canonical;
• page with noindex;
• page with custom social image;
• page with special schema;
• redirected legacy URL.

Compare source and destination metadata

Create a validation table:

URL
Source title
Destination title
Source description
Destination description
Source canonical
Destination canonical
Source robots
Destination robots

This makes differences visible.

Not every difference is an error

The destination plugin may intentionally render metadata differently.

For example, title separators or whitespace may differ while the underlying meaning remains correct.

Classify differences as:

equivalent
intentional improvement
unexpected
broken
requires review

Compare rendered HTML before and after

Database comparison alone is not sufficient.

The real SEO output is what reaches the browser and crawler.

Inspect the page source for:

• title element;
• meta description;
• canonical tag;
• robots metadata;
• Open Graph tags;
• social metadata;
• structured data.

Example output comparison

Before:

<title>Custom SEO Title | Example</title>

<meta name="description"
      content="Custom description">

<link rel="canonical"
      href="https://example.com/page/">

<meta name="robots"
      content="index,follow">

After migration, verify that the new system produces the intended equivalent.

Check for duplicate metadata

During transition, two SEO systems may both output tags.

You could accidentally render:

<meta name="description" content="Old description">
<meta name="description" content="New description">

or multiple canonical tags.

That is not a charming display of redundancy. It means ownership of the metadata is unclear.

Only one system should own each output layer

During the final production configuration, establish a clear owner for:

• title output;
• meta descriptions;
• canonicals;
• robots directives;
• social metadata;
• schema;
• XML sitemaps;
• redirects.

Some responsibilities can be split intentionally, but overlapping output should not happen accidentally.

Do not deactivate the source plugin too early

A safer sequence is:

inventory source
↓
backup
↓
clone to staging
↓
install destination
↓
import or convert
↓
validate stored values
↓
validate rendered output
↓
resolve unsupported fields
↓
prepare production migration
↓
switch ownership
↓
verify again

Test the destination plugin without creating duplicate frontend output

How this is achieved depends on the plugins involved.

On staging, you may temporarily need to control which system outputs metadata while inspecting stored migration results.

The important requirement is that the final production page does not emit conflicting SEO tags.

Watch for database prefixes and multisite

Custom migration scripts should not assume the database prefix is:

wp_

WordPress installations can use another prefix.

Multisite adds additional complexity because content and options may be distributed across site-specific tables.

Use WordPress APIs instead of hardcoded table names where practical

Application APIs reduce unnecessary assumptions about the environment.

If direct database work is required, use the WordPress database abstraction correctly and understand the schema first.

The wpdb class reference documents WordPress’s database access layer.

Escape and sanitize migration data appropriately

Migration scripts are not exempt from data handling rules simply because the source values already exist in WordPress.

Understand what the destination expects.

A title, URL, image reference and serialized settings object are different data types and should not all be processed identically.

WordPress provides guidance on sanitizing data and escaping output.

Be careful with HTML entities

An SEO title containing:

Design & Development

may exist in storage or output with different encoding depending on the context.

Do not repeatedly encode already encoded values and end up with visible:

&

in search-facing metadata.

Check Unicode and international content

Sites may contain:

• accented characters;
• non-Latin alphabets;
• emoji;
• multilingual metadata;
• language-specific templates.

Test representative international content after migration.

Multilingual plugins add another layer

On multilingual sites, SEO metadata may be stored separately for each translated content object or integrated through translation-specific plugin behavior.

Verify:

• each language;
• translated titles;
• translated descriptions;
• canonicals;
• hreflang output;
• translated taxonomy metadata;
• language-specific sitemaps.

Do not infer hreflang behavior from ordinary metadata migration

Hreflang may be generated by a multilingual plugin rather than the SEO plugin itself.

Determine which system owns that output before changing anything.

Check WooCommerce and other integration metadata

E-commerce sites may generate SEO information from:

• product data;
• product categories;
• structured product information;
• plugin integrations;
• theme templates.

Test product pages and product archives separately from ordinary Posts.

Check attachment and media behavior

SEO plugins may differ in how they handle:

• attachment pages;
• media redirects;
• image metadata;
• social images.

If the old system redirected attachment URLs and the new one does not, changing plugins may alter crawlable URL behavior even though no post metadata changed.

Check breadcrumbs separately

Breadcrumbs may depend on:

• taxonomy configuration;
• primary categories;
• plugin-specific metadata;
• theme integration;
• schema output.

If the old SEO plugin provided breadcrumbs, determine what will replace them before deactivation.

Primary taxonomy selections may be plugin-specific

Some SEO systems allow an editor to designate a primary category or taxonomy term.

That selection may affect:

• breadcrumbs;
• schema;
• canonical decisions;
• content presentation.

If the destination plugin does not support the same concept, decide how those values should be handled.

Check site-level verification codes

An SEO plugin may output verification tags for services such as search platforms or other webmaster tools.

When switching plugins, determine whether those codes are:

• still required;
• managed elsewhere;
• being migrated;
• about to disappear with the old plugin.

Do not duplicate verification tags unnecessarily

If verification is already handled through DNS or another system, the SEO plugin may no longer need to output the tag.

Migration is a useful time to document ownership rather than blindly reproducing every historical setting.

Review robots.txt ownership

Some SEO plugins modify or virtually generate robots.txt behavior.

Check whether the source system currently contributes directives and whether the destination system will do the same.

Google documents robots.txt behavior in its robots.txt documentation.

robots.txt and meta robots are different

Do not treat:

robots.txt crawling rules

as equivalent to:

meta robots indexing directives

A migration may affect one without affecting the other.

Check XML sitemaps after the switch

When the destination system becomes active:

• open the sitemap;
• verify it returns successfully;
• inspect child sitemaps;
• check important URLs;
• check excluded URLs;
• verify canonical host and protocol;
• look for staging URLs.

TheOneWP’s XML Sitemap can control sitemap output when TheOneWP becomes the site’s SEO system.

Check canonical URLs after the switch

Inspect representative pages for:

<link rel="canonical" href="...">

Verify:

• correct domain;
• correct protocol;
• correct path;
• intentional cross-canonicalization;
• absence of duplicate canonical tags.

Check robots directives after the switch

Inspect pages that should be indexed and pages intentionally excluded from indexing.

Do not verify only one side.

Check metadata on paginated archives

Archive pagination can expose differences between SEO systems.

Review representative:

/category/example/
/category/example/page/2/

and equivalent custom archives if the site uses them.

Check search and 404 pages

SEO plugins may handle non-standard page types differently.

Verify whether search-result pages, 404 responses and other special contexts produce appropriate metadata.

Preserve URLs unless the migration intentionally changes them

Switching SEO plugins does not normally require changing post slugs or permalink structure.

A metadata migration and a URL migration are separate operations.

Avoid combining them unless there is a planned reason.

If URLs must change, treat that as its own migration

When URLs are changing too, you now need to manage:

• redirects;
• internal links;
• canonical URLs;
• sitemaps;
• external references;
• analytics continuity.

Use How to Migrate WordPress URLs Safely for that separate process.

Do not change SEO plugin, domain and site architecture simultaneously if you can avoid it

Consider this deployment:

new SEO plugin
+
new domain
+
new permalink structure
+
new theme
+
new content architecture
+
new hosting

If organic visibility changes, identifying the cause becomes unnecessarily difficult.

Separate variables where practical

A controlled sequence is easier to validate:

establish baseline
↓
migrate SEO system
↓
verify
↓
monitor
↓
perform unrelated changes separately

The broader planning principles are covered in Planning a WordPress Site Migration: a Checklist.

Create a pre-migration SEO baseline

Before changing plugins, capture representative output.

For important URLs, record:

HTTP status
title
meta description
canonical
robots
Open Graph
schema
sitemap inclusion

This gives you something concrete to compare after migration.

Export metadata where possible

If the source plugin offers an export feature, retain an export before migration.

A structured export can provide:

• additional backup;
• easier auditing;
• field discovery;
• manual recovery;
• comparison data.

Database exports are useful too

A database backup preserves the original state even when the plugin does not provide a dedicated SEO export.

WP-CLI provides wp db export for command-line database exports where WP-CLI is available.

Count populated fields before migration

Counts are useful validation signals.

Suppose the source contains:

4,812 custom SEO titles
4,201 meta descriptions
83 custom canonicals
217 noindex overrides

After migration, destination counts should be explainable.

They do not necessarily need to match exactly if transformation rules differ, but unexplained losses deserve investigation.

Use checksums or snapshots for high-value migrations

For large sites, you can create structured before-and-after exports containing:

post ID
URL
field type
normalized value

Then compare the datasets programmatically.

This catches differences that manual spot checks can miss.

Manual sampling is still necessary

Automated comparison can tell you that values match.

It cannot always tell you whether the values make sense.

Combine:

automated validation
+
representative manual inspection

Prioritize high-value pages

For production validation, begin with pages that matter most to the site.

Examples include:

• homepage;
• high-traffic landing pages;
• important commercial pages;
• top organic entry pages;
• major category archives;
• high-value products;
• content with custom canonicals or robots rules.

Do not assume a successful database migration means successful SEO output

The database can look perfect while frontend metadata remains wrong because:

• the destination plugin ignores the field;
• a global template overrides it;
• another plugin outputs competing tags;
• the theme outputs metadata too;
• caching serves stale HTML.

Clear relevant caches after migration

Depending on the site, clear:

• page cache;
• object cache;
• server cache;
• CDN cache;
• plugin caches.

Otherwise you may inspect old metadata and incorrectly conclude that the migration failed.

View the raw HTML

Do not rely solely on browser-rendered text.

Inspect the document head and confirm which system actually produced the SEO output.

Check HTTP headers too

Some indexing directives can also be delivered through HTTP headers such as:

X-Robots-Tag

A correct meta robots tag does not override an unexpected server-level indexing directive.

Google documents the relationship in its robots meta tag and X-Robots-Tag documentation.

Monitor Google Search Console after migration

After the production switch, monitor relevant reports in Google Search Console.

Watch for unexpected changes involving:

• indexing;
• sitemaps;
• canonical selection;
• crawl errors;
• structured data;
• important URLs.

A plugin migration does not necessarily produce immediate search changes, so monitoring should continue beyond launch day.

Do not interpret every ranking fluctuation as migration failure

Search visibility changes for many reasons.

Use technical evidence first.

Ask:

Did titles change?
Did canonicals change?
Did robots change?
Did URLs change?
Did sitemap inclusion change?
Did schema disappear?
Did important pages become unavailable?

Those questions are more actionable than staring accusingly at a ranking graph.

Keep the old plugin available during the validation window when practical

You may deactivate the source plugin once the destination system owns the frontend output, but avoid deleting the plugin and its data immediately if doing so would make rollback harder.

The exact strategy depends on how the source plugin handles uninstall cleanup.

Check uninstall behavior before deleting the source plugin

Some plugins preserve data when deleted.

Others may provide a cleanup option.

Understand the behavior before pressing Delete.

The red button remains remarkably committed to doing exactly what it says.

Do not clean old SEO metadata during initial validation

Old metadata can be removed later if:

• the new system is stable;
• the migration is verified;
• rollback is no longer required;
• you understand which fields are obsolete.

Database cleanup should be a separate operation

This separation makes failures easier to diagnose:

migration
↓
verification
↓
monitoring
↓
cleanup

Moving to TheOneWP SEO Meta

When TheOneWP becomes responsible for page-level SEO metadata, its SEO Meta module should become the intended owner for the fields it manages.

Before switching production output:

• inventory existing metadata;
• determine which values need conversion;
• test the destination fields;
• verify representative posts and pages;
• check custom post types;
• check taxonomy archives;
• inspect final HTML;
• disable overlapping output from the previous SEO system.

Do not run competing metadata systems indefinitely

Keeping two SEO plugins active “just in case” can produce:

• duplicate descriptions;
• duplicate canonicals;
• conflicting robots directives;
• multiple sitemap systems;
• competing schema output;
• confusing admin interfaces.

Use staging and backups for safety, not permanent metadata competition.

Coordinate SEO Meta with XML Sitemap

If TheOneWP becomes the SEO owner, XML Sitemap should be reviewed alongside page-level metadata.

The sitemap should reflect the intended indexing strategy after migration.

For example:

important canonical page
→ included

redirected old URL
→ excluded

intentional noindex archive
→ normally not promoted as an indexable sitemap URL

Coordinate SEO Meta with Redirect Manager

If the previous SEO plugin also managed redirects, moving page metadata alone is not enough.

Redirect Manager can take ownership of redirects separately.

Document that transfer explicitly.

A practical SEO plugin migration workflow

1. Inventory current SEO plugin

2. Record plugin version

3. Create full backup

4. Export SEO data if possible

5. Clone site to staging

6. Record baseline metadata

7. Identify source storage

8. Identify destination storage

9. Build field mapping

10. Classify unsupported fields

11. Test native importer if available

12. Build custom conversion only if needed

13. Migrate a small sample

14. Compare database values

15. Compare rendered HTML

16. Test canonicals

17. Test robots directives

18. Test social metadata

19. Test schema

20. Test taxonomy archives

21. Test custom post types

22. Test homepage

23. Test redirects

24. Test XML sitemaps

25. Resolve discrepancies

26. Run complete staging migration

27. Validate field counts

28. Review high-value URLs

29. Prepare production backup

30. Run production migration

31. Switch metadata ownership

32. Clear caches

33. Crawl representative pages

34. Verify sitemap

35. Monitor Search Console

36. Retain rollback path

37. Remove obsolete data later

Common SEO migration mistakes

Installing the new plugin and immediately deleting the old one

This can remove access to source configuration before you know whether it migrated.

Migrating only titles and descriptions

Canonicals, robots, schema, social metadata and redirects may matter too.

Copying raw database values without understanding them

Equivalent concepts may use different representations.

Guessing metadata keys

Storage implementations can change between plugin versions.

Testing only the homepage

The homepage tells you almost nothing about taxonomy metadata, custom post types or page-level overrides.

Leaving both SEO systems outputting metadata

Duplicate tags make ownership ambiguous.

Deleting old metadata immediately

This removes an easy rollback source before the migration has proved itself.

Ignoring redirects

The source SEO plugin may have been managing them.

Ignoring XML sitemaps

The destination plugin may expose a different URL set.

Ignoring serialized settings

Naive database manipulation can corrupt structured values.

Combining the migration with a redesign and domain change

Too many simultaneous variables make problems harder to diagnose.

SEO field migration checklist

• Create a verified backup.
• Use staging first.
• Record source plugin and version.
• Inventory post-level SEO fields.
• Inventory taxonomy metadata.
• Inventory global SEO settings.
• Inventory redirects.
• Inventory sitemap configuration.
• Inventory schema settings.
• Inventory social metadata.
• Record a representative pre-migration baseline.
• Verify source storage keys.
• Verify destination storage keys.
• Create an explicit field mapping.
• Identify fields without equivalents.
• Test a native importer where available.
• Use WordPress APIs where appropriate.
• Handle serialized data safely.
• Use batches for large sites.
• Log migration results.
• Keep source data during validation.
• Compare field counts.
• Test Posts.
• Test Pages.
• Test custom post types.
• Test taxonomy archives.
• Test the homepage.
• Test custom canonicals.
• Test index/noindex overrides.
• Test social images.
• Test schema output.
• Test redirects.
• Test XML sitemaps.
• Check for duplicate metadata.
• Clear caches.
• Inspect rendered HTML.
• Inspect relevant HTTP headers.
• Review high-value URLs manually.
• Monitor Search Console.
• Clean obsolete metadata only after validation.

Related guides

• Planning a WordPress Site Migration: a Checklist
• How to Migrate WordPress URLs Safely
• Why Serialized Data Breaks Naive WordPress Migrations
• WordPress Canonical URLs Explained
• What Is an XML Sitemap, and Why Does It Matter?
• WordPress Custom Post Types and SEO

Final recommendation

Migrating SEO fields between WordPress plugins should be treated as a data migration, not as a plugin installation task.

Start by identifying what the current SEO plugin actually controls. Separate post metadata from taxonomy and global configuration, document redirects and sitemap behavior, and create a clear mapping between source and destination fields.

Use a staging environment, preserve a recoverable backup and test representative content before touching production. When possible, use a documented native importer. When custom conversion is required, use verified field names, WordPress APIs and serialization-aware tools rather than blind database replacement.

Most importantly, verify the final output rather than trusting the database or an “Import complete” message. Check titles, descriptions, canonicals, robots directives, social metadata, schema, redirects and XML sitemaps in the rendered site.

When migrating toward TheOneWP, SEO Meta can become the page-level metadata owner, while XML Sitemap and Redirect Manager cover related sitemap and redirect responsibilities.

Keep the previous data available until the new configuration has been validated and monitored. Cleanup comes afterward.

A successful SEO plugin migration is not one where the importer finishes without errors. It is one where the intended search-facing signals remain correct after the old plugin is gone.