It built that profile in seconds. You almost certainly did not.

Most WordPress security writing is from the defender’s point of view. Install this plugin. Update that one. Run weekly scans. The advice is fine, but it sits at the wrong altitude. The defender’s job is shaped by what attackers do, not the other way around, and almost no site owner has ever seen a real attacker workflow up close.

This is what one looks like in 2026.

The Volume Problem That Makes the Workflow Possible

Three numbers shape everything that follows.

Bots are now 51% of all internet traffic. Imperva’s 2025 Bad Bot Report marked the year automated traffic crossed the line from minority to majority of all web requests. WordPress, running 40% of public sites, is the largest single target surface online.

The median time from public vulnerability disclosure to first real-world exploitation is five hours. That number comes from Patchstack’s State of WordPress Security in 2026. Twenty percent of heavily exploited vulnerabilities are weaponized within six hours, 45% within 24 hours, and 70% within a week.

46% of newly disclosed vulnerabilities have no patch available at the moment of disclosure. Of 333 vulnerabilities Patchstack tracked in a single week of January 2026, 236 were public with no fix in place.

When you combine those three numbers, the result is not a random sequence of attacks. It is a five-stage industrial workflow operating at internet scale, and every WordPress site on the public internet is being run through it continuously.

Stage 1: Fingerprinting

The first thing an attacker’s scanner needs to confirm is that the target is actually WordPress. This is the cheapest stage in the workflow, and it almost never fails.

The simplest signal is the generator meta tag. WordPress emits <meta name="generator" content="WordPress 6.6.2"> by default in the head of every page. Most site owners never remove it, and many security plugins do not touch it. A scanner reads it once, stores the version number, and moves on.

If the meta tag has been stripped, the scanner reads asset URLs. Stylesheets and scripts in WordPress are versioned with query strings: style.css?ver=6.6.2. Themes and plugins inherit the WordPress version unless explicitly overridden. The version leaks anyway, just from a different file.

If those are stripped too, the scanner falls back to behavioral fingerprinting. It probes specific endpoints that exist only on WordPress installations: /wp-json/, /xmlrpc.php, /wp-content/, /wp-includes/wlwmanifest.xml. Any one of them returning a non-404 status confirms the platform.

The version number is what unlocks Stage 2. WordPress core is rarely the actual target — only 6 vulnerabilities affected core in all of 2025 according to Patchstack — but the version gates which plugin attack chains are likely to work.

Stage 2: Enumeration

Once the platform and version are known, the scanner enumerates installed plugins. This is where the real attack surface lives. 91% of all WordPress vulnerabilities in 2025 were in plugins. Themes accounted for 9%. Core accounted for 0.05%.

The enumeration techniques are not subtle:

Asset URL parsing. Every plugin that loads a CSS or JS file announces itself in the page source via a URL containing /wp-content/plugins/<plugin-slug>/. A scanner pulling the homepage HTML extracts every plugin slug present from a single response.

Readme probing. Most plugins ship with a readme.txt at /wp-content/plugins/<slug>/readme.txt. The file is publicly readable, declares the exact plugin version, and is rarely blocked at the server level. Scanners hit the top 200 plugin readme paths against any new target and harvest version numbers in bulk.

Directory listing exposure. If /wp-content/plugins/ returns a directory index instead of a 403 or empty response, the scanner gets the entire installed plugin list in one request. Server misconfiguration around directory browsing is one of the most consistent reconnaissance gifts a site can give.

REST API user enumeration. WordPress 4.7+ exposes user data at /wp-json/wp/v2/users/. Unless the endpoint is restricted, it returns usernames for every author on the site. Author URL enumeration via /?author=N is the older fallback, walking through numerical user IDs to extract usernames the same way.

By the end of Stage 2, the scanner has the WordPress version, every installed plugin and theme with version numbers, and a list of valid usernames. The full reconnaissance package is built from a handful of HTTP requests, all of which return public information by default.

Stage 3: Vulnerability Matching

The harvested plugin list now gets cross-referenced against vulnerability databases like the Patchstack vulnerability database and WPScan. This step is automated. The scanner is not reading CVE descriptions in real time. It is running a join against a local mirror of the database and getting hits instantly.

