
Redirects in WordPress: Fix 404s & Boost SEO in 2026
You refresh a WordPress site, publish the updated pages, and everything looks fine until someone from the marketing team clicks an old campaign URL and lands on a 404. Then someone notices an older blog post with backlinks now points nowhere. Then paid traffic starts hitting dead pages because the landing page slug changed during the redesign.
That's usually when redirects in WordPress stop feeling like a technical detail and start feeling like risk control.
A redirect is the instruction that tells browsers and search engines, “this page moved, go here instead.” Used well, redirects preserve the value of old URLs, keep visitors on track, and protect the work already invested in content, links, and campaigns. Used badly, they create chains, confusion, and avoidable ranking loss. The difference usually comes down to choosing the right method for the job.
Table of Contents
- Why WordPress Redirects Are Your SEO Safety Net
- Choosing Your Redirect Type 301 vs 302
- The Easiest Way Using a WordPress Redirect Plugin
- Advanced Redirects with Code and Server Files
- Redirect Workflows for Site Changes and Migrations
- How to Test Redirects and Avoid Common Pitfalls
Why WordPress Redirects Are Your SEO Safety Net
A common failure looks like this. A team updates page titles, cleans up URL slugs, archives a few thin pages, and ships the new site structure on schedule. Nobody maps old URLs to new ones. By the next morning, visitors are hitting dead ends from bookmarks, old ads, sales collateral, and backlinks that used to work.
That's why redirects in WordPress matter so much. A broken URL isn't just a user experience issue. It breaks continuity. The authority tied to the original page no longer reaches the replacement page, and visitors who were one click away from converting get dropped into an error state instead.
Practical rule: Every URL that has earned attention should have a destination, even if the page itself is gone.
In real site maintenance, redirects are less about “fixing errors” and more about preserving momentum. If a blog post has external links, if a landing page has been used in campaigns, or if a resource page ranks for a meaningful query, changing its URL without a redirect is like changing your office address and not forwarding the mail.
There's also a judgment call involved. Not every retired page deserves a redirect, but many do. The best target usually isn't the homepage. It's the closest relevant replacement page. WordPress SEO guidance has long advised against sending every removed page to the homepage and recommends direct old-to-new mapping instead.
If you're cleaning up an existing mess first, this guide to repair dead links is useful because it helps frame redirects as part of a broader broken-link recovery process, not a one-off patch.
The damage shows up in several places
- Users hit friction: Old bookmarked URLs and shared links stop working.
- Marketing loses continuity: Campaign pages disappear after redesigns or content rewrites.
- SEO signals get stranded: Backlinks and historical relevance stay tied to URLs that no longer resolve.
- Teams waste time reactively: Support, SEO, and content teams end up chasing errors after launch instead of preventing them before launch.
Redirects are the safety net because they catch all of that before it becomes visible to customers and search engines.
Choosing Your Redirect Type 301 vs 302
The most important choice isn't the plugin or the code snippet. It's the status code.
If you pick the wrong redirect type, you send the wrong signal about what happened to the page. In WordPress, the default decision is usually simple. 301 is for a permanent move. 302 or 307 is for a temporary one.
Think of redirects like mail forwarding
A 301 redirect is permanent mail forwarding after you move offices. You're telling everyone, including search engines, that the old address should now resolve to the new one going forward.
A 302 redirect is more like putting a temporary hold in place while you renovate the office lobby. The original location still matters. You're just routing visitors somewhere else for now.

For WordPress operators, that distinction matters because a 301 redirect is the standard permanent-redirect mechanism, and WordPress guidance commonly notes that it passes 90% to 99% of link equity from the old URL to the new one, which is why it's used when content moves or site structure changes, as noted in this WordPress 301 redirect guide.
That's why 301 is the default for most SEO-sensitive changes:
- renamed service pages
- blog post slug updates
- content consolidation
- category cleanup
- domain migrations
If you want a broader non-WordPress explanation of edge cases and implementation logic, this essential guide for 301 redirects is a solid companion read.
A quick decision checklist
Use 301 when:
- The old URL is gone for good: You changed the slug, merged content, or moved domains.
- You want search engines to treat the new URL as the replacement: This is the normal SEO case.
- You're cleaning up architecture: Old paths need to resolve directly to the new structure.
Use 302 or 307 when:
- The move is temporary: Maintenance pages, short-term campaign swaps, or limited tests.
- The original URL should come back: The source page still has an ongoing role.
- You're testing without replacing the original asset: Common with landing page experiments.
A redirect doesn't just move traffic. It communicates intent.
One useful related concept is the destination page itself. If the target returns a healthy response, that's the baseline you want before you point old URLs at it. This explanation of HTTP return code 200 is a good refresher if your team needs to verify what a “working page” should return.
The Easiest Way Using a WordPress Redirect Plugin
For many, the best way to manage redirects in WordPress is a plugin. It's faster to deploy, easier to audit, and far less likely to cause a site-wide problem than editing server files without a backup plan.
The default recommendation is Redirection. In the WordPress ecosystem, redirects are treated as a core SEO maintenance task, and the Redirection plugin listing describes it as the most popular redirect manager for WordPress and says it's designed to manage 301 redirections plus 404 error tracking.
Why plugins are the right default for most teams
A plugin is usually the right choice when:
- Marketing needs control: You want someone in the dashboard to add and review redirects without server access.
- The site changes often: Content teams rename pages, remove pages, and publish campaign URLs regularly.
- You need visibility: A 404 log helps catch missed URLs after launches and content updates.
- You want lower operational risk: A typo in a plugin field is easier to fix than a typo in a critical server file.
This is the interface most WordPress users should start with:

