SEO

Website redesign without losing search traffic: URLs, redirects and testing

How to redesign a website without losing search traffic: record a baseline, build a redirect map, keep the test site out of Google, and check the right reports after launch.

ESTASOFT
9 min read
An old page and a new page joined by a 301 redirect
On this page
    On this page

      This guide is for owners and managers who plan a new website design, a new platform or a new domain and want to keep the visitors they already get from Google. You will learn what to record before the project starts, how to plan redirects, how to keep a test site out of search, and what to check after launch. We read Google's documentation for this guide on 30 October 2026.

      Nobody can promise that search traffic stays the same after a redesign. Google itself says to expect ranking changes while it recrawls a moved site. The steps below remove the avoidable losses.

      Why redesigns lose search traffic

      Most losses come from a short list of mistakes. Google's site move guide names them: temporary noindex tags or robots.txt blocks left on the live site, wrong redirects (including pages that return "not found"), sitemaps that still list old URLs, and servers that cannot handle the extra crawling.

      The same guide gives three rules that apply to any redesign:

      • Change one thing at a time. Its example is to move to a new domain first and change the layout afterward, not both together.
      • Pick a quiet period for the launch.
      • Expect a wait. Google says a small or medium site can take a few weeks for most pages to move, and a larger site takes longer.

      Also decide which kind of change you are making. If you only change the design or the host and every URL stays the same, Google has a shorter guide for hosting moves. If any URL changes, because of a new domain, a new platform or a new page structure, you need redirects. Google says permanent redirects such as 301 do not cause a loss in PageRank, which is the reason to use them.

      Step 1: record your baseline

      You cannot prove a redesign worked without numbers from before it. Save these before anything changes.

      • Every URL on the old site. Google suggests building the list from your sitemaps, the "Links to your site" feature in Search Console, server logs, analytics and your content system. Include images, videos, JavaScript and CSS files, not only pages.
      • Search performance. Export the top pages and top queries from the Search Console Performance report. Google's export help page says exported data is truncated to 1,000 rows, so export in several cuts, for example by page group. Google's Analytics help says Search Console keeps data for the last 16 months, so save it now.
      • Page details. For each important URL, record the title, meta description, canonical URL, status code and the pages it links to.
      • Who links to you. Keep a list of the sites that link to your old URLs. You will ask the important ones to update their links.
      • Speed. Note your current scores against the Core Web Vitals thresholds: Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less.

      Step 2: build the redirect map

      A redirect map is a spreadsheet with one row per old URL. Use these columns: old URL, new URL, redirect type, reason and checked date. Google's guidance gives the rules for filling it in.

      • Match each old URL to its closest new page. Do not send many old URLs to one unrelated destination such as the home page. Google says that this might be treated as a soft 404 error.
      • Use server-side permanent redirects. A 301 or 308 status code is a permanent redirect. A 302, 303 or 307 is temporary, so Google can keep showing the old URL instead of the new one. Google says to use a JavaScript redirect only if server-side or meta refresh redirects are not possible, because Google might never see it if rendering fails.
      • Point straight to the final page. Googlebot generally follows up to 10 redirect hops. Google advises keeping chains ideally to no more than 3 and fewer than 5. Old chains from earlier migrations are common, so test them.
      • Return 404 or 410 for pages you delete. The site move guide names both codes for deleted content, and Google treats the two the same. If a page has moved, use a redirect instead.
      • Keep the redirects long enough. Google says to keep them generally for at least one year, and longer if you can.

      On the new site, give each page a canonical tag that points to itself, update any hreflang tags, and change internal links so they point to the new URLs directly instead of passing through a redirect. If your site has Arabic and English versions, read our guide to hreflang for Arabic and English sites first. If the move is to Shopify, our checklist for migrating to Shopify covers the platform side.

      Step 3: keep the test site out of search

      A staging site that gets indexed creates duplicate pages. A staging site that carries its blocks onto the live site removes you from search. Handle both with care.

      • Protect the test site with a password or by restricting access to known IP addresses. Google's hosting guide suggests IP-restricted access for the test copy, plus a noindex rule in the HTML or in the HTTP headers.
      • Do not rely on robots.txt to keep pages out. Google says robots.txt is not a way to keep a page out of Google. A blocked page can still appear in results, without a description, if other sites link to it.
      • If robots.txt blocks a page, Googlebot cannot crawl it, so it never sees the noindex rule on it.
      • Do not count on a quick cleanup. Google says it may take months for Googlebot to revisit a page and see a noindex rule.
      • At launch, remove the temporary blocks. Check three places: the robots meta tag in the page source, the X-Robots-Tag HTTP header, and your robots.txt file.

      Step 4: a launch-day plan

      1. Freeze content edits on the old site so your redirect map stays correct.
      2. Switch on the redirects. Test every page template and your top pages with a crawler, or with the URL Inspection tool's live test for single pages.
      3. Remove noindex tags, password protection and robots.txt blocks from the live site. If you have no robots.txt file, make sure the address returns a 404 status code.
      4. Check that canonical tags point to the new URLs and that internal links do not pass through redirects.
      5. Submit the new sitemap in the Search Console Sitemaps report and remove the old one. List only canonical URLs. One sitemap file can hold up to 50 MB uncompressed or 50,000 URLs. Only fill in the last-modified date if it is accurate.
      6. If you move to a new domain or subdomain, set up the Change of Address tool in Search Console after the redirects are live. Do this for every verified variant of the old domain. You must be an owner of both properties.
      7. If you only change hosting and keep every URL, lower the DNS TTL to a few hours at least one week before the move. Keep the old host running until your server logs show no more traffic to it.
      8. Record the launch time, so you can compare data before and after.

      Step 5: check the results

      Google gives no fixed schedule, so use a routine. We suggest checking daily in the first week, weekly for the next month, and monthly after that. Compare each result with your baseline until it is stable.

      • Page indexing report. Old URLs that redirect appear as "Page with redirect", which is normal for pages you redirected on purpose. Watch "Not found (404)", "URL marked 'noindex'", "URL blocked by robots.txt" and "Soft 404". The 404 view lists only URLs that returned a 404 in the past month. After you fix an issue, validation typically takes up to about two weeks, but can take much longer.
      • Sitemaps report. The indexed count for your new sitemap should grow while the old one falls.
      • Performance report. Clicks and impressions should move from old URLs to new ones.
      • Server logs. Look for Googlebot visits and unexpected errors. Google says 5xx server errors slow down its crawling, and URLs that keep returning them are removed from the index.
      • Redirects. Re-test them after each site update, because updates can change or remove them.

      Our SEO audit checklist for a company website is a good tool for the review after the first month.

      Mistakes to avoid

      • Redirecting every old URL to the home page.
      • Changing the domain, the platform and the design in one release.
      • Blocking the test site with robots.txt alone.
      • Launching with a noindex tag still in the page template.
      • Switching off the old server or removing redirects after a few weeks.
      • Starting the project without saving the old URL list and the Search Console data.

      Questions owners ask

      Will a redesign hurt my rankings?

      It can, and Google says to expect fluctuations while it recrawls and reindexes. A careful redirect map, a clean launch and the checks above reduce avoidable losses. We cannot promise any ranking or traffic result.

      Do I need the Change of Address tool?

      Only when you move from one domain or subdomain to another. Google says it is not needed for a move from HTTP to HTTPS, a switch between www and non-www, or path changes. Set up redirects first, then use the tool.

      How long should I keep my redirects?

      Google's site move guide says generally at least one year. The Change of Address help page says to keep them for at least 180 days, and longer if Google Search still sends traffic to them. Keeping them longer costs little.

      Need a hand?

      If you plan a redesign, our web development page lists redesigns among the work we do, and our SEO and growth page lists technical audits that cover redirects and errors. You can also send a short brief on the contact page, and we will reply with next steps.

      Sources

      Written by
      ESTASOFT

      Need help with a project?

      Share a short brief. We reply with next steps.

      Book a call

      30 minutes. Free.

      Tell us about your project and we will suggest a time.

      Or email us at info@estasoft.com