301 Redirects and Site Migration: How to Move Your Website Without Losing Your Rankings

by Francis Rozange | Mar 28, 2026 | SEO

What Redirects Actually Are and Why They Matter

A redirect is an instruction that tells a browser and search engines to go to a different URL when someone tries to access the original one. Think of it like a forwarding address for your website. When you move to a new house, you tell the post office where your mail should go. Redirects work the same way for web pages. Without them, visitors would hit error pages, search engine robots would waste time crawling dead links, and you would lose the ranking value built up over years. The difference between a proper redirect and no redirect at all can mean thousands of visitors and the difference between maintaining your organic traffic or starting from zero.

Search engines like Google follow redirects automatically. They understand that websites change, restructure, and evolve. The question for you is not whether to use redirects when things move, but which type to use and how to implement them correctly. A poorly configured redirect can waste crawl budget, confuse search engines, and slow down your site. A properly configured redirect passes ranking signals smoothly and tells search engines exactly where your content moved. The choice matters, but not always in the way the SEO industry claims it does.

The Different Types of Redirects Google Recognizes

Google recognizes several types of redirects, and understanding the differences helps you pick the right one for your situation. Each type sends a specific HTTP status code that tells browsers and search engines how to interpret the move. Some redirects say “this change is permanent” while others say “this is temporary, check back later.” Some redirects happen on the server side before anything reaches the user, while others happen in the browser after the page loads. Getting the type right matters for clarity and efficiency, even if the PageRank implications are not what you might have heard.

Permanent Redirects

Permanent redirects include 301, 308, and instant meta refresh tags. A 301 redirect sends an HTTP 301 status code and tells search engines that a URL has permanently moved. The 308 redirect is the newer standard and works almost identically to 301 but with stricter HTTP method handling. Meta refresh with a delay of zero seconds acts as a permanent redirect in search engine terms. Permanent redirects are appropriate when you have definitively moved a page and will never use the old URL again. Google treats permanent redirects as a strong signal that the old URL should stop ranking and all ranking power should flow to the new URL.

The critical point about permanent redirects is that they should stay active indefinitely, though a minimum of one year is recommended by Google. Webmasters sometimes remove redirects after a few months thinking the migration is complete, but search engines may still encounter old links from external sites pointing to the old URLs. If the redirect is gone, visitors hit 404 errors instead of reaching the content. Google Search Central explicitly recommends keeping redirects active for at least one year, and many experienced SEOs keep them permanently to be safe. The cost of keeping a redirect active is negligible compared to the damage of removing it too soon.

Temporary Redirects

Temporary redirects include 302, 303, and 307 status codes, plus meta refresh tags with a delay greater than zero seconds. These redirects tell search engines that the move is temporary and the original URL might come back. When Google sees a temporary redirect, it may continue crawling and trying to rank the original URL. This makes temporary redirects appropriate only when you truly expect the original URL to be active again. Most site changes are not temporary, even if they feel that way to you. If you are restructuring your site, changing your domain, or consolidating content, use a permanent redirect unless you genuinely plan to reactivate the original URL.

Many webmasters mistakenly use 302 redirects when they should use 301 redirects. They assume that the search engine implications are different, but Google’s Gary Illyes confirmed in July 2016 that 30x redirects no longer lose PageRank, meaning 301, 302, 303, and 307 all pass ranking signals the same way. John Mueller reiterated multiple times in Search Central office hours that the choice between 301 and 302 has no ranking impact. The real consideration is accuracy: are you making a permanent change or a temporary one? If you are permanently restructuring your site, use 301. If you are testing a change and plan to bring the old URL back, use 302. Most migrations are permanent and should use 301.

JavaScript and Meta Refresh Redirects

