Why your website is underperforming

What’s actually broken, and what to do about it

When a site underperforms, the team names what it can see. “The site is slow.” “We’re not converting.” “We’re not ranking.” That naming is where the diagnosis starts. What you can see is a symptom, and its cause can sit somewhere else entirely, so “we need a redesign” is a conclusion that belongs after the diagnosis. You can’t make that call honestly until you know which part is failing and why.

So the work runs in that order. First, where performance actually leaks:

• Speed. Whether the site is genuinely slow on the networks and devices buyers actually use, not the dev laptop on office fibre.
• Conversion. Where the flow leaks: mobile checkout, missing payment options, a broken Arabic checkout.
• Discoverability. Whether anyone can find you, through organic search or the local pack. The two need different work.
• The Arabic version. Broken in ways an English-first team never sees.
• Geography. The same site behaving differently depending on where it loads: fine from the Dubai office, slow from a network nobody tested.

Two more run through all of those: mobile, which carries most page views in five of the six GCC countries, and trust signals, which can decide whether a prospect stays at the moment they’re about to share your link or pay. Read each failure mode above with both in mind.

Then the decision they all feed into:

• Fix or redesign. Which failures need a targeted fix and which genuinely need a rebuild. We’ve seen six-figure redesign budgets spent on sites that needed a font-loading fix, a checkout change, and a Google Business Profile cleanup, at less than a tenth of the cost and with more measurable lift.
• What to do this week. A day-by-day plan to run the checks yourself and come out with a triage list.

For the fast version, run the free Site Audit. It runs the checks a crawler can do in a few minutes and points you to the failures worth your time.

Speed: is it actually slow, or does it just feel slow?

“Slow” gets used to describe three different things, and the fix is different for each.

Genuinely slow is when the largest content element takes more than two and a half seconds to render. That’s a Largest Contentful Paint problem, and on most sites that fail it, the image download is a small part of the wait. Google’s field data puts the median site with a poor LCP at 2,270 ms waiting for the server’s first byte and 1,290 ms more before the image starts loading, against 350 ms downloading it. So look at the server response first, then at anything that stops the browser finding the image in the HTML, then at render-blocking JavaScript and web fonts that hold back text.

Slow-feeling is when the page actually renders quickly but layout shifts in the next half-second. The eye reads that shift as broken. The metric is Cumulative Layout Shift, and it’s mostly solvable by handling fonts and images correctly — declaring dimensions on images, using font-display deliberately, and ensuring third-party embeds reserve their space before they load.

Slow-after-load is the newest of the three. The page renders fast, but every tap, click or key press afterwards has a noticeable lag. That’s Interaction to Next Paint, which became a Core Web Vital in March 2024, replacing First Input Delay. Where FID timed only the first interaction, INP watches every one. Third-party JavaScript is one way to fail it: a tag busy on the main thread when someone taps delays the response, and a third party’s timers are code you don’t control.

Two patterns shape speed in the GCC.

The first is the mobile share. StatCounter’s August 2026 figures put phones at 59.57% of page views in Saudi Arabia and between 50.61% and 52.62% in the UAE, Qatar, Kuwait and Bahrain. Oman is the exception, with desktop at 65.76%. Where phones lead, a site that’s fast on desktop and slow on mobile is slow for most of its visitors. Performance tests run from a developer’s laptop on office fibre are systematically optimistic about what those visitors experience.

The second is the spread between visits. A strong 5G connection in a business district and a dead spot in a basement are both your audience, and a synthetic test runs one fixed profile that sits somewhere between them. Real-user monitoring (the data Google’s Chrome User Experience Report aggregates from actual Chrome users) is the measure of what your site feels like in production. PageSpeed Insights pulls from CrUX, and CrUX covers the previous 28 days, so a fix shows up in its numbers gradually.

Where those numbers come from matters. CrUX is collected by Chrome itself, from users who have opted in to usage statistics, so a broken analytics setup doesn’t touch it. Core Web Vitals you send to GA4 are a separate copy. They arrive through the web-vitals library, and they are only as reliable as the tagging that sends them.

Working out which of the three metrics is actually costing you conversions is a different job from asking whether the site feels fast, and it is the one worth doing first.

