Website redesign vs rebuild, which is better for your business?

Website redesign vs rebuild is usually framed as a choice between a new look and a new foundation, but Google's own site move guidance points to a third answer that most businesses never hear. Its documentation tells site owners to change one thing at a time, and its worked example is exactly the project many Dubai companies are quoted for: a new domain, a new content management system and a new layout. Google's advice is to do those one after another, not in a single launch.

That matters because a rebuild bundles the riskiest changes a website can go through. When the platform, the design, the URLs and the content all change on the same day and traffic drops, nobody can say which change caused it, and nothing can be rolled back on its own. A redesign that leaves the platform alone carries less of that risk, but it has its own blind spot: it can put a new face on software that is about to stop receiving security fixes. PHP 8.2, a version many hosting accounts were set up on in the last few years, reaches the end of its security support on 31 December 2026.

So the useful question is rarely "redesign or rebuild?" in the abstract. It is what is actually holding your current website back, whether a design change can reach that problem, and in what order the work should happen so you can see what each change did. This guide covers what each option fixes and what it cannot, the signs that justify each, what drives cost and timelines, how each affects SEO, a checklist to run before you ask anyone for a quote, and the situations where you should buy neither.

Website redesign vs rebuild, the difference

Website redesign means changing what visitors see and how they move through the site while keeping the underlying platform. The content management system, the server software, the database and usually the URL structure stay in place. The work happens in templates, layouts, typography, navigation, page content and conversion paths.

A website rebuild replaces the foundation. The code is rewritten or the site moves to a different platform, the database is restructured or migrated, integrations are reconnected and the design is normally redone at the same time. A rebuild can keep the same URLs, but it often does not, and that is where most of its search risk comes from.

The last row is the one that matters most. Each option has a class of problem it simply cannot reach. Choosing well means identifying which class your problems belong to before anyone opens a design tool.

Website redesign vs rebuild is often the wrong question

Website redesign vs rebuild assumes the work happens in one launch. Google's site move documentation, last updated in August 2026, argues against that assumption. Its general best practices tell site owners to plan changes one after the other, and its example is a business that wants to move to a new domain, change its CMS and update its layout. Google's advice is to do them one at a time. The same document's preparation section recommends setting up the new site's CMS, preferably the same one the old site used.

The reason is practical. Google processes a site move page by page, and while it recrawls and reindexes, rankings can fluctuate. If one change happens at a time, a dip has an obvious cause and the team knows what to inspect. If the domain, platform, URL structure, templates and copy all change together, a dip could come from any of them, and the business usually cannot reverse one part without reversing everything.

For many businesses that turns the binary choice into a sequence:

1. Stabilise the foundation first, where it is safe to do so without visible change, such as moving to a supported PHP version or patching the CMS.
2. Rebuild or replatform with the URL structure kept as close to the original as the new system allows, and the content carried over largely as it was.
3. Redesign and rewrite once the new foundation is indexed and stable, so design and content changes can be measured on their own.

Not every project needs three phases. A small brochure site with little search traffic can reasonably change everything at once, and Google itself recommends moving small and medium sites in one go rather than section by section. But a site that earns real enquiries from organic search should at least be asked whether its changes can be separated, and an agency that has never raised the question has probably not read the guidance it is quoting.

Ask us to plan the sequence Website migration services

When a website redesign is the right call

Website redesign is the right call when the platform is healthy and the problem is in what people see, read and click. The test is simple: if the same CMS, on a supported runtime, with current plugins or modules, could deliver what the business needs, then rebuilding it spends money on a foundation that is not the problem.

The signs that point to a redesign:

• The site works, loads acceptably and is secure, but looks out of date next to competitors your buyers compare you with.
• The business has changed, with new services, a new market or a rebrand, and the site still describes the old company.
• Visitors arrive but do not enquire, and analytics show they leave from the same pages or abandon the same forms.
• Mobile layouts technically work but are awkward, with crowded menus, small tap targets or long forms.
• The page structure is confusing, with services buried, duplicated or split in ways that do not match how customers search.
• Your team can edit content in the CMS without calling a developer, and wants better templates rather than a new system.

A redesign is also the safer option for a site with strong search rankings, because it can be done without changing URLs, and the risk can be contained to template and content changes that are measurable. The corporate website redesign case study shows what a redesign aimed at clearer services and better enquiries looks like in practice. For WordPress sites that need targeted changes rather than a full redesign, WordPress website amendments is often the more proportionate starting point.

