Will moving my website to a new host hurt my Google rankings?

Not directly, if every URL stays the same. Google treats a hosting or CDN move as a site move without URL changes, and its guidance for that case is about infrastructure: testing the new servers, lowering DNS time to live, making sure Googlebot is not blocked. Google notes it is normal to see a temporary drop in crawl rate right after launch, followed by a steady increase over the next few days. That is crawl rate, not ranking.

Does changing my CMS automatically mean I lose rankings?

No. The platform swap itself is not what Google reacts to. The risk comes from what usually changes alongside it: URL patterns, page titles, structured data, internal links and site speed. A WordPress to Webflow move that keeps every URL identical and carries metadata across is a far smaller event than one that renumbers every page. Judge the risk by how much of the site's address book and markup changes, not by the logo on the CMS.

Why is changing platform and design at the same time such a bad idea?

Because Google advises against it in plain words. Its site move guidance says that if you are also changing your design, information architecture or content, you should make those changes after completing the move rather than at the same time. The practical reason is diagnosis. If URLs, templates and content all change in one launch and traffic falls, there is no way to isolate the cause. You end up guessing, and guessing is slow and expensive.

What does Google actually say happens to rankings during a migration?

Google says to expect temporary fluctuation in site ranking during the move, and that with any significant change to a site you may see rankings move while Google recrawls and reindexes. It calls this normal. What Google does not do is promise there will be no impact, or commit to a recovery date. Fluctuation is described as expected behaviour, not as a failure, and not as something you fix by making more changes.

How long does it take Google to reindex a site after a migration?

Google's own wording is that a small to medium-sized website can take a few weeks for most pages to move in its index, and that larger sites can take longer. It also states there are no fixed crawl frequencies, and that how fast Googlebot crawls depends on the size of your site. That is deliberately unquantified. Treat any confident promise of a specific recovery date with suspicion, because Google itself declines to give one.

Is it true that sites lose a fixed percentage of traffic after a migration?

No official source publishes such a figure. It does not appear anywhere in Google's site move documentation, its redirect documentation, or its Search Console help. The percentages that circulate in this market come from agency marketing content, not from measurement anyone can check. We do not publish one either. A well executed move with a complete redirect map and no other changes behaves very differently from a rushed rebuild, so a single average number would mean nothing.

What is wrong with using a 302 just for launch week?

It tells Google the change might be reversed, so the ranking signal does not reliably transfer to the new address. The bigger problem is that temporary measures become permanent. A 302 put in place on launch night to be tidied up later is very easy to forget, and while it stays there Google may keep showing the old URL. If the move is permanent, say so from the first request rather than correcting it afterwards.

How many redirects can I chain together?

Googlebot can follow up to ten hops in a chain, but that is a technical ceiling and not a target. Google's own advice is to redirect to the final destination directly, and to keep any unavoidable chain short, ideally no more than three and fewer than five. Long chains usually appear by accident, when a CMS plugin rule, a server rule and a CDN rule all fire in sequence. Audit the chain after launch, not just the endpoint.

Can I redirect all my old pages to the new homepage?

Google's documented process points the other way. Creating a URL mapping from old to new is an explicit named step in its five-phase site move process, which implies a page by page decision rather than a blanket rule. A redirect exists to pass a specific page's accumulated signal to its specific equivalent. Sending everything to the homepage discards the specificity that made the redirect worth setting up, and it strands visitors who wanted a particular page.

What should I do with old pages that have no equivalent on the new site?

Google's site move guidance says that if you are not moving all your old content, those URLs should correctly return a 404 or 410 on the new site. Its redirect documentation adds that where a relevant new page does exist, you can add a link pointing to it with a short explanation. Read together: redirect to a real equivalent when there is one, and let genuinely deleted content return an honest error rather than forcing a false match.

Do I need Google's Change of Address tool for every migration?

No. It is specifically for domain and subdomain changes, and it is used after the move and the redirects are already live. Google states it is not used for HTTP to HTTPS moves, for path changes inside the same domain, or for www and non-www switches, which are handled with redirects and canonical tags. A hosting move with no URL change does not need it either. Using it where it does not apply achieves nothing.

What does the Change of Address tool actually do?

It tells Google to emphasise crawling and indexing your new site over crawling your old site, forwards signals from the old domain, and prefers the new domain as canonical. To use it you must own both properties in the same Search Console account, they must be domain-level properties, and a 301 from the old homepage to the new homepage has to be live already. It supports the redirects rather than replacing them.

How long should I keep my redirects live after a migration?

Google recommends keeping them for as long as possible, and generally at least one year, so that all signals have time to transfer to the new URLs. This is one of only two hard durations Google publishes about site moves, the other being the 180-day Change of Address window. Treat one year as a floor rather than a target. If old URLs still receive traffic or still appear in printed material, keep the redirects beyond it.

Should I keep the old domain after a domain migration?

