Permanent redirects are hard to take back

A redirect is a single response: a status code saying "this lives elsewhere" and a Location header saying where. The browser makes a second request to the new address, and the visitor usually never notices. The interesting part is the status code, which is not cosmetic — it decides how long the answer is believed.

Permanent and temporary

301 is permanent: this URL has moved and is not coming back. 302 is temporary: go here for now, but keep asking the original. There are two newer equivalents, 308 and 307, which mean the same two things but preserve the request method — a POST stays a POST instead of being turned into a GET, which matters for form endpoints and not much else.

Search engines read the difference directly. A permanent redirect is an instruction to consolidate onto the new URL and eventually drop the old one from the index. A temporary redirect is an instruction to keep the original URL as the one to show. That is the whole reason to be deliberate: the status code is how you tell a crawler which address you want to own.

Why the choice sticks

Permanent redirects are cacheable, and browsers cache them enthusiastically. If the response carries no explicit cache lifetime, a browser is free to keep it for a long time. Once a visitor's browser has recorded that /old permanently goes to /new, it stops asking you. It performs the redirect locally, before any request goes out.

So consider changing your mind. You delete the redirect from your config and deploy. Every fresh visitor gets the new behaviour. The visitor whose browser cached the old answer keeps landing on /new, from a decision made on their machine, in a request you never see and cannot correct from the server. The usual remedy is to put a second redirect at /new pointing back — which is another permanent decision, taken to undo the first one — or to wait it out and accept that some people are on the wrong page in the meantime.

That gives a rule worth following: if you are not certain the move is final, use a temporary redirect. A temporary one costs you some consolidation of ranking signals while it is in place. A permanent one costs you an open-ended cleanup on machines you do not control. You can always upgrade a temporary redirect to a permanent one once the move has settled. Going the other way is the hard direction.

One practical corollary: do not test a new permanent redirect in your normal browser window. The first request caches it, and every check after that is reading your own cache rather than your server. Use a private window, or a command-line client, and open a fresh one each time you change the rule.

Chains

Every hop is a full round trip — a request out, a response back, and only then the real request. Two redirects in a row usually means one of them is unnecessary.

The classic accidental chain has three hops and nobody built it on purpose. A visitor opens http://www.example.com/old. The HTTPS upgrade sends them to https://www.example.com/old. The canonical-host rule sends them to https://example.com/old. The path rule finally sends them to https://example.com/new. Each rule is individually correct; together they cost three round trips before a byte of the page is requested, on connections where round trips are the slow part.

Collapsing it is mostly bookkeeping. Make the host rule land on the canonical host over HTTPS in one step rather than fixing the scheme and the host separately, and point path redirects at the final URL rather than at another URL that will itself be redirected. When you move a page twice, update the first redirect to point at the newest location instead of leaving it aimed at the middle one.

The failure at the end of that spectrum is a loop: /a to /b and /b back to /a. Browsers stop after a limited number of hops and show an error, so a loop does not hang — it makes a section of the site unreachable, and it is easy to create by adding a tidy-up rule that overlaps with one already in place.

The tool

The Redirects generator takes your domain, a canonical-host choice and a comma-separated list of from>to pairs. It writes a _redirects file for Cloudflare Pages or Netlify with one line per pair, adding the leading slash if you left it off, plus a commented-out fallback line for a custom 404. Separately it prints a Cloudflare Redirect Rule for the canonical host in either direction, because a host-level redirect is domain-wide and does not belong in a path-level file.

One thing to know before you paste the output: every path line it writes uses 301. That is the right default for a page that has genuinely moved and the wrong one for anything you might reverse. If the move might not stick, change that 301 to a 302 before you deploy the file — it is a two-character edit now, and considerably more work later.