JavaScript redirects and meta refresh tags work differently from HTTP-level redirects. A JavaScript redirect uses code in the page to send users to a new URL after the page loads. A meta refresh tag in the HTML tells browsers to redirect after a set number of seconds. These redirects are less efficient than HTTP-level redirects because the browser must download and parse the page before redirecting. Search engines can follow them, but they are slower and use more resources. Google recommends server-side HTTP redirects for better performance and reliability. Use JavaScript or meta refresh redirects only when server-side redirects are not available or for tracking purposes before the redirect.

The 301 vs 302 Debate That Google Already Settled

The SEO industry has obsessed over whether 301 or 302 redirects pass PageRank equally. For years, the common wisdom was that 301 redirects passed full PageRank while 302 redirects lost some value. This claim originated from Google’s algorithm documentation but has been repeatedly contradicted by Google’s own search engineers in public statements. In July 2016, Gary Illyes tweeted that 30x redirects no longer lose PageRank. John Mueller confirmed this multiple times in Search Central office hours and public forums. Both 301 and 302 pass ranking signals the same way. The only difference Gary Illyes noted is that “301 helps with canonicalization,” meaning it gives Google a clearer signal about which URL should appear in search results.

The real reason to choose between 301 and 302 is semantic accuracy, not ranking power. Use 301 when you are making a permanent change. Use 302 when you are making a temporary change. Tell Google the truth about your intentions, and let it interpret the redirect correctly. If you use 302 for a change you made permanent three years ago, Google might still crawl the old URL hoping it comes back, wasting crawl budget. If you use 301 for a change you plan to undo next month, you have told Google the wrong story. The focus should be on accuracy and on the other factors that actually affect your rankings, like content quality, site speed, and crawl budget efficiency.

Redirect Chains: What They Cost You and What They Don’t

A redirect chain occurs when one URL redirects to a second URL which then redirects to a third URL. Each redirect adds latency, meaning it takes longer for a visitor to reach the final destination. Each redirect also requires the search engine to make an additional request and parse an additional response. Google Search Central documentation states that Googlebot follows up to ten hops in a redirect chain but recommends keeping them under five and ideally under three. John Mueller specified that the ten-hop limit is cumulative: per individual crawl attempt, Googlebot follows up to five hops before stopping. Redirect chains do not lose PageRank, but they do waste crawl budget and slow down your site.

Many SEOs treat redirect chains as a critical ranking factor, but they are really a performance and efficiency issue. If you have a chain of three redirects and each one adds 200 milliseconds of latency, your site slows down by 600 milliseconds. For users, this is noticeable. For Google, this means it can crawl fewer pages with the same crawl budget. The solution is to map all your old URLs directly to their final destinations instead of chaining redirects together. If you are migrating old content to new URLs, make sure your redirect points directly to the final destination, not to an intermediate URL. Check your server logs or Google Search Console to identify redirect chains and collapse them into single hops.

When You Need Redirects: Common Scenarios

Redirects are necessary in specific situations where URLs change. Understanding which situations require redirects and how to implement them prevents ranking loss and visitor confusion. The key principle is that whenever a URL disappears from your site and a visitor might try to access it from an external link, an old bookmark, or a search engine index, you need a redirect. Let us walk through the most common scenarios where you will need redirects and what approach works best in each case.

Changing Individual URLs

Sometimes you need to change individual URLs while keeping most of your site structure the same. Common reasons include fixing typos in slugs, removing stop words, making URLs shorter and cleaner, or reorganizing content into different categories. When you change an individual URL, set up a 301 redirect from the old URL to the new one. This is straightforward and tells Google that the content has moved to a new permanent address. Monitor the old URL in Google Search Console to confirm that Google finds the redirect and eventually stops crawling the old URL. The process usually takes days to weeks depending on how often Google crawls your site.