Conversion: where buyers actually drop off

A site that gets traffic but doesn’t convert has a measurement problem, a flow problem, a trust problem, or some mix of the three. Work through them in that order. The measurement problem is invisible because the funnel report has gaps. The flow problem is fixable, but only after measurement is fixed, because until then you can’t see which step loses people. Trust fixes are mostly copy, badges and links, which makes them cheap to try.

Five places to check on a GCC consumer site:

The mobile checkout. Where most visits arrive on a phone, the checkout has to work on a phone first, and a desktop-first build shows its seams there: forms with desktop spacing, address fields iOS Safari can’t autofill, an OTP step that sends the buyer to their SMS app to read the code. Each has a known fix. For the OTP step it is autocomplete="one-time-code", which lets Safari’s keyboard suggest the code straight from the message.

The payment options. Buy-now-pay-later coverage differs by provider: Tabby serves the UAE, Saudi Arabia and Kuwait, and Tamara serves Saudi Arabia, the UAE, Kuwait and Bahrain, so neither is available in Qatar or Oman. mada is Saudi Arabia’s domestic card network. A merchant outside the kingdom can take mada cards as ordinary Visa or Mastercard debit cards, while processing them as mada needs a Saudi acquirer. Apple Pay works in all six countries and reaches furthest where iOS is strongest: 53.85% of mobile page views in Bahrain and 51.96% in Saudi Arabia, against about a fifth in the UAE, Qatar and Oman. Build the payment list country by country.

The Arabic checkout. On a bilingual site, test the Arabic checkout as a flow of its own, because its defects don’t show on the English side: UI text translated while error messages stay in English, or validation that rejects Eastern Arabic numerals. A team that tests only in English won’t see either.

Trust signals at the moment of payment. The Apple Pay logo visible above the payment form. Card brand badges that match what’s actually accepted. A phone number that resolves to a human during local business hours. A return policy that links to a real document, not a placeholder. These cost almost nothing, and they can decide whether a hesitant buyer completes the transaction or abandons the cart.

The forced-account step. Requiring an account before checkout costs orders. Among US shoppers who had abandoned a cart for a reason other than browsing, Baymard found 18% naming an account requirement as one of those reasons. The fix is guest checkout with an account-creation offer at the end, which keeps the loyalty sign-up out of the buyer’s way.

Conversion measurement is the layer underneath all of this. If your e-commerce events fire wrong, your funnel analysis is wrong, and you’ll fix the wrong step.

The narrower question is the handful of checkout steps where buyers actually abandon, and it is a far more tractable one than “improve conversion”.

Discoverability: does Google (and ChatGPT) even know you exist?

Discoverability has two surfaces, and each needs its own work.

The first surface is the organic index — Google and the AI engines (ChatGPT, Perplexity, Google’s AI Overviews) finding your pages, understanding what they’re about, and surfacing them in search results. This is the surface SEO work aims at. Schema markup, canonicals, redirects, sitemap hygiene, render quality, internal linking. The technical foundations that decide whether the crawler can read what you’ve published.

The second surface is the local pack, the map results Google shows for queries with local intent. It ranks on its own terms. Google names relevance, distance and prominence, and your Business Profile carries much of what feeds them: the details you fill in, your location and your reviews. Prominence also counts links to your business from other websites, so the two surfaces share a signal, but a business can rank first organically and still miss the pack for the same query. For any business with physical presence (retail, real estate, hospitality, clinics, professional services), both surfaces belong on the list.

On the organic surface, two things need checking:

AI engine crawl access. ChatGPT, Claude, Perplexity and Google each publish their own crawler names, and robots.txt treats each name separately, so which names a block lists decides what it does. OpenAI’s GPTBot and Anthropic’s ClaudeBot collect training data, while OAI-SearchBot and Claude-SearchBot index pages for search answers. Blocking GPTBot tells OpenAI not to train on your content, and leaves you in ChatGPT search. Blocking OAI-SearchBot takes you out of ChatGPT’s search answers, and blocking Claude-SearchBot or PerplexityBot can cut your visibility in theirs. Google’s own AI opt-out, Google-Extended, doesn’t affect Search. Generative AI has a wide audience here: Microsoft’s AI Diffusion Report puts its use in early 2026 at 70.1% of working-age people in the UAE, 41.8% in Qatar, 29.4% in Saudi Arabia, 26.5% in Oman and 21.1% in Kuwait, against 17.8% worldwide. Before you keep a crawler block added to “protect content”, check which bots it names.

