Why Canonicals Break After Every SEO Plugin Update

If every SEO plugin update quietly reintroduces Search Console warnings like Duplicate page without canonical or Page with redirect, you are fighting a storage problem, not a settings problem. Plugins store canonical state in two places, and updates can leave one of them stale.

Quick answer

WordPress SEO plugins keep canonical data in plugin-specific tables (Yoast's indexables) and classic postmeta (_yoast_wpseo_canonical). Repair one and not the other and the next render or update flips the page back. A durable fix writes the same canonical value to both stores, replaces NULLs with self-referencing values, and re-checks after every plugin update.

Typical breakage classes

NULL canonical rows. New or re-imported posts get indexable rows with NULL canonical fields. Search Console then reports duplicate-page warnings on pages you never touched.
Postmeta vs indexable drift. The postmeta value says one thing, the indexable table another. WordPress renders whichever the plugin reads first, and it can change between versions.
Canonical-redirect loops. The stored canonical points at a URL that 301s elsewhere (classic after slug or prefix changes). Google sees a canonical pointing at a redirect chain and either drops it or picks for you.
Trailing-slash and scheme drift. http vs https and with/without slash variants count as different canonical pages under the comparison rules used for URL matching.

The DIY approach

Compare the plugin table's canonical against the postmeta value for the same post. Note the disagreements.
For NULLs, write self-referencing canonicals (the page's own permalink) in both stores.
For drift, pick the store the plugin serves from as the source of truth and sync the other.
For loops, set the canonical to the final-resolved URL, not the redirecting one.
Re-crawl, then record the state so the next update can be diffed against it.

The Brambyl route

Four diagnostics and repairs cover exactly these classes: NULL canonical detection and repair, stale postmeta alignment (both stores written to match), canonical redirect-loop detection (canonical vs resolved permalink with an HTTP probe), and canonical shape-drift repair that resolves which shape your site actually serves before writing. Every repair captures scoped rollback SQL, so a repair can be reverted precisely. A drift-detection run re-diffs the stores weekly so the next plugin update does not surprise you.

FAQ

Which store does WordPress actually serve from?

It depends on your SEO plugin and version, which is exactly why one-store fixes break. Sync both and the question stops mattering.

Why does this happen after updates if I never edited anything?

Plugin updates routinely rewrite indexable tables or change the precedence between stores. Your content did not change; the read path did.

Does the repair survive the next update?

Repairs that write both stores with current resolved URLs do, because that is the state the plugin expects. Fixes that edit plugin files do not, because updates overwrite the files. Brambyl writes data, not files.