Be careful not to create soft 404 errors by redirecting multiple unrelated old URLs to your homepage or to a category page. If five old blog posts redirect to your homepage, Google sees this as five URLs pointing to the same destination without a logical relationship. Google may interpret this as a soft 404 situation where you are hiding the fact that the old content no longer exists. Search Engine Land documented a migration where only the top 50 pages had correct one-to-one redirects while thousands of other URLs all pointed to the homepage. Rankings dipped, and recovery took months longer than expected. Redirect each old URL to the most relevant new URL. If the old content no longer exists and you have no replacement, use a 404 error instead of a redirect. A 404 error is honest and tells Google the page is gone.

Moving from HTTP to HTTPS

Migrating from HTTP to HTTPS is one of the safest migrations you can do. Google treats HTTP and HTTPS versions of the same domain as the same site, so there is no need to use the Change of Address tool in Google Search Console. Set up 301 redirects from every HTTP URL to its corresponding HTTPS URL. This is typically done at the server level using a single redirect rule rather than individual redirects for each page. Once your HTTPS version is live and functioning properly, Google will gradually move its index from the HTTP version to the HTTPS version. This process is automatic and you do not need to do anything special beyond setting up the redirects and ensuring your HTTPS pages are properly configured.

Keep the HTTP to HTTPS redirects active permanently. Some webmasters think they can remove these redirects after a few years, but external sites will continue to link to HTTP URLs. Users may have old bookmarks with HTTP. Search engines may still crawl HTTP URLs occasionally. The redirects cost nothing to maintain and protect you from losing traffic. Update your sitemap to include only HTTPS URLs and make sure your robots.txt, internal links, and canonical tags all point to HTTPS. Google recommends using HTTPS, and migrating provides a small ranking signal in addition to better security and browser trust indicators.

Changing Your Domain Name

Changing your entire domain name is more complex than changing individual URLs. This is a significant migration that requires careful planning and execution. Set up 301 redirects from every old domain URL to the corresponding new domain URL. In Google Search Console, use the Change of Address tool to tell Google about the migration. This tool accelerates Google’s transfer of indexing from the old domain to the new domain. The process involves uploading your sitemap for the new domain, verifying ownership of both domains, confirming that redirects are in place, and then requesting that Google make the address change. Google will transfer your site’s search history, rankings, and crawl history to the new domain over time.

A full domain migration is one of the riskiest SEO moves you can make because so many things can go wrong. When TransferWise rebranded to Wise and migrated its domain, it took roughly eight months to recover traffic to pre-migration levels, then surpassed them. That is a well-resourced company with a dedicated technical team, and it still needed the better part of a year. Make sure your redirects are correct for every single page. Monitor the new domain carefully for several months to confirm that traffic transfers properly and that you are not losing rankings. Keep detailed records of the old domain traffic and compare it to the new domain traffic after the migration completes. Large sites with thousands of pages should split the migration into phases rather than moving everything at once. A phased approach allows you to catch problems on a subset of pages before they affect your entire site.

Restructuring Your URL Architecture

Sometimes you decide to completely restructure how your URLs are organized. This might mean moving all blog posts from /blog/article-name/ to /resources/article-name/, or moving product pages from a flat structure to a category-based structure. This is a major restructuring that affects many URLs at once. Set up 301 redirects from every old URL to its corresponding new URL. Map out the structure carefully before you make changes. Create a spreadsheet showing every old URL and where it should redirect to. Test the redirects on a staging environment before deploying them to your live site. Once you are confident the redirects are correct, implement them all at once rather than in stages, as this makes it easier for search engines to understand the change.

Large URL restructures may take longer to fully process by search engines. Google Search Central states that the move takes place on a per-URL basis, meaning Google will discover each redirect individually and process it according to its crawl schedule. For large sites with thousands of pages, this process can take weeks or months. During this time, search results may be inconsistent, showing some old URLs and some new URLs. This is normal and should resolve itself once Google finishes crawling all the redirects. Monitor your coverage in Google Search Console to see how many old URLs have been crawled and indexed. Do not remove the redirects until you are confident that all important URLs have been reindexed at their new locations.

The Complete Site Migration Checklist

