Redirects come up in two real scenarios: migrating from another platform where old URLs need to keep working, and general URL cleanup on an existing EmDash site. EmDash's documented mechanism for the first is a proper, validated schema in the seed file. This covers both cases honestly.

The Redirects Schema

A seed file's `redirects` array defines rules that preserve legacy URLs:

{
  "redirects": [
    { "source": "/old-about", "destination": "/about" },
    { "source": "/legacy-feed", "destination": "/rss.xml", "type": 308 },
    {
      "source": "/category/news",
      "destination": "/categories/news",
      "groupName": "migration"
    }
  ]
}

The full property reference:

• source (required) — the old path, must start with /.
• destination (required) — the new path, must start with /.
• type (optional) — HTTP status: 301, 302, 307, or 308. Omit for the platform default.
• enabled (optional) — whether the rule is active; defaults to true.
• groupName (optional) — a label for filtering/searching redirects in the admin, useful for tagging "all the redirects from the March migration" as one group.

source and destination must be local paths. External URLs, protocol-relative paths, path traversal segments, and newline characters are rejected by seed validation.

That validation is a real, deliberate constraint — redirects are for reorganizing your own site's URL structure, not for pointing at arbitrary external destinations, which closes off a potential open-redirect vector by design.

Choosing the Right Status Code

• 301 (Moved Permanently) — the standard choice for a page that's permanently moved; search engines transfer ranking signal to the new URL.
• 302 (Found) — temporary redirect; use when the old URL might come back (a seasonal page, an A/B test).
• 307/308 — method-preserving equivalents of 302/301, relevant mainly for non-GET requests.

For most migration and URL-cleanup scenarios, 301 is the right default.

Redirects From a WordPress Migration

EmDash's WordPress import generates a redirect map automatically, covering the URL patterns that change during migration:

{
  "redirects": [
    { "from": "/?p=123", "to": "/posts/hello-world" },
    { "from": "/2024/01/hello-world/", "to": "/posts/hello-world" },
    { "from": "/category/news/", "to": "/categories/news" }
  ],
  "feeds": [
    { "from": "/feed/", "to": "/rss.xml" }
  ]
}

That generated map uses `from`/`to` rather than the seed schema's `source`/`destination` — reconcile the field names when converting it into your seed file's `redirects` array, or apply it directly through your hosting platform's own redirect rules (Cloudflare redirect rules, or Astro's own `redirects` config option) if you'd rather not route it through the seed mechanism at all.

When You Add Redirects Matters

Seed files apply automatically only when a database is empty and setup hasn't been completed — that's the mechanism for a fresh install or a from-scratch migration, not for adding one new redirect to an already-live site. For redirects needed after initial launch (you renamed a page, restructured a URL), the two practical options are:

• Astro's own redirects config in astro.config.mjs, for redirects your codebase should own directly.
• Your hosting or CDN's redirect rules (Cloudflare Redirect Rules, or your Node.js host's equivalent), for redirects you want to manage outside your codebase entirely.

// astro.config.mjs
export default defineConfig({
  redirects: {
    "/old-about": "/about",
    "/legacy-page": { status: 301, destination: "/new-page" },
  },
});

A Realistic Migration Checklist

1. During migration, capture every generated or known old-URL-to-new-URL mapping.
2. Convert them into the seed file's `redirects` array (source/destination/type/groupName) if bootstrapping a fresh site.
3. Tag them with a `groupName` (e.g. "2026-migration") so you can find and audit them later.
4. For anything discovered after the initial launch, add it via Astro's `redirects` config or your hosting platform's rules instead.
5. Spot-check a sample of old URLs post-launch to confirm they actually redirect rather than 404.

Frequently Asked Questions

Do redirects apply automatically on every deploy, or just the first one?

The seed file's redirects apply when bootstrapping a fresh, empty database — not on every subsequent deploy of an already-running site, the same rule that governs the rest of the seed file's content and schema.

Can I point a redirect at an external domain?

No — seed validation explicitly rejects external URLs in `source` or `destination`, restricting redirects to local path-to-path rules within your own site.

Should I use EmDash's redirect schema or Astro's redirects config?

For a fresh migration or initial launch, the seed file's redirects array is the documented, purpose-built mechanism, especially useful with `groupName` for tracking a batch. For ongoing, post-launch redirect additions, Astro's own config or your hosting platform's rules are the more practical path.

What if I have hundreds of redirects from a large migration?

The seed schema handles this fine as a large array with no documented limit, and `groupName` becomes genuinely useful at that scale for filtering the admin view down to a specific migration batch rather than scrolling through everything.

The Bottom Line

EmDash's redirect schema — source, destination, status type, and an optional group label — is a real, validated feature purpose-built for migrations, most useful when bootstrapping a fresh site from a seed file. For redirects added after a site is already live, Astro's own `redirects` config or your hosting platform's rules are the more practical, always-available path. See our guide to migrating from WordPress for where the generated redirect map in that flow comes from.