A website migration is the single most dangerous event in the life of an organic search channel. Rankings that took years to earn can disappear in a week because of one unmapped URL pattern, one forgotten noindex tag or one redirect rule that sends every old page to the homepage. The cause is almost never Google. It is a missing inventory, a missing map and a missing test plan. This checklist is written for the person who owns the outcome: the marketing director, the hotel group’s digital manager, the developer’s client. It follows the structure of Google’s own guidance on site moves with URL changes and adds the engineering detail that decides whether the plan survives contact with a real server.

What Counts as a Migration

Search engines treat any change that alters URLs, content, rendering or crawlability as a migration. The risk profile differs by type, so name yours before you plan:

Domain change (for example from one brand domain to another): every URL changes, signals must transfer across hosts, and the Search Console Change of Address tool applies.
Protocol change (HTTP to HTTPS) or host change (non-www to www): every URL changes in a mechanical way, which makes it easy to redirect and easy to get wrong in small places such as canonical tags and sitemaps.
URL structure change on the same domain: a new permalink pattern, a new category hierarchy, language folders added or removed. Many URLs change in non-mechanical ways and need a real mapping table.
Platform change (for example a page-builder site rebuilt in custom code): URLs may stay the same, but templates, headings, internal links, structured data, rendering and speed all change.
Redesign without URL changes: the lowest risk, but templates and content can still shift rankings.

Google’s guidance is consistent on one point: change one thing at a time. If you can keep URLs identical while changing the platform, do that first. If a domain change and a redesign are both needed, separate them by enough time that you can attribute any movement to one cause.

Phase 1: Baseline Before You Touch Anything

You cannot prove a migration worked, or diagnose one that did not, without a record of how the old site behaved. Capture this before the first change is made, and store it somewhere that survives the project.

The URL inventory

Build one master list of every URL that exists on the old site. A single source is never complete, so merge several:

The XML sitemaps, including image and language sitemaps.
A full crawl of the live site with a crawler of your choice, following internal links and recording status code, canonical, title, H1, meta robots, hreflang and word count.
Search Console performance data exported by page, covering the longest period available, because pages that earn impressions but are not linked internally will not appear in a crawl.
Server access logs, which show every URL that Googlebot and real users actually request, including old URLs that earn external links.
The CMS database: posts, pages, custom post types, taxonomy archives, attachment pages and author pages.
Backlink data from the Search Console links report and any other tool you use, so you know which URLs have external links pointing at them.

Include images, PDFs and downloadable files. Google’s documentation lists images, videos, JavaScript and CSS among the resources that should be mapped, because image search traffic and rendering both depend on them.

The performance baseline

Export, with dates, the metrics you will compare against after launch:

Clicks, impressions, average position and click-through rate by page and by query from Search Console.
Organic sessions and conversions from analytics, including key events such as enquiry form submissions, booking confirmations, WhatsApp clicks and calls.
Index coverage: how many pages are indexed, and which are excluded and why.
Core Web Vitals field data from Search Console, plus lab results for your ten most valuable templates.
Rankings for the 30 to 50 queries that matter commercially, tracked by country and language.

Rank the URL inventory by value: organic clicks, conversions and backlinks. The top 5 to 10 per cent of URLs usually carry most of the value. Those get individual attention in the redirect map and individual checks after launch.

Phase 2: The Redirect Map

The redirect map is the core deliverable of any URL-changing migration. It is a table with one row per old URL and a destination for each, built on rules a developer can implement and a tester can verify.

Mapping rules that protect rankings

One-to-one by default. Each old URL redirects to the new URL that serves the equivalent content. Equivalence means the same search intent, not the same keyword in the slug.
Merged pages redirect to the merged page. If three thin articles became one strong guide, all three redirect to the guide.
Never redirect everything to the homepage. Google’s guidance warns against sending unrelated URLs to one page. A mass redirect to the homepage is treated as a soft 404 in many cases and discards the relevance of the original page.
Retired content returns 404 or 410. If a page has no equivalent and no value, let it go cleanly, rather than redirecting it to something irrelevant. If it has backlinks, look harder for a genuine equivalent first.
Redirect directly to the final destination. Chains such as old to interim to final waste crawl budget and add latency. Google’s guidance says to keep unavoidable chains short, ideally no more than three hops and always under five. The right target is zero extra hops.
Use permanent server-side redirects. A 301 or 308 status tells search engines the move is permanent. JavaScript or meta-refresh redirects are a last resort.

Pattern rules versus lookup tables

If the change is mechanical, such as moving from /blog/2024/05/post-name/ to /post-name/, write one rule using a regular expression and test it against the whole inventory. If the change is editorial, use a lookup table that the redirect layer reads at request time. For tens of thousands of URLs, avoid thousands of lines in an .htaccess file, since that is evaluated on every request. Prefer a server-level map (Nginx map blocks, Apache RewriteMap with a hashed file) or an application-level redirect table with a cached lookup, and keep the rules in version control.

