To migrate or redesign a website without losing SEO, crawl and benchmark the old site, map every old URL to its new equivalent with server-side 301 redirects, keep content and metadata at parity, launch from a noindexed staging site, then resubmit sitemaps and monitor 404s and traffic for several weeks. Google’s own site-move documentation says that for a medium-sized site it can take a few weeks or more for Google to show the new URLs, so a short, temporary fluctuation is normal. A lasting drop almost always traces back to missing redirects, lost content or a forgotten noindex tag.
What counts as a website migration?#
A website migration is any change that alters the URLs, platform, structure or domain that search engines have already indexed. In SEO terms, these all count:
- Redesign with new URLs, for example a new menu structure that renames pages.
- Platform change, such as moving a legacy ASP.NET or Umbraco site to WordPress, a common project for Jordanian and Gulf companies.
- Domain change, such as a rebrand or moving from a .com to a .jo or .sa domain.
- Adding a language, for example introducing /ar/ and /en/ folders on a previously English-only site.
- Protocol or host change, such as HTTP to HTTPS or a new hosting provider.
Google’s guidance is to make these changes one after the other, not all at the same time: move the domain first, then change the layout. Combining everything in one launch makes any drop hard to diagnose.
The 2026 migration checklist at a glance#
| Phase | Typical timing | Key tasks | Done when |
|---|---|---|---|
| 1. Baseline | 2–4 weeks before launch | Full crawl, Search Console and analytics exports, top pages and backlinks | Every indexable URL is listed with its traffic and links |
| 2. URL mapping | During build | Old-to-new map, 301 rules, decisions on removed pages | Every old URL has a destination or a deliberate 404/410 |
| 3. Staging | During build | Password or noindex, content parity, internal links, canonicals, hreflang | Staging crawl matches the baseline |
| 4. Launch | Launch day | Deploy, remove noindex, live robots.txt, test redirects, submit sitemaps, Change of Address if needed | Sample URLs return 200 or a single 301 |
| 5. Monitoring | Weeks 1–12 after launch | 404s, Page indexing, Performance, rankings, conversions | Traffic and indexing back to baseline |
| 6. Maintenance | At least 12 months | Keep redirects and old domain, update external links | Old URLs no longer receive search traffic |
Phase 1: Pre-migration crawl and baseline#
A baseline is a snapshot of how the current site performs, used to prove the new site is at least as good. Before anyone touches the design:
- Crawl the whole site with a crawler and export every URL, status code, title, meta description, H1, canonical and hreflang tag.
- Export Search Console data: top pages and queries from the Performance report, plus indexed pages.
- Export analytics: landing pages, sessions and conversions, including form submissions and WhatsApp clicks.
- List pages with backlinks, because these carry authority you cannot afford to lose.
- Record Core Web Vitals for key templates so you can compare speed after launch.
Google also recommends pulling old URLs from sitemaps, server logs and the CMS, including images and PDFs.
Phase 2: URL mapping and 301 redirects#
URL mapping is a spreadsheet that pairs every old URL with the most relevant new URL. It is the single most important document in any migration. Google’s site-move guidance sets the rules:
- Use server-side permanent redirects (301 or 308). Google states permanent redirects do not cause a loss in PageRank.
- Redirect one-to-one to the closest equivalent page. Google warns against redirecting many old URLs to one irrelevant destination such as the homepage, which might be treated as a soft 404.
- Avoid redirect chains. Point old URLs straight to the final destination, and update old redirects from previous migrations.
- Return 404 or 410 for content you are deliberately not migrating.
Bilingual sites need extra care. Arabic URLs can arrive percent-encoded or decoded, so redirect rules must match both forms, and every Arabic page must map to the new Arabic page, not to the English version.
Phase 3: Build on a staging site with noindex#
Staging is a private copy of the new site used for building and testing, and it must stay out of Google. Google’s documentation recommends password protection to keep private content out of search, and notes that a noindex rule only works if the page is not blocked by robots.txt, because Googlebot has to crawl the page to see the tag. For most WordPress builds we combine HTTP authentication with a site-wide noindex.
Content parity#
Content parity means every page that ranked before still exists after launch with equivalent text, headings, metadata and media. Redesigns often lose rankings when a long service page becomes a short, image-led layout. Each mapped page should keep:
- Its title tag, meta description and H1, unless you are deliberately improving them.
- Its main body copy, FAQs and structured data.
- The full Arabic translation, not just a translated header and footer.
Internal links, canonicals and hreflang#
Google advises updating internal links to point directly at the new URLs rather than relying on redirects, giving every new page a self-referencing canonical, and updating hreflang annotations to the new URLs. On a bilingual site, the Arabic and English versions of each page must reference each other’s new addresses, or Google will ignore the pairing.
Prepare the production robots.txt and a list of templates where noindex must be removed, as Google recommends. In our audit work, a staging noindex left on after go-live is one of the most common reasons a site vanishes from search.
Phase 4: Launch day#
- Choose a quiet period. Google suggests timing the move for lower traffic where possible, so avoid launching just before Ramadan campaigns, White Friday or your own peak season if those are your busiest weeks.
- Deploy, remove staging password and noindex, and publish the production robots.txt.
- Test a sample of old URLs from the mapping: each should return one 301 to a page that returns 200.
- Submit the new XML sitemap in Search Console. Google recommends also keeping the old-URL sitemap submitted for a while so you can watch those URLs being redirected.
- Request indexing for key pages with URL Inspection.
- Re-check analytics, conversion tracking, forms and WhatsApp buttons.
Changing domain? Use the Change of Address tool#
The Change of Address tool in Search Console tells Google you are moving a whole domain to a new one. According to Google’s help page, you must own both properties, set up 301 redirects first, and keep the redirects for at least 180 days, longer if the old URLs still get Google traffic. Google shows the move notice for 180 days. The tool works at domain level only, and Google says not to use it for an HTTP-to-HTTPS move, a www to non-www change or a hosting change without new URLs.
Phase 5: Monitor 404s and traffic for weeks#
Google’s site-move guide says that ideally traffic on the old site goes down while traffic on the new site goes up, and that medium-sized sites can take a few weeks or more to see the new URLs fully shown. Check at least weekly for the first two to three months:
- Page indexing report: new 404s, “Redirect error”, “Soft 404” and “Excluded by noindex tag”.
- Performance report: clicks and impressions by page, compared with your baseline.
- Crawl stats and server logs for error spikes.
- Analytics: organic landing pages and conversions.
- Backlinked pages: each should redirect to a live, relevant page.
A temporary dip that recovers within those weeks is normal. A drop that keeps falling, or one concentrated in the Arabic folder, means comparing the live crawl against the URL map immediately.
Phase 6: Keep redirects for the long term#
Google recommends keeping redirects for generally at least one year, and says keeping them indefinitely is reasonable from a user’s perspective. Renew the old domain and ask partners and directories to update their links.
Jordan and GCC considerations#
- Bilingual URL changes: a move from Latin to Arabic slugs, or the reverse, is a full URL migration and needs its own redirect map.
- Legacy platforms: older ASP.NET sites often use query-string URLs such as
page.aspx?id=12; redirect rules must match the parameters, not just the path. - Personal data: Jordan’s Personal Data Protection Law No. 24 of 2023, which Clyde & Co reports took effect on 17 March 2024, is a reason to review how form data and backups move between hosts and how consent appears on the new site.
Our website audit and performance team runs the baseline crawl and post-launch checks, our SEO specialists build and test the URL map, and our WordPress developers handle platform moves on staging without touching your live site until launch.
Planning a redesign, a platform change or a new domain? Consult One in Amman can plan and run the migration end to end, from baseline to 90-day monitoring. Get a free quote for your migration plan.
FAQ#
Will I lose SEO rankings if I redesign my website?
Not if the migration is planned. Rankings are lost when URLs change without 301 redirects, when content or metadata is removed, or when a staging noindex tag stays on after launch. Keep URLs where possible, redirect every changed URL to its closest equivalent, preserve content parity and monitor Search Console for several weeks after launch.
How long does it take for SEO to recover after a website migration?
Google’s site-move guidance says a medium-sized site can take a few weeks or more before Google shows the new URLs, and larger sites take longer. A temporary fluctuation in that window is normal. If traffic is still falling after about two to three months, compare the live site against your URL map for missing redirects or lost content.
Should I use 301 or 302 redirects for a site migration?
Use permanent server-side redirects, 301 or 308, for a migration. Google states that permanent redirects do not cause a loss in PageRank and signal that the new URL should replace the old one in search results. Keep 302 redirects for genuinely temporary moves, and avoid client-side or JavaScript redirects unless there is no server-side option.
Can I redirect all old pages to the homepage?
No. Google warns that redirecting many old URLs to one irrelevant destination such as the homepage can confuse users and might be treated as a soft 404, so the old page’s value is not passed on. Redirect each old URL to its closest new equivalent, and return a 404 or 410 for content you are deliberately removing.
When should I use Google’s Change of Address tool?
Use it only when you move a whole site from one domain to another, for example after a rebrand. You must own both properties in Search Console and have 301 redirects live first. Google says not to use it for HTTP-to-HTTPS moves, www changes or hosting changes. Keep redirects for at least 180 days, ideally a year or more.
How do I keep a staging site out of Google?
Protect the staging site with a password, which Google recommends for keeping private content out of search, and add a site-wide noindex as a second layer. Do not rely on robots.txt alone, because a page blocked by robots.txt cannot show Google its noindex tag. Remove both protections, and check the live robots.txt, on launch day.
