Automated traffic now represents a majority of the HTML traffic measured by Cloudflare in its reported dataset. For WordPress administrators, this means bot defense is no longer an optional security enhancement. Protect your website with server-validated bot challenges, rate limiting, multi-factor authentication (MFA), registration controls, timely patching, log monitoring, least-privilege access, and a tested incident-response plan.

Introduction: The New Reality of Website Administration

The modern web is increasingly shaped by automated traffic.

Cloudflare-reported data from 2026 indicates that automated requests accounted for 57.4% of the HTML traffic it measured, compared with 42.6% attributed to human activity. This figure should not be interpreted as a literal census of every human and bot on the internet. It is a measurement of traffic observed within Cloudflare’s dataset.

Nevertheless, the finding has an important practical implication for website administrators: public websites should be operated on the assumption that automated systems will continuously discover, crawl, probe, and test publicly accessible endpoints.

For WordPress administrators, this includes login pages, registration forms, password-reset endpoints, APIs, comments, WooCommerce account pages, contact forms, and other publicly accessible functionality.

Not every automated visitor is malicious. Search engines, monitoring services, accessibility tools, payment systems, research projects, and AI services may legitimately access websites. Others, however, may attempt to create fraudulent accounts, scrape content, test stolen passwords, inject spam, exploit vulnerable plugins, manipulate search results, or interfere with advertising and analytics systems.

The security question is therefore no longer simply:

“How do I stop bots?”

A better question is:

“How do I distinguish, control, and monitor automated activity without unnecessarily blocking legitimate users and services?”

What Changed in 2026?
Why Are WordPress Sites Targeted?
How Do I Detect Fake WordPress Registrations?
How Do I Detect WordPress Cloaking?
How Do I Check for Spam Injection and SEO Compromise?
How Do I Investigate Suspicious WordPress Files?
What Should I Do If My WordPress Site Is Compromised?
How Do I Stop Fake WordPress Registrations?
What Should I Monitor Each Month?
Monthly WordPress Security Health-Check Script
Frequently Asked Questions

What Changed in 2026?

The web has reached a practical turning point: automated systems now account for a substantial portion of public web requests.

In Cloudflare’s reported 2026 dataset, automated traffic represented 57.4% of measured HTML requests, while human-generated traffic represented 42.6%.

This automated activity includes several very different categories:

Automated visitor type	Typical purpose	Recommended response
Search-engine crawlers	Index pages for search results	Allow verified crawlers where appropriate
AI crawlers and agents	Retrieve, summarize, compare, or process content	Establish a documented crawl and content-access policy
Monitoring bots	Check uptime, performance, and availability	Allow known providers and monitor usage
Accessibility tools	Assist users or test accessibility	Avoid broad blocks that interfere with legitimate access
Scrapers	Extract content, pricing, or product information	Rate-limit, challenge, or block when appropriate
Credential-stuffing bots	Test stolen usernames and passwords	Use MFA, rate limiting, and login protection
Registration bots	Create fraudulent accounts	Require verification and protect registration endpoints
Vulnerability scanners	Identify exploitable software	Patch quickly and minimize unnecessary exposure
Impersonating crawlers	Pretend to be trusted bots	Verify crawler identity before allowlisting

A 2026 analysis of more than 3 billion website visits reported that AI-harvester traffic increased from 8% to 13% of measured web sessions during the preceding 12 months, representing a reported 62.5% increase. The same analysis reported AmazonBot at 4.1% of measured sessions.

These measurements should be interpreted according to the datasets and methodologies used by the organizations conducting them.

The broader operational lesson is straightforward:

Automation is now a normal condition of operating a public website.

WordPress administrators should therefore build security controls around continuous automated activity rather than treating bot traffic as an unusual event.

Why Are WordPress Sites Targeted?

WordPress remains a major target for automated attacks because of its widespread use, extensive plugin ecosystem, predictable architecture, and large number of publicly accessible installations.