Details that quietly break maps

Trailing slashes and case. Decide the canonical form and redirect the others to it in one hop.
Query strings. Decide which parameters survive (pagination, filters that create indexable pages) and which are dropped. Tracking parameters should not create new URLs.
Language folders. On a bilingual site, the Arabic and English versions each need their own map, and the mapping must keep language to language. An Arabic URL must not redirect to an English page. Percent-encoded Arabic slugs need to be compared in a normalised form, or the rules will not match what the browser sends. Our guide to multilingual SEO for Red Sea tourism sites covers the hreflang side in more detail.
Pagination and archives. Category, tag and date archives often earn links. Map them or consciously retire them.
Media. If the upload path changes, map image URLs too, or image search visibility resets.
Old redirects. If the old site already had redirects, flatten them: the oldest URL must point to the new final URL directly.

Phase 3: Build and Test on Staging

The new site is built in a private environment, and the private environment must never be indexed. The failure mode is well known: a staging site is blocked with noindex or a robots.txt disallow, the site goes live, and the block goes live with it. Plan for the removal of those blocks as an explicit launch step, and add a test that fails if they are still present.

On-page parity

Compare each high-value old page with its new version. A rebuild often changes things nobody intended to change:

Title tags, meta descriptions, H1 and the heading structure.
Body content, especially text that the new design hides behind tabs, sliders or scripts that render late.
Internal links. Navigation, footer and in-content links should point to final new URLs, not to URLs that redirect.
Canonical tags: each page needs a self-referencing canonical to its new final URL.
Hreflang annotations: updated to new URLs, reciprocal, and including a self-reference.
Structured data: the same types and valid values, with URLs updated.
Image alt text and file names.
Robots meta and X-Robots-Tag headers.

Technical checks

Rendering: use the URL Inspection tool on the live test or a headless browser to confirm that critical content is present in the rendered HTML.
Status codes: run the entire old URL list against the staging redirect rules with a script and assert the expected status and destination for every row. Report failures as a diff, not a feeling.
Speed: compare Core Web Vitals templates against the baseline. A migration that makes the site slower gives back some of what you hoped to gain. See our notes on page speed optimisation for the engineering side.
Server capacity: Google’s guidance asks you to confirm the new server can handle heavier Googlebot crawling after a move, since crawlers revisit many URLs in a short period. Test the redirect layer and the new origin under that load.
Security and HTTPS: valid certificate on every host variant you plan to redirect, HSTS only once you are sure, and no mixed content.
Forms, payments and tracking: submit a real test enquiry, complete a test booking, confirm the analytics events fire once and only once.

Phase 4: Search Console, Analytics and Sitemaps

Do the account work before launch day so that launch day is only execution.

Verify every variant of both old and new properties: HTTP and HTTPS, www and non-www. A domain property covers them in one verification. Confirm the verification method will survive the move: a file or tag on the old server disappears when that server does.
If you moved to a new domain, check the new domain’s history for manual actions or leftover URL removals from a previous owner.
Prepare the new XML sitemap, listing only final, canonical, indexable URLs with accurate last-modified dates.
Keep the old sitemap available for a period after launch so that Google can discover the redirects quickly. Warnings about redirecting URLs in an old sitemap are expected in this period.
Set up analytics so that old and new hostnames can be compared, with annotations for the launch date.
Re-upload any disavow file to the new property if you have one, and match crawl-related settings where they apply.

Phase 5: Launch Day

Choose a low-traffic window, and do not launch on a day when nobody can respond. Google recommends scheduling a move for a period when a temporary dip costs you least. For a Hurghada hotel or dive centre, that means avoiding peak booking weeks; for a B2B exporter, avoid month-end quoting cycles.

Launch sequence

Take a full backup of the old site and database, and confirm that you can restore it.
Deploy the new site and remove every staging block: noindex meta tags, X-Robots-Tag headers, robots.txt disallow rules and password protection.
Activate the redirect rules.
Run the redirect test script against production. Every row must pass.
Spot check the top 50 URLs by hand in a browser, and in the URL Inspection tool, including one Arabic and one English page, on mobile and desktop.
If you changed domain, submit the Change of Address in Search Console for each verified variant of the old property. It applies only to domain or subdomain changes, not to path or platform changes.
Submit the new sitemap.
Update everything you control that links to the old URLs: social profiles, Google Business Profile website link, ad campaigns, email signatures, directory listings and partner sites.
Confirm in analytics that traffic and conversion events are recording on the new site.

Phase 6: The First 30 Days

