What Is a Redirect? Redirects Explained (301 vs 302)

TL;DR: Redirecting means one URL automatically forwards visitors and search engines to another URL. Use a 301 for a permanent move and a 302 for a temporary one. Redirects do not inherently lose PageRank, but chains, loops, broken destinations, and irrelevant homepage redirects can still cause real SEO and usability problems.

What does redirecting mean?

A redirect is an instruction that says: “That URL moved. Go to this URL instead.”

Technically, a browser requests an address and the server can respond with a 3xx HTTP status code plus a Location header containing a different address. The browser then requests that destination automatically. Search engine crawlers can follow the same instruction.

The practical redirecting meaning is simpler: the old URL no longer serves its own content; it forwards the request to a new URL.

Redirects are needed because URLs change. Pages are renamed, products are removed, sites move from HTTP to HTTPS, overlapping articles are consolidated, and domains are replaced. Without a redirect, somebody following the old address usually reaches a 404. Backlinks continue pointing at an abandoned URL, and Google receives no explicit routing instruction connecting the old page to its replacement.

We dealt with this directly when Lida and I migrated SEOJuice from seojuice.io to seojuice.com in January 2026. A domain migration makes the purpose of redirects unusually clear: every old path needs a deliberate destination, not merely a rule that sends the domain somewhere vaguely sensible. With a two-person team, there was nowhere to delegate the reasoning; the redirect map had to be treated as part of the migration itself (not the administrative task after it).

That distinction matters. Redirecting an old article to its equivalent on the new domain preserves the route. Redirecting every old address to the new homepage merely hides the missing routes.

301 vs 302: permanence is the real decision

The difference between a 301 and a 302 is not that one is “SEO-friendly” while the other is bad. Each code communicates a different expectation about what happens next.

A 301 redirect means the move is permanent. A 302 redirect means the move is temporary and the original URL is expected to return. Google follows both, but does not interpret their canonical signals in the same way.

“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.”

Those are Google Search Central’s own descriptions in its Redirects and Google Search documentation.

Translated into practical SEO, a permanent redirect asks Google to replace the old URL with the destination in its index. A temporary redirect sends users to the destination while normally retaining the original URL as canonical. If canonicalization is the confusing part, our guide to how Google indexing works covers how crawling, canonical selection, and indexing fit together.

Use a 301 for permanent URL changes

A 301 is the conventional choice for an ordinary content URL that has moved permanently. Typical cases include:

• Renaming a page or changing its URL slug
• Moving from HTTP to HTTPS
• Standardizing on either www or non-www
• Moving to a different domain
• Combining duplicate or overlapping pages
• Replacing an old page with a genuinely equivalent successor

Google recommends using a permanent server-side redirect whenever possible if a URL needs to change in search results. It calls this the best way to ensure that people and Google Search reach the correct page.

Here is the same single permanent redirect in the two most common web servers:

# Nginx — redirect one old URL to its new home
location = /old-page/ {
    return 301 https://example.com/new-page/;
}

# Apache (.htaccess) — the equivalent one-line rule
Redirect 301 /old-page/ https://example.com/new-page/

The word equivalent is doing work here. A deleted product does not become equivalent to your homepage just because both URLs belong to the same business.

Use a 302 when the original URL is coming back

A 302 fits a temporary maintenance page, an experiment, a short-lived seasonal page takeover, or routing you expect to reverse. It tells Google that the destination is not intended to become the permanent replacement.

If a page has moved for good but remains behind a 302, Google may continue indexing the old address. The redirect can appear perfectly functional in a browser while still communicating the wrong indexing intent (a useful reminder that “it loads” is not a complete redirect test).

Choose based on whether you plan to reverse the change. Permanent means 301; temporary means 302. Our separate comparison of 301 vs 302 redirects covers the less obvious migration and canonicalization cases.

What about 303, 307, and 308 redirects?

Most editorial and marketing sites can use 301 and 302 redirects for years without needing the other codes. The distinctions become important around forms, APIs, and other non-GET requests.

As documented in MDN Web Docs’ guide to HTTP redirections, 301 and 302 carry historical ambiguity around request methods. Some clients may change a POST request into a GET while following them.

That behavior is often harmless for an ordinary page view. It is not harmless if an endpoint expects a request body.

307 preserves the request temporarily

