In this guide
Key takeaways
- For a lasting move, use 301 (or its method-preserving twin 308). For a short-term move, use 302 (or 307). Google groups them in those two pairs.
- The 301 versus 308 and 302 versus 307 choice is about the HTTP method. For ordinary pages Google crawls it makes no practical difference. It matters for forms, APIs and apps.
- Google treats permanent redirects as a strong signal that the target should be canonical, and temporary redirects as a weak one. Using the wrong kind leaves the wrong URL in search.
- Aim for one hop from each old URL to its final destination. Chains waste crawling, and Google follows only up to 10 hops.
- Redirect to the closest equivalent page. If none exists, return a 404 or 410. Do not send everything to the homepage.
The short answer
When someone asks me which redirect to use, I ask one question first: is the old URL coming back? If not, it is permanent. If it is, it is temporary. Everything else is detail.
| Code | Meaning | Method on redirect | Use it for |
|---|---|---|---|
| 301 | Moved permanently | Clients may switch POST to GET | Permanent page moves, domain changes, HTTP to HTTPS, merging pages |
| 308 | Permanent redirect | Method and body must be kept | Permanent moves where a form or API call must still work |
| 302 | Found (temporary) | Clients may switch POST to GET | Short-term moves, maintenance pages, tests |
| 307 | Temporary redirect | Method and body must be kept | Temporary moves where the method must be kept |
| 303 | See other | Always followed with GET | Sending a user to a confirmation page after a form submission |
For nearly every website page I deal with, the answer is 301. The other codes have real uses, covered below, but they are the exception.
Permanent versus temporary: what Google does
This is the distinction that affects search results. Google's documentation says that 301 and 308 mean a page has permanently moved, while 302 and 307 are temporary. Its crawler documentation treats 308 as equivalent to 301 and 307 as equivalent to 302, and handles 303 like 302.
- Permanent redirects are used as a signal that the redirect target should be canonical, and the target is what Google shows in search results.
- Temporary redirects are not used as a signal that the target should be canonical, and the source page keeps showing in results. The target can still be indexed if other canonicalisation signals point to it.
The practical lesson: if you move a page for good but use a 302, you may find the old URL still showing and the new one slow to take over. If you use a 301 for something that is really temporary, such as a short promotion, the target is treated as the page to keep. Use the code that matches your intention.
Other ways to redirect
Google also reads an instant meta refresh as a permanent redirect and a delayed one as temporary, and it can follow redirects done in JavaScript. Its advice is to use JavaScript redirects only when you cannot do a server-side redirect or a meta refresh, because rendering can fail and Google might never see the redirect. I use server-side redirects wherever I have the choice, and the JavaScript SEO guide explains why rendering can fail.
When the HTTP method matters
The reason four codes exist, instead of two, is history. When a browser sends a form with POST and receives a 301 or 302, the HTTP standard (RFC 9110) lets it follow the redirect with a GET instead, for historical reasons. That is what most browsers do. Codes 307 and 308 were created to say "repeat the same request, with the same method and body, at the new address".
- For a page crawled by Google there is nothing to preserve. Google does not submit your forms. Treat 301 and 308 as the same, and 302 and 307 as the same.
- For an API or a form handler that has moved, a 307 or 308 keeps a POST a POST. Without it, a client may arrive at the new address with a GET and lose the data it was sending.
- After a successful form submission, a 303 sends the browser to a confirmation page with GET. This is the post-redirect-get pattern, and it stops a refresh from submitting the form twice.
So if a developer says "we should use 308 because it preserves the method", they are right in an application context, and it will not change how Google handles an ordinary page. I would not argue the point. I would check that the moved URL is not a form endpoint and move on.
If you see a 307 you did not set
Chrome's developer tools can show a "307 Internal Redirect" when a site uses HTTPS strict transport security. The browser upgrades the request to HTTPS itself, without asking your server. It is not a redirect your server sent, so it is not something to fix in your redirect rules.
What breaks when you pick wrong
| Mistake | What happens | Fix |
|---|---|---|
| 302 used for a permanent move | Google keeps the old URL as the one to show. The new URL is slower to take over | Switch to 301 or 308 once the move is final |
| 301 used for something temporary | The target is treated as the page to keep, and browsers may cache the permanent redirect, so reversing it can be slow for returning visitors | Use 302 or 307 for anything you may undo |
| Redirect chains | Each extra hop adds delay and uses crawl effort. Google warns long chains hurt crawling | Point every old URL straight at the final one |
| Redirect loops | The URL never resolves. Search Console reports a redirect error | Trace the chain and break the cycle with one correct destination |
| Everything sent to the homepage | Unrelated redirects can be treated as soft 404s, and users land on a page they did not ask for | Map each URL to its closest equivalent, or return 404 or 410 |
| Old URL blocked in robots.txt | Google cannot fetch the old URL, so it never sees the redirect | Leave redirecting URLs crawlable. See the robots.txt guide |
| Canonical, sitemap and links still point at old URLs | Mixed signals. Google must reconcile conflicting instructions | Update canonicals, sitemaps and internal links to the final URLs |
| Method lost on a form or API | A POST arrives as a GET and the data is lost | Use 307 or 308 for endpoints, or 303 after a successful submission |
Chains and loops
A chain is a redirect that leads to another redirect. They build up quietly: a site moves to HTTPS, then to a new domain, then to a new structure, and every old rule points at the previous destination instead of the final one. A request for an old URL then makes three or four hops before it reaches a page.
- Limits. Google says its crawlers follow up to 10 redirect hops by default, and its crawl guidance advises avoiding long chains. In Search Console, a URL that does not resolve in time is reported as a redirect error.
- The most common chain I find is the host variants:
http://wwwtohttps://wwwtohttps://without www. Each of the four host and protocol combinations should reach the preferred version in a single hop. - Loops come from two rules that disagree, such as a trailing-slash rule undoing a path rule. The Redirect Checker traces every hop with its status code and flags loops, chains and 302s.
The fix is boring and reliable: write the redirect map as a table of old URL to final URL, and regenerate the rules from it each time, rather than adding a new rule on top of the old ones.
Mapping and implementing redirects
- Inventory the URLs that will change. Pull them from a crawl, the sitemap, Search Console and your analytics, so pages that earn traffic or links are included.
- Map each old URL to its closest equivalent. Match by topic and intent. The Redirect Mapping Tool gives a confidence-scored first draft that you correct by hand.
- Decide the code for each row. 301 for permanent, 302 for temporary, and a 404 or 410 where nothing matches.
- Generate the rules for your server or host. The Redirect Rule Generator outputs rules for several platforms.
- Test before launch. Run every old URL through the SEO Migration Redirect Checker and look for chains, loops, wrong destinations and 404s.
- Update everything that points at the old URLs. Internal links, canonical tags, hreflang and the sitemap should all use the final addresses.
- Keep the redirects in place. Google's site move guidance generally suggests at least a year, and nothing stops you keeping them longer.
- Monitor. Watch the Page indexing report for redirect and not found statuses, and check status codes again after the first crawl.
Google's own examples show the shape of a server-side rule. These are the same permanent redirect written for two common web servers:
# Apache (.htaccess or server config)
Redirect permanent "/old-page" "https://www.example.com/new-page"
# Nginx (inside a server or location block)
return 301 https://www.example.com/new-page;For large moves I use generated rules rather than hand-typed ones, and I read the checker's results before anything goes live. The full process for redesigns is in the migration audit checklist, and a template change can create the same problems at a smaller scale, as in the deploy guide.
Tip when testing: Search Console's URL Inspection tool does not follow redirects, so it will show you the redirecting URL rather than the destination. Use a redirect checker for the chain, then inspect the final URL.
Lessons from my own site
In October 2026 I rebuilt the redirects on this site after Search Console reported URLs I had deleted. The principles in this guide are the ones I applied. Each old URL went to its closest equivalent in a single hop, with no chains. Sections that had no equivalent returned 410 Gone, rather than being redirected to the homepage.
One practical catch is worth passing on. My host limits how many wildcard redirect rules a site can have, and it counts every rule below the first wildcard as one of them, so a wildcard near the top can push later rules over the limit and stop them applying. I now keep all exact-match rules at the top of the file and the wildcard rules at the end. If your platform has a rule limit, find out what it counts before you build a long redirect file.
Redirects on your platform
Most hosted platforms give you a redirect manager rather than a server file, and each has its own quirks about slug changes, wildcards and limits. I cover the ones that trip people up in the platform guide for Shopify, WordPress and Webflow. If you are planning a move and want it checked, my SEO migration service covers the mapping, the testing and the post-launch monitoring, and the wider technical SEO service covers the surrounding clean-up. The framework that places redirects within crawling and indexing is in technical SEO in four questions.
Frequently asked questions
Should I use 301 or 308 for a permanent redirect?
For ordinary web pages, either. Google treats 308 the same as 301. Use 301 as the default, and choose 308 when a moved URL receives form submissions or API calls and the method must be kept.
Is a 302 bad for SEO?
Not when it is used for what it means. A 302 is right for a short-term move you will undo. It is wrong for a permanent move, because Google keeps showing the old URL and does not treat the target as canonical.
Does a 301 lose ranking?
Google's documentation does not describe any loss from a permanent redirect itself. What causes loss is the surrounding mess: redirecting to an unrelated page, long chains, or leaving internal links and canonicals pointing at old URLs.
How many redirects in a row will Google follow?
Up to 10 hops by default, according to Google's crawler documentation. Aim for one, because every extra hop adds delay and wastes crawling.
Should I redirect deleted pages to the homepage?
No. Redirect to the closest equivalent page. If none exists, return a 404 or 410. Google treats 404 and 410 alike, and sending many unrelated URLs to one page can be treated as a soft 404.
How long should I keep redirects?
As long as possible. Google's site move guidance generally suggests at least a year, and redirects can stay indefinitely if they are still being used by visitors or links.
What redirect should I use from HTTP to HTTPS?
A permanent one, 301 or 308, sending every HTTP address straight to the final HTTPS address in one hop, with the host variants resolved in the same step.
Why does my browser show 307 when I set a 301?
If the site uses HSTS, the browser may upgrade the request itself and label it an internal redirect. Check what the server sends with a header viewer or the redirect checker rather than the browser's network panel alone.
Sources and further reading
Statements about Google in this guide are based on the pages below, checked on 24 October 2026. The server examples are illustrations from Google's documentation, so test them in your own environment.
- Redirects and Google Search: permanent and temporary redirects, meta refresh, JavaScript redirects and server examples
- How HTTP status codes affect Google's crawlers: redirect hops, 301 and 308 as strong signals, 302 and 307 as weak signals, 404 and 410, 5xx
- Site moves with URL changes: mapping old URLs to equivalents and keeping redirects in place
- Managing crawl budget for large sites: avoid long redirect chains; soft 404s
- How to specify a canonical URL: redirects as canonicalisation signals
- Introduction to robots.txt: a blocked URL cannot be fetched, so a redirect on it is not seen
- Page indexing report: Page with redirect and Redirect error statuses
- URL Inspection tool: inspecting the final URL and the live test
- RFC 9110: HTTP Semantics, section 15.4 Redirection 3xx: the standard definition of each redirect status code, including when a client may change the method