Changing your website without losing your rankings

Rankings vanish in a site change when the pages that earned them disappear, move without a redirect, or lose the content that ranked. All three are decided before launch, which is why the useful work is a list: what exists today, what it earns, and where each page goes.

Do the addresses have to change at all?

Not always, and the safest migration changes none. A redesign on the same platform can often keep every URL, title and heading, which shrinks the risk to whatever you break by accident. Ask the designer to keep the URL structure unless there's a reason, and make them name the reason.

Some moves force new addresses. Moving to Shopify from a site with different URL patterns changes nearly every product and collection address, because Shopify fixes the /products/ and /collections/ prefixes, and a change of domain changes all of them. Don't stack a redesign, a platform move and a domain change into one weekend: when rankings drop, nobody can tell which change did it.

What is the order of work?

1. 01Crawl the old site and save the crawl. Record every URL with its status code, title, H1, canonical, hreflang and internal links, Arabic pages included. This is your before picture. If the crawl finds far fewer pages than your sitemap lists, the missing ones are orphans with no internal links, so add them from the sitemap.
2. 02Collect the URLs that earn. Export pages from the Performance report in Google Search Console for the longest period available, pull landing pages from GA4, and take the most-linked pages from the Links report. Anything that earns clicks, enquiries or links is a protected URL. If Search Console isn't set up yet, set it up today, before anything changes.
3. 03Decide what stays, merges or goes. For each protected URL keep what earns: the title, heading, body copy and internal links. Merge pages only when two answer the same question. Retire pages nobody visits or links to and let them return a 404 or 410, instead of redirecting them somewhere irrelevant.
4. 04Map every old URL to its closest new URL, one to one. Use permanent (301) redirects, point each old address straight at its final destination with no chains, and never send many old pages to the home page. Keep the Arabic map separate, so /ar/old-page goes to /ar/new-page and never to an English page. If the new site has no equivalent for an old page, that's a content gap to fix before launch.
5. 05Check how Arabic addresses are written in the redirect file. Spreadsheets can garble Arabic characters unless the file is saved as UTF-8, and a server may expect the percent-encoded form while your list holds the decoded one. Test a sample of Arabic redirects by hand, in a private window, before launch day.
6. 06Build and test on a staging site that search engines can't reach. Protect it with a password rather than relying on a robots.txt rule, then crawl it and compare against the before crawl: missing titles, changed headings, canonicals that name the staging address, pages with no hreflang. Write down every noindex tag and robots.txt block on staging, so each can be removed on launch day.
7. 07Choose the launch date. Avoid your peak. White Friday starts on 27 November in 2026 by Amazon Ads' Friday-after-Thanksgiving rule and runs longer than a day. The Dubai Shopping Festival runs from 4 December 2026 to 17 January 2027, and Ramadan is expected to begin on 8 February 2027, subject to moon sighting. Launch early in the working week, with your developers at their desks.
8. 08Launch with a checklist, in order. Switch on the redirects, remove the staging noindex and robots.txt block, confirm that canonical and hreflang tags use the new addresses, submit the new XML sitemap in Search Console, and test your top fifty protected URLs by hand, Arabic ones included. If the domain changed, use the Change of Address tool in Search Console too.
9. 09Monitor daily for the first week, then weekly. Watch the Pages report for new errors, compare clicks for protected URLs against your before numbers, and run the old URL list through a checker to confirm each one lands where it should. Give it several weeks before judging, because Google has to recrawl the pages it already knew. Keep every redirect for at least a year, and indefinitely for any old address that still has links pointing at it.

On the launch day itself, remember the UAE working week. The federal government has worked a Saturday and Sunday weekend with a half day on Friday since 1 January 2022, and private companies set their own week, so check when your developers and your agency are actually at their desks before you fix a date.

What goes missing in a migration?

Each loss has a check you can run before launch. The Arabic pages lead the list for a reason: a rebuild gets checked in the language the team reads, and an Arabic gap can sit unnoticed for weeks.

A technical SEO audit before the rebuild produces most of this list as a by-product. A full crawl audit sits inside our SEO service, and what an SEO audit should cover shows what to ask for from anyone.

What if rankings drop after launch?

Compare, don't guess. Take one protected page that fell and check it against the before crawl, answering these questions in order and starting the repair at the first no.

1. 01Does the old address redirect once, straight to the new one?
2. 02Does the new page return a normal status?
3. 03Is its canonical the new address?
4. 04Did the title, heading and body copy survive?
5. 05Is it linked from the new menu or from other pages?

If the page is fine, wait. A move is processed gradually, so a dip in the first weeks is expected and a dip that persists is the signal. Fix the cause on the pages that matter most to revenue first, and leave the long tail until the main pages recover. Why your website isn't ranking gives the wider diagnosis if the page checks out.

Before anyone signs off a new design, ask for the redirect map in writing, as a spreadsheet with an Arabic tab. If it doesn't exist yet, the launch date isn't real yet.