Yes, for a good while. Google recommends holding onto the old domain for around a year, so it cannot be picked up and reused by someone else once you stop pointing it anywhere. The redirects have to live somewhere, and they only work while you control the domain and its DNS. Renewing a domain for another year is one of the cheapest pieces of insurance in a migration, and letting it lapse early undoes the transfer.

What is the most common launch-day mistake that damages a whole site?

Shipping the staging environment's robots.txt or noindex configuration to production. A blanket disallow rule copied from staging stops Google crawling the live site entirely, and it is invisible unless someone checks. The related trap is that Google states a noindex rule only works if the page is not blocked by robots.txt, because a crawler that cannot fetch the page will never see the rule. Check the live robots.txt within minutes of cutover.

Does blocking a page in robots.txt keep it out of Google?

No, and Google says so directly. Its documentation warns against using robots.txt as a way to hide pages from Search, and notes that a page disallowed in robots.txt can still be indexed if other sites link to it. robots.txt manages crawling, not indexing. If a page genuinely must stay out of results, use a noindex rule that Google is allowed to crawl and read, or put the page behind a password.

How should I hide a staging site from Google during a migration?

Use a noindex rule, delivered as a meta tag or an X-Robots-Tag HTTP header, and ideally password protection as well. Google's own site move guidance suggests a temporary test hostname carrying a noindex directive while you test the new infrastructure. Do not rely on robots.txt alone, and be careful not to block the test host in robots.txt and rely on noindex at the same time, because the block prevents Google reading the rule.

What happens to canonical tags during a migration?

They are one of the quiet failure points. Google describes a canonical URL as the one it chooses as most representative from a set of duplicate pages, and treats your rel=canonical annotation as a hint rather than a rule. On a migrated site, pages should carry self-referential canonicals pointing at their own new URLs. Canonical tags left pointing at old domain addresses are common after a platform change and quietly work against your redirects.

Do I need to resubmit my sitemap after a migration?

Yes. Regenerate it so it contains only the new canonical URLs, then submit it through the Sitemaps report in Search Console at or immediately after cutover. Google requires absolute URLs in a sitemap, and caps each file at 50,000 URLs or 50MB, so larger sites will need a sitemap index. An old sitemap still advertising pre-migration URLs pulls against your redirects instead of supporting them.

Does structured data survive a platform change automatically?

Not reliably. Schema markup on most sites is generated by a theme, plugin or template that will not exist on the new platform, so it has to be rebuilt rather than migrated. Google explicitly warns that pages might break after deployment because of templating or serving issues, and recommends validating with the Rich Results Test during development and watching the rich result status reports afterwards. Do both, because a review or FAQ rich result is easy to lose silently.

What is the extra migration risk for a bilingual Arabic and English site?

hreflang has to be reciprocal. Google states that if two pages do not both point to each other, the tags will be ignored. A URL change touches the English and the Arabic address of every pair at the same moment, so one side being updated while the other is missed breaks the whole annotation rather than half of it. On UAE bilingual sites this is the single biggest thing to test before and after cutover.

Does hosting my website inside the UAE affect my Google rankings?

Only indirectly, and this does not change during a migration. Google lists server location among several signals it uses to work out who a site is aimed at, alongside country domains, hreflang, local addresses and local links, and it explicitly ignores geographic meta tags. What actually moves rankings is speed and page experience. A fast site on international hosting with a good CDN can outrank a slow site sitting on a local server.

Should I lower my DNS TTL before a hosting move?

Yes, if the move involves changing DNS records. Google's guidance for site moves without URL changes is to lower the time to live to a conservative low value, giving a few hours as its example, at least a week in advance. That means resolvers pick up the new records quickly at cutover instead of sending some visitors and some crawlers to the old server for a day or more. Raise it again once the move has settled.

How do I check Googlebot can reach my new hosting before cutover?

Use the URL Inspection Tool in Search Console against the new environment before you switch DNS, which is exactly what Google's site move guidance recommends. Check as well that firewall rules or denial-of-service protection on the new infrastructure are not blocking Googlebot from reaching your DNS or your servers. New hosting often arrives with stricter default protection than the old setup, and that protection does not know Googlebot from a scraper.

What should I capture before a migration starts?

A baseline, or you will not be able to judge anything afterwards. Crawl and export every current URL with its status. Record Search Console indexed page counts, at least three months of the Performance report, current sitemap status and Core Web Vitals. Record analytics organic sessions, conversions and top landing pages. Without that snapshot, every post-launch number is unfalsifiable, and normal fluctuation and a real fault look identical.

How do I tell a normal post-migration wobble from a real problem?

A normal wobble looks like gradual movement in both directions across many keywords for a few weeks, while indexed page counts and impressions stay near the baseline. A real fault usually traces to a specific checkable cause: a spike in pages blocked by robots.txt or excluded by noindex, old URLs returning 404 instead of a redirect, or a sustained one-directional collapse that does not ease. Check causes in Search Console rather than watching rank trackers.

