Redirects that editors own

Every website accumulates URL debt. Services get renamed. Blog posts get recategorised. An entire site gets rebuilt on a new platform with a different information architecture. Without redirects, every old URL becomes a dead end, for visitors and for the search equity those pages earned over months or years.

Most teams handle this one of two ways. Developers add redirects to a config file that deploys with the codebase. Or someone maintains a spreadsheet that gets translated into server rules every few weeks. Both work until they don't, the config file becomes a bottleneck, and the spreadsheet drifts out of sync.

The underlying issue is ownership. Redirects are a content concern dressed up as a technical one. The people who know which URLs changed are editors and project managers. The people who can implement redirects are usually developers. That gap creates delays, missed redirects, and 404s that persist longer than they should.

We treat redirects as first-class content in Payload CMS. Editors create redirect entries with a source path and a destination — either a hardcoded URL or a reference to a CMS document. The redirect collection lives alongside pages, posts, and other content types.

On the Next.js side, a utility fetches all active redirects and caches them using unstable_cache with a dedicated cache tag. When a visitor hits a URL that doesn't match any page, the catch-all route checks for a matching redirect before returning a 404. If it finds one, it issues a proper 301 redirect to the destination.

The cache tag is the key piece. Without it, every page request would query the redirect collection, unnecessary load for something that changes infrequently. With it, redirects are fetched once and served from cache until an editor creates, updates, or deletes a redirect entry. At that point, a collection hook revalidates the tag, and the next request picks up the fresh set.

Redirects are a read-heavy, write-rare pattern. Most requests don't match a redirect at all — they resolve to a valid page. But every request needs to check, which means the lookup has to be fast.

We cache the full redirect set using the same tag-based pattern we use for sitemaps and content listings. The redirects utility wraps a Payload query in `unstable_cache` with a `'redirects'` tag. Collection hooks on the redirect model call `revalidateTag('redirects')` whenever an entry changes.

This means the redirect lookup on every page request is reading from cache, not querying the database. When an editor adds or changes a redirect, the cache busts, the next request fetches fresh, and everything after that reads from cache again.

It's the same principle as the rest of our caching architecture: aggressive caching for performance, instant updates when content changes.

CMS-managed redirects handle the editorial use case well, page renames, migrations, restructures. But some redirects are infrastructure concerns.

Domain-level redirects (www to non-www, HTTP to HTTPS) belong in hosting or CDN configuration. Trailing-slash normalisation belongs in the framework config. Redirects that need to fire before the application boots, like legacy domain migrations, belong at the edge or in DNS.

We use Next.js config-level redirects for these structural patterns. They deploy with the codebase because they're not content decisions, they're infrastructure decisions that shouldn't change without a code review.

The split is straightforward: if an editor would reasonably need to create or change it, it goes in the CMS. If it's a platform-level rule that applies to every request regardless of content, it stays in config.