What it is looking for:

Exploitable vulnerabilities in installed plugin versions. This is the bullseye. If the site runs a plugin with a known unauthenticated SQL injection, RCE, or privilege escalation, the scanner queues it for Stage 5.

Recently disclosed but unpatched vulnerabilities. The five-hour exploitation window is here. The 2025 King Addons for Elementor flaw (CVE-2025–8489) granted unauthenticated users administrator privileges by specifying the role during registration. Active targeting began as early as October 31, 2025, with mass exploitation kicking off November 9. Wordfence blocked over 48,400 exploit attempts targeting that single vulnerability.

Newly trending campaigns. When a critical vulnerability gets weaponized, scanners pivot. The October 2025 GutenKit and Hunk Companion campaign generated 9 million exploit attempts in two weeks across the Wordfence network, hitting any site that responded to the scanner — even sites without the plugin installed. The two plugins together account for roughly 48,000 active installs, and those are the sites that actually had to survive the campaign. Service Finder Bookings (CVE-2025–5947, CVSS 9.8) saw 13,800 exploit attempts after disclosure. The Relevanssi SQL injection campaign drew 16,500 unique attacking IPs, with 79% of hits landing on small sites with limited monitoring.

Stage 3 is the moment the attack moves from theoretical to actionable. Either the site has a vulnerability the scanner can exploit, or it goes back into the queue for the next time something new gets disclosed.

Stage 4: Configuration Probing

Even when no exploitable plugin vulnerability exists, the scanner does not give up. It probes configuration weaknesses that are exploitable on their own.

Login surface mapping. /wp-login.php and /wp-admin/ are the obvious targets. Brute force runs at industrial scale: Wordfence alone blocks 6.4 billion brute force attempts every month, and security analyses across multiple providers attribute the overwhelming majority of WordPress login traffic to automated bots rather than human attempts.

XML-RPC abuse. If /xmlrpc.php returns a 200, the scanner switches to XML-RPC's system.multicall method, which bundles hundreds of credential guesses into a single request. Most security plugins watch wp-login.php and miss the XML-RPC vector entirely. One real-world example documented in Marcin Dudek's analysis saw 288,493 XML-RPC requests from a single IP in 24 hours, only detected because the unusual cache miss rate triggered an investigation.

Security header gaps. The scanner reads HTTP response headers and checks for missing controls. Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy. A 2025 scan of 68,000 WordPress sites by ServerAvatar found 62.77% of sites had no Content Security Policy header at all, and only 15.3% passed a basic security configuration check. Missing headers do not get a site hacked on their own, but they enable XSS, clickjacking, session token leakage, and downgrade attacks once any other foothold exists.

SSL configuration analysis. The scanner pulls the certificate, validates the chain, checks expiration and TLS version support. Misconfigured chains that work in Chrome but break on iOS Safari, certificates set to expire in days, servers still accepting TLS 1.0 connections — these are catalogued as either active opportunities or signs of broader configuration neglect.

WordPress-specific exposure. Directory browsing on /wp-content/uploads/, debug mode left enabled, the WP-Cron HTTP endpoint reachable externally, the readme.html file accessible at the root.

This is the stage where the attacker stops needing a vulnerability and starts harvesting from misconfiguration alone.

Stage 5: Exploitation or Harvesting

If Stage 3 or Stage 4 returned anything actionable, exploitation runs immediately. Patchstack’s data shows the weighted median is five hours from disclosure to first exploit, but for sites already sitting in the scanner’s queue with the right plugin installed, the time is closer to seconds.

What “exploitation” actually means depends on the vulnerability class. Authenticated SQL injection or unauthenticated privilege escalation typically chains into administrator account creation — the King Addons flaw worked exactly this way, with the attacker specifying role=administrator during a registration call the plugin failed to validate. Once the attacker holds admin, the next moves are mechanical: upload a PHP webshell disguised as a legitimate plugin file, drop a backdoor user with an innocuous name like wp-support or siteadmin, and quietly change the admin email so future password resets route to the attacker instead of the owner.