Render-time SEO. A site built on a JavaScript framework can show visitors content a crawler never receives, if that content only appears after scripts run. Google renders pages in a headless browser before indexing, but not every crawler runs JavaScript. A normal page view won’t show the problem, because the page looks fine to a human. Open the raw HTML the server sends and the body can be empty. Google’s URL Inspection tool shows what Google itself rendered.

On the local surface, two patterns are specific to this market:

The Arabic-English business name canonicalisation problem. Google allows one Business Profile per business. A profile under the Arabic name and another under the English name puts two profiles at one address, and Google hides a profile it treats as a duplicate: it “won’t show on Google Search or Maps”. The fix is to pick the one name customers meet on the storefront and use only that. Google’s guidelines list “repeated bilingual names / script transliterations” as a prohibited name format, and the prohibition holds even when both scripts genuinely appear on your signage. There is no alternate-name field to fall back on: advice telling you to put the second script there is describing a field the profile does not have, and putting both names in the one field it does have is a suspension risk rather than a workaround.

The Apple Maps weighting. How much Apple Maps matters depends on the country. In StatCounter’s August 2026 figures, iOS runs 53.85% of mobile page views in Bahrain and 51.96% in Saudi Arabia, 44.81% in Kuwait, and about a fifth in the UAE, Qatar and Oman. That share caps how far Apple Maps can reach, since iPhone owners can use Google Maps too, but it shows where the cap sits highest. Claim the Apple Maps listing everywhere, and put it near the top of the list in Bahrain and Saudi Arabia, with Kuwait close behind. Beyond Apple, the address realities themselves are different here: Makani numbers in Dubai and four northern emirates, and franchises that span several emirates. Check that your listings handle both.

Two things follow from that. The crawlability and schema work that decides whether you are eligible to rank at all, and the map-pack and address specifics that behave differently in this region. They are separate problems.

The Arabic-English question

If your site has an Arabic version, check it for breakage your team may not have seen. A bilingual site works as a system, so its failures are systemic too.

The most visible failures are at the layout level. Arabic is right-to-left, so the interface mirrors along with the text. Navigation, breadcrumbs, sliders, progress bars and form alignment reverse, and so do icons that show direction. Logos, checkmarks and icons of real objects, such as a clock, stay as they are. An RTL stylesheet has to handle the icons and animations as well as the text direction. When it doesn’t, the result is visible: a “back” arrow still pointing left in an RTL flow, sliders animating in the wrong direction, progress bars filling from the side that reads as backwards to an Arabic eye. None of this errors. The page works. It just reads as wrong to an Arabic speaker, the way a slightly-off translation feels wrong to a native even when all the words are technically correct.

The less visible failures are at the render level. Arabic font rendering is meaningfully harder than Latin. Contextual letter forms, ligatures and diacritics all add complexity, and a font or fallback that lacks the glyphs or the shaping rules shows it. The breaks are visual: missing characters, broken ligatures, fallback fonts substituting in without the full Arabic glyph set. Testing on the devices your audience uses catches these, and the lead platform changes by country: iOS in Bahrain and Saudi Arabia, Android in Kuwait, the UAE, Qatar and Oman. Testing on a single dev browser doesn’t.

The structural failures are the deepest, because they affect ranking and discoverability rather than just appearance. Hreflang done right is reciprocal (English version points to Arabic, Arabic version points to English), present on both versions, region-coded when a version targets one country (ar-AE for UAE-targeted Arabic), and paired with a canonical in the same language. Break the reciprocity and Google ignores the tags, so a searcher can land on the wrong language version. Translating a page doesn’t make it a duplicate, though: Google counts one only when the main content is left untranslated.

Then there is the quality gap. When the English version goes through marketing, an editor and a brand check, and the Arabic version goes through a translator (sometimes a machine) and ships, the Arabic site ends up grammatically correct but foreign to a native speaker, like marketing copy that was translated without being written for its audience. The fix is a process change: an Arabic-native reviewer in the publishing workflow, the same way the English side has an editor.

