How to Troubleshoot a Website That Won't Load

Before You Panic: Is It Just You or Everyone?

The moment a website fails to load, a wave of panic can set in — especially if it is your own business site, a client project, or a revenue-generating platform. Before you start rebooting servers or firing off frantic support tickets, the single most important diagnostic question you need to answer is whether the outage is local to your machine or global. A systematic approach at this stage can save you hours of unnecessary troubleshooting. Taking a breath and running a quick external check separates genuine emergencies from false alarms caused by your local network, ISP hiccups, or browser state.

The distinction between a local issue and a global outage dictates every subsequent step in your troubleshooting flowchart. If the problem is on your end, no amount of server reconfiguration will fix it. Conversely, if the site is truly down for everyone, monkeying with your browser cache is a waste of time. Understanding this fundamental branching point is what separates effective diagnosticians from people who randomly click settings and hope for the best. At Hosting Captain, we have guided thousands of site owners through this exact decision tree, and we can tell you with confidence that starting at the right branch is half the battle.

Using Downforeveryoneorjustme.com and Similar Tools

Downforeveryoneorjustme.com is the quickest litmus test available. You type in your domain name, hit enter, and within seconds the tool tells you whether the site is reachable from its own independent network of probe servers. If the result says “It's just you,” the website is functioning normally from the tool's vantage point, meaning the failure is somewhere between your device and the broader internet — most likely your local connection, your ISP's DNS resolver, or a browser-level quirk. Tools like IsItDownRightNow.com and Site24x7 offer similar functionality, and we recommend checking at least two of them to rule out false negatives from a single probe network.

When the tool confirms the site is down globally, you can skip straight to server-side and DNS investigations because you have already eliminated the most common local culprits. These services work by sending HTTP requests to your domain from geographically distributed data centers, and if none of them receive a valid response, the problem is almost certainly not on your end. Bookmarking at least one of these checkers is a smart habit for any website owner. It is the digital equivalent of asking a friend across town if their lights are on before you call an electrician to rewire your house.

Testing from a Different Network and Device

Beyond automated checkers, a manual cross-check provides additional confidence in your diagnosis. Disconnect your phone from Wi-Fi and try loading the site over cellular data. If the site loads on mobile data but not on your office or home network, the issue lies squarely with your local ISP, router configuration, or a DNS setting specific to that network. Similarly, attempt to access the site from a different browser on the same machine — if Chrome fails but Firefox succeeds, you know the problem is browser-specific rather than network-wide.

This multi-device, multi-network validation eliminates ambiguity and gives you a clear direction before moving into deeper technical territory. We have seen cases where a single corrupted browser extension blocked dozens of sites while the server logs showed zero errors, and the site owner spent hours debugging a perfectly healthy server. Cross-referencing at least two networks and two devices takes less than three minutes and can prevent an enormous waste of effort. If you cannot access the site from any device on any network, it is time to move to the next stage of the troubleshooting flowchart: DNS.

Step Two: Diagnosing DNS Issues

The Domain Name System is the internet's phonebook, translating human-readable domain names like hostingcaptain.com into machine-routable IP addresses. When DNS breaks, your domain effectively vanishes from the internet even though your server may be running perfectly. DNS problems are notoriously tricky to diagnose because symptoms vary by geographic region — your site might load fine for you in Chicago but fail entirely for a visitor in Berlin. Understanding how to interrogate DNS records is therefore one of the most valuable skills any site owner can develop, and it sits right after the “is it just me?” check in our recommended troubleshooting flowchart.

DNS failures manifest in several recognizable patterns: a “server not found” or “DNS_PROBE_FINISHED_NXDOMAIN” error in Chrome, a generic “this site can't be reached” message, or a complete timeout with no error code at all. Each of these points toward a different root cause ranging from expired domains to misconfigured nameserver records. As the Mozilla domain name documentation explains, the hierarchical nature of DNS means that a single broken link in the chain can take down your entire domain resolution. The good news is that with the right command-line tools, you can trace the exact point of failure in under a minute.

Propagation Delays and Incorrect Nameservers