Commonly exposed endpoints include:

/wp-login.php
/wp-admin/
/public_html/
/public_html/htaccess
/public_html/index.php
/public_html/wp_content
/public_html/wp_content/themes
/wp-json/
/xmlrpc.php
Public registration forms
Password-reset forms
WooCommerce account and checkout flows
Contact forms
Search endpoints
Custom REST API routes

Attackers do not necessarily need to identify a particular website manually.

Automated tools can scan large numbers of websites looking for outdated software, exposed login pages, weak credentials, vulnerable plugins, misconfigured servers, or other weaknesses.

A relatively small WordPress website can therefore receive automated attacks even when it has limited legitimate traffic.

For example, a site with public registration enabled may receive large numbers of automated account-creation attempts. If a vulnerable plugin, compromised administrator account, exposed API credential, weak hosting password, or outdated theme is also present, an apparently minor spam problem can develop into a broader security incident.

Potential consequences include:

Database growth caused by fraudulent accounts
Credential-stuffing attacks against administrators and customers
Spam comments and fraudulent form submissions
Search-engine spam pages
Japanese Keyword Hack-style foreign-language injections
Cloaking, where different visitors receive different content
Unauthorized advertising or AdSense code
Unauthorized tracking and fingerprinting scripts
Search visibility problems
Browser, hosting-provider, or security-vendor warnings
Malware distribution
Unauthorized redirects
Webshells and persistent backdoors

The important point is that a visible symptom is not necessarily the original compromise mechanism.

For example, deleting thousands of fake accounts may remove the symptom while leaving the compromised plugin, administrator account, cron job, or PHP backdoor that created them.

How Do I Detect Fake WordPress Registrations?

One of the easiest indicators of automated abuse is a mismatch between the number of WordPress accounts and the number of genuine people who should have accounts.

During a recent WordPress cleanup, I observed that this small website contained 15,389 accounts. Following an evidence-based review, 15,363 appeared fraudulent, while 26 accounts were confirmed as legitimate. This represented an estimated fake-account rate of approximately 99.83%.

Editorial note: This example is anonymized and comes from a real-world cleanup. It should not be treated as a benchmark for every WordPress website. Registration patterns vary according to the site’s audience, business model, plugins, and legitimate user activity.

Review registrations by month

A sudden increase in registrations can be one of the earliest indicators of automated account creation.

Run the following query through phpMyAdmin, Adminer, or another authorized database-management interface:

SELECT
    DATE_FORMAT(user_registered, '%Y-%m') AS registration_month,
    COUNT(*) AS registrations
FROM wp_users
GROUP BY DATE_FORMAT(user_registered, '%Y-%m')
ORDER BY registration_month DESC;

If your WordPress installation uses a custom database table prefix, replace wp_ with your actual prefix.

Investigate patterns such as:

Hundreds of registrations on a site that normally receives only a few
Accounts created within minutes or hours of one another
Registration spikes following a plugin, hosting, DNS, or security configuration change
Large numbers of accounts with no purchases, comments, profile activity, or subsequent logins

A registration spike does not automatically prove that every account is malicious. It is an investigative signal that should be combined with additional evidence.

Identify Uniform WordPress Metadata Patterns

Legitimate users often generate different amounts of WordPress user metadata as they interact with a website.

Automated accounts may have a more uniform metadata footprint because they register and perform little or no additional activity.

The following query can help identify unusual patterns:

SELECT
    u.ID,
    u.user_login,
    u.user_email,
    u.user_registered,
    COUNT(um.umeta_id) AS meta_count
FROM wp_users AS u
LEFT JOIN wp_usermeta AS um
    ON u.ID = um.user_id
GROUP BY
    u.ID,
    u.user_login,
    u.user_email,
    u.user_registered
ORDER BY
    meta_count ASC,
    u.user_registered DESC;

You can also identify clusters of accounts that share identical metadata counts:

SELECT
    meta_count,
    COUNT(*) AS user_count
FROM (
    SELECT
        u.ID,
        COUNT(um.umeta_id) AS meta_count
    FROM wp_users AS u
    LEFT JOIN wp_usermeta AS um
        ON u.ID = um.user_id
    GROUP BY u.ID
) AS user_meta_counts
GROUP BY meta_count
ORDER BY
    user_count DESC,
    meta_count ASC;

Use Multiple Signals Before Removing Accounts

A metadata count alone does not prove that an account is fraudulent.

Review several indicators together:

Unusual registration dates or registration bursts
Repetitive or randomly generated usernames
Disposable or low-reputation email domains
Lack of email verification
No login activity
No purchases on WooCommerce websites
No comments or profile activity
Shared IP addresses or network ranges
Repeated or unusual user-agent patterns
Default subscriber roles with no subsequent engagement
Similar metadata counts across large groups of accounts
Similar registration behavior

Important: Do not bulk-delete accounts before creating a verified database backup. When possible, export, quarantine, deactivate, or otherwise review suspected accounts before permanently deleting them. Premature deletion can remove legitimate customers and valuable forensic evidence.

How Do I Detect WordPress Cloaking?

Cloaking occurs when a website intentionally delivers materially different content to different visitors based on characteristics such as user-agent, IP address, cookies, referral information, or other request attributes.

Attackers may use cloaking to display normal content to website owners while showing spam pages, malicious links, or foreign-language content to search crawlers.

However, not every difference between visitors is malicious.

Legitimate causes of different content can include:

Mobile rendering
Cookie-consent systems
Geographic notices
Personalization
A/B testing
CDN behavior
Caching
Language selection
Accessibility functionality

The objective is therefore not to find any difference whatsoever.

The objective is to identify unexplained and harmful differences.

Compare Browser-Like and Crawler-Like Responses

Run these commands only against websites that you own or are authorized to test.

Browser-like response

curl -sSL \
  -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 Chrome/124 Safari/537.36" \
  "https://[YOUR-DOMAIN]/" | head -n 40

Crawler-like response

curl -sSL \
  -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  "https://[YOUR-DOMAIN]/" | head -n 40

Origin-server response, if applicable

curl -sSL \
  -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  --resolve "[YOUR-DOMAIN]:443:[YOUR-ORIGIN-IP]" \
  "https://[YOUR-DOMAIN]/" | head -n 40

How Should You Interpret the Results?

Result	Possible meaning	Recommended next step
Responses are substantially identical	No obvious cloaking in this limited test	Continue monitoring
Crawler response contains spam or unfamiliar links	Possible cloaking or injection	Preserve evidence and investigate
CDN and origin responses differ	Possible cache, CDN, server, or application issue	Review cache rules and server logs
All responses contain suspicious content	Possible broad compromise	Treat as an active security incident
Differences are limited to legitimate presentation elements	Possible intended behavior	Document and verify the reason

Important Limitation of User-Agent Testing

A Googlebot user-agent string does not prove that the request actually came from Google.

It only allows you to test whether your website changes its response based on the supplied user-agent string.

A malicious crawler can simply pretend to be Googlebot.

Before allowlisting a crawler, verify its identity using the appropriate official crawler-verification process. Do not rely solely on the user-agent string.

Check for Unusual `Vary` Headers

curl -sSI \
  -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  "https://[YOUR-DOMAIN]/" | grep -i '^vary:'

A header such as:

Vary: User-Agent

is not automatically evidence of malware.

It can be used legitimately for device-specific caching or content delivery.

It becomes more interesting when it appears together with unexplained differences in page content.

How Do I Check for Spam Injection and SEO Compromise?

Search spam and foreign-language injections can damage search visibility, create unwanted indexed URLs, and reduce trust in a domain.

One known pattern is the Japanese Keyword Hack, in which compromised websites may contain Japanese-language spam pages or search-engine content.

