Before a website redesign, record the pages people already find, keep useful URLs where possible and agree how every changed address will work after launch. Then test those routes on the real domain. A polished preview cannot show whether an old search result still brings a buyer to the right service.
This checklist is for an established business replacing an existing website. It helps you agree what evidence your supplier should hand over. It can reduce avoidable disruption; it cannot guarantee unchanged rankings or enquiries. Google explains that significant site changes can cause temporary search fluctuations while pages are recrawled and reindexed.
1. Save a baseline before the old site disappears
Ask for a list of existing public page addresses, including useful PDFs and other downloads. Use the current sitemap and a site crawl, then compare them with pages receiving search traffic in Search Console, landing pages in analytics and links used in campaigns. One source can miss pages another source finds.
Flag the pages that matter to the business: a service people ask for, a product buyers identify by code, or a location page linked from your business listing. Save their current content, titles, important images and contact routes. Record the reporting dates and filters, so a later comparison means something.
Keep a recoverable copy of the old site and agree who can restore it. If orders or enquiries are stored separately, include those systems in the recovery discussion. A folder of screenshots does not establish that the website can be restored.
2. Decide what happens to each old address
A redesign does not require new URLs. Where a page still answers the same question, keeping its address removes one migration task. If the address changes, ask for an old-to-new mapping before launch.
| Old address — illustrative only | Decision | What to check after launch |
|---|---|---|
/services/repair/ |
Keep the page and address | Opens normally with the intended service content |
/old-service/ |
Move to /services/repair/ because it is the relevant replacement |
Permanent redirect reaches that final page |
/obsolete-offer/ |
Remove; no relevant replacement | Returns a genuine 404 or 410 response |
Do not send every removed page to the homepage. Google's site-move guidance warns against redirecting many unrelated old URLs to one irrelevant destination. A redirect should help someone who followed the old link.
For permanent moves, Google recommends server-side permanent redirects, such as 301 or 308. Ask the developer to test the actual response and destination, including avoidable chains and loops. A page containing a link to the new address is a different experience.
Google generally recommends keeping redirects for at least one year. Useful old links may remain in circulation longer; agree who maintains those routes when the old hosting is cancelled.
3. Preserve the answer, not just the address
Keeping a URL while removing the service detail it was known for can still change what that page offers. Compare important old pages with the proposed replacements. Check that the buyer can still find the relevant products, service area, limitations and next step.
The developer should also review page titles, main headings, internal links, canonical addresses and the sitemap. A canonical identifies the preferred address for a page; the redesigned page should not accidentally name a preview domain or an outdated URL. Where translations exist, check that language links connect the corresponding pages.
This is not an instruction to freeze weak content. Improve inaccurate or confusing material, and document substantial changes. The point is to make a deliberate decision rather than lose useful information during a template change. Use the website content checklist to organise the facts and approvals.
4. Set a preview and launch gate
Test a separate preview before replacing the public site. If it contains private information, restrict access. A search exclusion instruction is not access control.
A preview may use noindex to discourage search indexing. Google explains that a crawler must be allowed to access the page to see that instruction: blocking the page in robots.txt can prevent it from reading the rule.
Before launch, have the developer check that the pages intended for search have no accidental noindex, password barrier or crawl block, and that their canonical addresses use the final domain. Keep intentional restrictions on private or duplicate pages. Do not simply remove every restriction across the website.
Ask for a short list of launch blockers: missing important pages, wrong redirect destinations, broken buyer actions and unintended search exclusions. Give each one an owner. Agree the launch decision and recovery responsibility before the deadline arrives.
5. Test the real domain on launch day
Open the important old addresses directly after publication. Follow the full journey: old link, final page, relevant information and contact or order action. Test on a phone as well as a computer. Coordinate any live form or checkout tests so staff can identify them; avoid creating unintended customer messages or orders.
Have the developer verify response codes, redirects, page content, internal links, sitemap entries and search instructions on the public domain. A successful upload or a green preview check does not prove these are correct in production.
Record the launch time, the deployed version, failures and fixes. If a critical buyer route fails, use the recovery plan you agreed. Restoring an old version can affect new orders or submissions, so the decision needs someone responsible for that data.
6. Monitor with the same questions and reporting settings
After launch, check important URLs in Search Console and monitor indexing, search clicks and landing pages. Compare equivalent periods and filters, with business seasonality in mind. If enquiries matter, verify that measurement and the enquiry route both still work before interpreting a change in enquiry totals.
Investigate a missing page or wrong destination promptly. A short-term movement in average position alone does not establish that the redesign succeeded or failed. Google has to recrawl changed pages, and other changes in demand or content can affect the comparison. There is no reliable universal recovery date to promise.
Ask for a handover containing the old URL inventory, final redirect map, launch checks, known issues, recovery instructions and a named person for follow-up. The redesign cost guide helps separate these tasks when comparing scopes. If the project specifically involves leaving a hosted builder, also read what you can keep when leaving Wix or GoDaddy.
My acceptance question would be simple: can a buyer use an important old link and still complete the intended task? Keep the evidence for that answer alongside the new design.