A successful migration requires careful planning and execution across multiple phases. A Twitter poll by SEO consultant Natalie Mott, with over 1,300 votes, found that 78% of SEOs expect some traffic loss during a migration. That number is not a death sentence. It reflects the reality that migrations involve moving parts, and even well-planned ones cause short-term fluctuations. The goal is not zero disruption. The goal is minimal, temporary disruption followed by full recovery. This checklist covers the main tasks to get you there.

Before the Migration

Start by taking a complete inventory of your current site. Crawl your site with a tool like Semrush or Ahrefs to see all your URLs, their current rankings, traffic, and backlinks. Export your current traffic data from Google Analytics for at least the last three months so you have a baseline to compare against after the migration. Verify your ownership of your domain in Google Search Console and check your current crawl stats, coverage, and any existing errors. Create a detailed mapping document showing exactly which old URLs redirect to which new URLs. For smaller sites, a spreadsheet works fine. For larger sites, you may need a database or a specialized migration tool. Double-check your redirect mapping for accuracy before you proceed.

Plan your migration timing carefully. Choose a time when traffic is lower, such as late evening or early morning, so fewer people experience issues. Notify your team and any external partners that depend on your API or feeds. Update your sitemap and robots.txt to include the new URLs. Set up monitoring in Google Search Console for both your old URLs and new URLs. Create custom reports in Google Analytics to track migration metrics separately from regular traffic. Review your current canonical tags, internal linking structure, and meta tags to ensure they will be correct on the new URLs. Test everything on a staging server before making changes to your live site. A dry run catches problems without affecting your live traffic.

During the Migration

On the day you execute the migration, have your team ready to monitor for problems. Implement the redirects on your server. Update your internal links to point to new URLs instead of relying on redirects, since internal links are more efficient and should not redirect at all. Update your sitemaps and submit them to Google Search Console. If you are doing a domain migration, verify the new domain in Search Console and use the Change of Address tool. If you are doing a HTTPS migration, update your robots.txt to point to the HTTPS version. Monitor your server logs and error logs for redirect chains, infinite redirects, or unexpected 404 errors. Use a tool like Screaming Frog to verify that your redirects are working correctly. Test critical pages from different locations and devices to confirm users reach the new content.

During the first 24 hours after migration, check your site every few hours to make sure everything is functioning. Monitor your web server’s CPU, memory, and bandwidth to ensure the redirect logic is not causing performance issues. Set up monitoring alerts for crawl errors in Google Search Console. Check Search Console for any new coverage issues that might indicate redirect problems. Test forms, checkouts, and interactive features to make sure they still work with the new URLs. Check that your HTTPS certificate is valid if you are migrating to HTTPS. Verify that your CDN or caching layer is properly configured for the new URLs. The first day is critical because this is when most problems surface and you can still fix them quickly.

After the Migration

Monitor your traffic closely for at least two weeks after the migration. Use your analytics to compare old traffic levels to new traffic levels. Google Analytics may show lower traffic temporarily because of the time it takes for Google to recrawl and reindex your URLs, but it should recover within a few days for most sites. Check Google Search Console daily for the first week and weekly for the next month. Look for increases in crawl errors, coverage issues, or new problems. Verify that your old URLs are returning 301 redirects and not other status codes. Confirm that internal links have been updated so they point to new URLs directly instead of through redirects. Delete any temporary test redirects you created during testing.

As weeks pass after the migration, monitor your rankings for key pages. Some fluctuation is normal as Google adjusts its index. Rankings should stabilize within a few weeks to a few months depending on your site size and update frequency. Search Engine Land documented a case where a site that migrated with SEO built into every step saw a 455% increase in daily traffic and a 78% jump in top-10 rankings within four months of the move. That is the upside of a well-executed migration. Compare your organic traffic to the same period in the previous year, accounting for seasonal trends. Look at your crawl budget in Google Search Console to make sure it is not being wasted on old URLs or redirect chains. After a few months, you can be confident that the migration was successful if traffic has returned to previous levels or improved.