Japanese text alone, however, does not prove that a site has been hacked. Legitimate Japanese localization files, plugins, translations, or content can contain Japanese characters.

For example, a WordPress plugin’s JavaScript localization file may legitimately contain Japanese strings.

The important question is whether the language appears in an unexpected location or context.

Search for suspicious language markers

This is an investigative check, not a complete malware scan:

curl -sSL \
  -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  "https://[YOUR-DOMAIN]/" \
  | grep -iE 'lang="ja"|lang="zh"|charset=Shift_JIS|charset=EUC-JP|リボン|ワンピース'

Investigate the source of any unexpected result before deleting it.

Check Your Canonical URL

curl -sSL \
  -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  "https://[YOUR-DOMAIN]/" \
  | grep -i 'rel="canonical"'

Your canonical URL should normally point to the intended page on your own domain.

Investigate unexpected results such as:

An unfamiliar external domain
An unexpected subdomain
Spam-like URL paths
Foreign-language e-commerce pages
URLs unrelated to your website’s legitimate content

Review Status Codes and Redirects

curl -sSIL \
  -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  "https://[YOUR-DOMAIN]/"

Review the output for:

Unexpected 301 or 302 redirects
Redirects to unfamiliar domains
Repeated redirect chains
Unexpected 403, 500, or 503 responses
Differences between browser-like and crawler-like requests

A normal website can return HTTP/1.1 200, HTTP/2 200, or HTTP/3 200. The protocol version alone is not a security finding.

Verify Search, Analytics, and Advertising Code

Unexpected tracking, verification, analytics, or advertising code can sometimes reveal unauthorized changes.

At the same time, legitimate websites commonly contain many third-party scripts.

Therefore, the goal is to identify unexpected identifiers or scripts, not simply to search for Google-related code.

Check for Google Search Console verification tags

curl -sSL "https://[YOUR-DOMAIN]/" \
  | grep -i "google-site-verification"

Check for Google Tag Manager and Analytics

curl -sSL "https://[YOUR-DOMAIN]/" \
  | grep -iE "googletagmanager|gtag\(|google-analytics|analytics.js"

Check for your expected AdSense publisher ID

curl -sSL "https://[YOUR-DOMAIN]/" \
  | grep -i "pub-[YOUR-PUBLISHER-ID]"

If you discover an unfamiliar publisher ID, analytics ID, verification tag, external script, or domain, locate its source before deleting anything.

It may have been added through:

An active theme
A child theme
A header/footer injection plugin
A custom-code plugin
A WordPress widget
Theme settings
Database options
A must-use plugin
wp-config.php
Server-side templates
CDN transformation rules

What about Google Tag Manager?

Google Tag Manager code is not inherently malicious.

A legitimate website may intentionally install Google Tag Manager for analytics, advertising, conversion tracking, or other integrations.

However, if unexpected Tag Manager code appears after a compromise, determine who added it, when it was added, and what container or scripts it loads.

The presence of GTM alone should not be treated as proof of compromise.

Verify `ads.txt`

Check your site’s ads.txt file:

curl -sSL "https://[YOUR-DOMAIN]/ads.txt"

A typical Google AdSense entry may resemble:

google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0

Check the response headers as well:

curl -sSI "https://[YOUR-DOMAIN]/ads.txt" | head -n 10

Investigate:

Missing ads.txt
Unexpected redirects
Unfamiliar seller records
Unauthorized publisher IDs
Recently changed entries that you cannot explain

How Do I Investigate Suspicious WordPress Files?

A WordPress compromise can hide in many locations.

Potential persistence mechanisms include:

WordPress core files
Plugins
Themes
Upload directories
Database content
Administrator accounts
Cron jobs
.htaccess
.user.ini
PHP configuration
Must-use plugins
Hosting-level configuration

Do not rely on one malware signature or one security scanner.

