Site interruption – where does this problem come from and how to solve it?

A website outage can be caused by a number of factors – from a failure on the server side, to increased traffic or work on the site, to a scheduled migration of the site to new hosting.

The key, however, is to keep a cool head in case of unexpected difficulties, quickly track down the source of the problem and eliminate it efficiently on your own or with the help of the hosting provider.

Read on and find out the most common causes and methods of preventing site crashes, when to use a “blanking” (maintenance break), and whether a site crash can affect its ranking in Google.

Site break – most common causes and prevention methods

.
There are many factors that can cause a site to break. Some of them may contribute only to a short unavailability, while others may translate into a long-term inability to access the site. Some of the most common causes include:

• technical problems with the server;

.

• application errors (the site engine or its add-ons/plug-ins);

.

• overload of the site due to increased traffic or DDoS attack;

.

• moving the site to a new server;

.

Technical problems with the server

.
This is usually the first thought that comes to mind when a website crashes. Hosting can stop working as a result of a technical (e.g. hardware) or network failure, or as a consequence of a server or domain misconfiguration. Of course, by choosing the right web hosting for the site, most of these failures can be avoided.

A good web hosting provider should have an infrastructure that is resistant to hardware failures (e.g. by using redundancy on multiple levels, i.e. having “spare parts” of the server that automatically take over the operation of a failed component). It should also help you quickly fix a server configuration that is inappropriate for your website (e.g., an incompatible PHP version), or the configuration of your domain’s DNS zone (e.g., after accidentally deleting one of your records).

Application bugs or vulnerabilities

.
These are some of the most common causes of website crashes. They can occur as a result of installing incompatible versions of software, add-ons (plugins, themes, integrations) or updating them. Another cause can be having an outdated version of the site. Website engine errors can also occur as a result of upgrading the server to versions no longer supported by your application.

Virus infections are also a common source of site accessibility problems. These can appear on the site if only as a result of using modules, plugins or themes that have not been updated. Infected files may have code fragments and scripts in them, which, when executed, are designed to redirect the user to a pornographic or offer site. There are also scripts that “in the background” perform other operations that load the server, such as cryptocurrency digging. This obviously puts a strain on the hosting, slows down the loading time of the site, and can lead to its complete unavailability.

Fortunately, you can protect yourself from application bugs and vulnerabilities. All it takes is:

• install tested add-ons and verify their compatibility with the site engine;

.

• maintain the site up-to-date;

.

• make backups (backups) before doing major work on the site

.

In contrast, avoiding virus infections will help:

• good practices when building and expanding a site (only tested add-ons);

.

• regular updates to the site engine, plugins, theme, PHP version;

.

• strong and hard-to-crack access passwords (to the web server, database, backend of the site);

.

• regular virus scans (preferably performed by the hosting provider);

.

• regular cleaning of the site from unnecessary plug-ins;

.

• separation of sites when hosting more than one website on the same server;

.

Page overload with excessive traffic

.
Contrary to what you may think, this cause of site failure is not reserved only for popular sites. A small site that has been linked on a popular social media group or a service like Wykop can also fall victim to a crash as a result of increased traffic. It can be said that the site becomes a victim of its unexpected success – a sudden surge of visitors can paralyze the performance of the server processor, exhaust the available RAM or the connection limits imposed on the hosting, which were previously sufficient to handle a site with little reach and traffic. The server, when it lacks the resources needed to handle requests, will display visitors a 503 error.

Site overload can be caused not only by desired traffic (customers, visitors), but also by bot activity. Bots can “attack” our site, for example, through an unsecured contact form or comment form. The more attempts to leave a comment or send a message, the more traffic, more requests the server has to handle, and consequently – less available power on the server.

Another type of overload is aDDDoS attack, which is an attack that involves bots querying a server or site from multiple devices at the same time to occupy all available resources. The result of a DDoS attack is the inability to connect to the site, and therefore – the unavailability of the site to customers and visitors.

Responding to a site failure that occurs as a result of an overload is more difficult, but not impossible. If your site is a popular site, take care of server flexibility when choosing hosting. During promotional events, Black Friday, or, for example, a TV visit, you will strengthen the server with additional resources (CPU, RAM), and thus – make it immune to sudden overloads.

If increased traffic is something you can’t anticipate, make sure your web host is ready to boost server resources when your site needs it. Definitely bet on a cloud solution, if only in the form of a private cloud (cloud server), which will give you flexibility and greater stability.

In overcoming unwanted bot traffic, it will help you secure your contact forms and comment forms with captcha, for example. Leave the protection against DDoS attacks to your web host. Before choosing a server, however, make sure that it uses mechanisms to block such attacks, and that it hosts its services in independent data center locations, with independent connections from different carriers and ISPs.

Propagation of DNS zone – service migration

.
Not every interruption is caused by malicious or problematic activity. Temporary unavailability can also occur for activities that we ourselves intentionally perform. One example is the migration of a service to a new server.