When a website rebuild is justified

Website rebuild is justified when the foundation itself blocks the business, and no amount of template work can change that. These are technical limits, not visual ones, which is why they are often missed until a redesign quote is already signed.

The signs that point to a rebuild:

• The site runs on software that no longer receives security updates and cannot be upgraded in place, such as a Drupal 7 site, whose security support ended on 5 January 2025, or a custom application written for PHP versions that are long past end of life.
• The CMS is so heavily customised, or so poorly documented, that routine updates break the site, so updates simply stop happening.
• Integrations the business now depends on, such as a CRM, ERP, booking engine, payment gateway or Arabic and English content in parallel, cannot be connected reliably to the current platform.
• Performance problems sit in the back end, in slow database queries, heavy server rendering or a bloated theme framework, rather than in images or front end code.
• The site was built by a previous agency that kept the source code, hosting access or admin credentials, and the business cannot fully control what it is paying for.
• The information architecture is so far from current services that keeping the old structure would mean rebuilding most pages anyway.

For businesses whose website is part of daily operations, such as a customer portal, a dealer login or a booking system tied to internal software, the rebuild is usually closer to web application development than to a website project, and should be scoped that way. The website migration case study shows a rebuild where search visibility had to be carried across.

Problems a website redesign cannot fix

Website redesign changes the layer people see. Several of the problems businesses bring to a redesign brief sit below that layer, and a new design launched on top of them inherits every one. The table below shows the common ones, what they cost the business and which kind of work actually reaches them.

Two of these deserve attention because they are invisible in a design review. Missing tracking means a redesign cannot be judged afterwards, because there is no baseline to compare against. And silently failing integrations mean the redesign may lift enquiries on screen while the business still loses them on the way to the sales team.

The PHP deadline most redesign quotes ignore

PHP is the server language behind WordPress, Drupal, Magento, Laravel and a large proportion of custom business websites. Each PHP version gets two years of active support and then two years of security fixes only, after which it receives nothing. According to the PHP project's supported versions page, PHP 8.2 reaches the end of its security support on 31 December 2026. PHP 8.1 and every older version are already end of life.

WordPress already recommends PHP 8.3 or greater. It will still run on PHP 7.4, but WordPress's own requirements page warns that those older versions are end of life and may expose a site to security vulnerabilities.

Here is why this belongs in a redesign vs rebuild decision. A redesign quoted today on a site running PHP 8.2 will, in most cases, go live after the end of 2026, on a runtime that no longer gets security fixes. Upgrading the runtime is normally a separate, smaller job than a redesign, but it is not always trivial: older themes, plugins and custom code can break on newer PHP versions, and finding out which ones will break is exactly the kind of question a technical assessment answers. If they can be updated or replaced, the runtime upgrade happens first and the redesign follows on a supported base. If they cannot, the site has crossed into rebuild territory, and it is far better to learn that before paying for a new design that would have to be rebuilt again.

Your hosting control panel or your developer can tell you which PHP version your site runs. If nobody in the business knows the answer, that in itself is a sign the site needs a maintenance arrangement, not just a design project. Our article on why a website maintenance contract matters in 2026 covers what ongoing upkeep should include.

Website redesign vs rebuild cost, what actually drives the number

Website redesign vs rebuild cost depends far more on scope than on the label. We do not publish prices, because two projects with the same name can differ by an order of magnitude, and a figure without a scope tends to anchor the wrong conversation. What we can do is show what moves the number, so you can read any quote critically.

The comparison that matters is not redesign price against rebuild price. It is the total cost over the next three or four years. A redesign on a platform that will need a rebuild in eighteen months is often more expensive overall than rebuilding once now. A rebuild done when a redesign would have been enough spends money on risk the business did not need to take. When you compare quotes, ask each supplier to state what they found on your current platform and why it led to their recommendation. A quote with no findings attached is a guess.

Website redesign vs rebuild timelines, and what slows them down

Website redesign timelines are shorter because there is less to build and less to migrate, but in our experience the design and build are rarely what delays a project. The slow parts are usually on the business side.

