Your site is down and the panic move is to start clicking things. Restart the server, reinstall a plugin, message your host, refresh the DNS settings you don’t fully understand. Some of that ends up being the right fix, purely by luck, after twenty minutes of trying things in no particular order.
A faster route exists. Most causes of downtime sort themselves into a short list, and that list has a natural order: check the things that take five seconds before the things that take twenty minutes. This is that order.
Step 1: Confirm it’s actually down
Before touching anything, rule out the obvious trap: it working fine for everyone except you.
Run your domain through an external checker. If it reports the site as reachable and you still can’t load it, stop here, the site is fine and the problem is your own browser, DNS cache, or network. If it confirms the site is down, everything below applies.
Step 2: Check the domain and SSL certificate first
These cause a disproportionate share of outages precisely because they’re invisible until the exact day they expire, and they take five seconds to check.
Domain expiry. Look up your domain’s registration status. An expired domain doesn’t just stop working quietly, it usually starts resolving to a registrar parking page or fails to resolve at all. This is completely preventable and still catches experienced site owners because auto-renewal silently failed on an expired card.
SSL certificate expiry. An expired certificate doesn’t take the site offline exactly, but it makes every browser throw a full-screen security warning that stops almost all visitors cold, which is functionally the same as being down. Check the certificate’s expiry date directly rather than trusting that auto-renewal worked.
DNS records. If you changed hosts, changed nameservers, or edited a DNS record recently, propagation can leave the domain resolving inconsistently for anywhere from minutes to about 48 hours. Check whether your domain currently resolves to the IP address you expect it to.
Step 3: Check whether your hosting account itself is the problem
This layer catches people off guard because it’s rarely a technical failure, it’s an administrative one.
Suspended account. Missed payment, a resource usage violation, or an abuse complaint can get a hosting account suspended outright. Log into your hosting control panel directly rather than just checking the site, since a suspended account often still lets you log in and see exactly why.
Resource limits. Shared hosting plans cap CPU, memory, and concurrent connections. A traffic spike, a runaway process, or simply outgrowing your plan can get your account throttled or temporarily suspended until usage drops. Your host’s control panel usually shows resource usage directly.
Disk space. A full disk can silently break a site in ways that look like almost anything else: failed database writes, broken file uploads, error logs that grow until they consume the last available space. Worth checking directly rather than assuming.
The host itself having an outage. Check your host’s status page if it has one, or their support and social channels if it doesn’t. If their platform is down, nothing you do to your own site will fix it, and it’s worth confirming this before spending an hour debugging code that was never broken.
Step 4: Check what the server is actually returning
If domain, SSL, and hosting account all check out, the site is reachable but something behind it is failing, and the specific error tells you where.
A 500 error means your application crashed while handling the request. The most common trigger is something that changed recently: a plugin update, a theme update, a core software update, or a manual code change. Check what was modified last, and check your error log for the specific line that failed.
A 502 or 504 means the web server is up but whatever runs behind it, typically your application process, isn’t responding correctly or isn’t responding fast enough. We’ve broken down what a 502 bad gateway means and how to fix it in detail, including the difference between the two and which processes to check first.
A 503 usually means the server is deliberately refusing requests, either because it’s overloaded or because a maintenance mode flag got left on after a deploy. Check for a stray maintenance file before assuming it’s a capacity problem.
If you’re behind Cloudflare or a similar proxy, look for the more specific error codes that layer produces, since a 521, 522, or 523 points at a different stage of the connection between the proxy and your actual server rather than a generic failure.
Step 5: Rule out a hack or malware infection
This one gets skipped because the site often looks completely normal to the owner, which is exactly the point of how modern website malware behaves. It’s frequently built to stay hidden from the person most likely to remove it, targeting only certain visitors or search engine crawlers while the owner sees a clean site every time they check.
Signs worth checking specifically: unexpected redirects that only happen on mobile or from search traffic, a sudden and unexplained drop in search rankings, unfamiliar pages showing up when you search site:yourdomain.com on Google, or an unfamiliar administrator account in your CMS. If your host flagged the account for abuse in step 3, this is very likely the underlying cause. Running the domain through a website security and malware scan checks for injected scripts, blacklist status, and the other common signs of compromise in one pass.
Step 6: Check whether it’s down for everyone or just some regions
If everything above looks clean and the site is intermittently reachable, or reachable for you but not for others, the fault may be regional rather than a clean up-or-down failure. CDN edge node problems, DNS propagation still in progress, or a firewall rule that’s inadvertently blocking a range of visitors can all produce this pattern, and it’s easy to miss if you’re only testing from one location. Testing from a couple of different networks, or asking someone in a different region to try, usually confirms it within a minute.
The likely order, if you want a shortcut
Ranked roughly by how often each one turns out to be the actual cause, based on how these issues typically show up:
- A plugin, theme, or core update that broke something, usually producing a 500 error right after the update
- An expired domain or SSL certificate
- A suspended hosting account, usually for non-payment or a resource limit
- The host itself having an outage
- A misconfigured DNS record after a recent change
- A hack or malware infection
- A genuine server-side crash unrelated to a recent change
Starting from the top of that list before going deep into server logs saves real time in most cases, since the boring administrative causes outnumber the dramatic technical ones.
Preventing the next one
A handful of habits catch most of this before it becomes an emergency: turn on auto-renewal for both your domain and SSL certificate and confirm the payment method on file is current, keep a record of what you changed and when so a post-update outage is easy to trace back, watch your hosting resource usage before you hit the ceiling rather than after, and set up uptime alerts so you find out about an outage from a notification instead of from a customer.
Start by confirming the site is actually down for everyone, not just you, using an external checker. If it’s genuinely down, check your domain expiry and SSL certificate first, since both can take a site offline without producing a clear error on your end, then check whether your hosting account has been suspended, which often shows in the control panel even when the public site gives no explanation at all.
Yes, and it’s one of the most common causes of a sudden outage. A plugin conflict, a compatibility issue with your current software version, or a bug in the update itself can produce a 500 error immediately after updating. Checking what was changed most recently, and temporarily disabling the most recent update, resolves this more often than any other single fix.
Log into your hosting control panel directly rather than just checking whether the site loads, since many hosts display a clear suspension notice there even when the public-facing site shows a generic error or nothing at all. Common causes are a failed payment, exceeding your plan’s resource limits, or an abuse complaint tied to compromised content on the account.
Intermittent failures usually point to resource limits being hit under load, a server process crashing and restarting repeatedly, or a regional issue affecting only some visitors, such as a CDN edge node problem. Consistent, reproducible failures point more clearly at a specific code or configuration change, while intermittent ones are harder to trace and often require checking server logs during the exact windows when it failed.
Check the cheap, fast things yourself first: domain expiry, SSL status, and your hosting control panel for a suspension notice, since these take a few minutes and often turn out to be the actual cause. If those are clean and you’re seeing a clear server error like a 500 or 502, contacting your host with the specific error and timestamp gets you a faster answer than a general “my site is down” message.
The short version
Work down the list instead of guessing. Confirm it’s really down, check the domain and certificate, check the hosting account, read the actual error, then consider a hack. Most outages resolve somewhere in the first three steps.