How to Manage Next.js Redirects With Sanity and Cloudflare Workers KV

Redirects look like a small SEO task until a website has enough content, editors, URL changes, and migration history to make them operationally important.

For Tevpro's Next.js website, we built a CMS-managed redirect system using Sanity and Cloudflare Workers KV. Editors can create and manage redirects in Sanity without requiring an engineer to modify application code or deploy the website.

The architecture separates redirect management from redirect execution:

Sanity serves as the editorial source of truth. When redirect rules change, a signed webhook synchronizes the published redirect map to Cloudflare Workers KV. At runtime, a Cloudflare Worker evaluates incoming URLs before Next.js renders the request.

This gives content owners control over URL changes while keeping redirect resolution fast, predictable, and independent of a live CMS request.

Why Redirect Management Needs Its Own System

Next.js provides built-in ways to configure redirects, and hard-coding a short, stable list of redirects can be perfectly reasonable.

The operating model changes when redirects become routine editorial work.

A simple URL correction can otherwise require an engineer to update application configuration, open a pull request, complete a review cycle, and deploy the application. That is a lot of software delivery activity for what is often a straightforward content or SEO decision.

Production redirect management also requires more than maintaining a list of old and new URLs.

A reliable redirect system needs to account for:

• Permanent versus temporary redirects
• Exact and parameterized URL patterns
• Redirect loops
• Redirect chains
• Duplicate source URLs
• Internal versus external destinations
• URL validation
• Slug and content changes
• Large redirect imports during website migrations
• Recovery when synchronization fails

For Tevpro.com, we wanted redirect decisions to live with the content while redirect execution remained part of the application infrastructure.

How the Redirect Architecture Works

The system has two distinct workflows: authoring and synchronization and runtime redirect resolution.

When an editor creates or changes a redirect:

1. The redirect is created and published in Sanity.
2. Sanity sends a signed webhook to the Next.js application.
3. The webhook endpoint verifies the request.
4. The application loads and normalizes the published redirect rules.
5. The resulting redirect map is synchronized to Cloudflare Workers KV.

When a visitor or search crawler requests a URL:

1. The request reaches the Cloudflare Workers environment.
2. Redirect logic evaluates the incoming pathname.
3. The Worker checks Workers KV for an exact redirect and evaluates applicable pattern-based rules.
4. If a redirect matches, the Worker returns the appropriate HTTP redirect response.
5. If no redirect matches, the request continues into the Next.js application through OpenNext.

The important architectural decision is that Sanity is not queried during every visitor request.

Sanity manages the redirect data. Workers KV serves it at runtime.

Why We Manage Redirects in Sanity

We model redirects as structured documents in Sanity alongside the rest of the site's managed content. Each redirect contains a source path, destination, redirect status, and optional internal notes.

The schema validates redirect data before it reaches production. A source must begin with a valid relative path, while destinations must be either approved internal paths or complete HTTP(S) URLs. Invalid formats, spaces, and protocol-relative URLs can be rejected before publication.

This gives editors a controlled interface for managing URL changes without exposing application configuration.

It also creates a clean ownership boundary:

Sanity is where people make redirect decisions. It is not the service the production application needs to query for every redirect request.

Why We Use Cloudflare Workers KV for Redirects

One of the architectural questions we considered was where the production redirect map should live.

For our implementation, Cloudflare Workers KV is a better fit than D1 because redirect resolution is fundamentally a key-value lookup problem.

The application receives a path such as:

/old-services-page

and needs to determine whether that path maps to a destination such as:

/services/new-services-page

That does not require relational queries or transactional application data. The common operation is simply:

incoming path → redirect destination + HTTP status

Workers KV provides a straightforward runtime primitive for that workload and integrates naturally with the Cloudflare Workers environment where the redirect logic executes.

Cloudflare D1 is a relational database service and can be a better choice when an application requires SQL queries, relationships, or transactional behavior. Redirect resolution did not require that machinery in our implementation.

Choosing the narrowest appropriate infrastructure primitive keeps the redirect runtime easier to understand and operate.

