Cloudflare Pages redirects: the 301 playbook

Guide October 21, 2026

Built 2026-09-22
Stack Astro 5 static · Cloudflare Pages · Astro redirects config
Total cost $10.46/year, all in

I renamed a published article last week. The build went green, I pushed, and the old URL started returning 404 — because renaming a file is not a redirect. If you move content on Cloudflare Pages, you have to say so, or every link and every indexed URL dies.

The Astro → Cloudflare Pages walkthrough gets you to a live site; the setup gotchas list covers the surprises. This is the one about keeping old URLs alive.

What Cloudflare does for you already

Two redirects are free and automatic, so don’t hand-roll them:

• HTTP → HTTPS is forced at the edge.
• The pages.dev → custom domain handoff is handled when you attach the domain.

You only need to configure redirects for content moves: renamed pages, restructured paths, trailing-slash changes, or www consolidation.

Method 1 — the _redirects file

Drop a file named _redirects in your project root (or in public/, which copies it to the output). Cloudflare Pages reads it at deploy time:

/old-path/        /new-path/        301
/tools/old-name/  /tools/new-name/  301

Rules are first match wins, and order matters — put specific rules above catch-alls. The third column is the status code; 301 for permanent moves, 302 for temporary. Omit it and you get a 302 by default, which Google treats as “come back later” and won’t consolidate ranking. Use 301 for anything permanent.

This is a true edge redirect — fast, no HTML round-trip.

Method 2 — Astro’s redirects config

For a static Astro site, you can also declare redirects in astro.config.mjs:

export default defineConfig({
  redirects: {
    '/tools/old-name/': '/tools/new-name/',
  },
});

Astro emits a tiny HTML page at the old path with a meta refresh and a <link rel="canonical"> pointing at the new URL. It is not a server-side 301 — it’s a client-side redirect plus a canonical tag. For moved content that’s fine: the canonical tells Google the new URL, and browsers follow the refresh. But if you want a true edge 301 without a redeploy, use Method 1 or 3.

I used this for the rename above. It works, but know what it is: a redirect page, not a redirect rule.

Method 3 — Cloudflare Bulk Redirects (dashboard)

For many redirects, or host-level redirects you don’t want to bake into the repo, use Rules → Redirects → Bulk Redirects in the dashboard. You build a list of source→target pairs and a redirect rule that applies them at the edge, no redeploy needed.

This is the better tool when the redirects outnumber your content changes — say, consolidating an old site’s URL scheme into the new one.

The trap: a bare git mv 404s

The mistake I made: rename the file, push, assume the URL follows. It doesn’t. Until you add a redirect (any of the three above), the old path returns 404 on the next deploy, and every link — internal, indexed, or shared — breaks.

If you also hit a build-failure rabbit hole while moving things, that’s a separate problem covered in Astro builds failing on Cloudflare Pages.

What I’d tell myself

Decide the redirect before you rename. For one or two moves, the _redirects file is simplest and gives a real 301. For a static Astro site, the config redirects map is fine if you’re already in the repo. For bulk or host-level moves, do it in the dashboard. And never rename a file without adding the matching rule — a 404 where there used to be a page is the kind of thing that quietly costs you rankings.