The signs, three of which are invisible from your browser
The visible hack, with a defacement page instead of the homepage, has become rare. It pays nothing. What pays is quietly using your domain name, and being quiet is part of the plan.
- Pages that are not yours in Google. Search
site:yourdomain.comand scroll. Pages in a foreign language, or on unrelated subjects, signal injected content. - A Search Console warning. Google notifies the verified owner. Someone still has to read that mailbox.
- Redirects that only fire for some visitors. From a phone, or from a Google link, but never when you type the address directly. That is deliberate: the owner sees nothing.
- Emails you did not send. A spike in bounced messages, or customers receiving messages in your name.
- Recent files nobody uploaded. Visible in your host's file manager, in the modification date column.
The six steps, in this order
1. Tell your host. Before anything else. They hold backups and access logs, and have sometimes already spotted the incident on other sites on the same server. They are also the ones who can cleanly suspend the site during the work.
2. Change every password, from another device. Hosting panel, database, site admin accounts, FTP, and the associated mailbox. From another device, because if the usual machine is compromised, you are changing passwords under the attacker's eyes.
3. Understand how they got in, before restoring. This is the step people skip and pay for. The classic ways in: an outdated plugin or theme, a weak admin password, a backup or configuration file left publicly reachable.
4. Restore a backup from before the intrusion. Before, not the most recent one. If the intrusion is three weeks old and you restore yesterday's backup, you also restore the back door.
5. Update everything that can be updated, then remove what is not used. A deactivated plugin is still installed, therefore still attackable.
6. Request a review from Google if the site was flagged, from Search Console. Without that request, the red warning can stay up long after the repair.
The mistake that makes you start over
It fits in one sentence: restoring before identifying the way in. Restoring puts the site back as it was, including the flaw that was used. The attack replays, often within days, sometimes automatically since many compromises are the work of bots that come back around.
A second, more insidious mistake: believing a brochure site with no customer data is of no interest to anyone. What is of interest is not your content, it is your domain name. A legitimate domain, with a little age, is useful for sending emails that pass filters and hosting pages that rank. You are not the target, you are the tool.
What actually reduces the risk, beforehand
Three habits, in order of return on effort:
- Updates, actually applied. The vast majority of small-business site compromises exploit a known flaw fixed months earlier. The patch existed, it was not applied.
- Leave nothing lying at the root. Backups, database exports, configuration files renamed to
.old: that is the subject of our article on the files you should never leave reachable. - Two-factor authentication on the admin area and on the associated mailbox. That is what neutralises a stolen password.
The rest, security headers and server hardening, is covered in the website security guide.
What to keep, and why
The natural reflex after an intrusion is to clean everything as fast as possible. That is understandable, and it is the best way to lose what would let you understand.
Before restoring, ask your host for a copy of the access logs for the period, and take a backup of the compromised site as it is. It is not meant to be put back online: it is there to identify the first modified file, therefore the way in. Without it, you restore blind and will never know whether the flaw is closed.
Two situations call for extra steps. If personal data may have been accessed, the European regulation requires notifying the supervisory authority within 72 hours, and informing the people concerned when the risk to them is high. A brochure site with a simple contact form is concerned if the message log was reachable.
Second: reporting it to the police. It will probably not identify the author, and that is not the point. It officially dates the incident, which matters if a customer disputes an invoice, if your insurance covers cyber risk, or if your domain lands on a blocklist and you need to show good faith to get off it.
What our audit measures
The exposure and sensitive files category holds 8 checks: sensitive files served publicly, directory listing enabled, software version announced by the generator tag, reachable admin and deployment paths, abandoned JavaScript libraries, sensitive paths revealed by robots.txt, visible technical error messages, and detected technologies. A neighbouring category, automation layer exposure, adds 4 more, including secrets and keys left in plain sight in the page code.
What the audit does not do, and this matters: it looks at your website from the outside, like a visitor. It does not detect a back door already installed in your files, nor injected content that only appears for Google. It measures open doors, not intruders already inside. After a compromise, examining the files server-side remains essential.