Configuring 301 Redirects Correctly

A 301 redirect tells browsers and search engines that a URL has permanently moved, passing along the vast majority of its ranking signal to the new destination. Done correctly, it’s invisible to visitors and preserves SEO equity. Done sloppily — redirect chains, wrong redirect type, or loops — it quietly bleeds traffic and rankings for months before anyone notices. Here’s how to set them up correctly across the methods you’re likely to actually use.

301 vs 302: Why the Type Matters

A 301 (permanent) redirect tells search engines to transfer indexing signals to the new URL and update their index accordingly. A 302 (temporary) redirect tells them the move is short-term, so they keep the original URL indexed and don’t pass full ranking value to the destination. The single most common redirect mistake is using a 302 for what is actually a permanent change — many CMS plugins and CDN dashboards default to 302, so this needs a manual check every time.

Method 1: .htaccess (Apache)

On Apache servers, redirects live in the site’s .htaccess file, read top to bottom. For a single URL:

Redirect 301 /old-page/ https://example.com/new-page/

For pattern-based redirects (an entire folder moved), use RedirectMatch with a regex:

RedirectMatch 301 ^/old-folder/(.*)$ https://example.com/new-folder/$1

Place custom redirect rules above the WordPress core rewrite block (the section between # BEGIN WordPress and # END WordPress), since Apache processes rules in file order and a redirect placed after the WordPress block may never get reached for URLs WordPress itself is already handling.

Method 2: Nginx

Nginx doesn’t read .htaccess at all — redirects go directly in the server block config:

rewrite ^/old-page/?$ https://example.com/new-page/ permanent;

The permanent flag is what makes this a 301; using redirect instead issues a 302. For folder-wide moves:

rewrite ^/old-folder/(.*)$ https://example.com/new-folder/$1 permanent;

Any Nginx config change requires a config test and reload to take effect — nginx -t to validate syntax, then systemctl reload nginx, never a blind reload without testing first, since a syntax error in a reload (not a fresh start) can take the whole site down.

Method 3: WordPress Redirect Plugins

For non-technical setups, a plugin like Redirection (free) or the redirect manager built into Rank Math/Yoast handles this through wp-admin without touching server config. This is the right choice when: you don’t have server/SSH access, you need non-developers on the team to manage redirects, or you want built-in 404 monitoring to catch broken links automatically and suggest redirects for them. The tradeoff is a small per-request performance cost since WordPress has to load before the redirect fires, versus .htaccess/Nginx redirects which happen at the web server level before WordPress ever loads.

The Redirect Chain Problem

A redirect chain happens when URL A redirects to B, which redirects to C. Each hop adds latency, and search engines historically follow a limited number of hops before giving up — anything beyond 2-3 hops risks the destination not getting full credit at all. Chains accumulate silently over years of site migrations and URL restructuring. The fix is to periodically audit and update every old redirect to point directly at the final live URL, not the next link in the chain.

Comparison: Redirect Methods

Method	Speed	Access needed	Best for
.htaccess (Apache)	Fast — server-level	FTP/SSH/file manager	Apache-hosted sites, bulk pattern redirects
Nginx config	Fast — server-level	SSH + root/sudo	Nginx-hosted sites, high-traffic pages
Redirect plugin	Slightly slower — loads with WP	wp-admin only	Non-technical teams, ad-hoc single redirects
CDN-level (Cloudflare rules)	Fastest — edge, before origin	CDN dashboard access	High-traffic sites wanting to skip origin server load entirely

Testing a Redirect Before Trusting It

Never assume a redirect works because the browser lands on the right page — browsers cache redirects aggressively, so you might be seeing a cached result from before your change. Test with a header-checking tool (curl’s -I flag, or a browser dev-tools Network tab with cache disabled) to confirm the actual HTTP status code returned is 301, not 302, and that it doesn’t chain through an intermediate hop.

Verdict

Server-level redirects (.htaccess or Nginx) are the right default for permanent, high-traffic URL changes because they’re fast and don’t depend on WordPress loading. Reserve plugin-based redirects for teams without server access or for catching ad-hoc 404s reactively. Whichever method you use, verify the actual status code with curl rather than trusting what the browser shows you, and audit existing redirects periodically to collapse chains before they compound.

FAQ

Will a 301 redirect pass all my old page’s SEO ranking to the new URL?
It passes the substantial majority of ranking signal, though not literally 100% — search engines treat it as a strong signal to consolidate authority at the new URL, which is why 301s are the standard for any permanent URL change.

How long should I keep an old redirect in place?
Indefinitely for pages with any inbound links or search traffic history — removing a redirect years later can suddenly break old bookmarks, backlinks, and any cached search results still pointing at the original URL.

Can too many redirects slow down my site?
Individual server-level redirects add negligible latency, but redirect chains (multiple hops) add up, and a large volume of plugin-based redirects can add measurable overhead since each one loads through WordPress. Keep redirect rules server-level where possible for high-traffic paths.

What’s the difference between a redirect and a canonical tag?
A redirect physically sends visitors and crawlers to a different URL; a canonical tag lets both URLs stay live and accessible but tells search engines which one to treat as authoritative for indexing. Use redirects when a page is truly gone or moved; use canonicals when near-duplicate content needs to coexist (like URL parameters).

Do I need to update internal links after adding a redirect, or is the redirect enough?
The redirect handles external traffic and search engines fine on its own, but updating internal links to point directly at the new URL avoids the extra redirect hop for on-site navigation and slightly improves crawl efficiency.