WordPress diagnostics
Google Search Console Security Issues – what do the warnings mean?
Google Search Console Security Issues – what do the warnings mean?
The Google Search Console Security Issues report is not a routine SEO checklist. A finding means Google believes the site may be hacked, may serve harmful code, or may deceive visitors. The few URLs shown in the report are examples, not the complete repair scope.
Deleting only the listed page and immediately requesting a review is a common mistake. Search Console shows where Google observed a symptom. You still need to find the entry point, persistence and every other affected component.
The three main issue groups
Hacked content
This includes code injection, attacker-created pages and altered content. Common WordPress cases include pharmaceutical, gambling and adult-content SEO spam. The normal visitor may see the original page while Googlebot receives spam.
If unknown URLs are appearing in search, use the detailed guide to stopping Google from indexing hacked spam pages.
Malware and unwanted software
The site may directly serve a malicious download, execute injected JavaScript, or load a compromised third-party resource. The malicious file does not have to live in a plugin. It can appear in uploads, cache, a temporary directory or server configuration.
Social engineering
The site impersonates a trusted service and asks for a password, payment details, a software download or a phone call. On compromised WordPress installations, attackers often create a self-contained phishing directory while leaving the homepage untouched.
What does a sample URL tell you?
Google states that its affected URL list may not be complete. One example can mean that the payload is stored on that page, loaded by a shared theme file, activated through a conditional redirect, or generated by a backdoor elsewhere. A third-party script may also have changed since Google's crawl.
Preserve the examples, but investigate beyond them. Correlate nearby file changes with access logs and identify which request happened before a suspicious file appeared.
A practical WordPress investigation
Record the exact finding, detection time and example URLs. Capture file and database backups before making changes. Then inspect:
Unknown or recently created administrators
New plugins, disabled-looking plugins and themes
wp-content/mu-plugins and drop-in files
PHP files under uploads
autoloaded wp_options values
Injected scripts in wp_posts and wp_postmeta
WordPress cron events
.htaccess and web server configuration
Searches for obfuscation and dynamic execution are useful, but they do not produce an automatic verdict:
rg -n "base64_decode|gzinflate|eval\(|shell_exec|assert\(" public_html
find public_html -type f -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %p\n'
Legitimate software may contain some of these patterns, malware can avoid them, and timestamps can be forged. Our guide to confirming whether a WordPress site has malware provides broader indicators.
Why can the report and browser warning disagree?
Safe Browsing, Search Console and Chrome do not always update simultaneously. An algorithmic finding might trigger a warning without a manually reviewable Search Console item. Check the Safe Browsing Transparency Report, Search Console messages, Manual Actions and the affected URLs.
The opposite can happen too: you no longer reproduce the payload, but the report remains active. That does not make the warning false. Conditional malware may simply be hiding from your current request.
Clean the incident, not the report
Example: injection through a plugin endpoint
Suppose the report lists one strange URL while the site appears normal. Access logs show several POST requests to a plugin AJAX endpoint before Google first crawled that URL. In the same minute, a PHP file appeared under uploads and a scheduled event was created. The visitor-facing script was added to header.php later.
Cleaning header.php and deleting the example URL would miss the loader, cron event, vulnerable endpoint and potentially an attacker account. File-change and request chronology provides the causal path.
Investigating cloaking
Hacked content may target Googlebot, mobile devices or search referrals. Fetch the same URL with different headers and compare status codes, redirect chains and external resources:
curl -sSIL https://example.com/suspect-url
curl -sSIL -A 'Googlebot' https://example.com/suspect-url
curl -sSIL -e 'https://www.google.com/' https://example.com/suspect-url
CDNs, localisation and A/B tests can also produce differences. A variation becomes an indicator when it cannot be explained by intended behaviour or leads to a harmful destination.
Manual Actions and Security Issues are different
Manual Actions concern search-spam policy violations. Security Issues concern hacking, malware and deceptive behaviour. A compromised site can receive both, with different repair and review flows. Search Console's removal tool does not clean a compromise either. It may temporarily hide URLs, while the backdoor continues generating them.
Missing logs limit conclusions
Some hosting plans retain only a few days of access logs. Without evidence, you cannot confidently identify the entry point or claim that data was not accessed. Use file comparisons, database timestamps and logs from adjacent systems, but document uncertainty.
Increase retention and forward logs to external storage. An attacker with sufficient permissions may alter local logs too.
Verify at more than one moment
One clean scan is weak evidence against malware that activates hourly or daily. Recheck immediately after cleanup, after scheduled jobs run, during normal traffic and after at least a full day. Monitor files, administrators, outbound connections and new Search Console examples.
Two-hour incremental backups also provide forensic value: they narrow the window in which a change occurred without forcing a full-day rollback.
Compare core files with official packages, verify plugins and themes against clean sources, inspect custom components, and locate every persistence mechanism. Rotate credentials, replace security salts, patch or remove the vulnerable component, and test the site again from several contexts.
A hosting-provider file list is also only a starting point. The article about hosting malware warnings explains why scanner output is rarely a complete incident report.
Evidence for the review request
Keep a concise record of:
- the infection type and affected locations;
- removed files, records and accounts;
- the patched vulnerability or compromised credential;
- password and salt rotation;
- post-cleanup verification;
- controls added to prevent recurrence.
Google's official Security Issues documentation says reviews can take from several days to several weeks depending on the category. Repeated vague submissions do not make that process faster.
WebShield approaches this as incident response rather than a scan. It correlates HTTP requests with file changes, watches new administrators and components, and continues monitoring after cleanup. That is how you close the compromise instead of merely trying to clear a report entry.