- Check another network, the error message, and domain and hosting status first.
- Preserve current files, the database and logs before cleanup or restoration, while protecting visitors.
- Confirm that an enquiry reaches the team after repair, as well as checking that pages open.
Website down: what to do in the first hour? Open it on your phone using mobile data, save the error message, and check your domain and hosting payments. Before deleting files, reinstalling anything or restoring an older version, make a copy of the current site. If visitors are being sent to unfamiliar websites, work with your host to protect them and involve a developer.
An outage does not automatically mean a hack. An expired domain, a server fault and malicious code need different responses. Your immediate job is to identify the symptom, preserve what remains and give the person investigating enough facts to find the cause.
What to do while the website is unavailable
- Try another network. Turn off Wi-Fi on your phone and type the address yourself. Compare it with your computer. A problem affecting only your connection is not yet a confirmed general outage.
- Record what happens. Take a screenshot showing the address, note the time and save the error text. Check the homepage and one internal page. Do not enter passwords after a warning or unexpected redirect.
- Use your usual provider accounts. Check domain expiry, hosting status, outstanding bills and notices about outages or suspension. Do not pay through a link in a suspicious email.
- Preserve the current state. You need the files, database and logs, which are the server's records of requests and errors. If you cannot make this copy yourself, ask the host to preserve them before changes.
- Reduce the damage. If compromise is suspected, ask the host to restrict public access while preserving data. Pause advertising to broken pages and give your team an alternative way to receive enquiries.
Do not delay visitor protection while waiting for a backup: ask the host to restrict access and preserve evidence in parallel. Have one person coordinate with the host and developer. Several people changing settings at once make the sequence of events harder to establish.
Match the symptom to a safe next step
The website will not open at all
Possible cause: the domain expired, DNS settings changed, hosting is unpaid or suspended, or the server is unavailable. A domain is the site's address; hosting stores its data; DNS connects that address to a server. A server not found message and a connection timeout occur at different stages, but neither identifies the cause on its own.
Check yourself: confirm the spelling, try another network and check service status in your accounts. Ask your provider how to renew an overdue service. For .ua and .com.ua domains, do not assume a universal grace period: check the zone rules and current status with your registrar.
Call a developer when: services are active but the site fails across networks, or someone recently changed the server or DNS. Do not substitute a guessed IP address; you could disrupt email as well.
The browser warns that the connection is unsafe
Possible cause: the certificate expired, renewal failed, or it covers a different address. A certificate enables a secure HTTPS connection. An incorrect device date is another possibility. A certificate warning alone does not prove that the site was hacked.
Check yourself: confirm the date on your phone and computer, verify the address and try a different network. Save the warning code. Look for certificate status and renewal notices in your hosting account. Validity depends on the certificate in use.
Call a developer when: several devices show the warning, renewal fails or only some addresses work securely. Do not tell customers to bypass browser protection or disable HTTPS as a repair.
You see a 500, 502 or 503 error
Possible cause: 500 means an internal server failure; 502 means an intermediary server received an invalid response from the next server; 503 means the service is temporarily unable to handle the request, for example during maintenance or overload. The code narrows the investigation, but does not name the broken component.
Check yourself: record the code, time and page address, then read hosting notices. Note whether an update, move or settings change happened just beforehand. Check one internal page to establish the scope.
Call a developer when: the error persists or affects a form or checkout. Give the host the time so they can locate relevant logs. Avoid repeated restarts and speculative updates.
A database connection error or blank white page appears
Possible cause: the site cannot reach its database, which stores content, settings and records, or its code stops before producing the page. Connection settings, an unavailable service or a recent code change may be responsible. A blank page does not mean that all the content has been deleted.
Check yourself: save the message, check provider notices and identify the last known change. Do not replace the existing database with a new empty one.
Call a developer when: the message repeats or the blank page followed an update. They need to examine logs and the connection after preserving data. Do not post database passwords or detailed technical errors in public conversations.
The page loads but its layout is broken
Possible cause: CSS files, which control the page's appearance, failed to load; an old saved version remains; or resource addresses changed after an update. Text may be visible while menus, spacing and buttons appear as an unformatted list.
Check yourself: take a screenshot, open a private browsing window and try your phone. Note whether every page and language is affected. A failure limited to one browser is useful evidence for the developer.
Call a developer when: several visitors see the broken layout or buttons cannot be used. Do not switch the live site's theme as an experiment; it adds another change before the original fault is understood.
Forms have stopped delivering enquiries
Possible cause: the form is not sending data, email delivery fails or the connection to the CRM has stopped. Here, CRM means the system your team uses to handle enquiries. A thank you message on screen does not confirm that a manager received anything.
Check yourself: agree one clearly labelled test enquiry with your team. Record the time, page and expected destination. Check the inbox, spam folder and enquiry list. If testing an order, do not submit it repeatedly or trigger a real payment.
Call a developer when: the enquiry never reaches its destination or delivery is inconsistent. The whole route needs checking, including what happens after the button is pressed. Give your team a working alternative contact channel until it is fixed.
Only mobile visitors or people from Google are redirected
Possible cause: injected code changes behaviour according to the device or source of a visit. Advertising inserts and connected scripts also need investigation. A normal homepage on the owner's computer does not invalidate a customer's report.
Check yourself: preserve the customer's report, time, original address and circumstances: phone, search result or direct visit. Do not explore the suspicious destination or download anything from it.
Call a developer when: you receive this report. Ask the host to help restrict harmful public responses while preserving data. Clearing your own browser cache does not establish that visitors are safe.
Google warns about hacking or lists unfamiliar pages
Possible cause: someone added unwanted pages, changed content or left traces of an earlier compromise in search results. Send unfamiliar addresses and unexpected titles in other languages for investigation, even if the homepage looks normal.
Check yourself: open Search Console, Google's tool for website owners, and its Security Issues report. Save the sample addresses without visiting dangerous pages. They are examples, not necessarily a complete list.
Call a developer when: there is a warning or confirmed unauthorised content. After all affected parts are cleaned and fixes are tested, request a review through that report. Do not assume that warnings or lost search positions will recover immediately.
Your host suspended the site because of malware
Possible cause: the provider detected malicious code or harmful activity. Restrictions and the process for lifting them depend on the host. Paying an ordinary invoice does not remove an infection.
Check yourself: read the account notice. Ask for the findings, detection time, preservation of logs and a way to obtain files and the database without publicly reopening the site. Confirm what the provider requires before checking it again.
Call a developer when: you need the cleanup assessed. Do not automatically delete every listed file; a necessary file may contain an infected fragment. Moving an infected copy to another host carries the problem with it.
Your administrator login stopped working
Possible cause: an incorrect password, a login block, an update failure or an unauthorised account change. The administration area is the private part used to manage the site. One failed login alone is not evidence of a hack.
Check yourself: verify the usual address, keyboard layout and your email. If there are no signs of compromise, try the normal password recovery process. Preserve unexpected messages about changes to the administrator or email address.
Call a developer when: recovery fails, your email was changed without permission or other suspicious symptoms appear. Do not keep guessing passwords or run instructions from strangers to modify the database.
What to do if the website has been hacked
Ask for a complete copy before cleanup: files, database and available logs. Label it as infected and keep it away from the public site with restricted access. It is evidence and a possible source of recoverable data, not a version to publish again. Record who made it and when.
From a trusted device, change passwords for hosting, administrators and the email account used for access recovery. Use different passwords and enable additional login verification where available. Ask the developer to end existing login sessions and check technical access keys. Changing one password may leave other ways in.
Review the administrator list with the person responsible for the site. Establish who created each account and whether it is needed. Preserve the list before changes, then block unknown accounts once checked. Do not send replacement passwords through the same questionable channel or share screenshots containing customer information.
Restoration requires a verified clean backup. A date before discovery is not proof of safety: the intrusion may have happened earlier. The developer needs to check the copy, close the route used to get in and agree the return to service. Without a clean backup, recovery scope depends on inspection; promising that everything can be recovered would be misleading.
Do not delete one infected file and stop. Other changes and the original entry point may remain. Do not overwrite the current site with an old backup before preserving it: recent enquiries and content could be lost. After cleanup, test the affected conditions, change relevant passwords again and request a Search Console review if Google reports security issues.
Our snapshot of websites that would not open
On 21-23 October 2026, we checked 2,042 Kharkiv company websites once each, using addresses from Google Maps business listings. Domains did not resolve for 98, servers did not respond for 81, and 72 returned HTTP 4xx/5xx error pages, including 13 server errors in the 5xx range. Separately, 148 lacked a working secure HTTPS connection. Another 39 sites prohibited checking and were excluded from the counts.
This was one observation per site, not a measure of outage duration or a count of hacks. A site may have been down for minutes, while an inactive domain can belong to a closed business. Do not add the figures as unique incidents. Our website problems research describes a different sample and method.
How to check that recovery is complete
Open the site on a phone using mobile data and on a computer. Check the homepage, a service or product page, language versions and the normal enquiry route. If the failure depended on arriving from search, ask for that exact condition to be tested without unsafe visits to infected pages.
Send an agreed test enquiry and confirm that the team receives it. For a shop, agree a separate cart and checkout check without accidental real payments. Ask for a short record of what happened, what was restored, which backup was used, what remains restricted and who owns the next check. A working homepage is only part of the result.
Getting help with recovery
Artbrain takes over the website, assesses its current condition and agrees the next steps. For a hacked or infected site, we explain the recovery scope and start after the estimate is agreed. The task review is free; the work, timeline and cost are agreed before work begins.
Handover from a previous developer, missing access, platform differences and planned updates are covered on our website support and improvements page. For planning after the incident, see our separate guide to website maintenance costs.
Tell us what stopped working: send the website link, when the problem appeared, the error message and the last known change. Say whether a backup exists and whether you can sign in to your hosting and administration area. No passwords are needed in the first message. These facts are enough to begin discussing the next step.
FAQ
My website is down. What should I check first?
Open it on your phone using mobile data, record the error and time, and check domain payments and hosting status. Before deleting, reinstalling or restoring an older version, preserve files, the database and available logs. If compromise is suspected, ask the host to restrict public access while preserving data.
How can I tell whether my website was hacked?
Suspicious signs include redirects to unfamiliar sites, unknown pages or administrators, a hosting malware notice, or security issues in Search Console. A 500 error or expired certificate alone does not prove a hack; the cause needs investigation.
Can I restore a backup immediately?
Preserve the current state first so recent enquiries and content are not lost. The backup used for recovery must be checked for infection and the entry point addressed. A date before the hack was discovered does not guarantee a clean copy.
Why does my website redirect only on mobile or from Google?
Injected code can change behaviour according to the device or source of the visit. Record the original address, time and conditions without exploring the dangerous destination. Tell your developer and host even if the site looks normal on your computer.
What should I send for a website recovery estimate?
Send the website link, when the problem appeared, the error, the last known change and whether a backup exists. Say whether you can access your hosting and administration area. No passwords are needed in the first message. The task review is free; work starts after the estimate is agreed.