The rest of it, RTL layout, hreflang reciprocity, font rendering and the language switcher, is where an Arabic site drifts from its English half.

Why one GCC market is slower than another

The same site is not the same speed in every GCC market, and a team that only tests from its own office won’t find out which markets are worse.

CDN coverage in the GCC depends on the provider, and the published maps differ most in the smaller markets. Cloudflare lists locations in Kuwait City, Manama, Muscat and Doha. CloudFront lists Bahrain, Muscat and Doha, with nothing in Kuwait. Fastly’s GCC locations are Dubai, Fujairah and Riyadh, so none of the four smaller markets has one. All three list Saudi and Dubai locations, so if the two markets in question are Dubai and Riyadh, coverage is not the variable and the cause sits elsewhere. A visitor in one of the smaller markets without a local edge is served from further away, which adds round-trip latency a Dubai team never sees running a Dubai test.

Take a UAE company expanding into Saudi Arabia. If its marketing team tests only from UAE networks, a slower Saudi experience stays out of sight, and the difference shows up first in the Saudi cohort’s drop-off rate, a number a UAE-focused team may not be watching.

Geographic discoverability has another layer beyond latency. Geo-detection that goes wrong sends the wrong content to the wrong audience. A Saudi user redirected to UAE-specific pricing in AED rather than SAR. A Kuwait user shown the Arabic version when they prefer English. A user on a corporate VPN routed somewhere their actual location wouldn’t be served from. Each of these is a conversion leak the marketing team never sees: the user gets the wrong site, decides this business doesn’t serve them properly, and leaves. The analytics shows a Saudi visit that bounced, not a Saudi visit that was shown the wrong currency.

Hosting location intersects with data law in a way that matters for compliance-sensitive sectors. In the UAE, the federal PDPL lets personal data leave the country only on the conditions it lists, such as adequate protection at the destination or the person’s express consent, so UAE-hosted and Frankfurt-hosted setups aren’t equivalent. Health data sits under its own federal law, which bars storing or processing data from UAE health services outside the country unless an official decision allows it. Banking and credit data also fall under their own legislation, and the PDPL steps aside for both. Free zones with their own data protection law, DIFC and ADGM among them, run separate GDPR-modelled regimes, and the federal PDPL doesn’t apply to entities there. The right hosting answer depends on which regulatory perimeter applies, so settle that before procurement starts.

Seeing what your site actually does from Riyadh versus Dubai versus London settles the hosting question faster than any procurement discussion will.

The mobile-first reality (and where it breaks down in practice)

“Mobile-first” is a phrase that’s been used so broadly it’s lost meaning. The honest version: in five of the six GCC countries most page views arrive on a phone, which makes mobile the primary surface there. Oman, where desktop still carries about two-thirds of page views, is the exception.

Where mobile-first breaks down in practice:

Treating mobile as a smaller desktop. The mobile experience gets a squeezed-down navigation, smaller versions of desktop-sized images, and a checkout that’s the desktop checkout in a narrower column. The cleaner approach is to design the mobile experience as the canonical one and adapt it upward to desktop, not downward from it. The information architecture, the hierarchy, the calls to action — all of these should be optimised for the smaller surface first, because that’s the surface the audience actually uses.

Testing on the wrong device. A recent flagship phone is faster than the mid-range and older phones in your audience’s hands, so JavaScript that runs fine on it can leave a slower phone unresponsive for the first few seconds after page load. INP shows the gap: the Web Almanac 2025 found 77% of sites with good INP on mobile against 97% on desktop. Performance budgets that pass on the flagship can fail in the field.

Treating mobile network as a constant. A site tested on a fibre-connected MacBook with Chrome’s mobile emulation has been tested without any of the network constraints a phone meets in the field. Synthetic mobile testing is a useful sanity check, and real-device, real-network testing on the devices and networks the audience uses is the fuller test.

Treating mobile as inferior for “real work.” This shows up in checkout design where the desktop flow is optimised and the mobile flow is a port. On the primary surface, that flow has to carry buyers as well as browsers, and one designed for window-shopping costs conversion.

