TL;DR
Use a WordPress redirect plugin for editor-managed URL changes and server rules for structural redirects. The main goal is to avoid chains, loops, and scattered rules that nobody can audit later.
- Plugin redirects fit changed posts, deleted pages with replacements, campaign URLs, and small 404 cleanup lists.
- Server or hosting redirects fit HTTPS, www or non-www, domain moves, and broad path patterns.
- Test every redirect hop, status code, query string, cache layer, and final destination.
Start by Choosing the Redirect Owner
Most redirect problems begin when more than one layer tries to fix the same URL. A WordPress redirect plugin may redirect an old post. The hosting panel may force HTTPS. Apache may add a trailing slash. The SEO plugin may redirect changed slugs. A CDN may normalize the domain. Each rule can be valid alone, but together they can create chains, loops, and inconsistent testing results.
Before adding a rule, decide where that rule belongs. Editorial redirects belong close to editors. Structural redirects belong close to the server. Temporary campaign redirects may belong in a marketing tool if the team needs to change them often. The goal is not to avoid plugins completely; the goal is to stop scattering URL behavior across places nobody audits together.
When a WordPress Redirect Plugin Makes Sense
A redirect plugin is useful when editors need to manage URL changes without server access. Common cases include renamed posts, deleted service pages with a replacement, campaign landing pages, old category paths, and 404s discovered from Search Console or server logs. A good plugin stores the old URL, target URL, status code, hit count, date created, and a note explaining why the redirect exists.
The best plugin setup is narrow. Use it for page-level changes where the list is small enough to review. Export the rules regularly, and avoid using a plugin for broad patterns that match thousands of URLs. Pattern redirects can work inside plugins, but a mistake inside PHP costs more than a tested server-level rule.
When Server Rules Are Better
Server rules are better for structural behavior: HTTP to HTTPS, non-www to www, www to non-www, old domain to new domain, slash normalization, retired directories, and predictable path migrations. These redirects should happen before WordPress loads because every visitor and crawler request passes through them.
Apache sites usually use .htaccess or virtual host configuration. Nginx sites use server blocks. Managed hosts may expose redirect controls in the dashboard. Whichever layer you use, keep the source and target list documented. A redirect that nobody can find is a future outage waiting for a site redesign.
Pick the Status Code Deliberately
Use 301 when the move is permanent and the old URL should be replaced. Use 302 or 307 when the change is temporary and the old URL may return. Use 410 when the content is intentionally gone and there is no useful replacement. Do not redirect every deleted page to the homepage just to hide 404s. That makes search engines and users work harder.
For SEO, the target should satisfy the same intent as the old URL. An old pricing page can redirect to a new pricing page. An old plugin tutorial can redirect to a newer tutorial. A discontinued product with no equivalent may be better as a clear 410 or a helpful archive note than a forced homepage redirect.
Test the Full Path, Not Just the Final Page
A browser can hide redirect chains. Test with tools that show each hop: old URL, HTTPS version, canonical host, trailing slash, plugin redirect, and final URL. A clean redirect usually has one hop. Two hops may be acceptable during a migration. Three or more hops usually means rules are stacked in the wrong order.
Check mobile and desktop URLs, query strings, uppercase paths, old category slugs, and URLs with encoded characters. Also test cache behavior. A redirect may look fixed in a private browser while the CDN or page cache still serves an older response to visitors.
A Practical Redirect Workflow
- List the old URL, target URL, reason, owner, and expected status code.
- Choose plugin rules for editor-managed page changes.
- Choose server or hosting rules for domain, protocol, and path patterns.
- Avoid redirecting unrelated deleted pages to the homepage.
- Test for chains, loops, cache conflicts, and query string handling.
- Update internal links after adding redirects so users do not depend on old paths.
- Review Search Console and server logs after deployment.
Frequently Asked Questions
Can I redirect WordPress without a plugin?
Yes. Apache .htaccess, Nginx server blocks, hosting dashboard rules, and CDN rules can all redirect WordPress URLs without a plugin. Use the layer that your team can test and maintain.
Are 404 pages always bad for SEO?
No. A real 404 or 410 is fine for content that is gone and has no useful replacement. Redirect only when the target genuinely helps the user continue the same task.
What should I do after changing a slug?
Add a 301 from the old slug to the new slug, update internal links, clear cache, test the old URL, and watch Search Console for crawl or indexing issues.