# WordPress redirects: plugin or server rule, and how to set up a 301

> How to redirect a page in WordPress with a plugin such as Redirection, Rank Math or Yoast SEO Premium, when a server rule is better, and what WordPress already redirects on its own.

Updated 2026-09-26 · WordPress & WooCommerce · HTML version: https://getreport.app/guides/wordpress-redirects

To redirect a page in WordPress, add a 301 redirect from the old address to the new one, either with a redirect plugin (Redirection, Rank Math's Redirections module or the redirect manager in Yoast SEO Premium) or with a rule on the server, above the WordPress block in `.htaccess`. A plugin is easiest for editors and a handful of pages; a server rule is faster and keeps working when plugins change. This guide shows both, what WordPress already redirects on its own, and how to avoid the chains and loops that come from having too many layers. For what a 301 is and why it keeps your rankings, read the [301 redirects guide](https://getreport.app/guides/301-redirects).

## Quick answer

- **Posts redirect themselves** when you change a published post's slug. Pages do not: a renamed page answers 404 until you add a redirect.
- **One plugin does the job.** Redirection is free and dedicated; Rank Math has a free Redirections module; Yoast SEO has a redirect manager in Premium only.
- **Use 301** for permanent moves. Check the status in the plugin; some tools and forms offer 302 first.
- **Server rules for big lists.** On Apache or LiteSpeed, put them above `# BEGIN WordPress` in `.htaccess`. They run before WordPress loads.
- **One layer per job.** Pick one place for page redirects, one for https and www. Two layers doing the same thing is how loops start.
- **Test from outside the browser** with the [redirect checker](https://getreport.app/tools/redirect-checker): one 301, then a 200.

## What WordPress redirects on its own

Before you install anything, know what WordPress core already does, because it shapes what you need a plugin for.

**Changed post slugs.** When you change the slug of a published post, WordPress stores the old slug and answers the old URL with a 301 to the new one. The WordPress source skips this for hierarchical post types, which means **pages are not covered**: rename `/services/` to `/what-we-do/` and the old page answers 404. Moving a page under a new parent changes its URL the same way.

**The canonical host and permalink form.** WordPress redirects requests to the host and scheme in Settings → General (WordPress Address and Site Address) and tidies URLs into your permalink format, such as adding the trailing slash. These are 301s too.

**Guessing on 404.** When a URL does not exist, WordPress tries to guess what you meant by looking for a post whose slug starts with the last part of the address, and redirects there with a 301. This is why a mistyped URL sometimes lands on a vaguely related post. It is convenient, but it can also hide 404s you should fix properly, and it may send an old URL to the wrong page. Developers can switch it off with the `do_redirect_guess_404_permalink` filter, or make it exact-match only with `strict_redirect_guess_404_permalink`.

Everything else, renamed pages, merged posts, a new category structure, old URLs from a previous site, needs a redirect that you add.

## How to redirect a page in WordPress with a plugin

A redirect plugin stores rules in the database and answers matching requests from PHP. That makes it easy for anyone with a WordPress login, and the better plugins log 404s so you can see which old URLs still get visits.

### Redirection (free)

Redirection is a free plugin dedicated to redirects. To add one:

1. Install and activate **Redirection**, then run its short setup under **Tools → Redirection**. It can monitor permalink changes on posts and pages and add redirects automatically; turn that on.
2. Click **Add new**.
3. **Source URL:** the old path, such as `/old-page/`.
4. **Target URL:** the new address, such as `/new-page/`.
5. Open the options if you need them and check the HTTP code is **301 Moved Permanently**, then save.

It supports 301, 302, 303, 307 and 308 redirects, returning a 410 or another error instead of a redirect, regular expressions for patterns, redirects based on conditions such as login status, and import and export in CSV, `.htaccess` and nginx formats. Its **404s** log is the most useful part after a relaunch: sort by hits and add a redirect for every old URL that still gets traffic.

### Rank Math (free module)

If you already use Rank Math, you do not need a second plugin:

1. Go to **Rank Math SEO → Dashboard** and turn on the **Redirections** module.
2. Open **Rank Math SEO → Redirections → Add New**.
3. Enter the source path, the destination and the type, **301 Permanent Move**, and save.

The module also offers 302, 307, 410 and 451, and matches sources by exact URL, "contains", "starts with", "ends with" or a regular expression. Its Auto Post Redirect setting creates a 301 automatically when a post's URL changes.

### Yoast SEO Premium

The free Yoast SEO plugin has no redirect manager. In **Yoast SEO Premium**, go to **Yoast SEO → Redirects**, enter the old URL, the new URL and the type (301, 302, 307, 410 or 451), and save. Premium also asks whether you want a redirect when you change a slug or delete a page, which catches the page-slug gap core leaves open. It imports from other redirect plugins, CSV and `.htaccess`, and on Apache it can write redirects to `.htaccess` instead of answering them from PHP.

### Which WordPress redirect plugin to choose

| Plugin | Price for redirects | Best for |
| --- | --- | --- |
| Redirection | Free | Any site; strongest 404 log and import/export |
| Rank Math Redirections | Free module | Sites already on Rank Math |
| Yoast SEO Premium | Paid | Sites already paying for Yoast Premium |

Pick one. Two redirect managers, or an SEO plugin's module plus Redirection, means two lists of rules that nobody compares, and the day one sends `/a` to `/b` while the other sends `/b` to `/a`, you have a loop. If you switch, import the old list into the new tool and switch the old one off.

## When a server rule is better than a plugin

A plugin redirect fires only after the server has started PHP, loaded WordPress and queried the database. On a fast host that costs little; on a slow or busy one it adds noticeable time to every redirected request, and page caches often do not store redirects. A server rule answers before WordPress loads.

Use server rules when:

- **The list is long,** such as hundreds or thousands of URLs from a migration.
- **The redirect is site-wide,** such as http to https or non-www to www. These belong on the server or CDN, never in a plugin.
- **The site is changing platform or plugins,** because server rules keep working when a plugin is switched off.

On Apache and LiteSpeed hosting, add rules to `.htaccess` in the site root, **above** the `# BEGIN WordPress` line. WordPress rewrites only what sits between its own markers, so rules above it survive permalink changes and updates:

```apache
# .htaccess — above # BEGIN WordPress
RewriteEngine On
RewriteRule ^old-page/?$ /new-page/ [R=301,L]
RewriteRule ^services/?$ /what-we-do/ [R=301,L]

# BEGIN WordPress
# ...
```

On nginx hosting, WordPress cannot write the server configuration. Ask your host to add the rules, or use a plugin. The [setup guide for Apache, nginx, Cloudflare and WordPress](https://getreport.app/guides/301-redirects-htaccess-nginx-cloudflare-wordpress) has the nginx `map` pattern and the reasons a `.htaccess` rule sometimes does nothing. For a list of old and new URLs, the generator writes the rules for you:

> **Free tool:** [301 redirect .htaccess and nginx rule generator](https://getreport.app/tools/redirect-generator): Get 301 redirect .htaccess rules, or nginx, Cloudflare, Netlify, Vercel and Caddy rules, from your list of old and new URLs. Free, runs in your browser.

It runs in your browser, takes up to 10,000 rows, writes exact-match 301 rules for Apache, nginx and four other servers, and points chains in your list straight at their final page. Its WordPress note is the same as above: the rules go at the top of `.htaccess`, above the WordPress block.

## Decide which layer owns what

A typical WordPress site can redirect in four places: the CDN (such as Cloudflare), the web server, WordPress core and a plugin. Each is fine on its own. The trouble starts when two of them do the same job. Write down one owner for each kind of redirect:

| Redirect | Owner |
| --- | --- |
| http → https | Host, server or CDN, one of them only |
| www ↔ non-www | The same place as https, in the same rule |
| Renamed pages and posts | One redirect plugin, or `.htaccess` |
| Migration lists | Server or CDN |
| Changed post slugs | WordPress core, automatically |

Then make WordPress Address and Site Address in Settings → General match the https and www form your server enforces. A mismatch there, or Cloudflare's Flexible SSL mode in front of a server that forces https, is the classic cause of an endless loop; [ERR_TOO_MANY_REDIRECTS](https://getreport.app/guides/err-too-many-redirects) has the fixes.

## How to check a WordPress redirect

Your browser caches 301s, so a test in the same browser you used before can show the old result, or the new one after the rule is gone. Test from outside:

> **Free tool:** [Redirect checker: 301, 302 and redirect chains](https://getreport.app/tools/redirect-checker): Free redirect checker: follow every hop from your URL to the final page, with status codes, HTTP to HTTPS and www redirects, and the canonical at the end.

Enter the old URL. The checker follows every hop to the page that answers, lists each status code, requests the http and other www variant too, and compares the final page's canonical with its address. You want exactly one 301 or 308, then a 200 on a page whose canonical is itself. A 302 in the list means the plugin used a temporary type; change it.

After a relaunch or a batch of changes, paste all old URLs into the [bulk URL checker](https://getreport.app/tools/bulk-url-checker), or old and new pairs into the [migration redirect validator](https://getreport.app/tools/migration-validator), and fix every row that chains or lands somewhere else. The full getReport report also flags redirects on your pages:

> **Check: The URL loads without a redirect chain.** Each redirect is a full request and response before the browser can start loading the page, which slow mobile connections feel most. Google says redirects do not lose ranking value, but Googlebot follows at most 10 hops, and long chains slow crawling and break when one hop changes.
>
> 1. Point every old URL straight at the final one (a single 301), and update internal links to use the final URL directly.
> 2. Look for rules that stack, for example http → https, then non-www → www, then trailing slash; combine them into one rule.

> **Check: No link on the page goes through a redirect.** Every redirected link costs visitors an extra round trip, and a chain can break when one hop changes. Linking to the final URL is free.
>
> 1. Update each link listed in the technical detail to its final URL.
> 2. Search your templates and content for the old URLs after a domain, https or trailing-slash change.

Links in your menus and posts that still point at old URLs work, but every click pays for the extra hop. Update them at the source; [redirect chains and internal links that redirect](https://getreport.app/guides/redirect-chains-after-a-migration-finding-every-hop#internal-links-that-redirect-fix-them-at-the-source) shows how to find them. If you are moving a whole WordPress site to a new domain or host, follow the [WordPress site migration checklist](https://getreport.app/guides/wordpress-site-migration-checklist) instead of adding redirects one by one.

## Common mistakes

- **Renaming a page and assuming WordPress redirects it.** Only posts get the automatic redirect.
- **Redirecting deleted products or posts to the home page.** Google treats that like a missing page. Redirect to the closest equivalent, or let it answer 404 or 410.
- **Two redirect plugins, or a plugin plus server rules for the same URLs.** Chains and loops follow.
- **http or www redirects in a plugin.** They belong on the server or CDN, in one rule.
- **Deleting the redirect plugin during a clean-up.** Every rule it stored disappears with it. Export the list to server rules first.
- **Redirects for URLs that still exist.** Most plugins match before the page loads, so the old page is no longer reachable. Check you meant it.

## Questions people ask

### How do I redirect a page in WordPress?

Install a redirect plugin such as Redirection, go to Tools → Redirection → Add new, enter the old path as the source and the new address as the target, keep the type at 301 and save. Rank Math users can use its free Redirections module instead. Then test the old URL with a redirect checker: it should show one 301 and a 200.

### What is the best WordPress redirect plugin?

For most sites, the free Redirection plugin: it handles 301, 302, 307 and 308 redirects, regular expressions, CSV import and a 404 log that shows which old URLs still get visits. If you already run Rank Math, its free Redirections module does the same job without another plugin. Yoast SEO's redirect manager needs Premium.

### Does WordPress redirect old URLs automatically when I change a slug?

Only for posts and other non-hierarchical content. When you change a published post's slug, WordPress remembers the old one and answers it with a 301. Pages are skipped, so a renamed or moved page answers 404 until you add a redirect with a plugin or a server rule.

### Are plugin redirects slower than .htaccess redirects?

Yes, somewhat. A plugin redirect runs only after the server has started PHP and loaded WordPress, while an `.htaccess` rule answers before WordPress loads. For a few redirects on a fast host the difference is small; for large migration lists or slow hosting, server rules above the WordPress block in `.htaccess` are the better place.

### Why is my WordPress redirect not working?

Most often a cache: your browser remembered an earlier redirect, or a page cache or CDN served the old answer. Other causes are a second plugin or server rule that answers first, a source path that does not match exactly, such as a missing trailing slash, and a page that still exists at the old URL. Test with a redirect checker and purge caches.