WordPress · Plugin, theme and core updates
A WordPress update can break SEO without breaking how the site looks. The homepage loads, posts render, and nobody notices that a caching plugin now serves noindex or that the theme dropped its canonical tags. Rankings fall two weeks later, and by then five more updates have shipped, so nobody knows which one caused it.
The fix is a habit: crawl before the update, crawl after it, and compare. This page covers what to check and how to confirm the site came through clean. For the general post-deploy method on any stack, see SEO QA.
What can go wrong after a WordPress update
Each layer of a WordPress site can change your HTML on update. The diagram shows where each layer sits between your browser view and what Googlebot receives.
The WordPress stack: every layer can rewrite your HTML
Only a crawl sees the HTML that leaves the bottom of this stack, the same HTML Googlebot sees.
| Update type | What breaks | Why it's easy to miss |
|---|---|---|
| SEO plugin (Yoast, Rank Math, AIOSEO) | Titles fall back to defaults, schema output changes, sitemap moves or disappears, archives flip to indexable | The post editor still shows your custom fields |
| Theme or parent theme | Second title tag printed, H1 removed or doubled, breadcrumbs dropped, canonical removed | Page looks identical in the browser |
| Page builder (Elementor, Divi) | Content moves into JavaScript, headings change level, images lose alt text | Visible text is unchanged |
| Caching or performance plugin | Stale noindex served from cache, lazy loading hides images from crawlers, minified JS breaks rendering | Logged-in admins bypass the cache |
| Security plugin (Wordfence, Solid Security) | New bot rules block Googlebot or AI crawlers, rate limits return 429 or 503 | Only bots see the block |
| WordPress core | Default sitemap re-enabled next to the plugin's, new attachment or feed behavior | Core auto-updates run silently |
The common thread: the admin view and the logged-in view hide almost all of these. Only a crawl sees what Googlebot sees.
What to check
Crawl the full site, but inspect one URL per template first, since updates break templates, not single posts. Then check the elements updates usually touch.
URLs to inspect first: / homepage, one post, one page, one /category/ archive, one /tag/ archive, one /author/ archive, one attachment URL, the sitemap, robots.txt, and one WooCommerce product if you run a store.
| Element | Expected after a clean update |
|---|---|
| Status code | Same as before, no new 404, 429 or 5xx |
| Meta robots | No new noindex on pages that were indexable |
| robots.txt | Unchanged, no new Disallow rules |
| Title tag | One per page, same text as before |
| Meta description | One per page, same text as before |
| Canonical | One per page, pointing to the same URL |
| H1 | Exactly one, same text |
| Structured data | Same schema types, still valid |
| Sitemap | Same URL, same URL count within a few percent |
| Rendered word count | Within a few percent of the previous crawl |
| AI crawler access | GPTBot, ClaudeBot and PerplexityBot still allowed |
| Tracking tags | GA4 and pixels fire once, not twice |
How to run the checks
- Crawl before updating. Run a full SiteAud!tLint audit of the live site and save it. This is your baseline.
- Update on staging first, if you have it. Crawl the staging site with the same settings. Turn on JavaScript Rendering if you use a page builder.
- Update one thing at a time. Batch updates make it impossible to tell which plugin caused a change.
- Clear every cache. Purge the caching plugin, any host cache and Cloudflare. Otherwise you crawl the old HTML and miss the problem.
- Crawl again with identical settings. Same start URL, same exclusions, same rendering mode, or the comparison shows false differences.
- Compare the two audits. Open Audit Comparison and review new issues first, then changed values.
- Spot-check manually. For anything flagged, open the URL logged out, view source, and confirm what the crawler saw.
For sites with WordPress auto-updates turned on, set Scheduled SEO Audits to run weekly so a baseline always exists.
How to identify the scope
A new issue on one URL is usually a content problem. The same issue on every URL of one type is a template problem, and that's what updates cause. Match the pattern of new issues to the layer that changed:
- Group new issues by URL pattern. If every /tag/ URL gained noindex, the cause is the SEO plugin's taxonomy setting. If every post lost its H1, it's the single post template.
- Match the pattern to the update. Posts only points to the theme's single.php or the page builder. Every URL points to the SEO plugin, a caching layer or a security rule. Bots only, with a normal browser view, points to the security plugin or Cloudflare.
- Count affected URLs. Audit Comparison shows how many URLs each new issue hits. A count that matches a template's total URL count confirms the scope.
- Check logged out. If the issue disappears when you're logged in, the cache or a bot rule is serving a different page to visitors.
How to validate the fix
A fix isn't done until a crawl shows the issue gone and nothing new in its place.
- Apply the fix: change the setting, roll back the plugin, or patch the child theme.
- Purge every cache again.
- Recrawl with the same settings as the baseline.
- Compare against the pre-update baseline, not the broken crawl. The goal is zero difference from the healthy state.
- Confirm three things: the new issue count is zero, the affected URL count is zero, and sitemap and word counts match the baseline.
- For noindex or robots.txt fixes, request reindexing in Search Console for a few key URLs. Recovery still happens on Google's schedule.
Rolling back: if a fix isn't obvious, roll the plugin back to the previous version, confirm with a crawl that the site matches the baseline, and report the bug to the plugin author before updating again.
Before and after example
/blog/post-b/ → canonical present
Posts with canonical: 340 / 340
/blog/post-b/ → canonical missing
Posts with canonical: 0 / 340
Downloadable checklist
Tick items as you go, then download the list as CSV for a spreadsheet or Linear ticket, or print it and save as PDF. Your ticks are included in the download.
Common mistakes
- Checking only the homepage. Updates usually break one template, like archives or single posts, while the homepage stays fine.
- Testing while logged in. Admins bypass page caches and security rules, so you see a different site than Googlebot does.
- Crawling before purging the cache. The crawl reads the old cached HTML and reports everything as healthy.
- Updating ten plugins at once. When something breaks, you can't tell which update caused it.
- Changing crawl settings between audits. Switching JavaScript rendering on for the second crawl creates false differences in word count and headings.
- Leaving auto-updates on with no baseline. Plugin auto-updates run silently. Without a scheduled audit, there's nothing to compare against when traffic drops.
- Trusting the SEO plugin's green light. It scores one post against one keyword and won't notice a theme printing a second title tag.