Is moving to a .ae domain treated differently by Google?

No. It is a domain change under Google's site move with URL changes process, exactly like any other domain move, with the same redirect map, the same Change of Address submission and the same 180-day window. There is no .ae specific migration route. The .ae namespace is administered by the .aeDA under the TDRA, and first-level .ae registration is open to everybody, with additional eligibility rules on some second-level domains.

How much does a website migration cost in the UAE?

A migration starts from around AED 5,000 and rises with content volume and how much SEO preservation work is involved, with larger replatforms scoped in discovery. The main drivers are the number of URLs to map, whether templates and structured data have to be rebuilt on the new platform, whether an Arabic version is in scope, and whether the move includes a domain change. Final pricing depends on scope.

Should I migrate first and redesign later, even though it costs more?

In most cases yes, and it often costs less than it looks. Google recommends making design, information architecture and content changes after the move rather than at the same time. Two clean launches give you a diagnosable result at each step. One combined launch gives you a single ambiguous outcome and, if traffic falls, an investigation that can run for weeks. The extra launch is usually cheaper than the investigation it prevents.

Web DevelopmentAugust 7, 2026

Website Migration and Replatforming in the UAE: How to Move Without Losing Your Rankings

SKIMBOX Team

Google's own advice on site moves contains one rule almost nobody quotes: do not change several things at once. Here is how to move platform, host, or domain without turning a normal wobble into a drop you cannot diagnose.

Someone has told you the site needs to move. A new platform, a new host, maybe a new domain. And somewhere in that conversation, somebody mentioned the traffic drop. That is usually where the decision stalls, because nobody can tell you how large the drop will be or how long it lasts.

Here is the most useful thing Google publishes about site moves, and almost nobody selling migrations in this market quotes it. In its own guide, Google says: "if you're also changing your site's design, information architecture, or content, we recommend you make those changes after completing the move, not at the same time." [1]

That single sentence is worth more than every migration checklist you will read this week. Move the site. Then redesign it. Changing platform and design together is exactly what turns a normal, recoverable wobble into a problem nobody can diagnose, because when the traffic falls you have no way of knowing which change caused it.

A migration starts from around AED 5,000 and rises with content volume and how much SEO preservation work is involved, with larger replatforms scoped in discovery. This guide covers the move types ranked by risk, redirects done properly, the pre-launch checklist, and what to watch afterwards.

Change one thing at a time

The reason to isolate changes is not superstition. It is diagnosis.

When only the URLs change, the list of things that can go wrong is short and every item is checkable. Redirects are missing, or chained, or pointing at the wrong page, or the sitemap still lists old addresses. You look, you find it, you fix it. When URLs, templates, navigation, titles and half the copy change in one launch, that list gets long enough that testing each possibility takes weeks, and by then the drop has compounded.

Google is direct about what to expect during the move itself. It says to "expect temporary fluctuation in site ranking during the move," and that "with any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site" [1]. That fluctuation is the normal cost of a move. Your job is to make sure it stays fluctuation, and to be able to prove it when someone asks.

So sequence the work. Move the site with the content and structure it already has. Let it settle. Then run the redesign as its own project, with its own baseline. Our website redesign guide covers that second stage, and it makes the same argument from the other direction.

If the real question underneath all this is which platform to move to, decide that before anything else. Our comparison of WordPress, Webflow and Next.js and the Shopify versus WooCommerce versus custom comparison cover that decision properly.

The types of move, ranked by risk

Google splits site moves into two documented categories, and the split tells you almost everything about risk. A move without URL changes is a hosting, server or CDN transfer where every address stays identical [2]. A move with URL changes covers HTTP to HTTPS, domain changes including consolidations, and changes to URL paths [1].

The ranking below is ours, built on that split. Google does not publish a risk ladder.

Move type	What changes	Risk
Hosting or CDN transfer	Servers and DNS, no URLs	Lowest
HTTP to HTTPS, same paths	Protocol only	Low
URL structure change, same domain	Paths and internal links	Medium
Domain change	Every URL, plus domain authority signals	High
Any of the above plus a redesign	Everything at once	Highest, and hardest to diagnose

The bottom row is the one to argue about internally. It is not technically harder than a domain move. It is harder to recover from, because the evidence you need in order to fix it has been destroyed by the launch itself.

One nuance worth knowing: a platform change does not have to be a URL change. Move from WordPress to a new stack and keep every path identical, and you are doing the lowest-risk kind of move with a lot of build work behind it. That is often the right way to plan a replatform.

Redirects, done properly

Redirects are where migrations are actually won or lost, and there are only four rules that matter.

Use permanent redirects. Google recommends "HTTP permanent redirects if possible, such as 301 and 308" for a site move [1]. The distinction matters more than it looks. With a 301, Google states that "the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." With a temporary 302, "Googlebot follows the redirect, but the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical" [3]. A 302 left in place after a permanent move can leave Google indexing an address you have abandoned.