Mobile-first means the mobile experience is the experience. Everything else is a derivative of it.

Trust signals that matter to GCC buyers

Trust signals can decide whether a hesitant buyer becomes a customer. Some sit on the checkout page. Two of the easiest to break sit outside your site altogether, in the previews your links produce when people share them.

WhatsApp link previews. When a sales rep sends a product link, a customer forwards a page to a friend, or a journalist shares your press release over WhatsApp, the preview can be the recipient’s first look at your site. A broken preview, or no preview at all, costs trust at exactly the wrong moment. WhatsApp builds the preview from Open Graph tags. Its developer documentation requires og:title, og:description and og:url in the page head, and an og:image under 600 KB, at least 300 pixels wide and no wider than 4:1. Three faults to look for: an og:image that was never set, an og:title copied from the page title with no thought to social context, an og:description pulled from a first paragraph that makes no sense on its own.

WhatsApp documents no way to refresh a preview it has already built, so set the tags before a link goes out, and send a new page to yourself first to see what recipients will get.

LinkedIn builds its previews from the same tags and sets its own image rules: at least 1200 × 627 pixels, a 1.91:1 ratio, up to 5 MB. Meta publishes a third set for Facebook sharing and recommends at least 1200 × 630. Ship 1200 × 630 and one file clears all three: it is above LinkedIn’s 627 floor, it matches Meta’s recommendation, and it sits inside WhatsApp’s 4:1 ratio. The ceiling that bites is file size. A JPEG of that card lands in the low hundreds of kilobytes, while a lossless PNG of the same artwork runs to megabytes before compression and breaks WhatsApp’s 600 KB limit.

Payment trust at checkout sits one layer down. Payment logos that match the actual options accepted: the Apple Pay mark, the Tabby badge, the mada logo on sites selling into Saudi Arabia. Security copy that’s specific (“card payments verified with 3D Secure” beats “secure checkout”).

Arabic trust copy on a bilingual site needs its own check. If the English security copy is in place and the Arabic equivalent is missing, partial or machine-translated, an Arabic-preference buyer reaching checkout can see that the Arabic side got less care, at the step where they’re asked to pay.

Then there are testimonials, reviews and trust badges. Concrete signals give a buyer something to check: the reviewer’s full name, photo, role, company, and a specific detail in the review. Abstract ones give them nothing: a five-star average with no individual reviews surfaced, “thousands of happy customers” with no source, generic security badges from issuers buyers don’t recognise.

The same logic governs how your link looks when somebody pastes it into WhatsApp, which can be the first thing a buyer sees of your site.

Fix vs redesign: an opinionated framework

A redesign is one answer to underperformance, and the diagnosis decides whether it’s the right one. We’ve seen six-figure redesign budgets spent on sites that needed a font-loading fix, a checkout flow change, and a Google Business Profile cleanup: work that cost less than a tenth of the redesign and delivered more measurable conversion lift.

The framework that distinguishes fix from redesign:

Fix when the diagnosis points to specific failures with specific causes. CWV regression from font loading? Fix. Conversion drop on mobile checkout? Fix. Bilingual breakage in the Arabic checkout? Fix. AI crawler blocked? Fix. Local pack invisibility from a misconfigured Google Business Profile? Fix. Each of these has a known cause and a known remediation path. The work is bounded, measurable, and verifiable, and the budget is a fraction of a redesign’s.

Fix-then-evaluate when the foundations are sound but the experience has aged. Information architecture that worked for the business of three years ago and doesn’t match the catalogue of today. A design system that’s accumulated inconsistencies. Brand expression that’s drifted from where the company has actually gone. These don’t need a wholesale rebuild; they need a structured update pass with clear before-and-after measurements, ideally sequenced after the diagnostic fixes so the impact of each layer is legible.

Redesign when the diagnosis points to architecture-level mismatch. The site was built for a product line you no longer sell. The CMS doesn’t support a workflow you now need — multi-language, multi-region, multi-brand, headless commerce. The performance ceiling is set by structural decisions (a heavy framework, a monolithic template approach) that can’t be tuned away. The conversion model is fundamentally wrong (a brochure site selling what should be an e-commerce site, or vice versa). When these are the actual diagnosis, redesign is the honest answer.

