A redesign is one of the most common ways an Indian business loses search traffic overnight. The site looks sharper, the launch feels like a win, and then enquiries quietly fall away for weeks. A website redesign checklist exists to prevent exactly that, and most of the work happens before a single new page goes live. Treat it as part of the scope of your rebuild project, not as a task for launch week.

What follows is the sequence our team uses on rebuilds where the old site already earns organic traffic. If your current site gets almost nothing from Google, your risk is lower and your priorities change. Read the redirect and analytics sections either way. Those two mistakes cost the most and take the longest to reverse.

Why do websites lose rankings after a redesign?

Because the new site breaks connections Google already trusts. URLs change without redirects, page titles get rewritten by a designer, long-form copy gets cut for a cleaner look, and internal links disappear. Google recrawls, finds what looks like a different site, and re-evaluates it from a weaker position.

The damage is rarely one big error. It is usually five small ones stacked together: a new URL structure, no redirect map, thinner copy, text buried behind tabs, and a robots file copied across from staging. Each one alone is survivable. Together they read as a different, weaker site.

Recovery is possible but slow. Fixing redirects three weeks after launch still works, but you have spent three weeks of lost enquiries proving the point. If you are already in that position, our walkthrough on why a site stops showing up in Google sets out the diagnostic order.

Crawl and inventory the old site first

Nothing gets designed until you know what you already have. Run a full crawl of the live site and export every URL with its status code, title tag, meta description, H1 and word count. Tools like Screaming Frog or Sitebulb do this in minutes. Their pricing changes, so check the vendor page before you buy.

Then pull the data that tells you which of those pages actually matter.

  • Search Console: 16 months of clicks and impressions, by page and by query.
  • GA4: landing pages by sessions and by conversions for the last 12 months.
  • Your backlink tool: pages on your domain that have referring domains pointing at them.
  • Your CRM or lead sheet: the pages your last 50 enquiries landed on.
  • The current XML sitemap and robots.txt file, saved exactly as they stand today.

Sort the crawl by clicks and mark the top 20 percent of pages. Those are the pages most likely to carry your organic value, and they get protected. Everything else can be merged, rewritten or dropped, as long as it redirects somewhere sensible.

How do you map URLs and plan 301 redirects?

Build one spreadsheet with the old URL in column A and the new URL in column B, covering every indexable page on the old site. Nothing points at the homepage unless there is genuinely no closer match. Then test the whole map on staging before launch, not after.

  1. Export every URL from the crawl that returns 200 and is indexable.
  2. Add URLs that Search Console shows impressions for, even if the crawler missed them.
  3. Add old URLs that already redirect today, so you do not create new chains.
  4. Match each old URL to its closest new page by intent, not by name similarity.
  5. Flag any page with no equivalent, then decide: rebuild it, or send it to the nearest parent.
  6. Write the rules, apply them on staging, and crawl the old URL list against staging to confirm every row returns one 301 to a live 200.

Two details get missed constantly. Use 301, not 302, because a permanent redirect is the clear signal that the old URL has moved for good and the new one is now canonical. And keep every chain to a single hop: old URL straight to final new URL, never old to old to new.

If your URLs are changing because the new structure is genuinely clearer, that is a fair trade. Changing them because a new CMS defaults to a different pattern is not a reason. Every avoidable URL change is risk you took on for nothing.

What should you preserve from the old site?

Preserve what Google reads, not what your team has grown bored of. That means titles and H1s on ranking pages, body copy that answers real questions, internal links between service pages, structured data, and the URL itself wherever possible. Design can change completely. Text and structure should change only on purpose.

The most common self-inflicted wound is word count. A designer hands over a beautiful page carrying a fraction of the words the old one did. That page ranked because it answered questions. Strip the answers out and it stops ranking.

Keep the heading hierarchy intact as well. One H1 per page, H2s written in the language people actually search with, and no important text hidden inside accordions that load only on click. Our explainer on technical SEO covers how crawlers treat those patterns.

Lock down staging and protect your analytics

Staging sites belong behind HTTP password protection, not behind a noindex tag alone. A password stops crawlers and stops competitors reading your new pricing page a month early. If you must rely on noindex, put a hard reminder on launch day to remove it from every template.

The opposite failure is worse. Staging goes live carrying its own robots.txt, the one containing Disallow: /, and the site stays invisible until somebody thinks to check. Add "verify robots.txt and meta robots on five random pages" to your launch list and this stops being possible.

Analytics continuity matters as much as redirects. Keep the same GA4 property so your year-on-year comparisons survive, and confirm the tag fires on every template, thank-you pages included. Re-verify Search Console ownership if the CMS is changing, because verification often sits in a file or tag the rebuild quietly removes.

