Migrating a medical practice website without losing useful URLs
Start a medical practice website migration with an inventory of the existing URLs and a decision for each useful page. Record what should stay at the same address, what needs a new destination and what should be retired. Keep that inventory through testing and launch so the team can check what happened to the pages people already use.
A redesign creates plenty of visible decisions: navigation, photography, page layouts and typography. The migration plan covers another set of decisions that can be easy to miss during design reviews. An appointment link may be printed on a referral sheet. A location page may be bookmarked by a patient. An old service page may still receive inquiries. Include those journeys in the brief.
This guide describes how Health Site Works recommends organizing that work for a public marketing website. The examples are hypothetical planning examples, not client results. No migration plan can promise unchanged search rankings, and a successful launch needs evidence from the actual website.
Define what is moving
List the changes before choosing the launch sequence. Are you changing the domain, the platform, the content structure, the design or several of these together? Name the current and intended systems, including the appointment destination, marketing forms and content editor. Then identify which changes are essential to this release.
Google’s guidance on site moves with URL changes recommends changing one thing at a time where possible. It also explains that rankings can fluctuate while Google recrawls and reindexes a site. Use that guidance when discussing sequencing, rather than treating launch day as proof that search performance has settled.
Our planning recommendation is to give each proposed change an owner and an acceptance check. For example, a new content editor needs an editing demonstration. A changed inquiry form needs a complete submission test. A URL change needs an agreed destination and a tested response. Combining them in a single project does not make their acceptance criteria interchangeable.
Record the launch decision maker, the person responsible for technical release and the person who can approve content changes. Agree how the team will handle a failed critical check. That decision should be understandable before anyone changes a live setting.
Build the URL inventory
Ask the delivery team to gather the current website’s discoverable URLs and combine them with the information your organization already holds. Useful inputs include the CMS page list, existing sitemaps, analytics landing pages, Search Console page data and a crawl of the public site. Each source can reveal something another source misses.
Add addresses used outside the website: campaign landing pages, QR-code destinations, referral materials, directory listings and links maintained by partner organizations. Ask the people responsible for these channels which destinations are still in use. A page with little measured traffic may still support an important task.
Keep the inventory in one shared working document. For each address, record its current purpose, proposed treatment, intended destination and reviewer. Include a short reason for retiring or combining content. A blank row should mean a decision remains open, rather than permission for the page to disappear.
| Inventory field | What to record |
|---|---|
| Current address | The exact existing URL |
| Visitor task | The information or action the page supports |
| Proposed treatment | Keep, move, combine or retire |
| Destination | The intended page, or an explicit retirement decision |
| Acceptance | Reviewer, test result and unresolved issue |
Decide how to handle documents and downloadable files as well as ordinary pages. If a PDF is linked from correspondence, changing the navigation will not update that correspondence. Identify who owns the file and whether the existing address should remain usable. Keep sensitive or private materials out of a public migration inventory.
Give each page a decision
We use four plain-language treatments when reviewing an inventory. They help the organization discuss the content before the technical team implements the destination behavior.
- Keep the address
- Move the page
- Combine useful content
- Retire with a reason
Keep the address when the existing page still serves its purpose and the new structure can support it. A redesigned page does not need a different URL merely because its layout changes. Ask the team to distinguish design preferences from requirements that actually depend on a new address.
Move the page when a new address is necessary and there is a clear replacement. For a hypothetical practice, an old location page might move into a more consistent location structure. Record the relationship explicitly so the developer and content reviewer are testing the same destination.
Combine useful content when several old pages will become one more complete page. Review the old pages individually before signing off the replacement. Check whether each visitor task still has an answer. A combined page that drops location-specific details may look tidier while making the website less useful.
Retire with a reason when the information is no longer appropriate and there is no relevant replacement. Have the responsible person approve that decision. Ask the implementation team to explain the intended response for retired addresses instead of sending every removed page to the homepage by default.
Check the destination, then the redirect
A migration map should connect each changing old URL to its intended destination. Google’s site-move documentation describes preparing that mapping and using server-side permanent redirects for a permanent move. The technical implementation should be reviewed against the current guidance and your specific hosting setup.
Begin your own acceptance review with the destination’s meaning. Does the page answer the same visitor need? If a hypothetical visitor follows an old address for a particular location, confirm that the destination identifies that location and offers the relevant next step. A technically successful redirect can still send someone to an unhelpful page.
Then have the delivery team test the response and final destination. Ask for a report that shows the original address, each response in the path and the page reached. Investigate loops, unintended destinations and redirects that add unnecessary intermediate steps. Retain the tested mapping with the release record.
Update links inside the new website to the intended destinations as part of the content review. Check navigation, related-content links, buttons and document links. Where a third party controls a useful old link, assign someone to request an update. Keep a record of the request rather than assuming it happened because the new site launched.
Preserve useful information during redesign
For each important page, compare the existing information with the proposed replacement. A design mockup may use abbreviated text that is suitable for reviewing layout but incomplete for publication. Make the final content review a separate step with a named approver.
For a practice website, the review might cover service descriptions, provider information, location details and the route to an existing appointment service. For another healthcare business, it might cover product explanations, audiences and inquiry paths. Use the actual organization’s content responsibilities rather than a generic checklist alone.
Identify claims that need review by the responsible subject-matter expert. Preserve approved factual meaning when rewriting, and record any information the team cannot confirm. A migration should not quietly turn an uncertain service description into a stronger claim simply because the new page has room for a shorter headline.
Check page titles, descriptions, headings and image alternatives alongside the visible body. Assign ownership for missing material, including original photography or approved diagrams. If the team proposes removing a resource because it is difficult to migrate, evaluate its usefulness before accepting the shortcut.
Test the complete visitor path
Choose representative journeys and write down the expected result. Our suggested starting sequence is:
- Open an existing URL
- Reach the intended page
- Complete the next action
- Verify the saved result
For an inquiry journey, submit clearly labeled test information and confirm the durable record reaches the intended system. Check any staff notification separately. A success message in the browser proves that a message appeared; it does not, on its own, prove that the team can retrieve the inquiry.
For appointment journeys, verify the handoff to the agreed service without creating an unwanted real appointment. Decide with the relevant provider how a test should be conducted. Include the path back to the website where that is part of the intended experience.
Repeat representative checks on a smaller screen and using a keyboard. Review menus, form labels, error messages and visible focus. Ask the team to document the accessibility checks it performed and the issues still open, rather than treating a screenshot as a complete usability review.
Give release-critical failures a clear response. If the main inquiry cannot be saved, the team should know who investigates and who decides whether to delay or reverse the release. Keep the previous configuration and the intended recovery steps available to the people responsible for launch.
Check search settings and measurement
Ask the technical team to review the public release’s crawl settings, index directives, canonical URLs and sitemap. Google’s canonicalization documentation explains the signals used to indicate a preferred URL among duplicate or similar pages. Have the team check that the signals in the new implementation point to the intended public addresses.
Google’s sitemap overview describes how sitemaps help search engines discover content, while making clear that submitting one does not guarantee crawling or indexing. Include sitemap verification in the release checks, then use Search Console to observe what happens after launch.
Our measurement recommendation is to save a dated baseline before the move. Record available search clicks and impressions, relevant landing-page activity and successfully captured inquiries. Write down known limitations, such as missing historical events or a recent change in tracking. A baseline with disclosed gaps is more useful than a precise-looking comparison built from different definitions.
Agree on the event that represents a successful inquiry and test that event in the new implementation. Keep test activity distinguishable from genuine demand. When reviewing results, consider whether a measurement change could explain the difference before attributing it entirely to the redesign.
Assign the post-launch review
Launch handoff should include a named owner for unresolved migration issues and an agreed review schedule. Keep the URL inventory, test evidence, release details and access instructions together. The next person investigating a broken path should not have to reconstruct the migration from messages.
Review reported errors alongside real visitor journeys. Investigate important pages that lead to the wrong destination, failed inquiries and missing content promptly. For search performance, use comparable reporting windows and acknowledge the site’s traffic volume and any seasonal context. Small counts and short periods call for cautious interpretation.
Turn each material finding into an assigned action with a checkable outcome. For example, an incorrectly mapped location URL can be corrected and retested against its approved destination. A traffic decline needs investigation before someone promises that another design change will fix it.
If you are preparing a migration, bring your existing domain, intended platform, URL inventory and known integrations to the first discussion. Our website services include migration planning within an agreed scope, and our proposal approach explains how requirements shape the quote. You can share your project with Health Site Works even if some of the technical decisions are still open.