A redirect sends people and crawlers from one URL to another. The status code you choose tells search engines whether the move is permanent. This guide covers the codes, how Google reads them, redirect chains, and Google's documented process for site moves.
A redirect is a server response that points a request to a different URL. The HTTP standard, RFC 9110, defines the meaning of each code. A 301 says the target resource has been assigned a new permanent URI. A 302 says the resource resides temporarily under a different URI. A 307 also means temporary. A 308 means permanent, the same as 301.
The codes differ in one more way. For 301 and 302, RFC 9110 says a user agent may change the request method from POST to GET on the follow-up request, for historical reasons. For 307, it says the user agent must not change the method. This matters for forms and APIs more than for ordinary pages.
| Code | RFC 9110 meaning | Google classification |
|---|---|---|
| 301 | Moved permanently | Permanent |
| 308 | Permanent redirect | Permanent |
| 302 | Found, resides temporarily elsewhere | Temporary |
| 303 | See other | Temporary |
| 307 | Temporary redirect, method must not change | Temporary |
Google's redirect documentation splits redirects into permanent and temporary. Google follows both. With a permanent redirect, the indexing pipeline treats the redirect as a canonical signal for the target. With a temporary redirect, Google says the pipeline does not use it as a signal that the target should be canonical, so the original page may stay in results.
Google lists other redirect methods too. A meta refresh with a 0 second delay is treated as permanent. A delayed meta refresh is treated as temporary. JavaScript redirects are rendered after crawling, and Google notes that rendering may fail, so it might never see them. Google discourages JavaScript redirects unless server-side and meta refresh options are not available.
Google's preference is clear: server-side redirects are the best way to make sure Google Search and people reach the correct page. Use a permanent redirect when you are sure it will not be reverted. Use a temporary one for short-term situations, such as a service that is briefly unavailable.
A chain happens when URL A redirects to B, and B redirects to C. Google's site move documentation says Googlebot can follow up to 10 hops. It then advises keeping chains ideally to no more than 3 hops and fewer than 5.
RFC 9110 does not set a maximum number of redirects in its redirection section. The limit above is Google's, not the standard's. The practical fix is simple: when you add a new redirect, point the old URL straight at the final destination.
Google's documented process for a move with URL changes has three phases. Before the move, verify both old and new sites in Search Console, including all variants (www and non-www, HTTP and HTTPS where used). Prepare the new site, build a map from every old URL to its new URL, and update canonical tags, hreflang annotations and internal links on the new site.
When you start the move, turn on server-side permanent redirects such as 301 or 308. Google says to avoid sending many old URLs to an irrelevant page, such as the new home page. Check that canonicals point to the new URLs and that any temporary noindex rules are gone. Then submit the new sitemap and remove the old one.
If you switch hosting or add a CDN and the visible URLs stay the same, Google has a separate, shorter process. Copy and test the site on a temporary hostname with noindex. Confirm that firewalls and DoS protection do not block Googlebot. Lower the DNS TTL to a few hours at least a week before the move.
Then remove temporary robots.txt and noindex blocks and update DNS. Watch server logs on both old and new servers. Google says to expect a temporary drop in Googlebot crawl rate after launch, followed by a steady increase over a few days. Shut down the old host when its traffic reaches zero.
For a move with URL changes, Google says to keep redirects generally at least 1 year. It adds that from a user's perspective you can consider keeping them indefinitely. Google also says that medium-sized sites can take a few weeks or more for new URLs to replace old ones in results, and larger sites may take longer.
To verify, Google suggests testing redirects with the URL Inspection tool, or with scripts when you have many URLs. Warnings in Search Console about redirecting URLs in the old sitemap are expected during a move and can be ignored.
Sources were last checked on October 13, 2026. Documentation changes, so confirm any detail that matters to a decision against the source itself.
Indexive Research. (2026, August 5). Redirects and site moves, as Google documents them. Indexive AI. https://indexive.ai/research/redirects-and-site-moves
Straight answers about how we work. Still have a question? The free audit is the fastest way to get one answered for your site.
Google lists both as permanent server-side redirects. RFC 9110 defines both as permanent, and 307 as the temporary code that does not allow the method to change.
A free execution audit: your prioritized backlog, effort estimates, and what we'd ship first. Read-only access, no contract.