Choosing Between WordPress SEO Plugins
Every SEO plugin does the same four jobs. The difference that matters is how much of your site's metadata ends up locked inside plugin-specific database keys.
The decision is not which plugin: every option covers the same four jobs. What separates them is how much of your metadata ends up in plugin-specific database keys, and how hard that is to undo. Pick on lock-in and interface, not on feature counts.
The four jobs
Strip the marketing away and an SEO plugin does these things:
| Job | What it means | Do you need it? |
|---|---|---|
| Title and description templates | Patterns like %title% — %sitename%, editable per page |
Yes. This is the core value |
| XML sitemap | A crawlable index of your live URLs | Yes, though WordPress core ships a basic one |
| Canonical and robots meta | Declares the preferred URL, and what not to index | Yes, particularly on archives and paginated lists |
| Structured data | Article, FAQPage, Breadcrumb and similar markup |
Useful, and easy to get wrong |
| Redirect manager | Maps old URLs to new ones after a slug change | Only if you rename URLs often |
| Content analysis | Readability and keyword scores as you write | No. It measures a proxy, not the thing |
| Internal link suggestions | Proposes links between your posts | Occasionally helpful, never authoritative |
| Local and video sitemaps | Niche markup for shops and media sites | Only for those cases |
The first four are the ones worth paying attention to. Note that WordPress has generated a sitemap at /wp-sitemap.xml since 5.5, so "it gives you a sitemap" is not a differentiator any more, only "it gives you a better one".
Lock-in is the real cost
This is the part that surprises people two years in. Your titles, descriptions, canonical overrides and noindex flags are not stored in a neutral field. They live in wp_postmeta under keys the plugin owns, like _yoast_wpseo_title or _aioseo_description. Deactivating the plugin does not delete them, but nothing reads them either, so every page silently falls back to its default title.
Three practical consequences:
- Switching is a migration, not a swap. Run the new plugin's importer while the old one is still installed, verify a sample of pages, and only then remove the old plugin properly, as in deleting a WordPress plugin completely.
- Never run two at once. Two plugins both emit a canonical tag and a robots meta tag. Search engines get contradictory instructions, and you get the symptoms described in why a site is not showing in Google.
- The bigger the site, the higher the switching cost. On thirty pages, redoing metadata by hand is an afternoon. On three thousand, it is a project.
If you want to minimise lock-in, keep templates generic and override titles only where the default genuinely reads badly. Metadata you never customised costs nothing to migrate.
Matching the plugin to the site
- A brochure or portfolio site. Core's sitemap plus a small plugin for titles and descriptions is plenty. Do not install a suite that adds a dashboard, a wizard and a weekly email for eight pages.
- A content site or blog. This is where a full plugin earns its place: bulk editing of titles, per-archive noindex control, and breadcrumb markup. Content scores are the least useful part of it.
- A store. Product and category metadata, plus product structured data, matter more than anything else. Check that the plugin understands WooCommerce archives rather than treating them as generic listings.
- A headless or custom front end. Skip the suites. They render tags into a theme you are not using. Read the fields you need through the WordPress REST API and emit the markup yourself.
- A site with a developer on it. Templates, canonicals and sitemaps are perhaps eighty lines of PHP in a site-specific plugin. That is a legitimate option, and it has zero lock-in.
What no SEO plugin does
Being clear about this saves money:
- It does not write content. A green score on a thin page is still a thin page.
- It does not build links. Nothing installed on your own server can.
- It does not make the site fast. Core Web Vitals are a separate problem, covered in how to speed up a WordPress site.
- It does not fix crawl blocks above WordPress. A
Disallowin a server-levelrobots.txt, an HTTP password, or a staging site left indexable are all outside its reach. - It does not find your broken links unless it ships a crawler, and most do not. Use the approach in finding and fixing broken links.
Configure the four things that matter
After installing, per how to install a WordPress plugin, ignore the setup wizard's enthusiasm and set these:
- Title template. Decide whether the site name belongs in every title. On a long-tail content site it eats characters that could describe the page.
- Archive indexing. Author archives on a single-author site and date archives on most sites are duplicate listings. Noindex them.
- Canonical behaviour. Leave it automatic. Manual canonicals are for genuine duplicates, and getting one wrong deindexes a page, as in fixing canonical URLs.
- Sitemap contents. Exclude what you noindexed. A sitemap that lists noindexed URLs is a contradiction crawlers report back to you.
Common mistakes
- Installing a second plugin for one feature. Redirects, analytics and schema each tempt you into a second SEO plugin. Take the feature from a single-purpose plugin instead, or from the suite you already run.
- Treating the content score as a target. Keyword density stopped being a ranking factor long before these scores existed. Write for the reader, then check nothing is technically broken.
- Letting the wizard enable everything. Breadcrumbs the theme does not render, social meta duplicating what the theme already emits, and RSS footers nobody sees all add markup without adding value.
- Deactivating instead of migrating. The metadata stays, the output stops, and titles revert overnight across the whole site.
- Ignoring the plugin's own performance cost. Suites that run analysis on every admin page load make editing slow. Measure it, as in speeding up the WordPress admin.
Verify
View source on a published post and confirm exactly one <title>, one rel="canonical" and one robots meta tag. Load /wp-sitemap.xml or the plugin's sitemap URL and check it returns your live pages and nothing you marked noindex. Then use Search Console's URL inspection on one important page to see the canonical Google actually chose. If that differs from yours, fix it before writing anything new. The rest of the technical baseline is in the WordPress SEO checklist.
Frequently asked
- No. Both will output a canonical tag, a robots meta tag and a sitemap, and search engines see the conflict rather than the intent. Deactivating one is not enough either, because its metadata stays in the database.
- No. It removes technical obstacles and makes metadata editable. Rankings come from content that answers the query and from other sites linking to it, neither of which a plugin produces.
- They stay in the database under the old plugin's meta keys and stop being read. Most plugins ship an importer for the popular alternatives, so run it before deleting anything.