If you recently changed your nameservers, pointed your domain to a new hosting provider, or updated A records, you are almost certainly experiencing DNS propagation delay. Propagation is the time it takes for changes made at your domain registrar to cascade through the global network of DNS resolvers, and it can range from a few minutes to 48 hours depending on the Time-To-Live (TTL) values set on your records and the caching policies of individual ISPs. During this window, some visitors will be directed to your old server while others reach the new one, creating a maddeningly inconsistent pattern of uptime and downtime that no amount of server tweaking can fix.

To check whether propagation is in progress, use a tool like WhatsMyDNS.net, which queries your domain against resolvers in dozens of countries simultaneously and shows you a map of which IP address each resolver is returning. If you see a mix of old and new IP addresses, propagation is still underway and patience is your only real remedy. If all resolvers consistently return the wrong IP or no IP at all, you likely have incorrect nameserver settings at your registrar. Verify that the nameservers listed in your domain's configuration exactly match what your web hosting provider assigned you, because even a single transposed digit can break resolution entirely.

Using ping, traceroute, nslookup, and dig

Command-line DNS tools give you precision that web-based checkers cannot match. Start with ping yourdomain.com in your terminal or command prompt. If ping returns an IP address but all packets time out, the domain is resolving but the server at that IP is not responding — which means DNS is working and your problem is server-side. If ping returns “Ping request could not find host,” DNS resolution is failing entirely and you need to investigate further with dedicated DNS tools.

nslookup yourdomain.com on Windows or dig yourdomain.com on macOS and Linux queries your configured DNS resolver and shows you exactly which IP address it is returning for your domain. For a deeper check, run nslookup yourdomain.com 8.8.8.8 to query Google's public DNS directly, bypassing your ISP's resolver entirely. If Google's DNS returns the correct IP but your ISP's resolver does not, you have confirmed a propagation or ISP-level caching issue. traceroute yourdomain.com (or tracert on Windows) maps every network hop between your machine and the destination server, revealing whether traffic is dying at your router, your ISP's gateway, or somewhere deep inside the hosting provider's network.

Expired Domains and Registrar-Level Problems

A domain that has expired will stop resolving across the entire internet, often with zero warning beyond the renewal notices that may have landed in an unmonitored email inbox. Most registrars provide a grace period after expiration during which you can renew at the standard rate, but once that period closes, the domain enters a redemption phase where recovery becomes significantly more expensive. Log into your domain registrar's control panel immediately if you suspect expiration and verify the registration status, auto-renewal settings, and the email address on file for renewal notifications.

Registrar-level issues can also include account suspensions due to failed payment verification, WHOIS privacy service failures that trigger ICANN verification requirements, or even domain hijacking in worst-case scenarios. Keep your registrar account secured with two-factor authentication and maintain a separate, actively monitored email address for domain-related communications. Losing a domain due to an expired credit card or a missed renewal email is one of the most preventable catastrophes in web hosting, and it happens far more often than most people realize.

Step Three: Investigating Server-Side Problems

Once you have confirmed that DNS is resolving your domain to the correct IP address and the problem is not isolated to your local network, the next link in the chain is the web server itself. Server-side failures can range from complete hardware outages to subtle software misconfigurations that only manifest under specific traffic conditions. The key to efficient server-side troubleshooting is learning to read the signals your server sends back — HTTP status codes, error log entries, and resource utilization metrics all tell a story when you know how to interpret them.

Before diving into logs, verify the most basic server health indicators. Can you establish an SSH or remote desktop connection to the server? If not, the physical machine or virtual instance may be down entirely, which is an immediate escalation to your shared hosting provider or infrastructure team. If you can reach the server but the website is unresponsive, the web server daemon (Apache, Nginx, LiteSpeed, or IIS) may have crashed, been stopped during a maintenance operation, or hit a resource ceiling that prevents it from accepting new connections. Restarting the web server service is often a quick fix for transient issues, but persistent crashes demand deeper log analysis.

Common HTTP Error Codes Decoded

500 Internal Server Error is the web's most frustratingly vague error because it tells you something went wrong on the server but provides zero specificity about what. It typically indicates a PHP fatal error, a misconfigured .htaccess directive, an exhausted PHP memory limit, or file permission problems. Check your server's PHP error log and the web server error log simultaneously; the actual cause is almost always recorded there even though the browser sees only the generic 500 code.

