A website migration is the moment most UAE businesses lose ground in search, and not because migrations are inherently risky. It is because most teams skip the website migration SEO checklist until the problem already shows up in Search Console. Dominate Online has rebuilt and replatformed sites where one missed redirect on launch day cost three months of recovered rankings. The fix is sequencing: map every URL, write the redirect plan, benchmark the current state, then move the site, never the reverse.
Why migrations collapse rankings when nothing about the business changed
Google re-crawls and re-evaluates every URL on a migrated site as though it were new. A dropped redirect, a changed URL structure, or a staging robots.txt left live after launch all read the same way to a crawler: the old page is gone and the new one has no history attached to it. Rankings do not carry over automatically. They carry over only through signals a team deliberately preserves during the move.
Sites that come through a replatform unscathed treat the migration as its own SEO project with a timeline and an owner, not as a side effect of a rebrand or a developer’s platform choice.
The website migration SEO checklist starts with a full URL map
Every indexed URL on the current site needs a destination on the new one, matched one to one wherever the content genuinely overlaps. Pull the list from Search Console’s indexed pages report, the current XML sitemap, and a full crawl of the live site, then reconcile all three against each other. A URL that shows up in Search Console but not in the crawl is often an orphaned page still earning impressions, exactly the kind of page a rushed migration drops without anyone noticing.
Where no genuine equivalent exists on the new site, decide now whether that page gets rebuilt, folded into a broader page, or retired properly. Leaving that decision until after launch means guessing under pressure with the site already live.
Write a one-to-one 301 redirect plan, not a blanket rule
A single rule that sends every old URL to the new homepage looks finished on a project plan but destroys the relevance signal Google needs to carry rankings across. Each redirect should point to the specific new page that replaces the old one’s content, in a single hop. Avoid redirect chains: old URL to an intermediate URL to the final destination loses equity at every step and slows crawling.
Test every redirect before launch, not after. A redirect plan that only exists in a spreadsheet has not actually been tested, and the gap between the two shows up fastest on the pages that earn the most traffic.
Lock down the staging environment’s robots.txt before cutover
Staging sites get indexed more often than most teams expect. Sometimes a Disallow: / line meant for staging survives the copy to production and blocks the new live site from Google entirely. Sometimes it runs the other way: production’s open robots.txt gets copied to staging, and Google indexes the test environment instead of the real one. Confirm which robots.txt file is live on which domain in the final hour before cutover, not the week before.
Benchmark the current site before anyone touches it
Record current rankings, organic traffic, indexed page count, and Core Web Vitals before migration day. Without a documented starting point, a post-migration drop is impossible to size accurately or explain to a client or a board, and recovery work has nothing concrete to aim at.
Google Search Central’s own guidance on site moves with URL changes sets out the same order: prepare the new site fully, map every URL, then move, rather than migrating first and patching problems as they surface.
The pre-launch checklist, in order
- Full crawl of the current site reconciled against Search Console and the sitemap
- One-to-one redirect map for every URL with a genuine new destination
- Redirects tested in a staging environment, not assumed from the spreadsheet
- Robots.txt confirmed correct on both staging and production domains
- Rankings, traffic, indexation and Core Web Vitals recorded as the before state
None of these steps is difficult on its own. What causes the ranking loss is skipping one under deadline pressure, usually the redirect testing or the robots.txt check, because both feel like formalities until the week after launch proves otherwise.
What to check in the first 30 days after launch
Monitor Search Console’s Page Indexing and Coverage reports daily for the first week, then weekly for the rest of the month. Watch for a spike in 404s, which usually means a missed redirect. Watch for a drop in indexed page count, which usually means a noindex tag or canonical left over from staging. Watch for any URL still serving the old site’s content, which is a caching or DNS propagation issue rather than an SEO one, but looks identical in the reports until it is diagnosed.
A migration that holds its rankings at the 30-day mark rarely did so by luck. It held them because the mapping, the redirect plan and the benchmark were done before launch, not patched together after traffic had already dropped.
Dominate Online plans and runs site migrations and replatforms for Dubai and UAE businesses without the ranking collapse that usually comes with a rebuild. See Dominate Online’s technical SEO service for how a migration audit fits alongside ongoing technical work. For related reading, see how schema errors get caught before Google finds them, or check what actually belongs in an XML sitemap before rebuilding one for the new site.