Check for Newer Edits Before You Rerun an SEO Import

Do not rerun an SEO import on a site where anyone has edited titles, descriptions, or settings in WP Visibility since the first run until you know which of those edits the rerun would replace. In WP Visibility 2.10.3, a repeated import writes every non-empty source value that differs from the current one, and it has no option to choose fields. Take a backup, save a copy of the destination values, rehearse the rerun on a copy, and then either skip it or reapply the edits you want to keep.

This guide is for a second or interrupted import. The first-time sequence is in How to Switch SEO Plugins With a Verification Plan.

What a repeated import does

The importer never changes the source plugin’s data, so on a rerun it reads the same source values as the first time, unless someone has edited them in the old plugin since, and compares them with what WP Visibility stores now. The outcome depends on the field:

Only the mapped fields that the source has are written, so other fields on the same post, such as a schema choice you added, stay as they are. A source value that is set but does not survive translation or cleaning, such as a canonical that is neither a full http:// or https:// URL nor a path starting with /, or a title made only of variables the import removes, is written as empty and clears that WP Visibility field.

Two parts of the run behave differently from posts. On the first batch of the live run, every mapped term is written again with the same replace rule (only Yoast and Rank Math import terms), and the title separator, homepage title, and homepage description are replaced if they differ (All in One SEO imports no settings). The migration docs say it directly: running the import again after you have edited titles in WP Visibility puts the old values back, as in Migrate from Rank Math.

When a rerun is actually needed

Reruns usually come from one of three situations:

• The first import stopped partway. Batches that finished are written; later ones are not. A rerun from the settings screen or WP-CLI starts again from the beginning, and posts whose values already match are skipped, so it only fills the gap, unless someone has edited imported posts, terms, or settings in the meantime.
• People kept editing in the old plugin after the first import while both were active.
• New posts were added in the old plugin after the first run.

In the second and third cases, a rerun is the wrong tool if WP Visibility has also been edited, because it cannot tell a stale value from a newer one. Setting the few changed posts by hand is often safer.

Back up and record the current values

WordPress’s backup documentation, checked September 27, 2026, says a full restore of a typical site needs both the database and the files. Take that backup first. Then save the three places WP Visibility keeps imported values, so you can compare them before and after:

wp db export before-rerun.sql
wp db query "SELECT post_id, meta_value FROM wp_postmeta WHERE meta_key='_wpvis' ORDER BY post_id" --skip-column-names > wpvis-posts-before.tsv
wp db query "SELECT term_id, meta_value FROM wp_termmeta WHERE meta_key='_wpvis' ORDER BY term_id" --skip-column-names > wpvis-terms-before.tsv
wp option get wpvis_settings --format=json > wpvis-settings-before.json

Replace wp_ with the prefix that wp db prefix prints. The wp db export reference, checked September 27, 2026, also accepts --tables if you want a smaller file holding only the meta and options tables. A partial export is a record for comparison, not a site backup.

Preview the repeated operation

Start with the dry run on the live site. It writes nothing:

wp visibility import yoast --dry-run --user=admin

Read the count first. On a site where nothing has changed since the first run, it should be zero or close to it. Any posts it counts differ from their source values in at least one mapped field. The table shows up to ten of them with title and description before and after. A row whose title and description look identical differs in another field, such as a social title or the indexing choice.

The dry run does not cover terms or settings, and it shows ten posts at most. For the full picture, rehearse on a copy:

1. Restore before-rerun.sql onto a staging site, or clone production there.
2. Run the live import on staging.
3. Save the same three files on staging, named -after.
4. Compare:

diff wpvis-posts-before.tsv wpvis-posts-after.tsv
diff wpvis-terms-before.tsv wpvis-terms-after.tsv
diff wpvis-settings-before.json wpvis-settings-after.json

Each changed line in the post and term files is a post or term whose stored values the rerun would add, replace, or clear. The stored row is a serialized list, so open the two versions side by side to see which field moved. You now have the complete list of what production would lose.

Choose fields to preserve or reconcile

For each changed post or term, decide which value is correct, then pick one of these routes:

• Skip the rerun. If the gap is a handful of posts that were never imported, set them directly: wp visibility set 123 --title="..." --description="...". Nothing else is touched.
• Update the source first. If the old plugin is still active, change its value to the one you want to keep. The rerun then finds a match and leaves that field alone; the post is skipped when no other mapped field differs. This keeps the source and destination in agreement if you ever go back.
• Rerun, then reapply. Run the import, then restore the edits you listed. wp visibility set handles the search title, description, indexing, and canonical; restore social fields in the editor’s Social sharing panel, nofollow under Link following in its Indexing panel, and term titles, descriptions, and indexing on the term edit screen. Reapply the separator and homepage fields in General.

Whichever route you take, save the post and term rows again afterward and diff it against the version you decided on. The review queue does not stand between you and this operation: the import writes directly and does not create a proposal.

An illustrative example on garden.example: after the first Yoast import, an editor shortened ten product titles in WP Visibility. A new batch of blog posts was then written in Yoast. Rerunning would restore the ten long titles. Setting the new posts with wp visibility set from a list of their IDs avoids that.

Checklist

• Full backup taken and restorable.
• Destination values saved for posts, terms, and settings.
• Dry run count read, with non-zero counts explained.
• Rerun rehearsed on a copy and diffed.
• Every overwritten edit given a decision, and the final state checked with a second diff.

For where each value lives after the switch, see What WP Visibility Stores, and What Uninstall Removes.