Fix it or rebuild it? Changing a website without losing what already works
One project brief in twenty-five is repair work: a migration, a rebuild, a restore or a site that broke. How to tell which you need, and the four things a rebuild most often destroys on the way.
Muhammad Usman · Co-founder and CTO
Of the 2,397 project briefs posted between June and August 2026 that we analysed, 95 were repair work: migrations, rebuilds, restorations, and the brief that simply says fix my site. Four percent, steadily, and almost nobody markets to it. It is also the work where the most value gets destroyed by accident, because the site being replaced was quietly doing jobs nobody had written down.
Rebuild or repair: the actual test
The question is not whether the site looks dated. It is whether the problem lives in the platform, or in what sits on top of it.
| Symptom | Usually means | Usually needs |
|---|---|---|
| Slow, on a reasonable platform | Heavy theme, too many plugins, unoptimised images, third party scripts | Repair |
| Traffic flat, pages crawled but not indexed | Duplicate or thin pages, weak internal linking | Structural repair |
| Every edit needs a developer | A build that does not suit the people editing it | Rebuild, or a CMS change |
| Theme or plugins no longer maintained | An abandoned dependency | Planned migration |
| Hacked or defaced | Outdated software or compromised hosting | Clean restore, then hardening |
| Has to do something new: bookings, payments, Arabic | A scope change, not a fault | Often a rebuild |
The expensive mistake is rebuilding to solve a content or structure problem. A new design on the same thin pages ranks the same as the old one, and a rebuild that changes every URL on the way can rank worse.
The four things a rebuild most often breaks
1. Rankings tied to old URLs
Every URL that ranks has collected links and history. Change it without a permanent 301 redirect to its new equivalent and that history is thrown away. Before anything is redesigned, export every URL the old site has, from its sitemap, Search Console and analytics, and map each one to where it will live. Keep URLs unchanged wherever you can, and never redirect everything to the homepage, which search engines treat much like a missing page.
2. Tracking
Tag manager containers, analytics, ad pixels and conversion events live in the old templates. A rebuild that does not carry them across goes live blind, and the first sign is usually an ad platform that stops reporting conversions while the budget keeps spending. List every tag before the old site is switched off, and test that conversions fire on staging.
3. Email and DNS
Moving hosting often means moving DNS, and the DNS zone holds more than the website. Mail routing and the SPF and DKIM records that keep your email out of spam folders live there too. Drop them in the move and email stops, or quietly starts landing in junk. Export the full zone before anyone touches the nameservers.
4. Staging settings that reach the live site
A staging copy is normally set to noindex, or blocked in robots.txt, so it does not compete with the live site. When those settings ship to production, the new site tells search engines to forget it. Nothing looks broken in the browser, which is why it can go unnoticed for weeks.
Access is the first deliverable
Repair briefs often arrive with the same underlying problem: the business does not hold its own keys. The domain sits in a former developer's account, hosting is billed to someone who has left, the admin login was never shared. Each of those can usually be recovered, but recovery takes time and has to happen before any real work can.
It is why our briefing checklist asks who will hold the hosting, domain and admin access at the end of a project, and asks for that handover to be part of the scope. On a repair job, establishing access is step one, and it is worth paying for on its own. The list to recover and write down:
- The domain registrar account, and who receives its renewal notices.
- The DNS host, which is not always the registrar.
- Hosting or server access, and where backups are kept.
- CMS administrator logins.
- Tag manager, analytics, Search Console and Bing Webmaster Tools.
- API keys and accounts for the payment gateway, CRM and any other integration.
What a rebuild costs to build, and to run
Published UAE agency ranges put a multi-page business site at AED 2,500 to AED 12,000, WordPress on a customised premium theme at AED 8,000 to AED 12,000, and a bespoke build from a custom Figma design at AED 15,000 to AED 25,000. Running it costs AED 200 to AED 1,500 a year in hosting and AED 100 to AED 500 a month in maintenance.
That maintenance line deserves attention, because a site nobody budgeted to maintain is how a lot of repair briefs begin: plugins left un-updated, backups never tested, a theme whose developer moved on. A rebuild that does not include a maintenance plan is setting up the next repair brief.
Platform choice matters less than it seems. WordPress, WooCommerce or Elementor appear in 316 of the briefs, 13.2 percent, against 54 for Webflow, Wix, Squarespace and Framer together. Some buyers have firm views the other way, too:
No AI site builders or drag-and-drop generators.
Whatever the platform, the questions that decide whether you are back here in two years are the same. Who edits the site, who updates it, and who holds the access.
A sensible order for a rebuild
- 1Recover and document every account and login.
- 2Crawl and export every URL, with the traffic and links each one carries.
- 3Inventory every tag, form, integration and DNS record.
- 4Decide what content stays, merges or goes before design starts. Content scope is the most common reason a Dubai web project overruns its quote.
- 5Build on staging, map the redirects, and test forms and conversions there.
- 6Launch, then check robots.txt, noindex tags, redirects and Search Console coverage on day one and again a week later.
Questions
Rebuild when the platform itself is the constraint: it cannot do what the business now needs, its theme or plugins are no longer maintained, or nobody on your team can edit it. Repair when the problem is speed, content or structure, because a rebuild carries those problems straight across to the new site.
Not if every ranking URL is either kept or permanently redirected to its closest new equivalent, tracking is carried across, and staging noindex settings are removed at launch. Most ranking losses after a rebuild come from changed URLs with no redirect map.
Robots.txt, noindex tags on key pages, that your contact form reaches a person, that ad conversions are firing, and that email still sends and arrives. Check again a week later, and watch the Search Console coverage report for the following month.
Recover it before anything else, and make that the first paid step of the project. Write down the registrar, DNS host, hosting, CMS, analytics and integration logins, and make sure the business, not a supplier, owns each account.
