A website redesign can change how your organisation looks, works and speaks. Search traffic may be at risk if the move is only seen as a design job.
There is no honest way to promise that rankings will never move. Google needs time to crawl and process changed pages. A careful migration can reduce avoidable risk, keep useful signals in place and help your team spot problems fast.
In our website discovery sessions, we often hear the same needs. A team wants to reuse good content and fix a site that is hard to manage. It may need to merge two domains. It may want a page for each main product or service. The team also wants the current site to stay live while the new one is built. All of this needs a plan before the design and build are done.
Start with an inventory, not a blank page
Before changing the site, record what exists. Crawl the current website and export every known URL. Add URLs from the XML sitemap, Google Analytics and Google Search Console. Check paid ads and links from other sites too. Look for pages that are hard to reach through the menu.
Your inventory should include HTML pages, images, videos and useful downloads such as PDFs. For each URL, record its title, meta description and main heading. Add its canonical URL, search traffic, links and status code. Note which pages drive enquiries, sales or other actions.
This work shows what has value. It also finds old pages that need a choice: keep, improve, merge, redirect or remove. Our beginner's guide to completing a website audit is a useful place to start.
Plan the new URL structure early
A redesign does not mean every URL must change. Keep a good URL if the page still has the same purpose. This lowers the number of redirects and makes the move easier to test.
Change a URL when there is a clear reason. You may need a better site structure, one main domain or a new page type. A useful item hidden in a pop-up may need its own page. People can then share it, and search engines can index it. Two old pages may need one stronger page in their place. Make these content and search choices well before launch day.
Create a URL map with one row for every old address. Match it to the most relevant new address. Do not send every retired page to the home page. If no close replacement exists, a proper 404 or 410 response may be more accurate.
Build one-to-one permanent redirects
Google recommends server-side permanent redirects when page URLs change. A 301 or 308 status tells search engines and people that the page has moved. Read Google's guide to redirects before choosing the method for your platform.
A good redirect takes an old page to its closest new match in one step. Avoid redirect chains, loops and broad rules that send unrelated pages to the same place. Test every mapped URL, not just a few samples.
For a domain move, keep control of the old domain. Google says redirects should stay in place for as long as possible, generally at least one year. Keeping them for longer can still help people who use old bookmarks or links. For a large redirect set, our Cloudflare bulk redirects guide explains one practical way to manage the rules.
Protect content that already earns attention
Do not cut a useful page just because the new design needs less copy. Review the search terms, links and actions tied to that page first. Keep the parts that answer a real need, then make the writing clearer.
If several pages cover the same subject, choose the best home for that content. Redirect the weaker URLs to it. Keep old material when it still helps users. An archive may be better than deletion. Past products, reports or articles may still get links and searches.
Check every migrated page for missing text, broken images, empty headings and bad links. Content imports can look complete at a glance while leaving gaps in tables, captions, files or rich text.
Move metadata and search signals too
Each new page needs a clear title and meta description. It also needs one main heading. Preserve strong metadata where the topic has not changed. Rewrite it when the new page serves a different need. Do not give every page the same title or description.
Set a self-referencing canonical tag on each indexable page. Update internal links so they point straight to the final new URLs, not through redirects. Check image alt text, hreflang tags if used, and XML sitemaps.
Structured data can disappear during a rebuild even when the page looks right. Copy valid schema that still matches what people can see. This may include Organisation, Article, Product or Breadcrumb markup. Update all URLs and test the output with Google's Rich Results Test. Do not add claims to schema that users cannot see on the page.
Keep staging private, then remove the blocks
Build and test the new site on a staging address. Keep the current site live while this work takes place. Protect staging with login access where possible. A noindex rule can also keep staging pages out of search. You must remove it before launch.
Google's noindex guidance explains that Google must be able to crawl a page to see a noindex rule. Blocking the same page in robots.txt can stop that from happening. Do not rely on one rushed setting. Keep a launch list for passwords, noindex tags and robots.txt rules.
Before launch, crawl staging as if it were live. Check status codes, canonicals, headings and metadata. Test forms, search, menus and filters. Check mobile layouts and page speed. If the project is complex, our digital capabilities show how strategy, design, development and growth work can fit together.
Set up analytics and Search Console before launch
Keep measurement in the migration plan. Add the right Google Analytics and tag manager setup to staging. Test it without mixing test visits into live reports. Confirm page views, forms, purchases, phone links and other events that matter to the organisation.
Record a baseline before the move. Save recent organic traffic, top landing pages, conversions, indexed pages, rankings and crawl errors. Without this view, the team may know traffic changed but not where or why.
Verify the old and new site properties in Google Search Console. For a domain move, use the Change of Address tool and submit the new sitemap. This advice comes from Google's site move guide. An HTTP to HTTPS move does not need the Change of Address tool.
Run launch checks, then watch the site
Launch should be a controlled switch, not a late-night surprise. Take a final backup. Put the redirects live at the same time as the new pages. Remove staging blocks, confirm the main domain and HTTPS version, and submit the new sitemap.
Then crawl the live site. Test key old URLs and top landing pages. Test forms and steps that lead to a sale or enquiry. Look for 404 errors, redirect chains and missing canonicals. Check for blocked pages, noindex tags and broken files. Confirm analytics data is arriving.
Watch Search Console, analytics and server logs during the first days and weeks. Some movement is normal while Google crawls the site again. Check any sharp or lasting drop by page group, not only for the whole domain. Fix errors, keep the redirect map current and update strong external links where you can.
A safer redesign keeps old value in view
The safest migration starts by learning from the current website. Its URLs, content, links and data are part of the brief. Design can then improve the experience without discarding useful search value by accident.
You can see how IGNITE approaches complex website work in our selected work. If you are planning a redesign, platform change or domain merge, talk to our team before the URL plan gets locked in.