Blog

/

Product

Why we built Redirect Supply

·

7

min

·

Crumpled Redirect Supply sticker with a QR code and the line “I just rebranded and no one can see my site now… Bro, have you tried Redirect Supply?”

Redirects usually aren’t something you think about until you suddenly need them.

Maybe you’re launching a new website. Changing domains. Rebranding. Cleaning up old URLs. The actual request sounds simple enough:

old-url.com → new-url.com

Then you start figuring out how to make it happen.

Do you configure it in your hosting? Add something to the server? Keep an old website running? Ask a developer? And what happens when you need to change it again six months later?

For something that does one very simple job, redirects have a habit of becoming an infrastructure problem.

That’s the problem we wanted Redirect Supply to solve.

Redirects shouldn’t depend on your website

Traditionally, redirects often live wherever the website lives.

That might be your web server, hosting platform, CMS, or some configuration file a developer set up years ago. There’s nothing inherently wrong with that. If you have the right access and know where everything is configured, it works.

The awkward part comes when the website changes.

You might move to a different platform, replace the site entirely, change domains, or shut an old website down. Suddenly, redirects that should keep working for years are tied to infrastructure you’re trying to leave behind.

We thought that relationship was unnecessary.

A redirect needs somewhere to receive a request and return a new destination. It doesn’t need the website itself.

So we separated the two.

We wanted redirects to have their own place

One of the ideas behind Redirect Supply is simple: your redirects shouldn’t be scattered across hosting accounts, CMS settings and server configurations.

They should have a place of their own.

You connect a domain, create the rules you need, and manage them independently of whichever website happens to be live today.

That makes a difference when websites inevitably change.

A company might launch a new site today, rebrand two years from now and move platforms again later. The website keeps evolving, but some of the URLs created along the way can stay in circulation for much longer.

Backlinks don’t disappear because you redesigned your site. Bookmarks don’t update themselves. Google can still know about old URLs. And someone will always find that one link from 2019 you completely forgot existed.

Those old URLs still need somewhere to go.

Why we built it on the edge

Once redirects have their own infrastructure, the next question is where that infrastructure should live.

For us, the edge made sense.

Redirects have a small, specific job: receive a request, match it against a rule, and return the right response. There’s no reason to load an entire website just to tell a browser to go somewhere else.

Redirect Supply is built on Cloudflare’s edge network, so redirects can be handled across distributed infrastructure rather than relying on the server or hosting behind your website.

From the user’s side, none of that needs to feel particularly technical. You connect your domain through DNS, create your redirect rules, and Redirect Supply handles the requests.

The infrastructure is there. You just don’t have to manage it.

We wanted the setup to feel as simple as the redirect

The product itself follows the same idea.

Add your domain and Redirect Supply gives you the DNS records you need. Once you add them at your DNS provider, we check the setup automatically.

Your domain starts as Pending and changes to Connected once everything is ready.

From there, you create your redirect rules.

The basic flow is:

  1. Add your domain.

  2. Add the generated DNS records.

  3. Wait for the domain to become Connected.

  4. Create your redirect rules.

  5. Test them and you’re done.

You can redirect an entire domain or create rules for individual URLs, depending on what you’re trying to move.

There’s still real infrastructure behind all of this. The point is that managing it shouldn’t become your problem.

Because redirects tend to outlive websites

This was probably the biggest reason for separating redirects from hosting in the first place.

Websites are temporary in a way URLs often aren’t.

You rebuild a website. Switch CMS. Change agencies. Move hosting. Update the brand. Eventually, the website you launched a few years ago may have almost nothing in common with the one that’s online today.

But links to its old URLs can still be everywhere.

That makes redirects less like a feature of one particular website and more like infrastructure that sits between different versions of your presence online.

Once we started looking at them that way, keeping redirects tied to the website itself made less and less sense.

That’s Redirect Supply

We didn’t set out to make redirects more complicated or turn them into another big piece of software you need to manage.

Quite the opposite.

Redirect Supply exists so that when a URL needs to go somewhere else, there’s a clear place to make that happen. No old website kept online just for redirects. No digging through server configuration. No wondering where a rule was created the last time someone touched the site.

Connect the domain. Set the rules. Let the redirects keep working even when everything around them changes.

Redirects are simple.

Managing them should be too.

Ready to keep every link alive?

Ready to keep every link alive?

Ready to keep every link alive?