Clinic site migration: how to prevent ranking loss
A clinic site migration guide to prevent organic loss: pre-launch inventory and mapping, redirect rules, a launch-day checklist and eight weeks of monitoring.
By Roozbeh Nazari · CEO
Most of the clinic websites we work with get rebuilt every few years: a new design, a new CMS, sometimes a new domain and very often a new language structure. Our observation is that a meaningful share of these rebuilds end with organic traffic dropping in the weeks after launch; sometimes it comes back, sometimes it does not. This article walks through what a clinic site migration needs before launch, on launch day and in the weeks after, in the order we apply it as an agency, so that the ranking loss never becomes permanent.
First, a frame. Google's site-move documentation says that for a migration with URL changes, a medium-sized site can take a few weeks or more before the new URLs gradually replace the old ones. So some transition turbulence is normal; what is avoidable is the loss that becomes permanent because of broken redirects, lost pages and damaged language signals. For clinics the distinction matters even more, because most treatment pages took a long time to rank and are expensive to win back.
Before launch: inventory and mapping
A migration's fate is largely decided before launch. The first job is a complete URL inventory of the current site: the pages in the sitemap, the pages that received clicks in Search Console over the last twelve months, the URLs Googlebot visited according to the log file, and the URLs that have external links. These four lists are never identical; an old campaign page that is missing from the sitemap but still gets traffic, or a PDF that is only reachable through an external link, will be missing from the redirect table if it is missing from the inventory.
The second job is to assign a target to every old URL. The rule is simple but frequently broken in practice: the target must be the closest page in content, not the homepage. Redirecting a removed treatment page to the homepage is close to a soft 404 in Google's eyes, and for the user it is a screen where they cannot find what they came for. For pages with no real equivalent, an honest 404 or 410 is better than a 301 to the wrong target.
The third job is the multilingual structure. On a clinic site with Turkish, English, Arabic and Persian pages, every old language variant has to redirect to the new variant in its own language; an Arabic page landing on a Turkish target breaks both the user's journey and the hreflang cluster. Verify on staging, before launch, that the new site's hreflang tags are reciprocal; Google's documentation states plainly that tags which do not point back to each other are ignored. We collected the most common failures in the hreflang errors article.
The fourth job is crawling staging as if it were live. Before launch, crawl the new site end to end with a crawler and compare three lists: pages that exist on the old site with no equivalent on the new one, pages on the new site whose internal links still point to old URLs, and pages with an empty title or meta description. Internal links pointing at old URLs push every click through a redirect after migration; Google tolerates it, but the site's own links going straight to the new target is cleaner for both crawling and users.
Redirect rules: one hop, permanent, server-side
Google's redirect documentation makes the order of preference clear: server-side permanent redirects (301 or 308) are the most reliable method; meta refresh and JavaScript redirects only when server-side is not possible. We still find JavaScript redirects on clinic sites, usually because the old site was built with a page builder and nobody has server access. In that case it is better to plan the migration so that it includes moving to an infrastructure where server-side redirects are possible.
The second rule is to avoid chains. If the old site already carries redirects left over from a previous migration, the new rules should replace them rather than stack on top of them; chains from A to B to C consume crawl budget and risk signal loss at every hop. Google's documentation recommends keeping chains as short as possible. The third rule is not to remove the redirects: the same document advises keeping them for at least a year. Even after a year, any URL with external links should keep its redirect.
If the domain is changing, use the Change of Address tool in Search Console; its help page says it is only for domain or subdomain moves and does not work for path changes within the same domain. It is also not used for HTTP-to-HTTPS or www changes.
Launch day: the checklist
- Confirm that the noindex and robots.txt block from staging did not travel to production; this is still the most painful cause of migration losses.
- Fetch every URL in the old sitemap and record its status code and target; if the split between 200, 301 and 404 does not match expectations, roll the launch back.
- Submit the new sitemap and keep the old sitemap reachable for a while; Google will recrawl the old URLs from it and see the redirects.
- Test by hand, in all four languages, that canonical tags point to the new URLs, that the hreflang clusters are complete and that the language switcher goes to the right page.
- Check that GA4 and the tag manager work on the new site and that form and WhatsApp conversion events are firing; if measurement is broken you cannot even see the loss.
After launch: what to watch, and for how long
We run a monitoring routine that is daily for the first two weeks and weekly for the six weeks after. Three things are watched: the "page with redirect" and "not found" counts in Search Console's page indexing report; clicks and impressions per page in the performance report; and the number of Googlebot requests to old URLs in the log. If requests to old URLs are falling and impressions for new URLs are rising, the transition is progressing. If impressions fall and do not recover, work through the diagnosis in the order described in the indexing problems article.
Two things are also often confused. The first is changing content at the same time as the migration: if titles, copy and internal links all change on the same day, you cannot tell whether the drop came from the URL change or the content change. Where possible, move the URLs first and leave the content revision for a few weeks later. The second is the performance effect of the redesign: if the new theme increased image weight and script load, the drop in Core Web Vitals data shows up with a delay of a few weeks and gets mistaken for a migration effect.
All of this is a standard part of a technical SEO project; in projects where only the design agency runs the migration, most of the items on this list get skipped, because a designer's job is what is visible, not the redirect table.
Conclusion
Loss during a clinic site migration is not inevitable; almost every case where it became permanent traces back to avoidable mistakes such as an incomplete inventory, wrongly targeted redirects, broken hreflang and a noindex that shipped to production. Finishing the mapping table before launch, measuring status codes on launch day and monitoring regularly for eight weeks afterwards is the known way to keep the transition turbulence temporary.