WordPress Redirects: 301s, Plugins and Server Rules

• 301 Moved Permanently — this URL has moved for good. Search engines transfer the signals to the new URL and update the index. This is what you want for almost every redirect.
• 302 Found — temporary. The original URL is coming back, so search engines keep it indexed and don't transfer anything. Using 302 for a permanent move is a common and costly mistake.
• 307 Temporary Redirect — like 302 but preserves the request method. Relevant for form submissions, rarely for content.
• 308 Permanent Redirect — like 301 but preserves the method. Used for canonical domain redirects at the server level.
• 410 Gone — not a redirect. Says this URL is deliberately removed with no replacement. More honest than redirecting to an unrelated page, and it gets the URL out of the index faster than a 404.

There are three places a redirect can live in a WordPress site, and they differ in speed and in who can manage them.

• Server level — .htaccess on Apache, a rewrite rule on Nginx, or edge rules at your CDN or host. Fastest, because the request is answered before PHP starts. Needs server access and a deploy to change.
• Plugin — a redirect plugin storing rules in the database and matching them in PHP on a 404. Slower, because WordPress boots first, but manageable by anyone through the admin and easy to audit.
• Code — a hook in a site-specific plugin. Sits between the two: version controlled and deployable, but still runs in PHP.
• The pragmatic answer for most sites: server or edge level for site-wide rules (HTTPS, canonical hostname, a whole directory moving), and a plugin for the long tail of individual page moves that editors need to manage.

WordPress redirects more than people realise, and knowing this saves you creating rules that already exist.

Changing a post's slug leaves an old-slug record, and WordPress redirects the old URL to the new one automatically. This is genuinely useful and it's why some slug changes don't break anything.

Its canonical redirect also normalises URLs: adding or removing trailing slashes, redirecting /?p=123 to the pretty permalink, and correcting some capitalisation. Attachment pages and feeds get their own handling.

The guessing behaviour is less welcome — when a URL doesn't match, WordPress tries to find a similar one and redirects to it rather than returning a 404. That occasionally sends visitors somewhere baffling, and it can be disabled.

These are the two ways a redirect map goes wrong, and both are invisible until you look.

A chain is A redirecting to B redirecting to C. Every hop costs the visitor time, and search engines eventually stop following. Chains build up naturally: a page moves, then moves again, and nobody updates the first rule. Collapse them so every old URL points straight at the final destination.

A loop is A redirecting to B redirecting back to A. The browser gives up with an error and the page is simply unreachable. The usual cause is two systems both trying to enforce something — WordPress forcing HTTPS while the server also forces it, or a plugin rule contradicting a server rule.

Decide which layer owns each rule. Two layers enforcing the same thing is how loops happen.

• Map every old URL to its closest equivalent, individually. Never bulk-redirect to the homepage — search engines treat that as a soft 404 and you lose what those pages earned.
• Where there's genuinely no equivalent, use a 410 rather than redirecting somewhere unrelated.
• Test the map before it goes live. A spreadsheet of a thousand rules contains typos, and you'll otherwise find them via lost traffic.
• Keep redirects in place indefinitely. Old links and bookmarks send people for years, and the cost of keeping a rule is near zero.
• Also update the internal links pointing at old URLs. Redirects are a fallback for external links, not a substitute for fixing your own.

On a site that's been running a while, the redirect list is usually longer than anyone expects and contains rules nobody can explain.

• Export the full list and check each rule still has a working destination. Rules pointing at pages that were later deleted are a common find.
• Crawl the site and look for internal links that pass through a redirect — those should point directly at the destination.
• Look for chains and collapse them.
• Look for regex rules that match more than intended. A broad pattern written for one case can silently capture URLs added later.
• Check for rules created by plugins you've since removed.
• Watch the 404 log for URLs that should be redirected and aren't — that's your list of missing rules.

A redirect plugin that matches thousands of rules in PHP on every 404 is doing real work. On a site with a large map and a lot of bot traffic hitting nonexistent URLs, that adds up.

If your map is large and stable, moving the bulk of it to server or edge level is a genuine improvement — the request is answered before WordPress loads at all. Keep the plugin for the rules editors need to manage themselves.

Also check that your redirect plugin isn't logging every 404 indefinitely. Those logs grow fast and are rarely pruned.

• 302 used for a permanent move, so the old URL stays indexed and the new one never inherits anything.
• Redirecting HTTP to HTTPS in two places, producing a loop.
• A regex rule that matches far more than intended.
• Redirects that strip query strings when something depended on them — tracking parameters, or a filter state.
• Case-sensitivity differences between the rule and the actual URLs.
• Redirecting a page that still had value, when the right answer was to improve it.