How should a CMS invalidate caches so published SEO changes actually reach users and crawlers?

Treat cache invalidation as part of publishing, not as an infrastructure afterthought.

Map which caches can hold each page: application/object cache, full-page cache, reverse proxy, CDN, static artifact, browser cache, and any edge-rendered layer. Publishing should know which keys or paths need invalidation.

Prefer targeted purge/revalidation for affected pages and dependencies. Updating a category name may require purging the category page, breadcrumbs on child pages, sitemap entries, and structured data references—not necessarily the entire site.

For static generation, maintain dependency maps so a content change triggers rebuilds for pages that reference the changed entity. Without this, shared author/location/business data can remain stale across generated pages.

Add cache version or surrogate keys where your CDN supports them. This makes entity-level purges more reliable than guessing URL patterns.

After publish, fetch the live URL bypassing editor session state and compare expected values such as title, canonical, last modified content, and schema. A successful CMS save is not proof of a successful public deployment.

Set reasonable TTLs as a safety net, but do not depend on short TTLs to compensate for broken invalidation.

SEO-sensitive updates are especially vulnerable because stale pages can look correct in the editor while crawlers continue receiving old signals. Publishing should end with verification of the public response.