How Long Does a Site Migration Take

The timeline for a complete site migration depends on the size of your site and the extent of the changes. Google Search Central provides general guidance: small and medium sites typically complete their migration within weeks, while larger sites may take longer. This timeline refers to when Google finishes recrawling and reindexing all your pages, not when you push the changes live. You implement the redirect rules on your server in minutes or hours. Google starts discovering and following those redirects within hours to days. The full reindexing process takes much longer. For a small blog with hundreds of pages, Google may finish recrawling everything within two to four weeks. For a large site with tens of thousands of pages, the process may take two to three months or longer.

The timeline is affected by several factors. Sites that are crawled frequently finish migrations faster than sites crawled infrequently. A news site with daily updates is crawled multiple times per day, so Google discovers the redirects quickly. A small business site updated quarterly is crawled less often, so the migration takes longer. Your crawl budget also matters. If you have a large site with crawl budget limitations, Google may deprioritize crawling the old URLs with redirects. The number of inbound links pointing to your old URLs affects timing as well. If many external sites link to your old URLs, Google will keep trying to access those URLs and will notice the redirects. If few external sites link to your old URLs, Google may not discover the redirects as quickly. During the migration period, you will see inconsistent search results with both old and new URLs ranking. This normalizes once the migration completes.

Common Migration Mistakes That Actually Hurt Rankings

Many websites lose rankings during migrations because they make preventable mistakes. The most common mistake is using the wrong type of redirect. Using 302 redirects when 301 is more accurate tells Google the change is temporary and prevents full consolidation of ranking signals. Using JavaScript redirects instead of HTTP redirects is slower and less reliable. The second most common mistake is creating redirect chains. If your old URL redirects to an intermediate URL which redirects to the final URL, you have created unnecessary latency and crawl waste. Always make old URLs redirect directly to their final destinations. Mapping old URLs to the wrong new URLs is another frequent problem. If you redirect five different old URLs to your homepage, you create soft 404 errors. Always map each old URL to the most relevant replacement content.

Removing redirects too quickly is a critical mistake that causes lasting damage. Many webmasters remove redirects after a few months, assuming the migration is complete. External sites continue to link to the old URLs. Users have bookmarks and email links pointing to old URLs. Removing the redirect turns these into 404 errors, losing the visitor and wasting crawl budget. Search Engine Land reported a case where an electronics manufacturer lost nearly 50% of its organic traffic after a botched replatforming and HTTPS migration. The agency brought in to recover the site found broken internal links, missing redirects for high-traffic pages, and inconsistent URL rules. Recovery took months of painstaking redirect mapping and monitoring. Google recommends keeping redirects active for at least one year and many experts recommend permanent activation. Another mistake is not updating internal links. Instead of changing internal links to point to new URLs, some sites create internal redirects. This forces every internal link click to go through a redirect, wasting crawl budget and slowing down your site. All internal links should point directly to new URLs without redirects.

Monitoring Your Migration in Google Search Console

Google Search Console is your primary tool for monitoring a migration. Start by verifying ownership of both your old and new domains if you are doing a domain migration. Create separate properties in Search Console for the old domain and the new domain. In the new domain property, use the Change of Address tool to tell Google about your domain migration. This tool is only available for domain migrations, not for URL structure changes or HTTPS migrations. Upload your new sitemap and monitor the coverage report to see how many URLs Google has successfully indexed. The coverage report shows you exactly which pages have been indexed, which have errors, and which are excluded. This data is invaluable for understanding whether your migration is succeeding. The crawl stats report shows you how many pages Google is crawling and how much crawl budget it is using. After a migration, crawl stats should decrease over time as Google stops crawling the old URLs.

