You plan a website redesign without losing rankings by treating it as a migration, not just a makeover: audit every ranking page and URL on the current site first, build a redirect map that gives each changed URL one permanent destination, test the new site on staging for content parity and technical faults, launch following a written sequence, then monitor rankings, coverage and conversions against your pre-launch baseline for four weeks. Rankings are attached to pages, not to businesses — protect the pages and their addresses, and the rankings follow.
Redesigns earn their frightening reputation honestly. A site returns from its relaunch looking faster, cleaner and more modern — and within a fortnight its enquiries have halved, because a third of its pages moved to new addresses with no redirects, its best guide was quietly dropped for being “off brand”, and the staging copy’s block on search engines followed the new site into production. None of those failures is a design failure. All of them are migration failures, and every one is preventable with the checklist in this guide. The redesign itself — new look, better structure, clearer calls to action — is the part owners enjoy. This guide is about the unglamorous work around it that decides whether the business keeps the search visibility it has already earned while the new design goes live. It assumes you have already decided to redesign; for what that decision costs, our website redesign cost guide sets out the figures, and this guide picks up from the moment the project is approved.
Step One: Audit What You Already Have Before Anyone Designs Anything
The audit is an inventory of what must survive. Start in Google Search Console and your analytics: list every page that received organic traffic in the last twelve months, the queries each page ranks for, and every page that produces enquiries, bookings or sales, including pages whose traffic looks small — a page bringing five visitors a month who all become customers outranks, commercially, a page bringing five hundred who never enquire. Then crawl the whole site, or export its full URL list, so pages nobody remembers — an old offer page still linked from a partner site, a guide from three years ago still ranking quietly — are on the record. Record backlinks you know about, because a URL with links from other sites carries value that vanishes if the address dies. Finally, save the baseline numbers: total organic sessions, the ranking positions of your money keywords, and conversion counts for a normal recent month. Every later judgement in the project — dip or disaster, recovery or problem — is made by comparing against this baseline, and it cannot be reconstructed after launch.
| Audit item | Where it comes from | Why it matters |
|---|---|---|
| Every live URL | Site crawl or sitemap plus Search Console pages report | The raw material for the redirect map; anything missing here can be lost silently |
| Top pages by organic traffic | Analytics and Search Console, last 12 months | These pages must survive with content and address intact or redirected |
| Pages that convert | Analytics goals, form and order records | Commercial value, which traffic figures alone understate |
| Ranking queries per page | Search Console performance report | Tells you what each page is for, so a rewrite does not discard its topic |
| Known inbound links | Search Console links report | Linked URLs must never return a dead end after launch |
| Baseline traffic, rankings, conversions | Analytics and rank records for a normal month | The yardstick for the four post-launch weeks |
Step Two: Build the Redirect Map While the Old Site Is Still Live
A redirect map is a simple document with large consequences: two columns, old URL and new URL, one row for every address that will change. Build it from the audit list, not from memory, and apply three rules. First, every changed URL redirects to the single closest equivalent page on the new site — the successor that serves the same visitor intent. Second, redirects are permanent 301 redirects, which tell search engines the move is final and pass the page’s accumulated value to the new address. Third, URLs that are not changing get no row: the safest redirect is the one never needed, so keep addresses stable wherever the page’s purpose survives the redesign. Where an old page has no equivalent at all, decide deliberately: create the content on the new site if the page earned traffic or links, redirect to the nearest relevant section if a close cousin exists, or let it return a genuine not-found response if it earned nothing. What no old page should ever do is land, along with dozens of others, on the homepage — a pattern search engines treat as a soft error and visitors experience as being lost.
Keep the map in a shared document that the designer, the developer and you can all see, and treat it as a deliverable with an owner. It will grow during the build as page plans change; that is normal. What is not acceptable is discovering its gaps after launch from a crawl-error report, when the fix is still possible but the ranking damage has already begun.
Step Three: Staging Checks — Rehearse the Launch on a Copy
The new site should be built and reviewed on a staging address, a private copy the public and search engines are not meant to see. Staging is where design opinions belong — colours, layout, photography — and it is also where the migration checks happen, calmly, before they are urgent. Verify that the staging site is blocked from indexing, because a staging copy that search engines can find creates duplicate content; then schedule the equally important opposite check for launch day, because a block left in place after launch is one of the classic redesign disasters. Click through every template on a phone and a desktop. Submit every form and confirm the messages arrive. Run a test order if the site sells. Then do the check teams skip: content parity.
Content parity means comparing the new site against the audit, page by page. Every page that earned traffic or conversions exists on the new site, at its mapped address, carrying content that still covers the topic its rankings were built on. Headings may be tightened and copy improved — improvement is the point of a redesign — but a page that ranked for a detailed guide cannot be replaced by two cheerful paragraphs under the same address and expect to hold its position. Search engines rank the content, not the intention. Parity also covers the invisible layer: page titles and descriptions carried over or deliberately improved, images given equivalent alternative text, and internal links updated so the new site links to its own new addresses rather than leaning on redirects internally.
Step Four: The Launch-Day Sequence
Launch on a quiet weekday morning, never on a Friday and never just before a campaign, so that the people who built the site are available while the first checks run. The sequence itself is short and should be written down in advance with a name beside each step. Take a full backup of the old site before anything changes — the redesign’s rollback is the old site, complete and restorable. Put the new site live. Implement the redirect map, then test a sample of redirects by hand, including every top page from the audit, and confirm each lands on its intended destination in one hop. Remove the staging indexing block and confirm the live site can be crawled: check the robots file and a page’s indexing settings directly, not from memory. Submit the new sitemap in Search Console and request indexing for the homepage and the most important changed pages. Run a crawl of the live site looking for broken links, redirect chains and missing pages. Finally, annotate the launch date in your analytics, so that everyone reading the graphs in six months knows exactly where the change happened.
An Illustrative Timeline for a Small-Business Redesign
The timeline below is illustrative — a worked example for a small-business site of a few dozen pages, not a promise for any particular project. Larger sites stretch the audit and mapping stages; very small sites can compress the early weeks. What should not compress is the sequence: audit before design, map before build finishes, monitoring after launch for the full four weeks.
| When (illustrative) | Stage | Migration task due |
|---|---|---|
| Weeks −6 to −5 | Audit | Full URL inventory, top pages, baseline figures recorded |
| Weeks −4 to −3 | Design | Redirect map drafted from the audit; URL changes agreed |
| Weeks −2 to −1 | Build on staging | Content parity check; redirect map finalised; forms and orders tested |
| Launch day | Go-live | Backup, launch sequence, redirect spot-checks, sitemap submitted |
| Week +1 | Early monitoring | Coverage and crawl errors daily; redirect gaps fixed same day |
| Weeks +2 to +4 | Recovery monitoring | Rankings and traffic compared with baseline weekly; content gaps addressed |
Illustrative traffic pattern after a careful redesign (index, launch week = 100) — hover or tap each bar for details.
The chart is illustrative, not a statistic: it sketches the pattern a careful migration commonly produces, with traffic indexed against the launch week. A dip in the first week or two as search engines process the changes, a climb as redirects and new pages are absorbed, and a return to roughly baseline — or better, if the redesign genuinely improved the site — by about week four. Two readings of that shape matter. A dip inside this pattern is not an emergency and should not trigger panicked changes, because constant changes restart the processing you are waiting for. A fall far beyond this shape, or a line still dropping at week three, is a fault to hunt, and the hunt starts with the redirect map and the coverage report — the two places redesign losses actually live. Our guide to reading Google Search Console shows exactly where those reports sit and what their figures mean.
Step Five: Four Weeks of Post-Launch Monitoring
Monitoring is scheduled work, not anxious refreshing. In the first week, check Search Console coverage and crawl errors every day or two: new not-found errors are usually redirect-map gaps, and each one fixed the same day is a page rescued. Request indexing for important pages that are lagging. Weekly for the full four weeks, compare the same figures you baselined: organic sessions, positions for your tracked keywords, and conversions, page by page for the top pages from the audit. A top page that has slipped needs a specific diagnosis — is it indexed, does the redirect land correctly, does the new content still cover the queries it ranked for — rather than a general worry. Keep a short log of every fix you make, with dates, because the log is what lets you connect a recovery to a cause. After four stable weeks, hand the routine over to normal monthly maintenance; the launch checklist discipline in our website launch checklist covers the wider set of go-live checks that sit alongside the search-specific ones in this guide.
The Mistakes That Tank Rankings
- Changing URLs with no redirect map. The classic. Every moved page starts again from zero, every inbound link points at a dead end, and the loss is discovered weeks later in the enquiry figures. The map costs a day; the recovery costs a quarter.
- Leaving the staging block on the live site. A setting carried over from the staging copy can tell search engines not to index the brand-new site at all. It is a one-line check on launch day and a catastrophe if nobody makes it.
- Cutting “underperforming” pages by traffic alone. Pages with modest traffic often carry the conversions, the long-tail rankings and the inbound links. The audit must weigh conversions and links before any page is dropped, and dropped pages still need a deliberate redirect or retirement decision.
- Rewriting every page’s content at the same time as the move. Changing the address, the design and the entire text simultaneously makes any ranking movement impossible to attribute — and risks discarding the exact wording a page ranked for. Improve content in a second pass, once the migration has settled.
- Launching everything at once, including a domain or platform change. Each additional simultaneous change multiplies the variables. Where a domain move or platform change is also planned, sequence the changes and let each settle, unless there is a compelling reason to combine them and the team to monitor the combination.
Conclusion: The Design Is the Visible Half
A redesign protects its rankings the same way a house move protects its furniture: inventory first, labels on everything, a plan for where each piece goes, and a check of every room afterwards. Audit the site you have, map every changed address to its successor, rehearse on staging with a content-parity check, launch by a written sequence on a quiet morning, and monitor against your baseline for four weeks. Do those five things and the new design inherits the visibility the old one earned — which is, after all, the asset the whole project was supposed to improve rather than endanger.
Planning a redesign and worried about the rankings your current site has earned? Book a free consultation with Asad Webs — we will audit your top pages, build the redirect map with you, and plan the launch sequence before any design work begins, so the new site starts from your current visibility rather than from zero.
Frequently Asked Questions
Will a redesign always cause a traffic dip?
A small, short dip is common even with a careful migration, because search engines need time to process changed pages and redirects. The illustrative pattern in this guide shows a dip recovering within about four weeks. A large or lasting fall usually signals a specific fault — missing redirects, lost content or blocked crawling — rather than the redesign itself.
What is a redirect map?
A document that pairs every old URL that will change with the single new URL that replaces it, so a permanent 301 redirect can be set up for each one. It is built from the audit of the live site before design work begins, and tested again on launch day.
Should every old page redirect to the homepage if it has no equivalent?
No. Sending unrelated old pages to the homepage strands visitors and wastes the ranking value those pages earned. Redirect each page to its closest real equivalent; where nothing equivalent exists, let the page return a genuine not-found response or create the missing content if the old page earned meaningful traffic.
How long should I monitor the site after launch?
Closely for at least four weeks: crawl errors and coverage in the first days, rankings and traffic against the pre-launch baseline weekly, and conversions throughout. After four stable weeks, fold the checks into a normal monthly routine.
Can I change URLs and design at the same time?
You can, and most redesigns do — but every changed URL raises the stakes on the redirect map and the launch-day checks. Keeping URLs stable where the page’s purpose has not changed removes risk for free, so change only the URLs that genuinely need to change.
What should I record before the redesign starts?
Your top pages by organic traffic and by conversions, the queries they rank for, every URL on the site, inbound links you know about, and current baseline figures for traffic, rankings and enquiries or sales. Without that baseline, a post-launch dip cannot be measured and a recovery cannot be proved.
Who should own the migration checklist?
One named person, whether that is you, your developer or your agency. Ranking losses after a redesign are usually handover losses: each party assumed another was handling redirects or staging settings. A single owner with a written checklist closes that gap.

Be the first to share a useful question or thought.