301 Redirect Plugin for WordPress
A WordPress 301 redirect sends an old URL to a new one permanently. Do it three ways: the Redirection plugin (works on Apache and Nginx), an .htaccess rule on Apache, or a server-block return on Nginx — where .htaccess never runs. Test every rule with curl so you see each hop and the final 200.
Written for WordPress owners fixing changed slugs and site moves, with working code for each method and a curl test for every rule.
knowledge
- Read time
- 2 min
- Sections
- 4
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 15 November 2026.
What does a 301 redirect actually do?
A 301 redirect tells browsers and search engines that a URL has moved permanently, forwards visitors to the new address, and lets Google pass the old URL's signals to the new one. You use it when a slug changed, posts were merged, a site moved domain, or a campaign URL should land on a live page.
Choose the code deliberately, because caching behaviour follows it:
| Code | Meaning | Use it for |
|---|---|---|
| 301 | Moved permanently; browsers cache it hard | Slug changes, merges, domain moves |
| 302 | Moved temporarily | Short tests, seasonal swaps, a page down for days |
| 307 / 308 | Temporary / permanent, preserving the request method | APIs and POST forms where resubmission matters |
For ordinary WordPress pages 301 is the right default. A 302 left in place for a permanent move tells Google to keep the old URL indexed — the opposite of what you want. And one rule per old URL: two plugins writing the same redirect will fight and produce loops, so keep exactly one redirect tool active.
Method one: the Redirection plugin (works everywhere)
The Redirection plugin is the path most WordPress owners should take: it stores rules in the database, runs inside WordPress itself, and therefore behaves the same on Apache and Nginx. It also keeps a log of 404 hits, which tells you which dead URLs people still request.
- In the dashboard open Plugins, then Add New, search for Redirection, and activate it.
- Open Tools, then Redirection, and finish the first-run setup screen it shows.
- Put the old path —
/old-page/— in the source field and the full new address in the target field. Leave the type as 301. - Open the old URL in a private window: you should land on the new page in one hop, not via a second redirect.
The plugin's 404 log pairs naturally with the wider topic in WordPress 404 errors: causes and fixes. One caution: if your SEO plugin already manages redirects, use that module instead of installing a second one — duplicate redirect managers are the most common self-inflicted loop.
Method two: Apache and the .htaccess file
On Apache you can write permanent redirects straight into .htaccess — it is faster than a plugin because the rule fires before WordPress boots, but one broken line takes the whole site down with a 500 error. Back the file up before touching it.
The simplest form uses mod_alias, one line per redirect:
Redirect 301 /old-page/ https://example.com/new-page/
For pattern matching use mod_rewrite — the caret anchors the rule to the start of the path, and the ?$ accepts the slug with or without a trailing slash:
RewriteEngine On
RewriteRule ^old-page/?$ https://example.com/new-page/ [R=301,L]
Place redirect rules above the WordPress block (the lines between # BEGIN WordPress and # END WordPress), because that block is regenerated and will swallow hand-edits placed inside it. SFTP access to the file is covered from the hosting side on WordPress hosting.
Method three: Nginx server config — where .htaccess never runs
Nginx does not read .htaccess at all: a rule pasted there silently does nothing, so on Nginx you either keep redirects inside the plugin or ask the host to add them to the server block. WebJi support can tell you which web server your account uses.
The server-level syntax is a return inside a location block:
location = /old-page/ {
return 301 https://example.com/new-page/;
}
Unlike .htaccess, editing this file requires shell or host access, which is exactly why the plugin method is the practical default for shared hosting. The honest division of labour: plugin for everyday URL changes, server config for site-wide moves done with the host's help.
| Method | Use it when | Risk |
|---|---|---|
| Redirection plugin | You can log in; you want a 404 log; works on any web server | Very low — rules live in the database |
| .htaccess | Apache only; a handful of stable rules | A syntax error takes the site down — back up first |
| Host ticket / server block | Nginx, or domain-level moves | Needs host access; changes take a reload |
How do you test a redirect with curl?
Test with curl before you trust the private-window check, because curl prints every hop and the exact status code — the two things a browser hides. One command shows the full chain:
curl -sIL https://example.com/old-page/ | grep -iE "^HTTP/|^location:"
Each HTTP/… 301 line followed by a location: line is one hop. The chain should read 301 once and finish with HTTP/… 200. For a quick single-line verdict — status code and where it lands — use:
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" https://example.com/old-page/
Reading the output: more than one 301 before the 200 means a chain; a 404 means the rule never matched the path you typed; a 302 where you planned permanence means the wrong code was selected.
How do you avoid redirect chains and HTTPS mistakes?
Point the oldest URL straight at the final destination, and never send HTTPS visitors to HTTP — chains waste crawl budget and the wrong direction strips the padlock.
- Chain avoidance: if /a/ already redirects to /b/ and /b/ moves to /c/, update the /a/ rule to /c/ directly. Each extra hop is another round trip for visitors and another chance to drop signals.
- Direction: redirects should end on the https URL of the new page. A rule that lands visitors on http marks the site not secure and can expose login forms.
- Cleanup: if a plugin or an old .htaccess line created an https-to-http rule, delete it and keep the SSL certificate on.
- After a permalink change: WordPress does not create the 301s for you — work through the old slugs, which is easier to plan before the switch with the permalink structure guide.
When the redirects exist because a whole site moved — Blogger to WordPress, for instance — do it as one mapped migration rather than stacked rules; the Blogger to WordPress migration guide shows the pattern.
Frequently asked questions
What is the best 301 redirect plugin for WordPress?
Use one actively maintained plugin, such as Redirection, if you want a 404 log and your SEO plugin does not already manage redirects. Running two redirect plugins together is the fastest way to create a loop, so pick one and stay with it.
Do 301 redirects work on Nginx?
An .htaccess rule does not — Nginx ignores that file entirely. A plugin that runs inside WordPress does work, and a server-level rule needs to be added to the server block by whoever controls it, typically your host.
301 or 302 — which one for a temporary maintenance page?
302. It tells browsers and Google the move is temporary, so the original URL stays indexed and the redirect is not cached aggressively. Switch to 301 only when the move becomes permanent, as with a changed slug.
How many redirects in a chain are acceptable?
Aim for exactly one. Every additional hop adds a round trip, dilutes the passed signals, and risks a loop. Update the oldest rule to point at the final URL instead of stacking new redirects on top of old ones.
Where do .htaccess redirects go in the file?
Above the WordPress block — the lines between # BEGIN WordPress and # END WordPress are regenerated by WordPress and will overwrite hand-edits. Rules placed before that block survive updates and fire before WordPress boots.
Last editorial update: 15 November 2026.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.