How to redirect a page in WordPress without losing traffic

You renamed a page, deleted a product or moved the site to a new domain. The old URL still sits in Google, in old emails and on other people’s sites, and right now it leads to a 404. A redirect sends that old address to the right new one and tells search engines whether the move is permanent.

Most sites need one plugin, a few minutes and a careful test. What goes wrong is rarely the rule itself. It is a second rule, somewhere else, that disagrees with it.

What do people mean by a “WordPress redirect page”?

Usually they mean a URL redirect, and that is what this guide covers. The phrase also gets used for four other things, and each one has a different fix:

• A URL redirect. An old URL forwards to a new one with a 301 or 302 status. This is the one that matters for SEO.
• A destination page. The page people land on after a login, a checkout, a form or a QR scan. These come from a plugin or WooCommerce setting, not from a redirect rule.
• A 404 page. When nothing relevant replaces the old URL, the honest answer is a helpful 404. Our guide to customizing the WordPress 404 page covers that.
• A page that forwards to another site. For example an affiliate link or a Linktree page. Use a redirect rule here too. Building a page and redirecting away from it is unnecessary.
• A redirect that is broken. “Too many redirects”, a login loop, or a rule that never fires. These are covered further down.

If you are changing URLs as part of a wider cleanup, the redirect decisions belong inside your WordPress SEO basics. Change a URL only once you have its redirect ready.

Should the redirect be a 301 or a 302?

Use a 301 when the move is permanent and a 302 when the original URL will come back. Google’s documentation on redirects treats 301 and 308 as permanent and 302 as temporary. Google uses a permanent redirect as a strong signal that the new URL is the one to show.

Renamed pages, merged posts, HTTPS moves and domain changes are all 301s. A seasonal promotion that takes over a URL for a month is a 302.

There is one practical exception. Browsers cache 301s, so a visitor who has followed one may never ask your server again. If you print a QR code or run a campaign link whose destination you will keep changing, use a 302 so a change actually reaches people. WooCommerce follows the same logic: its Product 404 Redirects extension sends trashed or private products through a 302 and permanently deleted ones through a 301.

Where should the redirect live on your site?

On most single sites, put it in a plugin. Redirects can be set in WordPress, on the server, in the host’s dashboard or at a CDN such as Cloudflare. Each layer has a job it does best:

Layer	Good for	Watch out for
A redirect plugin	Individual pages, 404 logs, importing a spreadsheet of old and new URLs	It only sees requests that reach WordPress. A PDF the server delivers directly never reaches the plugin.
.htaccess	Server-level rules on Apache or LiteSpeed	Nginx ignores it. A typo can give you a 500 error across the whole site.
Host redirect tool or Nginx config	Managed hosts and Nginx servers	Every host does it differently. Read their docs.
Cloudflare or DNS-level rules	Whole domains, especially an old domain after a rebrand	It is easy to forget a rule here when you are debugging WordPress.

Check your host before you write server rules. WP Engine, for example, has deprecated .htaccess and points customers to its portal rules, Nginx configuration or a plugin. If you are on Apache and want rules outside WordPress, our guide to writing .htaccess 301 redirects has the syntax.

For an old domain after a rebrand, keep the domain registered and redirect each page to its matching new page. Something still has to answer requests on the old domain. A Cloudflare or server rule is usually cheaper and simpler than keeping a second WordPress install running just to send visitors on.

How to redirect a page with the Redirection plugin

Redirection is the plugin most people recommend for this. It is free, it has no paid version, and its WordPress.org listing shows more than 2 million active installations. You need an administrator login, the old URL and the new URL.

1. Go to Plugins > Add New, search for Redirection, install it and activate it.
2. Open Tools > Redirection and complete the short setup. It can watch for permalink changes and log 404s. Turn on the 404 log, because it shows which dead URLs people actually visit.
3. Click Add New. In Source URL, enter the old path, for example /old-services-page/.
4. In Target URL, enter the full new address, for example https://example.com/services/.
5. Open the extra options and set the HTTP code to 301 for a permanent move, or 302 for a temporary one.
6. Save. Then test it as described below, not just in your logged-in browser.

Moving more than a handful of pages? Build the list in a spreadsheet with one row per old URL, then use Redirection’s import. For a redesign or migration, crawl the old site first so the list contains every URL, not just the ones you remember. If you would rather describe the change in chat and have it made and checked for you, that work is covered on our SEO and redirects page.

Where should each old URL point?

Point it at the page that does the same job as the old one. An old product goes to its replacement or, failing that, its category. An outdated guide goes to the guide that replaced it. Someone who clicked a link about blue running shoes and lands on your homepage has hit a dead end that just looks nicer.

