What to do if your website stops working: 8 steps to act without making the problem worse

This page is an action protocol; it is not another technical support page

The purpose here is to answer one specific situation: “my website is down; what do I do now and in what order?”

If you already know you need someone to intervene technically, the appropriate page is technical website support .

If you want to prevent problems through recurring reviews, updates and backups, the right option is website maintenance.

And if there are clear signs of unauthorised access, modified files, unusual redirects or injected content, it should be treated as a possible security incident rather than a generic outage.

The 8 steps I would follow when a website stops working

The objective is to restore the service without erasing clues, losing recent information or introducing a second problem while trying to solve the first.

1. Check whether the website is genuinely down for everyone

Before changing anything on the server, check that the problem is not limited to your browser, connection or device.

Carry out a simple check:

• open the website from another device;
• try using mobile data instead of the same Wi-Fi network;
• use a private or incognito window;
• check several URLs on the site, not just one page;
• ask someone else whether they can access it from another connection.

If it works from another network, there may be a local cache, DNS, browser or connection problem. If it fails from several locations, it makes more sense to investigate the infrastructure or the application itself.

2. Save the error message, a screenshot and the approximate time

“It does not work” provides very little technical information. The exact message, however, can narrow the diagnosis considerably.

Make a note of:

• the error message or code;
• the URL you were visiting;
• the approximate time it started;
• whether the entire website fails or only one section;
• whether the admin panel is still accessible;
• what happened immediately before the failure.

A screenshot also helps if the error temporarily disappears before someone can review it.

3. Check the domain, DNS, SSL certificate and hosting status

A website can be perfectly programmed and still be inaccessible because an external element stopped working.

I would first check:

• that the domain has not expired;
• that the DNS records still point to the correct server;
• that the hosting provider is not experiencing an incident;
• that the SSL certificate is valid and correctly configured;
• that the hosting account has not been suspended;
• that important resource or storage limits have not been reached.

If the error is related to DNS or the network, Google cannot access the content either, so connectivity should be restored before starting to modify WordPress or the code.

4. Check what changed immediately before the website stopped working

The timeline is often one of the most useful clues.

I would ask whether there was:

• a WordPress, plugin or theme update;
• a PHP change;
• a DNS change;
• a hosting migration;
• a password or permissions change;
• a plugin installation;
• a code change;
• a change to an API or external service;
• an SSL renewal or change;
• a recent restore or import.

If the website was working correctly and stopped immediately after one of these changes, that event should be investigated before more remote possibilities.

5. Do not update, delete plugins, change DNS and restore a backup all at once

When the business is blocked, there is a temptation to try many things quickly. That can make recovery harder because afterwards we no longer know which change fixed the problem or which one introduced another issue.

I would especially avoid:

• updating every component “just in case”;
• deleting plugins without knowing what they do;
• changing DNS repeatedly;
• deleting files that look suspicious without analysing them;
• restoring several backups one after another;
• reinstalling the entire website without preserving the current state.

Whenever possible, change one thing, check the result and document what you did.

6. Review logs, database, application and critical components

If the domain, DNS and hosting are operational, the next step is to look for information in the application and server.

Depending on the technology, it may be useful to review:

• web server error logs;
• PHP or application logs;
• database connection;
• available space;
• file permissions;
• recently updated plugins or modules;
• dependencies;
• external services blocking a critical part;
• the state of the PHP process or application.

At this point we are already in technical diagnosis. If you do not know how to interpret these elements, it is better to ask for support than to continue changing configuration.

7. Decide whether a backup is the best recovery route

Having a backup is very important, but restoring should not be an automatic reflex.

Before recovering an earlier version, I would check:

• the date of the backup;
• whether it includes files and the database;
• what new information would be lost by restoring;
• whether the backup was created before or after the problem appeared;
• whether the failure comes from something that will still be present after restoring;
• whether we can preserve a copy of the current state before overwriting it.

On a simple corporate website, losing a few hours of changes may be acceptable. On an ecommerce site, booking system or application with users, restoring an old database can delete orders or recent information.

The specific guide for this decision is website backups .

8. When it loads again, check that the website has genuinely recovered

Seeing the homepage does not mean the entire service is working.

After recovering the website, I would check at least:

• homepage and main pages;
• admin panel, if there is one;
• forms;
• links and navigation;
• emails generated by the website;
• checkout, bookings or critical functions where applicable;
• HTTPS certificate;
• logs to make sure errors are no longer appearing;
• mobile and desktop.

I would also document the cause and the solution. That information can save a lot of time if a similar incident appears in the future.

What the error you are seeing may mean

The exact message does not always identify the cause, but it helps decide where to look first.

An isolated 404 does not mean that “the whole website is down”. Likewise, a problem that only appears in your browser should not immediately lead to changing the server.

What happens with Google if a website remains down?

A short outage does not mean Google immediately removes a website from its results. But prolonged unavailability can eventually affect crawling and indexing.

Google explains that server errors 5xx cause its crawlers to temporarily reduce crawling frequency. URLs already indexed may remain for a while, but if the errors persist they can eventually be removed from the index.

Google treats certain network and DNS errors in a similar way: if it cannot access the server, it cannot retrieve new content and URLs that remain inaccessible for days may eventually disappear from the index.

That is why, during a real outage, the priority is to restore a server that responds correctly, not to change titles, the sitemap or content while the infrastructure is still inaccessible.

If you suspect a hack, do not treat the problem as a normal outage

Some symptoms change the type of incident:

• administrator users you do not recognise;
• redirects to other domains;
• files modified without explanation;
• injected content or links;
• hosting or browser warnings about malware;
• password changes not made by the team.

In that scenario it may be important to preserve evidence, review access and recover from a version known to be clean. The specific guide is how to protect a website from hacking .

What to prepare afterwards so the next incident is easier to resolve

Not every outage can be prevented, but we can reduce the time lost when one happens.

I would keep the following prepared:

• up-to-date access to the domain and hosting;
• a backup policy appropriate for the type of website;
• a record of important changes;
• a clear technical contact;
• a list of critical functions that must be checked after recovery;
• controlled renewal of the domain, SSL and required licences;
• scheduled technical reviews when the technology requires them.

A maintenance service can help with part of this prevention, but it should not be confused with 24/7 monitoring if that service is not explicitly included.