Check SEO Plugin Blocks Before You Deactivate the Plugin

Blocks that an SEO plugin added to your posts stay in the post content after you deactivate it, but three things can change separately: what visitors see, whether editors can still edit the block, and whether any structured data is printed for it. Find every such block, test one example of each on a staging copy with the plugin off, and convert the ones you need before switching production.

This guide covers content that depends on the old plugin. Metadata such as titles and descriptions is a different job, handled by the importer for your source, for example Migrate from Yoast SEO.

What a block leaves in your content

The WordPress Block Editor Handbook’s page on markup representation, checked September 27, 2026, shows that a block is stored as an HTML comment with its name and settings, plus whatever HTML the block chose to save. Its page on dynamic blocks, checked September 27, 2026, describes the two cases. Many dynamic blocks save only their attributes and build their markup on the server at display time. A block can also save an HTML version, and the handbook says that saved HTML is rendered if the block is deactivated or its render callback is removed.

So the likely outcomes differ by block:

In the editor, WordPress shows such a block as its Unsupported block, which the handbook’s Unsupported block reference, checked September 27, 2026, describes as “Your site doesn’t include support for this block.”

Structured data stops in both cases because the plugin that built it is no longer running. Yoast, for example, describes its FAQ and How-to blocks as adding structured data that integrates with its Schema.org graph (Yoast’s structured data blocks page, checked September 27, 2026). The visible questions can remain while that markup disappears.

These are the expected patterns. Your plugin’s version decides which case each block falls into, which is why the test below matters.

Inventory dependent content blocks

Run this on the site with WP-CLI. It lists every block that is not a WordPress core block, how many posts use it, and up to ten post IDs:

wp eval '
$types  = array_merge( get_post_types( [ "public" => true ] ), [ "wp_block", "wp_template", "wp_template_part" ] );
$ids    = get_posts( [ "post_type" => $types, "post_status" => "any", "numberposts" => -1, "fields" => "ids" ] );
$found  = [];
$walk   = function ( $blocks, $id ) use ( &$walk, &$found ) {
	foreach ( $blocks as $b ) {
		if ( $b["blockName"] && ! str_starts_with( $b["blockName"], "core/" ) ) {
			$found[ $b["blockName"] ][ $id ] = true;
		}
		$walk( $b["innerBlocks"], $id );
	}
};
foreach ( $ids as $id ) {
	$walk( parse_blocks( get_post_field( "post_content", $id ) ), $id );
}
foreach ( $found as $name => $posts ) {
	echo $name, "\t", count( $posts ), "\t", implode( ",", array_slice( array_keys( $posts ), 0, 10 ) ), "\n";
}
' > third-party-blocks.tsv

The list includes synced patterns and block theme templates and template parts saved in the database, where a breadcrumb or table of contents block often lives. Templates that exist only as theme files are not scanned. Keep the rows whose names start with your SEO plugin’s prefix; other plugins’ blocks are not affected by this switch. If your content uses shortcodes the old plugin documented, search for those too.

Capture frontend and editor behavior on staging

Use a staging copy with the same content. For each block name in your list, pick one post and do the following:

1. With the old plugin active, save the page’s HTML, a screenshot of the block area, and the JSON-LD on the page.
2. Open the post in the editor and screenshot the block.
3. Deactivate the old plugin on staging.
4. Reload the page. Save the HTML, the screenshot, and the JSON-LD again.
5. Open the post in the editor and record what it shows for the block.

Read the results with this table:

Record the plugin name and version with each result. A result from one release does not prove the behavior of another.

Why the metadata import leaves blocks alone

WP Visibility’s importer copies stored SEO fields: titles, descriptions, canonicals, social fields, and indexing choices. It does not read or rewrite post content, and 2.10.3 has no converter for another plugin’s blocks. It also has no FAQ or how-to block of its own, and it never generates FAQPage or HowTo structured data; those types print only if someone adds them, for example as custom JSON-LD in the Advanced field of a post’s Structured data panel. For a visible breadcrumb trail, it offers a shortcode rather than a block; see Add a Visible Breadcrumb Trail.

Other plugins document converters for their own destinations. Rank Math’s Yoast migration guide, checked September 27, 2026, describes converting Yoast FAQ and HowTo blocks to Rank Math’s blocks. That helps only if Rank Math is where you are going.

Choose a tested conversion or replacement

Convert while the old plugin is still active on staging, because that is when the editor still understands the block and can show its content in editable form. Then repeat on production just before the switch, or convert on production first and switch afterward.

WordPress’s Details block documentation, checked September 27, 2026, describes a summary that opens to reveal hidden content and a name attribute that groups several Details blocks so that opening one closes the others. The core Breadcrumbs block arrived in WordPress 7.0, according to the Make WordPress Core post on breadcrumb block filters, checked September 27, 2026.

After converting a post, repeat the capture: the visible text should match the original, and the editor should show ordinary core blocks. If you relied on FAQ or HowTo markup, read Google’s Retired Rich Results before deciding whether to rebuild it.

For many posts, convert the most visited ones by hand and leave rarely read posts until an editor next opens them, as long as their saved HTML still displays. Posts where the block area went empty cannot wait.

Checklist

• Every non-core block listed, including templates and synced patterns.
• One example of each block tested on staging with the plugin off.
• Blocks that render nothing converted before production deactivation.
• Structured data changes recorded and decided.
• Plugin version noted beside each test result.