If your WordPress site is redirecting visitors to spam pages, Google has flagged it for malware, or your hosting provider suspended your account, you are likely dealing with a compromised site. WordPress powers 43% of the web, which makes it the most targeted CMS by a wide margin. This guide covers how to confirm whether your site has been hacked, what to do in the first hour, and how to verify it is clean before bringing it back online.

Signs Your WordPress Site Has Been Hacked

Attackers rarely announce themselves. Most compromises are designed to go unnoticed for as long as possible — the goal is to use your site's reputation and traffic for spam, phishing, or cryptomining, not to take it offline. Watch for these indicators:

Unexpected Redirects

Visitors — especially those arriving from Google search — are redirected to spam sites, fake pharmacy pages, or phishing landing pages. The redirect often only fires on first visit or for users coming from search engines, which is why you may not see it when you visit your own site directly. Test by opening your site in an incognito window after arriving via a Google search result.

Google Search Console Malware Warning

Google Search Console sends an email alert and flags your site under Security Issues when its crawler detects malware, phishing content, or harmful downloads. This is one of the most reliable early indicators. Check Search Console even if your site appears normal — Google often detects injected content before the site owner does.

New Admin Users You Did Not Create

Go to wp-admin → Users and look for administrator accounts you do not recognize. Attackers commonly create a backdoor admin account after gaining initial access, giving themselves persistent access even if you change your password. A new admin user with a random email address is a near-certain sign of compromise.

Modified Core Files

WordPress core files — particularly wp-login.php, index.php, and files in wp-includes/ — should never change between updates. Attackers inject malicious code into these files. Check file modification dates with: find /path/to/wordpress -name "*.php" -newer /path/to/wordpress/wp-config.php -not -path "*/wp-content/*". Any recently modified core PHP file that was not changed by a legitimate update is suspicious.

Spam Pages Appearing in Google Search

Search Google for site:yourdomain.com. If you see pages about pharmaceuticals, counterfeit goods, or gibberish keyword-stuffed content that you did not create, attackers have created hidden spam pages on your site. This technique — called SEO spam or Japanese keyword hack — exploits your site's domain authority to rank their spam content.

Visitors Getting Antivirus Alerts

If users report that their antivirus software is blocking your site, or browsers are showing a red interstitial warning, your site is serving malicious content. Chrome's Safe Browsing database and antivirus vendors flag sites in near real-time once malicious content is detected.

How to Verify the Compromise

Check Google Search Console

Log in to Google Search Console for your domain. Navigate to Security & Manual Actions → Security Issues. Google will list specific URLs containing malware or phishing content if it has detected a compromise. This is your most authoritative source — Google's crawlers have already indexed the malicious content.

Run Sucuri SiteCheck

Go to sitecheck.sucuri.net and enter your domain. Sucuri scans your site's publicly accessible content against known malware signatures and blacklists. It checks the Google Safe Browsing list, McAfee SiteAdvisor, and several other threat databases. A clean result here does not guarantee a clean server — server-side malware that is not rendered in the public HTML will not be detected — but a positive detection confirms compromise.

View Page Source for Hidden Iframes and Scripts

