WordPress redirects: three paths, one default code

A WordPress redirect comes from one of three places: a redirect plugin, a rule in the web server's configuration, or code that calls the wp_redirect() function. The function's default status is 302, a temporary redirect, so a permanent move made in code has to say so. Which kind of redirect a visitor gets depends on the path.

The three paths

Each path stores the rule in a different place, and that decides who can change it and what survives a redesign.

A plugin is the usual choice for a site run by editors: rules are listed in one screen, and nobody needs to touch a file. A server rule answers before WordPress loads, which suits large sets of rules and moves of a whole site. Code is for redirects that depend on logic, such as who is logged in or what a form returned.

WordPress already redirects some moves

WordPress handles one common case on its own. When the address of a post changes, the core function wp_old_slug_redirect(), described in the developer reference as "Redirect old slugs to the correct permalink", sends requests for the old address to the new one, and its source calls wp_redirect( $link, 301 ): a permanent redirect.

The same source carries a limit: "Do not attempt redirect for hierarchical post types." Pages are a hierarchical type, so renaming a page does not produce this automatic redirect. A changed page address needs a rule from one of the three paths, or the old address will answer with a 404.

The code path defaults to 302

The function has a default that matters. Its signature in the WordPress developer reference gives the status as $status = 302, and the safer variant, wp_safe_redirect(), has the same default. A redirect written without a status is temporary.

Google treats temporary redirects differently from permanent ones: its documentation on redirects, last updated on 2026-04-14 and checked on 2026-10-09, says a temporary redirect is followed but not used "as a signal that the redirect target should be canonical." A theme that moved pages with a bare call has told search that every move is temporary. What a 302 redirect is actually for is covered separately.

The reference also adds a note about the call itself: "wp_redirect() does not exit automatically, and should almost always be followed by a call to exit". Its own example, quoted as given and checked on 2026-10-09:

wp_redirect( $url ); exit;

For a permanent move, the status is passed as the second argument, as the core's own wp_redirect( $link, 301 ) does.

Plugins and server rules

A redirect plugin keeps rules in the database and applies them as WordPress handles the request. That makes it easy to edit and to review, and it means the rule only works while WordPress runs: if the plugin is deactivated, its redirects stop. Before choosing one, check which status it uses by default and whether you can set it per rule.

A server rule works without WordPress at all. On Apache the usual place is the site's .htaccess, which WordPress also writes to for its permalinks; rules added by hand belong outside the block WordPress manages, so they are not overwritten. The .htaccess redirect page covers the directives and their own default, which is also 302. On nginx, rules go into the server configuration, and a hosting company may manage that for you.

What survives a change

A redirect is only as durable as the place it lives. Rules in a theme disappear when the theme is replaced, which is a common way for a redesign to break years of old addresses. Rules in a plugin disappear when the plugin is removed. Rules in the server configuration survive both, and are lost instead in a move to a different host or server.

Keep a list of redirects outside all three places, with the old address, the new one, the status and the date. It is the record that lets the rules be rebuilt wherever they end up.

Moving many addresses at once

A change of permalink structure, a merge of categories or a move to a new domain changes hundreds of addresses in one step, and the order of work decides whether it goes quietly. Export the list of old addresses before anything changes, while they still answer. Map each one to its new address, one to one, rather than sending everything to the home page. Apply the rules in a single place, then test a sample that includes old posts, pages, category archives and addresses with query strings.

The overview of redirects covers the risk of patterns that match more than intended; on WordPress, the same risk sits in a plugin's wildcard rules as much as in a server file.

Checking the result

Check the response, not the settings screen. Request the old address and read the status line and the Location header it returns; a moved page should answer with 301 or 308 and the new address, in one hop. Two paths answering the same address show up as a chain of hops; how a trace reads each one is covered under redirect tracing.

When a redirect does not behave as configured, ask which path issued it. A server rule answers before a plugin gets the request, so a forgotten line in .htaccess can override everything the admin screens say.

FAQ