Website Status Checker
Enter up to 100 URLs (Each URL must be on separate line)
About Website Status Checker
Your site appears live to you — you can open it in your browser, navigate it normally, buy products from it. But three of your most important pages are silently returning a 500 Internal Server Error to Googlebot. You will not see the problem in your browser because your browser cached the page. But Googlebot has been seeing the error every time it crawls. Rankings for those pages have been quietly sliding for two weeks and you have no idea why.
This is why checking your server's actual HTTP response — not just loading a page in a browser — matters. The DigitalSub Pro Server Status Checker makes a direct HTTP request to any URL and returns the raw status code the server sends back: 200 OK, 301 Moved Permanently, 403 Forbidden, 500 Internal Server Error, or any other HTTP response code. You see exactly what crawlers see, along with the response time — in seconds, without a browser, without caching, without any filtering.
This page explains every HTTP status code your site can return, what each one means for your users and for SEO, how long a server can be down before Google starts dropping your rankings, and what to do when your server is showing errors that are harder to spot than a complete outage.
- What the Tool Shows You
- What an HTTP Status Code Is — and Why It Matters
- All HTTP Status Code Categories Explained
- Server Response Time — What the Numbers Mean
- Downtime and SEO — How Long Before Rankings Drop
- The 503 Maintenance Strategy — Protecting Rankings During Downtime
- Common Server Errors and What Causes Them
- How to Use the Server Status Checker
- Who Uses This Tool — and When
- Pro Tips for Server Status Monitoring
- Related Tools
- Frequently Asked Questions
What the Tool Shows You
The checker makes a direct HTTP request to any URL you enter and returns the raw server response — the status code, a plain-English description of what that code means, and the response time in milliseconds. Here is what a set of results looks like, showing four different types of response across different sites.
The green LED means the server is healthy. Yellow indicates a redirect. Red indicates an error or unavailability. Response time shows how quickly the server responded.
What an HTTP Status Code Is — and Why It Matters
Every time a browser, a search engine crawler, or any other HTTP client requests a URL, the server responds with a three-digit status code before sending any content. This code is the server's immediate, standardised answer to the request — it tells the client whether the request succeeded, failed, was redirected, or triggered a server-side problem.
The status code travels in the HTTP response header — the invisible part of every web response that precedes the actual page content. Users never see it directly (their browser interprets it and acts accordingly), but search engine crawlers read it on every single request and use it to make decisions about indexing, crawl frequency, and ranking signals.
The critical distinction: a page can look perfectly normal to a human visitor and still return a problematic status code to search engine crawlers. Browser caching, CDN edge caching, or geographic routing can mean that what you see when you open your site is not what Googlebot sees when it requests it. This is exactly why running an independent, uncached status check is necessary — particularly after server changes, plugin updates, or unusual traffic events.
All HTTP Status Code Categories — What Each One Means for SEO
HTTP status codes are grouped into five categories by their leading digit. Each category represents a fundamentally different type of server response, and each has distinct implications for users, crawlers, and search engine rankings.
Informational Responses
Request received, processing continues — rarely seen in practice
Success — Everything Worked
The request was received, understood, and processed successfully
Redirection — Content Has Moved
The requested resource is available at a different URL
Client Errors — Problem With the Request
The server received the request but cannot fulfil it due to a problem with the request itself
Server Errors — Problem on the Server Side
The server failed to fulfil a valid request — the problem is on the server, not the client
Server Response Time — What the Numbers Mean
Response time is the number of milliseconds between the moment an HTTP request is sent to a server and the moment the first byte of the response is received. This is called Time to First Byte (TTFB) and is one of the earliest measurable signals in a page's load journey — and one that Google uses as part of Core Web Vitals assessment.
Server response is near-instant. Hosting is fast and well-configured. CDN may be in use. Core Web Vitals will benefit.
Healthy response time for most shared and managed hosting environments. Acceptable for most sites in non-competitive niches.
Server is responding but slowly. Common causes: unoptimised database queries, no caching, shared hosting under load, no CDN. Investigate and optimise.
Significantly slow. Google's recommended TTFB threshold for a "Good" Core Web Vitals score is under 800ms. Slow response hurts LCP scores and rankings. Needs urgent attention.
Server did not respond within the tool's timeout window. Either the server is offline, severely overloaded, or the connection is blocked by a firewall.
Google's Core Web Vitals documentation states that a good TTFB should be under 800 milliseconds. Sites above 1,800ms are considered poor and may see negative ranking signals from the LCP (Largest Contentful Paint) metric. If this tool shows a slow response time on your server, the most impactful immediate fixes are: enabling caching (Redis, Memcached, or page-level caching via a plugin), using a CDN to serve responses from servers geographically closer to your users, and identifying slow database queries using slow query logs.
Downtime and SEO — How Long Before Google Drops Your Rankings
The relationship between server downtime and SEO impact is not immediate — there is a grace period, a warning stage, and a damage stage. Understanding the timeline helps you prioritise how urgently you respond to different types of server issues.
Google encounters the server error on its first crawl attempt. Rather than immediately penalising, Googlebot schedules a retry for the next day. This is the standard crawl retry behaviour for all 5xx errors. A brief outage lasting a few hours — a server restart, a plugin conflict fixed quickly — will likely not affect rankings at all, provided the error is resolved before Googlebot returns.
Googlebot has now made multiple unsuccessful attempts to crawl the affected pages. Rankings begin showing minor fluctuations — affected pages may drop a few positions or see reduced impression counts in Search Console. The damage is reversible at this stage if the server issue is resolved promptly. Users who had bookmarked direct links are also starting to encounter errors.
Persistent 5xx errors over multiple days cause significant ranking drops. Research from Moz found that intermittent 500 errors caused tracked keywords to plummet completely out of the top 20 search positions. Googlebot reduces the crawl frequency for the affected pages — a negative signal that compounds the ranking drop. A real-world case study documented a site losing significant SERP visibility within days of an SSL-related server error causing 5xx responses.
Pages that have been returning 5xx errors for more than a week risk being removed from Google's index entirely. De-indexed pages lose all their ranking signals and must be recrawled and reindexed from scratch after the server issue is resolved. Recovery from de-indexation can take weeks and is never guaranteed to fully restore pre-outage rankings. This is the most serious outcome of unmonitored downtime.
An expired SSL certificate caused 5xx errors for 6 days unnoticed
A documented case from an SEO case study: a business site's SSL certificate expired without the owner being notified (auto-renewal had failed silently). The site appeared to load normally in most browsers due to cached connections — but Googlebot encountered 5xx errors on every crawl attempt for 6 days before the owner noticed a sudden ranking drop and began investigating.
Googlebot made nearly 750 visits to the affected pages over those days, receiving server errors each time. The Crawl Stats report in Google Search Console showed a clear spike in 5xx errors. Several important pages dropped out of the top 20 positions for their target keywords. After the SSL certificate was renewed and verified as working, rankings took several weeks to stabilise — not instantly, despite the server itself being healthy again.
The lesson: server errors do not always announce themselves visually. Regular status checks are the only way to confirm what search engines are actually seeing.
The 503 Maintenance Strategy — Protecting Your Rankings During Planned Downtime
If you need to take your server offline for planned maintenance — a major update, a database migration, a server upgrade — there is a right way and a wrong way to handle it from an SEO perspective. The wrong way is to simply take the site offline, letting it return connection errors while you work. The right way is to return a correctly configured 503 Service Unavailable response.
Unlike 500, 502, and 504 errors — which tell Googlebot "something went wrong" — a 503 specifically means "we are temporarily unavailable, please check back." When a 503 is returned alongside a Retry-After header specifying how long the maintenance will last, Google treats this as planned downtime rather than a server failure. This distinction can protect your rankings for approximately one week of maintenance — far longer than an unannounced 500 would tolerate before ranking damage begins.
HTTP/1.1 503 Service Unavailable Retry-After: 3600 # Tells Googlebot to retry in 3600 seconds (1 hour) Content-Type: text/html # Body: a simple maintenance page explaining the situation # "We are currently undergoing maintenance. Back shortly."
John Mueller has specifically endorsed the 503 + Retry-After approach for maintenance windows, noting that Google can tolerate 503 responses for roughly a week before treating the unavailability as permanent. Use this checklist before any planned maintenance:
- Configure your server or CDN to return
503— not a redirect, not a 200 page saying "under maintenance" - Include a
Retry-Afterheader with a reasonable time estimate in seconds - Serve a simple, informative maintenance HTML page in the response body
- After maintenance completes, verify the server returns
200 OKusing this tool before announcing the site is back - Monitor Google Search Console's Coverage report for any 5xx errors that persist after maintenance ends
Common Server Errors — Causes and Fixes
500 Internal Server Error — The Most Destructive Common Error
The generic catch-all for server-side problems. Unlike 5xx errors that indicate infrastructure failure (502, 504), a 500 usually means the application itself has crashed or encountered a fatal error. In WordPress environments, the most common causes are: a recently installed or updated plugin with a PHP conflict, exceeding PHP memory limits, a corrupt .htaccess file (verify by temporarily renaming it), and database connection errors. Check your server's PHP error log immediately — the 500 response typically accompanies a detailed error message that your log will contain even when the page shows nothing to visitors.
502 Bad Gateway — Usually a Hosting Infrastructure Problem
A 502 almost always means your web server (Nginx or Apache) is running fine but cannot reach the application server behind it. On WordPress/PHP sites this typically means PHP-FPM has crashed or is refusing connections. On Node.js or Python apps, it means the application process is down. On sites using Cloudflare, it often means your origin server (not Cloudflare itself) is unreachable from Cloudflare's network. Check whether your application process is running, restart PHP-FPM if needed, and verify that your server's firewall allows connections from your proxy layer.
503 Service Unavailable — Load, Limits, or Maintenance
A 503 that you did not intentionally configure usually means your server is temporarily overwhelmed — too many concurrent requests, a traffic spike exceeding your server's capacity, or resource limits being hit. Review your server's concurrent connection limits, check for unusual traffic patterns in your access logs (which may indicate a bot attack or traffic spike), and consider upgrading server resources or enabling more aggressive caching if 503s are occurring under normal traffic loads.
504 Gateway Timeout — Slow Upstream Processes
The proxy layer is waiting for a response from the upstream server that never arrives within the timeout window. The most common cause is a slow database query that exceeds the server's configured timeout. Enable MySQL or PostgreSQL slow query logging to identify the offending queries, add appropriate database indexes, and consider increasing your web server's timeout configuration for legitimate long-running processes. If the 504 occurs on a specific page only, that page likely triggers an unusually slow database operation or external API call.
How to Use the Server Status Checker
Enter Any URL
Type or paste the full URL including https://. Check any publicly accessible page — your homepage, landing pages, or any URL you want to verify.
Submit the Check
Click Submit. The tool makes a direct HTTP request — no browser, no cache — and retrieves the raw server response code and response time.
Read the Status Code
200 means healthy. 3xx means a redirect. 4xx means a client/request issue. 5xx means a server problem. Each code is displayed with its plain-English meaning.
Check Response Time
Review how fast the server responded. Under 200ms is excellent. Over 1 second warrants optimisation. A timeout means the server is unreachable or down.
Who Uses the Server Status Checker — and When
Investigating a Traffic Drop
When organic traffic drops unexpectedly, server errors are one of the first things to check. A 500 or 503 that appeared days ago — visible in Search Console's Crawl Stats but not obvious from browser visits — is a common cause of sudden ranking drops that seems unrelated to any content change.
Post-Update Verification
After any significant change — a CMS update, a plugin install, a hosting migration, a code deployment — run your key pages through the status checker before considering the deployment complete. Plugin conflicts that cause 500 errors are common and may only affect certain page types, not the homepage you naturally test first.
Client Site Health Checks
SEO professionals and developers managing client sites use the status checker as a quick baseline diagnostic during monthly reporting or before launching any optimisation campaign. Confirming all key pages return 200 — and at acceptable response times — is a one-minute check that can prevent significant client surprises later.
Checking a Competitor or Vendor
Before adding a link from your site to a third-party domain, verify it is actually live and returning a 200. Before relying on an external API or service in production code, verify its endpoint status. A vendor experiencing 503s is a risk to your own uptime if your site depends on their service.
"Is It Just Me?" Verification
When you cannot reach a website, is it down for everyone or just you? The status checker makes the request from an external server — if it returns a 200, the site is up and the issue is local (your ISP, DNS, network, or browser cache). If it returns a timeout or 5xx, the site is genuinely down for everyone.
Verifying Maintenance Ended Correctly
After bringing a server back online from maintenance or an outage, confirm it is returning 200 — not still serving 503, not stuck in a redirect loop, not returning cached error pages from a CDN. This is a quick final check before announcing the site is back or restoring traffic to it.
Pro Tips for Server Status Monitoring
5 Habits for Staying Ahead of Server Issues
- Check more than just your homepage. The most common server errors affect specific page types — a plugin conflict that only fires on product pages, a PHP error only triggered by certain database queries, a permission issue only on a specific directory. Check your top-traffic pages and your most commercially important pages, not just the root URL. A 200 on your homepage does not guarantee all your content is healthy.
- Use Google Search Console's Coverage report alongside this tool. The Crawl Stats section in Search Console shows the response codes Googlebot has actually been receiving from your server — including historical data. After fixing a server error, both the Crawl Stats and this tool should confirm healthy responses before you consider the issue resolved. What Google already saw matters as much as what it will see going forward.
- Check response time benchmarks across different times of day. A server that responds in 150ms at 3am may respond in 900ms during peak traffic hours if it is on shared hosting. Running the status check at different times reveals whether your server degrades under load — which has Core Web Vitals implications independent of any error codes.
- After any hosting migration, check all redirects AND status codes. Site migrations are the most common source of accidental server errors. New server environments may have different PHP versions, different directory permissions, missing modules, or missing environment variables that work on the old server but fail on the new one. Use both this tool and the Redirect Checker to verify every important URL after a migration.
- Treat 403 on public pages with the same urgency as 500. A 403 on a page that should be publicly accessible means Google cannot crawl it — the page will not be indexed. Common causes are overly aggressive security plugins, misconfigured firewall rules that accidentally block crawlers, or Cloudflare security settings that require human verification. These are silent ranking killers because the page appears to load fine in a logged-in browser session but returns 403 to Googlebot's unauthenticated requests.
Frequently Asked Questions
My website returns 200 in my browser but visitors are complaining it is down. What is happening?
This is a caching problem — and it is more common than you might expect. Several caching layers can serve a cached version of your page even while the live server is returning errors:
- Browser cache: Your browser may have a cached version of the page from a recent successful visit. Force a fresh request with Ctrl+F5 (Windows) or Cmd+Shift+R (Mac).
- CDN cache: If your site uses Cloudflare or another CDN, edge servers may be serving cached responses even while your origin server is returning 5xx errors. Check your CDN's status and origin pull logs.
- Geographic routing: Some visitors may be routed to a different server or data centre region that is experiencing issues while yours is fine.
Use this tool to check the raw status code from a server outside your network and browser cache. It makes a fresh, uncached request from a neutral location — which reflects what external visitors and Googlebot are actually receiving.
Will a few hours of server downtime destroy my SEO rankings?
A few hours of downtime is unlikely to cause lasting SEO damage, according to Google's own guidance. John Mueller has stated that when a URL returns 5xx errors, Googlebot will retry over the following day or so before any indexing or ranking changes occur.
The factors that determine whether downtime damages rankings are: how long the outage lasts (hours vs days), how frequently Googlebot crawls your site (high-authority sites get crawled more often), whether the downtime occurs during a major crawl, and whether the error type is a 5xx server error (bad for SEO) or a 503 with Retry-After header (managed maintenance — Google tolerates this for about a week).
Brief outages under 4–6 hours that resolve cleanly typically result in no lasting ranking impact. Outages lasting several days can cause measurable ranking drops that take 1–3 weeks to recover after the server issue is resolved.
What is the difference between a 500 and a 503 error?
Both indicate server-side problems, but they communicate different things — and have different SEO implications:
- 500 Internal Server Error — Something unexpected went wrong on the server. An application crash, a fatal PHP error, a database connection failure. The server encountered an unhandled exception. This tells crawlers something is broken unexpectedly.
- 503 Service Unavailable — The server is temporarily unable to handle requests, typically due to overload or maintenance. This is specifically designed to communicate temporary unavailability. When paired with a
Retry-Afterheader, it tells Google "this is deliberate and temporary, come back in X seconds."
From an SEO perspective: a 500 is always bad — fix it as soon as possible. A 503 is bad if it occurs unexpectedly (server overload), but manageable if it is intentionally configured during planned maintenance. Use 503 with Retry-After for maintenance windows; never intentionally return 500.
My page returns a 403 error. What does this mean and how do I fix it?
A 403 Forbidden means the server understood your request but has specifically refused to allow access to that resource. Unlike 404 (page does not exist), 403 means the page exists but access is denied. This is particularly harmful for SEO because Google cannot crawl pages returning 403 — they will not be indexed or ranked.
Common causes and fixes:
- File permissions: Check that the file and directory permissions allow the web server user to read the content. PHP files should typically be 644; directories 755.
- Security plugin blocking crawlers: Some WordPress security plugins (Wordfence, iThemes Security) can misconfigure rules that block Googlebot. Check your security plugin's firewall rules and whitelist Googlebot's user-agent if necessary.
- Cloudflare security rules: If Cloudflare's security level is set too aggressively, it may require CAPTCHA verification or block requests that match Googlebot's profile. Check your Cloudflare firewall rules and ensure "Verified Bots" are not being blocked.
- .htaccess rule: A misconfigured .htaccess directive that restricts access to certain paths or IP ranges may be unintentionally blocking legitimate crawlers. Review your .htaccess for any overly broad deny rules.
How is this different from simply opening a website in a browser?
Several important differences make an independent status checker more reliable than a browser test:
- No browser cache: Your browser caches web pages. A page you visited an hour ago may appear fine in your browser even if the server is currently returning errors. This tool makes a fresh, uncached request every time.
- No geographic bias: Your browser sends requests from your location. Server issues, ISP routing problems, or CDN edge failures may affect some regions but not others. This tool makes its request from a neutral, external server location.
- Shows raw status codes: Browsers interpret status codes and display user-friendly results — a 302 redirect chain is followed silently, a 403 may show a generic "access denied" page. This tool shows you the actual numeric HTTP response code, not the browser's interpretation of it.
- Shows response time: Browsers do not display server response time directly. This tool measures Time to First Byte (TTFB) — the raw server response latency — which is a Core Web Vitals signal that browser-level page load timing can obscure.
Is the Server Status Checker completely free?
Yes — completely free with no account required, no sign-up, and no usage limits. Check as many URLs as you need. This applies to all 47 free tools on DigitalSub Pro — there is no premium tier and no paywall on any feature.