The process of moving the site’s files itself does not affect its operation. The data is copied between hosts imperceptibly and very quickly. After the migration, however, it is necessary to direct the domain to the new hosting. To do this, you need to change the DNS records of the domain. Changing DNS records causes propagation. This is the time when the domain “refreshes” on the Internet. Sometimes propagation happens so that up to X hour, the website runs from the source server, and from X hour, from the destination server. In such a case, propagation does not cause any interruption in the operation of the site. However, it may happen that the site runs until X hour from the source server, and only a few hours later it starts running from the server to which the migration was performed.

There are methods to influence (shorten) the propagation by setting the frequent refresh of DNS records (TTL to a maximum of a small number of seconds), but keep in mind that the propagation process can take up to 48h and will not end at the same time in all locations.

Page outage – how to find the source of the problem?

.
When an outage occurs, it is not uncommon for us to panic immediately, accompanied by a lot of stress and unnecessary nerves. Meanwhile, it’s best to keep a cool head and go through some basic steps that will lead us to a diagnosis.

To start, I suggest answering a few questions:

.
1. Whether and what kind of work was being done on the site before the failure occurred

.

2. Was the server configuration changed recently, if so – what settings were made?

.

3. Was the domain configuration changed recently, if so – what settings were made?

.

4. Did I forget to pay the domain and/or hosting?

.

If the crash occurred as a result of work being carried out on the site, I suggest restoring the site backup from the last backup (preferably if done by the hosting provider), and then carrying out further work already on the working version of the site (not on the production version).

If the changes were carried out as part of the server or domain configuration – ask the hosting provider for help in restoring the configuration to its pre-edit state.

If you have not paid for the domain or hosting – immediately transfer the required funds and send transfer confirmations to restore the comments as soon as possible.

The failure did not occur as a result of ongoing work, and the domain and hosting are paid. What next?”

.
If the answer to all of the above questions is “no,” it’s time to move on to the next step of verification. Check the performance of the site on different devices with internet from different providers. If the failure is network-based, you may find that the page from the operator Orange will not display, but displayed using the Internet from Play will already work correctly.

Still not working? At this stage, I suggest you make a phone call to the hosting provider’s hotline and make sure that there is no server failure (it is also worth asking whether the domain is working properly – it is in active status).

If there is a failure, it remains to keep your fingers crossed that it is resolved as soon as possible. If the failure is not present – keep looking.

It is worthwhile in this situation to have the hosting provider diagnose the failure. This diagnosis should focus on analyzing the server logs and if the logs do not indicate a problem – performing a scan of the server for a virus infection.

If the logs are “clean” and the scan did not show anything, the situation becomes much more complicated, but a good hosting provider should not give up in the search for the source of the problem, and finally (if the fault lies on the server side) – solve the difficulty.

In case you can’t get competent support, a site backup, that is, restoring the site from the last backup, can come to your aid.

Page viruses vs SEO

.
If a virus scan has indicated suspicious files or detected infections, act quickly. You can either de-virus the site yourself orb have it de-virused by your web host or a third-party expert. After the de-virusing process, take care to secure your site to avoid a recurrence of the infection. Perform an update of the site engine and installed add-ons, remove unnecessary add-ons (e.g. plug-ins you no longer use), change passwords for access to the site’s admin panel and FTP server, and check if there is any forgotten copy of the site on the server. If so – remove everything that is unnecessary. At the stage of securing the site, it is a good idea to ask for support from a Web Developer.

Unfortunately, leaving an infected site can have very bad effects on SEO. Google protects users from unwanted software. If an infection is detected on a site, users who visit it will receive a warning about dangerous content and often abandon further visits. In addition, Google blocks sub-pages that contain malicious scripts from displaying in search results.

Site maintenance outage

.
Problem diagnosed? It’s time to proceed with its solution! If you can’t fix the errors “in the background” of the site’s operation, you should schedule a site maintenance break. A site maintenance break will also come in handy in the event of a major site redesign, upgrade, or during repair work.

The purpose of introducing a maintenance break is to hide an imperfect version of the site, or the display of errors on the site, from the visitor and the customer (especially if we have enabled debugging mode during the repair). However, this break should be as short as possible, and we should carry out maintenance work (if possible) during the hours of least traffic on the site.

The interruption caused by scheduled and time-consuming work should be accompanied by the appropriate HTTP code (code 503). The introduction of this code causes the server, if visited by Google’s robot, to tell it that the unavailability of the site is a temporary condition. This code will also work well if our site has crashed and many of its subpages are marked with a 404 error. The 503 code will be the “lesser evil” in this case.

How does a page break affect SEO?

.
A short page break, regardless of the source of the problem, should not cause any unpleasant consequences for Google positions. Most often, robots won’t even have time to look at the site during its unavailability.

If the interruption is prolonged and the robots look at our subpages during the unavailability, we may see temporary drops in positions. However, it all depends on how long the outage condition persists and how many subpages are visited by the robot during the outage. You will see possible fluctuations in Google visibility in the Senuto Visibility Analysis chart:

.

If the site is read correctly during the next visit of the robots, the positions will in all likelihood quickly return to their place. The longer the failure, the more time the return process may take. If you are concerned about waiting a long time for a return, once the difficulty is resolved, it is worth inviting the robot to our site using the Google Search Console tool.