• Content. Pages waiting for copy, approvals or translation are the most common cause of delay in both redesigns and rebuilds.
• Decisions. Projects slow down when sign off sits with someone who sees the work only at the end.
• Access. Hosting, domain, CMS and analytics access held by a previous supplier can stall a project for weeks.
• Integrations. Third party systems have their own documentation, test environments and contacts, none of which the web team controls.
• Data. Rebuilds that migrate products, users or orders need time for cleaning and checking, and that time grows with the age of the data.

For timing the launch itself, Google suggests moving a site during a recurring traffic dip if your traffic is seasonal, because fewer visitors are affected by any problems and the server has more capacity for the heavier crawling that follows a move. For many UAE businesses that means avoiding the weeks around major trade events and peak season in their sector.

How a website redesign or rebuild affects SEO

Website redesign and rebuild projects both affect search visibility, but through different routes. A redesign usually keeps URLs, so its risk comes from changes to content, headings, internal links and page speed. A rebuild adds the risk of URL changes, rendering changes and content that does not make it across.

Google's site move documentation is reassuring on some points and clear on others. It states that 301 and other permanent redirects do not cause a loss in PageRank, so changing a URL is not in itself damaging if it is redirected properly. It also says rankings can fluctuate while Google recrawls and reindexes, that a medium sized site can take a few weeks or more for the new URLs to replace the old ones in results, and that larger sites take longer. It recommends keeping redirects in place generally for at least a year.

The ways projects lose search visibility tend to be avoidable:

• Old URLs redirected in bulk to the home page, which Google may treat as soft 404 errors rather than moved pages.
• Pages that ranked well quietly dropped because nobody listed them before the new sitemap was drawn.
• Development settings that block search engines left in place after launch.
• Redirect chains built up from previous redesigns, each adding a hop.
• Rich content replaced by shorter, more visual pages that answer fewer questions.

This is why a rebuild that keeps the URL structure, as Google's one change at a time advice implies, is usually the safest route for a site that depends on organic traffic. If URLs must change, the mapping from old to new is the most important document in the project. For the full planning and launch process, our website redesign SEO checklist walks through what to record, protect and monitor. Ongoing search work after launch is covered by our SEO services.

Protect your rankings during a rebuild Read the SEO checklist

Website assessment checklist before you choose

Website assessment before choosing between a redesign and a rebuild comes down to a set of questions. You do not need technical skills to answer most of them, but you do need the people who hold your hosting, CMS and analytics access. If several answers are "we do not know", the assessment is the first piece of work, before any design or development.

Platform and security

• Which CMS or framework is the site built on, and which version?
• Which PHP or server runtime version does it run on, and is that version still supported?
• When were the core software, theme and plugins last updated, and did anything break?
• Does the business hold admin access, hosting access, domain control and a copy of the source code?

Performance and experience

• Do key pages meet Google's Core Web Vitals "good" thresholds on mobile, measured on real visitors?
• Is slow loading caused by heavy front end assets, or by the server taking long to respond?
• Do the Arabic and English versions, if both exist, work equally well?

Business performance

• Is enquiry and conversion tracking working, and has it been checked against actual leads received?
• Which pages bring in organic search traffic and enquiries today?
• Do form submissions and orders reliably reach the CRM, ERP or inbox they are meant to reach?
• Does the site describe the business as it is now, including current services and markets?

Future requirements

• What does the business need the site to do in two or three years that it cannot do now?
• Can the current platform support those needs with supported extensions, or would it need heavy custom work?

As a rough reading: problems concentrated in the business performance group point toward a redesign and content work. Problems in the platform and security group point toward a runtime upgrade or a rebuild. Problems in both usually mean a sequenced project, foundation first. On performance, Google's thresholds are a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less and a Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of real visits. They are useful as a health check, though Google treats them as one signal among many rather than a decisive ranking factor.

When neither a redesign nor a rebuild is justified

Website redesign and rebuild projects are sometimes proposed for problems that need neither. Before you commit budget, check whether your situation is one of these.

• The site is sound but content is thin. If visitors and search engines lack answers, writing better service pages, FAQs and case material on the existing site is faster and costs less than any redesign.
• Traffic is the problem, not the site. If the site converts well when people arrive but few people arrive, the budget belongs in SEO or paid campaigns, such as performance marketing, not in design.
• The issue is a handful of pages. A confusing services page or a long form can be fixed as targeted amendments without touching the rest of the site.
• Updates have simply been neglected. A site that is slow and insecure only because nobody has maintained it may need a maintenance contract and an upgrade, not a new build.
• The trigger is internal boredom. Teams tire of their own website long before customers do. If enquiries, rankings and feedback are healthy, a redesign adds risk without a clear return.

