What to Do in the First Hour After a WordPress Site Is Hacked

If the site is redirecting visitors, serving malware or sending spam, stop that harm first. Depending on the hosting, put the site into maintenance mode at the server or CDN level, restrict access to your own IP address or ask the host to suspend public access temporarily. Do this at the server or CDN rather than with a WordPress plugin, because you cannot trust WordPress itself at this point.

If the site processes payments or stores customer accounts, assume data may be affected until you know otherwise. Pause checkout if necessary and contact your payment provider. Write down the time you noticed the problem and what you saw; you will need that timeline later.

Before deleting, restoring or updating anything, take a full copy of the current files and database, and download the web server access and error logs. Many hosts keep logs for only a few days, so this step is urgent. Store the copies away from the server, and label them as compromised so nobody restores them by mistake.

This snapshot is your evidence. It lets you, your developer or a security specialist work out how the attack happened and what was touched, without the clock ticking on a live, infected site. It also matters if you later need to tell customers, insurers or authorities what happened.

Most WordPress compromises come through a small number of routes: a vulnerable plugin or theme, a stolen or weak administrator password, a compromised hosting or FTP account, or another infected site on the same server. Check the installed plugins and themes against known vulnerabilities, especially anything outdated, abandoned or installed from an unofficial source.

Then look at the evidence. Search the file copy for recently modified PHP files, unfamiliar files in the uploads folder, which should not normally contain PHP, and code that uses obfuscation such as long base64 strings. Compare the core files with a fresh download of the same WordPress version. In the access logs, look for POST requests to unusual files, requests to plugin paths with known vulnerabilities and logins from unfamiliar locations around the time the problem started. Check the users table for administrators you did not create.

• New or unknown administrator accounts
• PHP files in the uploads directory
• Core files that differ from a clean download
• Outdated or nulled plugins and themes
• Unusual POST requests in the access log before the first symptom

If you know the entry point and the damage is limited, cleaning can work: remove malicious files and code, replace WordPress core, plugins and themes with fresh copies from trusted sources, remove unknown users and close the vulnerability. If the infection is widespread, the entry point is unclear or it has happened before, rebuilding is safer: a fresh install with clean copies of every component, the content imported from a verified-clean database and media checked before it is copied across.

A backup is only a good restore point if it predates the compromise and you have closed the hole. Restoring an older backup without updating the vulnerable plugin brings the weakness straight back. The malware removal guide and the backup strategy guide cover these steps in more detail.

Assume every secret the site could reach has been seen. Reset the passwords of all WordPress administrators and editors, and ask other users to reset theirs. Change the authentication keys and salts in wp-config.php, which signs out every session. Change the database password, the hosting control panel, SFTP and SSH credentials, and the passwords of any email accounts on the domain.

Rotate API keys for payment gateways, email services, analytics and any other connected system, and check those systems for unexpected activity. Turn on two-factor authentication for administrators and the hosting account. The login security guide and the two-factor authentication guide explain the setup.

Hacks often leave search damage behind: spam pages indexed under your domain, a security warning in search results or a blocked domain in browsers and email filters. Check the Security issues and Manual actions reports in Google Search Console, and Bing Webmaster Tools. Once the site is clean, request a review through those tools and remove injected spam URLs, returning a 404 or 410 for them.

Check whether your domain or server IP has been added to email blocklists if the site sent spam, and request removal once the cause is fixed. Keep an eye on search results for your brand name over the following weeks.

If personal data may have been accessed, you may have legal duties to notify affected people or authorities, and contracts with clients or payment providers may require notice too. In India, the Digital Personal Data Protection Act and CERT-In's reporting directions can both apply, and other countries have their own rules. The requirements and deadlines depend on the data involved and your organisation, so take legal advice quickly rather than guessing.

When the site is stable, write a short post-mortem: what happened, how it was found, the entry point, what was affected and what will change. Common outcomes are automatic updates for plugins, removing unused plugins, a web application firewall, tested off-site backups and regular vulnerability scanning. The security hardening checklist is a good starting list, and the WordPress performance and maintenance service explains how I can help with recovery and ongoing care.