Why your website is underperforming — and how to diagnose it yourself

1. The five reasons a website underperforms in the GCC

When a site underperforms, the team usually names what they can see. “The site is slow.” “We’re not converting.” “We’re not ranking.” That naming is the start of the diagnostic problem, not the end of it. The thing you can see is rarely what’s actually broken.

Most website underperformance traces to one of five repeating patterns in this market. The site is genuinely slow on the network and devices buyers actually use, not the dev laptop on office fibre. The flow leaks at predictable points — mobile checkout, missing payment options, Arabic-side regression. Nobody can find the site, either through organic search or in the local pack — and these are two separate problems most businesses conflate. The Arabic version is broken in ways the English-first team has never seen. The site looks fine from Dubai and slow from Riyadh, and nobody has tested from outside the office.

Two more layers cut across all five. Mobile is where consumer traffic actually arrives, comfortably the majority share in retail, F&B, hospitality, and most service categories, which makes mobile the primary surface to build for, not the viewport to adapt to. Trust signals (WhatsApp link previews, payment logos at checkout, Arabic copy that reads as written rather than translated) decide whether the prospect stays at the moment they’re about to share your link or complete a purchase.

The diagnostic discipline is to ask where the real failure is before throwing budget at “the website.” Most underperformance does not need a redesign. It needs a diagnosis. 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 costs less than a tenth of the redesign and delivers more measurable conversion lift.

This page walks the five reasons in order, then the two cross-cutting layers, then the opinionated framework that turns the diagnosis into a decision. If you want the fast version, run the Site Audit quick-check below. It scans for the most common failure modes in about ninety seconds and tells you which of the sections below are worth your time.

2. 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 the cause is almost always one of three things: an unoptimised hero image, render-blocking JavaScript, or fonts that delay text rendering.

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 and the one most teams haven’t caught up to. The page renders fast, but every tap, scroll, or interaction afterwards has a noticeable lag. That’s Interaction to Next Paint, which became a Core Web Vital in March 2024, replacing First Input Delay. INP measures responsiveness for every interaction, not just the first. A site that passed FID is likely failing INP if it carries heavy third-party JavaScript — which most do, because most marketing sites have accumulated tags and pixels over years without anyone auditing the runtime cost.

Two patterns matter more in this market than in Western performance analyses.

The first is the mobile share. Consumer traffic for retail, F&B, hospitality, and most service categories sits comfortably at the majority on mobile. A site that’s fast on desktop and slow on mobile is a site that’s slow for the channel actually carrying revenue. Performance tests run from a developer’s laptop on office fibre are systematically optimistic about what buyers experience. The desktop number is the edge case in this market, not the headline.

The second is the network condition variance. Mobile network performance in the GCC varies enormously across operators, indoor coverage, and time of day. Etisalat 5G in DIFC is excellent. Cellular in a Northern Emirates basement is not. Hotel Wi-Fi in JBR is variable. Smaller operators in the lower Gulf states lag. The buyer experience is the union of all of these, and no synthetic test captures it. Real-user monitoring (the data Google’s Chrome User Experience Report aggregates from actual visitors) is the only honest measure of what your site feels like in production. PageSpeed Insights pulls from CrUX, but the dashboard view of CrUX often lags real-user shifts by weeks.

A note on the loop between this section and the next pillar over. The performance numbers you’re looking at are themselves measured by analytics — usually GA4 reading from gtag, or PSI pulling from CrUX. If your analytics setup is wrong, your performance data is wrong too. The two diagnoses run in parallel.

→ Full prescription: site speed (coming soon)

3. Conversion: where buyers actually drop off

A site that gets traffic but doesn’t convert has a measurement problem, a flow problem, or a trust problem — usually all three, 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. The trust problem is the cheapest to address and the one most often skipped.

Where conversion actually leaks on GCC consumer sites, in the order we see most often in audits:

The mobile checkout. Majority-mobile traffic means majority-mobile checkout, and most checkouts are still designed desktop-first. Forms with desktop spacing. Address fields that don’t autofill correctly on iOS Safari. OTP verification flows that lose the page when the user tabs to their SMS app to read the code. Each of these is a known pattern with a known fix; most checkouts in this market still carry at least one.