Modern malware can be obfuscated, encrypted, time-dependent, cookie-dependent, user-agent-specific, or hidden outside the normal WordPress plugin and theme structure.

Verify WordPress Core Checksums

If WP-CLI is available:

cd "[WORDPRESS-PATH]"
wp core verify-checksums

If files fail verification:

This compares installed WordPress core files against the official checksums for the installed WordPress version.

Record the results.
Preserve a backup or forensic copy.
Compare the files with the official WordPress release.
Replace altered core files with known-clean files.
Do not overwrite wp-config.php or wp-content without an intentional recovery plan.

Check for PHP Files in the Uploads Directory

WordPress upload directories generally contain media rather than executable PHP files.

Run:

find "[WORDPRESS-PATH]/wp-content/uploads" \
  -type f \
  -iname "*.php" \
  -print

Also consider checking common alternate PHP extensions:

find "[WORDPRESS-PATH]/wp-content/uploads" \
  -type f \
  \( -iname "*.php" -o -iname "*.phtml" -o -iname "*.php5" -o -iname "*.php7" -o -iname "*.phar" \) \
  -print

Any unexpected executable file in uploads deserves investigation.

Review Recently Modified PHP Files

find "[WORDPRESS-PATH]" \
  -type f \
  -iname "*.php" \
  -mtime -30 \
  -print

This identifies files modified during the previous 30 days.

Important: A recent modification is an investigative lead, not proof of malware.

WordPress updates, plugin installations, theme changes, deployments, caching systems, and legitimate maintenance can modify many PHP files.

Search for Suspicious Function Patterns

grep -RInE \
'base64_decode|eval\(|gzinflate|str_rot13|assert\(|shell_exec|passthru|system\(|exec\(' \
"[WORDPRESS-PATH]" \
--include="*.php" \
2>/dev/null

These functions can appear in legitimate software.

For example, base64_decode() or curl_exec() is not automatically malicious.

Review:

The matching file
Surrounding code
Plugin or theme identity
File ownership
Modification date
Whether the code exists in a known-good version
Whether the code communicates with an unfamiliar external server

Review `.htaccess` Files

Find .htaccess files:

find "[WORDPRESS-PATH]" -name ".htaccess" -type f -print

To review them:

find "[WORDPRESS-PATH]" \
  -name ".htaccess" \
  -type f \
  -exec sh -c 'echo "===== $1 ====="; sed -n "1,220p" "$1"' _ {} \;

Look for:

Redirects to unfamiliar domains
User-agent-specific conditions
Unknown rewrite rules
Unexpected PHP handlers
Obfuscated content
Rules that cannot be traced to your host, CDN, WordPress configuration, or installed software

What Should I Do If My WordPress Site Is Compromised?

If you suspect that your WordPress website has been compromised, containment should come before cosmetic cleanup.

Removing a spam page or deleting suspicious accounts may remove visible symptoms without removing the underlying access mechanism.

An attacker may still have access through:

A PHP backdoor
A rogue administrator account
A stolen hosting password
A compromised SFTP/FTP account
An altered plugin
A malicious cron job
A modified .htaccess
A compromised database
A server-side configuration file

Immediate Incident-Response Checklist

1. Preserve evidence

Before making broad changes, preserve available evidence such as:

Website files
Database backups
Access logs
Error logs
Scheduled tasks
Configuration files
Suspicious files
Timestamps
Relevant security alerts

Keep forensic copies outside the publicly accessible web directory whenever possible.

2. Review privileged access

Check:

WordPress administrators
Hosting-panel users
SSH keys
SFTP accounts
FTP accounts
Database users
Domain registrar access
CDN accounts
Email accounts
Backup systems

3. Change credentials from a known-clean device

Rotate credentials for:

Hosting
WordPress
SFTP/SSH
Database
Domain registrar
CDN
Email
Backup systems

Use unique passwords and MFA wherever available.

4. Rotate WordPress salts