502 Bad Gateway means a proxy or gateway server — commonly Nginx sitting in front of Apache or PHP-FPM — received an invalid response from the upstream backend. When PHP-FPM crashes or exhausts its process pool, Nginx cannot complete the request and returns a 502. Restarting PHP-FPM usually clears a transient 502, but recurring occurrences signal that your server needs more PHP worker processes or that a slow-running script is consuming all available workers and starving other requests.

503 Service Unavailable indicates the server is temporarily unable to handle the request, often because it is overloaded or down for maintenance. A traffic surge beyond your hosting plan's capacity is the most common trigger on shared hosting, and if you are on a shared hosting plan, this may signal that it is time to upgrade to a VPS. Other causes include a web server that is running but has no available worker threads or a backend application pool that has stopped entirely.

504 Gateway Timeout means the upstream server took too long to respond and the gateway gave up waiting. Long-running database queries, external API calls that hang, or PHP scripts caught in infinite loops are the usual suspects. Unlike a 502 where the backend returned a garbage response, a 504 means the backend never returned anything at all within the configured timeout window. Adjusting the proxy read timeout value can buy you more headroom, but the real fix lies in profiling and optimizing the underlying slow operation.

403 Forbidden is a permission error. The server understands the request but refuses to fulfill it. Common causes include incorrect file permissions (directories without execute permission, files without read permission), an IP address block rule in your .htaccess configuration, or a missing index file combined with disabled directory listing. Check your file permissions against your hosting provider's recommended settings and review any recently added security rules.

404 Not Found is universally recognized but often misunderstood. While it can simply mean the requested URL genuinely does not exist, on a previously working site a sudden flood of 404s usually points to broken permalink structures, a missing .htaccess file after a server migration, or corrupted rewrite rules. Regenerating permalinks (in WordPress, visiting Settings > Permalinks and clicking Save Changes) is a remarkably effective fix for mysterious 404s that appear after a migration or update.

Resource Limits: CPU, RAM, I/O, and Disk Space

Shared hosting environments enforce strict per-account resource limits, and exceeding any one of them can render your site unreachable. CPU limits are typically measured in seconds of processing time per day or as a percentage of a single core. A sudden traffic spike from a social media mention or a poorly optimized database query can burn through your CPU allocation in minutes, after which the server returns 503 or 508 (Resource Limit Reached) errors until the next measurement window resets your usage counters. Monitoring your resource usage through your hosting control panel's statistics section can alert you to approaching limits before they become outages.

Physical disk space is another silent killer of websites. When a server's disk fills completely, the web server, database, and mail services can all fail catastrophically because they can no longer write logs, temporary files, or session data. Error logs that rotate automatically are a common culprit, growing to gigabytes in size if a script is throwing repeated warnings. MySQL and MariaDB will refuse to start or will crash silently when the disk holding their data directory has zero bytes free. Set up disk usage alerts in your hosting dashboard and periodically audit your account for stale backups, oversized log files, and orphaned temporary data that can be safely purged.

PHP Errors and Database Connection Failures

PHP fatal errors are among the most common root causes of the dreaded white screen of death. A missing semicolon, a call to an undefined function, or a syntax error in a theme's functions.php file can crash the entire PHP process before any HTML reaches the browser. Enabling WordPress debug mode with define('WP_DEBUG', true); in wp-config.php surfaces these errors directly on screen during troubleshooting. On a production site where public debug output is unacceptable, configure PHP to log errors to a file and review that log whenever the site goes white. Most hosting control panels provide a dedicated error log viewer that filters PHP, Apache, and Nginx errors into separate, searchable streams.

Database connection failures typically produce a specific error message: “Error establishing a database connection” in WordPress or a similar driver-level exception in custom applications. The root cause is usually one of four things: the database server process has crashed, the database credentials in your configuration file are incorrect, the database host is unreachable due to a network or firewall change, or the database server has exhausted its maximum connection limit. Verify that the MySQL or MariaDB service is running by checking your hosting control panel's service status page or running mysqladmin ping from the command line if you have SSH access. If the service is running but you still cannot connect, test the credentials manually with the mysql command-line client to isolate whether the problem is in your application's configuration or the database server itself.

Step Four: Application-Level and Browser-Side Checks

If the server is responsive, DNS is resolving correctly, and all backend services are running, the fault likely resides within the application layer or the visitor's browser environment. Application-level issues are the broadest category of website failures because they encompass everything from buggy plugin code to corrupted cache files to client-side JavaScript errors that prevent a page from rendering. The systematic approach here is to strip away variables one at a time until the site starts working again, at which point you have isolated the culprit by process of elimination.

