Rebuild or Redesign? Deciding on an Existing Dubai Website

Deciding between a website redesign and a rebuild is easier once you separate four layers: the content, the URLs, the platform and the presentation. A redesign changes the presentation and leaves the other three alone. A rebuild replaces the platform, and often the URLs with it. Almost all of the risk, cost and lost search traffic in a website project lives in that URL layer, so the honest first question for a Dubai business is not which one sounds better. It is whether the addresses of your pages have to change at all.

Key takeaways

• A redesign that keeps the same URLs and the same CMS is a low-risk project. A rebuild that changes URLs is a site migration, and Google treats it as one.
• Google’s guidance on moving a site with URL changes, last updated 20 August 2026, says a medium-sized site can take “a few weeks or more” before the new URLs appear in place of the old, and asks you to keep the redirects “for as long as possible, generally at least 1 year”.
• Only permanent redirects pass the canonical signal. Google’s redirect documentation, last updated 14 April 2026, is explicit that with a temporary redirect the indexing pipeline does not treat the target as canonical.
• You can change platform without changing URLs. Google publishes separate guidance for exactly that case, and it is the cheapest way to escape an ageing stack.
• If the complaint is that the site looks dated, that is a design problem. If the complaint is that nobody can add a page without a developer, that is a platform problem. They have different answers and different prices.

Four layers, and which one you are actually changing

Most briefs arrive as “we need a new website”. Broken into layers, the conversation gets shorter.

Read down the rebuild column and the cost becomes obvious. A rebuild touches everything, which is why it takes longer and carries more ways to go wrong. Read the URL row and the risk becomes obvious too: it is the only row where a mistake removes traffic you already had.

The test that settles it in an afternoon

Three questions, answered honestly, usually decide this without a workshop.

First, can a non-developer on your team publish a new service page today, with images, without asking anyone? If yes, the platform is doing its job. If no, and if that has cost you weeks of delay over the past year, you have a platform problem that a new set of templates will not fix.

Second, when something breaks, does it break in the design or underneath it? A page that looks wrong on a phone is a presentation problem. A page that times out under load, or that cannot accept a new field on a form without custom work, is a platform problem.

Third, what is the runtime version? A site on a PHP branch that has left security support is being served by code that receives no fixes. Read on 19 September 2026, php.net lists 8.2 in security-only support until 31 December 2026 and 8.3 until 31 December 2027, so anything on 8.1 or below is already past every published date. That is a rebuild trigger regardless of how the site looks, although the cheaper route is often an upgrade rather than a replacement.

One issue we often see is a fourth answer that nobody asked for: the site is fine, the content is the problem. Sites get replaced because the pages say nothing a buyer needs, and a new design ships the same emptiness in a nicer typeface.

When a redesign is the right and cheaper answer

A redesign earns its keep when the structure works and the surface does not. Typical cases in Dubai: a site built in 2021 that reads badly on a phone, a brand refresh that the site never caught up with, navigation that has grown eleven top-level items, or a contact path that buries the enquiry form three clicks deep.

Because the URLs and the CMS stay put, a redesign keeps every ranking, every backlink and every piece of analytics history. It can also ship in stages: the home page and one service template first, the rest over following weeks, with the old and new designs coexisting. That staging is impossible in most rebuilds, which is a practical argument for the smaller project when the smaller project is enough. Our earlier piece on the design mistakes Dubai businesses keep repeating goes through those symptoms in more detail.

Our usual advice to a smaller company is to exhaust the redesign case before entertaining a rebuild, because the rebuild is still available next year and the traffic you keep in the meantime is not.

When a rebuild is worth the risk

Four situations justify replacing the platform rather than repainting it.

The stack no longer receives fixes

An unsupported CMS version, an abandoned theme, or a framework whose maintainers have moved on. Patching becomes impossible rather than merely inconvenient, and hosting providers eventually stop offering the runtime it needs.

The site cannot do the next thing the business needs

A booking flow, a customer login, a product configurator, an Arabic version with its own URLs, or an integration with the system that actually runs the company. If each of these arrives as a bolt-on plugin, the site becomes a stack of workarounds. There is a threshold where the honest answer is that you now need an application rather than a website, which is a different brief.

Content is locked inside the presentation

Page builders store layout and copy together. That is convenient until you want the same content in two places, or in a second language, or in a mobile app. When every page is a unique arrangement rather than an instance of a template, editing at scale stops being possible. Our comparison of WordPress and Strapi for Dubai sites covers the trade-off between an all-in-one CMS and a content-first one.