The payment options that aren’t optional here. Buy-now-pay-later (Tabby and Tamara) is not a nice-to-have for retail in this region; for the under-thirty-five segment it’s table stakes. Saudi traffic without MADA loses checkout silently because MADA is the domestic payment network most Saudi cards run through, and a card declined silently at checkout doesn’t come back. Apple Pay is heavily adopted in the GCC and not offering it is a measurable friction. Cash on delivery remains legitimate in some segments, and rejecting it costs certain customer types entirely. A checkout that defaults to Visa and Mastercard only is a checkout designed for a market that isn’t this one.

The Arabic checkout regression. Bilingual sites here almost always have a polished English checkout and an Arabic checkout that’s quietly broken. UI text translated, error messages still in English. Validation that rejects Arabic numerals where users naturally type them. Payment forms that lose context when the user switches keyboards. The Arabic side is where bilingual sites lose Arabic-preference buyers, and most teams never see the regression because the team is English-first.

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 decide whether a hesitant buyer completes the transaction or abandons the cart.

The forced-account-creation problem. Forcing the user to create an account before checkout costs conversion in every market it’s been measured in. The justification is usually “for the loyalty program.” The fix is guest checkout with an account-creation offer at the end. Loyalty enrolment doesn’t drop; conversion improves.

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.

→ Full prescription: e-commerce conversion (coming soon)

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

Discoverability has two surfaces, and most businesses optimise one and ignore the other.

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 what most SEO work targets. 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 that appear above organic for any query with local intent. This is a completely different ranking system. The signals are different: proximity, prominence, and relevance via Google Business Profile rather than on-site SEO factors. The optimisation work is different. For any business with physical presence (retail, real estate, hospitality, clinics, professional services), the local pack is often where the highest-intent commercial traffic decides who to call. A business can rank first organically and be invisible in the local pack for the same query. Ranking on one surface does not carry to the other.

On the organic surface, two patterns matter more than they used to:

AI engine crawl access. ChatGPT, Claude, Perplexity, and Google’s AI Overviews use different crawler signatures and respect different parts of robots.txt configurations. A site that blocks GPTBot is invisible to ChatGPT citations. In this region AI search is being adopted faster than the global average, especially among professional buyers researching B2B services. The block is often a default someone enabled to “protect content” without knowing the downstream visibility cost. AI search isn’t a future surface to plan for here; it’s a current channel that’s already routing buyer queries.

Render-time SEO. Sites built on JavaScript frameworks (and most modern GCC builds are) can produce content that the user sees but the crawler doesn’t, if rendering isn’t configured for SEO. The audit is invisible from a regular page view: the page looks fine to a human. Run it through a headless crawler and the body is empty. This is the failure mode that hides longest because nobody notices until rankings have already dropped.

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

The Arabic-English business name canonicalisation problem. A business listed under both Arabic and English names risks Google treating them as duplicate listings and suppressing one, or splitting reviews and signals between the two. The fix involves choosing a primary name and using the alternate-name field correctly, but most GCC profiles were set up by someone who didn’t know that field existed and the two listings have been competing ever since.

The Apple Maps weighting. Apple Maps matters more in this region than in most Western local-SEO advice, because the device mix is iOS-heavy in core GCC markets (UAE, Kuwait, and Qatar in particular). A business with a clean Google Business Profile and a stale or unclaimed Apple Maps listing is invisible to a meaningful share of high-intent local searches. Most local-SEO content the region’s marketing teams read is written for Google-Maps-dominant markets, which means the Apple side gets skipped by default. Beyond Apple, the address realities themselves are different here: Makani codes in the UAE, PO Box conventions, multi-emirate franchise structures. Generic local-SEO advice rarely accounts for any of them.

→ Full prescription for the organic surface: technical SEO foundations (coming soon). For the local pack: local SEO (coming soon)

5. The Arabic-English question

If your site has an Arabic version, it’s probably broken in ways your team hasn’t seen. Bilingual is a system, not a translation pass, and the failure modes are systemic.

