You change the URL of a page and need the old one to point somewhere new.
The redirect itself is simple:
example.com/old-page → example.com/new-page
But in many teams, making that happen isn’t simple at all. You open a ticket, explain what needs to change, wait for a developer to pick it up, and sometimes wait for the next deployment before the redirect finally goes live.
That process makes sense for changes that genuinely require engineering work. A basic redirect usually isn’t one of them.
Redirects are infrastructure, but managing everyday redirect rules shouldn’t always require someone who writes code.
The redirect is rarely the difficult part
A redirect has a very small job. Someone requests one URL, and the browser is told to go somewhere else.
The complexity usually comes from where that rule lives.
It might be buried in a server configuration, managed through a hosting platform, added to a codebase, or controlled by a CMS that only certain people can access. If the marketing or SEO team needs a redirect, they may know exactly what the old URL is, exactly where it should go, and exactly why it needs to happen. They still can’t make the change themselves.
So a task that takes seconds to describe can turn into a workflow involving several people.
That isn’t necessarily a technical limitation. Often, it’s simply a consequence of redirects being managed in a system designed for something else.
Developers have better things to do
There are plenty of redirects where developer involvement makes sense. Complex routing logic, application behavior, unusual infrastructure, or changes that interact with the rest of a technical system may absolutely belong with an engineering team.
But consider a common request:
/summer-sale → /offers
The campaign has ended. The marketing team knows the new destination. The redirect needs to go live.
Does that really need to become a development task?
The same thing happens during content updates, SEO cleanups, rebrands, and website migrations. One redirect becomes ten. Ten become a spreadsheet with two hundred old URLs. Suddenly, a developer is spending time implementing and maintaining rules that another team has already decided.
The goal isn’t to remove developers from redirects entirely. It’s to involve them when the redirect actually requires their expertise.
The people making the URL decisions should have more control
Redirects often sit at the intersection of several teams.
SEO might identify a broken URL that still has valuable backlinks. Marketing might retire a campaign page. A content team might merge two articles. A web team might restructure an entire section of the site.
In each case, the person requesting the redirect often understands the context better than the person implementing it.
They know that:
/old-pricing should go to /pricing
and not simply to the homepage.
Giving those teams a clear place to manage redirect rules shortens the distance between deciding what should happen and actually making it happen. It also makes it easier to review existing rules later instead of trying to remember whether a redirect lives in a CMS, a server file, or somewhere inside an old hosting account.
This matters even more during a migration
A few redirects are easy to pass around in Slack. A website migration is where the limitations of that workflow become much more obvious.
You might have hundreds of old URLs that need to be reviewed, mapped, implemented, and tested. The SEO or web team may already have a complete redirect map showing exactly what should happen:
/about-us → /company
/our-work → /projects
/pricing-old → /pricing
If every change still needs to be translated into a development task, implemented somewhere in the website infrastructure, and deployed, redirect management becomes another dependency in an already busy launch.
A dedicated redirect layer changes the workflow. The team responsible for the migration can manage the rules directly, while developers can stay focused on the parts of the launch that actually need development.
Redirects shouldn’t disappear with the website either
There’s another problem with making redirects part of the website’s technical setup: websites don’t last forever.
A company might move from one CMS to another, replace its hosting, rebuild the website, or shut an old site down completely. If the redirects live inside that infrastructure, someone needs to remember to move them too.
And old URLs can remain useful long after the website that created them is gone. They can still have backlinks, appear in search results, live inside old emails, or sit in someone’s bookmarks.
Redirects therefore make more sense as something that can exist independently of a particular website stack.
That’s one of the ideas behind Redirect Supply.
Give redirects their own place
Redirect Supply separates redirect management from the website itself.
You connect a domain through DNS, create the rules you need, and manage them from one place. Once the domain is Connected, a new redirect doesn’t require editing server configuration or deploying a website change.
The workflow becomes much closer to the task itself:
Choose the URL you want to redirect.
Enter its new destination.
Select the redirect type.
Save the rule.
Test the old URL.
Developers can still be involved in the initial technical decisions or more complex situations. They just don’t need to become the gatekeeper for every /old-page → /new-page change afterwards.
Simple changes should have simple workflows
Developers aren’t the problem with redirect management. The problem is requiring development work when the task itself doesn’t require it.
Sometimes a redirect belongs in code. Sometimes it needs custom routing logic or careful technical implementation. But many everyday redirects are simply decisions about where an old URL should lead now.
Those decisions should be easy to make, easy to implement, and easy to find again later.
That’s why we built Redirect Supply so redirects can have their own place, separate from the website and the development queue.
A redirect might be infrastructure.
Managing one doesn’t always need to be an engineering project.
