Set up redirections

Redirections are a site setting: lines mapping a source pattern to a destination, with an optional status code. They matter most in the three moments where URLs move: a redesign, a slug change, and the day a site turns multilingual — which re-homes every URL under a locale prefix and leaves the old bare addresses answering 404.

1. Decide the status code

A 301 written by mistake is expensive: browsers remember it, so the fix does not reach the people who already got it.

2. Compose the lines

One redirection per line, space-separated: a source pattern, a destination, an optional status code (301 when omitted). The source is a regex matched against the URI, and parentheses capture into {$1}, {$2}… — the full format is in the reference.

This is the block composed for Lisière after its language pass, covering both classic moments at once:

# The site went bilingual — the bare pre-i18n URLs no longer exist
^/the-review$ /en/the-review
^/section/(.*)$ /en/section/{$1}
^/article/(.*)$ /en/article/{$1}

# A slug was translated after launch — the old address retires
^/fr/article/the-watershed-line$ /fr/article/la-ligne-de-partage-des-eaux

Anchor the patterns (^…$). An unanchored literal like /the-review is still a regex, and a substring match against /en/the-review — whose destination contains the source — is how a redirect loop is born.

Where the lines go

Content management → Redirections, in the left rail, between Routes and Dictionnary. It is one text area with line numbers, and a Save that applies the whole block at once — so the file is the unit, not the rule. Keep it in your repository too if you value the history; the editor has no diff.

That is the practical reason to keep the set small and anchored: the feedback loop runs through a deploy.

3. Handle the multilingual case

On a bilingual site, one moved page is usually two URLs — one rule per locale prefix, nothing is expanded for you. And the slug-translation case only concerns the locale whose slug changed: the engine already retired the old address (it answers the not-found branch), so the redirection's job is to carry its accumulated traffic to the new one.

4. Let an agent compose the block

This is the guide's natural delegation: the rules are mechanical, the volume is what hurts, and the output is text you read before it goes anywhere.

Here are the URLs that moved: <old> to <new>, one pair per line.
Compose the redirection block: one rule per line, patterns anchored with ^ and $,
301 unless I mark a pair temporary, and one rule per locale prefix on the bilingual paths.
Give it back as text — there is no API for this, so do not try to apply it.

That last line matters more than it looks. No MCP tool and no CLI command writes redirections, so an agent that reports having applied them has done something else — patched miscellaneous, most likely, which rejects the key. Composing is the whole of what it can do here.

Read the anchors before pasting. An unanchored pattern is the one failure that does not show up in review and does not show up in a test either — it shows up as a loop, the day real traffic hits the substring you did not think about.

5. Test them

Test with the redirect not followed, so you see the status code rather than the destination page:

curl -sI https://example.com/old-path | head -2

You want the code you chose, and a location header pointing exactly where you meant, including the trailing slash and the locale prefix.

6. What redirections should not fix

A redirection is not a substitute for a working route. If a detail page 404s, the cause is upstream, an inactive page, a route path without its leading slash, or a missing detail page-type. See Troubleshooting.

Related