There's also a straightforward video walkthrough if your team prefers to see the flow before touching anything:
How to create a redirect with Redirection
The setup is simple, but details matter.
Install the plugin Go to Plugins > Add New in WordPress, search for Redirection, then install and activate it.
Open the redirect manager In most setups, you'll find it under Tools > Redirection.
Add the old path In Source URL, enter the old path only.
Example:/old-page/Add the destination In Target URL, enter the new destination.
Example:/new-page/or a full destination if needed.Confirm the redirect type For permanent page moves, use 301.
Save and test Visit the old URL in a private browser window and make sure it lands on the intended new page.
Don't overthink the first redirect. The core job is simple: one retired URL, one closely related live URL.
Use the 404 log as a working queue
The feature many teams overlook is the 404 log. That turns redirect management from guesswork into maintenance.
Instead of waiting for someone to complain, you can review requests that hit missing pages and decide what each one needs:
- a redirect to a relevant replacement
- a content restoration
- a true 404 because the request is junk or irrelevant
Plugin-based redirects in WordPress become strategic after a redesign or migration, as the log acts like a punch list. It shows what users and bots are still requesting from the old structure.
A good workflow looks like this:
| Situation | Best response |
|---|---|
| Old blog post moved to new slug | Add a direct 301 to the new post |
| Old service page replaced by a newer equivalent | Redirect to the closest matching service page |
| Deleted thin content with no replacement | Leave as 404 or handle intentionally |
| Random malformed URLs | Ignore unless they represent meaningful demand |
Plugins aren't the fastest possible method at the server level, but they're often the best operational method. They give non-developers a safe interface, they create an editable record of changes, and they make ongoing redirect hygiene much easier.
Advanced Redirects with Code and Server Files
There comes a point where a plugin stops being the best tool. Maybe the site is large and tightly controlled. Maybe you need redirects before WordPress loads. Maybe dashboard access is limited during a migration window. That's when manual implementation makes sense.
The two common manual routes are .htaccess and wp_redirect().

When manual redirects are the better choice
Manual redirects are usually better when:
- You need server-level handling: The redirect should happen before WordPress does more work.
- You're managing a controlled migration: Developers want redirect rules versioned and deployed with infrastructure changes.
- You don't want plugin overhead: Fewer moving parts in the admin environment.
- You need environment-level consistency: Especially across staging and production workflows.
That said, manual work raises the risk of mistakes. One bad rule in the wrong place can create loops, 500 errors, or catch URLs you never intended to touch.
The right way to add a 301 in .htaccess
For WordPress redirects, the most technical method is editing the site's root .htaccess file. Guidance for WordPress redirects recommends placing rewrite rules before the autogenerated # BEGIN WordPress block, and a standard rule is:
Redirect 301 /old-path/ https://yourdomain.com/new-path/
That placement matters because it keeps WordPress's own rewrite rules intact and avoids conflicts, as explained in this manual WordPress redirect implementation guide.
A practical process looks like this:
Connect to the site files Use your host file manager or SFTP/FTP access.
Locate the root .htaccess file This is usually in the main WordPress install directory.
Back it up before editing If you break this file, the site can fail hard.
Insert the rule above
# BEGIN WordPressExample:Redirect 301 /old-path/ https://yourdomain.com/new-path/Save, upload if needed, then test Use an incognito window after clearing cache so you're not reading a cached response.
Server-level redirects are like rerouting traffic at the highway entrance instead of inside the parking lot. They're efficient, but mistakes affect everything upstream.
Using wp_redirect in theme or plugin code
wp_redirect() is useful when redirect logic depends on WordPress conditions. For example, you might redirect based on a custom template, a query condition, or a logged-in state.
The critical implementation detail is easy to miss. WordPress's native wp_redirect() function does not terminate execution automatically and should almost always be followed by exit, as noted in the WordPress developer reference for wp_redirect().
Example:
function custom_old_page_redirect() {
if ( is_page('old-page') ) {
wp_redirect( home_url('/new-page/'), 301 );
exit;
}
}
add_action('template_redirect', 'custom_old_page_redirect');
Without exit;, WordPress can continue processing after the redirect header is sent. That creates hard-to-debug behavior.
A quick comparison helps:
| Method | Best for | Watch out for |
|---|---|---|
.htaccess |
Fast, direct URL rules | File errors, broad matches, rule order |
wp_redirect() |
Conditional logic inside WordPress | Forgetting exit;, slower path than server rules |
| Plugin | Day-to-day admin management | Less ideal for highly customized server workflows |
The dividing line is simple. If the redirect is routine and content-driven, use a plugin. If it's part of infrastructure, deployment, or custom conditional logic, go manual.
Redirect Workflows for Site Changes and Migrations
Single redirects are maintenance. Redirect workflows are project management.
The difference matters because most redirect failures don't happen on one page. They happen during structural change, when dozens or hundreds of URLs move at once and nobody owns the mapping end to end.
Workflow for a permalink change
A permalink update sounds harmless until you realize every old URL becomes legacy the moment the new format goes live.
The safest process is:
- Audit the existing URL patterns: Know what format users and search engines are already hitting.
- Define the new structure clearly: Don't improvise slugs during rollout.
- Map predictable changes first: If patterns are consistent, rules can cover many URLs cleanly.
- Review internal links: Update navigation, content links, and templates so your own site doesn't rely on redirects.
- Test representative samples: Posts, pages, categories, and any custom content types.
For teams reworking URL structure, site architecture planning matters as much as the redirect rule itself. This overview of site architecture SEO is useful because redirects work best when the new structure is cleaner than the old one.
A redirect map is the backbone of the job. Even when you can automate part of the pattern, you still need to review exceptions.