Persistence is the part most site owners underestimate. The original entry point closes when the plugin patch lands, but by then the attacker has typically planted three to five backdoors across the install: a must-use plugin that survives plugin deletion, a scheduled cron job that re-creates the rogue admin user if it gets removed, an injected rule in .htaccess that redirects high-value pages to attacker infrastructure, and modified theme files loading attacker-controlled JavaScript. Cleaning a compromised WordPress site is hard precisely because patching the original CVE does not touch any of these. Sucuri's incident data consistently shows that injected malware and redirects account for roughly 70% of post-compromise infections — the residue, not the entry point.

If nothing was immediately exploitable, the site enters the long-tail surveillance pool. The reconnaissance package — version, plugins, users, configuration profile — gets stored. The next time a relevant vulnerability is disclosed for any plugin already on the target’s installed list, the site jumps to the front of the queue. This is why “I patched as soon as I heard about it” is no longer a defensible response time. By the time most site owners hear about a vulnerability, the disclosure-to-exploit window has already closed for the majority of impacted sites — and a fresh disclosure relevant to your existing plugin stack is the moment you stop being theoretical and start being a target.

The Defensive Asymmetry

Patchstack reports that standard host defenses block only 26% of attacks, and traditional WAFs block just 12% of WordPress-specific vulnerability attempts. That gap is not because the products are bad. It is because the attacker workflow is shaped by what the defender cannot see.

The defender sees their dashboard. The attacker sees the rendered HTML, the response headers, the asset URLs, the readme files, the REST API responses, the XML-RPC endpoint, the certificate chain — everything the defender’s plugin dashboard does not show.

Closing that gap means seeing the site the way the scanner sees it. That is mostly a matter of routine: read your own headers, fingerprint your own plugins, validate your own SSL, watch your own login surface for anomalies, and do all of this on a cadence that matches the disclosure cycle.

The free Royal Plugins security tool suite covers the external scanner side of this routine. The WordPress Security Scanner runs the Stage 1 and Stage 4 fingerprinting and configuration probes. The Plugin Security Scanner cross-references installed plugins against the same vulnerability databases attackers query. The HTTP Headers Checker grades the gaps any scanner would catalogue. The SSL Certificate Checker tests the certificate chain across the conditions where misconfigurations actually break. They are the same lens, pointed at your own site.

What I’d Actually Do This Week

Open your homepage in a private browser window. View source. Search for meta name="generator" and wp-content/plugins/. Whatever you find, an attacker found ten minutes ago.

Run an external scan against your own domain. Note every plugin a stranger could enumerate from the public HTML. Cross-reference each one against a vulnerability database; assume any plugin not updated in 90 days is a candidate for the next disclosure cycle.

Read your own response headers. If Content-Security-Policy is missing, you are in the 62.77% of WordPress sites that handed an attacker the easiest path forward.

Check your SSL configuration today and put a calendar reminder for 30 days before expiration, regardless of whether auto-renewal is “set up.” Manual renewal failures are still the leading cause of certificate outages.

Pick a cadence. Doing all of the above once is theater; doing it weekly is reactive. The five-hour exploitation window means even weekly is too slow for actively-exploited plugin vulnerabilities. GuardPress runs the plugin vulnerability monitoring, login lockdown across both wp-login.php and XML-RPC, security header enforcement, and file integrity checks on a continuous schedule — same lens as the free tools, but matched to how fast the disclosure cycle actually moves.

The point is not to do any of these once. The point is to know what you look like to the workflow that is already running against you, and to close the gap fast enough that by the time the next mass exploitation campaign drops, your site is not in the queue.

The attacker is not waiting for you to make a mistake. The attacker is reading the mistake your site is making right now.

Your WordPress Site Is Being Scanned Right Now. Here’s the Five-Step Workflow was originally published in MeetCyber on Medium, where people are continuing the conversation by highlighting and responding to this story.

Not dying. Dead.

In 2026, more than 40% of informational searches never reach a traditional search results page. Users ask ChatGPT. They ask Perplexity. They get an answer synthesized from multiple sources, served in a clean paragraph with maybe a citation or two — and they never click through to your site. Google’s own AI Overviews now appear on the majority of informational queries, pulling content from pages and presenting it directly in the SERP.

