Website works for me, but not customers in Dubai
A customer says your website will not load on their phone. You open the same address from the office in Dubai and it comes up straight away. The obvious conclusion is that their device is the problem.
Sometimes it is. Often enough, it is not.
A successful load on one laptop, through one office connection, proves that one route reached the website at that moment. It does not prove that customers on another mobile carrier, home broadband connection, DNS resolver or internet protocol route are getting the same answer.
That distinction matters when the website is meant to generate enquiries. A regional failure can quietly shut out people trying to view services, check a location or submit a contact form, while everyone internally keeps seeing a healthy homepage.
Compare the routes, not just the screen
The useful question is not whether the website is online in the broadest sense. It is whether a visitor can resolve the domain, establish a secure connection, reach the right server and receive a current page from their network.
For a proper regional fault, a website repair review for Dubai businesses should trace the request from more than one route. That means comparing office Wi-Fi with mobile data, trying a second DNS resolver, and checking whether IPv4 and IPv6 visitors are being sent somewhere different.
Website availability can differ by network because DNS records, CDN edge locations, IPv4 and IPv6 routing, SSL configuration, firewall rules and cached responses are not necessarily identical for every visitor. A site may work from one connection while another receives a timeout, an old page, a certificate warning or a different server response. Testing from multiple networks and locations is the practical way to separate a visitor-side fault from a regional website issue.
A Dubai scenario that catches people out
A business can load its WordPress site on office Wi-Fi without any bother. Customers using mobile data, though, receive a timeout. The domain may resolve through a different DNS path, or the mobile network may prefer an IPv6 address that was never properly configured at the host or CDN.
The homepage being visible in the office does not cancel out the customer report. Both observations can be true.
IPv6 is a particularly dull little trap. If an AAAA record points to an address that is unavailable, misconfigured or blocked upstream, visitors whose connection prefers IPv6 can fail while IPv4 visitors carry on as normal. Nobody needs a dramatic server outage for that to happen.
Run a small regional availability check
Before changing WordPress settings, take a short record of what different routes are doing. Keep the URL exact, including whether the visitor used www, a non-www address, a service page or a campaign landing page.
- Open the same URL on office Wi-Fi and on a mobile connection from a different carrier.
- Check both the main domain and the www version, if both are intended to work.
- Compare DNS results from more than one resolver and look for unexpected A or AAAA records.
- Check whether IPv4 and IPv6 return the same expected destination and status.
- Record the HTTP response, redirect destination, certificate behaviour and approximate time of the test.
- Test a page beyond the homepage, especially a contact page or lead generation landing page.
A contact form can make this more awkward. A customer may reach an old cached version of the page with an outdated phone number or a WhatsApp link going to the wrong number, while the owner sees the current version. The page has technically loaded, but it is still costing the business enquiries.
Where DNS and CDN behaviour split apart
DNS tells a visitor where to start. A CDN may then decide which edge location serves the request. Both layers can create a mismatch without the WordPress installation itself being broken.
Look for a stale DNS record after a migration, a forgotten subdomain, a CDN edge still holding an old response, or a cache rule that treats mobile and desktop traffic differently. If the issue began after a hosting move, do not assume the old record disappeared simply because the office router has already picked up the new one.
Cached content has its own fingerprints. If some visitors see an old homepage, outdated sitemap or a page version that no longer exists in WordPress, the problem may be a cache layer rather than DNS. The same logic applies when a WordPress sitemap is stuck behind a stale cache layer: establish which layer supplied the response before editing content that may already be correct.
Certificate errors are route-specific clues
A certificate warning can also appear for some visitors and not others when a CDN, load balancer or old origin server serves the wrong certificate on one path. Check the exact hostname in the warning, the certificate expiry, and whether the failing route lands on a different IP address.
Do not brush off a report because the padlock looks fine on your own connection. A valid SSL but unsafe page diagnosis can help separate certificate problems from mixed-content warnings and browser-side issues. They are related, but they are not interchangeable.
Firewall rules can block a real customer without blocking you
Security rules may block an IP range, country setting, user agent or rate pattern that does not affect the office connection. This can happen after a firewall rule is tightened, a CDN setting changes, or a hosting provider adds protection upstream.
Do not immediately turn security off to prove a point. Record the failing network, time, URL and response first. A useful test is to compare a browser request with a simple request to the same URL, then check server, CDN and firewall logs for the relevant time window. Without that, people tend to disable three things, clear every cache and lose the one useful clue.
What counts as enough evidence to escalate
You do not need to become a network engineer to report this properly. Give your developer, host or CDN provider the domain, affected URL, failing network or carrier, approximate location, date and time, browser error, and whether IPv4 or IPv6 was involved where known.
That is enough to move the conversation from it works for me to a traceable fault. It also prevents a genuine customer access issue being filed away as somebody having a funny phone.
Message Standish Services on WhatsApp if you need regional availability traced properly. Test the same URL from another network before assuming the customer’s device is the problem.