Clinic website migration testing checks whether a planned move preserves the pages and functions visitors need. A new host, a different CMS or a changed domain can affect more than the homepage. Enquiry forms, old links, images and search signals may behave differently even when the design appears unchanged.
This guide focuses on the testing and handover around a technical move. It complements a redesign brief but does not repeat the broader decision about what content to keep. Start with the actual changes being proposed, then build checks that can demonstrate whether those changes work.
Describe what is moving
Write a short scope statement: hosting only, domain change, CMS change, URL change or a combination. Different changes create different dependencies. A server move with stable URLs is not the same task as rebuilding the site under a new address.
List what should remain available, including public pages, uploaded files, appointment enquiry routes and administration access. Identify connected services such as email and payment workflows without assuming they move automatically. Give each dependency an owner who can explain how it will be checked.
Build a representative test inventory
Include the homepage, service pages, doctor profiles, articles, location pages and contact form. Add examples with images, long content or special layouts. A single successful homepage request does not establish that the rest of the site survived.
Use real public URLs from the current site. Record the expected result for each test rather than simply writing “check website.” Where the move changes a URL, identify the intended replacement. Keep private administration and personal data out of public test records and shared screenshots.
Establish a baseline before the move
Save the important URLs and note how the current functions behave. Confirm where enquiries arrive and how staff recognise a successful submission. If there are known faults already, record them so the team does not mistakenly attribute every issue to the migration.
Retain an appropriate backup and make sure the responsible developer knows how recovery would work. Having a backup file and having a tested restoration process are different things. Decide which failures would justify postponing launch and who has authority to make that decision.
Test the new environment privately
Use a suitable preview or staging arrangement to inspect the new site before public launch. Protect that environment appropriately and make its indexing intentions explicit. Do not assume a preview address is private merely because it is unfamiliar.
Check that links in the preview do not accidentally send users back to the old production environment. Test forms using approved sample data and distinguish test notifications from genuine enquiries. Record what was tested, by whom and which version was used so later changes do not invalidate the evidence silently.
Verify changed URLs deliberately
When addresses change, compare the old URL inventory with the new destinations. Google provides guidance for site moves with URL changes, including planning URL mappings and monitoring the move.
Do not send every retired page to the homepage simply to avoid an error response. A redirect needs an appropriate destination. Test important mappings directly and look for loops or unnecessary chains. If URLs are not changing, confirm that the move has not accidentally introduced new paths through a CMS default.
Check indexability after launch settings change
Preview protections and launch settings need separate attention. A site may look normal to a visitor while retaining an unintended instruction that discourages indexing. The developer should inspect response codes, canonical URLs and relevant indexing controls on the public version.
Verify the sitemap contains the intended public addresses and that internal links use the preferred destinations. These checks are technical evidence, not a guarantee of immediate indexing. Record unresolved issues clearly instead of marking the move complete because a browser can display the homepage.
Follow an enquiry from start to finish
Submit a test enquiry with approved fictional details and confirm where it appears. Check the visitor confirmation, staff notification and any supported CRM handover. A message saying “sent” in the browser is not proof that reception received the request.
Test validation and an expected failure case as well as a successful submission. Confirm that mobile users can complete the form and that the confirmation accurately describes the next step. Avoid testing with real patient information or making a live booking that staff could mistake for a genuine appointment.
Inspect images and mobile layouts
Open pages that use different image types and crops. Check whether uploaded media still resolves after path changes and whether image descriptions remain attached. Look at the page on a phone as well as a desktop display.
Pay attention to menus, tap targets and content pushed outside the screen. A cached desktop view can hide a broken mobile asset. Where performance is part of the move's scope, compare meaningful measurements under comparable conditions rather than claiming improvement from a different testing device or network.
Rehearse a fictional launch decision
Imagine a clinic's new host serves most pages correctly, but test enquiries do not reach reception. The launch team should treat that as a functional problem even if the design review is complete. A pre-agreed decision rule prevents pressure to declare success prematurely.
The developer investigates delivery, repeats the end-to-end test and documents the outcome. If a reliable fix is not available within the agreed window, the owner uses the prepared postponement or recovery plan. This scenario is illustrative and does not describe a Doctor Promotion migration result.
Monitor after the change
Reserve time after launch to review errors, incoming enquiries and search reporting. Some problems appear only under real traffic or after cached information expires. Give staff a clear route for reporting a broken page with its URL and observed behaviour.
Do not interpret every short-term traffic fluctuation as proof of a technical failure or a successful move. Compare the technical evidence with relevant reporting windows and known external changes. Keep the previous environment available only as appropriate for the agreed recovery and security arrangements.
Ask for a testable handover
The final handover should identify the changed infrastructure, retained access, test results, known limitations and maintenance responsibility. It should also explain who manages renewals and how future faults reach the right person.
Doctor Promotion's technical SEO support can be scoped around the public URL and indexing checks associated with a move. Use the contact page to describe the existing platform and proposed change. A migration brief is stronger when it asks for evidence of working behaviour rather than a generic “SEO safe” label.
Create a launch sheet with one row for each critical behaviour and three separate fields: expected result, observed result and reviewer. For an enquiry test, name the actual destination that must receive the record. For a changed URL, record its exact final destination. Leave a failed check visibly open until it has been repeated successfully. This makes the launch decision reviewable and reduces reliance on a verbal assurance that someone has checked everything. Keep the test data fictional and remove temporary public test material appropriately.
Frequently asked questions
Does a hosting move require new page addresses?
Not necessarily. Confirm the intended setup with the developer. Stable URLs reduce one category of change, but forms, files, certificates and server behaviour still need testing.
Can a backup replace pre-launch checks?
No. A backup supports recovery, while testing helps find faults before visitors encounter them. The team should know both how the new version was checked and how recovery would be handled.
Will rankings remain exactly the same?
No responsible migration plan can promise unchanged rankings. Testing reduces avoidable technical mistakes and supports monitoring. It does not control every search-system decision or eliminate all temporary variation.