A CDN caching pages can keep showing "online" even after the origin server behind it has actually gone down. Check status, response time, and TTFB from multiple global locations in seconds.
A CDN sitting in front of a server is supposed to make a site faster and more resilient, and most of the time it does. But it can also paper over a real problem: if the origin server crashes while the CDN still has a cached copy of the homepage, a basic check requesting that cached page gets a clean 200 OK back from the edge, no idea the origin is down. The visible result says everything's fine while logins, checkouts, and anything requiring a fresh page render are actually broken.
Beyond that specific case, downtime in general gets noticed by search engines the same way it gets noticed by customers. A 5xx error or timeout during a Googlebot crawl gets flagged, and frequent enough downtime drags down crawl rate and eventually rankings.
A full diagnostic of the server's handshake with the rest of the world.
Downtime has an immediate and lasting impact on SEO. Here's how to diagnose and resolve the most common uptime problems your site may be experiencing.
Check error logs first (Apache: /var/log/apache2/error.log, Nginx: /var/log/nginx/error.log, WordPress: wp-content/debug.log). Common causes are a faulty plugin update, exhausted memory, or a database connection failure. A 503 usually means the server itself is overloaded.
Check whether a CDN is serving a cached copy of the page while the origin server behind it is actually unreachable. Add a cache-busting query parameter or check directly against the origin's IP, bypassing the CDN, to see the real status. Look at the cache-status response header too; it often reveals whether the edge served a hit instead of reaching the origin.
Check whether the server process is even running, whether a firewall is silently dropping requests, and whether the host itself is having an outage. A timeout from one region specifically may point to a CDN edge issue rather than a full outage.
Past 800ms, Core Web Vitals takes a hit. Server-side page caching, database query optimization, and a CDN for static assets are the highest-impact fixes; a well-cached WordPress page should serve in under 200ms.
A spot-check only reflects this exact moment, and the site could go down five minutes later. Continuous monitoring with instant alerts catches outages in under 60 seconds, before customers or Googlebot notice.
By the time a manual check confirms a problem, customers have already hit it. Being the first to know, not the last, is the entire point of continuous monitoring, including monitoring that's smart enough to check the origin directly rather than trusting whatever a CDN's cache happens to be serving.
Real visibility into whether the site, and specifically the origin behind any CDN, is actually healthy.
Everything you need to know about uptime monitoring and what it means for your SEO.
Yes. A CDN or reverse proxy with caching enabled can keep serving a stored copy of a page after the origin server stops responding entirely. A basic check sees a clean 200 from the edge and calls it healthy, while logins, checkouts, and anything needing a fresh request are actually broken. A cache-busting URL or a direct check against the origin reveals the real state.
A site can be reachable in one region and not another due to regional DNS failures or edge-server outages. A single-location check can look perfectly healthy while customers elsewhere genuinely can't connect.
Time to First Byte: the gap between a request and the first byte back. It feeds Largest Contentful Paint, one of Google's Core Web Vitals, and Google recommends staying under 800ms. A slow TTFB delays everything that follows.
A timeout means no response came back at all, usually overload, a firewall, or a network failure. A 5xx means the server responded but hit an internal problem. Both block access, but the fixes differ: timeouts point to infrastructure, server errors to the application.
A single brief outage rarely moves rankings, since Google tolerates occasional server errors. Persistent or frequent downtime reduces crawl rate, and pages returning 5xx for an extended stretch can eventually get de-indexed. Search Console's Coverage report is the place to check after a significant outage.
Uptime monitoring answers whether the server responds at all. Synthetic monitoring goes further, simulating real interactions like completing a checkout, catching failures in dynamic content and third-party integrations that a basic uptime check would miss entirely.
