Exabytes Hosting vs Cloudflare for SEO Performance

KL Latency: Penang Origin vs Edge Routing

Exabytes operates its own data center in Penang and resells Alibaba Cloud’s Kuala Lumpur region (ap-southeast-3) for its cloud lineup. Most shared hosting and business hosting plans pin your site to the Penang floor. A Unifi residential line in Bangsar to Penang costs roughly 7–12ms RTT over TM’s northern fiber backbone. That is fine for humans. Googlebot is the problem: Google’s crawler fleet pulls Malaysian sites predominantly from Google Singapore infrastructure, which adds a cross-border hop to your origin — typically 18–30ms RTT before any packet touches your server.

Cloudflare shifts the endpoint answer for Googlebot. The Cloudflare Kuala Lumpur PoP terminates the bot’s TLS connection locally, and your origin server only receives a fetch when the object misses cache. On a `cf-cache-status: HIT` for HTML, you effectively remove Penang, Singapore, and the Strait of Malacca from the crawl path. On a `MISS` or `DYNAMIC` response, your request does the KL → Penang hop twice — once at the edge fetch level, once through Cloudflare’s backbone — which can push TTFB above what Exabytes alone would have produced.

Core Web Vitals: What Exabytes Alone Serves

Exabytes’s Business and Premium shared plans run on LiteSpeed with cPanel, which gives you `X-LiteSpeed-Cache` header options for WordPress — but only if you set up the LiteSpeed Cache plugin with page cache enabled. Without it, PHP still executes on every request. A typical Malaysian WooCommerce store on Exabytes with 25 plugins serves LCP between 2.4s and 3.8s on 4G, mostly due to the uncached first-byte wait and unoptimized images being pulled direct from Penang.

Slap Cloudflare’s edge on the same store and you change the metric profile: images, JS, and CSS now come from the KL PoP with Brotli compression and HTTP/3 if you toggle those features. Cloudflare Polish (available on Pro) strips Exif data and recompresses JPEGs at the edge. You still must handle the dynamic PHP payloads. The realistic outcome is LCP dropping to 1.8s–2.6s for a cached home page, while /cart and /checkout remain identical to the Exabytes-only baseline because they should never be cached.

Cloudflare Cache Keys and Googlebot Crawl Budget

A crawl budget issue occurs when Googlebot’s requests to the Penang origin get rate-limited or choked under concurrent crawl connections. Exabytes shared hosting has no built-in bot management layer; a single aggressive crawl can burn CPU and cause 503s. Cloudflare, in front, gives you two concrete levers:

– Cache rules / page rules: Force HTML caching for URLs matching `/blog/` with a 1-hour TTL, while bypassing `/wp-admin/`, `/cart`, `/my-account`, and anything with cookies. Set the cache key to include `host` but exclude `query` for canonical URLs so Googlebot does not generate unique cache entries per tracking parameter.

– Bot fight mode: Cloudflare’s default challenge will not be triggered by Googlebot if you whitelist the documented Googlebot IP ranges under `Bot Management` or `Firewall Rules`. The value-add is that you see crawler rates in the analytics dashboard and can verify a `cf-cache-status: HIT` ratio above 80% before you sit back and call it done.

Without these rules, Cloudflare simply becomes a middleman that forwards every HTML request to Penang, and your crawl-to-bandwidth cost gets worse, not better.

SSL Termination: Where the TLS Handshake Happens

Exabytes shared cPanel includes AutoSSL (Sectigo/Let’s Encrypt) at no cost. That works for Chrome and Googlebot, but the handshake completes at Penang — roughly 2 network round trips plus OCSP checks. Cloudflare terminates TLS at the KL edge on its anycast IPs. The handshake for Googlebot then completes inside the same metro area as the crawler fetch, and session resumption (0-RTT) applies for repeat crawls. That is measurable: TLS handshake time reported in PageSpeed Insights often drops from ~120ms to ~15ms when the endpoint moves from Penang to KL edge.

The trap is the SSL mode selection in Cloudflare. `Flexible` breaks mixed content and can cause SEO redirect loops because the edge speaks HTTP to the origin. The correct setting is `Full (Strict)` with an origin cert installed on the Exabytes server — cPanel’s SSL/TLS section handles this without touching your AutoSSL setup. Log in to Cloudflare, set SSL/TLS mode to Full (Strict), and confirm your origin’s `nginx`/LiteSpeed config is not forcing `http→https` redirects at the application layer, or you will fight a redirect storm with Googlebot.

Tuned Stack: Exabytes Origin Behind Cloudflare Proxy

The practical configuration for a Klang Valley business running WordPress on Exabytes:

1. Point the domain’s nameservers to Cloudflare (free plan is sufficient to start).

2. Create an A record with the Exabytes Penang IP set to Proxied (orange cloud).

3. Enable SSL mode `Full (Strict)` and install a Cloudflare Origin CA certificate into cPanel.

4. Use the default WordPress cache rule in Cloudflare dashboard — HTML cache 2 hours, bypass on `wp-admin`, `wp-login`, `cart`, `checkout`, `my-account`.

5. Turn on Brotli and HTTP/3. Leave Polish on “off” if your images are already compressed; otherwise enable `Polish (Lossless)` on the Pro plan.

6. Monitor `/cdn-cgi/trace` in a headless fetch to verify the `ip` field shows the KL PoP, and monitor `cf-cache-status` in response headers during Googlebot crawls.

If your Exabytes plan is the entry shared tier (2GB RAM equivalent), add the Cloudflare `cache reserve` only if you are on the Pro plan and your static asset ratio is above 60%. Otherwise, the origin fetch cost on a cold cache will drag TTFB past your Exabytes-only baseline. The correct, SEO-first behavior is to treat Cloudflare as a cache layer for read-heavy pages, not as a universal fix for a weak server.