Website was hacked
The order matters more than the speed. Most sites get cleaned and then reinfected within a week, because the credentials were never changed or the hole was never closed. Here is the sequence that actually ends it.
Before you touch anything
Skipping steps here is how a cleanup turns into a monthly ritual. Step 4 is the one people leave out, and it is the one that decides whether it comes back.
Not everything that looks like a hack is one. An expired SSL certificate, a DNS change, or a plugin update can all produce alarming browser warnings. Real signs of compromise: pages redirecting to somewhere else, spam text or links in your page source that you did not add, new admin users you do not recognize, files modified at 3am, a sudden flood of outbound email, or a Google Search Console message under Security Issues. Check the source of your home page and search it for links to domains you do not know.
If the site is redirecting visitors to malware or a scam, take it offline. A maintenance page or a temporary block at the host is better than leaving it serving harm while you work. If it is defaced but not dangerous, you can usually leave it up. Then change the hosting account password and enable two-factor authentication on it, because the host account is the one that controls everything else.
Restoring is faster, more reliable, and it is what I recommend whenever you have a backup from before the compromise. The catch is knowing when the compromise started. If the backup is from after the break-in, you restore the backdoor along with the site. If you have no clean backup, or the site has changed too much since, then it has to be cleaned file by file. Restoring also loses anything added since that backup, including orders and form submissions, so export those first.
This is the step that gets skipped. Change: the hosting or cPanel password, every FTP and SFTP account, the database user password, every WordPress or CMS admin password, and the API keys for anything connected. On WordPress, also regenerate the security keys and salts in wp-config.php, which forces every existing login session to end, including the attacker session. Delete admin accounts you do not recognize instead of just changing their passwords.
Nearly always one of four things: an out-of-date plugin or theme with a known vulnerability, a weak or reused admin password, an old copy of the site sitting in a subfolder that nobody updates, or a stolen FTP credential from an infected desktop. Update everything, delete plugins and themes you are not using rather than leaving them deactivated, and remove any old installations you find lying around in the hosting account.
If Chrome is showing a red warning, that is Google Safe Browsing, and it will not clear itself the moment you fix the site. Open Google Search Console, go to the Security Issues report, confirm the problem is resolved, and request a review. Reviews typically take a few days. Requesting one while the site is still infected resets the clock, so be sure before you submit.
Reinfection usually shows up within two weeks. Keep an eye on new files, new users, and outbound mail. If it comes back, the hole was never closed and cleaning again will not help.
Small business sites are rarely targeted personally. Almost all of this is automated scanning that found a known hole and walked in.
Most common
How to check: Look at the update list. Anything that has been sitting on an available update for months, and anything the developer has abandoned, is a candidate. Publicly known vulnerabilities get scanned for at scale within days of disclosure.
The fix: Update everything. Remove what you do not use, including deactivated plugins, because the code is still on the server and still reachable. Prefer plugins that are actively maintained.
Very common
How to check: An admin account named admin, or a password you also use somewhere else, or a password a former employee still knows. Check the user list for accounts belonging to people who no longer work with you.
The fix: Unique long passwords in a password manager, two-factor authentication on the admin and hosting accounts, and remove accounts nobody uses. Do not share one login among several people.
Common
How to check: Look in the hosting file manager for folders like /old, /backup, /dev, /staging, or a second WordPress install from a redesign three years ago. They are live, reachable, and nobody has ever updated them.
The fix: Delete them once you are sure they hold nothing you need. If you want a staging copy, keep it behind a password and keep it updated like the real thing.
Common after a first hack
How to check: The site was cleaned, worked for a week or two, and got infected again with no new vulnerability. Attackers plant extra entry points precisely so a surface cleanup does not remove them. They hide in upload folders, in must-use plugins, and in files named to look ordinary.
The fix: Restore from a known clean backup rather than cleaning again, then rotate every credential. This is the case where cleaning file by file most often fails.
Less common but nasty
How to check: Your FTP client saves passwords in plain text. If a desktop was infected, those went with it. The tell is a compromise with no vulnerable software and no weak password.
The fix: Clean or replace the machine first, then rotate credentials from a device you trust. Rotating from the infected machine just hands over the new passwords.
There is no shame in this. A partly-cleaned site is harder to fix than an untouched one, and some of these carry consequences beyond the website.
Check what is externally visible yourself first, then decide how much of the rest you want to own.
SSL certificate checker
Rules out the most common false alarm: a browser warning caused by an expired certificate rather than malware.
OpenFree IT checkup
Scores security headers, email authentication, and site health so you can see what else is exposed.
OpenWebsite malware cleanup
Containment, cleaning or restore, credential rotation, and hardening. The version where I do it.
OpenWordPress security guide
The maintenance habits that keep a site off the automated scanners in the first place.
OpenWordPress backups guide
How to set up the backup you will wish you had. Do this today, not after the next incident.
OpenWebsite rescue
For sites where the hack is one symptom of a setup nobody has looked after for years.
OpenRestore, if you have a backup from before the break-in and you can afford to lose what changed since. It is faster and it removes backdoors you would never find by hand. Clean only when there is no clean backup, or when too much has changed since the last one.
Sort the files by modification date in the hosting file manager and look for a cluster of changes you did not make. Check when new users were created. Check your Search Console messages, which are timestamped. Then pick a backup from before the earliest of those.
No. If the attacker has an active session, a backdoor file, or a second admin account, a new password changes nothing for them. Rotate the hosting password, FTP, database, and admin logins, and regenerate the WordPress salts so existing sessions are invalidated.
It clears after Google re-reviews the site, which you request through the Security Issues report in Search Console. Reviews commonly take a few days. It does not clear automatically just because you fixed the files.
Almost certainly not. The overwhelming majority of small business site compromises come from automated scanning for known vulnerabilities and weak passwords. It is not personal, which is also why it happens again to anyone who does not close the hole.
Usually yes, depending on what access the current host allows. Sometimes the honest answer is that moving to hosting where I can see the whole account is faster and cheaper than fighting the old one.
Tell me the domain, what you noticed, and whether you have a backup. I will tell you whether this is a restore or a cleanup before any money changes hands.
