Dental website migration checklist: keep useful pages and contact routes working

Before replacing a dental website, list the pages, contact routes and account access the practice needs to keep. A redesigned homepage does not establish that an old treatment link still works or that appointment requests reach reception. Agree what will stay, what will move and who will check the result before scheduling the change.

1. Establish what is changing

Separate the design, hosting, domain and page-address decisions. Google's migration guidance distinguishes hosting changes that preserve visible URLs from moves that change them. Ask your provider which kind of change the proposal includes. A different layout does not automatically require a different address for every page.

Record who controls the domain, hosting, website files, practice email and any appointment service. Agree the access needed and arrange it through the appropriate account process. Do not place passwords or patient records in a project brief. Keep a recoverable copy of the existing website and configuration, and name the person who can restore it if an agreed launch check fails.

2. Build an inventory around real practice tasks

Collect current page addresses from the website and any available sitemap or reporting tools. Add important links that reception, practice emails or printed material use. Review more than the homepage: a new patient may arrive directly on a treatment, practitioner or contact page. Where traffic evidence is unavailable, mark it unknown and have the practice identify operational priorities.

• Information: treatment explanations, team profiles, first-visit instructions, fees where published and location details.
• Actions: click-to-call links, appointment requests, directions and any existing booking-service connection.
• Documents and assets: downloadable forms, images and other files the practice still wants visitors to reach.
• Ownership: the person who confirms each item's accuracy and whether it belongs in the new release.

The practice should approve clinical wording and practitioner credentials before they are reused. Migration is also an opportunity to flag outdated hours, departed team members or missing permissions. Reusing a page because it exists is different from confirming that its content is current.

3. Give each old URL an explicit decision

For each address, record the current page, the proposed destination, whether the URL stays or changes, the reason and the person approving it. For a permanent URL change, Google's redirect guidance recommends a permanent server-side redirect where possible; HTTP 301 and 308 indicate a permanent move. Have the developer test the actual response and destination.

Google advises mapping moved pages to relevant replacements, avoiding chains and avoiding a blanket redirect of unrelated old pages to the homepage. Update internal links and canonical references to the chosen destinations. Its move guidance recommends retaining redirects generally for at least a year. Include ownership and maintenance of those rules in the handover.

Some material may no longer have a useful replacement. Make that a deliberate content decision, with the appropriate missing-page response agreed by the developer, rather than promising that every retired URL will lead to the homepage. Keep the URL map available after launch so reception and the website maintainer can investigate an old link.

4. Test the contact journey in the private preview

Review approved pages on desktop and mobile, then follow the contact actions as a visitor would. Confirm that a phone link contains the intended number, directions point to the actual clinic and a booking link reaches the correct practice. Check the form's validation and acknowledgement wording. A request should not imply a confirmed appointment unless the real scheduling system confirms it.

Agree a clearly labelled internal form test with reception and verify receipt in the intended inbox. A success message alone is not evidence of inbox delivery. Test the published form again after launch because preview and production configurations can differ. Keep QA messages out of genuine enquiry totals, and do not use real patient information for a website-delivery test.

Use the Polar Bear Dental concept alongside this guide to discuss page hierarchy and contact placement. It is a design demonstration, not an existing clinic system or evidence that a commissioned booking integration has been connected. Record which features in your own preview are live, simulated or still awaiting access.

5. Name launch checks and the people responsible

Choose the change window with the practice and its technical provider. Keep the launch checklist short enough to use: approved page content, working priority links, correct contact details, confirmed form routing and an agreed fallback. Record who can make the launch decision and who will be available to correct a problem. A date on a proposal is not a substitute for checking these dependencies.

For hosting changes, Google's guidance includes testing the new infrastructure and preserving Search Console verification. Its launch checks also cover removing temporary indexing blocks when the site is ready. Ask the provider to check HTTPS, the public canonical URLs, robots and indexing directives, analytics consent behaviour and the sitemap. Have the account owner confirm which DNS changes are intended so unrelated practice email settings are not changed casually.

6. Example: a contact-page change needs more than a new menu label

Imagine a fictional single-location practice whose old Contact page is at /find-us and whose proposed rebuild uses /contact. The old address also appears in the practice's first-visit email. This is an illustrative planning example, not a client migration or evidence of improved enquiries.

• Practice manager: confirms the clinic address, phone, hours and which inbox handles requests.
• Designer and developer: agree whether changing the URL is necessary, then document and test the chosen route.
• If the address changes permanently: test the old URL's redirect to /contact and update the first-visit email's link.
• Reception: confirms receipt of a labelled production test; the approver records that the agreed launch checks passed.

7. Monitor the move and keep the handover usable

After launch, review broken links, delivery errors, Search Console reports and analytics for a stated period. Record actual dates and distinguish a live page, a submitted sitemap and a Google-indexed URL. Google's site-move guidance notes that search visibility can fluctuate while changes are processed; a provider should not promise unchanged rankings or immediate indexing.

Keep the approved URL map, account ownership, test evidence and maintenance contact together. Decide who handles a failed form or an old link reported by reception. Compare genuine enquiries with delivery records, excluding QA and spam; a page view or click is not a confirmed appointment.

For a First Look Sites preview discussion, share the current website, practice location and the pages or contact tasks that must survive the rebuild. Keep your fuller inventory ready for the scope conversation. The private dental preview route lets us review dependencies and agree migration work in writing before a release is scheduled.