The question is no longer “do I rank on page one?” The question is: does the AI cite me when it answers?

That’s a fundamentally different optimization problem, and almost nobody is solving it correctly.

The Blind Spot in Every SEO Tool

I’ve spent the last year watching the SEO industry scramble to adapt. The big platforms have started adding AI visibility features — a mention tracker here, an AI overview tab there. But these are bolt-ons — afterthoughts welded onto tools that were built for a search paradigm that’s being replaced in real time.

The core issue is that traditional SEO tools measure the wrong things for AI search. They’ll tell you your page has a 95/100 technical SEO score, and that’s great — for Google’s crawler. But ChatGPT doesn’t care about your canonical tags. Perplexity doesn’t rank pages by Domain Authority. Claude doesn’t check your sitemap.

AI engines care about something different: how well your content answers the question, how much evidence you provide, and whether you look like a trustworthy source worth citing.

That’s not traditional SEO. That’s Generative Engine Optimization — GEO.

What GEO Actually Measures

GEO as a concept comes from peer-reviewed research out of Princeton and IIT Delhi, published at ACM KDD 2024. The headline finding: applying GEO methods — adding citations, quotations from relevant sources, and statistics — boosted source visibility in generative engine responses by up to 40%.

The most effective individual strategy? Adding direct quotations from authoritative sources, which improved visibility by roughly 43% over baseline. Statistics addition came in around 32%. These aren’t vague best practices — they’re measured against a benchmark of thousands of real queries across multiple domains.

What the research also showed is that effectiveness varies by domain. The strategies that work for health content aren’t identical to what works for finance or technology. One-size-fits-all GEO advice is almost as useless as ignoring it entirely.

The problem was that nobody had turned this research into an actionable scoring system. You couldn’t look at a page and know: is this optimized for AI citation, or am I invisible to the models?

That’s the gap that SEObolt’s GEO Score fills. It runs 30 checks across six categories and gives you a 0–100 score with specific, prioritized fixes. Not “improve your content” — more like “add inline citations to sections 2 and 4, your evidence density is below threshold.”

What AI Engines Actually Look For

GEO scoring evaluates six categories, but two stand out as the biggest gaps between traditional SEO and AI readiness:

Evidence density is everything. This is the single biggest differentiator. Pages with statistics, named sources, inline citations, and concrete examples get cited dramatically more than pages with generic advice. An AI engine constructing an answer will pull from the source that provides verifiable data points, not the one that says “many experts agree.” Most content marketers have been trained to write in broad strokes — “experts recommend,” “studies show,” “it’s widely accepted.” That style is invisible to AI citation engines. They want the specific number, the named researcher, the linked source.

Freshness is a quiet killer. AI models prefer current information, and they’re surprisingly good at detecting staleness. A guide that references “2024 best practices” when it’s 2026 signals outdated content, and the model will reach for something more recent. This matters because most evergreen content strategies are built around writing once and ranking forever. In AI search, content that isn’t actively maintained gets silently dropped from the citation pool.

The other four categories — content structure, technical accessibility (schema markup), authority signals, and writing quality — matter too, but they’re more intuitive. If you’re already doing solid SEO, you’re probably covering most of them. Evidence and freshness are where the gap lives.

The Triple Threat: Why One Score Isn’t Enough

Here’s what I think most people miss — optimizing for AI search doesn’t mean abandoning traditional SEO. Google still sends the majority of referral traffic. Local search still drives foot traffic. The winning strategy isn’t picking one; it’s covering all three.

That’s the thinking behind what SEObolt calls the triple scoring model:

1. SEO Score — Your traditional on-page optimization across 57 factors. Meta tags, headings, image alt text, internal linking, readability. This is table stakes in 2026, not a differentiator.
2. GEO Score — Your AI citation readiness across those 30 research-backed factors. This is where the competitive gap lives right now, because almost nobody is optimizing for it yet.
3. Local Score — Your maps and local pack visibility through NAP consistency and LocalBusiness schema. Critical if you have a physical presence.

