301 Redirect SEO: HTTP 301 vs 302 Status Codes and Which One Google Uses to Move Your Indexed URL

301 vs 302: which redirect should you use?

Use a 301 for anything permanent and a 302 only when the original URL is genuinely coming back. The difference is not about strength or speed. Both get followed. The difference is what the indexing pipeline does afterwards.

Google spells out both halves. For permanent redirects: "Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." For temporary redirects: "Googlebot follows the redirect, but the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical." The practical result is that a permanent redirect shows the new URL in search results and a temporary one keeps showing the old one.

This is why a 302 on a migration is such an expensive mistake. Everything appears to work. Users reach the new page, analytics fills up, the redirect returns a valid response. But Google keeps the old URL in the index, keeps sending traffic to an address you intended to retire, and never transfers the canonical status you were trying to move. Teams often discover it months later while investigating why the new URLs will not rank, and the answer is that Google was never asked to rank them.

The reverse mistake is rarer but real. Firing a 301 at a page that is out of stock for three weeks, or a landing page paused between campaigns, hands away a URL you wanted to keep. When the page comes back, you are waiting on a recrawl to undo something that a 302 would have avoided entirely.

• Permanent (use 301 or 308): domain change, replatform, HTTP to HTTPS, www to non-www, merging duplicate pages, retiring a URL that has a clear replacement.
• Temporary (use 302, 303 or 307): maintenance pages, geo or device variants that will revert, A/B tests, out of stock products that are coming back, short campaign redirects.
• Neither: a page with no meaningful equivalent. A clean 404 or 410 is more honest than dumping it on the homepage, and Google treats a 404 as a strong signal not to crawl that URL again.

Does a 301 redirect pass link juice?

Yes. Google has said publicly and repeatedly that redirects do not cost PageRank. The clearest version came from Gary Illyes of Google in July 2016, stating that 30x redirects do not lose PageRank anymore, and John Mueller had said the same thing earlier that year. The older belief that a 301 costs you a percentage of link equity comes from guidance that Google itself has since retired, and it has not been true for a long time.

What that does not mean is that a redirect makes the target rank like the source. Signals move, but so does relevance. If you 301 a page about commercial roofing quotes into a generic services page, Google now has a target that matches the original queries much less well. The links point somewhere, and the rankings still fall, and people read that as PageRank loss when the actual loss is topical fit. The rule that holds up in practice is to redirect to the closest genuine equivalent, one page at a time, and accept a 404 where no equivalent exists.

The other real cost is time. Signals do not transfer at the moment you deploy the rule. They transfer as Google recrawls each old URL, sees the redirect, and processes it. On a large site that is weeks of partial state where some pages have moved and others have not, which is exactly what a temporary ranking dip during a migration looks like from the outside.

How long does a 301 redirect take to work, and how long should you keep it?

The redirect works instantly for humans and takes weeks for Google, because Google has to recrawl the old URL to find out about it. Google's guidance on site moves puts a number on the aggregate: "as a general rule, a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer". There is no way to speed this up per URL beyond the usual crawl signals, and no service can force it.

Because the work is per URL, progress is uneven in a way that alarms people. Your most crawled pages move within days. A product page Googlebot visits every six weeks moves in six weeks. During that window the index genuinely contains a mixture of old and new URLs, and reporting that shows both is accurate rather than broken.

On retention, Google is unambiguous: "keep the redirects for as long as possible, generally at least 1 year". That is deliberately longer than most teams plan for, and it is longer than the 180 days the Change of Address tool forwards signals for after a domain change. The trap is reading 180 days as the length of the migration, retiring the old domain at six or seven months, and taking down redirects Google is still using. Renew the old domain past the redirect window, and treat the rules as permanent infrastructure. There is no upside to removing them.

How to set up a 301 redirect

Server-side is the only method worth planning around. Google orders redirect types by how reliably it can interpret them and puts server-side redirects at the top, noting that "a server side redirect has the highest chance of being interpreted correctly by Google". Everything else on the list is a fallback for when you do not control the server.

Wherever you implement it, redirect to a specific target, not to a category or the homepage, and redirect to the final URL rather than to something that redirects again. Both of those sound obvious and both are where large redirect maps go wrong, usually because a bulk rule was written with a wildcard that was easier than the mapping work.

• Apache (.htaccess): Redirect 301 /old-page /new-page, or RewriteRule with the R=301 flag for pattern matching. Confirm mod_rewrite is enabled and that no earlier rule matches first.
• Nginx: return 301 https://example.com/new-page; inside a location block. Use return rather than rewrite where you can, because it is faster and clearer to read.
• WordPress: a redirect plugin writes rules into the database and applies them in PHP. That works, but every request pays for it, so move high-volume rules into the server config once the map settles.
• Cloudflare and other CDNs: bulk redirects and redirect rules run at the edge before the request reaches your origin. Fast, and easy to forget about, so document them where whoever debugs this next will look.
• Next.js, Rails, Laravel and similar frameworks: a redirects config or route-level permanent redirect. Keep the map in version control so a deploy cannot silently drop it, which is one of the most common ways redirects disappear.

Redirect chains, loops, and the 10 hop limit

A redirect chain is an old URL that points at another URL that points at a third. They accumulate honestly: a restructure in 2023, a domain change in 2025, and suddenly the original address takes three hops to arrive. Google does follow chains, and it publishes the limit: "by default, Google's crawlers follow up to 10 redirect hops". So a two hop chain is not fatal.

It is still worth flattening, for two reasons that have nothing to do with the hop limit. Each hop is a request Googlebot has to spend, which matters on large sites where crawl capacity is the constraint. And each hop is another rule that a future config change can break, at which point the whole chain fails and you lose the original URL rather than one hop of it. Point every old URL at its final destination directly and the chain stops being a dependency.

A redirect loop, where A points to B and B points back to A, is a hard failure. Browsers report it as too many redirects and crawlers give up. Loops are usually accidental collisions between rules written at different times, most often a trailing slash rule fighting a canonical hostname rule, or a CDN edge rule and an origin rule each trying to enforce HTTPS. Test the actual response chain rather than the config, because the config rarely shows you the interaction.

How to check whether Google actually moved to the new URL

Verifying a redirect and verifying a move are different jobs. curl or a browser tells you the server is answering correctly. It cannot tell you whether Google recrawled the old URL, followed the redirect, accepted the target as canonical, and indexed it. Those four things happen inside Google, days or weeks after your deploy, and every one of them can fail while your redirect stays perfectly healthy.

In Search Console, an old URL that has been processed correctly shows up under the Page with redirect status, which means Google has seen the redirect and is no longer indexing that address. That is the outcome you want on the source side. On the target side you want the new URL indexed. Checking one without the other is how half-finished moves get signed off. Bear in mind the Page indexing report caps its example lists: Google states that "the list of example URLs in the report is limited to 1,000 items, and isn't guaranteed to show all URLs in a given status, even when less than 1,000 items".

That cap is why redirect maps of any size need a bulk check instead. Load both URL lists into Indexing and you get the status of each side together: old URLs still held in the index, new URLs picked up, and a named reason for the ones being refused, which in redirect work is nearly always a canonical still pointing at the old address, a noindex that shipped with the new template, or a chain that never got flattened. Targets that qualify get resubmitted through the official Google Indexing API, IndexNow and your sitemaps, and time to index is tracked so you can show the fix landed.