A 307 Temporary Redirect expresses the same temporary intent as a 302, but guarantees that the HTTP method and body are preserved. A POST remains a POST after the redirect.

308 preserves the request permanently

A 308 Permanent Redirect is the method-preserving counterpart to a 301. MDN explains that “308 was created to remove the ambiguity of the behavior when using non-GET methods.”

For an ordinary content page requested with GET, users will see little practical difference between 301 and 308. The same applies to 302 and 307. Method preservation becomes significant for POST and PUT requests, forms, and APIs (at which point I would involve whoever owns the backend rather than choose a status from an SEO report).

303 deliberately changes the request to GET

A 303 See Other redirect is temporary and deliberately makes the following request a GET. A common use is sending someone from a submitted form to a separate confirmation or result page, preventing a refresh from resubmitting the original POST.

This is HTTP behavior first and SEO behavior second. Do not make ordinary page redirects more exotic than necessary.

Server-side redirects beat browser workarounds

HTTP status redirects happen server-side. Two client-side alternatives also exist: HTML meta refresh and JavaScript redirects.

A meta refresh runs after an HTML document starts loading. MDN says to set its delay to zero for accessibility compliance and warns that HTTP and HTML redirect rules which fall out of sync can produce an infinite loop or “other nightmares.” The wording is memorable because the failure is real: two separately managed routing layers can start disagreeing after an otherwise routine CMS change.

A JavaScript redirect depends on the client executing JavaScript. Google Search Central states: “Only use JavaScript redirects if you can't do server-side or meta refresh redirects. While Google attempts to render every URL Googlebot crawled, rendering may fail for various reasons.”

My order of preference is:

1. A server-side HTTP redirect with the correct permanent or temporary status
2. A zero-second meta refresh if server configuration is unavailable
3. A JavaScript redirect only if neither option above is possible

Some static hosts and constrained CMS platforms do not expose the ideal server layer. That constraint is real. Still, a browser eventually reaching the destination is not the same as a clean redirect that every client can interpret consistently.

Do redirects lose PageRank?

An old SEO rule claimed that each redirect loses a fixed percentage of “link juice.” The percentages still circulate, but they should not drive implementation decisions. They are not supported by Google’s current position.

“30x redirects don't lose PageRank anymore.”

Gary Illyes of Google made that statement in 2016, as reported by Search Engine Land. The sensible conclusion is narrow but important: the mere presence of a 301, 302, or another 30x redirect does not impose an automatic PageRank penalty.

It does not follow that 301 and 302 are interchangeable.

A 301 tells Google to treat the destination as the permanent canonical replacement. A 302 usually leaves the original URL canonical because the move is temporary. PageRank handling and canonical intent are related, but they are not the same question.

I also would not promise that a domain migration will preserve every ranking without fluctuation. Redirects carry an important signal, but Google still has to recrawl URLs, process canonicals, and update its index. Clean routing removes one major source of ambiguity; it does not freeze search results in place.

The redirect mistakes that cause real damage

Redirect chains

A redirect chain sends a request through multiple URLs:

URL A → URL B → URL C → URL D

The cleaner route is URL A directly to URL D. If B and C are still linked internally, update those links to D as well.

Every hop adds another request, consumes crawler resources, and creates another rule that can fail. Long chains also risk the final destination not being reached during a particular crawl. Repeated across thousands of pages, this becomes a genuine crawl budget problem rather than a cosmetic audit warning.

There is no need to attach an invented PageRank-loss percentage to each hop. More requests, slower routing, wasted crawling, and additional failure points are sufficient reasons to collapse the chain.

Redirect loops

A loop sends the request in a circle, such as A → B → A. Browsers eventually stop and show a “too many redirects” error. The content is unreachable to users and crawlers.

Loops commonly result from conflicting rules: an HTTPS rule fighting a hostname rule, a trailing-slash rule reversing another redirect, or a meta refresh disagreeing with the server. The final browser error conceals the path, so inspect each response rather than repeatedly refreshing the page (or, more often than I would like, clearing caches and hoping).

Redirecting every deleted URL to the homepage

This is not a cleanup strategy. It replaces a clear missing-page response with an irrelevant destination.

Google’s soft-404 guidance explains that redirects to irrelevant pages can be interpreted as soft 404s. Redirect an old URL only when a genuinely relevant replacement exists. If there is no replacement, return a proper 404 or 410.

