# 5 Website Redesign Mistakes That Wipe Out Search Traffic, and What to Check Before, During and After Launch > Redesigned your site and watched search traffic vanish? The usual culprits are leftover noindex rules, missing redirects, old URLs left behind, broken tracking, and changing everything at once. Here's how to avoid all five. | Field | Value | |-------|-------| | Published | 2026-10-13 | | Category | Beginner | | Author | Aro Ogata | | Tags | beginner, SEO basics, website redesign, site migration, noindex, robots.txt, 301 redirect | | URL | https://linksurge.jp/blog/en/site-renewal-seo-mistakes/ | --- ## Key Takeaways: Redesign Disasters Come Down to Five Mistakes A redesign (rebuilding your site's look, structure or platform) goes live, and organic traffic drops off a cliff. Looking back at the cases I've been asked about, nearly every one traces to one of five mistakes. Here they are, backed by Google's own documentation. 1. **Leaving staging noindex or robots.txt blocks in place** — The "don't show this in search" (noindex) and "don't crawl this" (robots.txt) settings used during development go live with the new site, so your pages can't appear in search properly. Google lists this first among common site-move mistakes 2. **Missing redirects from old URLs** — If URLs change and there's no 301 redirect, the old URLs return "not found" and drop out of results. Redirecting everything to the homepage doesn't count either 3. **Old URLs left inside the new site** — Navigation links, canonical tags (the "this is the main version" label) and sitemaps still pointing at old URLs send Google mixed signals 4. **Tracking tags that don't make the trip** — If your analytics tag or Search Console verification tag isn't carried over, you can't compare before and after, so you can't tell what happened 5. **Changing design, URLs and content all at once** — Google recommends making one major change at a time. Change everything together and you can't isolate the cause when traffic falls Let's start with why redesigns hurt search traffic at all, then take the five mistakes one by one. --- ## 1. Why Does a Redesign Wipe Out Search Traffic? Here's the thing: to Google, a redesign looks a lot like a move. Google finds pages (crawling), stores them in its database (indexing), and orders them for each search (ranking). "[How Search Engines Work](/blog/en/how-search-engines-work/)" walks through all three stages. When URLs or content change, Google has to revisit and re-store the new pages. ### Temporary fluctuation vs. an actual breakage Google's "Site moves with URL changes" guide says to expect temporary ranking fluctuation during a move. Even for medium-sized sites, it can take a few weeks or more for Google to gradually start showing the new URLs. So some movement right after launch is normal. The real problem is when a configuration mistake means Google can't read the new pages, or can read them but isn't allowed to show them. That kind of drop doesn't fix itself. | What you're seeing | What's going on | Will it recover on its own? | |:--|:--|:--| | Temporary fluctuation | Google is working through the new URLs | Usually settles within a few weeks | | A breakage | Leftover noindex, missing redirects and so on keep pages out of search | Not until you fix it | All five mistakes below are breakages. The good news: every one of them can be caught with a few checks before and right after launch. > References: > [Site moves with URL changes - Google Search Central](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) --- ## 2. Mistake 1: Leaving Staging noindex or robots.txt Blocks in Place This one does the most damage, and it's far from rare. Sites under construction usually carry settings that keep unfinished pages out of search: - **noindex** — An instruction on the page that says "don't show this in search results" - **A robots.txt block** — A file on your site that tells crawlers (Google's bots) not to visit certain areas. `Disallow: /` blocks the whole site - **Your CMS's "discourage search engines" setting** — WordPress, for example, has a checkbox that works like a site-wide noindex Launch with any of these still on and the new site won't show up in search properly. A leftover noindex drops pages from results. Pages blocked by robots.txt can't be read, so Google can't show them with their actual content (a blocked URL can still appear on its own if other pages link to it). ### Google puts this at the top of its list In the troubleshooting section of its site-move guide, Google lists noindex and robots.txt blocks first among common mistakes. Its advice is blunt: "Don't forget to remove any noindex or robots.txt blocks that were only needed for the migration." What I find practical about the guide is how it handles this upfront. During preparation, it suggests keeping a list of every URL where you added noindex, so you can remove them all when the move starts. Without that list, it's easy to clear the homepage and miss one template. ### The opposite problem: your staging site gets indexed Sometimes it goes the other way: a staging site with no protection shows up in Google. Google's hosting-change guide recommends adding noindex to test versions so they stay out of results. Add it on staging, remove it the moment you go live. Honestly, I'd make that the first line of any launch runbook. For how noindex and robots.txt work and how to check them, see "[Why Isn't My Page on Google?](/blog/en/page-not-indexed-checklist/)" > References: > [Site moves with URL changes - Google Search Central](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) > [Changing your web hosting (site moves without URL changes) - Google Search Central](https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes) > [Block Search indexing with noindex - Google Search Central](https://developers.google.com/search/docs/crawling-indexing/block-indexing) --- ## 3. Mistake 2: Missing Redirects From Old URLs Redesigns often change URL structure too. `/blog/123` becomes `/guides/moving-costs`, that kind of thing. If URLs change and there's no redirect from the old address to the new one, the old URL returns a 404 ("not found"). Google says previously indexed URLs that return 4xx errors are gradually dropped from the index. The old URLs vanish from results while the new ones haven't been picked up yet. That gap is where the traffic goes. ### Where redirects usually get missed Even careful teams miss a few spots: - **Older, low-traffic posts** — The redirect map only covers the pages people remember - **Images and PDFs** — Google's guide says to include images and other files in the move, since they may get image search traffic and inbound links - **Parameter URLs and category pages** — URLs your CMS generates automatically often don't show up in page lists ### "Everything to the homepage" isn't a redirect strategy Building a URL map feels tedious, so everything gets pointed at the homepage. Google explicitly says to avoid redirecting many old URLs to one irrelevant destination, such as the new homepage. It confuses visitors and may be treated as a soft 404, meaning Google sees it as "not found" anyway. If there's no matching new page, don't force a redirect. Let the old URL return a 404 (or a 410, "gone for good"). Google's site-move guide says removed or merged content should return 404 or 410. If you merged several pages into one, though, redirecting them to the merged page is fine. For what a 301 is and how it differs from a 302, see "[What Is a 301 Redirect?](/blog/en/301-redirect-beginners-guide/)" > References: > [Site moves with URL changes - Google Search Central](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) > [How HTTP status codes, and network and DNS errors affect Google Search - Google Search Central](https://developers.google.com/search/docs/crawling-indexing/http-network-errors) --- ## 4. Mistake 3: Old URLs Left Inside the New Site Redirects in place? You're not done. The thing people overlook is the old addresses still sitting inside the new site. Google's site-move guide says to update these to the new URLs: | Item | What it is | If it still points to old URLs | |:--|:--|:--| | Internal links | Navigation, breadcrumbs, links inside articles | Every click goes through a redirect, which is slower | | Canonical tags | The "this is the main version" label | New pages announce that the old URL is the main version | | Sitemap | The file that lists your pages for Google | Google keeps getting pointed at old URLs | | hreflang | The tags linking language versions of a page | Language pairings break on multilingual sites | ### Canonical mistakes hide in plain sight Canonicals are the sneakiest. They never appear on the visible page, so nobody notices after launch. When I review a freshly redesigned site, the canonical tag in the page source is one of the first things I check. Google recommends that each new page's canonical point to its own new URL. If you reused templates, make sure an old domain or a hard-coded URL didn't come along for the ride. Spot-check your key pages at minimum. ### "The redirects work, so internal links can stay" — not quite Some teams figure redirects will cover old internal links. Google's guide notes that redirects slow things down and says to update internal links to the new URLs. For internal linking in depth, see "[Topic Clusters & Internal Linking Strategy](/blog/en/topic-cluster-internal-linking-strategy/)." For sitemaps, see "[XML Sitemap Strategy 2026](/blog/en/xml-sitemap-strategy-2026/)." > References: > [Site moves with URL changes - Google Search Central](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) --- ## 5. Mistake 4: Tracking Tags That Don't Make the Trip The fourth mistake doesn't block search traffic directly. It blinds you. That can be just as costly. ### Which tags tend to go missing? When a new template is built, tags that lived in the old template's `` sometimes don't get copied over: - **Analytics tags** — Google Analytics or similar. Lose it and post-launch traffic looks like zero - **Search Console verification** — The meta tag or HTML file that proves you own the site - **Ad and conversion tags** — The code that counts sign-ups, leads or purchases Google's site-move guide says that if you verify Search Console with an HTML file, meta tag or Google Analytics, you should make sure verification carries over to the new site. Its preparation checklist also includes using web analytics to analyze usage on both the old and new sites. ### Why broken tracking hurts You lose the ability to tell "traffic dropped" from "measurement stopped." I've seen a team scramble over a traffic crash that turned out to be one deleted line of tracking code. The check takes a minute. On launch day, open your analytics real-time view and confirm your own visit shows up. Google's guide also notes that real-time analytics reports are useful in the early stages of a move. For reading Search Console's numbers, see "[Your First Hour in Google Search Console](/blog/en/search-console-first-hour/)." > References: > [Site moves with URL changes - Google Search Central](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) --- ## 6. Mistake 5: Changing Design, URLs and Content All at Once The last one is a planning mistake, not a settings mistake. New design, new URL structure, rewritten content, maybe a new domain while you're at it. It feels efficient. But Google's site-move guide says to change only one thing at a time, and gives the example of not combining a CMS change with a domain move. ### Change everything and you can't find the cause If traffic drops after a big-bang launch, there are too many suspects: - The new URLs? - Content you cut? - New titles and headings? - Or just normal fluctuation during the move? Search Console's Change of Address help makes a similar point. If you combine a move with a redesign of content and URL structure, Google may need to re-learn the site, and traffic is likely to drop. ### If you cut content, cut it on purpose Redesigns are a tempting time to prune old pages. Pruning isn't bad in itself, but it's common to delete a page that was quietly pulling in search traffic. Check each page's impressions and clicks in Search Console before it goes. Split the big jobs up. It's unglamorous, and it's the safest plan there is. > References: > [Site moves with URL changes - Google Search Central](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) > [Change of Address tool - Search Console Help](https://support.google.com/webmasters/answer/9370220?hl=en) --- ## 7. Common Misconceptions and Mistakes Beyond the five mistakes, here are a few beliefs I hear around every redesign. ### Misconception 1: "A fresh design will boost our rankings" Google's site-move guide doesn't say a new look improves rankings. It says to expect temporary fluctuation. Redesign for your readers' experience, not as a ranking tactic. ### Misconception 2: "If traffic drops, roll back immediately" Early ups and downs may just be the normal settling period. Rolling back can look to Google like yet another move and drag things out. First rule out the five breakages above. If none apply, give it a few weeks. ### Mistake: Finding the noindex a month after launch The team checked the homepage on launch day, but the article template still had noindex. Check one page per template type (articles, categories, product pages), not just the homepage. > References: > [Site moves with URL changes - Google Search Central](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) --- ## 8. What to Check Before, During and After Launch Here's everything above, in order. If you're also changing domains, the full step-by-step lives in the next article, "[A Domain Migration and URL Change Checklist](/blog/en/domain-migration-checklist/)." ### Before launch 1. List every old URL and map it to a new URL (include images and PDFs) 2. Record where staging noindex and robots.txt blocks are applied 3. Confirm the new templates include your analytics and Search Console verification tags 4. Record rankings for your key keywords and traffic by page ### Launch day 1. Remove the noindex and robots.txt blocks 2. Open a handful of old URLs and confirm they 301 to the right new URLs 3. Run one page per template through Search Console's URL Inspection tool and confirm it can be indexed 4. Confirm your own visit appears in analytics real-time 5. Submit the new sitemap in Search Console ### The weeks after 1. Watch the Page indexing report for unfamiliar errors 2. Watch impressions and clicks on new URLs climb 3. Compare key keyword rankings against your pre-launch baseline > References: > [Site moves with URL changes - Google Search Central](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) > [Page indexing report - Search Console Help](https://support.google.com/webmasters/answer/7440203?hl=en) --- ## 9. How to Check Your Own Site Search Console's URL Inspection tool and a browser cover most launch-day checks. To audit page-level settings in one pass, [LinkSurge](https://linksurge.jp/)'s [AI Ready check](https://linksurge.jp/ai-ready) reviews items like robots.txt and canonical settings for any URL you enter, which helps catch a template you missed. Just as important is a baseline. Without pre-launch rankings, you can't tell normal movement from redesign damage. [LinkSurge](https://linksurge.jp/)'s [rank tracker](https://linksurge.jp/seo-hub/ranking-dashboard) records rankings for your keywords automatically every day, so starting a few weeks before launch gives you something to compare against. Knowing which pages rank for which keywords also tells you which redirects matter most. [LinkSurge](https://linksurge.jp/)'s [ranked keywords analysis](https://linksurge.jp/ranked-keywords) lists the keywords and pages your domain currently ranks for. --- {{linksurge-card}} ## Quick Check ### Q1: Traffic fell after a redesign. What's the classic "won't fix itself" breakage to check first? Answer: A leftover staging noindex or robots.txt block. Google lists it first among common site-move mistakes. ### Q2: Is it OK to redirect every old URL to the new homepage? Answer: No. Google says redirecting many URLs to one irrelevant page confuses users and may be treated as a soft 404. ### Q3: Why shouldn't you change the design and the domain at the same time? Answer: If traffic drops, you won't be able to isolate the cause. Google recommends making one major change at a time. --- ## Frequently Asked Questions ### How long does it take for rankings to recover after a redesign? Google says rankings fluctuate temporarily during a move, and even medium-sized sites can take a few weeks or more before new URLs show up. Without configuration mistakes, things typically settle over time. Leftover noindex rules or missing redirects won't recover until fixed. ### Do I need to worry if the redesign doesn't change any URLs? Yes. Leftover noindex or robots.txt blocks, missing tracking tags and wrong canonicals can all happen without URL changes. If you're only switching servers or hosts, follow Google's "Changing your web hosting" guide. ### What should I do with pages I'm deleting? If a new page covers the same content, 301 redirect to it. If not, return a 404 or 410. Google treats 404 and 410 essentially the same way. Avoid bulk-redirecting deleted pages to unrelated pages or the homepage. ### What's the bare minimum to do before a redesign? Build a map of old URLs to new URLs, and record key keyword rankings and traffic by page. The map prevents missing redirects. The records give you a baseline for judging what happened after launch. --- ## Conclusion: Put "Remove, Redirect, Rewrite, Measure" in Your Launch Runbook None of these mistakes are technically hard. Most are prevented by checking four things at launch: remove staging blocks, redirect old URLs, rewrite internal references, and confirm measurement works. Write it down in a launch runbook so the checks survive staff changes. After launch, expect a few weeks of movement and compare Search Console against your ranking baseline. Not tinkering with settings every day is part of the fix. This is the first article in round three of the beginner series, "Common Mistakes and What to Do When Things Go Wrong." The previous article is "[5 SEO Basics That Haven't Changed in the AI Era](/blog/en/seo-basics-unchanged-ai-era/)," and next up is "[A Domain Migration and URL Change Checklist](/blog/en/domain-migration-checklist/)." The full reading order lives in "[SEO, GEO and AIO for Beginners: A Reading Order From Zero](/blog/en/seo-beginner-curriculum/)," and the "[SEO Glossary for Beginners](/blog/en/seo-glossary-beginners/)" is there when a term trips you up. LinkSurge's [rank tracker](https://linksurge.jp/seo-hub/ranking-dashboard) records your key keyword rankings daily, so you can compare before and after a redesign.