The dip is normal. The slide isn't.
Search engines need time to re-crawl a new site. A drop that keeps deepening after the first few weeks points to something broken, usually redirects.

A new website hurts your SEO only when the launch throws away what the old site earned: the URLs search engines already trust, the content that ranks, and the links pointing at both. Some dip is normal while search engines re-crawl, but an advanced website build planned around URL mapping and permanent redirects keeps it small and short.
Most ranking losses after a launch aren't caused by the new site. They're caused by what nobody carried over from the old one.
Search engines need time to re-crawl a new site. A drop that keeps deepening after the first few weeks points to something broken, usually redirects.
Rankings and links are attached to addresses. Change an address without a permanent redirect and the page starts over.
Google may treat mass redirects to a homepage as soft 404s, which means the old page's value is simply dropped.
Moving content without improving it wastes the launch. Better answers, faster pages and cleaner markup are how a new site ends up ahead of the old one.
If your developer can show you a complete URL map and redirect plan before launch, rebuild with confidence. If nobody can, don't launch yet.
Rankings drop after a launch because search engines are re-learning a site they thought they understood. URLs change, pages disappear, internal links get rearranged and content gets rewritten. Each change resets some of what Google had already worked out, and a few of them, handled badly, delete it outright.
The causes are predictable, which is the good news. Nearly every serious loss I see traces back to one of these:
| What goes wrong | What it does to rankings | How it's prevented |
|---|---|---|
| Old URLs change with no redirect | Ranked pages return errors and their link value is lost | A complete URL map with a permanent redirect for every old address |
| Old pages all redirect to the homepage | Google may treat them as soft 404s and drop them | Redirect each page to its closest equivalent |
| Content gets cut or thinned in the redesign | The page no longer answers the query it ranked for | Inventory ranking pages and keep or improve their content |
| A noindex or crawl block ships from the staging site | The site quietly drops out of search | A pre-launch check of robots rules and meta directives |
| Content only appears after JavaScript runs | Some crawlers, AI crawlers especially, see an empty page | Core content delivered in the initial HTML |
| Internal links still point at old addresses | Crawlers hit redirect chains and lose the trail | Internal links updated to final URLs |
| Analytics and conversion tracking aren't reinstalled | A reporting gap looks like a ranking loss | Tracking verified before launch day |
None of these are design problems. They're migration problems, and they're decided before launch, not after.
Expect a measurable dip, and judge it by its size and how quickly it levels out. Google's guidance on site moves says most pages on a small or medium-sized site can take a few weeks to move to new URLs, and larger sites take longer. A dip that keeps deepening after that window means something in the migration is broken.
There is always a post-migration dip. Over the last two years, we've brought our average dip down, and the steps in the next section are how.
The average comes from the migrations we run, not a promise for yours. Every site carries different history, different links and different problems waiting in the old build.
What I'd worry about is a vendor who tells you there won't be a dip at all. Search engines have to re-crawl, re-index and re-evaluate every page. Anyone promising otherwise either hasn't watched a launch closely or doesn't plan to.
Five things keep rankings intact: a platform that gives you full control of URLs and redirects, a map of every old URL, permanent 301 redirects to each page's closest match, a new site that's genuinely better than the old one, and every submission step done on launch day. Skip one and the dip gets bigger.
Your platform decides how much control you have over URLs, redirects, rendering and markup. We build on Replit, so every route and redirect is part of the build itself rather than a setting someone hopes a plugin respected.
Every URL the old site exposes gets a row: pages, posts, PDFs, and the campaign page someone built years ago that still earns links. Search Console, analytics and a full crawl each surface addresses the others miss, so the map is built from all three.
Each old URL gets a 301 redirect to the new page that answers the same question. Google recommends permanent redirects and keeping them in place for as long as possible, generally at least a year. Redirects should point straight to the final address, with no chains.
A rebuild that only moves content wastes the launch. We improve what moves: answer-first copy, cleaner headings, faster pages and valid structured data. A site that's genuinely better gives search engines a reason to rank it higher, not just to restore it.
On launch day the new XML sitemap goes to Google Search Console and Bing Webmaster Tools, and indexing gets requested for the pages that matter most. The point is getting crawlers onto the new site quickly, so the dip ends sooner.
A URL map is a spreadsheet with one row per old address, showing where it goes, why, and how much it matters. It's the single document that decides whether a launch keeps its rankings, and you should be able to see it before anyone touches the live site.
| Column | What it records |
|---|---|
| Old URL | Every address the current site serves, from every source |
| New URL | The closest matching page on the new site |
| Redirect type | Permanent (301) unless there's a specific reason otherwise |
| Traffic and rankings | What the old page earns today, so priorities are clear |
| Inbound links | Whether other sites link to it, and how many |
| Content action | Keep, improve, merge or retire |
| Post-launch check | Redirect confirmed and new page indexed |
Pages being retired still get a row. If a genuinely equivalent page exists, the old URL redirects there. If nothing on the new site answers the same need, a clean 404 is more honest than a redirect to the homepage.
You can, but every change you stack onto one launch makes the dip harder to read. A new domain, a new platform and a new URL structure all at once means that if rankings fall, you can't tell which change caused it. Change only what the business actually needs changed.
Sometimes the business does need it. We're moving SyncDS onto its own new domain as this is written, and the same rules apply to us: a full URL map, a permanent redirect for every old address, and nothing skipped on the submission side.
For a domain change, the Change of Address tool in Google Search Console tells Google the move is deliberate. It's built for moves between domains or subdomains, not for URL changes inside the same domain.
Yes. A rebuild can keep its Google rankings and still drop out of AI answers, because AI crawlers read sites differently. If the new site blocks AI crawlers, ships a nosnippet directive, or only renders content through JavaScript, assistants like ChatGPT and Perplexity may not be able to read it at all.
Check crawl access and rendering as part of the launch, not after it. If being named in AI answers matters to your business, here's what AEO work actually includes.
Ask to see the plan, not the promise. A developer who has protected rankings before can show you the URL map, the redirect list and the launch checklist before the site goes live. If any of those don't exist yet, the launch date is too early.
If you'd rather have the build and the search work owned by the same team, that's what our audit-first SEO and AEO engagement is built around.
There's no fixed timeline, and nobody can honestly promise one. Google says most pages on a small or medium-sized site can take a few weeks to move to new URLs, and larger sites take longer. A well-run migration levels out within that window; one that keeps sliding usually has a redirect or indexing problem.
Keep them as long as possible. Google recommends at least a year so every signal transfers to the new URLs, and links from other sites keep pointing at the old addresses long after that. Removing redirects early throws away value you already paid to protect.
Less risk, not none. Keeping URLs removes the biggest cause of ranking loss, but rankings still depend on the content, internal links, page speed and rendering the new design delivers. A redesign that cuts copy or hides it behind JavaScript can still lose ground with identical addresses.
No. The build is where most SEO decisions get made: which pages exist, what they're called, how they link together and how fast they load. Pausing search work during a rebuild hands those decisions to people who aren't measuring them. SEO should shape the build from the first scope.
Yes, when it's used as a catch-all. Google says redirecting many old URLs to one irrelevant page, such as the homepage, can confuse users and may be treated as a soft 404, which means the old page's value is dropped. Each old URL should point to its closest equivalent.
You can keep most of them with a permanent redirect for every old URL, Google's Change of Address tool, and new sitemaps submitted on launch day. Expect a dip while Google processes the move. Avoid stacking a domain change on top of a new URL structure unless the business needs both.
Check that every redirect is a single permanent hop, that the new sitemap is submitted and being read, that Search Console shows no spike in errors, and that analytics and conversion tracking are firing. Compare your top pages against the URL map so nothing important slipped through.
It can. AI crawlers need access to the site and content they can read without running JavaScript, and a stray nosnippet directive or blocked crawler can remove pages from AI answers while leaving Google rankings intact. Treat AI crawl access as part of the launch checklist.