Map every URL individually. Google's five-phase process names "create a URL mapping" as its own step, before execution [1]. That is a spreadsheet job: every old URL, its new equivalent, and a decision for the ones with no equivalent. It is tedious and it is the single highest-value hour of the project. Redirecting an entire old site to the new homepage is the shortcut people take instead, and it throws away the specific page-level signal the redirect existed to carry.

Keep chains short. Googlebot can follow "up to 10 hops in a chain of multiple redirects," but Google advises "redirecting to the final destination directly" and keeping any unavoidable chain to "ideally no more than 3 and fewer than 5" [1]. Chains build up by accident when a CMS plugin rule, a server rule and a CDN rule each fire in turn. After launch, test a sample of old URLs and look at the full hop sequence, not only the final status code.

Be honest about deleted pages. Google's site move guidance says that if you are not moving all your old content, those URLs should "correctly return an HTTP 404 or 410 error response code on the new site" [1]. Its redirect documentation adds that where a genuinely relevant new page exists, you can "add a link pointing to the new page accompanied by a short explanation" [3]. Real equivalent, redirect to it. No equivalent, let it return an honest error. Never invent a match to keep the redirect count tidy.

Then leave the redirects alone. Google's recommendation is to "keep the redirects for as long as possible, generally at least 1 year," because "this timeframe allows Google to transfer all signals to the new URLs" [1]. One year is a floor, not a finish line.

The pre-launch checklist

Most of this list comes straight from Google's two site move documents. The rest is the baseline work that makes the aftermath measurable.

Crawl and export the current site. Every URL, its status, its title and description, its structured data. This is the reference you will compare against for months.
Record the baseline. Search Console indexed page count, three months of the Performance report, sitemap status and Core Web Vitals [12]. Analytics organic sessions, conversions and top landing pages. Without this, no post-launch number can be judged.
Build the URL map. Old to new, every row decided, before development finishes.
Test the new environment before cutover. Google recommends verifying that Googlebot can reach the new infrastructure with the URL Inspection Tool in Search Console, and checking that firewall or denial-of-service protection is not blocking it [2].
Keep the test environment out of the index properly. Google suggests a temporary test hostname carrying a noindex directive [2]. Note the mechanism: "for the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file," because a blocked crawler "will never see the noindex rule" [6]. And robots.txt is not an indexing control at all. Google warns not to use it "as a means to hide your web pages from Google Search results," since a disallowed page "can still be indexed if linked to from other sites" [5].
Check the production robots.txt within minutes of launch. A blanket disallow copied from staging is the classic launch-night disaster, and it is silent.
Point canonicals at the new URLs. Google chooses a canonical from several signals and treats your rel=canonical as "a hint, not a rule" [7]. Self-referential canonicals on the new site, and no leftovers aimed at the old domain.
Rebuild and revalidate structured data. Schema on most sites comes from a theme or plugin that will not exist on the new platform. Google warns that "pages might break after deployment due to templating or serving issues" and recommends the Rich Results Test before launch and the rich result status reports after [11].
Regenerate and resubmit the sitemap. New canonical URLs only, absolute addresses, submitted in Search Console at cutover. Google caps each file at 50,000 URLs or 50MB, so larger sites need a sitemap index [10].
Lower the DNS TTL a week ahead if DNS is changing. Google's advice is to lower it "to a conservative low value (for example, a few hours) at least a week in advance" [2].
Submit the Change of Address, if it applies. Only for domain and subdomain moves, only after the redirects are live.

Bilingual sites: the reciprocity trap

If your site runs in English and Arabic, one item on that list carries more risk than the rest.

hreflang is bidirectional. Google states plainly that "if two pages don't both point to each other, the tags will be ignored" [8]. Not degraded. Ignored. A URL change moves the English address and the Arabic address of every pair at the same moment, which means every single pair is exposed at once, and a partial update breaks the annotation rather than half-breaking it.

The failure is quiet. Google may start showing the English page to Arabic searchers, or treat the two versions as duplicates and pick one. Nothing errors. Test the return tags on both sides of a sample of pairs before cutover and again after, wherever you declare them, whether that is HTML tags, HTTP headers or the sitemap [8].

Our guides to Arabic-first ranking in Google UAE and RTL website design cover the tag set UAE sites usually need.

Domain moves and the 180-day window

If you are changing domain, one extra tool applies. The Change of Address tool in Search Console tells Google to "emphasize crawling and indexing your new site over crawling your old site" and forwards signals from the old domain [4]. You need both properties verified in the same account as domain-level properties, and the 301 from old homepage to new homepage has to be live first.

Google publishes a specific number here: the preferential treatment runs for 180 days. After that, Google "does not recognize any relationship between the old and new sites, and treats the old site as an unrelated site" [4]. So the tool is a boost with an expiry date, and the redirects, which should live at least a year, are what carry the rest. Google also suggests holding the old domain for around a year so it cannot be picked up and reused by someone else [4].