The most visible failures are at the layout level. Arabic is right-to-left, which means the entire UI flips, not just the text. Navigation, breadcrumbs, icons, sliders, progress bars, form alignment — all of them reverse. Most development teams treat RTL as direction: rtl and stop there. The visible result: icons pointing the wrong way (a “back” arrow still pointing left in an RTL flow, which is wrong), 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. Shaping, ligatures, kashida, and diacritics all add complexity that some browsers handle well and some don’t. A page that looks fine on Chrome desktop can break on iOS Safari or on older Edge versions. The breaks are visual: missing characters, broken ligatures, fallback fonts substituting in without the full Arabic glyph set. Testing on the device mix the audience actually uses (heavy iOS in GCC consumer markets) catches these. 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), country-coded (ar-AE for UAE-targeted Arabic rather than just ar), present on both versions, and matched against the canonical. Get any of those wrong and Google may treat the two language versions as competing duplicates instead of language alternates. That’s a real ranking penalty hiding in plain sight on most bilingual GCC sites we audit.

The deepest pattern is the quality gap. Arabic content on bilingual sites is almost always lower quality than the English side, because the review process is English-only. The English version goes through marketing, an editor, a brand check. The Arabic version goes through a translator (sometimes a machine) and ships. The result is an Arabic site that’s grammatically correct but reads as foreign to a native speaker, the equivalent of marketing copy that’s been technically translated but not actually written for the audience. The fix here isn’t a better translation engine. It’s a process change: an Arabic-native reviewer in the publishing workflow, the same way the English side has an editor.

→ Full prescription: bilingual and RTL (coming soon)

6. How your site looks from Riyadh, Mumbai, and London

A site that’s fast in Dubai is often slow in Riyadh, and the team that built it has never tested from outside the office. This is one of the most common geographic failure modes we see, and one of the most invisible.

CDN coverage maps tell a marketing story that doesn’t always match the routing reality. Cloudflare, AWS CloudFront, Akamai, and Fastly all claim regional coverage in the Middle East; what differs is where their actual edge presence sits and which transit paths your origin server can reach efficiently. UAE edge coverage is generally good across the major providers. Saudi edge coverage varies more than the brochures suggest. Smaller GCC markets (Kuwait, Bahrain, Oman, Qatar) are often served from Dubai or from Frankfurt rather than from a local edge, which adds round-trip latency invisible to a Dubai team running a Dubai test.

The pattern we see in audits: a UAE company expanding into Saudi, the marketing team hasn’t tested from a Saudi network, and the Saudi page-load experience is several hundred milliseconds slower than the UAE equivalent. The conversion difference shows up in the Saudi cohort’s drop-off rate before it shows up anywhere a UAE-focused team would look.

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 an invisible conversion leak: the user sees the wrong site, decides this business doesn’t serve them properly, leaves. Nobody on the marketing team knows it happened because the analytics shows a Saudi visit that bounced, not a Saudi visit that was shown the wrong currency.

Hosting location intersects with PDPL in a way that matters for compliance-sensitive sectors. UAE-hosted versus Frankfurt-hosted has different implications under the federal PDPL for certain data categories. Healthcare and financial data carry stricter localisation expectations than retail. Free zones with their own regulatory frameworks (DIFC and ADGM) run separate GDPR-aligned regimes that override the federal stance for entities incorporated there. The right hosting answer depends on which regulatory perimeter actually applies, and most procurement decisions are made without anyone asking that question first.

→ Full prescription: geographic performance (coming soon)

7. The mobile-first reality (and what most agencies still get wrong)

“Mobile-first” is a phrase that’s been used so broadly it’s lost meaning. The honest version: in this market, mobile is the primary surface, not a viewport to design for. Consumer traffic sits comfortably at the majority on mobile across retail, F&B, hospitality, and most service categories. Calling that “mobile-first” undersells the reality. The desktop view is the edge case.

What most agencies still get wrong, in the order we see most often:

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. The QA device is a recent iPhone or a high-end Samsung. The audience device is a two- or three-year-old Android with less RAM and a slower processor. JavaScript that runs fine on the QA device makes the audience device unresponsive for the first few seconds after page load. INP regressions are concentrated on the slower devices, which is also where the audience actually is. Performance budgets that pass on the QA device fail in the field.