If WP-CLI is available:

cd "[WORDPRESS-PATH]"
wp config shuffle-salts

This invalidates existing WordPress sessions.

5. Update WordPress and dependencies

Update:

WordPress core
Active plugins
Themes
PHP
Server components

Remove software that is no longer required.

6. Remove unnecessary components

Delete:

Unused plugins
Unused themes
Abandoned plugins
Untrusted software
Pirated or nulled software

Every unnecessary component increases the potential attack surface.

7. Review administrator roles

Confirm that every administrator account is legitimate.

Investigate:

Newly created administrators
Unexpected role changes
Unknown usernames
Accounts belonging to former users
Users with unexplained elevated privileges

8. Inspect scheduled tasks

Review:

WordPress cron events
Hosting cron jobs
System cron jobs
Scheduled requests

Look for unknown commands, scripts, URLs, or recently created tasks.

9. Run reputable security scans

Consider using your hosting provider’s security scanner, Wordfence, Sucuri, or a qualified incident-response professional.

A clean scanner result is useful, but it does not by itself prove that every backdoor has been removed.

10. Rebuild when trust has been lost

If you cannot confidently determine how the attacker gained access or whether persistence remains, rebuilding from known-clean software and a trustworthy backup may be safer than repeatedly deleting individual suspicious files.

11. Review Google Search Console

Check:

Security Issues
Manual Actions
Indexed pages
Search performance
Unexpected URLs
Sitemap status

If spam was indexed, clean the site first before requesting search-engine remediation.

How Do I Stop Fake WordPress Registrations?

The most effective strategy is layered protection.

No individual CAPTCHA, plugin, firewall rule, or bot-detection system can eliminate every automated registration attempt.

1. Disable Registration If You Do Not Need It

Go to:

WordPress Dashboard → Settings → General → Membership

Then disable:

Anyone can register

If your website has no legitimate need for public accounts, membership, contributor registration, or customer profiles, disabling public registration removes an important attack surface.

2. Use Server-Validated Bot Challenges

Cloudflare Turnstile is one option for protecting forms against automated submissions.

The critical point is that the challenge must be validated server-side.

Simply displaying a challenge widget on a form is not sufficient if the submitted token is never validated by the server.

Consider protecting:

WordPress login forms
Registration forms
Password-reset forms
Comments
Contact forms
WooCommerce account creation
WooCommerce checkout
Membership forms
Learning-management-system forms
Custom forms
API endpoints

Turnstile tokens have a limited lifetime and are designed to be validated server-side. Your implementation should handle failed, expired, and already-used tokens appropriately.

3. Add Rate Limiting at the CDN or WAF Layer

Use a web application firewall, CDN, or hosting-level rate limiter where available.

Pay particular attention to:

/wp-login.php
/wp-admin/
/wp-json/
/xmlrpc.php
Registration endpoints
Password-reset requests
Contact-form handlers
WooCommerce account endpoints
High-cost search and API routes

A graduated approach can be more effective than immediately blocking large groups of users:

Allow normal behavior.
Challenge suspicious bursts.
Rate-limit repeated requests.
Block confirmed malicious patterns.

Avoid excessive blocking. Overly aggressive rules can interfere with legitimate customers, search engines, payment systems, monitoring services, accessibility tools, and other valid traffic.

4. Require Email Verification

For membership, course, WooCommerce, or community websites, consider requiring users to verify ownership of their email address before activating accounts or granting meaningful privileges.

Email verification does not eliminate automated abuse, but it increases the cost of mass registration and provides another signal for identifying suspicious accounts.

5. Protect Administrator Accounts With MFA

Enable multi-factor authentication for WordPress administrators.

Also protect:

Hosting control panels
Domain registrar accounts
Cloudflare/CDN accounts
Recovery email accounts
Git repositories
Deployment systems
Backup systems

MFA reduces the risk that a stolen password alone will result in administrative takeover.

