Back to thinking
Technology 24 Aug 2026

The Website Redesign Checklist: When to Rebuild, What to Do First, and How Not to Lose Your Rankings

Most redesigns are launched by feelings and measured by nothing, and the bill arrives as a 30 percent organic-traffic drop nobody can explain. This is the operational website redesign checklist: the triggers that actually justify a rebuild, the baseline work before anyone opens Figma, the SEO-safe migration steps, performance and accessibility budgets, and the 90-day post-launch watch. Written from projects where we were called in after the rankings were already gone.

The Website Redesign Checklist: When to Rebuild, What to Do First, and How Not to Lose Your Rankings

Most website redesigns are launched by feelings and measured by nothing. Someone senior gets bored of the site, a competitor ships something shiny, and six months later there is a new website, a 30 percent organic-traffic drop, and no baseline that can prove the new site converts any better than the old one did.

This is the website redesign checklist we actually run: the triggers that justify a rebuild, the pre-work that happens before anyone opens Figma, the SEO-safe migration steps, and the post-launch watch. It comes from scars, including projects where we were called in after the rankings were already gone.

Redesigns are the highest-risk project in web work because you are not building an asset, you are moving one. Traffic, rankings, backlinks, and conversion patterns all live at specific URLs on the old site. Move carelessly and they do not come with you.

