Switching SEO plugins guide
Plan an SEO Plugin Migration Across Client Sites
Stage a portfolio switch through an inventory, a pilot on the least typical sites, per-site acceptance checks, and a recovery decision recorded before each switch.
On this page
Treat a portfolio migration as one short procedure run on each site, not as one bulk job. Inventory how the sites differ, pilot on the least typical ones, accept each site against written checks, and record before every switch how you would recover it. Schedule by batches with room for exceptions rather than promising a completion date, because the sites that differ from the pattern set the pace.
The single-site procedure lives in How to Switch SEO Plugins With a Verification Plan. This guide covers what changes when you run it many times.
Inventory source differences
Build one sheet with a row per site before you schedule anything. The columns that change the work are:
| Column | Why it matters |
|---|---|
| Source plugin and version | Decides which fields and term data an import can read |
| Term SEO in use | SEOPress, The SEO Framework, and All in One SEO term data is re-entered by hand |
| Redirect count and rule types | Pattern, case-insensitive, and conditional rules need conversion |
| Custom or hand-written schema | Not imported from any source |
| SEO plugin content blocks | May stop rendering when the plugin is deactivated |
| Sitewide rules that differ from defaults | Only the separator and homepage title and description can import (none from All in One SEO); the rest are manual settings |
| Verification method | A meta tag printed by the old plugin stops with it |
| Staging available, backup restore tested | Without both, the site is not ready |
| Client contact and change window | Who approves, and when the switch can happen |
WP-CLI can gather much of this from your workstation. Its configuration handbook, checked September 27, 2026, describes named aliases such as @staging with their own SSH and path settings, alias groups that combine several aliases under one name, and the --url parameter that selects a site in a multisite network. Its guide to running commands remotely, checked September 27, 2026, runs one command against such a group. With aliases defined, an inventory pass looks like this:
wp @client-a plugin list --status=active --fields=name,version
wp @client-a db query "SELECT COUNT(*) FROM wp_termmeta WHERE meta_key LIKE 'rank_math%'"
wp @client-a db query "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%application/ld+json%'"Adjust the table prefix per site. Once WP Visibility is installed on a staging copy, wp @client-a-staging visibility import yoast --dry-run adds the number of posts each import would change. In version 2.10.3 the import finds posts by the source’s title field (for Yoast, _yoast_wpseo_title), except All in One SEO, which it reads from its own table. A post that has a custom description or noindex setting but no title field is therefore not counted or imported; add a count of those to the sheet. One license key covers every site, client sites included; see Use the Same License on Another Site.
Choose the pilot
Pick two or three pilot sites that are the least typical in the portfolio, not the easiest. Useful pilots include:
- One site per source plugin you have.
- The site with the most redirects, or the most pattern rules.
- A site whose source has no term import, with many categories.
- A site with custom schema or SEO plugin blocks.
- A store or multisite network, if you manage one.
Run the full procedure on each pilot and time every step. The pilot’s purpose is to turn unknowns into worklist items and time estimates for the rest of the portfolio. Anything the pilot reveals, such as a separate X image policy or an old verification tag, becomes a column in the sheet.
Run the per-site transfer
Every site gets the same sequence, and every step leaves a record:
- Back up and prove the restore. WordPress’s backup documentation, checked September 27, 2026, says a typical site needs both the database and the files to be restored. Restore once to staging.
- Capture the baseline. Save the rendered head of one URL per page type, the redirect export with its row count, the settings screenshots, and the structured data on one URL per template.
- Rehearse on staging. Install WP Visibility, run the dry run, run the live import, and apply the settings worklist from Audit the Sitewide SEO Defaults a Metadata Import Leaves Behind.
- Move redirects with the conversion and testing steps in Convert Redirect Exports Between SEO Plugins.
- Accept the staging site against the checks below.
- Switch production in the agreed window: fresh backup, repeat the steps that passed, deactivate the old plugin, clear caches.
- Accept production against the same checks.
The SEO import runs in batches of 200 posts from WP-CLI and skips posts whose values already match, so a run cut short can be started again safely, provided nobody edited imported values in between. The redirect import is per site, through the Redirects page or its REST route, and needs the Redirects module, which is off by default.
Per-site acceptance checks
A site is done when every check passes or has a recorded exception:
| Check | Pass condition |
|---|---|
| Sample output | Title, description, canonical, and robots match the baseline, or each difference is intended and noted |
| Indexing | The source’s noindex list and WP Visibility’s reconcile; see Check Noindex and Inherited Defaults After an SEO Plugin Switch |
| Redirects | Data rows in each file equal created plus skipped; test requests return the expected status and location |
| Term SEO | Sampled category and tag archives match, or were re-entered |
| Structured data | Each missing node has a decision |
| Content blocks | No SEO plugin block renders empty |
| Verification and sitemap | Verification codes present, sitemap submitted at /sitemap.xml |
| Client actions | Forms, checkout, and logins still work |
Keep the evidence (the diff files, test output, and screenshots) with the site’s record. It lets someone other than the person who ran the switch confirm what happened.
Track exceptions and recovery decisions
Keep an exception log with the site, the finding, the decision, and who approved it. Exceptions repeat across sites, so a decision made once can be applied again with the client’s agreement.
Before each production switch, write down which recovery route applies if acceptance fails:
| Route | What it does | Limit |
|---|---|---|
| Reactivate the old plugin | Its data was never changed by the import, so it resumes with its old values | Edits made in WP Visibility do not go back to it, and redirect rules added in WP Visibility stop firing once WP Visibility is deactivated |
| Restore the backup | Returns the whole site to the backup point | Loses orders, comments, and content created since; plan how to keep them |
| Fix forward | Correct the specific finding in WP Visibility | Needs someone available during the window |
For a store or a busy site, restoring an old database is often the last choice, so agree the route with the client in advance.
Hand off each site
Close each site with a short record for the client or the next person on the account: the switch date, the old and new plugin versions, the settings worklist with its outcomes, the exception log, and what to watch over the following weeks, such as indexing reports for the pages in the sample. There is no fixed period after which a migration is proven complete, so agree how long you will keep the old plugin’s data in place before anyone deletes it.
Move to the next batch when the current one is accepted, not when the calendar says so.