A website migration keeps its rankings when every URL that earns traffic or links has a planned destination, one permanent redirect to it, and updated canonicals, hreflang, internal links and sitemaps. Benchmark before you change anything, test redirects on staging, use Change of Address only for domain moves, and watch Search Console closely after launch.
The checklist at a glance
- Decide what kind of migration this is.
- Crawl the current site.
- Export Search Console, analytics and link data.
- Record a baseline.
- Map every old URL to a new one.
- Build one-hop permanent redirects.
- Update canonicals, hreflang and internal links.
- Prepare old and new sitemaps.
- Test everything on a protected staging site.
- Launch, then test redirects and tracking on the live site.
- Submit a Change of Address if the domain changed.
- Monitor daily, then weekly, and fix what slips.
Most of the work sits in steps 2 to 9, before anyone touches DNS. The sections below go through each one, including what tends to go wrong. If you’d rather hand the whole thing over, migrations are part of our website design and development work.
1. What kind of migration is it?
A migration is any change that alters URLs, content, templates or hosting across a site. The type decides how risky it is and whether Google’s Change of Address tool applies at all.
| Migration | Do URLs change? | Change of Address tool? | Main risk |
|---|---|---|---|
| New domain (example.com to example.ae) | Yes, all of them | Yes | Lost link signals, slow reprocessing |
| HTTP to HTTPS | Protocol only | No | Mixed content, redirect chains |
| www to non-www, or back | Hostname variant | No | Chains and duplicate versions |
| New platform or CMS | Usually | No, if the domain stays | Different URL patterns, lost metadata |
| Redesign with a new structure | Often | No | Content cut, pages merged badly |
| Hosting or CDN change only | No | No | Downtime, crawlers blocked by a firewall |
| Merging two sites | Yes, for one of them | Possibly | Overlapping topics, mapping gaps |
| Adding language folders such as /ar/ | New URLs added | No | Missing or broken hreflang |
Most projects we’re asked about sit in rows four and five, often both at once: a new design on a new platform. That’s the riskiest combination, because URLs and content change on the same day and nobody can tell which one caused a drop.
2 to 4. Crawl, export and benchmark before you change anything
You can’t protect what you haven’t listed. Before design starts, crawl the live site, export its search and analytics data, and write down a baseline, so that after launch you can tell a real drop from normal noise.
Crawl the site. Every URL with its status code, title, canonical, hreflang, word count and internal links. Include images, PDFs, and anything in the XML sitemap that the crawler couldn’t reach through links.
Export what you’ll need later. Search Console performance by page and by query, the Links report (top linked pages and top linking sites), and analytics landing pages with their key events. Search Console doesn’t keep history forever, and the old site’s analytics setup may not survive the rebuild, so save it now.
Record the baseline. Indexed pages in the Page indexing report, clicks for your top pages, Core Web Vitals, and screenshots of the main templates. Note how many enquiries a week the site produces today.
The output is a spreadsheet with one row for every URL that has any value: traffic, links, enquiries, or a reason a customer might have bookmarked it.
5. Map every old URL to a new one
Every valuable old URL gets exactly one destination: its direct equivalent where one exists, the closest relevant page where it doesn’t, and a 404 or 410 when nothing on the new site fits. Sending everything to the home page is not a plan.
Google is direct about this. In its site move guide it says redirecting many old URLs to one irrelevant destination such as the home page can confuse users and might be treated as a soft 404. The visitor lands somewhere that doesn’t answer their question, and the old page’s signals go nowhere useful.
We went through this on our own site. An older version of vdesignu.com had thousands of thin, near-duplicate pages, and retiring them meant deciding where every one of them should go. None went to the home page. Each points at its closest real parent: the city-and-service page where we’d written one, otherwise that city’s hub, otherwise the service page itself. A script generates the redirect file from the same content files that build the pages, so a redirect can’t point at a page that doesn’t exist, and every target is the final URL with its trailing slash, so there’s never a second hop.
Writing the rules once as logic, instead of thousands of hand-typed lines, is what made that manageable. For a smaller site, a spreadsheet is enough. Our bulk URL mapper turns old-path and new-URL pairs into a clean CSV you can review and hand to a developer.
6. Build one-hop permanent redirects
Use server-side permanent redirects, 301 or 308, from each old URL straight to its final destination. Google’s redirects documentation recommends a permanent server-side redirect whenever possible and treats JavaScript redirects as a last resort, because rendering can fail.
What goes wrong at this step:
- Chains. Old URL to an interim URL to the final one. Google’s crawlers follow up to 10 redirect hops, but every hop slows visitors down and adds one more thing to break. If the old site already had redirects, rewrite those rules to point at the new final URLs too.
- Defaults. Some platforms issue a temporary redirect unless told otherwise. On Cloudflare Pages, a
_redirectsrule without a status code defaults to 302, and the file is capped at 2,000 static and 100 dynamic rules. Our own build fails on purpose if the generated file goes over either limit. - Variants. Redirect both the slash and no-slash forms, uppercase versions if the old server accepted them, and the http and www versions of everything.
- Query strings. Decide whether parameters such as
?page=2or old product IDs need rules of their own.
Generate the rules in whatever format your server reads. Our 301 redirect code generator writes Apache and Nginx rules, and there’s a separate builder for Netlify-style _redirects files. Everything else we’ve built for this job is on the redirects and migrations tools page.
Then keep the redirects. Google says to keep them as long as possible, generally at least a year. We have no plans to remove ours.
7. Update canonicals, hreflang and internal links
Redirects catch links from other sites. Everything you control should point straight at the new URLs: each new page carries a self-referencing canonical, the hreflang in every language version lists the new URLs, and internal links skip the redirect entirely.
Google’s site move guide asks for all three. Canonicals matter because Google weighs signals when choosing which URL to index, and its canonicalization guide ranks them: redirects and rel=“canonical” are strong signals, sitemap inclusion a weak one. A new page that canonicalises to an old URL, which then redirects back to the new page, sends two strong signals that contradict each other. It happens more often than you’d think when templates are copied from the old site.
On bilingual sites, hreflang is where migrations break quietly. Both the English and the Arabic versions move, the English tags get updated, and the Arabic ones still point at old addresses. Google ignores hreflang without return links, so both languages lose their pairing. Our hreflang setup for Arabic and English sites covers the codes and structure.
8. Prepare old and new sitemaps
Build two XML sitemaps: one listing the new URLs, and one listing the old URLs that now redirect. Submit both in Search Console after launch. The old-URL sitemap gets Google recrawling the old addresses and finding the redirects, and the new one lets you watch the new pages being picked up.
Google describes exactly this setup: initially the sitemap of new URLs shows zero pages indexed, and the sitemap of old URLs shows many. The numbers swap over as the move is processed. Once they have, drop the old-URL sitemap. Leave the redirects.
9. Test everything on a protected staging site
Put staging behind a password, not just a robots.txt block; Google’s canonicalization guide warns that URLs disallowed in robots.txt can still be indexed without their content. Then crawl staging the way you crawled the live site, and check:
- Every mapped URL returns a 301 to the right destination, in one hop.
- Titles, headings and main copy on the pages that ranked survived the redesign.
- Canonicals, hreflang and structured data use production URLs, not staging ones.
- Analytics and key events fire on forms, calls and WhatsApp taps.
- Templates pass Core Web Vitals in mobile lab tests.
Content cuts are the quieter cause of lost traffic. A service page that ranked on a long, specific explanation gets “refreshed” into three lines and an icon. The redirect works perfectly, and the ranking goes anyway.
Our site migration pre-flight checklist is a quick tick list for this stage.
10. Launch day
Launch early in the working week, when your developers will be around for the days that follow. Then:
- Remove the staging password, any noindex tags and any robots.txt block.
- Test the old URLs of your top pages against the live server. From a terminal:
curl -sI https://example.com/old-service-page/ | grep -iE "^(HTTP|location)"You want a single 301 or 308 status and a location header holding the final URL.
- Check robots.txt and the XML sitemaps on the live domain.
- Confirm analytics and key events are recording real visits.
- Verify the new property in Search Console if the domain or protocol changed, and submit both sitemaps.
11. Change of Address: only for domain moves
Use Search Console’s Change of Address tool when you move from one domain or subdomain to another, and only then. Google’s help page says not to use it for HTTP to HTTPS moves, path changes within a domain, switches between www and non-www, or hosting changes with no visible URL change.
To use it, you need to be an owner of both properties in Search Console, under the same Google account, and the old home page must already 301 to the new home page. Google says the tool’s effect lasts 180 days, so the redirects have to keep working long after that window closes.
12. After launch: what to watch, and for how long
Watch Search Console and your server logs daily for the first two weeks, then weekly for at least two months. Expect some movement. Google says that for medium-sized sites it can take a few weeks or more before new URLs replace the old ones in results, and longer for large sites.
What to look at:
- Page indexing report. New URLs moving into the indexed count, old ones moving to “Page with redirect”.
- 404s. Errors in Search Console and 404s in your server logs show URLs your map missed. Add rules for any that have traffic or links.
- Top pages, one by one. Clicks for each page in your baseline, compared week by week.
- Enquiries. Key events from organic search against the baseline.
What should worry you: new URLs still not indexed after several weeks, one whole template losing traffic while the others hold, or a jump in soft 404s. Those usually point at a pattern problem (a canonical, a stray noindex, a redirect rule) rather than Google being slow.
If you changed domains, keep the old one registered. Letting it lapse breaks every redirect at once, and expired domains get bought and reused by people you’d rather not be connected to.
Mistakes we see on almost every migration
- Design signed off before anyone has listed the URLs that earn traffic.
- PDFs and image URLs left out of the redirect map.
- Staging URLs baked into canonicals or the sitemap.
- Hreflang updated in one language only.
- Tracking removed along with the old theme.
- Redirects deleted a few months later “to tidy up”.
If you’re picking an agency for a rebuild, ask them to walk you through this list before you sign; our guide on what to ask a Dubai web design agency has more questions like it. Our SEO team can also run just the migration alongside whoever builds the new site. Or tell us what you’re moving.