What to Do When Your WordPress Site Is Hacked

If your WordPress site is hacked, take it offline, rotate every admin credential, and replace modified files with clean copies from official sources. At Layer3Labs, we build and operate web infrastructure across our own portfolio and client deployments, and we treat every breach as a containment event before conducting forensic discovery. Rapid isolation prevents automated scripts from stealing customer records, executing malicious redirects, and triggering domain blacklists.

Most attacks exploit vulnerable extensions rather than server infrastructure. Security intelligence from Patchstack reveals that researchers identified 11,334 new vulnerabilities across the WordPress ecosystem in 2025. Third-party plugins accounted for 91% of those security flaws, while themes represented 9% and the core codebase experienced only 6 flaws. Automated web scanners continuously target unpatched plugins, inject unauthorized administrative profiles, and embed spam content into published posts.

A compromised installation disrupts daily business revenue and degrades customer trust. Resolving the problem requires methodical containment, root-cause identification, and search engine status repair. Once the immediate incident is contained, website owners must also evaluate whether maintaining a dynamic content management system justifies ongoing security overhead or whether moving to a static architecture provides better long-term protection.

The First Hour After a WordPress Site Is Hacked

Taking your website offline with an HTTP 503 Service Unavailable status code stops malicious scripts from executing while signaling to search crawlers that the outage is temporary. Leaving a defaced or redirecting site online allows automated scripts to infect visitors and accelerates search engine penalties.

Update every credential connected to your hosting environment immediately. This includes your hosting control panel, Secure File Transfer Protocol (SFTP) access, Secure Shell (SSH) keys, database user passwords, and all WordPress dashboard administrator profiles. Modifying database passwords requires updating the corresponding values in your configuration file so WordPress can reconnect to your database.

Managed web hosts like WP Engine, Kinsta, and Hostinger run support desks that can pull web server access logs for you. Ask what cleanup and restoration they cover, because that scope differs by host and plan.

• Place the website in 503 maintenance mode to restrict visitor access and prevent search engines from indexing spam scripts
• Change credentials for your hosting account, database user, SFTP accounts, and WordPress administration profiles
• Generate fresh authentication security keys and salts inside wp-config.php to invalidate active sessions
• Contact hosting support teams to review server access records and isolate adjacent hosting directories

Identifying How Attackers Entered the System

Finding the root cause of an intrusion requires inspecting access logs, file modification timestamps, and active extensions. Without identifying the initial vulnerability, reinstalling clean files often results in reinfection within hours.

Vulnerability distributions explain why most breaches occur. In the Patchstack 2026 security report analyzing 2025 incident data, 91% of 11,334 discovered vulnerabilities existed within plugins, 9% occurred in themes, and only 6 flaws occurred in WordPress core code. The report also documented that 46% of vulnerabilities were not fixed in time for public disclosure. Outdated plugins, abandoned commercial themes, and weak passwords represent the primary entry points.

Review server access logs for unusual POST requests directed toward administrative endpoints or files inside your uploads folder. Attackers routinely disguise web shells as image files or hide backdoor functions inside dormant plugins. Check the user database table for newly created administrator accounts that your team did not authorize.

• Cross-reference active plugins against public vulnerability databases to flag unpatched security defects
• Search server access logs for suspicious POST requests targeted at wp-admin or upload directories
• Audit the WordPress users table to locate and delete unauthorized administrative accounts
• Remove nulled commercial themes and pirated plugins that frequently contain pre-installed backdoors

Clean Restoration Versus Manual File Scrubbing

Restoring clean core files and database tables from an off-site backup created prior to the breach is safer than attempting manual malware removal. Attackers hide persistence mechanisms across system folders, making complete manual cleanup difficult without missing hidden code.

If you possess a verified clean backup, delete your existing web files completely rather than overwriting them. Overwriting infected directories leaves orphaned PHP files intact. Reinstall fresh WordPress core files directly from WordPress.org, download verified plugin packages from original repositories, and import your clean database file.

If a clean backup does not exist, manual restoration demands a strict file replacement protocol. Delete the wp-admin and wp-includes directories entirely before uploading fresh copies. Inspect your uploads directory to remove any executable PHP files, verify your configuration file for unauthorized code injections, and scan the database options table for suspicious script tags.