The triggers that justify a redesign (and the ones that don't)

Legitimate triggers name a business outcome the current site is blocking:

  • A positioning shift. New offer, new audience, a rename, a rebrand. When the identity changes, the website has to follow or the brand splits in two. The Bengaluru Cafe rebrand playbook shows how a repositioning cascades into every customer-facing surface, and the website is first in that queue.
  • Conversion decay you have diagnosed. Enquiries per hundred visits falling for consecutive quarters, drop-offs concentrated on specific pages, and you know why. "The site feels off" is not a diagnosis.
  • An unmaintainable stack. Nobody can edit the site without the one developer who built it. Plugin towers that break on every update. The vendor is gone. When publishing a price change takes two weeks, the stack itself is the trigger.
  • Mobile and performance debt. Failing Core Web Vitals, five-second loads on the mid-range Android phones most Indian traffic arrives on, layouts that break below 400px. This debt is measurable, which makes it the easiest trigger to verify.

The vanity triggers, by contrast: a new marketing head wants a visible win, a competitor redesigned, the founder is bored, an awards deadline. None of these name an outcome. If you cannot finish the sentence "the current site is costing us ___", you do not need a redesign yet. You need the diagnosis.

The pre-work: baseline everything before you touch anything

The most common redesign failure is not bad design. It is starting the build with no record of what the old site actually did. Budget three to four weeks for this, before the first wireframe.

1. Capture the analytics baseline

Pull 6-12 months of data: sessions by source, conversion rate overall and per key page, top landing pages, top queries. If tracking is broken (it often is), fix it and collect at least four clean weeks first. Without a baseline, nobody can ever prove the redesign worked, and the loudest opinion in the room wins forever.

2. Run the content audit

Every page gets a verdict: keep, rewrite, merge, or kill, decided with data (traffic, rankings, backlinks, conversions) rather than taste. Most sites past their fifth year shrink 30-50 percent in this step, and that is healthy.

3. Build the keyword and URL inventory

Crawl the site (Screaming Frog or similar), export every indexed URL from Search Console, and mark which URLs hold rankings and backlinks. These URLs are assets on a balance sheet; the redesign either preserves them or writes them off. This inventory becomes the redirect map later, so it is not optional.

4. Archive the old site and agree the success metric

Keep a full crawl copy plus screenshots of every key page. Then write down, before design starts, the number the redesign must move and by when. This is discovery work, and it is exactly why our Discovery Blueprint front-loads strategy before pixels: a redesign without an agreed metric cannot succeed. It can only end.

The SEO-safe migration steps (skip these and pay in rankings)

The part most redesigns get wrong, and the part that is genuinely unforgiving:

  • Map every URL. Old URL to new URL, one to one, in a sheet, finished before the build finishes. Redirecting everything to the homepage is not a migration, it is a write-off: Google treats those as soft 404s and the accumulated link equity evaporates.
  • Use 301s, not 302s. Permanent redirects pass authority. Test the full map on staging with a crawler, not by clicking around.
  • Keep URLs stable wherever you can. The best redirect is the one you never needed. Renaming /services/branding to /what-we-do/brand for aesthetics is paying real ranking risk for nothing.
  • Canonical hygiene. Canonicals must point at the final new URLs. Not staging, not the old domain, and never through redirect chains. We have audited sites a full year after launch still canonicalizing to a dead staging subdomain.
  • Metadata and content parity on money pages. Pages that rank keep their targeting: titles, headings, and the substance of the copy. A redesign that "cleans up" a ranking page is quietly deleting the reason it ranked.
  • The noindex check, in both directions. Staging must be noindexed; production must not be. Shipping the staging robots tag to production is the classic launch-night injury: one line to cause, weeks to recover.
  • Structured data parity. Whatever schema the old site carried (organization, products, articles, FAQs) survives or improves. Sitemap regenerated and submitted on day one.

None of this is exotic. It is a spreadsheet, a crawler, and discipline. Which is exactly why it gets skipped when the launch date turns emotional.

Performance and accessibility budgets: set them before design

Budgets set after the build is an argument. Budgets set before design are a filter every decision passes through cheaply, while it is still a Figma frame.

Write them into the project agreement as numbers. A workable 2026 set for an Indian audience: LCP within 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, measured on a mid-range Android over 4G (the official thresholds are documented at web.dev). Add a weight budget of roughly 1.5 MB on key landing pages, a two-font-family cap, and every image sized and lazy-loaded.

Accessibility rides along as a budget, not an afterthought: WCAG AA contrast, visible focus states, keyboard-navigable menus and forms, real alt text. In practice the accessible version of a decision is usually also the faster, better-converting one.

The point of budgets is that "we'll optimize later" is a lie every project tells itself. The full-bleed autoplay video hero is cheap to kill in design review and expensive to kill after the CEO has seen it live.

The post-launch watch: the 90 days that decide it

Launch night is the midpoint of a redesign, not the end.

Days 1-7. Crawl the live site. Test the redirect map against production, at minimum the top 200 old URLs by traffic and links. Submit the new sitemap in Search Console and watch coverage for 404 spikes. Verify analytics events actually fire; a redesign that silently drops conversion tracking blinds you at the exact moment you need eyes.

Weeks 2-6. Rankings wobble after a migration; that much is normal. What is not normal is a specific money page falling and staying down, which almost always traces to a broken redirect, lost content parity, or a stray noindex. Work the 404 report weekly and patch the map.

Days 28-90. Core Web Vitals field data runs on a 28-day window, so the real-user performance verdict arrives a month late; do not celebrate or panic on lab numbers alone. Then run the comparison that justifies the whole project: conversion rate against the baseline you captured in pre-work. Keep the old-site archive and the URL map for a year. Late-discovered breakages happen.

The website redesign checklist, condensed

  1. Name the trigger as a business outcome, or stop.
  2. Capture 6-12 months of analytics baseline; fix tracking first if it is broken.
  3. Audit content: keep, rewrite, merge, kill, with data.
  4. Inventory every URL; mark rankings and backlinks.
  5. Archive the old site. Agree the success metric in writing.
  6. Set performance and accessibility budgets before design starts.
  7. Keep URLs stable where possible; map the rest one to one.
  8. 301 redirects, tested on staging with a crawler.
  9. Canonical, metadata, content, and schema parity on money pages.
  10. Check noindex in both directions at launch.
  11. Week one: crawl, test redirects, submit sitemap, verify analytics.
  12. Watch Search Console and the 404 report weekly for six weeks.
  13. Judge Core Web Vitals on field data after day 28.
  14. Compare conversions to the baseline. Keep the archive for a year.

Fourteen lines. Every ranking-loss story we have been called into skipped at least three of them.

FAQ

How long does a website redesign take?

Eight to fourteen weeks for a studio-grade marketing site: two to four weeks of pre-work and discovery, four to six of design and build, two of content load and migration testing. Content readiness, not design, is the usual schedule killer.

Will a redesign hurt my SEO?

Done with the migration steps above: expect a dip of two to six weeks, then recovery to equal or better. Done without them: 20-50 percent organic losses are common, and some never fully return, because deleted URLs and broken redirects write off years of accumulated authority.

Should we redesign or improve incrementally?

If the stack is maintainable and the positioning has not moved, iterate: performance passes, page-level rewrites, conversion fixes. Redesign when a real trigger fires: the position has shifted, the stack fights every change, or the debt is structural.

How often should a website be redesigned?

On triggers, not on a calendar. A well-built site on a maintained stack runs three to five years with continuous iteration. If you are rebuilding every 18 months, the problem is how the sites are being built.

What does a redesign cost?

The same market as a new build, often 10-20 percent more because of migration work: ₹30,000-1,50,000 freelance-grade, ₹2,50,000-8,00,000 studio-grade in the Indian market, quoted + GST. The migration discipline is the point of the fee; it protects the traffic you already own.

Redesign like it's a migration, not a repaint

The redesigns that go wrong treat the project as decoration: new look, same URLs somewhere underneath, hope for the best. The ones that work treat it as moving a revenue asset between buildings. Inventory first, insurance in place, nothing valuable left behind, everything tested before the old door closes.

That discipline is most of what you are buying when you hire well. It is baked into how we scope website work, and whoever builds yours, hold them to the fourteen lines above. A repaint costs a few lakhs. A careless migration costs the rankings that took five years to earn.

Websites

What a business website costs in India, who should build it, and how to redesign without losing your rankings.

  1. How Much Does a Website Cost in India in 2026? The Real Ranges, Tier by Tier Start here
  2. Agency, Freelancer, or DIY: How to Choose a Website Development Company in Bangalore (or Skip One Entirely)