A redesign is not ready because the homepage looks finished. Agree which pages and contact routes must keep working, who checks them and how the previous version can be restored if a serious problem appears.
Inventory before replacing anything.
List current service, location, team and contact pages. Include useful documents and pages receiving search visits or external links where data is available. Record appointment tools, telephone destinations and the existing analytics setup.
For each item, decide to keep the address, move it to a relevant replacement or retire it. A short site can use a simple worksheet. Do not wait until launch to discover an old treatment page has no place in the new structure.
Map changed URLs to relevant pages.
Google's site-move guidance recommends a URL mapping and relevant permanent redirects when addresses change. Sending every old page to the homepage is not a replacement plan. A moved branch page should reach its real replacement, where one exists.
Test actual old URLs, not merely the presence of a redirect rule. Check loops, chains and missing destinations. Keep useful addresses unchanged where appropriate, but do not treat unchanged URLs as a substitute for checking content and contact links.
Separate preview from public controls.
A preview may intentionally use noindex. Identify which public pages should become indexable and which private or preview routes must remain excluded. Check metadata and response headers; one setting does not describe every layer.
Confirm canonical addresses, sitemap and intended public domain. Preserve Search Console verification. Google notes processing a move takes time and rankings can fluctuate. Submitting a sitemap helps discovery, but does not guarantee immediate indexing or retained positions.
Test reception with the clinic.
Inspect call, map, messaging and form destinations on a phone. Use staging or an approved labelled test for form receipt and booking integrations. Do not create false patient appointments as a convenient launch test.
Check patient-facing feedback and the receiving system. A success banner does not prove reception received a request. If the site only requests appointments, it must not imply a time is confirmed. Use the form acceptance checklist for that distinction.
Agree cutover and rollback.
Name who approves launch, who deploys and who checks clinic facts. Keep a tested backup and clear restore steps. Decide which failures stop launch, such as a broken appointment route, instead of debating them under pressure.
Where practical, separate major changes rather than changing domain, publishing system and design together. Google recommends changing one thing at a time in site moves. The sequence depends on the project; the goal is to make failures easier to identify and undo.
Check again after switching.
Open public URLs, repeat agreed contact tests and confirm analytics receives intended pageviews. Identify internal QA traffic rather than presenting it as customer interest. Review Search Console and relevant errors over time; the first successful response does not complete a search migration.
Keep an issue log with page, symptom, owner and next check. A technically successful launch can still have stale details. Our redesign brief and quote checklist help include this work in scope before a supplier starts.
Launch sign-off sheet
- Important old URLs have a keep, move or retire decision.
- Canonical, sitemap and header/meta indexing rules checked on public URLs.
- Clinic-approved contact and receipt tests passed for each relevant branch.
- Location, team and service facts approved.
- Backup, restore steps, launch owner and stop conditions recorded.
- Analytics QA identified and an aftercare owner named.
Source notes
Platform guidance checked 18 October 2026. Checklists are Wellfront recommendations, not ranking, booking, clinical or legal guarantees.