Skip to content
WP Visibility

Switching

Move to Another SEO Plugin

Your data stays in the database when WP Visibility is deactivated. Copy the redirects and settings the next plugin cannot read, check the new sitemap address, then deactivate.

Updated September 27, 2026

Docs

Deactivating WP Visibility leaves every title, description, canonical, indexing choice and redirect rule in your database. What you need to do before you switch is about the next plugin: check what it can import, copy what it cannot, and check whether the sitemap address changes. Deleting the plugin also keeps the data unless you turn on Delete all plugin data on uninstall first.

Where WP Visibility keeps your data

Data Where
Per-post SEO (search title, description, canonical, indexing, social fields, schema choice, per-post redirect) One post meta row, _wpvis, holding a serialized array. Values at their defaults are usually left out, and a post that never had SEO values set has no row.
The noindex flag A second post meta row, _wpvis_noindex, present only on posts set to Noindex individually.
Per-term SEO One term meta row, _wpvis.
Settings (templates, separator, verification codes, social defaults, schema identity, crawler policy) The wpvis_settings option.
A custom llms.txt body, the IndexNow key and other internal state The wpvis_state option.
Redirect rules and hit counts The {prefix}wpvis_redirects table, for example wp_wpvis_redirects.

Check what the next plugin imports

An importer has to know these keys. Look at the other plugin’s import options before you count on them, and if WP Visibility is not on its list, plan to re-enter values or copy them with a script. The keys inside _wpvis are title, description, canonical, noindex (1 noindex, -1 index, 0 or absent inherit), nofollow, noarchive, og_title, og_description, og_image_id, tw_title, tw_description, schema_type, schema_json and redirect.

There is no bulk export in the plugin. WP-CLI prints one post’s stored values, with defaults filled in, as key and value rows, and a shell loop turns that into a file with one line per post:

wp visibility get 123 --format=json
for id in $(wp post list --post_type=post,page --post_status=publish --format=ids); do
  echo "{\"id\":$id,\"wpvis\":$(wp visibility get "$id" --format=json)}"
done > wpvis-export.jsonl

To list the posts set to Noindex individually (post types noindexed in the Indexing section carry no flag):

wp post list --post_type=any --post_status=any --meta_key=_wpvis_noindex --meta_value=1 --fields=ID,post_title,url

Copy the redirects

Do not count on the next plugin reading the wpvis_redirects table unless its import options name WP Visibility. WP Visibility has a CSV import for redirects but no CSV export. Before deactivating:

  1. Open WP Visibility → Redirects and copy the rules into a spreadsheet as source,target,status; the table is searchable and pages 20 at a time. Or fetch them all in one request per hundred: GET /wp-json/wpvis/v1/redirects?per_page=100&page=1 with an administrator’s credentials.
  2. Note the rules with a regex tag; the next plugin may write patterns differently.
  3. Recreate them in the new plugin, then test the ten most visited from the Hits column.

The moment WP Visibility is deactivated the rules stop firing, and so does every per-post Redirect (301) to field. Have the replacements in place first.

Copy the settings

Screenshot or note the following, because none of it travels unless the new plugin’s import options name WP Visibility: the title separator and templates, the homepage title and description, the codes in the Site verification section, the default social image and X handle, the organization or person identity in the Schema section, the AI crawler policy and any custom llms.txt body, whether the IndexNow module is on, and the noindex choices in the Indexing section. Re-enter them in the new plugin before you deactivate WP Visibility, and compare the head of a post, a category and the homepage before and after.

The sitemap moves

While its Sitemaps module is on (the default), WP Visibility serves /sitemap.xml and turns off WordPress’s own /wp-sitemap.xml. When you deactivate, the WordPress sitemap can come back at its own address (WordPress turns it off when search engines are discouraged or a plugin disables it, per the WordPress 5.5 sitemap announcement, checked September 27, 2026), and the new plugin may publish its own at another one. If the address changes, submit the new one in Search Console and Bing Webmaster Tools, and remove the old one, once the new plugin is live: Submit Your Sitemap explains where.

Deactivate

  1. Activate the new plugin and finish its setup while WP Visibility is still active, or on staging. WP Visibility does not switch off its head output when another SEO plugin is active, so the two can print two sets of head tags; keep that window short.
  2. Deactivate WP Visibility on the Plugins screen. The menu disappears; the data stays.
  3. Check ten URLs in a private window: title, description, canonical, robots line, and the redirects you recreated.

Uninstall

Deleting the plugin from the Plugins screen keeps every option, meta row and table by default, so an accidental removal destroys nothing and a reinstall picks up where it left off.

To remove the data as well, turn on Delete all plugin data on uninstall in the Advanced section of the settings screen before deleting the plugin. That removes the settings, the SEO meta on posts and terms, the redirect table, the review queue’s proposals and the activity log, on every site of a network that opted in. There is no undo; take a database backup first. A network administrator can force the same for every site by setting the WPVIS_DELETE_DATA_ON_UNINSTALL constant to true in wp-config.php.

If you come back

Reactivate the plugin. Everything is where you left it unless you chose to delete it, and your license key is still saved: while the license is current it covers updates for any number of sites, and deactivating a site does not use anything up.