Site Migration Without Losing Traffic: Rebuild the Site, Keep the Rankings

Most traffic losses after a redesign are not caused by the new design. They are caused by URLs that changed without anyone writing down what they changed to. A site that ranked for two hundred queries goes live with a new structure, the old addresses 404 or redirect to the homepage, and six weeks later someone asks why enquiries dried up. The work that prevents this is dull and has to happen before launch.

Work out which kind of migration you are actually doing

Risk is set by how many things change at once, so name them first. A refresh on identical URLs is close to zero risk. A restructure that changes URLs is where traffic is normally lost, and a domain change on top of that is the hard case.

• Platform change, same URLs. Verify rendering, status codes and the sitemap; the addresses protect you.
• URL restructure. A full redirect map is mandatory. This is the common failure case.
• Domain change. All of the above, plus a change of address notification and a longer monitoring window.
• All three at once. Split it into two releases if the calendar allows. Bundling saves days and costs you the ability to tell which change caused the drop.

Start from a crawl of the site you already have

Before anything is rebuilt, export every URL that currently exists and attach two numbers to each: sessions over the last twelve months, and impressions from Search Console. That list is the asset you are protecting. It will contain pages nobody remembers, and some of them bring the search traffic. Add the pages other sites link to, because a backlink is only worth keeping if the address it points at still resolves.

• Full URL list from a crawler, plus the XML sitemap and Search Console's page report.
• Twelve months of sessions and impressions per URL, so seasonal pages are not judged on a quiet month.
• External links, so a page with one good backlink is not quietly deleted.
• Any URL printed on material, vehicle livery, ads or a QR code, because those cannot be updated later.

Twelve months matters more in Nepal than the usual advice admits: a page earning nothing in Baisakh can carry the quarter through Dashain and Tihar. Sort by twelve-month impressions, not last month's sessions.

The redirect map is a spreadsheet, not a rule

Pattern-based redirects handle the tidy cases and quietly break the rest. Write the map as an explicit old-to-new list, one row per URL that matters, and let a pattern cover only the long tail you have actually inspected. Every redirect should be a 301 to the closest equivalent page. Sending everything to the homepage is treated as a soft 404, and it loses exactly the ranking you were trying to keep.

The slow rows are the ones with no equivalent, because the redesign dropped a service or merged three thin pages into one. Send those to the nearest genuinely relevant page, not a category index that mentions the topic in passing. If nothing relevant exists, a 410 is more honest than a redirect nobody will honour. Keep the map in the repository, with a column saying why each row exists.

If you cannot name the new page an old URL should land on, that is a content decision you have not made yet, not a redirect problem.

Content parity matters more than most teams expect

A correct redirect to a page that lost half its content still loses rankings. Redesigns compress text because long copy looks awkward in a new layout, and the cut paragraphs often carry the terms the page ranked for. Compare old and new versions of your top thirty pages and check the substance survived, not only the headline.

• Title and H1 still contain the terms the page ranks for, checked against Search Console queries rather than guessed.
• Body content is not materially shorter unless you decided it should be.
• Internal links from body copy survived; many live inside text that gets rewritten.
• Structured data, canonicals and hreflang carried into the new templates.

One parity check catches modern rebuilds: content rendered only after a client-side fetch may be indexed late or not at all, so render main content on the server if the new stack is JavaScript-heavy. Our note on choosing between Next.js and WordPress covers that trade-off.

Test on staging with a crawler before the design is signed off

Run the old URL list against staging with redirects in place and check every status code. You are looking for chains, loops and anything returning 404 or 500. Then make sure the staging robots.txt cannot ship to production carrying a blanket disallow, which is the most common self-inflicted wound in this process.

# Every old URL should reach a 200 in exactly one hop.
while read -r url; do
  printf '%s ' "$url"
  curl -sIL -o /dev/null -w '%{http_code} hops=%{num_redirects}\n' "$url"
done < old-urls.txt | grep -v ' 200 hops=1' > redirect-problems.txt

• Every old URL returns 301 straight to a live 200, no chains, no loops.
• Canonicals, internal links, sitemap and navigation use the new URLs, not redirected ones.
• Staging robots rules and noindex tags are removed at launch, and verified again after.
• HTTPS, the www choice and trailing slashes resolve to one canonical form, not four.

This is the moment for a full technical pass, not only a redirect check. The technical SEO audit checklist is what we work through on staging, and it is far cheaper before launch than as an emergency in week three.

Launch day is a sequence, not a moment

Write the order of operations down and give each step an owner, because failures on the day are almost always sequencing failures. Deploy with redirects already active, then verify in order: robots.txt, a sample of high-value redirects, the sitemap, the analytics tag, and one real form submission.

• Reduce DNS TTL 24 to 48 hours before, restore it a week after, so a rollback is fast.
• Deploy in your lowest-traffic window, which for most Nepali business sites is early Saturday.
• Never launch on the Friday before a holiday. Something will need fixing and nobody will be at a desk.
• Submit the new sitemap the same day and leave the old one reachable for a few weeks, so redirects are discovered faster.
• Send a test enquiry from a phone on mobile data and confirm the email arrives.

Watch the fortnight after launch, and know what normal looks like

Rankings wobble for two weeks even on a clean migration, so decide in advance what counts as normal. A ten to twenty per cent dip in impressions that recovers within a fortnight is ordinary. A drop that keeps deepening after day ten, or one confined to a single template, is a fault to diagnose. Check coverage daily for a spike in 404s, watch impressions rather than positions in week one, and keep server logs so you can see what the crawler requests.

Full recovery on a URL restructure typically takes four to eight weeks, a domain change longer. Judging at day five produces panic decisions, and the usual one is to change more things, which makes the next diagnosis impossible.

If the domain is changing as well

Move the domain on its own where you can, with paths and content unchanged, then restructure later. Keep the old domain registered and serving redirects for at least a year, since letting it lapse hands your backlinks to whoever buys it next. Use the change of address tool, verify both properties, update the business profile and directory listings, and expect recovery measured in months.

What to do if traffic does drop

Work outward from the mechanical causes. In every migration we have been called in to rescue, the cause was somewhere in this list.

• A stray noindex or Disallow: / carried over from staging. Check this first, always.
• Redirect chains, or a pattern rule sending a whole section to the homepage.
• A canonical tag on every page pointing at the homepage: a template bug that looks fine in a browser.
• Content shortened, or moved behind script, during the redesign.
• A slower site from heavy hero images and new third-party scripts. Compare against the old Core Web Vitals numbers rather than assuming the new build is faster because it is newer.
• Nothing you did, because the drop is seasonal or an update landed the same week. Check whether comparable sites moved before rewriting anything.

Keep the old map for a year

Redirects are not temporary scaffolding. Leave them in place for at least twelve months, longer if the old URLs are printed anywhere, and keep the spreadsheet in the repository so the next team can see why a rule exists. The cost of an old redirect is a line in a config file. The cost of removing it early is traffic you already paid for once. Redirect work is part of how we scope every rebuild under web development, and the measurement afterwards sits with our SEO work.