Most tools give you one of these. The problem is that a page can score 95 on traditional SEO and 30 on GEO — which means you’re perfectly optimized for a search paradigm that’s shrinking while invisible to the one that’s growing.

Scoring Is Half the Picture — Tracking Is the Other Half

Optimizing for AI citation is step one. But how do you know if it’s working?

You can’t check this the way you check Google rankings. There’s no “position 3 for this keyword” in ChatGPT. The answer changes every time someone asks, and different models cite different sources for the same question. You need something that monitors whether ChatGPT, Claude, Perplexity, Gemini, and DeepSeek are actually mentioning your brand — across dozens of industry queries, tracked over time.

That’s the feedback loop that makes GEO optimization actionable instead of theoretical. Optimize your content based on the scoring factors, then watch whether your AI citations actually increase. Without that tracking layer, you’re optimizing blind.

SEObolt pairs its GEO Score with LLM Rankings that do exactly this — share of voice, mention frequency, sentiment, competitor benchmarking across all five major AI platforms. It’s the only setup I’ve seen that connects the “how to optimize” with the “is it working.”

The Race Nobody Knows They’re Running

Right now, GEO optimization is where traditional SEO was in 2010. The people who figure it out early will dominate AI citations for their industry while their competitors are still arguing about keyword density and backlink profiles.

The research is clear. The scoring factors are known. The tools exist. The only question is whether you optimize for where search is going, or keep optimizing for where it was.

Here’s what I’d actually do this week: take your top five performing pages — the ones that already rank well in Google — and audit them for evidence density. Do they have specific statistics? Named sources? Inline citations? Dates that are current? If not, you’ve found your first GEO wins. Tools like SEObolt can automate this scoring, but even a manual pass against those criteria will show you where the gaps are.

*SEO isn’t dead. But if you’re only optimizing for Google’s crawler in 2026, you’re optimizing for half the picture. The other half is already here.*

In October 2025, nearly 1,000 plugins were pulled from the WordPress repository due to security vulnerabilities. Those plugins had over 7.1 million active installations.

Let that sink in for a moment.

If you’re running a WordPress site in 2026, security isn’t something you’ll “get around to.” It’s not a nice-to-have you can bolt on after launch. It’s the foundation everything else sits on — and most site owners are getting it dangerously wrong.

I run a WordPress plugin company. We build security tools, performance plugins, and SEO software. Every day, we see the damage that comes from neglected sites: hacked databases, injected spam, destroyed rankings. The common thread? It was almost always preventable.

This guide covers everything — from the basics you’ve probably heard before (but aren’t doing) to the advanced hardening steps that actually stop real attacks in 2026.

The WordPress Threat Landscape Has Changed

Let’s be honest: WordPress powers 43% of the web. That makes it the single biggest target for automated attacks.

The attacks in 2026 aren’t the brute-force hammering of a decade ago. They’re smarter:

• Supply chain attacks — Compromised plugins that inject malicious code through legitimate update channels
• Zero-day exploits — Attackers hitting plugin vulnerabilities before patches exist
• Credential stuffing — Using leaked password databases to try username/password combinations at scale
• API abuse — Exploiting the WordPress REST API and XML-RPC to extract data or gain access

The old advice of “keep WordPress updated” is necessary but nowhere near sufficient.

Step 1: Audit What You’re Actually Running

Before you harden anything, you need to know what you’re working with.

Open your WordPress admin, go to Plugins, and ask yourself:

• When was each plugin last updated?
• Do I actually use all of these?
• Are any of these abandoned?

Here’s a stat that should concern you: 59% of all WordPress plugins are abandoned or unmaintained. That means more than half the plugin ecosystem is running on code that nobody is patching.

We track this problem at Royal Plugins. Our Plugin Graveyard is a searchable database of 194+ abandoned plugins — each with over 10,000 active installs — collectively running on more than 5 million sites. You can search for any plugin you’re using and find out if it’s been left to rot.

If a plugin hasn’t been updated in two years, it’s not “stable.” It’s a liability.

Action step: Deactivate and delete any plugin you’re not actively using. Replace abandoned plugins with maintained alternatives. Check the Graveyard if you’re not sure.

