My Website Was Hacked: A Step-by-Step Incident Response Plan

Finding out that your website has been hacked is stressful, and the temptation is to start deleting things at once. Resist it. A calm, ordered approach recovers the site faster and, more importantly, stops it being hacked again next week. This plan works for most small business sites, including WordPress.

The response plan, step by step

Step 1: confirm and contain

Confirm the problem is real: defaced pages, redirects, spam content, a blocklist warning, or your host reporting malicious activity. Then limit the harm:

• Put the site into maintenance mode, or take it offline with a simple static page, so visitors are not exposed to malware or phishing.
• If the hack involves a shop or collects personal data, pause orders and forms.
• Tell your host or support team what you have found. They may be able to isolate the account and see server-level logs you cannot.

Step 2: preserve evidence

Before cleaning, take a full backup of the infected site and its logs, stored separately and clearly labelled as infected. You may need it to find the entry point, to prove what happened or to meet notification duties. Save server access and error logs, because logs older than a few weeks may be rotated away.

Step 3: secure your accounts

Assume the attacker may have credentials. From a computer you trust, which is scanned and clean, change passwords for:

1. Email accounts linked to the site and domain.
2. Hosting account and control panel.
3. Domain registrar and DNS.
4. CMS administrator and editor accounts, and remove unknown users.
5. SFTP and SSH users, and database users.
6. API keys, payment gateway keys and any secrets stored in configuration files.

Turn on two-factor authentication for each of them, and log out all active sessions where possible.

Step 4: find how they got in

Cleaning without finding the cause leads to reinfection. Look for:

• Outdated or vulnerable plugins, themes and core software.
• Files modified or added around the first sign of trouble, and PHP files in upload folders.
• Suspicious admin logins or requests in the access logs.
• Pirated plugins or themes.
• Infected admin computers, if the pattern suggests stolen credentials.

Your host can often help match times in logs with the first malicious request.

Step 5: clean or restore

You have two routes.

Route	When to use	Risk
Restore a clean backup	You have a backup from before the compromise	Restoring without patching brings the vulnerability back
Clean manually	No clean backup exists	Easy to miss hidden backdoors

The most reliable method for WordPress is to rebuild: reinstall WordPress core and all plugins and themes freshly from trusted sources, delete everything you do not need, and carry over only your content, the uploads folder after inspecting it, and a reviewed configuration file. Examine the database for injected content, rogue users and unexpected scheduled tasks. Remove unknown cron jobs and check the root of the account for hidden files.

Step 6: close the hole and harden

1. Update everything, and remove abandoned plugins and themes.
2. Apply sensible file permissions, and disable PHP execution in upload folders.
3. Add a web application firewall and login rate limiting; see the security page for platform-level measures.
4. Regenerate WordPress security keys and salts in the configuration to invalidate old sessions.
5. Set up automatic backups, file change monitoring and alerts for new admin users.

Step 7: restore search and visitor trust

• If browsers or Google flagged the site, request a review in Search Console once it is clean.
• Remove spam pages from the index by serving a proper error for them, and use the removal tools if needed.
• Check your domain and IP against email blocklists if the server sent spam, and ask to be delisted once fixed.
• Re-test the site from different devices and locations for hidden redirects.

Step 8: tell the people who need to know

If personal data may have been exposed, data protection laws in many places require you to assess the risk and, where required, notify the regulator within a short deadline and inform affected people. Check the rules that apply to you, and keep notes of what you found and did. Telling customers plainly what happened and what you did about it builds more trust than silence.

Step 9: learn from it

Hold a short review. What was the entry point? What would have detected it sooner? Write down the lessons, update your checklist, and schedule a follow-up scan a week later, because some infections return.

Mistakes that make things worse

• Deleting files before saving a copy. You lose evidence and may delete things that turn out to matter.
• Restoring over the top without patching. The attacker returns through the same hole, often within hours.
• Changing only the CMS password. If the hosting account, SFTP or database credentials were stolen, the attacker keeps their access.
• Trusting a single scanner. A clean report does not prove a clean site.
• Telling nobody. Delays in notifying your host, customers or a regulator make everything harder.

A short prepared plan

Write a one-page version of this plan before you need it. Include who to call, where the backups are, who holds the credentials, and what the notification duties are. Review it twice a year, and store a copy outside the website itself. When something does go wrong, you can follow your own checklist instead of inventing one under stress. Also have a plan for communicating: a short status message for your social profiles or a simple holding page lets customers know you are working on it.

Get help early

You do not have to handle this alone. If you host with Zebra Hosting Cloud, contact the team through the contact page; support is available in 17 languages, and they can help check the account and restore from backups.