The site will not load. You do not yet know whether it is your connection, the hosting, something you touched, or a much more serious problem. The instinct is to start trying things at random, and that is exactly what wastes the most time. There is a diagnostic order that resolves most cases in minutes, with no advanced technical knowledge needed.
Minute 1: confirm the problem is real and not on your end
Before assuming the site is down for everyone, rule out a local problem. Try from another network (mobile data instead of wifi, for instance) or ask someone elsewhere to check it. Free online tools also exist that show whether a site is down just for you or for everyone, just by typing in the address.
This step, which takes under a minute, avoids the most common scenario of all: spending half an hour "fixing" a problem that was actually with your own internet connection.
Minute 2: identify what type of error you are seeing
Not every "the site is down" is the same problem, and the type of message shown points directly at the cause.
The page does not load at all, the browser says it cannot connect: this can be a domain problem (not resolving) or the server being completely unreachable.
A server error message appears (a code like 500, 502 or 503): the server is running but something failed while generating the page. The cause is on the site's side, not the connection.
A security certificate warning appears, expired or invalid: the site itself may be working, but the browser is blocking access over a specific security issue, not a general outage.
Each of these three scenarios points somewhere different, and knowing which one saves valuable minutes in the next step.
Minute 3: check whether you made a recent change
The most useful question in the whole process, and the one asked least in the moment of panic: what changed right before this started? A plugin update, a configuration change, a new install. The vast majority of sudden outages on a site that was working fine are tied to a recent change, not a spontaneous failure with no cause.
If you identify a recent change, reverting it (deactivating the plugin that was just updated, for instance) usually solves the problem far faster than searching for the cause from scratch.
Minute 4: check the hosting's general status
Before assuming the problem is exclusively yours, confirm it is not something wider: many providers have a status page reporting whether there is a general service interruption affecting several accounts, not just yours. If there is a notice there, the problem is already being handled and there is no need to keep diagnosing on your own.
Minute 5: contact support with the information you already gathered
If the steps above did not identify the cause, this is the moment to write to support, and doing so with the information already organised saves valuable response time. Report exactly what type of error you saw, when it started, whether you made a recent change, and whether you confirmed it is not a general service issue. That report, built from what you already gathered in the first four minutes, gets resolved far faster than a message saying "my site is down".
Three instinctive reactions that make things worse
Reinstalling or deleting things at random, hoping something fixes itself. Without having identified the cause, this is more likely to lose information useful for diagnosis than to solve the problem.
Restoring a backup in a rush without first confirming its date and what will be lost by doing so. A badly done restore can turn a solvable problem into a genuine loss of content.
Posting on social media that the site is down before confirming the cause. If the problem resolves in minutes, that public notice may have generated more worry than the situation warranted.
After it is resolved
Once the site is back up, write down what happened and how it was fixed, even somewhere informal. The next time something similar shows up (and it usually does), having that record cuts diagnosis from minutes down to seconds.
Why it is worth having this process thought out in advance
The worst moment to design a plan of action is in the middle of the emergency, with the site down and the pressure of fixing it right now. Having this five-step order internalised, or even written down somewhere accessible, turns a stressful situation into a familiar procedure. It does not eliminate the problem, but it does eliminate the time wasted deciding where to start, which is usually the longest minute of the whole crisis.
If more than one person administers the site, sharing this same order with the whole team also prevents everyone from trying different things at once with no coordination, which is another common way to waste time exactly when it can least be spared.
Also keep, wherever you write this order down, the details you will need the moment something happens: the direct link to support chat or tickets, and the address of the provider's status page. Looking those up only once the site is already down adds time that this five-minute process should not need to spend.