6. Apply Least Privilege

Use individual accounts rather than shared administrator credentials.

Give each user only the permissions necessary for their role.

For example:

Authors generally should not be administrators.
Editors should not automatically receive hosting access.
Shop managers should not automatically have plugin-installation privileges.
Former staff and contractors should have their access removed.
Administrator privileges should be reviewed periodically.

7. Maintain a Minimal Plugin Stack

Every installed plugin and theme adds software to your attack surface.

Follow a simple rule:

If you do not need it, remove it.

Also:

Remove unused plugins and themes.
Avoid nulled, pirated, or unverified premium software.
Update components promptly.
Replace abandoned plugins.
Document why each active plugin exists.
Maintain independent backups.
Monitor reputable vulnerability advisories.

What Should I Monitor Each Month?

A monthly WordPress security review does not have to take hours.

A structured 30-minute review can reveal warning signs before they develop into a major security or SEO incident.

Check	What to review	Why it matters
New users	Registration volume, roles, domains, activity	Detect registration abuse
Administrator accounts	New and changed administrators	Detect privilege escalation
Login activity	Failed logins and unusual patterns	Detect credential attacks
File changes	PHP, themes, plugins, `.htaccess`	Detect unauthorized modifications
Search Console	Security issues and indexed pages	Detect SEO compromise
Page source	Scripts, analytics IDs, verification tags	Detect unauthorized code
`ads.txt`	Authorized seller records	Detect advertising tampering
Backups	Recency and restoration testing	Confirm recoverability
Plugins and themes	Updates and vulnerabilities	Reduce attack surface
Logs	404s, redirects, POST bursts, unusual requests	Identify active attacks

Monthly WordPress Security Health-Check Script

The following baseline script can help identify anomalies on websites that you own or administer.

It is an investigative tool, not a malware-certification system.

Replace the placeholder values before using it:

#!/usr/bin/env bash

set -u

DOMAIN="[YOUR-DOMAIN]"
ORIGIN_IP="[YOUR-ORIGIN-IP]"
WP_PATH="[WORDPRESS-PATH]"

echo "=========================================="
echo "WORDPRESS SECURITY HEALTH CHECK"
echo "Domain: ${DOMAIN}"
echo "Time: $(date)"
echo "=========================================="

echo
echo "--- Public response status and redirects ---"
curl -sSIL "https://${DOMAIN}/" | sed -n '1,20p'

echo
echo "--- Browser-like page preview ---"
curl -sSL \
  -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 Chrome/124 Safari/537.36" \
  "https://${DOMAIN}/" | head -n 10

echo
echo "--- Crawler-like page preview ---"
curl -sSL \
  -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  "https://${DOMAIN}/" | head -n 10

echo
echo "--- Origin test, if configured ---"
curl -sSL \
  -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  --resolve "${DOMAIN}:443:${ORIGIN_IP}" \
  "https://${DOMAIN}/" | head -n 10

echo
echo "--- Vary headers ---"
curl -sSI "https://${DOMAIN}/" \
  | grep -i '^vary:' || true

echo
echo "--- Canonical URL ---"
curl -sSL "https://${DOMAIN}/" \
  | grep -i 'rel="canonical"' || true

echo
echo "--- Search Console verification tag ---"
curl -sSL "https://${DOMAIN}/" \
  | grep -i "google-site-verification" || true

echo
echo "--- Analytics and Tag Manager indicators ---"
curl -sSL "https://${DOMAIN}/" \
  | grep -iE "googletagmanager|gtag\(|google-analytics|analytics.js" || true

echo
echo "--- ads.txt ---"
curl -sSL "https://${DOMAIN}/ads.txt" || true

echo
echo "--- WordPress core checksum verification ---"
if command -v wp >/dev/null 2>&1; then
    wp --path="${WP_PATH}" core verify-checksums || true
else
    echo "WP-CLI is not installed or is unavailable in PATH."
