Check Noindex and Inherited Defaults After an SEO Plugin Switch

An indexing setting has three possible states: an explicit noindex, an explicit index, and no choice at all, which means the page follows a site default. A plugin switch can keep the first, lose the second, and silently change what the third means, because the defaults belong to the old plugin’s settings. Record which state each important URL was in, import on staging, and check the robots tag each URL publishes afterward.

This is a robots test for a migration. For a page that is missing from search for other reasons, start with Keep a Page Out of Search, which explains how WP Visibility decides indexing. For the whole switch, use How to Switch SEO Plugins With a Verification Plan.

Why an absent value is a decision too

Google’s robots meta tag documentation, checked September 27, 2026, says that without a noindex rule a page may be indexed and shown in results. It lists restrictive rules such as noindex and nofollow, and says that when rules conflict, the more restrictive one applies. The same page notes that a URL blocked in robots.txt cannot have its indexing rules read at all.

So what reaches Google is the published tag, not the setting behind it. An “explicit index” choice only matters inside a plugin, where it overrides a type-wide or taxonomy-wide noindex. If the new plugin drops that override and you then noindex the whole type, the page leaves search, even though no one chose that for it.

How each source’s values import

This table describes WP Visibility 2.10.3 and how its importer reads each plugin’s stored values. “Inherits” means nothing is written, so the post or term follows WP Visibility’s own site rules in the Indexing section.

Nofollow follows the same pattern on posts where the source stores it. Directives such as noarchive, nosnippet, and preview limits are not imported from any source, and term settings come only from Yoast and Rank Math; SEOPress, The SEO Framework, and All in One SEO term robots values do not come across. The per-source detail is in the migration docs for Yoast and Rank Math.

Two rows need attention. A Yoast term, or a Rank Math post or term, that was explicitly set to index arrives as “inherits”, as does an All in One SEO post with default settings off and noindex unticked, so it is only safe while WP Visibility does not noindex that whole taxonomy or type. And a Rank Math term’s noindex only comes across when that term also has a custom Rank Math title.

Posts the import never finds

For Yoast, Rank Math, SEOPress, and The SEO Framework, the importer finds posts by their stored SEO title field (All in One SEO posts are found by their row in its own table). A post that had a noindex choice but no stored title field, usually because it never had a custom SEO title, is not visited, so its noindex does not come across and it becomes indexable under WP Visibility’s defaults. This is how a deliberately hidden page can end up back in search.

Compare the two lists after a staging import. For Yoast:

wp post list --post_type=any --post_status=publish --meta_key=_yoast_wpseo_meta-robots-noindex --meta_value=1 --field=ID | sort > source-noindex.txt
wp post list --post_type=any --post_status=publish --meta_key=_wpvis_noindex --meta_value=1 --field=ID | sort > wpvis-noindex.txt
comm -23 source-noindex.txt wpvis-noindex.txt

For Rank Math, build the first list from the serialized robots field instead (replace wp_ with your table prefix):

wp db query "SELECT post_id FROM wp_postmeta WHERE meta_key='rank_math_robots' AND meta_value LIKE '%\"noindex\"%'" --skip-column-names | sort -u > source-noindex.txt

That query includes drafts and private posts, which the WP Visibility list leaves out, so expect a few extra IDs. Apart from those, every ID comm prints was noindexed in the source and is not noindexed in WP Visibility. Set them explicitly:

for id in $(comm -23 source-noindex.txt wpvis-noindex.txt); do wp visibility set "$id" --noindex=1; done
wp visibility flush

In 2.10.3, wp visibility set does not clear the cached sitemap; flush does, so the sitemap is rebuilt without those posts on its next request. Check explicit index values too (Yoast 2, The SEO Framework -1) if you plan to noindex any whole post type. _wpvis_noindex only marks noindex, so confirm those posts with wp visibility get <id>, where an explicit index shows noindex as -1.

Match the defaults the import leaves behind

No importer carries the source’s sitewide robots defaults. Screenshot the old plugin’s settings for post types, taxonomies, author archives, date archives, and paginated pages, and compare them with WP Visibility’s starting values in WP Visibility → Settings → Indexing:

Where the old plugin differed, change the setting and write down why. For example, if the old site noindexed tag archives but one tag was set to index, tick tags under Noindex these taxonomy archives and then set that tag to Index on its edit screen, because the import did not keep its override.

Build a small test set on staging

Where your site has no example of a state, create one. On a staging copy with the old plugin active, add disposable posts and terms:

1. A post set to noindex, with a custom SEO title.
2. A post set to noindex, with no custom SEO title.
3. A post explicitly set to index, in a post type you intend to noindex.
4. A post left on the default.
5. A category explicitly set to index, and a tag set to noindex.

Record each one’s robots tag, run the import, apply your Indexing settings, and record them again. Only a result that matches the intent you wrote down counts as a pass.

Inspect the public robots output

Check the tag and the response header for every URL in your sample:

curl -s https://garden.example/private-offer/ | grep -io '<meta name=.robots[^>]*>'
curl -sI https://garden.example/private-offer/ | grep -i '^x-robots-tag'

If Settings → Reading discourages search engines, WordPress adds noindex to the robots tag (checked September 27, 2026) and WP Visibility leaves it in place, so no per-page Index changes it. That is expected on staging and a problem in production. Finally, run wp visibility flush, because in 2.10.3 neither the import nor saving the Indexing settings clears the cached sitemap, then open the sitemap and confirm that the noindexed sample is absent. In 2.10.3 the sitemap also leaves out every post type and taxonomy you noindex in Indexing, including items set to Index, so check those by their robots tag instead.

Checklist

• Intent recorded for each sample URL: noindex, index, or default.
• Source and WP Visibility noindex lists compared, gaps set by hand.
• Sitewide Indexing settings matched to the old defaults, with reasons noted.
• Explicit index overrides restored wherever a whole type or taxonomy is noindexed.
• Robots tag, header, and sitemap checked on production after the switch.