The tool does not apply to HTTP to HTTPS moves, to path changes inside one domain, or to www and non-www switches [4]. Those are redirect and canonical work. Moving to a .ae domain is a domain change like any other, with no special process; .ae is administered by the .aeDA under the TDRA, and first-level registration is open to everybody [13].

What to watch afterwards, and the numbers nobody should quote

Google's five-phase process ends on monitoring, and specifically on monitoring both the old and the new URLs [1]. That second half is what people forget. The old URLs are where you find out whether the redirects are actually firing.

Watch three things in Search Console. First, the Page Indexing report, for a spike in pages blocked by robots.txt or excluded by noindex, which points at a staging configuration that shipped. Second, indexed page counts against your pre-launch baseline. Third, individual old URLs in the URL Inspection Tool, to confirm they return a redirect rather than a 404.

Now the part that most articles get wrong. There is no credible traffic-loss percentage. No Google document states one. Every figure circulating on this topic comes from agency marketing, and we will not add another. There is also no honest recovery timeline. Google's own language is "a small to medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer," and it states flatly that "there are no fixed crawl frequencies; how fast Googlebot crawls depends on the size of your site" [1]. Anyone quoting you a precise recovery date is quoting themselves.

Google publishes exactly two hard durations for site moves: keep redirects for at least one year, and the Change of Address window is 180 days [1][4]. Both describe how long you maintain your side of the move. Neither describes how long Google takes on its. Do not let anyone blur the two.

Hosting location is worth one clarification, because it comes up in every UAE migration conversation. Server location is one of several signals Google uses to work out who a site is aimed at, alongside country domains, hreflang and local content, and Google explicitly ignores geographic meta tags [9]. It is not a ranking factor in its own right. Speed is what matters, which is the same position as our UAE hosting guide [14]. Move hosting for performance and reliability, not for a ranking effect that is not there.

Real client stories

These are anonymised situations from migration work.

The launch that changed everything at once. A UAE business moved from WordPress to a new platform and launched a full redesign on the same night. New URLs, new navigation, new copy, new templates. Organic enquiries fell over the following weeks and nobody could say why. The redirects existed, so the obvious answer was ruled out early, and after that the investigation had no shape: the drop could have been the URL change, the removed pages, the rewritten titles, or the new navigation burying two service pages three clicks deep. It was, in the end, several of those. Splitting the launch would have cost one extra deployment and saved weeks of guesswork.

The staging file that shipped. A site went live on new infrastructure with the staging robots.txt in the deployment. A single disallow line stopped Google crawling the entire live site. Nothing looked broken to anyone using the site, which is why it survived launch checks. It was caught when the Page Indexing report began flagging pages blocked by robots.txt. The fix took minutes. Finding it took far longer, because nobody had opened the live robots.txt after cutover.

The Arabic half that stopped pairing. A bilingual site changed its URL structure and updated the English hreflang references correctly. The Arabic templates kept pointing at the old English paths, so the return tags no longer matched and the annotations were disregarded. Arabic search results started showing English pages. There was no error message anywhere, and the site had passed a visual check on both languages. Testing hreflang pairs in both directions is now the first thing checked on any bilingual move.

How SKIMBOX approaches migrations

We start by asking what is actually changing, and then argue for changing less of it at once. If a replatform can keep its URLs, we keep them, because the safest redirect is the one you never have to write. We build the URL map before development finishes rather than on launch night, capture a full baseline so the result can be measured against something, and treat the redirect audit and the hreflang check as launch gates rather than follow-up tasks. Where a redesign is also wanted, we offer to sequence it after the move, and we will explain why in the proposal rather than after the traffic drops.

A migration starts from around AED 5,000 and rises with content volume and how much SEO preservation work is involved, with larger replatforms scoped in discovery. Final pricing depends on scope. For what the site costs to build and run either side of a move, see our website development cost guide and the real cost of running a website in the UAE.

See our web development services and digital marketing services, or contact us for a plain assessment of what your move actually involves.

References

[1] Google Search Central - Site moves with URL changes. developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

[2] Google Search Central - Site moves without URL changes. developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes

[3] Google Search Central - Redirects and Google Search. developers.google.com/search/docs/crawling-indexing/301-redirects

[4] Google Search Console Help - Change of Address tool. support.google.com/webmasters/answer/9370220

[5] Google Search Central - Introduction to robots.txt. developers.google.com/search/docs/crawling-indexing/robots/intro

[6] Google Search Central - Block Search indexing with noindex. developers.google.com/search/docs/crawling-indexing/block-indexing

[7] Google Search Central - Consolidate duplicate URLs with canonicals. developers.google.com/search/docs/crawling-indexing/canonicalization

[8] Google Search Central - Localized versions of your pages and hreflang. developers.google.com/search/docs/specialty/international/localized-versions