Workflow for a domain migration
A domain migration raises the stakes. You're not just changing paths. You're changing the site's public address.
In a clean migration, every meaningful old URL should point directly to its new equivalent on the new domain. The goal isn't to “get people somewhere.” The goal is to preserve relevance page by page.
A practical migration checklist:
Export or crawl the old URL inventory Pull together pages, posts, resources, and high-value campaign URLs.
Create a redirect map Match each old URL to the closest new destination.
Implement direct old-to-new redirects Avoid intermediate hops.
Keep the launch tightly controlled Redirect deployment, internal link updates, canonicals, and sitemap refreshes should happen together.
Monitor post-launch Watch for missed URLs, stray 404s, and redirect mismatches.
The best migration redirects feel boring. Users don't notice them, and that's exactly the point.
If your migration includes a platform shift as well as a domain or structure change, examples from teams handling platform moves can be helpful. IMADO's WordPress migration expertise is a useful reference point for how migration planning connects URL mapping, content transfer, and structure decisions.
The trade-off in migrations is speed versus accuracy. Fast launches often skip redirect mapping detail. That's where teams lose continuity. Slower, disciplined launches usually protect the value the old site already earned.
How to Test Redirects and Avoid Common Pitfalls
A redirect that hasn't been tested is a guess. On production sites, guesses are expensive.
The problem is that redirects often look right from inside WordPress or from a browser that has cached the destination. Meanwhile, real users and search engines may be seeing something different. That's why testing belongs in the same workflow as implementation, not after it.
A simple testing routine
Use a three-part check.
Test in an incognito or private window
This reduces the chance that browser cache masks the server's real behavior.Enter the old URL directly
Don't click from your own nav. Paste the exact retired URL and confirm the destination is the intended replacement.Confirm the status path with a checker or audit tool
You want to see the redirect behavior clearly, especially if multiple systems might be affecting routing.
For larger launches, a technical review process matters more than ever. A proper technical website audit helps surface redirect problems alongside crawl issues, broken internal links, and status code mismatches.
Mistakes that cause trouble fast
Some redirect mistakes are much more damaging than others.
- Redirect chains: Old URL to intermediate URL to final URL. These slow things down and complicate crawling. WordPress guidance consistently advises using direct old-to-new mappings instead.
- Homepage dumping: Sending every removed page to the homepage is usually a poor experience. If someone wanted a specific article or service page, the homepage is not a relevant answer.
- Wrong status codes: A temporary redirect for a permanent move sends mixed signals.
- No post-launch monitoring: Even careful teams miss URLs during redesigns and migrations.
- Testing only one example: One working redirect doesn't prove the pattern is sound.
Untested redirects fail quietly. The site can look fine to your team while visitors keep hitting broken paths.
Good redirect maintenance isn't glamorous. It's operational discipline. But it protects years of work in content, backlinks, campaigns, and navigation decisions. For WordPress sites that change often, that discipline is part of SEO, not separate from it.
If your team wants clearer visibility into how technical changes affect discoverability, LucidRank gives you a practical way to monitor brand presence across major AI assistants, track shifts over time, and spot where competitors are gaining ground. It's a useful layer of oversight when your site structure, content, and search visibility are all moving at once.