Step 2: Lock Down Your Login

Your login page is the front door. Most site owners leave it wide open.

Use strong, unique passwords

This sounds obvious. It isn’t being done. According to breach data, “admin/admin” and “admin/password123” still work on a disturbing number of WordPress sites.

Use a password manager. Generate a random 20+ character password. Never reuse it.

If you need to create a strong password quickly, use a generator — there are plenty of free ones that run entirely in your browser with no signup required.

Enable Two-Factor Authentication (2FA)

Passwords alone aren’t enough. 2FA adds a second verification step — usually a time-based code from an authenticator app — that makes stolen passwords useless.

Most security plugins offer this. It’s the single highest-impact change you can make to your login security.

Limit login attempts

Brute force attacks try thousands of password combinations per minute. Rate limiting stops them cold.

A good WordPress firewall will handle this automatically, blocking IPs after repeated failed attempts and progressively increasing lockout durations.

Step 3: Install a Web Application Firewall (WAF)

A firewall sits between your site and incoming traffic. It analyzes every request before it reaches WordPress and blocks anything that looks malicious.

What a good WAF blocks:

• SQL injection attempts
• Cross-site scripting (XSS)
• Directory traversal attacks
• Malicious file uploads
• Known exploit patterns

The key word is before. A firewall stops attacks before they reach your application code. Without one, you’re relying on WordPress and every single plugin to handle malicious input correctly. That’s a losing bet.

When we built GuardPress, our WordPress security plugin, the firewall was the first feature we prioritized. It analyzes requests, blocks malicious traffic instantly, and lets legitimate visitors through — with minimal performance impact.

Step 4: Scan for Malware Regularly

Firewalls prevent attacks. Scanners catch what got through.

A malware scanner checks your files and database for:

• Injected code in theme and plugin files
• Base64-encoded payloads (a common obfuscation technique)
• Known malware signatures
• Modified core WordPress files
• Suspicious database entries

The sneaky ones don’t announce themselves. We regularly see infections buried in the wp_options table — a base64-encoded payload sitting in an innocuously named option like widget_settings_cache that executes on every page load. File-only scanners miss these entirely. Make sure your scanner checks the database too.

Run scans on a schedule — weekly at minimum, daily if your site handles sensitive data. Don’t wait until Google flags your site with a “This site may be hacked” warning. By then, you’ve already lost traffic and trust.

Step 5: Harden Your HTTP Security Headers

This is one of the most overlooked security measures, and it’s completely free.

Security headers are instructions your server sends to browsers that control how your site can be loaded and interacted with. Without them, you’re leaving the door open to clickjacking, MIME sniffing, and cross-site attacks.

The critical headers:

Header What It Does Content-Security-Policy Controls which scripts, styles, and resources can load Strict-Transport-Security (HSTS) Forces HTTPS connections X-Frame-Options Prevents your site from being loaded in iframes (clickjacking) X-Content-Type-Options Prevents MIME type sniffing Referrer-Policy Controls what information is sent when users click links Permissions-Policy Restricts browser features (camera, microphone, geolocation)

A word of caution on Content-Security-Policy: a misconfigured CSP will break your site — inline scripts stop working, third-party embeds disappear, Google Analytics goes silent. Start with Content-Security-Policy-Report-Only to see what would be blocked before enforcing anything.

Not sure where you stand? Run your site through a security headers checker — we have a free one at Royal Plugins, and there are others out there too. They’ll grade your headers and tell you exactly what’s missing.

Most of these headers can be added with a few lines in your .htaccess file or nginx config:

# .htaccess security headers
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Step 6: Verify Your SSL Configuration

Having an SSL certificate isn’t enough. You need to verify it’s configured correctly.

Common SSL issues:

• Mixed content — Loading HTTP resources on an HTTPS page (breaks the padlock, creates vulnerabilities)
• Expired certificates — Let’s Encrypt certs expire every 90 days. Auto-renewal fails silently more often than you’d think
• Weak cipher suites — Old TLS versions (1.0, 1.1) have known vulnerabilities
• Missing HSTS — Without it, the first request to your site can be intercepted before the HTTPS redirect

