Every site move or URL cleanup runs into the same worry: whether 301 redirects will hurt SEO. The short answer is no, not when they're set up the way Google's own documentation describes. The longer answer is about which redirect type to use, how to map old URLs to new ones, and what to check in Search Console while Google catches up. This guide walks through 301 redirects and SEO from the first decision to the final check, using Google's own crawling and indexing documentation as the source.
301 redirects and SEO work together: a 301 tells Google a page has moved permanently, so Google's indexing systems treat the new URL as the one to rank instead of the old one. Google says permanent redirects don't cause a loss in PageRank. Used correctly, 301s protect rankings during a move; chained or temporary redirects slow the transfer down.
Prerequisites
Before you touch a redirect, have these ready:
- Server or CMS access that can return a real HTTP status code: your host's
.htaccessor NGINX config, a server-side script, or a CMS redirect manager that sets a true 301 rather than a meta refresh. - Verified Search Console properties for every variant of the old and new site:
wwwand non-www, HTTP and HTTPS. Google's site move guide recommends verifying each one separately before you start. - A current list of your URLs, pulled from your sitemap, server logs, your CMS, or the Links report in Search Console, including images, PDFs, and any other files hosted on their own URLs.
- A sitemap you can update with the new URLs once the move starts. Submitting it helps Google discover the new pages faster.
Step 1: Why 301 redirects and SEO rankings rise or fall together
Google splits every redirect into two buckets, and which bucket you land in decides what shows up in search results. A permanent redirect tells Google the old URL is gone for good; the indexing pipeline uses that as a signal that the new URL should become canonical. Google's guide to HTTP status codes describes a 301 specifically as a strong signal that the target should be processed. A temporary redirect does the opposite: Googlebot follows it, but keeps showing the old URL in results, because the indexing pipeline doesn't treat a temporary redirect as a reason to swap the canonical. Google's redirects documentation ranks a 302 as only a weak signal to process the new target.
Permanent options include an HTTP 301, an HTTP 308, an instant meta refresh set to 0 seconds, an instant HTTP refresh, and a JavaScript location redirect. Temporary options include HTTP 302, 303, and 307, plus a meta refresh or HTTP refresh set to more than 0 seconds. Google ranks these by how reliably it can interpret them, and a server-side redirect sits at the top of that list in both cases. If none of those are available, Google says it may even recognize a plain link to the new page, with a short explanation, as what it calls a crypto redirect, though it compares that method's reliability to the Loch Ness monster: not every search engine agrees it counts as a redirect at all.
Use a temporary redirect only when the move really is temporary, such as a page that's offline while a service is down. Use a permanent redirect for anything meant to stay that way, including a full site move, a domain change, or a page retired for good.
Step 2: Map every old URL to its new destination
Before writing a single redirect rule, build a list of every URL that needs one. Google's site move guide suggests starting with the most important URLs: check your sitemap, since your most important pages are likely already listed there; check server logs or analytics for the URLs getting the most traffic; and check the Links report in Search Console for pages with the most internal and external links pointing at them. Your CMS can usually export a full list of everything it hosts. Don't forget images, PDFs, videos, JavaScript, and CSS files that live on their own URLs. They need a mapping too.
Once you have the list, decide where each URL should redirect to, and store that mapping somewhere you can maintain, whether that's a spreadsheet, a database, or a set of URL rewrite rules. For small and medium sites, Google recommends moving all the URLs at once rather than in pieces, since that helps its algorithms detect the move and update the index faster. Large sites can move section by section, which makes it easier to monitor and fix problems as they come up. Either way, if the move is going to take time, start with a section that changes infrequently, so the process can be tested before the rest of the site depends on it.
Step 3: Set up the redirects on your server
Server-side redirects are the most reliable option, because they don't depend on a browser executing anything first. On PHP, you can set the status code and destination directly:
header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/newurl');
exit();
On Apache, mod_alias handles simple one-to-one redirects inside .htaccess:
# Permanent redirect:
Redirect permanent "/old" "https://example.com/new"
# Temporary redirect:
Redirect temp "/two-old" "https://example.com/two-new"
For pattern-based redirects, such as a whole folder moving to a new structure, use mod_rewrite:
RewriteEngine on
RewriteRule "^/service$" "/about/service" [R=301]
On NGINX, the equivalent sits inside the matching location block:
location = /service {
return 301 $scheme://example.com/about/service;
}
Whichever method you use, avoid chaining redirects through multiple hops. Googlebot will follow up to 10 redirects in a row, but Google's site move guide recommends redirecting straight to the final destination, and keeping any unavoidable chain to no more than 3 hops and fewer than 5. Every extra hop adds latency, and not every browser or crawler supports long chains.
Step 4: Point every signal at the new URL
A redirect is the strongest signal you can give Google about which URL should be canonical, but it works best alongside the other signals rather than instead of them. Google's canonicalization documentation, updated 10 July 2026, ranks redirects as the strongest canonicalization method, ahead of rel="canonical" link annotations, with sitemap inclusion the weakest of the three. Using more than one at once increases the odds that the preferred URL is the one Google shows.
On every new page, add a self-referencing rel="canonical" link pointing at itself:
<link rel="canonical" href="https://example.com/dresses/green-dresses" />
Use the full absolute URL, not a relative path. Then update internal links so they point straight to the new URLs instead of to old ones that redirect, update the sitemap to list only the new URLs, and update any hreflang annotations to the new URLs as well.
A few things to avoid here: don't declare one URL as canonical in the sitemap and a different one in the rel="canonical" tag, since Google treats that as a conflicting signal. Don't use noindex to steer Google away from a duplicate, since that blocks the page from Search entirely instead of consolidating it. And don't use robots.txt or the URL removal tool to manage duplicates: a disallowed URL in robots.txt can still get indexed without its content, and the removal tool hides every version of a URL from Search, not just the one that should go.
Step 5: Verify the move in Search Console and wait it out
Verify the old site and the new site as separate properties in Search Console, including every www, non-www, HTTP, and HTTPS variant of each. Google's site move guide points to two reports worth checking regularly: the Index Status report for a broad view of what's indexed, and the Sitemaps report to see how many of the submitted URLs have actually been indexed. If the move includes a switch to HTTPS or a new domain, set the crawl rate setting to "Let Googlebot determine" on both properties, and if backlinks were previously disavowed, re-upload that disavow file under the new property.
Then be patient. Google considers a site move complete once Googlebot has visited every URL on both the old and new site at least once, and there's no fixed schedule for that. How fast it happens depends on the number of URLs being moved and how fast the server responds, which is also why an updated sitemap helps: it gives Google a direct list of what to check. Expect rankings to fluctuate while this happens. For a medium-sized site, Google says it can take a few weeks or more for the new URLs to fully replace the old ones in search results, and longer for a larger site. A rank tracker that charts position over time, such as SEOAgent's rank tracking, makes it easier to tell a normal dip during this window from a page that needs attention.
Common mistakes
- Using a 302 for a move that's actually permanent. Google treats a 302 as only a weak signal to swap in the new URL, so the old one can keep showing in search results long after it was meant to disappear. If the move is permanent, use a 301 or 308.
- Chaining redirects across too many hops. Googlebot will follow up to 10 redirects in a row, but each extra hop adds latency, and Google recommends keeping a chain to no more than 3 hops, fewer than 5 at most.
- Panicking over a high "pages with redirect" count in Search Console. In Google's July 2023 SEO office hours, one site owner said their site had migrated about a year earlier and Search Console still listed about a million pages with redirect. Google's answer: that's normal, old URLs can stay in Google's memory a long time, and as long as they keep redirecting correctly, it isn't a problem. They drop out gradually on their own.
- Treating 404s as worse than they are. The same office hours session covered whether a large number of 404 errors hurts the rankings of pages that return a 200. The answer was no. Asked to compare the harm from millions of 404 pages against millions of 301 redirects, Google's answer was that both status codes are completely harmless, and the choice between them should come down to what fits the situation.
- Skipping the audit after the move. A redirect that got missed, a page left off the new sitemap, or a canonical tag still pointing at the old domain are all easy to overlook by hand across a few hundred URLs. SEOAgent's site audit crawls every page and checks its status code, canonical tag, and indexability in the same pass, which is worth running right after a move, not just before one.
What's new (as of 2026-10-24)
Google has updated all three documents behind this guide in 2026. Its guide to HTTP status codes, which draws the line between a 301 as a strong signal and a 302 as a weak one, lists 4 February 2026 as its last update. The redirects documentation carries a 14 April 2026 update date, and still lays out the same five permanent methods (301, 308, instant meta refresh, instant HTTP refresh, and JavaScript location) against five temporary ones (302, 303, 307, and a delayed meta refresh or HTTP refresh), ranked by how reliably Google can interpret each. And on 10 July 2026, Google updated its canonicalization documentation to directly compare redirects, rel="canonical", and sitemaps side by side, confirming redirects as the strongest of the three signals.
Once the redirects are live and the sitemap lists the new URLs, submitting them directly through IndexNow and the Google Indexing API is the fastest way to get Google crawling the move.
Key takeaways
- A permanent redirect (301 or 308) tells Google a URL has moved for good and counts as a strong signal to rank the new URL; a temporary one (302, 303, or 307) is only a weak signal and keeps the old URL showing in results.
- Google has confirmed that 301s and other permanent redirects don't cause a loss in PageRank, and that large numbers of 404 or 301 pages are both harmless on their own.
- Redirects are the strongest canonicalization signal Google recognizes, ahead of rel="canonical" link annotations and sitemap inclusion, and the three stack when used together.
- Keep redirect chains to 3 hops or fewer; Googlebot will follow up to 10, but each hop adds latency.
- Expect ranking fluctuation for a few weeks or more during a site move, longer for larger sites, and expect Search Console's "pages with redirect" count to stay high and fade out gradually on its own.
FAQ
Do 301 redirects hurt SEO?
No. Google has stated directly that 301s and other permanent redirects don't cause a loss in PageRank, and that Google's indexing systems treat a 301 as a strong signal to rank the new URL in place of the old one. Problems during a move usually come from using a 302 instead of a 301, chaining too many redirects together, or leaving canonical tags and sitemaps pointing at old URLs, not from the 301 itself.
Should I use a 301 or a 302 redirect?
Use a 301 (or 308) when the move is permanent, since Google treats it as a strong signal to show the new URL in search results instead of the old one. Use a 302 (or 303, 307) only when the change is genuinely temporary, such as a page that's offline while a service is unavailable, since Google keeps showing the old URL in results and doesn't treat the redirect as a reason to swap the canonical.
How long does it take for rankings to recover after a site move?
Google says it can take a few weeks or more for a medium-sized site to see the new URLs fully replace the old ones in search results, and longer for a larger site, since the speed depends on how many URLs are involved and how fast the server responds. Submitting an updated sitemap as soon as the move starts helps Google discover the new URLs faster.
Is a high "pages with redirect" count in Search Console a problem?
Not on its own. Google has said that old URLs can stay in its systems' memory for a long time after a migration, and a large "pages with redirect" count is normal as long as those URLs are still redirecting correctly. They tend to drop out gradually over time without any action needed.