Dental website migration SEO: rebuilding your practice site without losing rankings
On this page
Dental website migration SEO is the work of moving a practice to a new site, new design, new platform or new domain without losing the search visibility the old site earned. Does redesigning a website lose SEO rankings? It doesn't have to. It usually happens because the old URLs were never mapped to the new ones, content was cut, or tracking broke and nobody noticed for weeks.
Rebuilds lose rankings for known reasons, and each stage, before, on and after launch, has its own checks, including what to do if your traffic has already dropped. They make up the checklist I run on every rebuild, whoever builds the site. Migration is one part of the complete guide to SEO for dental practices.
Why rebuilds lose rankings
A search ranking is attached to a specific URL and what is on it. A rebuild usually changes both. Here is what commonly goes wrong.
| Cause | What happens | How it shows up |
|---|---|---|
| No redirects | Old URLs return a "not found" error | Treatment pages drop out of results; links from other sites now point at errors |
| Redirects to the home page | Every old URL sends visitors to the home page | Google does not treat it as the same content; rankings for specific treatments fade |
| Temporary redirects | 302 or 307 used instead of 301 or 308 | Old URLs linger in results; signals move slowly or not at all |
| Content cut | Long treatment pages replaced with short designer copy | Pages still exist but rank for less |
| Structure changed | Treatment pages moved deep into menus or merged | Internal links that carried weight are gone |
| Staging left open or blocked | A test site indexed, or the live site launched with "noindex" still on | Duplicate content, or the whole site disappears |
| Tracking lost | Analytics or conversion tags not carried over | The drop cannot be measured, so it is noticed late |
Google says it expects some ranking fluctuation while it recrawls and reindexes a moved site1. That is normal and short-lived when the move is done properly. A rebuild that ignores the list above turns a fluctuation into a loss.
Before you rebuild
This is where the work is. Most of the damage is decided before a designer opens a file.
1. Inventory the old site. Crawl it with a site crawler and export every URL. Add URLs from Search Console (pages with impressions), analytics (pages with visits), your XML sitemap, and any backlinks tool you use. The union of those lists is the URL inventory. Keep it; it's the only record of what the old site was once it's gone.
2. Mark what matters. For each old URL, record its organic clicks and impressions for the last 12 months, the enquiries it produced, and whether other sites link to it. These are the pages you can't afford to lose.
3. Build the redirect map. Google's guidance is to map old URLs to new ones and use server-side permanent redirects where technically possible1. My method:
| Old URL | New URL | Match type | Redirect | Notes |
|---|---|---|---|---|
| /implants.html | /dental-implants/ | Same content | 301 | Keep full content |
| /blog/implant-cost-2021/ | /dental-implants/cost/ | Merged into better page | 301 | Carry over the useful sections |
| /services/whitening/ | /teeth-whitening/ | Same content | 301 | |
| /offer-summer/ | /teeth-whitening/ | Closest relevant | 301 | Expired offer |
| /team/dr-old-associate/ | /team/ | Closest relevant | 301 | Associate has left |
| /tag/news/ | none | No equivalent | 410 or 404 | Deliberately retired, logged |
The table rows are illustrative. The rules I apply:
- One to one wherever possible. Each old page redirects to the single new page that best replaces it.
- Closest relevant, never the home page by default. If a page has no direct equivalent, send it to the nearest topic.
- No chains. Old URL to final URL in one step, including any old redirects from previous sites.
- Permanent only. Google treats 301 and 308 as permanent and 302, 303 and 307 as temporary2.
- Retire deliberately. Pages with no value and no equivalent can return a 404 or 410, but only as a logged decision.
4. Protect content parity. Content parity means the new page says at least what the old one said, if the old one ranked. Design can change. The substance, headings and answers that earned the ranking stay unless there's a reason to cut them.
5. Build on staging, hidden. A staging site is the test copy of the new site. Keep it behind a password so it can't be indexed, and test the redirect map against it.
6. Record the tracking baseline. List every analytics tag, conversion action, call-tracking script and booking-tool event on the old site, and what each one counted last month. You will compare against this after launch.
Launch day
Launch day is for switching things on in the right order and checking them straight away.
| Step | Check |
|---|---|
| Remove the staging password and any noindex setting | Live pages return 200 and are indexable |
| Deploy the redirect map on the server | A sample of old URLs, including the top 50 by traffic, each land on the right new page in one hop |
| Update internal links | Links point directly at new URLs, not at redirects1 |
| Publish the new XML sitemap | Submitted in Search Console1 |
| Domain change only: use Search Console's Change of Address tool | Google recommends it when moving between domains or subdomains1 |
| Carry over tracking | Analytics, conversion tags, call tracking and booking events fire on the new site |
| Test enquiries end to end | A test form, call and booking each appear where they should |
After launch
The first weeks after launch are for watching and fixing. Google says a medium-sized site can take a few weeks or more to be reflected in results1.
- Watch Search Console daily for the first fortnight. Look for rising "not found" errors and pages dropping out of the index.
- Compare against the baseline. Organic clicks, enquiries and conversions per page, old site against new.
- Fix redirect gaps as they appear. Old URLs you missed will show up as 404s in Search Console and your server logs.
- Keep the redirects. Google advises keeping them as long as possible, generally at least one year1. I leave them in place indefinitely; they cost nothing.
- Keep old tracking numbers working. Numbers printed on leaflets and directories keep ringing for years.
If traffic has already dropped
If a rebuild has already happened and traffic fell, recovery is usually possible if the cause is mechanical. It starts with reconstructing what the old site was.
- Recover the old URL list. Search Console keeps performance data by page for a period; export every page from before the launch. The Internet Archive may also have copies. Old sitemaps, analytics exports and backlink tools fill the gaps.
- Test every old URL. Find which return errors, which redirect to the home page, and which redirect temporarily.
- Map and redirect. Apply the same method as above, prioritising pages that had the most clicks and enquiries.
- Restore content. Where a new page is much thinner than the old one, rebuild the substance from the archived version.
- Fix tracking first if it's broken. Otherwise you can't tell whether the recovery is working.
- Log what you changed and when, then compare in Search Console over the following weeks.
I can't tell you how much will come back or how quickly. That depends on how long the errors were live and what else changed. What I can say is that nothing comes back until the old URLs point at the right pages.
A rebuild is often the moment a practice also changes supplier. If that is your situation, read how to leave an agency without losing your site, accounts or data before the handover. If you're still deciding whether you need a new site at all, start with a site that carries the strategy. The wider organic picture is on the dental SEO page.
For a rebuild you're planning, or one you're recovering from, email Fayez@imfayez.com with the old and new web addresses; the first look is free.
Sources
-
Google Search Central: Site moves with URL changes, accessed 1 October 2026. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
-
Google Search Central: Redirects and Google Search, accessed 1 October 2026. ↩