The key points
- Record a baseline first: top pages, queries, backlinks and speed.
- Every address that changes needs a 301 to its closest equivalent, never the homepage.
- Keep the pages and headings that already earn traffic; consolidate true duplicates.
- Build on a separate address, then remove staging blocks and check indexing at launch.
Why do redesigns lose search visibility?
Mostly because of addresses. Search engines learn that one URL answers one question. Change the URL, point nothing at the new one, and the ranking attached to the old page goes with it. You click a result that used to work, land on an error page, and leave. Google notices that too.
The other causes are quieter: content that earned traffic gets cut during a rewrite, titles and headings change without anyone asking whether they mattered, and a staging block (noindex or a robots rule) survives into production. Each one is easy to prevent and slow to diagnose afterwards.
What should you record before you design anything?
A baseline. Export your live URLs, the pages that bring traffic or enquiries, the queries they appear for, the sites that link to them and how fast they load. Crawl the site once and keep the file. After launch you will crawl the new site and compare the two, and without the first crawl you are guessing what changed.
This is also the cheapest moment to see what the redesign should not touch. A page that quietly brings in half your enquiries deserves a different level of care from a page nobody has opened in a year.
- Every live URL, with status and title
- Pages that bring traffic or enquiries, and the queries behind them
- Pages other sites link to
- Load speed on a mid-range phone
What should you keep, merge or remove?
Content that earns traffic or enquiries stays, ideally improved rather than rewritten from nothing. Pages that duplicate each other are usually better merged into one stronger page, which tends to help rather than hurt. Pages that serve no one can go, with a redirect to the nearest relevant page.
Deciding this after the design is finished means the design was made without knowing what mattered. That is why the audit comes first, and sometimes the audit shows you should fix the site instead of redesigning it.
In what order should you change things?
Where you can, change one layer at a time: layout first, then content, then URLs. If everything moves at once and traffic drops, you cannot tell whether the cause was the design, the copy or the addresses. If you must move everything together, the baseline crawl is what lets you work backwards.
Keep the page structure search engines already trust. Titles, main headings and the internal links between your important pages should survive the redesign unless you have a reason to change them.
How should redirects be set up?
Pair each old address that will change with its closest new equivalent and use a permanent (301) redirect. Sending everything to the homepage is close to deleting the pages. Point each old URL straight at its final destination so there are no chains, and set the redirects on the server rather than with JavaScript or meta refresh, which search engines may not treat as a permanent move.
If the domain itself changes, the same rule applies at larger scale: every old address maps to a new one, and the old domain keeps redirecting for as long as people still link to it.
Will the website be offline during the switch?
It does not need to be. The new site is built and tested on a separate address, you approve it, and the domain is then pointed at it, a change that takes minutes and can be scheduled outside your busiest hours.
On launch day, work through a launch checklist: remove any staging noindex and robots block, check that the sitemap lists the new addresses, confirm analytics and forms work, and test a sample of old URLs to see that each redirects once and lands on the right page.
How long until rankings settle?
Expect some movement. Search engines need time to recrawl and reassess, so watch indexing, crawl errors and enquiries in Search Console and analytics for several weeks rather than judging in days. Fix redirect errors, missing pages and metadata problems as they appear, and keep your comparison crawl to hand.
Judge the result by enquiries and the pages that bring them, not by a single day's ranking report.
Can AI search and assistants still read the new site?
Only if the content is in the page itself. A redesign that moves text, links or filters into scripts that run after the page loads can hide them from crawlers that do not run JavaScript, which includes some AI assistants. We build pages on Next.js so the full text and links arrive in the first response. Check any redesign you commission by viewing the page source and looking for your headline and main links.
How do you redesign a website without losing SEO, step by step?
Record a baseline
List every live URL, the pages that bring traffic or enquiries, their queries, backlinks and speed, and crawl the site once and keep the file.
Plan the new structure
Keep the structure and headings search engines already trust, and decide what is kept, improved, merged or retired.
Map the redirects
Pair every address that will change with its closest new page, pointing straight at the final destination.
Build on a separate address
Develop and test away from the live site, with search engines blocked from the staging copy only.
Switch and verify
Point the domain at the new site, remove staging blocks, submit the sitemap, then crawl and compare against the baseline.
Monitor for several weeks
Watch indexing, errors and enquiries, and fix anything that appears quickly.
Before approving a redesign
- Do you have a crawl and list of every URL currently live?
- Which pages currently bring traffic or enquiries?
- Is there a written redirect map for every address that changes?
- Will the new site be tested on a separate address first?
- Who removes staging blocks and checks indexing after the switch?
- Can you see your headline and main links in the new page's source?
Sources
Rules and guidance this answer relies on. Policies change, so check the current version before acting on it.