Treating mobile network as a constant. Mobile network conditions in this market vary enormously, as the speed section above covered. A site tested on a fibre-connected MacBook with Chrome’s mobile emulation has been tested on a device that has none of the network constraints the audience actually experiences. Synthetic mobile testing is a useful sanity check; it is not a substitute for real-device, real-network testing on the devices and networks the audience uses.

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. The mobile buyer is not browsing-only in this market — they’re buying, and increasingly they’re buying things that used to be desktop-only purchases: insurance, B2B services, high-ticket retail, professional services. Designing as if the mobile buyer is window-shopping is the assumption that costs the most conversion in this market.

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

8. Trust signals that matter to GCC buyers

Trust signals decide whether a hesitant buyer becomes a customer. The signals that matter here are not the ones most generic conversion-optimisation advice covers.

WhatsApp link previews. WhatsApp is the dominant messaging platform in this region, used for both consumer and B2B sales conversations in ways that have no clean Western parallel. When a sales rep sends a product link, a customer forwards a page to a friend, or a journalist shares your press release, the preview that renders in WhatsApp is the first impression most recipients get of your site. A broken preview, or no preview at all, costs trust at exactly the wrong moment. The Open Graph tags that drive these previews are often missing or wrong: og:image undefined, og:title mirroring the page meta with no thought to social context, og:description pulling the first paragraph of the page even when it makes no sense out of context.

WhatsApp’s caching adds a wrinkle most teams don’t know about. The first time WhatsApp generates a preview for a URL, it caches that preview aggressively. If the first share happens before the OG tags are set correctly, the broken preview persists for hours or sometimes days even after the tags are fixed. The fix exists (running the URL through the right validator forces a cache refresh), but most teams discover the problem after the link has already been shared a hundred times with the wrong preview.

LinkedIn previews are the B2B equivalent. LinkedIn is the dominant B2B sharing channel in the GCC, and a site that shares badly on LinkedIn loses credibility every time it’s mentioned in a professional context. The dimensions LinkedIn wants are different from WhatsApp’s, and many sites use a single OG image dimensioned for one platform that renders awkwardly on the other.

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 targeting Saudi. Security copy that’s specific rather than generic (“payments processed by Stripe with 3D Secure” beats “secure checkout”). Phone numbers that resolve to humans during local business hours. A return policy that’s a real, linked document rather than a footer link to a placeholder page.

Arabic trust copy on bilingual sites is its own category. The English trust copy is usually fine. The Arabic equivalent is often missing, partial, or machine-translated. An Arabic-preference buyer reaching checkout and seeing English-only security copy reads that as a signal — and not a positive one. The Arabic side has been deprioritised, and at the moment of payment that signal carries more weight than at any other point on the site.

The cluster everyone gets vaguely wrong: testimonials, reviews, and trust badges. The signals that work here are concrete — the reviewer’s full name, photo, role, company, and a specific detail in the review. The signals that don’t work are abstract: a five-star average with no individual reviews surfaced, “thousands of happy customers” with no source, generic security badges from issuers no buyer recognises. Concrete trust is moat-building; abstract trust is noise.

→ Full prescription: social sharing and previews (coming soon)

9. Fix vs redesign: an opinionated framework

Most underperformance does not need a redesign. It needs a diagnosis followed by targeted fixes. 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 costs less than a tenth of the redesign and delivers 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 the one most often mishandled. Many sites 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 delays the conversion lift by the redesign’s duration, which is almost always longer than the timeline that was quoted. 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.

10. 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 any of the data you’ve seen so far. If GA4 shows implausible conversion counts, unexplained direct traffic, or three different numbers in three different reports, the rest of this list is built on sand. Without it, every fix below is being measured against a wrong baseline.

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 run the CWV Business Impact Checker to translate the performance numbers into revenue impact, which is the framing that makes the conversation with leadership productive instead of theoretical.

Day 4 is the discoverability check. Run the AI Crawler Access Checker to confirm your site is visible to the engines that matter. 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; this single field is one of the most under-managed and most heavily weighted signals in the entire local pack.

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

Day 6 is the geographic check. Run the GeoIP Site Viewer for Riyadh, Mumbai, and London. See what users in each location actually see when they hit your site. Look for currency wrong, language wrong, latency too high, or content that doesn’t apply to the visitor’s market.

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 run the OG/WhatsApp Preview Checker on any URL you’d consider sharing publicly.

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.

11. Get the full audit and the walkthrough