Performance problems are structural

If the field data fails Core Web Vitals because of how pages are assembled rather than how they are styled, a redesign will not move it. Google’s published thresholds, on a page last updated 31 October 2024, put Largest Contentful Paint at 2.5 seconds, Interaction to Next Paint at 200 milliseconds and Cumulative Layout Shift at 0.1. Diagnose before deciding, because plenty of poor scores come from one oversized hero image and a chat widget.

What a URL change actually costs you

This is the part that gets underestimated, so it is worth quoting the source rather than paraphrasing it.

Google’s documentation on moving a site with URL changes, last updated 20 August 2026, states that “for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones”. It asks site owners to keep the redirects “for as long as possible, generally at least 1 year”, and to keep redirect chains short, ideally no more than three hops and fewer than five. It also says plainly that “visibility of your content in Search may fluctuate temporarily during the move”.

Two practical consequences follow. A migration launched two weeks before your busiest season is a bad plan, because the fluctuation lands in the season. And the redirect map is not a launch-week task that can be closed afterwards; it is infrastructure you keep for at least a year, which means it has to be maintained in version control rather than typed into a plugin and forgotten.

The redirect type matters as much as the map. Google’s redirect guidance, last updated 14 April 2026, says a permanent redirect signals that the target should be canonical, while with a temporary redirect the indexing pipeline does not use it that way. A migration served with 302s keeps the old addresses in search results, which is the opposite of the intention. Use 301 or 308 for a move, server-side, and treat JavaScript redirects as a last resort.

Changing the platform without changing the URLs

The route most Dubai businesses should consider first is rarely proposed to them: rebuild the platform and keep every address exactly as it is. Google publishes separate guidance for this case, last updated 10 December 2025, describing a move where hosting or the underlying system changes while URLs do not. The steps are to stand up the new system, test it including a check that Googlebot can reach it, switch DNS, watch logs and Search Console on both sides, and retire the old host only once its traffic reaches zero.

The same page names the two mistakes that cause most of the damage, and both are avoidable. A firewall or denial-of-service protection on the new host that blocks Googlebot, and a noindex tag or robots.txt block left over from the staging site. We have seen a staging robots file survive a launch and take a site out of the index for a fortnight; nothing about the design was at fault.

Keeping URLs is not always possible. If the old structure is genuinely broken, with query-string pages, duplicated categories or a language folder that never worked, changing it is the point of the project. Make that a deliberate decision with a redirect map attached, rather than an accident of the new system’s default permalink settings.

The parts of a rebuild people forget to scope

1. The redirect map, built from the live URL list and from Search Console, not from the sitemap alone.
2. Forms, and where their submissions go. Every form is a small integration, and each one needs testing after launch, not before.
3. Analytics and conversion tracking, which break quietly when page structure changes and take a month to be noticed.
4. Structured data. Schema tends to live in the old theme and vanish with it.
5. Images, including the ones embedded in old posts, which are the most common source of broken pages after a CMS change.
6. Arabic or other language versions, and the hreflang relationships between them.
7. Anything a third party embeds: booking widgets, payment gateways, map keys, chat tools.

A rebuild quote that does not itemise these is quoting for the visible half of the work.

A sequence that lowers the risk

Where a rebuild is the right call, the order of operations matters more than the technology choice.

Export the full URL list first, from the server rather than from the sitemap, and pair it with twelve months of Search Console data so you know which pages actually earn something. Build the new site on a staging domain that is blocked from crawling, then verify that the block is removed before launch and not after. Migrate content before design sign-off, because content always reveals template gaps. Keep the old site reachable internally for a month so that anything missing can be recovered. Launch mid-week and early in the day, when your team is available, not on a Thursday evening.

Then watch three things for six weeks: server logs for 404s, Search Console coverage for pages dropping out, and your enquiry count. The enquiry count is the one that matters, and it is the one most migration checklists leave out.

If the decision is turning on cost rather than evidence, a short audit of the current site’s structure, runtime and search performance usually answers it for you. Our team handles website design and full website development in Dubai, and we are happy to look at what you have before anyone proposes replacing it.

Guidance and dates here were checked against Google’s published documentation and php.net on 21 September 2026 and change over time. This is general information rather than advice on your specific site. Cover photo: Sheikh Zayed Road 10, via Wikimedia Commons (CC0).