The most destructive event in a website’s life is not a Google algorithm update. It is a redesign.
Algorithm updates are survivable and usually partial. A botched migration removes years of accumulated ranking equity in a weekend, and the business typically does not notice for three to six weeks, long enough that the connection to the launch is no longer obvious to anyone in the room.
The failure is nearly always the same one, it is entirely preventable, and it keeps happening because the people who plan migrations and the people who understand the consequence are usually different people who meet too late.
The mechanism
Search engines do not rank websites. They rank URLs.
Every ranking signal your site has earned (external links, internal links, click history, topical relevance, age) is attached to a specific URL string. Not to the page. Not to the content. To the address.
When a redesign changes /services/web-design/ to /what-we-do/web-design/, the new URL is a brand new page from Google’s perspective, with no history and no accumulated equity. Meanwhile the old URL returns a 404, and every external link pointing at it now points at nothing.
The content is identical. The design is better. And the page starts from zero.
Do that across two hundred URLs and you have not launched a new site. You have launched a new domain that happens to share a brand name with something that used to rank.
The fix, which is not complicated
A 301 redirect tells search engines that a URL has permanently moved and instructs them to transfer the accumulated signals to the new address. It is not lossy in any meaningful way when done correctly and promptly.
The work is straightforward:
- Before launch, crawl the entire existing site and export every indexable URL.
- Pull the URL list from Search Console as well: it contains addresses that no longer link from anywhere but still receive traffic and hold external links. Crawling alone will miss these.
- Map every old URL to its closest new equivalent. One to one wherever possible.
- Where no equivalent exists, map to the most relevant parent category. Never map everything to the homepage: Google increasingly treats a mass redirect to the homepage as a soft 404 and passes nothing.
- Implement as 301s, not 302s. A 302 signals a temporary move and does not reliably transfer equity.
- Test every single redirect before launch, on staging, in bulk.
- After launch, monitor Search Console’s coverage report daily for a fortnight.
That is the whole procedure. It is a day or two of careful work on a mid-sized site, and it is the difference between a redesign that preserves the business and one that resets it.
Why competent teams still get it wrong
Knowing the fix and executing it are different problems, and the failure modes are organisational rather than technical.
Nobody owned it. The designer assumed the developer would handle redirects. The developer assumed the marketing team would supply the mapping. The marketing team assumed it was technical. This is the most common version by a wide margin and it produces a launch where redirects simply do not exist.
The old URL list was incomplete. Someone crawled the live site and mapped what they found. But orphan pages, URLs with no internal links pointing at them, do not appear in a crawl, and they frequently hold external links accumulated over years. Search Console’s data catches them. A crawl alone does not.
Redirect chains. The site has migrated before. URL A redirects to B, which now redirects to C. Each hop loses a little and adds latency, and long chains eventually stop being followed. Every migration should flatten previous chains so every old URL points directly at its final destination in one hop.
Query parameters and trailing slashes. /page, /page/, /page?utm_source=x may all be indexed separately. Redirect rules built on exact-match string comparison will miss the variants.
Staging leaked, or staging rules survived. The staging site was indexable and now competes with production for its own content. Or, worse, the noindex directive or robots.txt block used on staging shipped to production. The second one takes an entire site out of the index within days and is more common than anyone admits.
Nobody checked afterwards. The launch went smoothly, everyone moved on, and the coverage report showing four hundred new 404s went unread until a quarterly review.
What it costs
Traffic losses of 40-70% are typical when redirects are missed entirely. Recovery, if the redirects are implemented late, is usually partial and slow. Google will eventually reprocess, but external links that pointed at 404s for months may have been dropped from the linking sites in the meantime, and those are not recoverable at all.
The timing makes the diagnosis harder than it should be. The drop is not immediate. Google takes weeks to recrawl an entire site and reprocess its index, so the decline is gradual over three to six weeks. By the time it is unmistakable, the launch is old news, and businesses routinely attribute the loss to seasonality, an algorithm update, or competitor activity.
The clearest diagnostic is simple: crawl the old URL list against the live site and count how many return 404. If that number is not close to zero, the migration is the cause and nothing else needs investigating.
The other half of the problem
Redirects preserve what you had. They do not address a second category of migration damage, which is that the new site is often technically worse than the old one in ways nobody checked.
Common regressions:
Rendering strategy changed. The old site served HTML. The new one builds content in client-side JavaScript. Google can render JavaScript, but it does so on a delayed second pass, and complex client-side applications frequently render incompletely for crawlers. Content that was previously trivially indexable now may not be.
Page titles became templated. The new CMS generates titles from a pattern, and two hundred pages now share near-identical titles. Every one of them competes with the others.
Performance regressed. A visually richer design with heavier images and more third-party scripts. Google’s own case data shows what this costs in both directions: Vodafone Italy gained 8% more sales from a 31% LCP improvement, Redbus recorded an 80-100% increase in mobile conversion rate after cutting CLS from 1.65 to zero and halving Time to Interactive. Those gains run in reverse when a redesign makes things slower.
Structured data was dropped. Schema markup that generated rich results in the SERP did not survive the rebuild, and the listings lose their star ratings, prices and FAQ expansions.
Internal linking flattened. The old site had contextual links inside body copy. The new design is cleaner, with fewer in-content links, and authority stops flowing to deep pages.
A pre-launch checklist should compare the new site against the old on all six, not just on redirects.
If it already happened: the recovery sequence
Most people reading this are not planning a migration. They are three weeks past one and trying to work out what went wrong. The recovery is real but time-sensitive, and the order matters.
Confirm the diagnosis first. Crawl the old URL list against the live site and count 404s. If that number is not close to zero, stop investigating anything else. This is the cause and everything else is a distraction.
Reconstruct the old URL list, even if nobody kept one. Three sources: Search Console’s Performance report going back sixteen months, the Wayback Machine’s index for the domain, and any surviving analytics export listing landing pages. Between them you can usually recover the great majority of URLs that mattered.
Prioritise by inbound links and past traffic, not alphabetically. A handful of URLs will account for most of the lost equity. Redirect those first and the bulk of the recovery arrives before the long tail is finished.
Implement, then request indexing on the highest-value destinations. Search Console’s URL Inspection tool has a “Request Indexing” button. It does not guarantee anything, but on a small number of critical pages it accelerates reprocessing meaningfully.
Expect partial recovery, and know why. Google will reprocess the redirects and pass most of the accumulated signals. What does not come back is external links that pointed at 404s for long enough that the linking site removed or replaced them. That loss is permanent, and it is the reason speed matters. Recovery is more complete the sooner the redirects go in.
Then look at the second-order damage. Redirects restore what the old URLs earned. They do not fix a new site that renders client-side, ships templated titles, or dropped its structured data. Work the six-point comparison below before declaring the incident closed.
Getting it right
The single highest-leverage change is timing: involve whoever understands search before the URL structure is decided, not after launch when the traffic has gone.
This costs almost nothing at the right moment. Reviewing a proposed sitemap and URL scheme is an hour of work. Reconstructing ranking equity destroyed by a migration is months, and is never fully successful.
The businesses that handle this well tend to do one of two things. Either they bring in an seo services nepal provider, or the equivalent in their market, at the architecture stage specifically to review the URL plan and rendering strategy. Or they hire a development studio that treats search architecture as part of the build rather than as somebody else’s problem afterwards.
The second is preferable when available. A team doing web development in pokhara, or anywhere, that maintains a redirect map as a build deliverable rather than a launch-week scramble has removed the failure mode structurally. When it is a checklist item owned by the build team, it does not fall between two roles.
The pre-launch checklist
Do not launch until every one of these is true:
- [ ] Full crawl of the existing site exported, with every indexable URL
- [ ] Search Console URL list exported and merged in, to catch orphans
- [ ] Every old URL mapped one-to-one, or to a genuinely relevant parent
- [ ] Redirects implemented as 301, tested in bulk on staging
- [ ] Previous redirect chains flattened to single hops
- [ ] Trailing slash and query parameter variants covered by the rules
- [ ] Staging no-index and robots.txt blocks confirmed removed from production
- [ ] XML sitemap regenerated with the new URLs only
- [ ] Page titles and meta descriptions verified unique across the new site
- [ ] Structured data present on the templates that had it before
- [ ] Core Web Vitals measured on the new build against the old one
- [ ] Search Console coverage report checked daily for two weeks post-launch
Twelve items. Most of the day. The alternative is a rebuild that costs more than the redesign did and takes a year to recover from.