Set up conversion tracking before launch, never after. If forms, calls and WhatsApp clicks are untracked on day one, you cannot tell whether a dip is a ranking problem or a broken form. That distinction decides what you fix and how fast.

The pre-launch website redesign checklist

Run this in the 48 hours before go-live, on staging, with someone other than the developer signing off each line.

  • Redirect map tested: every old URL returns one 301 to a live 200 page.
  • Titles, meta descriptions and H1s carried across for the top 20 percent of pages.
  • robots.txt correct, no stray noindex, XML sitemap listing canonical URLs only.
  • GA4 and Search Console tags on every template, conversions firing in test mode.
  • Every form submitted end to end, including the email that lands in your inbox.
  • Mobile pass on a real phone: no cut-off text, no tap target smaller than a thumb.
  • Speed checked on your heaviest template, with images compressed and correctly sized.

Speed deserves its own pass, because new sites often ship heavier than the ones they replace. Sliders, video headers and three font families add up quickly. Work through a proper speed pass before go-live instead of promising to optimise it later.

If you want a second pair of eyes on the redirect map and the checklist before you launch, our team runs pre-launch reviews as standalone work. Send the details through our enquiry form with your launch date. We reply within one business day.

Launch day and the first 30 days

Launch on a Tuesday or Wednesday morning, never on a Friday evening. You want the developer, the marketer and the person who answers the phone all reachable for the next two days. Push the site, submit the new XML sitemap in Search Console, then immediately crawl your old URL list against the live domain.

Then watch, and give it time. Google needs days to weeks to recrawl a site fully, so small movement in week one is normal rather than proof of failure. What is not normal is a dip that deepens after week two, or pages vanishing from the index.

What to checkWhereHow often in month oneIf it looks wrong
404 errors and redirect chainsSearch Console Pages report plus a fresh crawlTwice a weekAdd the missing 301 the same day
Indexed page countSearch Console Pages reportWeeklyCheck robots.txt, meta robots and canonical tags
Clicks for your top 20 landing pagesSearch Console Performance, 28 days versus the previous 28WeeklyCompare old and new titles and copy, restore what was cut
Core Web Vitals and mobile usabilitySearch Console plus PageSpeed InsightsWeeklyFix images, third-party scripts and layout shift
Form fills, calls and WhatsApp enquiriesGA4 and your CRM or lead sheetDaily in week oneTest the journey yourself before assuming demand fell

Hold the site in active monitoring for a full 30 days before you judge the rebuild. Compare like with like: the same 28-day window against the previous period, and against the same month last year. Seasonality moves Indian service and B2B enquiries more than most owners expect.

If Core Web Vitals is where the trouble shows, read the field data and lab data separately. They often disagree in the weeks right after a launch, and acting on the wrong one wastes a sprint.

A rebuild is also a natural moment to fix search problems you have carried for years: thin service pages, missing schema, a sitemap stuffed with tag archives. Folding that into the build is usually simpler and less disruptive than scoping a separate SEO engagement once the site is live. Owners in Pune and Pimpri-Chinchwad usually arrive with both problems at once, which is why our Pune build team scopes them together.

Frequently asked questions

How long should a website redesign take?

Most business sites take 6 to 12 weeks from discovery to launch, depending on page count and how much new content you need. The build is rarely the bottleneck; content approvals and redirect mapping are. Weekly checkpoints keep it honest, so nobody discovers an unfinished mapping exercise during launch week.

Will I lose rankings even if I do everything right?

You may see movement for a few weeks while Google recrawls and re-evaluates the site. Handled properly, positions usually settle back, and often improve because the new site is faster and better structured. Nobody can guarantee rankings and we do not. A good process guarantees that any drop has a findable cause.

Do I have to keep my old URLs?

Keep them wherever the page is doing the same job. Change them only when the new structure is genuinely clearer for a visitor, and redirect every changed URL with a single 301. If you are moving off a messy CMS with URLs like /index.php?p=42, changing them is the right call.

Can I redesign in stages instead of one big launch?

Yes, and on larger sites it is usually safer. Ship the new template on a low-traffic section first, watch it for two weeks, then roll forward. Staged launches make it obvious which change caused a problem. They take longer and cost a little more in project management.

Getting the rebuild right the first time

A redesign that keeps its rankings is not luck. It is an inventory, a tested redirect map, preserved content, working analytics, and somebody watching the numbers for 30 days after launch. Everything else is design opinion, which matters far less than most owners assume.

If you are planning a rebuild this quarter, send us your current site URL and what you want to change. We will tell you honestly which pages are at risk and what the mapping work involves. Start on our contact page, or call the Pune office on +91 70962 91214.