Your website was hacked. What to do next

The site is showing someone else’s content, sending people to another domain, or Google has flagged it. You need the site back, and you need the way in closed. Deleting one spam page and going live again is how this repeats by tomorrow.

The operator checklist, with the decisions about taking the site offline and what to tell customers, is Website hacked. This page is the first hour, plus what Google will ask for before they remove a warning.

What you are looking at

Google shows “This site may be hacked” when they believe someone changed existing pages or added spam pages. Their public note says a visit can redirect people to spam or malware, and they recommend that searchers stay away until the warning is gone. That note is This site may be hacked.

Owners see the same problem in Search Console, under Security Issues. The report gives you a sample of URLs, not a complete list. Google says an empty sample does not mean the site is clean. It means they could not build a sample.

If customer data, a database, or a credential was exposed, you have a second incident on top of the defacement. Private data appears in a public repository and Production API key leaked are the ones to open if a secret or a dump went out with the hack. Do not paste customer records into a chat while you coordinate.

Get a clean foothold

Sign in to the host, the registrar, and the CMS from a computer you trust. The machine you usually use may be where the password was stolen. Change those passwords after you are on a clean device, not before, or you type the new one into the same malware.

Decide whether the site stays up. Leaving it online keeps the spam in front of visitors and may keep giving the attacker a session. The playbook treats “keep it online so we do not lose the afternoon’s orders” as a decision you write down, not as the default.

Ask the host what they can see. Shared hosting often means you cannot inspect the server yourself. A host who has dealt with this before is faster than a long night of guessing which plugin it was.

Clean the whole site, then ask Google

Google’s fix steps are in the Security Issues report help:

1. Open each issue, read it, and follow the “Learn more” link for that issue type.
2. Use the sample URLs to find the pattern. Then search the rest of the site for the same pattern. The sample is not the full infection.
3. Fix every issue, on every affected page. Google says a partial cleanup does not get you partially back into search.
4. Test the fixes.
5. When the report’s issues are fixed everywhere, choose Request Review. Describe the issue, what you did, and how you checked it.

You get a confirmation that the review started. Google says not to send another request before they decide the open one. Reviews take time. They email you. There is no honest way to quote a number of days, because their page says it varies and does not promise one.

Register the site in Search Console if you have not. Without it you cannot see the sample URLs or file the review. The warning on the search result is removed after Google checks the site, not when you delete a folder and hope.

Close the way they got in

A deleted file is not a fix if the password, the plugin, or the extra admin user is still there. Work through this before you call the site recovered:

• Remove admin users you did not create. Reset passwords for the ones you did.
• Update the software that was left behind. An old plugin is a common door. The playbook’s point is that the vulnerable version has to go, not only the spam it delivered.
• Rotate credentials that lived on the server: database, API keys, deploy keys, the registrar. If a key was in the repo or in a public file, the API-key playbook is the rotation list.
• Check DNS at the registrar. A hack that changes nameservers is DNS change takes the business offline as well as a content hack.
• Restore from a backup only if you know the backup is from before the intrusion. A backup taken yesterday may already contain the webshell.

If you are not sure you can find every change, a reinstall onto a new host from a known-good copy is slower and often cleaner than editing the live server. The playbook goes further into evidence and who is allowed to make that call.

Customers and data

If the only change was spam pages, say that when you know it, and say how you checked. If you do not know whether data was copied, do not announce that nothing leaked. Quiet theft often leaves the pages looking normal.

If other people’s personal data was involved, you may have to tell a regulator and the people affected. The clock and the threshold depend on the country. We are not stating a single worldwide deadline here, because there is not one. Name someone to own that decision today, even if the notice goes out later. The website playbook lists the regulator guides to open for the US and the UK, and you should confirm those pages still match your situation before you send anything.

Before you call it finished

Search Console shows no open security issues, or a review is pending and you have not resubmitted. A test account can sign in, and unknown admins are gone. Passwords and keys that were on the server have been replaced. The home page is yours, and a site: search is not full of pages you never wrote.

Then run the prepare section of Website hacked. The item that matters most is a backup you have actually restored once, on a spare environment, before the next quiet compromise.

Related playbooks

• Website hacked. An attacker may have altered your site, stolen data, installed persistence, or gained access to connected systems.
• Private data appears in a public repository. Customer information, credentials, internal documents, or private source code were pushed to a public repository.
• Production API key leaked. A credential that can read data, spend money, send messages, or control production has been exposed.