Website migration case study, rebuilding a UAE business website while preserving its SEO foundations

Home / Case studies / Website migration case study

This website migration case study documents the rebuild of a UAE business website, including the content audit, the URL decisions, the launch checks and the post-launch review. The client moved from an ageing WordPress site to a custom application built on the MERN stack, on the same domain, with most of its URLs kept and a small number deliberately changed.

The commercial concern was not the design. It was everything the old site had quietly accumulated over nine years: pages that ranked, documents customers downloaded, links other sites pointed at, and an enquiry route the sales team depended on. This is what Tomsher's Dubai-based team audited, retained, changed, tested and monitored, and what the figures showed afterwards. The client is not named, and all screenshots are anonymised.

Website migration overview, the business, platform and project scope

The website migration involved a platform change, a new design and a partial URL change on the same domain, with the existing content, documents and enquiry forms included in scope. The domain did not change, so this was not a domain move.

Website rebuild challenges and the SEO foundations to preserve

Website rebuild planning began with identifying the content, search landing pages and enquiry routes the business already relied on. The old site was slow and hard to update, but it was also earning work, and that is the part a rebuild puts at risk.

• Pages that already ranked. Search Console showed 18 pages producing 71% of organic clicks, most of them product and service pages written years earlier.
• Documents customers used. 23 PDFs, including product datasheets and a company profile, several of them linked from supplier and tender portals.
• External links pointing at specific URLs. Backlinks from trade directories, association listings and two industry publications, all pointing at page addresses rather than the homepage.
• An enquiry route the sales team depended on. Four forms across the site, including a quotation request that fed the sales inbox.
• Content that looked expendable and was not. A technical FAQ section with 26 questions, poorly designed but responsible for a steady share of long-tail search traffic.

The rebuild had a second constraint: the plugin-driven WordPress site had no clean content model, so content had to be restructured into the new application rather than copied across. That is where content is usually lost.

Pre-migration content audit and search performance baseline

The pre-migration content audit recorded which pages would be retained, updated, merged or retired. Nothing was decided from the design mockups.

• A full crawl of the old site, exporting all 68 pages with status codes, titles, meta descriptions, H1s, canonical tags and word counts.
• Twelve months of Search Console data, by page and by query, so retention decisions were made against clicks, impressions and positions rather than opinion.
• Twelve months of GA4 data, for organic landing pages, sessions and form submissions.
• A backlink review, listing every externally linked URL so none of them could be dropped without a redirect.
• A document inventory, covering all 23 PDFs, their file paths and where they were linked from.
• A copy of every page, archived before development began, so nothing depended on the old site still being available.

The decisions that came out of it: 54 pages retained as they were or lightly improved, 7 pages merged into 3 stronger pages, 4 thin pages retired, and 4 new pages added. All 23 documents were carried over. The technical FAQ section was kept in full and rebuilt as a structured content type rather than being trimmed to suit the new layout.

URL mapping and redirect planning for the new website

URL mapping documented how each affected old address would be handled after launch. The starting principle was to keep URLs that were already accurate, because every URL retained is one less redirect to write, test and maintain.

The approach followed Google's own migration guidance: server-side permanent redirects where technically possible, one-to-one mappings to the most relevant destination rather than sending many old URLs to one irrelevant page, redirect chains avoided, and the redirects kept in place for at least a year so signals transfer. Because the domain did not change, no Change of Address request was needed, which applies to domain and subdomain moves rather than a rebuild on the same domain. The internal links in the new build point at the new addresses directly rather than relying on redirects, and the sitemap lists only live, indexable URLs.

Content migration into the rebuilt website

Website content migration covered page copy, headings, images, the 23 documents, metadata and internal links, and their placement within the new MERN templates. Content was not pasted into a page builder. Each content type was modelled in MongoDB with defined fields, then the React templates were built to render it, which is why the migration doubled as a content clean-up.

• Copy and heading structure preserved, with one H1 per page and the heading hierarchy rebuilt rather than flattened into styled text.
• Metadata carried over page by page, improved where it was weak, and never overwritten by a template default.
• Images re-exported in modern formats with descriptive filenames and alt text, which was missing on 44% of images on the old site.
• Documents moved with redirects, and every download tested from the pages that link to it.
• Internal links updated to new addresses, including links inside body copy that plugins had hard-coded.
• Structured data rebuilt, covering organisation, breadcrumb and FAQ markup, and validated before launch.
• The technical FAQ rebuilt as a content type, so the client can add questions without a developer.