A discontinued product can reasonably redirect to its direct successor or, in some cases, a tightly related category. It should not automatically send users to a generic homepage that fails to answer the request.

Mixed protocol and hostname versions

If HTTP, HTTPS, www, and non-www variants all serve content, multiple addresses compete to represent the same page. Choose one canonical host and protocol, then permanently redirect every alternative directly to it.

Test every combination. An HTTP rule may work correctly on its own while adding a second hop or creating a loop when combined with the hostname rule.

Redirects that end on an error

A redirect is not successful merely because its first response is 301. Its final destination must return a working response.

A 301 leading to a 404 remains broken for the person who followed it. A redirect ending on a 500-series response is no better. This is why checking only the initial status code misses a substantial part of the route.

How to find and fix redirect problems

Start with a crawler such as Screaming Frog, Ahrefs Site Audit, or SEOJuice’s audit. Crawl the source URLs and follow each route to its final response. Look for:

• Redirect chains containing multiple hops
• Redirect loops
• Redirects ending in a 4xx or 5xx response
• Internal links still pointing to redirected URLs
• Permanent moves implemented with temporary redirects

From what we see across sites on SEOJuice, internal links pointing to already-redirected URLs deserve more attention than they receive. The redirect may work, so the issue looks harmless. But your site still sends every user and crawler through an unnecessary request, and future redirect changes can turn that old internal link into part of a chain.

This became especially relevant during our .io-to-.com migration. Domain-level rules can make the site appear migrated while old absolute links remain buried in pages, templates, or structured content. A working global redirect masks those links; a crawl exposes them.

Google Search Console provides Google’s view of the result. The Page indexing report can show “Page with redirect” and “Redirect error” statuses. URL Inspection displays the user-declared and Google-selected canonical, which helps when Google has not accepted the destination you expected.

For a single suspicious URL, use the Network panel in browser DevTools. Inspect every status and Location response until the final page loads or the route fails. This is faster than running a full crawl when you are debugging one rule.

Prioritize fixes in this order:

1. Remove loops because they make pages unreachable.
2. Repair redirects ending in 4xx or 5xx responses.
3. Collapse chains so old URLs point directly to final destinations.
4. Replace irrelevant redirects with relevant destinations or real 404/410 responses.
5. Update internal links to bypass redirects.
6. Confirm permanent moves use a permanent status.

SEOJuice’s SEO audit surfaces redirect chains, broken redirects, and internal links pointing at redirected URLs, giving you a practical list to work through. It does not rewrite nginx, .htaccess, CDN, or CMS redirect rules for you; those changes still belong in the infrastructure that controls the response.

A redirect checklist for site migrations

Treat redirects as routing rules, not SEO magic. Choose a relevant destination, state whether the move is permanent, and remove avoidable hops. Most redirect decisions become straightforward once those three points are explicit.

Frequently Asked Questions

What does “redirecting” mean?

Redirecting means a URL no longer serves its own content and instead forwards visitors and search engines to another URL. A server-side redirect normally returns a 3xx HTTP status plus the destination address, which the browser requests automatically.

What is the difference between a 301 and a 302 redirect?

A 301 says the move is permanent, allowing Google to treat the destination as canonical. A 302 says the move is temporary, so Google generally keeps the original URL indexed. Use a 301 if the old page will not return and a 302 if it will.

Do redirects hurt SEO?

Correctly implemented redirects do not inherently hurt SEO. Google recommends permanent server-side redirects for permanent moves, and Gary Illyes stated that 30x redirects do not lose PageRank. SEO problems arise from chains, loops, broken destinations, irrelevant redirects, and status codes that communicate the wrong intent.

What is a redirect chain?

A redirect chain occurs when URL A redirects to URL B, which redirects again to URL C. It adds unnecessary requests and crawler work. Fix it by pointing URL A directly to URL C and updating internal links to use the final address.

What causes a “too many redirects” error?

A redirect loop causes this error. Two or more rules send the request in a circle, often because HTTPS, www, trailing-slash, server-side, or meta-refresh rules conflict. The browser eventually stops following the cycle.

When should I use a 307 or 308 redirect?

Use 307 for a temporary move and 308 for a permanent move when the original HTTP method and request body must be preserved. They matter most for forms and API requests using methods such as POST or PUT. For ordinary content pages requested with GET, 301 and 302 remain the conventional choices.