Inventory the existing site before changing it
A redesign can improve the way a business presents itself while accidentally breaking a useful page, a saved link or an enquiry journey. Before drawing the new page structure, list the existing URLs and what each one does. Include service pages, articles, downloadable files and older pages that still receive visitors.
For each URL, decide whether it stays, moves, merges into a relevant replacement or is removed. Record the decision beside the new page destination. This creates a shared reference for content, development and launch review rather than leaving redirects to the final hour.
Give moved pages a relevant destination
When a page moves permanently, plan an appropriate permanent server redirect to its new equivalent. A service page should lead to the corresponding service information, not automatically to the homepage. Google’s site-move guidance recommends preparing a URL mapping and avoiding many unrelated old URLs redirecting to one destination.
If there is no useful replacement for removed content, decide that explicitly rather than masking the missing page with a generic redirect. Test the old URLs as direct requests, including the variants your previous site used. A route that works through the new menu may still fail when opened from an old bookmark.
Review the page content as well as the route
Check that each important new page explains its purpose, has a descriptive heading and title, and links to the next useful action. Confirm that contact information and project claims are current. A redesigned page should retain the information a visitor needs rather than relying on animation to carry the explanation.
Review internal links against the final URL structure. Update canonical URLs and the sitemap to the chosen public addresses. Ensure preview or staging restrictions are handled deliberately at launch and that private environments remain protected. Treat these as release checks with an owner, not assumptions.
Run a launch rehearsal
Build the production version and test representative pages on the intended hosting configuration. Open internal URLs directly, refresh them and follow old URLs through their redirects. Check that a missing page returns the correct status instead of a successful homepage response.
Walk through the enquiry process on mobile and desktop, including validation and what actually happens after the primary button is pressed. Check keyboard navigation and reduced-motion behavior. Agree a backup and recovery plan with the person responsible for deployment before replacing the live files.
- Important new URLs load directly and after refresh.
- Mapped old URLs reach the intended replacement.
- Missing pages and missing files return appropriate errors.
- Navigation, contact links and enquiry journeys work.
- Production sitemap and canonical URLs use the public domain.
- Deployment ownership and recovery steps are documented.
Keep checking after the new site is live
Confirm the live pages and sitemap before using Search Console to inspect important URLs. Watch for unexpected missing pages and redirect problems, and compare visitor journeys with the launch checklist. A sitemap helps discovery; it does not guarantee that every submitted page will be indexed.
A change to URL structure can cause temporary search fluctuations while Google processes the move. Keep the mapping available for follow-up checks and avoid treating launch day as the end of the project. Your first review should ask whether visitors can still find the information and complete the tasks the site was built to support.