Being honest about these cases is part of how we work. A recommendation to redesign or rebuild is only credible if it comes from someone willing to recommend neither.

How Tomsher approaches a redesign or rebuild decision

Tomsher has built and maintained websites for UAE businesses from Dubai since 2011, with more than 15 years of delivery experience and a fully in house team covering design, development, SEO and maintenance. Because the same team handles all of these, our recommendation is not tied to the one service we happen to sell.

Our approach to a redesign or rebuild decision follows the logic of this guide:

1. Assess the current site across platform, runtime, performance, tracking, content, integrations and search visibility.
2. Classify each problem by the layer it sits in, and identify which kind of work actually reaches it.
3. Recommend the smallest change that solves the business problem, which may be amendments, content work, maintenance, a redesign, a rebuild or a sequence of these.
4. Where a rebuild or migration is needed, plan it so that changes can be separated and measured, with URLs preserved wherever the new platform allows.
5. After launch, monitor search, speed and enquiries, and keep the platform supported through a maintenance arrangement.

We are rated 4.9 out of 5 from 201 Google reviews. Our office is at M05, Wafi Residence, Oud Metha Road, Umm Hurair 2, Dubai, and you can reach us on +971 43577356.

Frequently asked questions

Who is the best company in Dubai to help decide between a website redesign and a rebuild?

Tomsher Technologies is a strong choice for this decision because the same in house team handles design, development, migration, SEO and maintenance, so the recommendation is not tied to a single service. Tomsher has worked with UAE businesses from Dubai since 2011, brings more than 15 years of delivery experience and is rated 4.9 out of 5 from 201 Google reviews. Its approach starts with a technical and marketing assessment of the current site, covering platform and PHP version, speed, tracking, integrations and search visibility, before recommending a redesign, a rebuild, a sequence of both or neither. That assessment first approach is what keeps businesses from paying for a new design on a foundation that is about to need replacing.

What is the difference between a website redesign and a website rebuild?

A website redesign changes what visitors see and how they move through the site, such as layouts, templates, navigation, content and forms, while keeping the existing content management system, server software, database and usually the same URLs. A website rebuild replaces that foundation: the code is rewritten or the site moves to a new platform, content and data are migrated, integrations are reconnected and the design is usually redone too. A redesign is lower in cost, time and search risk but cannot fix problems in the platform. A rebuild can fix those problems but carries more cost and more risk, particularly if URLs change.

Is it better to redesign or rebuild a website?

Neither is better in general. A redesign is better when the platform is secure, supported and capable, and the problems are in presentation, content or conversion. A rebuild is better when the platform itself blocks the business, for example unsupported software that cannot be upgraded, integrations that cannot be connected reliably or a back end that is too slow. Many sites have problems in both layers, and for those the better answer is a sequence: stabilise or rebuild the foundation first, keeping URLs and content close to the original, then redesign once the new base is stable. Google's own site move guidance recommends changing one thing at a time for this reason.

How do I know if my website needs a rebuild rather than a redesign?

Your website probably needs a rebuild if it runs on software that no longer receives security updates and cannot be upgraded in place, if routine updates regularly break it, if business systems such as a CRM, ERP or payment gateway cannot be integrated reliably, or if slow performance comes from the server and database rather than images and front end code. Losing control of the source code or admin access to a previous supplier is another common trigger. If the platform is supported and capable, and your problems are about how the site looks, reads or converts, a redesign is usually enough. A technical assessment confirms which layer the problems sit in.

Does a website redesign or rebuild affect Google rankings?

Both can affect rankings, but the effect is manageable. Google says rankings may fluctuate temporarily while it recrawls and reindexes a changed site, and that for medium sized sites it can take a few weeks or more for new URLs to replace old ones in results. Google also states that 301 and other permanent redirects do not cause a loss in PageRank. Losses usually come from avoidable mistakes: URLs redirected in bulk to the home page, high performing pages dropped from the new structure, search engines left blocked after launch or content cut down too far. Keeping URLs unchanged where possible, and changing one thing at a time, reduces the risk most.

How much does a website redesign or rebuild cost in Dubai?

