Website Hacked? What a Small Business Should Do First

Short answer: Take the site offline properly (a 503 page served from outside the compromised server), tell your host, and copy the infected files and database before you change anything. Then remove unknown accounts, change every password, restore from a backup made before the hack, patch everything, and only bring the site back when you've found how the attacker got in. If Google flagged the site, request a review in Search Console's Security Issues report once it's clean. If customer personal data may have been exposed and you're subject to the GDPR, the clock for notifying your data protection authority is 72 hours from when you become aware, where feasible.

The first hour: contain

1. Take the site offline, the right way. Google's web.dev recovery guide recommends stopping the web server or pointing DNS to a static page on a different server that returns a 503. It warns that returning a 4xx or 5xx code from the infected server isn't enough, because harmful content can still be served, and that a robots.txt block only stops search crawlers, not visitors. The same guide says taking a site offline during recovery is unlikely to affect its future rankings.

2. Call your host. They may see the same attack on other customers, can set up the 503 page from outside your files, and can tell you what logs they keep and for how long.

3. Tell the few people who need to know. Whoever manages the site, whoever handles customer contact, and whoever is responsible for data protection. Agree that nobody "quickly fixes" files yet.

4. Check the obvious exits. Is the site sending spam email? Are payment pages changed? If you take card payments directly on the site, contact your payment provider now.

Hours 1–4: preserve and investigate

5. Make a copy of the infected state. Before deleting anything, archive the files and export the database. Google's cleanup guide shows exactly this step (a full archive of the web directory plus a database dump labeled "infected") before restoring. You'll need it to understand what happened, and possibly to show a regulator or insurer.

6. Save the logs. Web server access logs, CMS activity logs, hosting control panel logins and FTP/SSH logs. Some hosts rotate logs after a few days.

7. Write a timeline. When was the problem noticed, by whom, what did you see, what has been done since. Keep it running.

8. Look for the way in. Google's guide lists typical entry points, starting with a virus-infected administrator computer recording passwords, and recommends scanning every computer an admin has used to sign in. Other common causes: outdated CMS, plugins or themes; reused or leaked passwords; abandoned admin accounts; insecure file permissions. Google also warns there may be multiple, independent hacks, so keep looking after you find one.

Hours 4–24: clean and restore

9. Remove intruder accounts and change every password. The web.dev guide says to check for user accounts the hacker created, note them, delete them, and change passwords for all site users and accounts, including FTP, database, system administrator and CMS logins. Add to that: hosting account, domain registrar, DNS provider, email accounts linked to the site, API keys and payment integrations. Turn on two-factor authentication wherever it's offered.

10. Restore from a clean backup. Check the backup was created before the compromise. Google's guide separates three cases:

Clean and current backup: restore it, then install all updates and patches
Clean but outdated backup: archive the infected site, restore the old backup, update everything, then carefully re-add newer content
No backup: clean the infected copy file by file, which usually means professional help

11. Patch and prune. Update the CMS, plugins, themes and server software. Remove plugins and themes you don't use; every unused component is extra attack surface.

12. Fix the root cause. Restoring without closing the hole often means being hacked again within days.

Days 1–3: clear warnings and notify

13. Check Search Console. The Security Issues report lists hacked content (code injection, content injection, URL injection), malware and social engineering problems, with example URLs. Confirm the issue is gone on those URLs, then click Request a review. Google's help page says a review can take from a few days to a few weeks. Its recovery guide suggests describing what you did for each issue type, for example removing injected spam and updating the outdated plugin that let the attacker in.

14. Clean up search results. Use Search Console to request removal of spam URLs the attacker created and ask Google to recrawl your cleaned pages.

15. Decide whether this is a personal data breach. If the attacker could access customer accounts, form submissions, orders or a mailing list, treat it as a possible breach.

When the law gets involved

Under GDPR Article 33, a controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it's unlikely to result in a risk to people's rights and freedoms. Late notifications must explain the delay. The notification describes the nature of the breach, the categories and approximate numbers of people and records, a contact point, likely consequences and the measures taken. Information can be provided in phases.

Article 34 adds that where a breach is likely to result in a high risk, you must also tell the affected individuals without undue delay, in clear and plain language.

Where the GDPR doesn't apply, rules differ by country and, in the US, by state. Check the rules for where your customers live, and talk to a lawyer if personal data was involved. This section is general information, not legal advice.

Hour-by-hour checklist

When	Action
0–1 h	503 from outside the server, call host, inform key people, check payment pages
1–4 h	Archive infected files and database, save logs, start timeline, look for entry point
4–24 h	Remove rogue accounts, change all credentials, restore clean backup, patch, fix root cause
24–72 h	Search Console review, spam URL removal, breach assessment, notifications if required
Week 1+	Monitoring, backups tested, update routine, 2FA everywhere

FAQ

Should I just delete the site and start again?

Only after you've archived the infected copy and found the cause. A fresh install on the same compromised hosting account, with the same passwords, can be reinfected.

How do I know the hack is really gone?

Fetch your homepage and a previously infected URL with a tool like cURL, as Google suggests, check that Search Console shows no issues, and watch logs and new admin accounts for a few weeks.

Will this hurt my Google rankings?

Google says temporary downtime during recovery is unlikely to affect future rankings. Leaving spam or malware online is what does the damage.

Do I have to report it to the police?

Not usually required, but in many countries you can report cybercrime to a national reporting service, and insurers may ask whether you did.

If your site has been compromised and you need a calm pair of hands, get in touch with the details you have so far.