Expect fluctuation. Google states that a site move can take a few weeks for small and medium sites and longer for large ones, because each old and new URL has to be crawled at least once and the process runs per URL. A temporary movement in rankings does not by itself signal failure. What signals failure is a pattern, and the way to catch a pattern is a monitoring routine with fixed checks.

Daily for the first two weeks

Server logs: Googlebot requests by status code. Rising 404s mean URLs missing from the map. Rising 5xx errors mean capacity problems. A spike of 301s followed by 200s on new URLs is the healthy pattern.
Search Console: the sitemap report and the page indexing report. New URLs should gain indexed counts while old ones decline.
Crawl errors from your own crawler: re-crawl the new site weekly and compare to the baseline for missing titles, wrong canonicals and unexpected noindex.
Analytics: organic landing pages and conversions compared to the baseline period, adjusted for seasonality.

Weekly through day 30

Compare clicks and impressions for the top 5 to 10 per cent of URLs against the baseline.
Check branded and non-branded queries separately. Brand queries recover first; a gap in non-brand queries on the same pages points to content or relevance changes.
Check your tracked ranking set by country and language.
Ask for fixes in priority order: broken high-value redirects, then wrong canonicals, then missing content, then everything else.

Diagnosing a drop

If traffic falls and does not recover, follow the evidence in this order. First, indexing: are the new URLs indexed, and are the old ones dropping out as expected? Second, redirect integrity: are they one hop, 301, and to the correct page? Third, on-page parity: did titles, headings or content change materially? Fourth, rendering: is the content visible in the rendered HTML? Fifth, speed and server errors. Sixth, links: did external links pointing at old URLs get consolidated through redirects, and were internal links updated? Only after those do you look for algorithmic explanations, because the earlier causes are far more common and are fixable.

Keeping Redirects Long Enough

Google’s guidance says to keep redirects in place for generally at least one year. In practice, keep redirects for as long as the old URLs have backlinks or bookmarks. Redirects are cheap to keep and expensive to lose: removing them early turns every old inbound link into a 404. Document the redirect table as part of the permanent site documentation, and make sure a future developer cannot remove the rules without seeing what they protect. If the redirect rules live in a plugin, keep an exported copy of the table outside the site, so that a plugin change or a hosting move does not silently delete it.

Special Cases for Egyptian and Multilingual Sites

Moving between .com and .com.eg: a country-code domain is a geographic signal. If your market is Egypt, check that the new domain’s targeting still fits your audience, and remember that international visitors may trust a .com differently. Decide based on audience data, not preference.
Language switchers: language plugins can create duplicate or conflicting URLs during a migration, such as the default language appearing both with and without a folder. Test every combination, and confirm that hreflang pairs remain reciprocal after the move.
Arabic URLs: a browser shows Arabic slugs, but servers and logs see percent-encoded forms. Test redirects with the encoded form, and decide whether new Arabic pages use Arabic slugs or short Latin ones. Changing the slug policy during a migration creates unnecessary redirects.
Hosting changes: if the migration also moves the origin server, read our comparison of hosting in Egypt or abroad before you pick the location, and lower DNS TTLs a few days ahead so cutover is quick.
Platform changes: moving from a page-builder build to custom code changes templates and rendering. Our WordPress or Laravel guide explains the architectural choices, and the migration plan should treat the new templates as a content parity exercise, page type by page type.

The Pre-Launch Sign-Off List

Treat the following as a gate. If any item is not verified with evidence, the launch waits.

The URL inventory is complete and merged from sitemaps, crawl, Search Console, logs, CMS and backlinks.
Baseline metrics are exported and dated.
Every old URL has a mapped destination or a deliberate 404 or 410.
The redirect test script passes against staging with zero failures and zero chains.
Canonicals, hreflang, structured data and internal links point at final new URLs.
No staging noindex, robots.txt block or password protection remains in the launch build.
The new sitemap contains only final, indexable URLs.
Search Console properties are verified for old and new, and verification survives the move.
Forms, payments, bookings and analytics events pass an end-to-end test.
Rollback is defined: who decides, within what time, and how the old site is restored.
Someone is assigned to the monitoring routine for each of the first 30 days.

Who Should Run It

A migration crosses the boundaries between SEO, development and hosting, and that is where most failures happen: the SEO specialist writes a redirect map that the developer implements differently, and the hosting team caches the wrong thing. One owner should hold the plan, with the redirect map, the test script and the monitoring routine in a single document that all three disciplines sign. Our SEO service and managed hosting teams plan migrations with the redirect test script written before the first redirect rule, because a rule you cannot test automatically is a rule you cannot trust, and a migration is the last place to find that out.

Moving Your Website Without Losing Google Rankings: A Migration Checklist