[9] Google Search Central - Managing multi-regional and multilingual sites. developers.google.com/search/docs/specialty/international/managing-multi-regional-sites

[10] Google Search Central - Build and submit a sitemap. developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap

[11] Google Search Central - Introduction to structured data markup. developers.google.com/search/docs/appearance/structured-data/intro-structured-data

[12] web.dev - Web Vitals and Core Web Vitals thresholds (Google). web.dev/articles/vitals

[13] TDRA - About the .ae national domain and the .aeDA. tdra.gov.ae/en/aeda/about-us/about-ae

[14] SKIMBOX - Best web hosting in the UAE, on hosting location and rankings. skimbox.co/resources/blogs/best-web-hosting-uae

Frequently asked questions

Will moving my website to a new host hurt my Google rankings?
Not directly, if every URL stays the same. Google treats a hosting or CDN move as a site move without URL changes, and its guidance for that case is about infrastructure: testing the new servers, lowering DNS time to live, making sure Googlebot is not blocked. Google notes it is normal to see a temporary drop in crawl rate right after launch, followed by a steady increase over the next few days. That is crawl rate, not ranking.
Does changing my CMS automatically mean I lose rankings?
No. The platform swap itself is not what Google reacts to. The risk comes from what usually changes alongside it: URL patterns, page titles, structured data, internal links and site speed. A WordPress to Webflow move that keeps every URL identical and carries metadata across is a far smaller event than one that renumbers every page. Judge the risk by how much of the site's address book and markup changes, not by the logo on the CMS.
What is the difference between a site move with and without URL changes?
Google splits site moves into exactly those two categories, and they have separate documentation. A move without URL changes is a hosting, server or CDN transfer where every address stays identical. A move with URL changes covers HTTP to HTTPS, domain changes including consolidations, and changes to URL paths or structure. The second category is the one that needs a redirect map, and in the case of a domain change, the Change of Address tool as well.
Why is changing platform and design at the same time such a bad idea?
Because Google advises against it in plain words. Its site move guidance says that if you are also changing your design, information architecture or content, you should make those changes after completing the move rather than at the same time. The practical reason is diagnosis. If URLs, templates and content all change in one launch and traffic falls, there is no way to isolate the cause. You end up guessing, and guessing is slow and expensive.
What does Google actually say happens to rankings during a migration?
Google says to expect temporary fluctuation in site ranking during the move, and that with any significant change to a site you may see rankings move while Google recrawls and reindexes. It calls this normal. What Google does not do is promise there will be no impact, or commit to a recovery date. Fluctuation is described as expected behaviour, not as a failure, and not as something you fix by making more changes.
How long does it take Google to reindex a site after a migration?
Google's own wording is that a small to medium-sized website can take a few weeks for most pages to move in its index, and that larger sites can take longer. It also states there are no fixed crawl frequencies, and that how fast Googlebot crawls depends on the size of your site. That is deliberately unquantified. Treat any confident promise of a specific recovery date with suspicion, because Google itself declines to give one.
Is it true that sites lose a fixed percentage of traffic after a migration?
No official source publishes such a figure. It does not appear anywhere in Google's site move documentation, its redirect documentation, or its Search Console help. The percentages that circulate in this market come from agency marketing content, not from measurement anyone can check. We do not publish one either. A well executed move with a complete redirect map and no other changes behaves very differently from a rushed rebuild, so a single average number would mean nothing.
Should I use a 301 or a 302 redirect when I move a page permanently?
A 301. Google states that with a permanent redirect, its indexing pipeline uses the redirect as a signal that the redirect target should be canonical. With a temporary 302, Googlebot follows the redirect but the indexing pipeline does not use it as that signal, so the old URL can stay the one Google indexes. Every redirect in a genuine migration is permanent, so 301 or 308 is the correct choice throughout.
What is wrong with using a 302 just for launch week?
It tells Google the change might be reversed, so the ranking signal does not reliably transfer to the new address. The bigger problem is that temporary measures become permanent. A 302 put in place on launch night to be tidied up later is very easy to forget, and while it stays there Google may keep showing the old URL. If the move is permanent, say so from the first request rather than correcting it afterwards.
How many redirects can I chain together?
Googlebot can follow up to ten hops in a chain, but that is a technical ceiling and not a target. Google's own advice is to redirect to the final destination directly, and to keep any unavoidable chain short, ideally no more than three and fewer than five. Long chains usually appear by accident, when a CMS plugin rule, a server rule and a CDN rule all fire in sequence. Audit the chain after launch, not just the endpoint.
Can I redirect all my old pages to the new homepage?
Google's documented process points the other way. Creating a URL mapping from old to new is an explicit named step in its five-phase site move process, which implies a page by page decision rather than a blanket rule. A redirect exists to pass a specific page's accumulated signal to its specific equivalent. Sending everything to the homepage discards the specificity that made the redirect worth setting up, and it strands visitors who wanted a particular page.
What should I do with old pages that have no equivalent on the new site?
Google's site move guidance says that if you are not moving all your old content, those URLs should correctly return a 404 or 410 on the new site. Its redirect documentation adds that where a relevant new page does exist, you can add a link pointing to it with a short explanation. Read together: redirect to a real equivalent when there is one, and let genuinely deleted content return an honest error rather than forcing a false match.
Do I need Google's Change of Address tool for every migration?
No. It is specifically for domain and subdomain changes, and it is used after the move and the redirects are already live. Google states it is not used for HTTP to HTTPS moves, for path changes inside the same domain, or for www and non-www switches, which are handled with redirects and canonical tags. A hosting move with no URL change does not need it either. Using it where it does not apply achieves nothing.
What does the Change of Address tool actually do?
It tells Google to emphasise crawling and indexing your new site over crawling your old site, forwards signals from the old domain, and prefers the new domain as canonical. To use it you must own both properties in the same Search Console account, they must be domain-level properties, and a 301 from the old homepage to the new homepage has to be live already. It supports the redirects rather than replacing them.
How long does the Change of Address window last?
Google gives a specific figure here: 180 days. During that window it applies preferential crawling and forwards signals from the old site to the new one. After 180 days Google does not recognise any relationship between the old and new sites, and treats the old site as an unrelated site. Anything not transferred by then depends on your redirects continuing to do the work, which is one reason those redirects need to outlive the window.
How long should I keep my redirects live after a migration?
Google recommends keeping them for as long as possible, and generally at least one year, so that all signals have time to transfer to the new URLs. This is one of only two hard durations Google publishes about site moves, the other being the 180-day Change of Address window. Treat one year as a floor rather than a target. If old URLs still receive traffic or still appear in printed material, keep the redirects beyond it.
Should I keep the old domain after a domain migration?
Yes, for a good while. Google recommends holding onto the old domain for around a year, so it cannot be picked up and reused by someone else once you stop pointing it anywhere. The redirects have to live somewhere, and they only work while you control the domain and its DNS. Renewing a domain for another year is one of the cheapest pieces of insurance in a migration, and letting it lapse early undoes the transfer.
What is the most common launch-day mistake that damages a whole site?
Shipping the staging environment's robots.txt or noindex configuration to production. A blanket disallow rule copied from staging stops Google crawling the live site entirely, and it is invisible unless someone checks. The related trap is that Google states a noindex rule only works if the page is not blocked by robots.txt, because a crawler that cannot fetch the page will never see the rule. Check the live robots.txt within minutes of cutover.
Does blocking a page in robots.txt keep it out of Google?
No, and Google says so directly. Its documentation warns against using robots.txt as a way to hide pages from Search, and notes that a page disallowed in robots.txt can still be indexed if other sites link to it. robots.txt manages crawling, not indexing. If a page genuinely must stay out of results, use a noindex rule that Google is allowed to crawl and read, or put the page behind a password.
How should I hide a staging site from Google during a migration?
Use a noindex rule, delivered as a meta tag or an X-Robots-Tag HTTP header, and ideally password protection as well. Google's own site move guidance suggests a temporary test hostname carrying a noindex directive while you test the new infrastructure. Do not rely on robots.txt alone, and be careful not to block the test host in robots.txt and rely on noindex at the same time, because the block prevents Google reading the rule.
What happens to canonical tags during a migration?
They are one of the quiet failure points. Google describes a canonical URL as the one it chooses as most representative from a set of duplicate pages, and treats your rel=canonical annotation as a hint rather than a rule. On a migrated site, pages should carry self-referential canonicals pointing at their own new URLs. Canonical tags left pointing at old domain addresses are common after a platform change and quietly work against your redirects.
Do I need to resubmit my sitemap after a migration?
Yes. Regenerate it so it contains only the new canonical URLs, then submit it through the Sitemaps report in Search Console at or immediately after cutover. Google requires absolute URLs in a sitemap, and caps each file at 50,000 URLs or 50MB, so larger sites will need a sitemap index. An old sitemap still advertising pre-migration URLs pulls against your redirects instead of supporting them.
Does structured data survive a platform change automatically?
Not reliably. Schema markup on most sites is generated by a theme, plugin or template that will not exist on the new platform, so it has to be rebuilt rather than migrated. Google explicitly warns that pages might break after deployment because of templating or serving issues, and recommends validating with the Rich Results Test during development and watching the rich result status reports afterwards. Do both, because a review or FAQ rich result is easy to lose silently.
What is the extra migration risk for a bilingual Arabic and English site?
hreflang has to be reciprocal. Google states that if two pages do not both point to each other, the tags will be ignored. A URL change touches the English and the Arabic address of every pair at the same moment, so one side being updated while the other is missed breaks the whole annotation rather than half of it. On UAE bilingual sites this is the single biggest thing to test before and after cutover.
Does hosting my website inside the UAE affect my Google rankings?
Only indirectly, and this does not change during a migration. Google lists server location among several signals it uses to work out who a site is aimed at, alongside country domains, hreflang, local addresses and local links, and it explicitly ignores geographic meta tags. What actually moves rankings is speed and page experience. A fast site on international hosting with a good CDN can outrank a slow site sitting on a local server.
Should I lower my DNS TTL before a hosting move?
Yes, if the move involves changing DNS records. Google's guidance for site moves without URL changes is to lower the time to live to a conservative low value, giving a few hours as its example, at least a week in advance. That means resolvers pick up the new records quickly at cutover instead of sending some visitors and some crawlers to the old server for a day or more. Raise it again once the move has settled.
How do I check Googlebot can reach my new hosting before cutover?
Use the URL Inspection Tool in Search Console against the new environment before you switch DNS, which is exactly what Google's site move guidance recommends. Check as well that firewall rules or denial-of-service protection on the new infrastructure are not blocking Googlebot from reaching your DNS or your servers. New hosting often arrives with stricter default protection than the old setup, and that protection does not know Googlebot from a scraper.
What should I capture before a migration starts?
A baseline, or you will not be able to judge anything afterwards. Crawl and export every current URL with its status. Record Search Console indexed page counts, at least three months of the Performance report, current sitemap status and Core Web Vitals. Record analytics organic sessions, conversions and top landing pages. Without that snapshot, every post-launch number is unfalsifiable, and normal fluctuation and a real fault look identical.
How do I tell a normal post-migration wobble from a real problem?
A normal wobble looks like gradual movement in both directions across many keywords for a few weeks, while indexed page counts and impressions stay near the baseline. A real fault usually traces to a specific checkable cause: a spike in pages blocked by robots.txt or excluded by noindex, old URLs returning 404 instead of a redirect, or a sustained one-directional collapse that does not ease. Check causes in Search Console rather than watching rank trackers.
Is moving to a .ae domain treated differently by Google?
No. It is a domain change under Google's site move with URL changes process, exactly like any other domain move, with the same redirect map, the same Change of Address submission and the same 180-day window. There is no .ae specific migration route. The .ae namespace is administered by the .aeDA under the TDRA, and first-level .ae registration is open to everybody, with additional eligibility rules on some second-level domains.
How much does a website migration cost in the UAE?
A migration starts from around AED 5,000 and rises with content volume and how much SEO preservation work is involved, with larger replatforms scoped in discovery. The main drivers are the number of URLs to map, whether templates and structured data have to be rebuilt on the new platform, whether an Arabic version is in scope, and whether the move includes a domain change. Final pricing depends on scope.
Should I migrate first and redesign later, even though it costs more?
In most cases yes, and it often costs less than it looks. Google recommends making design, information architecture and content changes after the move rather than at the same time. Two clean launches give you a diagnosable result at each step. One combined launch gives you a single ambiguous outcome and, if traffic falls, an investigation that can run for weeks. The extra launch is usually cheaper than the investigation it prevents.