Why Not Put Every Redirect in next.config.js?

Next.js supports redirects directly in application configuration. For a small number of stable, developer-managed rules, that approach works well.

Our requirement was different.

We wanted redirects to become managed editorial data rather than application configuration.

When redirects live in Sanity, an authorized content owner can create or update a rule without changing application code. Publishing that change triggers synchronization to the runtime redirect store without requiring a normal application deployment.

This becomes particularly useful for sites with:

• Frequent content changes
• Large content libraries
• Multiple editors
• SEO teams managing URL changes
• Website or CMS migrations
• Large historical redirect maps

The goal is not to replace Next.js redirect configuration in every situation. It is to use a different operating model when redirects need to change independently of application releases.

301 vs. 307 Redirects

Our Sanity schema allows editors to explicitly choose between permanent and temporary redirects.

Permanent URL changes return an HTTP 301 response. Temporary redirects return an HTTP 307 response.

The distinction matters for both application behavior and SEO.

A permanent redirect indicates that a resource has moved to a new location and that the destination should generally be treated as the replacement URL. A temporary redirect communicates that the original URL may still be relevant and that the move should not necessarily be treated as permanent.

Rather than hiding that decision in application code, the redirect status is part of the content model and visible to the person creating the rule.

The important principle is that redirect status should be intentional. A production redirect system should not treat every URL change as interchangeable.

Handling Exact and Parameterized Redirects

Most redirects are simple exact matches.

For example:

Those rules are stored in Workers KV under predictable keys, allowing the Worker to handle the most common lookup efficiently.

Some redirects, however, need to represent patterns rather than individual URLs.

For example, a legacy site structure might contain URLs that conceptually map like this:

Our synchronization process therefore separates exact redirects from parameterized patterns.

Exact matches are evaluated first. Pattern-based rules are maintained as a compact collection that can be evaluated when an exact redirect does not exist.

This gives the system the flexibility to handle legacy URL structures without forcing every incoming request through unnecessary pattern matching.

Preventing Redirect Chains and Loops

Redirect flexibility needs guardrails.

Consider a redirect chain:

The visitor and search crawler must make multiple requests before reaching the final destination. When possible, the better rule is:

Loops are more serious:

A production redirect system should therefore validate and normalize redirect rules rather than blindly publishing whatever data it receives.

The same applies to duplicate source paths. A source URL should have one predictable outcome, not multiple competing destinations.

These checks become especially important during website migrations, where hundreds or thousands of historical URLs may be imported at once.

Redirect management is not simply about storing source and destination strings. It is about maintaining a predictable URL graph.

Redirects Run Before Page Rendering

At runtime, redirect resolution happens at the request boundary in the Cloudflare Workers environment.

The Worker reads the incoming pathname and evaluates it against the redirect data stored in Workers KV. If a rule matches, the application returns the appropriate redirect response before the request proceeds to page rendering.

If no rule exists, the request continues normally into the Next.js application.

Conceptually, the runtime logic looks like this:

const redirect = await getRedirect(pathname);
if (redirect) {
  return Response.redirect(new URL(redirect.destination, request.url), redirect.permanent ? 301 : 307);
}

This is a simplified example rather than our complete production implementation, but it illustrates the important architectural point: determine whether the request should redirect before doing the work required to render a page.

That matters for visitors and search engines.

The browser receives a real HTTP redirect rather than loading a page and then performing client-side navigation. Search crawlers receive the HTTP status and destination directly, and the application avoids unnecessary rendering work for a request whose correct response is simply another location.

Synchronizing Sanity Redirects to Workers KV

When a redirect document changes, Sanity sends a signed webhook to a dedicated Next.js endpoint.

The application verifies the webhook signature before performing synchronization. Invalid requests are rejected rather than being allowed to modify production redirect behavior.

Once verified, the synchronization process loads the published redirect set, normalizes the records, separates exact and pattern-based rules, and updates the Workers KV namespace used by the production runtime.

This security boundary is important.