This category also includes what we call “it loads for me but not for anyone else” problems, which are almost always a combination of aggressive caching and stale content delivery network (CDN) configurations. If you are the site administrator viewing a cached version of the page while visitors are hitting a broken uncached version, you will remain blissfully unaware of the outage until someone reports it. Always test your site in an incognito or private browsing window to bypass your own cached assets and cookies before concluding that everything is fine.

Browser Cache, Cookies, and Extensions

A corrupted browser cache can cause partial page loads, broken stylesheets, and JavaScript errors that make a perfectly healthy site appear broken. When a cached version of a CSS file references class names that no longer exist in the updated HTML, the browser renders a garbled mess that looks like a catastrophic layout failure. Clearing your browser cache is the first browser-side fix to attempt, and it resolves a surprising percentage of display-only issues. In Chrome, this is under Settings > Privacy and Security > Clear Browsing Data; select “Cached images and files” and set the time range to “All time” for a thorough purge.

Cookies store session state and authentication tokens, and a stale or corrupted cookie can trigger redirect loops, login failures, or access-denied errors that look identical to a server-side misconfiguration. Clearing cookies for the specific domain you are troubleshooting is more surgical than nuking all cookies, and most browser developer tools let you delete individual site data from the Application tab. Browser extensions — particularly ad blockers, privacy tools, and security suites — can inject or block scripts in ways that break page functionality. Test the site in a clean browser profile with all extensions disabled to rule out extension interference before escalating to server-side investigations.

Leveraging Browser Developer Tools and curl

Every major browser ships with a powerful developer tools suite accessible via F12 or Ctrl+Shift+I. The Network tab is your primary diagnostic panel: it shows every HTTP request the page makes along with the response status code, load time, and response headers. If your HTML document loads (status 200) but a critical CSS or JavaScript file returns a 404 or 500, you know exactly which asset is broken and where it is supposed to be located. The Console tab surfaces JavaScript errors with file names and line numbers, which is often enough to identify a specific plugin or theme script that is throwing exceptions and halting further execution.

For server-side debugging that bypasses the browser entirely, curl is the command-line tool of choice. A command like curl -I https://yourdomain.com fetches only the HTTP response headers, showing you the raw status code and server information without rendering any HTML. Adding the -v flag gives you verbose output including the full TLS handshake, which surfaces certificate expiration issues, hostname mismatches, and protocol negotiation failures that are invisible in a browser. For sites behind a CDN like Cloudflare, add a Host header override with curl -H "Host: yourdomain.com" http://server-ip-address to test the origin server directly while bypassing the CDN edge.

WordPress-Specific Troubleshooting

WordPress powers over forty percent of all websites, so it deserves a dedicated section in any troubleshooting guide. When a WordPress site goes down or starts behaving erratically, plugins are the first place to look. A plugin conflict occurs when two plugins (or a plugin and the active theme) load incompatible versions of a shared JavaScript library, define functions with the same name, or enqueue resources in the wrong order. The standard diagnostic method is to disable all plugins via the WordPress admin dashboard or by renaming the /wp-content/plugins/ directory via FTP, then reactivating them one by one until the problem reappears. This process of elimination is tedious but definitive.

Theme issues are the next most common culprit. A poorly coded theme can trigger PHP fatal errors, especially after a WordPress core update deprecates a function the theme relied on. Temporarily switch to a default WordPress theme like Twenty Twenty-Four through the database if the admin area is inaccessible: update the template and stylesheet rows in the wp_options table to point to the default theme directory name. The .htaccess configuration file in WordPress is particularly prone to corruption because numerous plugins (security, caching, and SEO plugins in particular) append their own rewrite rules to it. A malformed directive or a duplicate rule block can trigger 500 errors across the entire site. Rename your .htaccess file to .htaccess.bak, then regenerate it by visiting Settings > Permalinks and clicking Save Changes — this rebuilds a clean .htaccess with only the core WordPress rewrite rules.

