← Back to the blog

WordPress Update SEO Checklist: What to Check After Updating

A WordPress update SEO checklist is a short list of things to verify on the live site after core, a theme or a plugin has been updated: robots meta, titles, canonicals, the sitemap, robots.txt and tracking tags. You check SEO after a WordPress update because updates replace files and migrate settings, and the front end usually looks identical while the markup underneath has changed.

This article covers the hour after an update. For the settings worth watching all year, see WordPress SEO monitoring, and for a domain or platform move, the website migration SEO checklist.

SEO plugin updates: title templates, robots defaults and the sitemap

Yoast SEO and Rank Math build titles from templates with variables. Yoast writes them as %%title%% %%sep%% %%sitename%%, Rank Math as %title% %sep% %sitename%. When a template gets reset, or a variable stops resolving, the result shows up in the <title> of every URL of that post type at once. A title that reads literally "%%sitename%%", or has lost the page name, is the thing to look for.

The same plugins own the robots meta for archives, tags, author pages and media attachment URLs. A settings migration during a major version can change those defaults, so compare the <meta name="robots"> on one tag or author archive with what it was before.

Then open the sitemap index. Both plugins serve it at /sitemap_index.xml, and each has a switch that turns it off (in Rank Math the Sitemap module, in Yoast the XML sitemaps feature). If the index returns a 404, or a post type has vanished from it, Search Console will keep reading the old submission and report errors later. Losing sitemap entries is covered in more depth in pages removed from the sitemap.

Theme updates that overwrite header.php

Updating a theme replaces its files with the vendor's copy. Anything edited directly in the parent theme, rather than in a child theme, is gone. On many older sites that includes a GTM snippet pasted into header.php or a verification meta tag added by hand.

The more serious failure is a missing wp_head() call. Plugins inject their output through that hook, so if a customised header template no longer calls it, the SEO plugin's title, description, canonical and robots tags disappear together, along with anything Site Kit or a GTM plugin adds. The page still renders. View the source, search for the canonical, and if it isn't there, check whether the SEO plugin's comment block is missing too.

Page builder updates and H1s

Elementor, Divi and similar builders store headings as widgets with an HTML tag setting. An update that changes a global template, a theme builder header, or how the theme's own page title is displayed can leave a page with two H1s or none. A common example is a theme that starts printing the post title as an H1 above a builder layout that already has its own. Check the H1 on the homepage, one landing page and one post.

Caching and optimisation plugins that move GTM

WP Rocket, LiteSpeed Cache, Autoptimize and similar plugins can defer, delay or combine JavaScript. After an update, a new default or a changed exclusion list can push the GTM container behind a "delay until user interaction" rule. The tag is still in the HTML, so a source check passes, but pageviews from visitors who never scroll or click are no longer sent.

Two habits help. Purge the page cache after every update, because the HTML you see logged in usually bypasses it. Then load the page in a private window with the Network tab open and confirm the gtm.js request fires before you interact. The steps for GA4 are in how to check GA4 is installed.

Permalinks, robots.txt and staging pushes

Plugins that register custom post types or taxonomies can change their rewrite rules in an update. Until the rules are flushed, those URLs return 404 while normal pages work. Visiting Settings > Permalinks and clicking Save Changes flushes them, as does wp rewrite flush in WP-CLI. Test one URL from each custom post type rather than assuming.

robots.txt needs its own look. If there is no physical file, WordPress serves a virtual one that SEO plugins can edit, and a plugin update or settings import can rewrite it without a file ever changing on disk. If there is a physical file, it wins, and a deploy can copy a staging version with Disallow: / over it.

Staging pushes are where the "Search engine visibility" setting catches people. The option lives in the database, so a database push from a staging site with "Discourage search engines from indexing this site" ticked adds noindex to the whole live site. How to catch a noindex in production goes through the ways to spot it.

A 10 minute WordPress update SEO checklist

Run this on the live domain, logged out, after the cache has been purged.

  1. Confirm the homepage and one inner page return 200 and don't show "Briefly unavailable for scheduled maintenance".
  2. View source on the homepage, one post and one category page and search for noindex.
  3. Run curl -I on the homepage and check there is no X-Robots-Tag header you didn't expect.
  4. Compare the <title> and meta description on those pages with what they were before the update.
  5. Check that each page has one H1 and that it is the one you expect.
  6. Confirm the canonical is present and points to the page's own URL on the right protocol and host.
  7. Open /sitemap_index.xml (or /wp-sitemap.xml without an SEO plugin) and check that every post type is still listed.
  8. Open /robots.txt and compare it with the previous version.
  9. Visit one URL per custom post type and taxonomy and confirm none return 404.
  10. In a private window, confirm GTM, GA4 and the Meta Pixel load, and that the cookie banner still appears.

Keep a copy of the robots.txt and a few titles before you update. Without a before, most of these checks turn into guesswork.

What to automate and what to keep doing by hand

Doing this for one site after a planned update is realistic. Doing it across thirty client sites where plugins auto update overnight is not, because you often don't know an update ran.

Deltio covers the automated part. It reads each site's sitemap and pages once a day and compares them with the previous check, then sends Slack and email alerts for that site when noindex, robots.txt, canonicals, titles, meta descriptions, H1s or sitemap URLs change, when GA4, GTM, the Meta Pixel or the cookie consent platform is missing, or when a maintenance page replaces the content. Uptime, SSL and domain expiry are tracked too.

Being daily, it tells you about an auto update that broke something the next day. For an update you run yourself, still do the checklist straight away, or trigger a manual SEO scan in Deltio once the cache is purged.

If you want the overnight updates covered, there's a 14 day free trial.

Frequently asked questions

Does WordPress email me when an automatic update runs?
Yes. Since WordPress 5.5, the site sends an email to the admin address after automatic plugin and theme updates, and core has sent one for automatic core updates for longer. Routing those emails to a shared inbox gives you a trigger for the post update check, though it depends on the site being able to send mail.
How do I get a site out of maintenance mode after a failed update?
During an update WordPress creates a file called .maintenance in the site root. If the update is interrupted, the file stays and every visitor sees the maintenance notice. Deleting that file over SFTP or the host's file manager restores the site, after which you should rerun the update that failed.
Should I update plugins one at a time?
On a client site with SEO, caching and page builder plugins, updating those three individually and checking between each makes it much easier to tell which one changed the output. Low risk plugins can go in a batch. On staging, the order matters less.
Can I roll back a plugin update that broke SEO output?
WordPress restores the previous version when a plugin update fails to install, and since 6.6 it rolls back an automatic update that causes a fatal error, but a plugin that updates cleanly and changes your titles stays. The options then are reinstalling the previous version from the Advanced View on the plugin's WordPress.org page, WP-CLI with wp plugin install plugin-slug --version=x.y.z --force, or a backup restore, which also reverts content edited since.