Redirect rules belong in version control, not your admin panel

You're managing redirects in the wrong place

Most people add a redirect by logging into a plugin settings page or their hosting dashboard, typing in the old URL, typing in the new URL, and clicking save. It works. The redirect happens. Then six months later someone rebuilds the site, migrates hosts, or updates the plugin, and half your redirects vanish. You don't notice until search traffic drops or someone sends you a broken link.

Redirects are infrastructure. They belong in a file you can read, diff, and deploy—not buried in a database table or scattered across admin screens.

Keep redirects in a flat file

Create a redirects file in your project repository. Format depends on your setup: .htaccess for Apache, _redirects for Netlify, vercel.json for Vercel, nginx config for nginx. Whatever the syntax, the file lives in version control alongside your templates and content model.

Every time you move or delete a page, you add a line to that file before you deploy. The redirect and the content change ship together. No separate step. No separate login. No separate person who remembers where the redirect UI lives.

Document why each redirect exists

In six months you won't remember why /old-services points to /solutions. Neither will anyone else. Add a comment above each redirect or group of redirects explaining what changed and when.

# 2025-01-15: Renamed "services" to "solutions" in rebrand
/old-services /solutions 301
/services/consulting /solutions/consulting 301

Comments make it safe to clean up old redirects later. If you see a redirect from 2019 and the comment says "temporary during site migration," you know it's safe to remove.

Redirects are content decisions

When you define your URL structure before you create content, you're making promises about where things live. Redirects are how you keep those promises when things move. They're not technical cleanup—they're part of your information architecture.

Treat them like the rest of your content model: explicit, documented, and versioned.