When your business website gets hacked, the order of operations matters most: put the site in maintenance mode or take it offline, change every credential tied to it, close the actual hole with a clean backup or a manual cleanup, then request a security review from Google and check whether state breach notification rules apply. Businesses that clean up first and change credentials afterward often get reinfected through the exact same gap within days.
The first 60 minutes
Once you suspect a breach, speed matters more than a perfect diagnosis. Put the site into maintenance mode or take it fully offline so visitors don’t land on malicious content and Google doesn’t index more compromised pages than it already has. Then change every credential connected to the site: CMS login, FTP or SFTP access, database password, and anywhere else that password got reused. Save a copy of the current, compromised state before deleting anything. That copy matters later both for tracing what happened and as documentation if a breach notification becomes necessary.
At the same time, try to pin down when this started. Hosting logs or Google Search Console often show a date when unusual traffic, a new admin user, or modified files first appeared. That date matters later for figuring out which contact form submissions or customer records may have been exposed.
How to actually confirm a hack
A breach rarely announces itself with an obvious message on screen. Common signs include a warning directly in Google’s search results, an email from your hosting provider about unusual server load or outbound spam, an unfamiliar admin user inside the CMS, and redirects that only show up when you open the site in a private browser window while logged out. A customer calling to mention a strange redirect or a warning from their own antivirus software is also a reliable signal worth acting on immediately.
A quick check: open your own domain in a private browser window, then search for it separately on Google. Unfamiliar ads, a browser tab title that doesn’t match what you normally see, or an automatic redirect to an unrelated domain are clear warning signs, even when the homepage looks completely normal at first glance.
Cleanup: restore from backup or clean up manually
A verified clean backup from before the breach is, in most cases, the fastest way back online. The catch: the backup has to actually predate the infection, otherwise you’re just reinstalling the malicious code. Without a usable backup, manual cleanup is the only option: reinstall the CMS core from scratch, replace every plugin and theme with fresh original files, check the database for injected scripts or unfamiliar user accounts, and remove suspicious files one by one, including altered core functions, a tampered config file, or a rogue server config file.
Either way, closing the actual cause is not optional. A restored backup running an unpatched plugin or the same old passwords isn’t a fix, it’s a delay. The gap that let the first attacker in usually lets the second one in just as easily.
| Step | Restore from backup | Manual cleanup |
|---|---|---|
| Requires | A clean backup from before the hack | No usable backup available |
| Typical time | A few hours | One to several days |
| Main risk | Reinfection if the backup is too recent | Missed remnants of malicious code |
| Required either way | Close the hole, rotate every credential | Close the hole, rotate every credential |
Getting Google to lift the security warning
If Google is showing a security warning, a technical cleanup alone won’t remove it. Open the Security Issues report in Google Search Console and, once cleanup is complete, submit a request for review. Describe specifically what you did, which files were removed and which vulnerability was closed, since a detailed explanation speeds up processing. According to Google, review times run anywhere from a few days to several weeks depending on how extensive the hack was and how thorough the cleanup looks. Once Google confirms the site is clean, warnings in browsers and search results usually disappear within a few days of that confirmation. An incomplete review request gets rejected and adds to the total delay, so a second submission is only worth it after a genuinely thorough second look at your own cleanup.
When state breach notification rules kick in
If a contact form, a customer database, or a login system exposed personal information, or could plausibly have, check your state’s breach notification law before doing anything else. Every US state, plus DC, Puerto Rico, and the Virgin Islands, has its own statute requiring notification once a breach involving personal information is confirmed, and most set a specific deadline, commonly in the 30 to 60 day range depending on the state and how many residents are affected. Businesses that handle financial account data or fall under FTC oversight may face additional requirements under the Safeguards Rule, including notifying the FTC directly within 30 days for incidents involving 500 or more consumers. Document your assessment even if you conclude notification isn’t required, since regulators generally expect a paper trail showing how that call got made.
Preventing the next one
A cleaned-up site is a checkpoint, not a permanent fix. Keep the CMS core, plugins, themes, and PHP version updated on a regular schedule, since most breaches exploit known vulnerabilities that were already patched months earlier. Set fresh, unique passwords for every login and turn on two-factor authentication for the admin area wherever it’s available. Put a recurring backup schedule in place with storage kept separate from the live site, and actually test the restore at least once a year rather than assuming the backup works. Statically built sites without a database or a publicly reachable admin login cut the attack surface down significantly from the start, simply because there are fewer moving parts an attacker can get into in the first place.
The next step
Nothing undoes a breach after the fact, but getting the order right is what determines whether a site is clean and visible again in hours instead of weeks. Mr.Site keeps several hundred business websites actively maintained, including updates, tested backups, and a point of contact for exactly this kind of situation. For details on what that looks like, see Managed Website Service. For how ongoing maintenance prevents this from happening in the first place, see What Actually Happens Without Website Maintenance, and for how often a backup actually needs to run so there’s a clean restore point available when it matters, see How Often Should a Business Website Be Backed Up?.