01
Start with what the existing website does
Before choosing a new layout, list the pages customers use and the decisions those pages support. A service page may receive few visits yet be the exact link a prospect needs before requesting a quote. A redesign should preserve useful information and routes, then improve the parts that make the decision harder.
Save a dated baseline: current URLs, page titles, Search Console page/query reports, consented organic landing data and known external links. Separate customer activity from staff tests where the evidence permits. Missing analytics rows are not proof that a URL has never been indexed or has no backlinks.
- Name the main customer and the action they need to take.
- Record the content, domain and hosting owners.
- List pages with enquiries, useful search impressions or known links.
- Agree who approves new copy, media and the launch.
02
Give each old URL an explicit decision
Use one row per existing URL: old URL; customer purpose; observed evidence and date range; keep, improve, merge or remove; replacement URL if equivalent; implementation owner; verification result. This makes the migration reviewable before the old site disappears.
Keep a stable URL when its purpose remains useful. Improve the existing page when the question is unchanged. Merge genuinely overlapping content into its strongest owner and use a permanent redirect. When a page is removed and has no useful equivalent, return a genuine 404 or 410 instead of sending everyone to the homepage.
03
Review the replacement before switching traffic
Use a staging or preview deployment to check content and behaviour without treating it as the public website. Review the homepage and several different page types on a phone: service, project, contact and article. Test the actual contact handoff rather than just checking whether a button looks clickable.
- Check one clear H1, accurate title/description and intended canonical on each page type.
- Check visible text, image descriptions, navigation and accessible form labels.
- Verify that temporary crawl blocks are appropriate on preview and will be removed from production.
- Test successful and failed form submission; confirm receipt without claiming a booked or qualified customer.
- Keep original media and a recoverable copy of the old content.
04
Test responses as well as appearances
A branded error page can look correct while returning HTTP 200. Test the response status of removed URLs and the actual destination of merged URLs. Include old variants that people or search engines may still request, such as extension-bearing paths, when the old site used them.
On this site, stale article responses required a scoped Cloudflare Pages handler that returns no-store 404s before consulting assets. The verification checked 306 removed clean, .html and OG paths plus equivalent redirects. That is a documented solution to this site's release issue, not a universal reason to add a custom handler to every redesign.
- Confirm that the domain serves the intended release.
- Request every old-to-new redirect and verify a useful final page.
- Check the sitemap contains the intended canonical set.
- Keep unknown URLs as genuine errors, not homepage copies.
05
Monitor the move without promising fixed rankings
Google explains that significant site changes can cause temporary ranking fluctuations while it recrawls and reprocesses URLs. A technically correct migration does not guarantee unchanged visibility. Keep Search Console access, submit the appropriate sitemap and watch for unexpected crawl, canonical or server problems.
Compare meaningful periods and customer outcomes. A launch-day traffic change is not enough to diagnose success or failure. Investigate a broken service page or contact path immediately; give indexing and ranking changes enough context before attributing them to the new design.
06
Bring the decision sheet into the redesign brief
The useful handover is a URL ledger, agreed replacement content, redirect ownership, a launch checklist and someone responsible for monitoring. It is easier to price a redesign when the provider can see which pages need preservation, substantial rewriting or a separate integration.
Use the website brief guide to capture those requirements. For a scoped review, discuss your existing website with Project Monet; the review should start from actual URLs and business decisions.
Sources
Primary and supporting sources
Use the linked documentation and labelled build examples to check the evidence. Business examples are planning tools; they do not establish customer outcomes or guarantee search visibility.