Website migration testing before launch

Website migration testing checked the agreed requirements across priority pages, templates, devices and enquiry routes. Testing ran on staging with search engines blocked, and every check had a named owner.

• Crawl comparison. The staging crawl was placed beside the baseline crawl to find pages that had lost a title, an H1 or their indexability. Nine issues were found and fixed.
• Redirect testing. All 16 changed URLs plus the 23 document paths were tested for the correct destination, a single hop and a permanent status. Two chains were found and flattened.
• Content verification. Each of the 61 retained or merged pages was checked against the archived copy, item by item, including the FAQ entries.
• Form and email delivery. All four forms were submitted from desktop and mobile and confirmed in the destination inbox, not just by the success message.
• Tracking checks. GA4 and conversion events were verified on every template before launch, since a missing tag produces an alarming chart that has nothing to do with search.
• Mobile and performance testing on real devices over a mobile connection.
• Indexing controls. robots.txt reviewed line by line, staging blocks confirmed removed at launch, canonical tags checked for any still pointing at staging.

Launch was scheduled for a low-traffic period, with the old site and database retained and a rollback path agreed before go-live.

Post-migration SEO monitoring and issue resolution

Post-migration SEO monitoring compared the rebuilt website with the recorded baseline weekly for the first month and monthly after that, through to 16 September 2026. Four issues surfaced, which is normal rather than alarming.

• A crawl error spike in week one. Old plugin-generated URLs that had not appeared in the crawl or the sitemap began returning 404s. Twenty-two of them were mapped to relevant destinations, the rest were left to drop out.
• A short click decline in weeks two and three. Organic clicks fell about 9% against the same weeks of the prior period, then recovered by week five. Google states that temporary fluctuation is normal while a site is reprocessed, and that for medium-sized sites it can take a few weeks or more before new URLs replace old ones.
• Two pages indexed at the wrong address. Both were traced to a canonical tag pointing at the pre-launch path, corrected and re-submitted.
• One form not reaching the second recipient. Found in week one from the monitoring checklist rather than from a customer complaint, and fixed the same day.

Website migration results and verified outcomes

The website migration results below cover the 90 days before launch, 20 March to 17 June 2026, against the 90 days after, 19 June to 16 September 2026, and separate technical delivery from search and enquiry performance.

Read these with the context. The launch date is marked on the Search Console chart accompanying this case study. Traffic was mildly seasonal across both windows, no advertising was added or removed, and GA4 tracking definitions were unchanged, which is what makes the enquiry comparison usable. The click difference is modest and within the range normal variation could explain, so the honest reading is that search performance held through the migration and improved slightly, rather than that the rebuild caused a lift. The technical rows are the more definitive evidence: nothing was lost, and the mobile performance change is directly attributable to the new build.

Choosing the best website migration company in Dubai, evidence to request

Choosing the best website migration company in Dubai starts with reviewing its process, relevant project evidence and post-launch responsibilities. For businesses comparing the best SEO migration agencies in the UAE, ask for four things in writing.

• A URL map from a real project, anonymised, showing one-to-one mappings rather than a bulk redirect rule.
• The content decision record, showing which pages were kept, merged or retired and the data behind each call.
• The launch checklist with actual outcomes, including the defects found and fixed rather than a clean template.
• The monitoring commitment, covering who watches Search Console after launch, for how long, and what happens when something breaks.

Be careful with anyone promising zero ranking loss. Google's own documentation says temporary fluctuation is normal during a move, so a guarantee of no movement is a claim nobody can support. A credible provider explains what it protects, what it monitors and how quickly it responds.

Plan your website migration with Tomsher

Website migration services should be scoped around your current platform, your valuable content, the changes you plan and your business requirements. To assess a migration we need the current website and platform, access to Search Console and analytics, a list of what is changing (design, CMS, URLs, domain or hosting), your document and form inventory, and the launch date you are working towards.

From that we produce the content inventory, the URL map, the test plan and the monitoring plan before development starts. The process we follow is the one set out in our website redesign SEO checklist, and this case study is that checklist applied to a real rebuild. Our website redesign and development in Dubai team handles the design and build, website development services cover the wider requirements, and where a site stays on its existing platform our WordPress website development team works on that instead.

Frequently asked questions

Sources

• Google Search Central, Site moves with URL changes
• Google Search Central, Redirects and Google Search
• Google Search Central, Site moves without URL changes