The honest middle case is where the call gets hard. A site can need a redesign eventually but not immediately. A site that’s underperforming today and needs structural change in twelve to eighteen months should be treated as two projects: the diagnostic-and-fix project that buys the conversion lift now, and the redesign project that addresses the structural issues on a planned timeline. Conflating them as one big redesign holds the conversion lift back until the redesign ships. The fix-first sequencing is also better diagnostic input for the eventual redesign. You go into it knowing which problems were structural and which were just neglected.

If you’ve inherited the site rather than built it, the diagnosis-first discipline is even more important. The previous team’s architectural decisions are not transparent to you; the redesign instinct is partly an instinct to make the unfamiliar familiar by rebuilding. The cheaper move is inventory and audit before deciding.

What to do this week

If you’ve read this far, the next step is sequencing. The order matters; doing the right work in the wrong order wastes time, and several of the diagnoses depend on each other.

Day 1 is the measurement check. Confirm your analytics is producing trustworthy numbers before you act on its traffic and conversion data. If GA4 shows implausible conversion counts, unexplained direct traffic, or three different numbers in three different reports, any fix you judge by conversions is being measured against a wrong baseline. Field speed data is the exception: Chrome collects it, so it stands apart from your analytics.

Days 2 to 3 are the performance baseline. Run PageSpeed Insights on your three highest-traffic pages — not just the homepage, the actual revenue pages. Capture LCP and INP specifically, then translate those numbers into revenue impact — the framing that makes the conversation with leadership productive instead of theoretical.

Day 4 is the discoverability check. Confirm your site is visible to the engines that matter: check that your robots.txt isn’t blocking the search crawlers (Googlebot, OAI-SearchBot, Claude-SearchBot, PerplexityBot), and that your pages render server-side rather than only in the browser. Search your brand and three of your category terms on Google and on ChatGPT and Perplexity. If you have physical presence, search the local-pack queries (“[your category] in [your city]”) and see whether you appear. Check your Google Business Profile primary category against what your business actually does; Google lists what kind of business you are among the details it uses to match a profile to a search.

Day 5 is the bilingual audit. If you run an Arabic site, click through the Arabic version on an iPhone and on an Android phone. Note what looks misaligned, off-tone, or visibly wrong. Then check the systemic issues a manual click-through won’t catch — hreflang configuration, font fallback behaviour across browsers, and translation completeness across the templates.

Day 6 is the geographic check, and it splits into two questions. What a visitor is served you can test yourself: a VPN with an exit in the market shows you the currency, the language, and whether the content applies there. How fast it arrives you cannot. A VPN reading is your own leg to the exit node plus that node’s leg to your origin, which is a longer path than a local visitor’s and tells you more about where you are sitting than about them. For that question, segment your field data by country, or run a synthetic test from an agent actually in the market. WebPageTest’s public locations cover Dubai, Mumbai and London.

Day 7 is the social sharing check. Share your homepage and your highest-traffic landing page in a WhatsApp message to yourself, then in a LinkedIn post. Look at the previews. Then validate any URL you’d consider sharing publicly with Facebook’s Sharing Debugger and LinkedIn’s Post Inspector — both force a fresh fetch of your Open Graph tags and surface what’s missing.

By the end of the week you’ll have a triage list. The fixes that are cheap and high-impact (font loading, OG tags, Google Business Profile primary category) go first. The fixes that need engineering work (data layer expansion, server-side tagging, schema implementation, CDN reconfiguration) go on the roadmap with sequencing. The work that points to architectural issues (CMS-level constraints, framework-level performance limits, IA that no longer matches the business) gets the redesign conversation it deserves, on the right timeline.

The discipline is the diagnosis. The redesign instinct comes after.

Get the full audit and the walkthrough

If you’d rather not run the week-long diagnostic yourself, Bracketworks does it end to end — a full audit across everything above, the findings sequenced into a fix-first plan, and a walkthrough of what actually matters for your market rather than a generic checklist.

Want a head start? The free Site Audit below covers the part of this that a crawler can settle on its own — speed signals, findability, and the journey checks — and gives you a fast read on where to look first.