Run your domain through an SSL checker to validate your certificate chain, expiration date, and protocol configuration. Takes 10 seconds.

Step 7: Disable What You Don’t Use

WordPress ships with features enabled by default that most sites don’t need — and each one is an attack surface.

XML-RPC

Unless you’re using the WordPress mobile app or Jetpack, disable it. XML-RPC supports a method called system.multicall that lets attackers test hundreds of passwords in a single HTTP request — bypassing most rate limiters that count by request, not by attempt.

Add to .htaccess:

<Files xmlrpc.php>
    Order Allow,Deny
    Deny from all
</Files>

File editing in wp-admin

The built-in theme and plugin editor lets anyone with admin access modify PHP files directly from the browser. If an attacker gains admin access, this is the first thing they use.

Add to wp-config.php:

define('DISALLOW_FILE_EDIT', true);

User enumeration

By default, WordPress reveals valid usernames through author archives and the REST API. Attackers use this for targeted brute force attacks.

Try it yourself: visit yoursite.com/?author=1 or yoursite.com/wp-json/wp/v2/users in a private browser window. If you see a username, so can every bot on the internet. Block the REST API user endpoint for unauthenticated requests and disable author archives if you don't need them.

Directory browsing

If directory indexing is enabled, anyone can browse your file structure. Disable it:

Options -Indexes

Step 8: Keep a Security Activity Log

You can’t investigate what you can’t see.

An activity log records every significant action on your site:

• User logins and failed login attempts
• Plugin installations and updates
• File modifications
• Settings changes
• User role changes

When something goes wrong — and eventually, something will — the activity log is how you figure out what happened, when, and how. Without one, you’re flying blind.

Step 9: Backup Before Everything

No security strategy is complete without backups. Security reduces risk. Backups eliminate consequences.

The rules:

• Automate it. Manual backups don’t happen.
• Store offsite. A backup on the same server as your site is useless if the server is compromised.
• Test restores. A backup you’ve never restored is a backup you hope works. Hope is not a strategy.
• Keep multiple copies. Rotating backups (daily for a week, weekly for a month) let you go back to before the compromise, even if you didn’t catch it immediately.

Step 10: Monitor Continuously

Security isn’t a one-time setup. It’s ongoing.

Set up monitoring for:

• Uptime — Know immediately when your site goes down
• File integrity — Get alerts when core files are modified
• Blacklist status — Check if Google, Norton, or McAfee have flagged your domain
• SSL expiration — Get warned before your certificate expires

Real-time monitoring with email alerts means you find out about problems in minutes, not days.

The Hardening Checklist

Here’s everything in one actionable list:

• [ ] Audit installed plugins — remove unused, replace abandoned
• [ ] Check the Plugin Graveyard for dead plugins
• [ ] Use strong, unique passwords (use a generator if needed)
• [ ] Enable Two-Factor Authentication
• [ ] Install a Web Application Firewall
• [ ] Set up automated malware scanning
• [ ] Add HTTP security headers
• [ ] Verify SSL configuration
• [ ] Disable XML-RPC, file editing, user enumeration
• [ ] Disable directory browsing
• [ ] Enable activity logging
• [ ] Set up automated offsite backups
• [ ] Configure uptime and file integrity monitoring
• [ ] Keep WordPress core, themes, and plugins updated

We maintain a more detailed interactive version of this checklist at our WordPress Hardening Checklist — it walks you through each step with specific instructions.

Final Thought

WordPress security isn’t complicated. It’s just not optional.

Most compromised sites weren’t targeted specifically. They were scanned by bots, found running outdated software or missing basic protections, and exploited automatically. The attackers didn’t care what the site was about. They just needed a host for spam, phishing pages, or cryptocurrency miners.

Every step in this guide reduces your attack surface. None of them require a computer science degree. Most can be done in an afternoon.

Start with the firewall and 2FA. Then work through the rest. Your future self — the one who doesn’t have to spend a weekend cleaning malware out of their database — will thank you.

WordPress Security in 2026: The Complete Hardening Guide was originally published in MeetCyber on Medium, where people are continuing the conversation by highlighting and responding to this story.