fi

echo
echo "--- PHP files in uploads directory ---"
find "${WP_PATH}/wp-content/uploads" \
  -type f \
  -iname "*.php" \
  -print 2>/dev/null || true

echo
echo "--- Recently modified PHP files: last 30 days ---"
find "${WP_PATH}" \
  -type f \
  -iname "*.php" \
  -mtime -30 \
  -print 2>/dev/null || true

echo
echo "=========================================="
echo "END OF HEALTH CHECK"
echo "=========================================="

Frequently Asked Questions

Are bots really more common than humans online?

In Cloudflare’s reported 2026 measurement of selected HTML traffic on its network, automated requests accounted for 57.4%, compared with 42.6% attributed to human activity.

This is an important operational signal for website administrators, but it should not be interpreted as a literal count of every human and bot on the internet.

Is every bot visiting my website malicious?

No.

Search engines, uptime monitors, accessibility services, payment systems, analytics platforms, research tools, and some AI systems use legitimate automation.

The objective should be to identify, verify, control, and monitor automated activity, rather than attempting to block every bot.

Does Cloudflare Turnstile stop all WordPress bots?

No.

No individual bot-control system is perfect.

Turnstile can provide an important layer of protection when implemented correctly, including server-side validation of the submitted token.

For stronger protection, combine bot challenges with:

Rate limiting
Email verification
MFA
Software updates
Least privilege
Login protection
Logging
Account reviews
Tested backups

How can I tell whether WordPress registrations are fake?

Look for multiple signals rather than relying on one indicator.

Useful signals include:

Abnormal registration spikes
Disposable email domains
Repetitive usernames
Uniform metadata counts
No login activity
No orders
Shared IP ranges
Repeated user agents
Similar account behavior

Review and quarantine suspicious accounts before permanently deleting them whenever practical.

What is the fastest way to make WordPress safer?

Start with the fundamentals:

Disable unnecessary public registration.
Update WordPress core, plugins, themes, and PHP.
Enable MFA for administrators.
Protect public forms with server-validated bot controls.
Rate-limit login and registration endpoints.
Review administrator accounts.
Remove unused plugins and themes.
Maintain tested, off-server backups.
Monitor file changes and logs.
Investigate suspicious activity rather than simply deleting its visible symptoms.

Should I block AI crawlers from my website?

That depends on your objectives, licensing preferences, content strategy, infrastructure capacity, and business model.

Before blocking a crawler, identify it accurately and understand what it does.

Develop a documented crawler-access policy rather than automatically blocking all automated systems.

Be particularly careful not to block legitimate search-engine crawlers accidentally, because doing so can affect search visibility.

Final Thoughts: Treat WordPress Security as Continuous Administration

The most important change for WordPress administrators is a change in mindset.

Your website is not exposed only when someone manually visits it.

It is continuously being discovered, crawled, scanned, tested, and sometimes attacked by automated systems.

That does not mean every automated request is dangerous. It means that automation should be treated as part of the normal security environment of every public website.

A resilient WordPress security strategy therefore combines:

Strong authentication
MFA
Least-privilege access
Timely software updates
Minimal plugins and themes
Server-side bot validation
Rate limiting
Registration controls
File-integrity monitoring
Log analysis
Search Console monitoring
Tested backups
Incident-response procedures

Most importantly, when something suspicious happens, investigate the underlying access mechanism, not merely the visible symptom.

A deleted spam account can return.

A restored index.php can be modified again.

A removed malicious script can be recreated by a hidden backdoor.

Security is therefore not a one-time cleanup task. It is an ongoing process of prevention, detection, response, recovery, and verification.

About the Author and Editorial Review

Dr. Clement C Aladi is a cybersecurity and information-systems professional specializing in web application security, information systems, technology, and digital infrastructure.

Eduinfomark

Education, Reflection, Scholarship

Donate to Feed or Gift A Child On my Birthday
10.00USD