You change a page slug in WordPress, hit update, and move on. A day later, someone clicks the old link from Google, an email campaign, or a partner site and lands on a 404 page. The page still exists. The value behind it still matters. But the path is gone.
That's the moment most businesses realize redirect management isn't a technical side task. It's part of running a stable website.
When clients ask about redirect URL WordPress setups, the underlying question usually isn't “How do I add a redirect?” It's “Which method should I trust for my team, my site, and our workflow?” That's the decision that matters. A marketer needs something safe and easy. A developer may want server-level control. An agency managing ongoing content changes needs something scalable and trackable.
Why WordPress Redirects Are Essential
A redirect sends visitors and search engines from an old URL to a new one. On a live WordPress site, that solves a very common problem. Pages get renamed, old landing pages are retired, service pages are merged, and blog posts get moved into cleaner structures.
Without a redirect, the old URL breaks.
That creates two problems at once. First, users hit a dead end. Second, the authority attached to the old URL can get stranded instead of flowing to the new location. If your site has been live for a while, those old URLs may already exist in search results, bookmarks, partner links, PDFs, ads, or internal documentation.
The business case for handling redirects properly
For SMBs, this usually shows up after a redesign or content cleanup. Marketing improves page names. SEO teams simplify slugs. Leadership wants cleaner navigation. All of that is good. But every URL change creates a responsibility.
Practical rule: If an old URL has ever been public, treat it like it still matters.
That's why redirects are part of professional site management, not just damage control. They preserve continuity. They help users reach the right destination without friction. They also reduce the mess that builds up when a site evolves over time.
Common moments when redirects matter
- URL updates: You change
/services-old/to/web-design/. - Content consolidation: Several thin articles become one stronger page.
- Site migrations: A new domain, subdirectory change, or reworked page structure goes live.
- Deleted pages: A retired page still receives visits from old backlinks or search listings.
A good redirect strategy also keeps teams honest. It forces a simple question before publishing changes: where should the old visitor go now?
That's the right mindset. Redirects aren't a patch after the fact. They're part of the launch checklist whenever URLs change.
Choosing Your Redirect 301 vs 302 for SEO
Before you decide how to create a redirect, decide what kind of redirect you need. WordPress redirects rely on HTTP status codes, and for practical site management the two that matter most are 301 and 302. There are five common redirect codes in HTTP, 301, 302, 303, 307, and 308, but for most WordPress work the main choice is permanent versus temporary, as outlined in SEOPress's WordPress redirect guide.
When a 301 is the right choice
A 301 redirect means the move is permanent. Use it when the old URL is not coming back in its original form.
That includes situations like:
- Renamed pages: You changed the slug and want the new page to become the main destination.
- Merged content: You retired one article and folded its value into another page.
- Domain or structure changes: You moved content during a migration and need continuity.
For SEO, this is the standard choice when you want search engines to treat the new URL as the long-term home.
When a 302 makes sense
A 302 redirect means the move is temporary. You're telling browsers and search engines that the original URL is expected to return.
That's useful in narrower cases:
- A page is temporarily unavailable
- You're routing traffic to a short-term campaign page
- You're testing a temporary destination before restoring the original page
Many WordPress sites make avoidable mistakes. Teams leave a temporary redirect in place for too long, or they use a 302 for a page that has clearly moved for good.
A simple way to think about it is mail forwarding. A 301 is your permanent change of address. A 302 is a temporary forwarding request while you're away.
The decision most teams should make
If you're asking whether to use 301 or 302 for a renamed page, migrated page, or content consolidation, the answer is usually 301. It signals permanence, and that signal matters.
Here's the practical test:
| Situation | Best Redirect Type |
|---|---|
| Page slug changed permanently | 301 |
| Old page replaced by a new page | 301 |
| Full site migration | 301 |
| Temporary campaign swap | 302 |
| Short-term maintenance detour | 302 |
When clients want a safe default, I tell them this: if the old URL shouldn't come back, use a 301.
The Easiest Method Using a WordPress Redirect Plugin
A common client scenario looks like this: a marketing team updates page slugs after a content refresh, traffic starts hitting old URLs, and no one wants to touch server files to fix it. That is where a redirect plugin makes sense. It keeps the work inside WordPress, lowers the chance of editing the wrong configuration file, and gives your team a place to review changes later.
For site owners, marketers, and SMB teams, that balance of safety and control is usually the right call. From an agency perspective, plugin-based redirects are often the best choice when the people maintaining the site are not the same people who built it.
The most familiar workflow comes from the Redirection plugin. Its interface has become a standard reference point for WordPress users: install the plugin, go to Tools > Redirection, enter the old path in Source URL, enter the destination in Target URL, and save the rule, as described in WP Engine's walkthrough of WordPress redirects.
Why plugin-based redirects work well
Use a plugin when the priority is maintainability, not maximum technical control.
A plugin is usually the right fit when:
- Your team does not manage server files
- You want redirects visible in the WordPress admin
- Non-developers may need to add or review rules
- You expect regular content changes over time
- You need logs or 404 monitoring without custom setup
That last point matters more than many teams expect. Redirects rarely stay static on active sites. If pages are added, merged, renamed, or retired every month, a dashboard-based process is easier to hand off and easier to audit.
How to set up a redirect with Redirection
Start by installing the plugin through your dashboard. If you need help with that part, this guide on how to install plugins for WordPress covers the basics clearly.
Then use this flow:
- Go to Tools > Redirection
- Find the fields for Source URL and Target URL
- Enter the old path in the source field
- Enter the new destination in the target field
- Choose 301 Moved Permanently if the move is permanent
- Save the rule
- Test the old URL immediately
The process is straightforward.
It still needs care. A redirect that is entered wrong is just as broken as one missing from the site entirely.
Where plugin redirects usually go wrong
The biggest issue is often formatting. In many plugin workflows, the Source URL should be entered as a relative path like /old-page/, not the full domain. The Redirection plugin documentation explains how matching and URL handling work, and it is worth checking if a rule does not fire the way you expect.
Other common problems include:
- Caching: the rule is saved, but browser cache, page cache, or CDN cache still serves the old response
- Incorrect destination format: some setups expect an absolute URL for external destinations, while internal paths may be handled differently
- No post-launch testing: someone assumes the redirect works and never verifies the old URL, mobile behavior, or tracking parameters
- Too many hands in the tool: multiple users add overlapping rules and create conflicts that are hard to spot later
Save the redirect, then test it right away in an incognito window and with any active cache cleared.
A common mistake is leaving temporary rules in place long after a page move became permanent. In a plugin, that is easy to miss because the rule keeps working at a technical level even when it is the wrong long-term choice.
Redirection also adds features that are useful on busy sites. It can log hits, track 404s, and help surface broken paths you may not know about yet. For agencies and in-house teams managing frequent content edits, that visibility is often the primary reason to use a plugin instead of a one-off redirect method.
Here's a quick walkthrough if you prefer to see the interface in action:
When to choose a plugin over other methods
Choose a plugin if your priority is safe delegation and ongoing maintenance.
It is a strong fit for:
- marketing-led websites
- lean in-house teams
- agencies handing off site management
- sites with frequent page edits
- teams that need visibility into redirect history
Even technical teams sometimes choose this route on purpose. A visible redirect manager inside WordPress is easier to review than rules buried in server configuration, especially on sites where content teams make changes every week.
If you already run an SEO suite with redirect features, that can also be a reasonable choice. The decision usually comes down to your operating model: use a dedicated redirect plugin if you want focused control and clear logs, or keep redirects inside your existing SEO stack if your team already manages everything there.
Advanced Redirects via htaccess and Nginx
Server-level redirects are the right choice when you want speed, tighter control, or broad rule handling before WordPress even loads. This method suits developers, technical site managers, and agencies working on migrations or infrastructure-heavy projects.
It is not the safest option for casual users.
A single typo can break routing and trigger a site error, so back up the relevant file before touching anything. On Apache, that usually means .htaccess. On Nginx, it's your server configuration.
Apache redirects in .htaccess
If your site runs on Apache, you can place redirect rules in .htaccess. A simple single-page redirect looks like this:
Redirect 301 /old-page/ https://example.com/new-page/
That rule sends requests from the old path to the new URL.
You can also redirect an entire directory:
RedirectMatch 301 ^/old-section/(.*)$ https://example.com/new-section/$1
And if you need to force HTTPS:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
Keep custom rules in the correct place. If you edit .htaccess, be careful not to drop them into the wrong part of the WordPress-generated block. If you want a more detailed walkthrough, this guide to 301 redirect .htaccess rules is a useful reference.
Nginx redirect examples
If your server uses Nginx, redirects are handled in the server config rather than .htaccess.
A single-page redirect can look like this:
location = /old-page/ {
return 301 https://example.com/new-page/;
}
A directory redirect can look like this:
location /old-section/ {
return 301 https://example.com/new-section$request_uri;
}
To force HTTPS, a common pattern is:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}
When server-level redirects are the better choice
This approach works best when you need:
- Pre-WordPress handling: The redirect happens before WordPress loads.
- Lean plugin stacks: You want fewer dashboard dependencies.
- Large structural rules: Entire sections, protocol rules, or domain-wide logic.
- Infrastructure consistency: Redirect behavior managed alongside server config.
That said, control comes with risk. If a non-technical team will need to maintain redirects later, server rules can become fragile fast.
Server-level redirects are powerful, but they age badly when nobody documents them.
What often goes wrong
These setups fail for predictable reasons:
- No backup before editing
- Rules added in the wrong location
- Overlapping logic that creates loops
- Forgetting to reload or validate config on Nginx
- No post-change testing on affected paths
In agency work, I usually recommend server-level redirects for migrations, infrastructure rules, and repeatable patterns. I don't recommend them for day-to-day content changes unless the team maintaining the site is fully comfortable with server configuration.
Custom Redirects with Code in WordPress
A common agency scenario looks like this. The client wants /account/ to send signed-in users to their dashboard, send guests to /login/, and leave admins on a different path entirely. A plugin can handle some of that, but once redirect behavior depends on user state or site logic, code is usually the safer and cleaner choice.
This method fits developer-led sites, membership builds, custom checkout flows, and any setup where the redirect should respond to what WordPress knows about the visitor.
When code is the right method
Use custom WordPress code when the redirect depends on conditions such as:
- login status
- user role or capability
- page template or post type
- query variables
- custom workflow rules tied to your application
That distinction matters. If the job is no more than moving one URL to another, code adds maintenance overhead you do not need. If the rule depends on application state, putting it in WordPress keeps the logic where your team can reason about it.
A safe WordPress redirect example
Place this in a custom plugin or, if necessary, your theme's functions.php file:
function custom_account_redirect() {
if ( is_page('account') && !is_user_logged_in() ) {
wp_redirect( home_url('/login/'), 301 );
exit;
}
}
add_action('template_redirect', 'custom_account_redirect');
This checks whether the visitor is on the account page and not logged in. If both conditions are true, WordPress redirects them to the login page.
The key detail is the template_redirect hook. WordPress runs it early enough for redirects to work before output is sent to the browser. WordPress documents wp_redirect() and the need to call exit after it in the official developer reference. Ignore that pattern and you can run into the familiar "headers already sent" error or partially rendered pages.
What to watch for
Code-based redirects fail in predictable ways. The logic is too broad. A developer forgets exit. Someone drops the snippet into a theme file, then the redirect disappears on the next redesign.
I recommend a custom plugin over functions.php whenever the redirect is business-critical. It survives theme changes and is easier to document, review, and version.
Use this checklist:
- Keep conditions narrow: Match only the pages and users you intend to catch.
- Use WordPress URLs carefully: Be consistent about
home_url()and absolute versus relative paths. - Exit after redirect: Stop execution immediately after
wp_redirect(). - Test real states: Logged in, logged out, admin, cached, uncached.
- Check for collateral issues: Redirect changes often surface broken links elsewhere on the site.
- Document the reason: Future developers need the business context, not just the code.
Caching can also confuse testing. If a redirect seems unchanged after you update the code, browser or DNS caching may be part of the problem. For troubleshooting steps outside WordPress, see more tech tips from Simply Tech Today.
My rule is simple. Use code for conditional behavior. Use a plugin for routine content edits. Use server rules for infrastructure-level redirects. That split scales better, and it prevents simple URL moves from turning into custom development work later.
A Practical Guide to Redirect Best Practices
The method matters, but the maintenance habit matters more. A clean redirect setup starts with choosing the right tool for the job, then testing and reviewing it like part of normal site operations.
That's where many WordPress sites drift off course. Redirects get added reactively, nobody audits them, and over time the site accumulates broken paths, duplicate logic, and redirect chains.
Which Redirect Method Should You Use
| Method | Ease of Use | Performance Impact | Best For |
|---|---|---|---|
| Plugin | Easy | Moderate | SMBs, marketers, content teams, ongoing page edits |
| .htaccess or Nginx | Technical | Low | Developers, migrations, server-wide rules |
| Custom WordPress code | Technical | Moderate | Conditional redirects, custom workflows, membership logic |
The right choice usually comes down to three questions:
- Who will maintain it later
- How often URLs change
- Whether the redirect is simple or conditional
If your team changes pages regularly, a plugin is usually the safest operational choice. If you're handling infrastructure logic, use server rules. If the redirect depends on application state, write code.
The redirect checklist that prevents most problems
Use this checklist every time:
- Map old URLs to new URLs before launch: Don't wait for 404s to reveal what changed.
- Test immediately after saving: Use a private browser window when possible.
- Avoid redirect chains: Update old rules so Page A goes straight to the final destination.
- Monitor 404 activity: That helps you catch URLs real visitors still use.
- Fix broken internal links too: Redirects help users, but your site should still link directly to the current page. This guide on how to fix broken links is a good companion process.
- Clear caching layers when results look wrong: Browser or site cache can make a working redirect look broken. If you suspect a local resolution issue during testing, these more tech tips from Simply Tech Today can help with troubleshooting.
Good redirect management is less about creating rules and more about reducing avoidable complexity.
What strong teams do differently
Strong teams don't treat redirects as isolated fixes. They tie them to content operations.
When a URL changes, they also update internal links, navigation references, and campaign destinations. They don't leave a trail of outdated paths behind them. That's what keeps a WordPress site clean over time.
If you remember one rule, make it this: every old public URL should have an intentional outcome. Redirect it, replace it, or retire it deliberately. Don't leave it to chance.
If your team is redesigning a site, migrating content, or cleaning up a messy redirect setup, OneNine can help you plan it properly and implement it without breaking traffic, SEO continuity, or user experience.