Right-click any page on your site and choose View Page Source (not Inspect — the browser developer tools render the DOM, which can hide injected content). Search the raw HTML for <iframe tags you do not recognize, <script src= pointing to unfamiliar domains, and base64-encoded strings (look for eval(base64_decode or long strings of characters matching [A-Za-z0-9+/=]{100,}). Malicious injections are often appended at the very end of the HTML, just before the closing </body> tag.

Review Access Logs for Unusual POST Requests

Your hosting provider's access logs record every request to your server. Filter for POST requests to unexpected paths: grep "POST" access.log | grep -v "wp-admin|wp-login|wp-cron|xmlrpc" | grep ".php". Repeated POST requests to obscure PHP files in wp-content/uploads/, randomized filenames, or files that should never accept POST requests are strong indicators of a webshell — a backdoor script the attacker is using to execute commands on your server.

Check File Modification Dates

Run find /path/to/wordpress -name "*.php" -mtime -30 to list all PHP files modified in the last 30 days. Any PHP files in wp-content/uploads/ are immediately suspicious — this directory is for media uploads and should not contain PHP files at all. PHP files in wp-content/themes/ or wp-content/plugins/ that were not updated recently warrant review.

How Shieldome Checks This

Shieldome scans the running, publicly accessible version of your WordPress site and checks for the compromise indicators that are visible from the outside — which is what attackers and Google both see. In a typical scan against a WordPress site, Shieldome performs over 40 individual checks, including:

Run a Shieldome scan before restoring from backup to document the attack surface and understand how the attacker likely got in. Run another scan after restoring to verify that security headers are in place, sensitive files are not exposed, and the hardened configuration is actually being served.

Immediate Response Steps

1. Take the Site Offline

Put your site in maintenance mode or temporarily block public access through your hosting provider or CDN. A compromised site actively harms your visitors and accelerates damage to your search rankings. Taking it offline stops both.

2. Restore from a Clean Backup

Identify the most recent backup that predates the compromise. Compare file modification timestamps between the backup and your current files to confirm the backup is clean. Restore WordPress core files from the official WordPress.org download rather than from backup — this guarantees they match the published checksums.

3. Change All Passwords and Keys

Immediately change: WordPress admin passwords for all users, database password (and update wp-config.php), FTP/SFTP credentials, hosting control panel password, and WordPress security keys in wp-config.php (generate new ones at api.wordpress.org/secret-key/1.1/salt/). Invalidate all active sessions.

4. Update Everything

Update WordPress core, all plugins, and all themes to their current versions. The majority of WordPress compromises exploit vulnerabilities in outdated plugins. Delete any plugins or themes you are not actively using — inactive plugins are still exploitable.

5. Scan and Verify

After restoring, use a server-side scanner (Wordfence or Maldet) to verify no malicious files remain on the server. Then run an external scan to confirm the publicly accessible site is clean. Run a Shieldome scan to verify security headers, no exposed sensitive files, and no version disclosure — the indicators that made the initial compromise easier.

FAQ

How did my WordPress site get hacked?

The most common entry points are: outdated plugins with known vulnerabilities (accounts for over 55% of WordPress compromises), weak or reused admin passwords, compromised shared hosting accounts where another site on the same server was exploited first, nulled (pirated) themes and plugins that contain backdoors by design, and brute-force attacks on wp-admin and xmlrpc.php.

Can I clean a hacked WordPress site myself or do I need a professional?

For straightforward compromises with a clean backup available, self-remediation is feasible if you are comfortable with FTP/SFTP access, command line, and database operations. For sites without a clean backup, sites with unknown compromise dates, or sites where you find webshells and do not know the initial access vector, professional remediation (Sucuri, Wordfence, or a specialized agency) reduces the risk of incomplete cleanup and reinfection.

My site was cleaned but got hacked again. Why?

Reinfection almost always means the initial access vector was not closed. Common causes: the backdoor webshell was not found and removed (attackers often plant multiple), the vulnerability that allowed initial access (an outdated plugin) was not patched, or attacker-created admin users were not deleted. After reinfection, treat the entire server as compromised and restore from a verified-clean backup taken before the initial compromise.

Will Google unblacklist my site after I clean it?

Yes, but you must request a review. In Google Search Console, navigate to Security Issues, confirm you have fixed all listed issues, and click "Request a Review." Google typically responds within 1-3 days for sites with no prior history of malware. Sites with repeated violations take longer. Bing Webmaster Tools has a similar review process. Third-party blacklists (McAfee, Norton, etc.) typically clear automatically within a few days once Google's Safe Browsing status is clean.

Should I use a security plugin after cleaning my site?

Yes. Wordfence (free tier) and Sucuri Security (free tier) both provide file integrity monitoring, login protection, and firewall rules for WordPress. Wordfence's free tier includes a malware scanner with daily scans and real-time firewall rules (with a 30-day delay on new rules for free users). Either is significantly better than no protection. Combine a security plugin with a web application firewall (WAF) at the CDN or hosting level — Cloudflare's free tier includes basic WAF rules for WordPress.

Is xmlrpc.php dangerous and should I disable it?

Yes, unless you specifically use it. xmlrpc.php enables remote procedure calls to WordPress — it is required by some mobile apps and the Jetpack plugin, but is otherwise unnecessary. Attackers use it for brute-force login attempts (the system.multicall method allows testing hundreds of passwords in a single request, bypassing per-request rate limits) and as an amplification vector for DDoS. Disable it with a server configuration rule or the Disable XML-RPC plugin unless you have a specific need for it.

How do I prevent my WordPress site from being hacked in the future?

Apply the baseline: auto-update WordPress core and plugins, use unique strong passwords with a password manager, enable two-factor authentication on all admin accounts, delete unused plugins and themes, use a web application firewall, disable xmlrpc.php, restrict wp-admin access by IP if your admin team uses static IPs, and run regular external scans to verify your security configuration is actually in place. Security is a practice, not a one-time configuration.

After cleaning your WordPress site, verify that your security configuration is actually serving correctly — not just configured in files. Run a free Shieldome scan to confirm security headers, check for exposed sensitive files, and get a baseline for ongoing monitoring.