301 Vs 302 Redirects
Using the wrong redirect can silently destroy months of SEO work. I’ve seen it happen on over 200 client sites since 2008, and the pattern is always the same: someone picks a 302 when they needed a 301, rankings tank, and nobody connects the dots for weeks.
The fix is simple once you understand the difference. A 301 tells Google “this page moved permanently, transfer all the SEO value.” A 302 says “this is temporary, keep the original URL indexed.” Pick wrong, and Google holds onto a page that no longer exists while ignoring the one you actually want to rank.
I’ll walk you through exactly when to use each type, how Google treats them differently in 2026, and how to set them up in WordPress without breaking anything. I’ll also cover meta refresh redirects, redirect chains, and the testing tools I use on every client site.
What Are HTTP Redirects and Why Should You Care?
Every time you type a URL or click a link, your browser sends a request to a server. The server responds with an HTTP status code. A 200 means “here’s the page.” A 404 means “page not found.” And a 3xx code means “go somewhere else instead.”
That “go somewhere else” is a redirect. The server tells your browser (and Google’s crawler) to load a different URL. This happens in milliseconds. You barely notice it. But Google notices everything about how you set it up.
Redirects matter because they control how search engines transfer authority between URLs. Get them right, and your new pages inherit all the ranking power of the old ones. Get them wrong, and you start from scratch. I had a client in 2023 who redesigned their entire site with 302 redirects instead of 301s. They lost 62% of their organic traffic in three weeks. It took four months to recover after we fixed it.
The HTTP Status Codes You Need to Know
There are four redirect status codes that matter for SEO:
- **301 (Moved Permanently):** The original URL is gone forever. All SEO value transfers to the new URL. This is your default choice 90% of the time.
- **302 (Found / Temporary Redirect):** The original URL will come back. Google keeps the old URL indexed and doesn’t fully pass link equity. Use this sparingly.
- **307 (Temporary Redirect):** The HTTP/1.1 version of 302. Same SEO treatment. Preserves the request method (POST stays POST). Most people don’t need to worry about this one.
- **308 (Permanent Redirect):** The HTTP/1.1 version of 301. Same SEO treatment as 301. Preserves the request method. Rare in practice for WordPress sites.
For 95% of WordPress sites, you’ll only deal with 301s and 302s. The others are edge cases for developers handling form submissions or API endpoints.
301 Redirects: The Permanent Move
A 301 redirect is your “we’ve moved, update your records” signal to Google. It’s permanent. It tells search engines to deindex the old URL, index the new one, and transfer the ranking signals (what SEOs call “link equity”) to the new destination.
I use 301 redirects more than any other type. They’re the right choice for domain migrations, URL structure changes, deleted pages, HTTP to HTTPS moves, and non-www to www consolidation. Basically, if the old URL isn’t coming back, use a 301.
How Google Handles 301s in 2026
Google has gotten smarter about redirects over the years. Back in 2015, there was a persistent myth that 301 redirects lost 10-15% of link equity in the transfer. Google’s John Mueller debunked this repeatedly, and my own testing confirms it. A properly set up 301 passes virtually all ranking power to the destination URL.
Here’s what happens when Google crawls a 301:
1. Googlebot hits the old URL and receives the 301 status code
2. It follows the redirect to the new URL
3. Over time, Google drops the old URL from its index
4. The new URL inherits the old URL’s backlinks, PageRank, and ranking signals
5. The canonical shifts to the new URL
This process isn’t instant. I’ve tracked it across dozens of migrations, and it typically takes 2 to 8 weeks for Google to fully process a large batch of 301 redirects. Small sites with under 100 pages see it happen faster, sometimes within a week.
When to Use a 301
Use a 301 redirect when:
- You’re changing your URL structure (e.g., removing /blog/ from your permalinks)
- You’ve deleted a page and want to redirect visitors to a relevant alternative
- You’re migrating from one domain to another
- You’re consolidating multiple pages into one stronger page
- You’re switching from HTTP to HTTPS (though most hosts handle this automatically now)
- You’re forcing www or non-www versions of your domain
I ran a content consolidation project for an e-commerce client last year. They had 47 thin product category pages that were cannibalizing each other. We merged them into 12 strong pages and set up 301 redirects from the old URLs. Organic traffic to those categories increased 34% within six weeks because Google could finally figure out which page to rank.
301 Implementation in WordPress
The cleanest way to add 301 redirects in WordPress depends on how many you need and how comfortable you are with server config files.
**For a handful of redirects,** use the Redirection plugin or Rank Math’s built-in redirect manager. Both work fine. I prefer Rank Math since most of my clients already use it for SEO, so there’s no extra plugin to maintain.
**For bulk redirects during a migration,** I go straight to .htaccess. It’s faster, doesn’t add database queries, and works before WordPress even loads. Here’s the syntax:
“`
Redirect 301 /old-page/ https://yourdomain.com/new-page/
“`
Or for more complex patterns using RewriteRule:
“`
RewriteEngine On
RewriteRule ^old-category/(.*)$ /new-category/$1 [R=301,L]
“`
**For PHP-level redirects** (useful in custom templates or functions.php):
“`php
wp_redirect( ‘https://yourdomain.com/new-page/’, 301 );
exit;
“`
Always include `exit;` after `wp_redirect()`. Without it, WordPress continues executing the rest of the page, which wastes server resources and can cause weird behavior.
**One mistake I see constantly:** people adding redirects in both .htaccess and a WordPress plugin. This creates redirect chains (old URL > intermediate URL > final URL). Every hop in the chain adds latency and dilutes the signal to Google. Pick one method and stick with it.
302 Redirects: The Temporary Detour
A 302 redirect tells browsers and search engines “this page has temporarily moved, but it’s coming back.” Google keeps the original URL in its index and doesn’t fully transfer link equity to the destination. That’s by design. If the page is coming back, you don’t want Google to forget about it.
The problem is that most people use 302s when they actually need 301s. I audit about 40 sites per year, and roughly half of them have at least one 302 redirect that should be a 301. It’s one of the most common technical SEO mistakes I encounter.
When a 302 Actually Makes Sense
Legitimate uses for 302 redirects are rarer than you’d think. Here are the scenarios where I actually recommend them:
- **A/B testing landing pages:** You’re temporarily sending traffic to a test variant and plan to revert. A 302 tells Google to keep the original indexed.
- **Geo-targeting redirects:** Sending US visitors to /us/ and UK visitors to /uk/ based on IP. The original URL still needs to exist for other regions.
- **Maintenance mode:** Your site is temporarily down for updates and you’re redirecting to a “back soon” page. (Though a 503 status is actually better for this.)
- **Seasonal promotions:** You’re redirecting /deals/ to /black-friday-2026/ for a few weeks, then switching it back.
Notice the pattern. Every legitimate 302 use case involves a situation where the original URL will be relevant again. If the original URL is never coming back, you need a 301. Full stop.
How Google Handles 302s Differently
Here’s where it gets interesting. Google has said that after a long enough period, they’ll treat a 302 like a 301. Gary Illyes from Google confirmed this. But “long enough” is vague, and in my experience, it can mean months of lost opportunity.
I tracked this on a client’s site in 2024. They had 23 URLs with 302 redirects that had been in place for over a year. Google was still indexing the old URLs and showing them in search results. The new URLs had almost no organic visibility despite having better content and more internal links. We switched them to 301s, and within four weeks, Google swapped the indexed URLs. Rankings improved on 19 of the 23 pages.
The lesson: don’t rely on Google “eventually figuring it out.” Be explicit. If it’s permanent, use a 301.
The Real Cost of Using 302 When You Need 301
I want to be specific about what goes wrong because this isn’t theoretical. I’ve fixed this on real sites with real traffic losses.
**Link equity doesn’t transfer properly.** When another site links to your old URL and Google sees a 302, it keeps the authority on the old URL. Your new page doesn’t benefit from those backlinks. On one client’s site, I found 340 external backlinks pointing to URLs with 302 redirects. Those links were essentially wasted until we switched to 301s.
**Google indexes the wrong URL.** Instead of showing your shiny new page in search results, Google shows the old one. Users click through and get redirected anyway, but you’ve lost control over which page appears in the SERPs. This matters for click-through rate because you can’t optimize the title and description of a page Google chose for you.
**Crawl budget gets wasted.** Google recrawls the old URLs because it thinks they’ll come back. On a 50,000-page e-commerce site I worked on, incorrect 302s were burning through about 15% of the daily crawl budget. That meant new products were getting indexed slower than they should have been.
Meta Refresh Redirects: The One You Should Avoid
A meta refresh redirect uses an HTML meta tag to send visitors to a different URL after a delay. You’ve seen these. They’re the pages that say “You will be redirected in 5 seconds” with a countdown.
Here’s what the code looks like:
“`html
“`
The `content=”0″` means redirect immediately. Some implementations use `content=”5″` or `content=”10″` to add a delay.
Why Meta Refresh Is Almost Always Wrong
Meta refresh redirects are client-side, meaning the browser has to load the page first, then read the meta tag, then redirect. This is slower than a server-side 301 or 302. It also creates a worse user experience because there’s a visible flash of content before the redirect happens.
From an SEO perspective, Google treats meta refresh with a delay of 0 as a 301-like signal. But anything with a delay of 5 seconds or more gets treated closer to a regular link, not a redirect. You lose most of the link equity transfer.
I’ve only seen meta refresh redirects make sense in one situation: when you don’t have access to the server configuration. Maybe you’re on a free hosted platform that doesn’t support .htaccess or PHP redirects. Even then, I’d push hard to find a server-side solution first.
**My rule:** if you can set up a server-side redirect, always do that instead of a meta refresh. On WordPress sites, you always have server-side options, so there’s no excuse for using meta refresh.
SEO Impact of Choosing the Wrong Redirect Type
I’ve talked about this in pieces throughout the article, but let me consolidate the real-world impact I’ve measured across client sites. These aren’t hypothetical scenarios. They’re actual cases from my consulting work.
Case 1: The E-Commerce Migration Disaster
A Shopify-to-WooCommerce migration in early 2024. The developer used 302 redirects for all 1,200 product URLs because “they wanted to make sure everything worked before making it permanent.” They never went back and changed them to 301s.
After 8 weeks, organic traffic was down 58%. Google was still trying to index the old Shopify URLs (which no longer existed) while treating the new WooCommerce URLs as temporary. We changed all 1,200 redirects to 301s using .htaccess. Traffic recovered to 90% of pre-migration levels within 6 weeks. The remaining 10% was attributed to content changes, not the redirect fix.
Case 2: The Redirect Chain Nightmare
A WordPress site had been through three URL structure changes over five years. Nobody cleaned up the old redirects. The result: some pages had 4-hop redirect chains (original URL > first move > second move > third move > current page).
Google doesn’t follow infinite redirect chains. It stops after about 5 hops, but each hop dilutes the signal. Core Web Vitals were failing because of the added latency. We flattened every chain to a single hop from the oldest URL to the current destination. Page load times improved by 400ms on average, and crawl errors dropped by 73% in Search Console.
Case 3: The Accidental 302
This is the most common scenario I see. A site owner uses a WordPress redirect plugin and doesn’t change the default setting from 302 to 301. They set up 15 redirects over two years, all 302s. None of those pages were coming back. It was a quiet ranking drag that nobody noticed because it happened gradually.
We switched all 15 to 301s. Within three weeks, 9 of the destination pages saw ranking improvements of 3 to 12 positions. The other 6 stayed the same because they had other SEO issues that redirects alone couldn’t fix.
How to Set Up Redirects in WordPress the Right Way
I’ve covered the basics earlier, but here’s my full recommended approach for WordPress sites in 2026. This is the exact workflow I use with clients.
Step 1: Decide Your Method
For most WordPress sites, I recommend using Rank Math’s redirect module. It’s built into the SEO plugin you should already be using, it handles both 301 and 302 redirects, and it has a nice auto-redirect feature for deleted posts.
If you’re running a large site (10,000+ pages) or doing a major migration, use .htaccess directly. Plugin-based redirects add a small amount of database overhead per request. On big sites, that adds up.
If you’re on Nginx instead of Apache, you’ll need to edit your server config file instead of .htaccess. The syntax is different:
“`nginx
location = /old-page/ {
return 301 https://yourdomain.com/new-page/;
}
“`
Step 2: Map Your Redirects Before You Start
Don’t wing it. Create a spreadsheet with three columns: old URL, new URL, and redirect type. Map every single URL before you change anything. I use a simple Google Sheet for this.
For migrations, crawl your current site with Screaming Frog or Sitebulb first. Export all URLs. Then map each one to its new destination. Pages with no equivalent should redirect to the most relevant category or parent page. Never redirect everything to the homepage. Google treats mass redirects to a single page as soft 404s.
Step 3: Set Up and Test
Add your redirects using your chosen method. Then test every single one. I know that’s tedious on a big site, but broken redirects are worse than no redirects. Use the Redirect Checker tool at httpstatus.io or the Ayima Redirect Path Chrome extension to verify each redirect returns the correct status code.
Step 4: Monitor in Search Console
After setting up redirects, watch Google Search Console closely for 4 to 8 weeks. Check the Pages report for crawl errors. Look for “redirect errors” and “not found (404)” entries. If Google is flagging your redirected URLs as errors, something went wrong in the setup.
Bulk Redirects with WP-CLI
For developers comfortable with the command line, WP-CLI paired with the Redirection plugin can handle bulk imports. Export your redirect map as a CSV, then import it:
“`bash
wp redirection import redirects.csv
“`
I’ve used this to import 3,000+ redirects during a migration in under a minute. Much faster than clicking through a plugin interface one redirect at a time.
Testing and Monitoring Your Redirects
Setting up redirects is only half the job. You need to verify they’re working and keep monitoring them over time. Redirects break. Plugins get updated. Server configs get overwritten. I’ve seen it all.
Tools I Use for Redirect Testing
Here are the tools in my regular rotation:
- **httpstatus.io:** Free, fast, checks individual URLs for status codes and redirect chains. I use this daily.
- **Screaming Frog SEO Spider:** Crawls your entire site and flags redirect chains, loops, and incorrect status codes. The free version handles up to 500 URLs. Worth every penny of the paid license for larger sites.
- **Ayima Redirect Path (Chrome extension):** Shows you the redirect chain for any page you visit in Chrome. Great for quick spot checks.
- **Google Search Console:** The Coverage report shows you which URLs Google is having trouble with, including redirect-related issues. Check it weekly after any redirect changes.
What to Watch For
**Redirect chains** are the most common issue I find during audits. They happen when redirect A points to URL B, which has its own redirect to URL C. Every extra hop adds latency and can confuse search engines. Fix chains by pointing all redirects directly to the final destination.
**Redirect loops** crash browsers. They happen when URL A redirects to URL B, and URL B redirects back to URL A. Your browser will eventually stop and show an error. These are almost always caused by conflicting redirect rules in .htaccess and a WordPress plugin.
**Mixed redirect types** on the same URL path are a subtle problem. If your .htaccess has a 301 but your plugin has a 302 for the same URL, the behavior is unpredictable. Pick one source of truth for each redirect.
I run a full redirect audit on every client site at least once a quarter. It takes about 30 minutes with Screaming Frog and catches issues before they impact rankings.
The Bottom Line on Redirects
Here’s my simple rule after 18 years of dealing with redirects: **when in doubt, use a 301.** The scenarios where a 302 is correct are rare and specific. If the old URL isn’t coming back within a few weeks, it’s a 301.
Don’t overthink redirect types. Don’t use meta refresh redirects on WordPress. Don’t create redirect chains. And don’t set up redirects without testing them.
If you haven’t audited your site’s redirects recently, do it this week. Install Screaming Frog, crawl your site, and look at the redirect report. I guarantee you’ll find at least one issue worth fixing. For most of the sites I audit, the redirect cleanup alone results in a measurable ranking improvement within a month.
Frequently Asked Questions
Does a 301 redirect pass full link equity?
Yes. Google has confirmed that 301 redirects pass full PageRank to the destination URL. The old myth about losing 10-15% of link equity during a 301 redirect was debunked years ago. In my own migration projects, I’ve consistently seen destination pages inherit the full ranking power of the original URLs within 2 to 8 weeks.
How long should you keep 301 redirects active?
Keep them active for at least one year. Google needs time to discover, process, and update its index. I recommend keeping 301 redirects permanently if possible. Removing them too early causes 404 errors for anyone still using the old URL, including external sites linking to you.
Will Google eventually treat a 302 redirect as a 301?
Sometimes, but don’t count on it. Google has said that long-standing 302 redirects may be treated as permanent signals over time. In my testing, this can take months, and it doesn’t always happen consistently. It’s much better to use the correct status code from the start than to hope Google figures out your intent.
Can too many redirects slow down my site?
Individual redirects add very little latency, usually under 10ms for a server-side 301 or 302. But redirect chains (one redirect pointing to another) stack up. A 4-hop chain can add 200-400ms of load time. Plugin-based redirects are slightly slower than .htaccess redirects because WordPress has to load first. For sites with hundreds of redirects, .htaccess or server config is the better choice.
Should I redirect deleted pages to the homepage?
Only if there’s no better alternative. Google treats mass redirects to the homepage as soft 404s, which means they’re basically ignored. Redirect each deleted page to the most relevant existing page on your site. If a blog post about WordPress caching gets deleted, redirect it to your main caching guide, not your homepage.
What’s the difference between a 307 and a 302 redirect?
For SEO purposes, they’re treated the same. Both signal a temporary move. The technical difference is that a 307 preserves the HTTP request method (a POST request stays a POST), while a 302 might change it to GET. For WordPress sites serving regular pages, you’ll almost never need a 307. Stick with 302 for temporary redirects and 301 for permanent ones.
How do I check what type of redirect a URL is using?
The fastest way is the Ayima Redirect Path Chrome extension. Visit any URL and it shows you the full redirect chain with status codes. For bulk checking, crawl your site with Screaming Frog and filter the results by status code. You can also use curl from the command line: curl -I yourdomain.com/old-page will show you the HTTP status code and Location header.
