Stop published content from staying stale after an edit

An editor changes an article's opening paragraph and sees the new value in the database. A public visitor still sees the old paragraph. Refreshing sometimes helps, while opening a new browser sometimes does not. The confusing part is that every layer can honestly claim it served its current value: the database has the edit, a cached query has the old record, and a rendered route may already contain the old HTML.

This walkthrough assumes Next.js 15 App Router, with examples compatible with 15.1.11. Caching defaults changed across Next.js releases, so record the installed version before using an assistant's explanation. Do not introduce newer cache APIs into an older application merely because a current example recommends them.

Define what published means

Start with a user-visible contract. For a small blog, publishing could mean that a new direct request sees the updated article after a successful edit response. An already open browser might require a refresh. A news site may require a stricter maximum delay; an archive may accept a short interval. Write this down before choosing tags, timers, or a broad cache purge.

Add deletion and unpublishing to the contract. A stale spelling correction is inconvenient; a publicly cached draft or withdrawn article can violate a more important promise. The same caching mechanism may need different policy for these operations. Define whether a missing article can be cached and how publication changes invalidate that absence.

The edit response should describe completed work accurately. If it reports success before invalidation is attempted, the user cannot tell whether the public page is ready. A durable publish operation can record a pending invalidation state if that step can fail independently. Do not imply atomicity across a database and an external cache service.

Trace the record through every layer

Add a harmless revision number to a synthetic article. Read it directly through the repository, through the page response, and through client navigation. Record which revision each path returns. This avoids vague comparisons of paragraphs and makes it easier to tell whether a browser cache differs from a server cache.

Inspect application code for explicit fetch caching, unstable_cache, route configuration, and in-process maps. Also inspect deployment headers and any reverse proxy or CDN. A database driver's connection pool is not a content cache. React request memoization is not the same lifetime as a persistent data cache. Keep these mechanisms separate in the evidence table.

A direct database read may run on each request while the route itself is served from an earlier rendered result. Conversely, a dynamic route can still read an explicitly cached data function. Ask an AI assistant to trace these exact calls and settings, naming files. Reject explanations that assume every request is cached because the project uses Next.js.

Apply invalidation where ownership is clear

For one article route, a path-based invalidation may be sufficient. If the same article appears on the homepage, category listing, and related-content panel, a data tag can express the shared dependency. Choose names that identify the resource and collection intentionally. Avoid using one global tag for every piece of application data.

In Next.js 15.1.11, revalidatePath and the one-argument revalidateTag API are available. Their effects depend on the call context, and a Route Handler invalidation does not automatically refresh every open client's router cache immediately. Check behavior with your actual edit path instead of assuming a server invalidation pushes an update to the browser.

import { revalidatePath } from 'next/cache'

export async function savePublishedArticle(input: EditInput) {
  const article = await updateArticleAfterAuthorization(input)
  revalidatePath(`/blog/${article.slug}`)
  revalidatePath('/blog')
  return { id: article.id, revision: article.revision }
}

The authorization and repository functions are application code. The example assumes the slug is already validated and belongs to the article being edited. If a slug changes, invalidate both old and new paths and update canonical discovery. Do not build a purge endpoint that accepts arbitrary paths from anonymous callers.

Keep correctness separate from convenience

Disabling a cache can establish whether that layer caused the stale result. It is a useful diagnostic experiment, but the final change should follow the freshness contract. A public article read may benefit from caching; a private preview should use a separate privileged read with no public reuse.

If multiple application instances use independent cache storage, test invalidation across instances. One successful local refresh proves little about shared deployment behavior. Identify the adapter or hosting cache configuration and its documented consistency limits. Do not invent an application-level distributed guarantee that the infrastructure does not provide.

Handle invalidation failures observably. Record article identifier, revision, target paths, and result without logging private content. A retry should be safe when the same invalidation runs again. If publishing queues the work, show an honest pending state and notify the editor when the public revision can be confirmed.

Verify publication and withdrawal

Use a fresh synthetic article and fetch it before publication, after publication, after editing, and after withdrawal. Check response status, revision, HTML, and metadata. Include the listing and sitemap because discovery surfaces may have their own stale records. The article page alone is not the complete publication journey.

Exercise both a direct HTTP request and client navigation from a page visited before the edit. Record when an already open session needs router.refresh or a new navigation. Do not confuse that UX action with invalidating server data: a client refresh can still receive stale server output.

Test failures between the database write and invalidation. If the write succeeds but the next step fails, the system needs a recoverable status instead of silently losing the event. Use a controlled fake cache failure in tests and one deployment-level check of the real cache path. An assistant can propose these failure points; your verification must establish which ones were actually exercised.

Trade freshness for complexity deliberately

A short time-based revalidation interval can be adequate when a little staleness is acceptable and updates are infrequent. Explicit invalidation offers tighter control but creates dependency bookkeeping. Combining both can provide recovery from a missed event, provided the maximum delay is acceptable and documented.

Broader invalidation is easier to reason about initially but may increase load or trigger unnecessary regeneration. Narrow invalidation can miss a derived surface. Start with the surfaces that actually use the record, then measure whether finer granularity is needed. Avoid designing an elaborate tag hierarchy before the application has enough shared data to justify it.

Draft-cache isolation addresses a different risk in the same path. Sitemap freshness extends the revision checks to public discovery. Together these checks make publishing an observable transition rather than a database write that merely appears successful.