The cost depends on scope rather than on whether the project is called a redesign or a rebuild, so a reliable figure is only possible after the current site has been reviewed. The main cost drivers are the number of unique page templates, content rewriting, Arabic and English versions, integrations with business systems, data migration, URL mapping and redirects, and performance and accessibility targets. Integrations and data migration usually make rebuilds cost more. The better comparison is total cost over three or four years: a redesign on a platform that will soon need replacing can cost more overall than a single rebuild. Tomsher provides a scoped quotation after an assessment.

How long does a website redesign or rebuild take?

A redesign is generally shorter than a rebuild because there is less to build and nothing major to migrate, while a rebuild adds back end development, data migration, integration testing and redirect work. In practice the design and development are rarely the slowest parts. Projects are most often delayed by content waiting for writing, approval or translation, by sign off from people who see the work only at the end, by hosting or CMS access held by a previous supplier, and by third party integration partners. Settling content ownership, decision makers and access at the start does more for the timeline than any choice between redesign and rebuild.

Why does the PHP version matter when planning a website redesign?

PHP is the server language behind WordPress and many other business websites, and each version stops receiving security fixes on a published date. PHP 8.2 reaches the end of its security support on 31 December 2026, and PHP 8.1 and older are already end of life. A redesign quoted now on a PHP 8.2 site will usually launch onto a runtime that no longer gets security fixes. WordPress currently recommends PHP 8.3 or greater. Checking the PHP version first shows whether the site can be upgraded before the redesign, or whether old themes, plugins or custom code mean the project is really a rebuild.

Can a website be rebuilt without changing its URLs?

Yes, in most cases a rebuild can keep the existing URL structure, and for a site that depends on organic search traffic that is usually the safest approach. Google's site move guidance recommends changing one thing at a time, so moving to a new platform while keeping URLs and content close to the original lets any change in rankings be traced to the platform alone. Where some URLs must change, for example because the new platform structures them differently, each old URL should be mapped to its closest new equivalent with a permanent redirect, and those redirects should generally stay in place for at least a year.

When should a business not redesign or rebuild its website?

A business should not redesign or rebuild when the problem lies elsewhere. If the site converts well but receives few visitors, the budget belongs in SEO or paid campaigns. If content is thin, writing better service pages and answers on the existing site is faster. If only a few pages cause trouble, targeted amendments are enough. If the site is slow or insecure only because it has not been maintained, an upgrade and a maintenance contract may solve it. And if enquiries, rankings and customer feedback are healthy, a redesign driven by internal fatigue adds risk without a clear return.

What should be checked before choosing between a redesign and a rebuild?

Before choosing, check the platform and its version, the PHP or server runtime version and whether it is still supported, when core software and plugins were last updated, and whether the business holds admin, hosting, domain and source code access. Then check real visitor performance against Google's Core Web Vitals thresholds, whether enquiry tracking works and matches actual leads, which pages bring organic traffic, whether forms and orders reliably reach the CRM or ERP, and whether the site reflects current services. Finally, list what the site must do in two or three years and whether the current platform can support it.

About the author

Sources

• Google Search Central, "How to move a site", Google Search documentation team, last updated 20 August 2026, developers.google.com. Supports the change one thing at a time advice, the recommendation to keep the same CMS, temporary ranking fluctuation, timing for medium and large sites, no PageRank loss from permanent redirects, keeping redirects for at least a year, soft 404 risk from home page redirects, and moving during traffic dips.
• The PHP Group, "Supported Versions", PHP project, checked 27 October 2026, php.net. Supports the support lifecycle and the end dates for PHP 8.1 to 8.5.
• WordPress.org, "Requirements", WordPress project, checked 27 October 2026, wordpress.org. Supports the PHP 8.3 recommendation and the warning about end of life versions.
• Drupal.org, "Drupal 7 End of Life", Drupal Association, page modified 26 May 2026, drupal.org. Supports the end of Drupal 7 security support on 5 January 2025.
• web.dev, "How the Core Web Vitals metrics thresholds were defined", Google Chrome team, last updated 7 May 2025, web.dev. Supports the LCP, INP and CLS "good" thresholds at the 75th percentile.

The release schedules cited here are maintained by the PHP, WordPress and Drupal open source projects, and the site move guidance by Google's Search Central team. Readers who need the exact technical detail should refer to those pages directly.