Before a clinic website redesign launches, require a URL inventory, a redirect map for changed addresses, a content approval list, tested inquiry routes, and a rollback plan. A visually finished website is not ready if existing search destinations disappear or appointment requests no longer reach the team. The owner does not need to implement every technical change, but should know what the vendor must demonstrate before the launch is accepted.
This checklist applies to the public website, whether you run a medical spa, aesthetic clinic, dental practice, plastic surgery practice, or hair-restoration clinic. Private clinical systems and patient portals need their own controlled migration process.
Name the owner of the launch decision
Assign a practice decision-maker, a technical lead, and the people responsible for clinical content and inquiries. Record who can approve launch, pause it, and authorize a rollback. Avoid a handoff where the designer assumes the owner checked the form and the owner assumes the developer did.
List which systems change: hosting, CMS, domain, URL structure, forms, scheduling integration, analytics, and any third-party tools. A redesign that keeps the same addresses has different risks from a move that changes them.
Use our technical SEO checklist to identify wider dependencies before assigning a launch date.
Copy this migration acceptance checklist
Create an internal launch record with a status, owner, and evidence link for every item:
- Current URL inventory: Important public pages and their purpose are documented.
- New destination map: Each retained or changed page has an agreed final address.
- Redirect evidence: Changed URLs reach the appropriate final destination.
- Content approval: Provider, service, location, fees, and practical information are current and approved.
- Public indexing controls: Production pages have the intended directives and canonicals.
- Navigation and internal links: Important pages remain reachable through real links.
- Mobile inquiry test: A labeled synthetic request reaches the assigned team and produces accurate feedback.
- Telephone and scheduling links: The advertised routes work as described.
- Accessibility checks: Forms and navigation can be used with appropriate keyboard and assistive-technology testing.
- Sitemap and search access: The final public URLs and verified property access are available.
- Data and permissions review: Proposed tracking and inquiry tools have the practice's required approval.
- Backup and rollback: A known recovery point, responsible person, and stop conditions are documented.
Mark unresolved blocking items as hold. Do not convert them to passed because the launch date has arrived.
Inventory pages before the old site disappears
Include public service pages, location pages, provider profiles, contact routes, and articles that still serve a useful purpose. Ask the vendor to identify important existing destinations using available site and search records, not only the navigation menu.
For each URL, decide whether it stays, changes, merges into a genuinely relevant page, or is intentionally removed. The owner and content lead should approve decisions that affect useful practice information.
Do not keep every old page without review, but do not delete one merely because the new template lacks a place for it. Record the reader need and the reason for the decision.
Map redirects to relevant destinations
For addresses that change, ask the vendor for an explicit old-to-new mapping and test evidence. Sending every old procedure page to the homepage does not preserve its purpose.
Google's site-move guidance explains the importance of URL mapping, redirects, updated links, and monitoring. Apply that guidance to the actual scope of the move rather than assuming every redesign needs a domain-change procedure.
Test important old URLs after launch. Confirm they reach the intended final page, not a missing destination, an unexpected login, or a long redirect chain. Retain the mapping so later edits do not silently break it.
Approve the new facts, not only the design
Have the practice verify provider roles, credentials, locations, available services, appointment explanations, and contact coverage. The redesign should not copy outdated information more attractively.
Clinical statements and patient material require the appropriate approval and permissions for the actual use. Keep those checks separate from a designer's confirmation that the text fits the layout.
Review mobile placement of important limits and practical information. A fact present in a desktop sidebar but missing from the mobile route is not consistently communicated.
Test inquiry delivery with invented information
Send a labeled synthetic request from a real mobile browser. Confirm receipt in the intended system, assignment to the responsible role, accurate confirmation, and a usable next step. Verify any scheduling handoff separately.
Do not use a real patient's details to test the site. Avoid creating genuine appointments, treatment records, or marketing subscriptions from the test. Agree how test entries are identified and handled.
W3C's accessible forms guidance covers labels, instructions, validation, and feedback. Ask for relevant technical tests; do not describe a passed form submission as proof of complete accessibility or legal compliance.
Define stop conditions before launch day
Examples include unavailable public pages, accidental indexing restrictions, broken inquiry delivery, incorrect provider information, or exposed private information. Agree which findings require pausing or rolling back, and who makes that decision.
A rollback plan needs more than an old screenshot. Identify the recoverable version, hosting and DNS responsibilities where relevant, dependencies, and what happens to inquiries received during the transition.
Desk-test a hypothetical failure: the new site loads, but a consultation request goes to an unused inbox. The form success message should not make the launch acceptable. Repair delivery or follow the agreed recovery process, then repeat the synthetic test.
Check the sitemap and monitor after launch
Confirm the sitemap contains the intended final public URLs and meaningful modification dates. Google's sitemap guidance describes discovery support, not guaranteed indexing or preserved rankings.
Review important destinations, inquiry delivery, and available search reports after launch. Keep the old-to-new map and a change log. Investigate unexpected errors by URL rather than assuming every short-term traffic fluctuation has the same cause.
If a page is missing from Google, use the indexing diagnostic decision tree before changing content blindly. Our websites and digital experience service supports implementation when the migration needs a coordinated technical owner. The migration acceptance checklist is ungated and usable without hiring us.