PHP memory exhaustion is a frequent WordPress failure mode on budget hosting plans where the default memory allocation is a lean 64MB or 128MB. Modern page builders, e-commerce plugins like WooCommerce, and membership plugins can easily consume 256MB or more during peak operations. The error message “Allowed memory size of X bytes exhausted” in your PHP error log is unambiguous: you need to increase the PHP memory limit. Add define('WP_MEMORY_LIMIT', '256M'); to your wp-config.php file, and if your hosting provider allows it, raise the limit further in your hosting control panel's PHP configuration section. If you cannot increase the limit due to a restrictive shared hosting plan, it may be time to consider upgrading to a plan with more generous resource allocations.

When to Contact Your Hosting Provider's Support Team

Self-service troubleshooting should always be your first line of defense, but there are clear inflection points where escalating to professional support saves time and prevents further damage. If your site is down and you have confirmed through the steps above that the issue is server-side but beyond your access level — for example, a database service that will not restart, a suspected hardware failure, or a network routing problem upstream of your server — contact your hosting provider immediately. Reputable hosting companies including Hosting Captain maintain 24/7 support teams specifically to handle these situations, and the faster you provide them with actionable diagnostic information, the faster they can restore your service.

You should also contact support if you encounter error messages referencing server modules you do not control, such as mod_security blocks, Imunify360 quarantine notifications, or CloudLinux LVE (Lightweight Virtual Environment) faults. These security and resource isolation layers operate above the application level and typically require root or administrative access to modify. Attempting to circumvent them without understanding their purpose can introduce security vulnerabilities, so let the professionals handle it. Support teams also have access to server-wide monitoring data that can reveal whether your site was affected by a broader infrastructure incident, such as a DDoS attack targeting the shared hosting node or a data center power event.

What Information to Provide for Faster Resolution

The quality of information you provide to a support agent directly dictates how quickly your ticket gets resolved. Start with your domain name and the exact time the issue started — timestamps allow engineers to correlate your report with server log entries and monitoring alerts. Include the specific error message or HTTP status code you are seeing, not a paraphrase. A screenshot of the exact browser error is even better. Describe every troubleshooting step you have already taken, because this prevents the support agent from wasting time suggesting steps you have already completed and demonstrates that you are an informed user who has done due diligence.

If you are comfortable with command-line tools, include the output of ping, traceroute, and nslookup or dig runs against your domain. This data is pure gold for support engineers because it reveals exactly where in the network stack the failure is occurring without requiring any back-and-forth. Specify whether the issue affects a single page or the entire site, whether it is intermittent or persistent, and whether any recent changes were made to the site (plugin updates, theme changes, DNS modifications, server migrations). When Hosting Captain receives a support ticket with all of this information upfront, our average resolution time drops by over sixty percent compared to tickets that begin with a vague “my site is down.”

Prevention: Building a Resilient Website That Stays Online

Troubleshooting skills are essential, but the ultimate goal is to build a website that rarely needs them. A resilient website is not the product of a single heroic configuration change; it is the cumulative result of proactive monitoring, regular maintenance, and architectural decisions made before problems occur. Uptime monitoring services like UptimeRobot, Pingdom, or StatusCake will check your site at regular intervals (ideally every one to five minutes) and alert you via email, SMS, or push notification the moment a failure is detected, often before your visitors notice anything is wrong. Many of these services offer free tiers that are more than adequate for a single website.

Automated backups are your safety net for the worst-case scenario. A site that can be restored to its last known good state within minutes is a site that can survive plugin update catastrophes, hacking incidents, and accidental database deletions. Your web hosting plan should include daily automated backups stored off-server in a geographically separate location. Test your backup restoration process at least once per quarter; a backup you have never tested is not a backup, it is a hope. Keeping your CMS core, plugins, themes, and PHP version updated closes known security vulnerabilities that would otherwise be exploited. Enable automatic minor updates where possible, and schedule major updates during low-traffic windows with a verified rollback plan ready.

Finally, choose a hosting provider that gives you the tools to self-diagnose and the support to escalate when needed. A control panel with integrated error log viewers, resource usage graphs, and one-click service restarts empowers you to resolve routine issues independently. A support team that is reachable 24/7 and actually knowledgeable about the platform they support ensures that when you do need help, you get it fast. Your hosting compliance and data residency requirements should also factor into your provider selection to ensure your monitoring and backup infrastructure meets regulatory standards for your jurisdiction.

Frequently Asked Questions