SKIMBOX Team

Tech Consultancy

Want us to build something?

We work with teams across MENA, UK, USA, and India to build products, run programs, and grow.

Get in touch

Continue reading

Website Redesign in Dubai: Cost, Signs You Need One, and How to Keep Your SEO

Jul 18, 2026Blogs

Cookie Consent and Privacy Pages for UAE Websites (2026): What the Law Actually Says

Aug 7, 2026Blogs

Multilingual Website Development in the UAE (2026): Which Languages, and What It Costs to Keep Them

Aug 7, 2026Blogs

Website Migration and Replatforming in the UAE: How to Move Without Losing Your Rankings

Change one thing at a time

The types of move, ranked by risk

Redirects, done properly

The pre-launch checklist

Bilingual sites: the reciprocity trap

Domain moves and the 180-day window

What to watch afterwards, and the numbers nobody should quote

Real client stories

How SKIMBOX approaches migrations

References

Frequently asked questions

Want us to build something?

Continue reading

Website Redesign in Dubai: Cost, Signs You Need One, and How to Keep Your SEO

Cookie Consent and Privacy Pages for UAE Websites (2026): What the Law Actually Says

Multilingual Website Development in the UAE (2026): Which Languages, and What It Costs to Keep Them

Capabilities

Pages

Links

Capabilities

Pages

Links

Change one thing at a time

The types of move, ranked by risk

Redirects, done properly

The pre-launch checklist

Bilingual sites: the reciprocity trap

Domain moves and the 180-day window

What to watch afterwards, and the numbers nobody should quote

Real client stories

How SKIMBOX approaches migrations

References

Frequently asked questions

Get fresh writing in your inbox

Want us to build something?

Continue reading

Website Redesign in Dubai: Cost, Signs You Need One, and How to Keep Your SEO

Cookie Consent and Privacy Pages for UAE Websites (2026): What the Law Actually Says

Multilingual Website Development in the UAE (2026): Which Languages, and What It Costs to Keep Them