Badly configured WordPress redirects can drop a page out of the index inside 48 hours. A chain of three 302s can bleed PageRank for a year before anyone notices in the server logs. The setup you pick matters more than the plugin you install on top of it.
Most sites accumulate dozens of WordPress redirects through plugin migrations, URL changes, and content cleanups. Without a monthly audit, that list turns into a stack of 301s pointing at 301s pointing at deleted pages. The fix is understanding which redirect type belongs where, then implementing at the right layer of the stack.
Which WordPress Redirects to Use (and When)
Four redirect types cover every scenario you’ll hit on a WordPress site. Picking the wrong one is the root cause of most redirect-related ranking drops:
- 301 (Permanent). Use when a URL moves for good. Google treats 301s as a full transfer of link signals, usually within 4-8 weeks. This is your default.
- 302 (Temporary). Use for short-term redirects: A/B tests, seasonal promos, maintenance pages. Google preserves the original URL’s signals in its index and keeps recrawling the old URL to check if the redirect has been removed.
- 307 (Temporary, HTTP/1.1). Same SEO treatment as 302 but preserves the HTTP method. Rarely needed for marketing content.
- 410 (Gone). Not technically a redirect, but the right answer when you delete a page and don’t want to point it anywhere. 410 removes the URL from the index about 40% faster than a 404 response.
Using 302 when you mean 301 is the single most common mistake. You’ll see it when a client reports that “the old URL still shows in Google months after the migration.” Swap to 301 and the index updates inside a crawl cycle.
One caveat on 410s: don’t 410 a URL that still holds inbound links and traffic. Those links become wasted signal. Redirect those URLs with a 301 to a relevant replacement page instead. Reserve 410s for pages that both have zero external value and zero internal replacement.
The Three WordPress Redirects Methods Ranked by SEO Impact
WordPress gives you three main paths to implement redirects. They are not equal.
Server-level (.htaccess or Nginx config). Fastest performance, lowest overhead. The redirect happens before WordPress loads. A .htaccess 301 adds around 3-8ms to the redirect response. Use this for any redirect pattern that applies to hundreds of URLs (old blog path to new, HTTPS migration, subdirectory moves). The tradeoff: you need server access and confidence editing config files without breaking production.
WordPress plugin (Redirection, Rank Math redirects, Yoast Premium). Easiest for non-technical editors. Each redirect adds 40-120ms of PHP overhead because WordPress processes the rule on every page request. Fine for under 100 active redirects. Above that, you’ll see Time to First Byte creep up across the whole site.
Edge-level (Cloudflare Page Rules or Workers). Runs at the CDN before the request hits your origin. Fastest for users, zero WordPress overhead. Best for high-traffic sites with complex pattern rules. Cost scales with request volume on the Workers plan, so this pays off above roughly 500k monthly requests.
The practical rule: under 100 redirects, a plugin is fine. Above 100, move bulk rules to .htaccess. For sites above 10 million monthly pageviews, push everything to Cloudflare.
How to Migrate URLs Without Dropping Rankings
URL migrations are where WordPress redirects fail most often. A five-step process avoids the common ranking losses:
- Crawl the current site first. Use Screaming Frog or Sitebulb. Export every URL that has pulled traffic from GSC in the last 90 days. This is the list you must redirect. Missing one is how a top-ranking page ends up a 404.
- Map old to new one-to-one. Every old URL points to its closest content equivalent on the new site. Don’t lazy-redirect everything to the homepage. Google treats 1-to-homepage redirects as soft 404s and drops the old URL from the index without passing signals.
- Write 301 rules before launch. Stage the redirects, test them on a staging environment, confirm each returns a clean 301 (not a 302, not a chain, not a 404).
- Preserve URL fragments where possible. If you’re keeping slugs and only changing the domain, 301 at the domain level and keep paths intact. Fragment preservation recovers rankings about 3 weeks faster than full URL rewrites.
- Submit the updated sitemap to GSC within 48 hours of launch. Then watch the Coverage report daily for 2 weeks. Any URL flagged as “Redirect error” or “Not found (404)” needs immediate fix.
The first 30 days post-migration are the highest-risk window. Rankings that recover by day 45 usually stabilize. Rankings that haven’t recovered by day 60 often won’t without a redirect audit and at least one round of reindexing requests.
A Monthly Redirect Audit That Catches Chains
Redirect chains (A then B then C then D) waste crawl budget, slow Googlebot, and can silently drop PageRank between hops. Every third hop loses roughly 15% of the signal, based on tests Moz ran in 2023 and replicated since.
Run this audit monthly. It takes 25 minutes:
- Crawl your site with Screaming Frog in Spider mode. Check “Always Follow Redirects” before the crawl.
- Filter the Response Codes tab by “Redirection (3xx)”. Export.
- Find any URL with a redirect chain of 2+ hops. Screaming Frog labels these as “Redirect Chain” in the Redirects report.
- Update each chain to a single hop. If A then B then C, change the A-to-B rule so it points A directly to C.
- Delete any redirect pointing to a URL that no longer exists. Those are dangling rules. They return 404 to the user and waste server cycles.
Sites with clean redirect tables crawl faster, recover from migrations sooner, and lose less PageRank to chain decay. Fix chains this week and they’ll stay fixed until the next plugin migration.
Two habits keep your redirect table clean long-term. First, document every rule with a one-line reason in your plugin or config file. “Old /services slug moved to /offerings in March 2026 rebrand” takes 10 seconds to write and saves a future editor from wondering if a rule still belongs. Second, set a reminder to re-audit immediately after any plugin update that touches redirects or permalinks, since those updates sometimes silently regenerate rules that conflict with your manual entries.