A website changes more often than the URLs pointing to it disappear.
You redesign it. Move from one CMS to another. Change hosting providers. Rebuild the whole thing from scratch. Eventually, the old website may not exist at all.
But the URLs it created can stick around for years. They live in Google, backlinks, bookmarks, emails, documentation, social posts, and places you may have completely forgotten about.
That creates an interesting problem: if redirects need to survive the website, why should they live inside it?
Your website and your redirects have different lifecycles
Imagine you publish a page at:
example.com/old-service
Over time, other websites link to it, Google indexes it, customers bookmark it, and your team includes it in emails and documents.
A year later, you rebuild the website and the same content moves to:
example.com/services
The old page is gone, but the old URL isn’t. People can still request it, and links across the internet can continue sending traffic there.
A 301 redirect gives that old URL somewhere useful to go. The redirect may need to keep working for years, even if the website gets rebuilt again during that time.
This is where the lifecycles start to separate. Your website is one piece of infrastructure. Your old URLs and the redirects attached to them can easily outlive it.
Website-based redirects create a dependency
Redirects are often managed wherever the website happens to live.
On WordPress, they might be handled by a plugin. On another platform, they may be configured through the CMS. A developer might add them to Apache or Nginx, or the hosting provider might offer its own redirect settings.
There’s nothing inherently wrong with any of these approaches. If the website stays where it is, they can work perfectly well.
The problem appears when you want to leave.
If the redirect depends on the old CMS, server, or hosting environment, removing that infrastructure can remove the redirect with it. Suddenly, switching platforms isn’t just about moving the new website. You also need to find every old redirect, work out where it currently lives, and make sure it survives the move.
The website becomes a dependency for something that doesn’t necessarily need the website at all.
A migration makes the problem much more visible
Suppose you’re replacing an old website with a completely new one.
You map the important URLs before launch:
/about-us → /company
/old-pricing → /pricing
/blog/old-guide → /academy/new-guide
You launch the new website, test the redirects, and everything works.
Two years later, you migrate again.
If those rules were built into the previous website, they become part of the next migration too. Someone has to preserve them, rebuild them, or decide which ones still matter. The same redirect can end up moving from CMS to CMS simply because the website around it keeps changing.
Now imagine the redirect layer stays where it is while the website changes underneath it.
The migration becomes simpler because existing redirect infrastructure doesn’t automatically need to move with the site.
Old domains make the separation even more useful
The difference becomes even clearer during a rebrand.
Imagine moving from:
oldbrand.com
to:
newbrand.com
Once the new website is running, there may be no reason to keep the old website online. But there can be plenty of reasons to keep oldbrand.com.
People may still type the old brand name. Backlinks can continue pointing to old pages. Customers may open old emails or documents months later. Search engines may still encounter URLs from the previous site.
You want those requests to reach the new website, but you don’t need the old website itself to make that happen.
What you need is control of the old domain, working DNS and HTTPS, and infrastructure capable of returning the redirect.
That’s a much smaller job than keeping an entire website online.
Redirects are infrastructure of their own
A redirect looks like a tiny website feature, but technically it doesn’t need a website page at all.
The request comes in:
oldbrand.com/pricing
Something receives it, matches it against a rule, and responds with a redirect to:
newbrand.com/pricing
The browser follows that response. There is no need to load the old homepage, run the old CMS, query its database, or render anything.
That makes redirects a good candidate for their own infrastructure.
Instead of asking the old website to stay alive just to answer with “go somewhere else,” the redirect layer can handle that job independently.
This is how we think about redirects at Redirect Supply
Redirect Supply was built around that separation.
You connect a domain through DNS and manage its redirect rules independently of the website. Requests are handled through Cloudflare’s edge network, where Redirect Supply can match the incoming URL and return the appropriate redirect.
The basic flow looks like this:
Old URL → Redirect Supply → New URL
Your new website can be hosted somewhere completely different. The old website can eventually disappear. If you rebuild again later, the redirect setup doesn’t automatically have to move with it.
This also gives redirect rules one predictable place to live. Instead of wondering whether a particular redirect is hidden in WordPress, a server configuration, an old hosting account, or the current website platform, you can manage the redirect layer separately.
Moving redirects outside the website doesn’t mean everything belongs there
Not every redirect needs to be separated from a website.
If you’re changing one URL inside an active site and your CMS already provides an easy way to manage redirects, keeping that rule there can be perfectly reasonable. Application-specific routing may also belong inside the application because it depends on its logic.
The distinction becomes useful when the redirect needs to survive independently of the current website.
Ask a simple question:
If we replaced or deleted this website tomorrow, would this redirect still need to work?
If the answer is yes, there’s a strong reason to consider managing it outside the website.
Websites change. Redirects can stay.
A website is temporary infrastructure. Even a successful one will eventually be redesigned, migrated, rebuilt, or replaced.
The links pointing to it don’t follow that schedule.
Separating redirects from the website means those old URLs don’t have to depend on whichever CMS, hosting provider, or server happens to be running today. The website can evolve without forcing the redirect layer to start over every time.
That’s the principle behind Redirect Supply: give redirects their own place to live, so they can keep doing their job even when the website around them changes.