That is why blanket “send every 404 to the homepage” plugins are a poor shortcut, popular as some of them are. If nothing replaces the old page, let it return a proper 404 with good navigation.

Two more rules from Google’s guidance on site moves:

• One hop, no chains. If page A already redirects to B and B now moves to C, edit the first rule to go straight from A to C. Then update your own links so they point at the final URL. Our guide to fixing internal links explains why every extra hop costs visitors and crawlers time.
• Keep migration redirects for at least a year where you can. Most owners keep them indefinitely. A rule that gets a few hits a month may still be catching a valuable backlink.

How do you check that the redirect worked?

Open the old URL in a private window, logged out. You should land on the new page in one step. Your admin session and cached pages can hide problems that a new visitor would see.

Then check the status code. A redirect checker shows each hop. From a terminal, this does the same:

curl -sI https://example.com/old-services-page/

A correct result shows HTTP/2 301 (or 302 if you chose that) and a location: line with your new URL. Running the same command on the new URL should return 200. If you see a second 301, you have a chain.

What if the redirect doesn’t fire?

The Redirection plugin’s support page lists the usual reasons, and they apply to most tools:

• Cache. Your browser or a page cache is serving the old response. Purge the site cache, the host cache and the CDN, then retest in a private window.
• No match. The rule does not match the URL. Check the trailing slash, capital letters and any query string.
• The server answered first. Files such as PDFs are often served directly, so WordPress never sees the request. Redirect those in .htaccess or the Nginx config, or delete the file if appropriate.
• Something else redirected it. Another plugin, a theme, or WordPress’s own canonical redirect got there first.

The opposite problem catches people too: a redirect you never created. WordPress sometimes redirects an old post slug on its own, and it guesses at mistyped URLs. If a visitor ends up on an old post, check whether a rule exists at all before you hunt for it. Unexpected redirects that only happen to logged-out mobile visitors arriving from Google are a common malware symptom. Our malware removal guide covers that.

How do you fix “too many redirects”?

A redirect loop means two rules are sending the request back and forth. Chrome shows ERR_TOO_MANY_REDIRECTS, Firefox says “The page isn’t redirecting properly”, and Safari says “Too many redirects occurred”. The fix is to find the pair of rules and remove one. Adding another redirect makes it worse.

These are the usual pairs:

• Cloudflare Flexible SSL plus a server that forces HTTPS. Cloudflare’s docs explain it: in Flexible mode, Cloudflare talks to your server over HTTP, your server redirects to HTTPS, and the request goes round again. Switch to Full or Full (strict) only once the server has a working certificate. The alternative is to remove the server’s HTTPS redirect.
• URL settings that disagree. WP_HOME and WP_SITEURL in wp-config.php override the Site Address and WordPress Address in Settings > General, according to the wp-config.php handbook. One using http and the other https is enough to loop, especially after a migration.
• HTTPS forced in two or three places. An SSL plugin, a caching plugin’s “Force SSL” option, .htaccess and Cloudflare’s Always Use HTTPS can all do the same job. Keep one.
• A pattern that catches its own target. A regex rule for /shop/.* that redirects to /shop/new/ matches its own destination. Anchor the pattern with ^ and make sure the target falls outside it. Never put the same URL in both fields.

Work from the cheapest check to the most invasive one. Try a private window and clear the site’s cookies. Purge every cache. Compare the four URL values. Check the Cloudflare SSL mode. Rename wp-content/plugins to test whether a plugin is responsible, then restore the folder and reactivate plugins one at a time. As a last step, back up .htaccess, rename it, and save Settings > Permalinks to regenerate WordPress’s own rules. Inner pages return 404 until you do. Also, deactivating a plugin does not always remove rules it already wrote to .htaccess.

When to stop and get help: if the loop is in wp-admin and you cannot reach the database or the server files, if you are on Nginx and the rules live in server config, or if redirects appeared without anyone adding them. Ask your host for the first two. The third needs a security cleanup.

Redirecting from your own code

Developers adding a redirect in a theme or plugin should run it on the template_redirect hook, before any output. Redirect after output and you get “headers already sent”. wp_safe_redirect() defaults to a 302, sends unapproved external hosts to the admin URL instead, and does not stop execution. Always follow it with exit:

add_action( 'template_redirect', function () {
    if ( is_page( 'old-services-page' ) ) {
        wp_safe_redirect( home_url( '/services/' ), 301 );
        exit;
    }
} );

Prefer a server-side redirect like this over a timed meta refresh or JavaScript redirect. Those confuse visitors, screen reader users in particular, and search engines read them less reliably.