Check the coverage report regularly during the first month after your migration. The number of indexed pages at your new domain should gradually increase as Google recrawls and reindexes your content. The number of indexed pages at your old domain should gradually decrease as Google discovers the redirects and consolidates everything under the new URLs. Look for any errors or excluded pages that might indicate a problem with your redirects or with the new pages themselves. If you see excluded pages on the new domain, investigate whether they have robots.txt directives blocking them or canonical tags pointing elsewhere. Monitor the Enhancement reports if you use structured data, since you will need to ensure structured data is correct on your new URLs. The Security Issues report will alert you to any malware or hacking problems detected during the migration. Any security issues should be resolved immediately before they impact your rankings.

When Redirects Go Wrong: Diagnosing Problems

Despite careful planning, redirects sometimes fail or cause unexpected problems. The first sign is usually a spike in errors in Google Search Console or a sudden drop in organic traffic. Common problems include infinite redirect loops where URL A redirects to URL B which redirects back to URL A. This is a critical error that locks users and search engines in a loop. Check your redirect rules carefully to ensure no circular redirects exist. Another problem is a redirect to a 404 error page. You intend to redirect oldurl.com to newurl.com, but newurl.com does not actually exist or has an error. Google and users get redirected to a broken page. Verify that every redirect destination exists and returns a 200 status code. A soft 404 situation arises when you redirect multiple unrelated URLs to the same destination. For example, if three different old blog posts all redirect to your homepage, Google may interpret the old URLs as soft 404s instead of legitimate redirects.

Redirect chains are another common problem. You redirect oldurl1 to oldurl2 and oldurl2 to oldurl3. The user and search engine must follow two redirects to reach the final destination. Detect redirect chains by crawling your site and checking the redirect path for each URL. Collapse chains by redirecting directly to the final destination. Slow redirects are a more subtle problem that affects user experience and crawl efficiency. If your redirects take longer than 200 milliseconds to complete, users will notice a delay. Slow redirects are usually caused by server-side processing issues or database lookups. Optimize your redirect logic to be as fast as possible. Monitor your server logs for any errors related to redirects. A 5xx server error returned instead of a 3xx redirect status code indicates that something went wrong on your server. Use a tool like curl or your browser’s developer tools to inspect the response headers and confirm you are returning the correct redirect status codes.

How Long Should You Keep Redirects Active

Google Search Central explicitly recommends keeping redirects active for at least one year after a migration. This recommendation applies to all types of migrations, whether you are changing URLs, moving to HTTPS, or switching domains. In 2021, Gary Illyes clarified the mechanics: after a 301 redirect has been in place for about one year, Google permanently consolidates all signals from the original URL to the destination. Even if the redirect is later removed, those signals stay with the new page. Many SEOs extend their redirects to two years or permanent activation to be safe.

In 2023, Ahrefs’ Patrick Stox tested this claim by removing 301 redirects that had been active for over a year. His conclusion: the signals did seem to persist after removal, largely confirming what Gary Illyes described, but the results were not conclusive enough for a definitive recommendation. Stox wrote that this behavior is “radically different from how SEOs thought redirects consolidated,” suggesting the industry’s mental model may need updating. The safest approach remains keeping redirects permanently active. The server resource cost is essentially zero. The benefit is that you never have to worry about removing them too early and losing traffic.

If you are changing hosting providers and want to clean up old redirect rules, make sure the redirects have been in place for at least one year and preferably two years. Check your analytics to confirm that traffic to the old URLs has dropped to near zero before removing redirects. Even after removing redirects, some traffic may come from cached search results or old bookmarks, so be prepared for a small increase in 404 errors for a while. If traffic spikes back up after you remove redirects, reinstate them immediately. The key principle is that your redirects should remain active as long as any traffic is coming from old URLs, which for most sites means indefinitely.

For more guidance on technical SEO fundamentals, start there before tackling a migration. Understanding crawl budget optimization is also essential, as redirect chains and structural changes directly impact how efficiently search engines crawl your site. Make sure your Core Web Vitals remain healthy throughout the migration process, and monitor your site speed closely, since redirect latency compounds with every hop in the chain.