A redirect system can change where visitors and search engines are sent. The synchronization endpoint therefore should not function as an unauthenticated public mechanism for changing routing behavior.

Publishing is treated as a privileged operational event: authenticated, validated, and controlled.

Designing a Recoverable Redirect Sync

Webhooks are useful, but production systems should not assume every integration event will always arrive exactly as expected. Our redirect synchronization process includes a recovery mechanism.

A control within Sanity Studio can initiate a full refresh of the published redirect set. This allows the team to rebuild the Workers KV redirect map after a large import, configuration change, or failed webhook and provides a deterministic recovery path.

Instead of trying to determine which individual event may have been missed, the system can synchronize the known published state from Sanity back to the runtime store.

This becomes especially valuable during large CMS migrations, where redirect data may arrive in bulk rather than through normal day-to-day editorial activity.

Where OpenNext and R2 Fit

Redirect handling is only one part of our site’s Cloudflare architecture.

Tevpro.com is built with Next.js and runs on Cloudflare Workers. OpenNext for Cloudflare provides the runtime bridge that allows the application to operate in the Workers environment while preserving the Next.js development model.

Cloudflare R2 serves another purpose. It supports the OpenNext incremental cache used by the application. It is not our redirect store.

The separation is intentional and each component solves a different problem:

Workers KV → redirect data

R2 → incremental-cache artifacts

Cloudflare Workers → request and redirect execution

Sanity → editorial content and redirect authoring

OpenNext → Next.js runtime compatibility on Cloudflare

Keeping those responsibilities explicit makes the architecture easier to reason about, troubleshoot, and evolve.

Why This Architecture Matters for SEO

Redirects are infrastructure, but their consequences are highly visible to search engines.

When URLs change, correctly implemented redirects help crawlers understand where content has moved and prevent users from landing on obsolete locations.

A poorly maintained redirect system can instead create redirect chains, loops, stale destinations, unnecessary crawl paths, and inconsistent URL behavior.

Moving redirect management into the CMS also brings URL changes closer to the people managing content and SEO. Editors can account for redirects as part of publishing and migration work rather than treating them as a separate engineering request after the fact.

The technical architecture supports the SEO objective: make every old URL resolve to the correct destination as directly and predictably as possible.

What This Gives the Team

For editors, redirect management becomes part of the CMS workflow they already use.

For engineering, routine URL changes no longer require application releases.

For visitors and search engines, redirect resolution happens before unnecessary rendering work.

And for the production application, Sanity does not become a live dependency every time someone requests an old URL.

The result is a clear division of responsibilities:

• Sanity owns redirect authoring.
• Signed webhooks synchronize published redirect data.
• Workers KV provides the runtime redirect map.
• Cloudflare Workers evaluate redirects at the edge.
• R2 supports the application's incremental cache.
• OpenNext runs the Next.js application in the Cloudflare Workers environment.

The operational lesson is not that every website needs this exact technology stack.

It is that redirect authoring and redirect execution are different jobs.

Separating them allows content teams to control URL changes while engineering maintains a fast, predictable production request path.

The Broader Engineering Lesson

Redirect management is a relatively small piece of a modern web platform, but it illustrates a larger production engineering principle.

The technologies themselves are rarely the difficult part.

The challenge is deciding which system should own which responsibility and how those systems should communicate reliably in production.

For this implementation, Sanity provides the editorial workflow. Signed webhooks carry trusted changes. Workers KV provides the runtime data structure. Cloudflare Workers execute the redirect logic. OpenNext runs the Next.js application, and R2 supports incremental caching.

No single technology is being asked to solve every problem.

That separation of responsibilities is what turns a collection of modern platforms into a maintainable production architecture.

Final Thoughts

At Tevpro, we apply the same engineering approach to modern web applications, enterprise integrations, legacy modernization, and AI-enabled systems: use modern platforms where they create leverage, then engineer the architecture between them for performance, security, maintainability, and production reliability.

Building or modernizing a complex web application? Tevpro engineers production-ready applications and cloud architectures designed to perform beyond the prototype. Let’s collaborate.