Hardening Defenses Against WordPress Security Issues

Hardening a recovered website requires reducing access privileges, enforcing multi-factor authentication, and restricting file modifications. Limiting exposure vectors protects the site against automated credential-stuffing bots and cross-site scripting vulnerabilities.

Enforce two-factor authentication across every user account capable of publishing or altering content. Restrict user privileges according to daily responsibilities, granting administrator privileges only to technical personnel who manage updates. Authors and marketing staff should use standard roles that lack permission to install extensions or modify themes.

Deploy a web application firewall at the Domain Name System (DNS) or server level. A web application firewall analyzes incoming traffic, blocking malicious requests before they reach your PHP execution environment. Disable file editing inside the administrative dashboard by setting the file edit restriction constant to true inside your wp-config.php file.

• Require two-factor authentication on all administrative and editorial user accounts
• Assign least-privilege user roles to prevent non-technical staff from installing extensions
• Disable dashboard file editing to prevent attackers from editing theme and plugin code directly
• Delete inactive plugins and themes so their dormant code cannot be exploited by web scanners

Resolving Google Search Console Security Warnings

Clearing Google search penalties and deceptive site warnings requires submitting a security review request inside Google Search Console after all malicious code is removed. Compromised websites frequently suffer traffic drops when search engines flag them for hosting spam or phishing redirects.

Open Google Search Console and navigate to the Security and Manual Actions section. Review the specific sample URLs that Google identified as deceptive or harmful. Confirm that every listed spam page has been removed and returns an HTTP 404 Not Found or 410 Gone status code.

Submit a detailed review request once your technical team confirms the cleanup is complete. Explain the vulnerability that enabled the breach, outline the steps taken to eliminate malicious files, and summarize the hardening policies applied to the server. Google reviews the request and removes the warning once it confirms the cleanup. It does not publish a turnaround time.

Deciding Whether to Stay or Leave WordPress

A site breach exposes the operational overhead required to secure WordPress and prompts teams to evaluate modern static or hosted architectures. WordPress powers 40.3% of all websites according to W3Techs data from September 2026, making it the most frequent target for automated web exploits.

Static websites eliminate dynamic security risks because they contain no database, no PHP runtime, and no administrative login screen for remote attackers to exploit. Converting your installation using our guide on how to migrate WordPress to a static site removes the entire dynamic server attack surface. Similarly, comparing options in our guide to WordPress alternatives reveals modern platforms where engineering teams manage core infrastructure security automatically.

Staying on WordPress remains justifiable for organizations with dedicated technical staff, dynamic user memberships, or advanced eCommerce requirements that depend on database execution. If your team cannot commit to continuous plugin updates and routine security audits, migrating content to static hosting or a managed software builder provides reliable long-term security. Evaluating the trade-offs in why people are leaving WordPress clarifies the maintenance commitments involved. Our answer would flip if WordPress core sandboxed third-party plugins so one unpatched extension could no longer expose the whole install. Until then the plugin layer stays the entry point.

• Static architectures eliminate databases and server-side scripts, neutralizing injection attacks
• Hosted software builders handle core updates and server security without manual intervention
• Staying on WordPress works when teams have internal resources to test and apply weekly patches
• Reviewing the WordPress migration service outlines steps for transitioning content to secure static hosting

Ten-Point Hacked WordPress Recovery Checklist

Following a structured checklist ensures your team contains the breach, cleans system files, and establishes security controls to prevent repeat intrusions. Complete each step in sequence to restore operational integrity.

• 1. Place the website in 503 maintenance mode to restrict public execution and search indexing
• 2. Reset hosting account, database, SFTP, SSH, and WordPress administrative passwords
• 3. Replace secret authentication keys and salts in wp-config.php to invalidate compromised sessions
• 4. Audit the database user table and delete unauthorized administrator profiles
• 5. Delete the wp-admin and wp-includes directories before uploading fresh copies from official sources
• 6. Reinstall verified versions of required plugins directly from their authorized repositories
• 7. Inspect the wp-content uploads folder to delete all non-media files bearing executable PHP extensions
• 8. Remove all dormant themes and unused plugins to shrink available attack surfaces
• 9. Review flagged links in Google Search Console and submit an itemized security review request
• 10. Configure two-factor authentication and activate a web application firewall to protect login endpoints