Six months ago I shipped a plugin called Royal MCP to the WordPress.org directory. It does a specific job: it lets AI clients like Claude and ChatGPT talk to a WordPress site through a secure authenticated endpoint. Since it went live, two independent researchers have found bugs in it. Both got fixed. Both are on the public record. Both are the reason the plugin is measurably safer today than it was when it launched.

The first email

Alexis Lafontaine, via a security research platform called Patchstack. Alexis had found a broken access control gap on one of the plugin’s request paths. Certain tool calls could be reached without going through the authentication check. It was real. The fix landed a few days later. All tool calls now require authenticated credentials.

The whole exchange took under two weeks from initial report to public disclosure. Alexis was patient, precise, and generous with the reproduction steps. I fixed the code, verified with Alexis that the fix closed the vector, shipped the patch, and credited Alexis by name in the changelog. That is the model. That is what “responsible disclosure” actually looks like in practice.

The second email

Alessandro Greco, who goes by Aleff, coordinated through WPScan (the WordPress vulnerability database owned by Automattic). Alessandro had found something more subtle. Once the plugin added OAuth support so AI clients could authenticate as specific WordPress users, a low-privileged user (someone with a Subscriber or Contributor role) could get a valid OAuth token and then use it to invoke operations they should not have been able to. The plugin was not checking, per tool call, whether the authenticated user’s actual role allowed the specific operation they were requesting.

We fixed it in v1.4.26. And then we did something bigger. We used Alessandro’s report as the trigger to build a role-based capability scanner and bake it into Royal MCP’s pre-ship process. Before any Royal MCP release ships to WordPress.org today, the scanner creates test accounts at every WordPress role tier, walks every entry point the plugin exposes, and verifies that low-privileged users cannot invoke operations they should not be able to.

The pattern is now the internal model for anything Royal Plugins ships with a per-user role surface. One researcher’s report on one plugin became a permanent defense against the same class of bug for Royal MCP, with a repeatable model for future products. That is a return on investment that is hard to describe in words. It is the kind of thing you only get when you take a single disclosure seriously enough to treat it as a signal, not just a ticket.

Why I don’t dread these emails anymore

Most plugin authors treat their first disclosure email as a crisis. It is not. What can turn it into a crisis is how the author responds.

The bad response is depressingly common. Deny the report. Silently patch and pretend nothing happened. Go quiet for weeks. Argue with the researcher about severity. Threaten legal action. The vulnerability gets disclosed anyway (because the researcher owns the report). The plugin’s reputation takes a hit. Users lose trust. And the researcher makes sure other researchers know the vendor is difficult to work with.

The good response is boring. Acknowledge quickly. Fix quickly. Ship the patch. Credit the researcher by name. Move on. That is it. That is the whole thing.

The good response takes less energy than the bad one. And it compounds. Every good response you ship makes the next researcher who finds a bug in your code more likely to contact you privately first. That is the reputation you actually want.

Closed tickets are marketing, not damage

This is the part nobody tells first-time plugin authors, and I wish someone had told me.

Public vulnerability records are not damage to your plugin’s reputation. They are the opposite. A record that says “found, fixed, verified, credited” is one of the strongest signals you can send to a prospective user that your plugin is being actively maintained by someone who takes it seriously. It says you have an intake process. It says you ship fixes fast. It says you are willing to put the entire chain of custody on the public record.

A plugin with no public vulnerability records could mean it has never had one. In practice, on any plugin of real complexity, it usually means the author has been hiding them or that no researcher has looked. Neither is a virtue.

When a prospective customer checks Wordfence’s public database or WPScan and sees clean patch records on Royal MCP, that is not a warning label. That is credibility. Every entry is proof that a class of issue was found, closed, and documented instead of shipped indefinitely into thousands of production sites.

Which is why I now treat those two records as bragging rights, not scars.

If you build software

At some point, someone will email you about a bug they found. Read the email. Reproduce the report. Fix it fast. Audit adjacent code while you are in there. Ship the patch. Credit the researcher by name. Publish the record.

Then keep building.

The email is not a bad day. It is a good one.

The longer, more technical version of this piece with the full case study details lives on the Royal Plugins blog at royalplugins.com/blog/two-vulnerabilities-two-researchers-two-fixes.

The tricky part is that these bots do very different things. Some are training crawlers, some are retrieval bots, and some are shopping agents. Blocking the wrong one can quietly remove you from citation graphs, from product search results, or from the answers that your future customers are about to see in ChatGPT.

Here are the thirteen you are most likely to see, in rough order of how often they show up in the wild, with what each one does and what happens if you block it.

1. GPTBot (OpenAI)

The one that gets all the press. GPTBot is OpenAI’s training crawler. When it hits your site, the content it reads may end up in the next version of ChatGPT’s base model.

What it collects: Full page HTML, most site sections it can reach.

Blocking consequences: None to your ChatGPT visibility today, because base model training is not what makes ChatGPT cite you. Blocking GPTBot is one of the safer moves if you do not want your content in future training runs. It will not stop ChatGPT from citing you at query time, because ChatGPT uses a different bot for that.

2. ChatGPT-User (OpenAI)

The one people confuse with GPTBot, at their peril. ChatGPT-User is the on-demand fetcher. When a ChatGPT user asks a question and the model decides to fetch a URL to answer, ChatGPT-User is what makes the request.

What it collects: A specific page in response to a user query.

Blocking consequences: Real. If you block ChatGPT-User you remove your site from ChatGPT’s live citation results. Blogs that block ChatGPT-User stop appearing in the “Sources” list on ChatGPT answers. If you want to be citeable, keep this one allowed.

3. OAI-SearchBot (OpenAI)

OpenAI’s third crawler and the one most people forget exists. OAI-SearchBot indexes content for ChatGPT’s search product (the one that surfaces links in the ChatGPT UI, separate from the on-demand fetches ChatGPT-User does).

What it collects: Web pages for the ChatGPT Search index.

Blocking consequences: Removes your site from ChatGPT Search results. Same allow/block calculus as PerplexityBot below. If you want to be discoverable inside ChatGPT, keep this one allowed. OpenAI publishes its IP range at openai.com/searchbot.json so you can verify real hits versus spoofers.

4. ClaudeBot (Anthropic)

Anthropic’s training and retrieval crawler for Claude.

What it collects: Full site content.

Blocking consequences: Similar tradeoff to GPTBot plus ChatGPT-User combined. Anthropic runs a slightly different infrastructure where the same bot handles both training reads and some retrieval. Blocking ClaudeBot fully will remove you from Claude’s citation surface. Anthropic has published guidance for site owners who want to opt out of training but stay citeable; check their docs before you make a policy decision.

5. PerplexityBot (Perplexity)

Perplexity is a search engine that answers questions with cited sources. PerplexityBot is what builds the index those answers cite from.

What it collects: Page content plus link graph.

Blocking consequences: Removes your site from Perplexity answers. If you sell information products, courses, or B2B content, Perplexity is one of the highest-intent AI referrers currently in the wild. Blocking this bot is almost always the wrong move.

6. CCBot (Common Crawl)

Not an AI company directly. Common Crawl is a nonprofit that publishes a monthly open-web dataset. Every major AI training run uses Common Crawl as one of the input sources.

What it collects: Full HTML. CCBot has been crawling since before AI training was a phrase people used.

Blocking consequences: Removes your content from Common Crawl’s public datasets, which means removes it from the base training data for basically every open-source model and most closed ones. This is the most consequential single block on this list. It does not touch retrieval at all, so blocking it does not affect ChatGPT or Claude citations. It only affects future training.

7. Google-Extended (Google)

Not a crawler in the traditional sense. Google-Extended is a policy signal. If you disallow Google-Extended in robots.txt, Google will exclude your content from Bard, Gemini training, and Vertex AI grounding. Googlebot itself keeps crawling for regular search.

What it collects: Nothing new. It’s a flag on the existing Googlebot crawl.

Blocking consequences: Google’s AI products stop using your content for training and grounding. Google search itself is unaffected. This is the cleanest opt-out on the list.

8. Applebot-Extended (Apple)

Apple’s equivalent of Google-Extended. Signals whether Apple can use your content in Apple Intelligence.

What it collects: Nothing new. Signal on the Applebot crawl.

Blocking consequences: Apple Intelligence stops training on your content. Regular Apple search (which powers Siri suggestions and Spotlight) is unaffected.

9. Bytespider (ByteDance)

ByteDance’s crawler, associated with TikTok and Doubao. Historically aggressive. Bytespider has been reported to ignore robots.txt in some cases; Cloudflare and others published findings on this in 2024.

What it collects: Full page HTML, often at high frequency.

Blocking consequences: Almost none for Western audiences. If TikTok search and Doubao are not part of your distribution plan, this is a safe block. Watch the request volume in your logs before and after; a hard block via user agent may not stop the crawl if Bytespider is rotating IPs.

10. Amazonbot (Amazon)

Amazon’s crawler for Alexa answers and product-adjacent AI.

What it collects: General web content, but with a bias toward product-facing pages.

Blocking consequences: Removes you from Alexa answer surfaces. If your site is ecommerce or affiliate, think twice. If your site is B2B SaaS, blocking is low-consequence.

11. Meta-ExternalAgent (Meta)

Meta’s crawler for LLaMA training and adjacent AI products.

What it collects: Web content.

Blocking consequences: Content excluded from Meta’s future LLaMA training. Meta has an increasingly large open-source AI footprint, so blocking here has broader downstream effect than it looks. LLaMA fine-tunes ship from every corner of the AI ecosystem.

12. cohere-ai (Cohere)

Cohere is an enterprise LLM provider. Their bot crawls for embedding and RAG use in enterprise AI products.

What it collects: Public site content.

Blocking consequences: Limits your content’s inclusion in enterprise AI answer surfaces. If your audience is developers or engineers evaluating Cohere APIs, this bot is worth keeping allowed. Otherwise low-consequence.

13. YouBot (You.com)

You.com’s crawler. You.com is a smaller AI search competitor.

What it collects: Full page content.

Blocking consequences: Removes you from You.com answers. Low blast radius compared to the top of this list.

What to actually do about this

You have three reasonable policies.

Allow everything. This is the default if you take no action. It maximizes your citation surface and gives you the largest possible AI-referral funnel over the next twenty-four months. It also means every crawler on this list is reading your content.

Block training bots, allow retrieval bots. This is the middle path most sites should consider. Block GPTBot, CCBot, ClaudeBot’s training paths, Bytespider, Meta-ExternalAgent, and Google/Applebot-Extended. Keep ChatGPT-User, PerplexityBot, Amazonbot, and cohere-ai allowed. You stay citeable. You stop feeding the training pipeline.

Block everything. Rarely correct. This is what most panic-blocking guides recommend, and it costs you the AI-referral traffic that is already starting to show up in analytics for sites that let the retrieval bots in. Do this only if you have a legal reason.

The setup problem

Reading a list like this is one thing. Actually implementing per-bot policy on a WordPress site is another. You have to identify user agents in your logs, decide whether a hit is verified or spoofed, write matching rules, deploy them somewhere, and audit whether they’re actually working.

That’s the exact workflow Royal AI Firewall does for you. It’s a free WordPress plugin that classifies 55 AI bots across six categories (training crawlers, retrieval bots, AI search engines, agent browsers, dataset scrapers, and traditional search indexers, so you can distinguish Googlebot from GPTBot in the same view), shows you which ones have hit your site, and gives you a per-bot policy toggle with the blocking-consequences note that this article just walked through for each bot. The dashboard lives inside wp-admin. The plugin does not require Cloudflare or any external service.

Before you install it, or any WordPress plugin, run the audit process I wrote up in The Complete WordPress Plugin Audit Guide on Skill Stuff. Same discipline. Read the code, check the changelog, verify the author, then install.

The full Royal Plugins catalog is at royalplugins.com. Details on Royal AI Firewall are at royalplugins.com/royal-ai-firewall/.

Two hours later I found it. The setting had been renamed. It had been moved to a new section. The screenshots in my own runbook were now wrong. And when I finally clicked through, I discovered that Cloudflare had introduced a third interface for AI bots called “AI Audit,” which lived somewhere entirely different and did something adjacent but not identical.

This is not a complaint about Cloudflare. Cloudflare is genuinely good software. Their edge network is best-in-class. Their engineers ship faster than almost anyone.

The problem is that they ship so fast, and their surface area is so large, that if you are not living in the Cloudflare dashboard every week, you spend a real percentage of your working hours re-learning where things are.

For a WordPress site owner who touches Cloudflare maybe once a quarter, this is a tax. And it is the exact tax that led us to build Royal AI Firewall.

The problem with the “just use Cloudflare” advice

Every time somebody on Reddit or a Facebook group asks how to block ChatGPT from scraping their WordPress content, three replies show up within an hour. All three say the same thing. Just use Cloudflare.

The advice is not wrong. Cloudflare’s WAF and their bot management product genuinely can block AI crawlers. If you are a Cloudflare-native shop and your team lives in that dashboard, it is the right tool.

But that advice ignores four groups of people.

The site owners who are not on Cloudflare at all. They are on Kinsta or Pressable or WP Engine or a shared host that has its own CDN. Telling them to add Cloudflare to solve one problem is telling them to add an entire infrastructure layer.

The site owners whose host is already fronting Cloudflare for them. GoDaddy, Bluehost, and SiteGround all put their own Cloudflare in front of customer sites. The customer does not have access to that Cloudflare dashboard. They have access to the host’s simplified UI, which does not expose most of the bot controls. If they then add their own Cloudflare on top, they now have two Cloudflares, and neither one shows a complete picture.

The site owners who are on Cloudflare but only need to configure it once a year. They know the interface will have moved by then. They know they will spend an afternoon relearning it. Every year.

The agencies who need to give a client a straight answer about which AI bots are hitting their site. They cannot log into a client’s Cloudflare account to check. They need something that lives inside WordPress, that the client can see, that the client can screenshot when the marketing team asks.

For all four groups, the honest answer to “how do I control AI bots on my WordPress site” is not “use Cloudflare.” It is “install something that lives where you already work.”

What we built

Royal AI Firewall is a free WordPress plugin. It installs from the plugin directory, activates in one click, and shows you every AI bot hitting your site inside a single wp-admin page. The plugin recognizes 55 AI bots at launch across six categories, identified by user agent and verification method: GPTBot, ChatGPT-User, OAI-SearchBot, ClaudeBot, PerplexityBot, CCBot, Google-Extended, Applebot-Extended, Bytespider, Meta-ExternalAgent, agent browsers like Operator and Claude Computer Use, and the long tail of smaller ones.

For each bot you get three things.

You get a count of how many times it has hit your site in the last 24 hours, 7 days, and 30 days.

You get a per-bot policy toggle. Allow, block, or leave as-is.

You get a blocking-consequences explainer. Because blocking GPTBot means one thing and blocking ChatGPT-User means something completely different. One is a training crawler. The other is what fetches a page when someone in ChatGPT clicks a link to your article. Blocking the second one removes you from the citation graph.

That is the whole plugin. There is a first-run wizard that runs on activation, a dashboard, a settings page, and a fingerprint database that updates itself. There is no Pro tier. There is no analytics telemetry. There is no paywall on the core feature set.

Why WordPress-native beats edge-first for this specific problem

The AI bot problem is a content problem more than a network problem. You want to know who is reading your content, whether your content is showing up in AI answers, whether the ratio of “in” versus “out” traffic is fair, and whether any of these bots are hitting endpoints they should not be hitting.

Those are questions best answered where your content lives. That is WordPress.

Cloudflare knows a lot about what happens at the edge. It does not know which of your posts got cited in a Perplexity answer three days ago. It does not know which of your product pages an AI shopping bot has scraped seven times this week. It sees traffic. It does not see meaning.

A WordPress plugin sees both. It sees the request, and it sees the post ID the request was for. It sees who the visitor is claiming to be, and it sees which of your custom post types they hit hardest.

That is why we built inside WordPress instead of trying to compete with Cloudflare at the edge. Different tools, different jobs.

The “vet everything before you install it” caveat

Before you install any WordPress plugin, including this one, you should audit it.

I wrote a guide for Medium’s Skill Stuff publication last week called The Complete WordPress Plugin Audit Guide. It walks through the checks I run on every plugin before it goes on a client site. Author reputation, changelog frequency, code review, PHP version support, database footprint, and about a dozen other things. Same discipline applies to Royal AI Firewall. Read the source before you trust it.

The plugin is open source. The source is in the WordPress.org plugin directory. Read it, run it through Plugin Check, and decide if it belongs on your site.

What comes next

Royal AI Firewall is at royalplugins.com/royal-ai-firewall/. When the WordPress.org listing goes live I will follow up with a walkthrough post on the first-run wizard and the surprising bot hits I saw on my own site in the first week.

If you want a broader look at what Royal Plugins is building, the whole catalog lives at Royal Plugins.

Cloudflare is fine. But some of us just want a settings page that stays in the same place.

RP Team

The certificate had been “valid” the day before, with the green padlock showing in every browser I tested. The padlock told me what I wanted to hear. An SSL certificate checker would have told me what I needed to know.

What the Padlock Actually Verifies

The padlock icon means the connection between your browser and the server is encrypted. That is it. It does not verify that the certificate is current, that the chain is complete, that the TLS version is modern, or that all subdomains are covered.

Browsers are intentionally permissive about which certificates they accept. They prioritize getting the user to the page over surfacing configuration warnings. So a certificate that expires in 24 hours shows the same green padlock as one that just renewed. A certificate with a broken intermediate chain might work in Chrome but fail on iOS Safari. A certificate using deprecated TLS 1.0 still encrypts, just badly.

The padlock is binary. The actual configuration is a spectrum.

What Actually Goes Wrong

Some of the silent SSL failures I have seen on real sites:

Auto-renewal failures. Free certificates from Let’s Encrypt expire every 90 days. Auto-renewal is supposed to handle it. When DNS changes break the auto-renewal verification, no email goes out. The certificate just dies on schedule.

Incomplete chain. Your certificate is signed by an intermediate authority, which is signed by a root. If the intermediate is missing from the server response, some browsers reject the connection. Chrome might fix it on the fly. iOS Safari often does not. Result: your site works for some visitors and breaks silently for others.

Mixed content. Page loads over HTTPS, but images, scripts, or stylesheets load over HTTP. Browsers show warnings, the padlock disappears or downgrades, and form submissions can fail.

Outdated TLS. Older TLS versions (1.0 and 1.1) have known vulnerabilities. Modern browsers are deprecating them. Servers that still support them work today and will start failing tomorrow.

Subdomain mismatch. Your main domain has a wildcard certificate. Your blog subdomain ended up on a different server with its own setup. One subdomain works, another shows warnings.

None of these issues remove the padlock for everyone. They just create a percentage of visitors who hit broken connections, and you have no idea unless you check.

Make This a Monthly Check

I run my domains through an SSL certificate checker on the first of every month. The check shows the exact expiration date, chain completeness, TLS version, and cipher strength. Five seconds per domain. The 30-day buffer means even if auto-renewal silently fails, I catch it before the cert dies.

The free Royal Plugins SSL Certificate Checker runs all of these checks on any URL, with no signup. It tests the main domain plus any subdomains you specify, reports expiration in days, and flags weak ciphers or chain issues immediately.

For continuous monitoring of SSL alongside the rest of the WordPress security stack (login lockdown, security headers, file integrity, malware scanning), GuardPress covers the recurring side. Use the free checker for monthly spot audits and as the first step after any DNS or hosting change.

The honest answer is yes, but you have to know which workflow to pick. There are four ways I know of to edit Elementor with Claude today. I’ve personally used three of them across real client work. The fourth is interesting but I haven’t shipped it on a live site yet, and I’ll be upfront about why.

Here’s the breakdown.

Workflow 1: Write in Gutenberg, Open in Elementor

This is the simplest one. You ask Claude to draft a post or page through an MCP connection. Claude writes the content directly into WordPress’s Gutenberg block editor. You then open the post in Elementor and it wraps each block as a widget.

I use this for blog posts and template-driven service pages. Anywhere the layout is consistent and the content is what matters, this workflow gets a draft up in seconds.

Where it breaks: pages built natively in Elementor from the start have empty post content. Gutenberg has nothing to write into. So if you’ve designed a page widget-by-widget inside Elementor, this approach won’t apply.

Use it for content-first work, skip it for design-first work.

Workflow 2: Build the Layout Yourself, Let Claude Handle the Copy

For high-stakes marketing pages, I still build the layout manually. Container model, atomic widgets where the design calls for it, spacing tuned by eye. Then I ask Claude to draft the headlines, body copy, CTAs, and FAQ answers, and I paste those into the relevant widgets.

This is the most labor-intensive of the three I use, but it’s the right call when pixel precision matters. Humans are still better than AI at non-trivial layout decisions. I reserve this for landing pages where every conversion point pays for the time.

The split works because copy and layout are different problems. You don’t need AI for the part it’s worst at.

Workflow 3: Clone an Existing Page and Mutate It (Royal MCP)

This is the one I reach for most often, and it’s the one I built a plugin to make reliable.

The idea: instead of asking AI to build something new, you point it at a page that already works and ask it to make a variant. Claude reads the page outline, clones the page, regenerates the internal element IDs so nothing collides, swaps text across the widget types it understands (headings, buttons, text editors, testimonials, FAQs), swaps image URLs where you tell it to, and saves a draft for you to review.

A concrete example. My services page for one city converts well. I want a version for a different city. I tell Claude:

▎ Clone the New York services page. Replace “New York” with “Los Angeles” everywhere. Swap the hero image for the LA skyline photo I uploaded last week. Save as a draft.

The MCP runs the clone, runs the text replace, runs the image swap. A draft is ready in seconds. I open it in Elementor, refine anything that needs a human touch, and publish.

Why this approach actually works: nothing tries to decode the Elementor page-builder JSON from scratch. The clone copies bytes. The replacements only touch widget types the tool knows how to handle, and they tell you exactly how many replacements happened. If zero things matched, you get a clear “0 replacements” response instead of a silently broken page.

I built Royal MCP for exactly this workflow. It’s free on the WordPress.org plugin directory, capability-gated, runs on OAuth, and ships among the first cohort of MCP plugins reviewed by the wp.org team.

Workflow 4: Generate Elementor JSON From a Prompt (I Haven’t Used This)

This is the workflow I haven’t put into client work, and I want to be honest about that.

The idea is exciting: describe a page in plain English, AI generates the underlying Elementor JSON, the page materializes. A few projects are chasing it.

Two worth knowing about:

1. Angie is the official plugin from the Elementor team. It’s on WordPress.org. Current rating is 2.4 stars, and the negative reviews tell you which workflows are still rough. I haven’t installed it on a production site. If you want to try it, read the reviews first.

2. msrbuilds/elementor-mcp is a community project on GitHub with around 316 stars and active development on a roughly two-to-three-week release cycle. The tool surface is the most ambitious I’ve seen: over 100 tools spanning page management, layout, widgets, templates, and theme builder. I’ve read through the repo and the code looks serious. I haven’t run it on a client site yet because the distribution is GitHub-only (no WordPress.org security review before installation) and the auth model uses WordPress Application Passwords, which means a leaked credential gives broader access than just the MCP routes.

If you’re tinkering or building demos, both are worth exploring. For production work where a broken page costs real money, I’m still using clone-and-mutate.

How to Pick

It actually comes down to the task, not the tooling.

• Content-first page with a template: Workflow 1, write in Gutenberg, open in Elementor.

• One-off marketing page where design matters: Workflow 2, build the layout yourself, let Claude handle the copy.

• Variants of a page that already works: Workflow 3, clone-and-mutate with Royal MCP.

• Demos, experiments, or you just want to see what’s possible: Workflow 4, try Angie or msrbuilds and see how far you get.

The guiding principle I keep coming back to: start with something that already works unless you specifically need to invent from scratch. AI is better at customizing than inventing. The whole reason clone-and-mutate works so well is that you’re handing the AI a problem it can succeed at.

If you want the longer version with the technical reasoning behind each workflow, setup steps for Royal MCP, and the FAQ I’ve built up from these conversations, I wrote the full breakdown on the Royal Plugins blog: Editing Elementor with Claude: The Four Workflows That Work Today (https://royalplugins.com/blog/editing-elementor-with-claude-four-workflows/).

Performance and security are graded by completely different tools, and most site owners only check one of them. The result is sites that are fast and wide open at the same time.

Why PageSpeed Does Not Touch Security Headers

PageSpeed Insights measures rendering performance. Time to first byte, largest contentful paint, cumulative layout shift, total blocking time. These tell you how fast your site loads. They tell you nothing about whether your site is configured against the most common web attacks.

Security headers are a separate concern entirely. They are HTTP response headers your server sends with every page. Browsers read those headers and use them to decide what is allowed: which scripts can run, whether the site can be embedded in iframes, how cookies should be handled, what referrer info gets leaked.

A site can return Content Security Policy headers, X-Frame-Options, Strict-Transport-Security, X-Content-Type-Options, and Referrer-Policy, or it can return none of them. Either way, PageSpeed scores the same. Security graders do not care about your speed.

What an F Actually Means

Six core security headers, all missing. Six separate attack vectors left open by default. None of them flagged by performance tools or by my caching plugin or by my SEO plugin.

Content-Security-Policy missing. Any script from any source could execute on my pages. Most XSS attacks rely on this gap to inject malicious scripts.

Strict-Transport-Security missing. Even though I had SSL, browsers were not required to use it. A user on public WiFi could be intercepted on the initial HTTP request before the redirect.

X-Frame-Options missing. My entire site could be embedded in an invisible iframe and used for clickjacking on a phishing page.

X-Content-Type-Options missing. Browsers were free to guess file types. Attackers exploit this to run uploaded files as scripts.

Referrer-Policy missing. Full URL paths, including any session tokens in query parameters, leaked to every external link.

Permissions-Policy missing. Camera, microphone, and geolocation access were not restricted, even on pages that had no business asking for those permissions.

The Fix Took 15 Minutes

I added all six headers through my hosting panel’s custom header settings. On WordPress with shared hosting, the same fix is a few lines in .htaccess or a security plugin that handles headers.

After deploying, I ran the same security headers check again. The grade jumped from F to A. Same site, same content, same hosting. Just six lines of configuration.

The whole thing took less time than my morning coffee. Months of speed optimization had not affected security at all, and 15 minutes of header configuration had not affected speed.

Treat Speed and Security as Two Separate Audits

Whatever performance tool you run weekly, run a security headers check on the same cadence. They take seconds. They surface entirely different problems.

The free Royal Plugins HTTP Headers Checker checks 8 security headers, gives a weighted grade, and shows exactly what is present and what is missing. No signup.

For a hardening setup that maintains security headers across deploys, plus the rest of the WordPress security stack (login lockdown, file integrity, 2FA, malware scanning), GuardPress handles continuous protection. Start with the free header check to see your current grade.

Plugin install count is the worst proxy for plugin safety, and most site owners use it as the only signal. A WordPress plugin security scanner checks the things install count cannot.

Why Install Count Means Nothing for Security

The reasoning behind “if it has 10,000 installs, it must be safe” goes like this: if there were a problem, someone would have caught it by now. The math is wrong.

Bug reports happen when a user notices the bug. Most plugin vulnerabilities are silent. Cross-site scripting, SQL injection, broken access control. None of these change the user-facing behavior of the plugin. The plugin keeps doing its job. The vulnerability sits there unnoticed until a researcher finds it or an attacker exploits it.

By the time an exploit is public, the gap between disclosure and patch is the dangerous window. A plugin with 10,000 installs that gets disclosed on a Monday and patched on a Friday means 10,000 sites are exposed for four days. Attackers automate scans for known-vulnerable plugin versions and hit thousands of sites in hours.

What Happened to My Site

The plugin I was running, a simple social sharing widget, had a public XSS disclosure two weeks before my site got hit. I never saw the disclosure because I was not subscribed to any vulnerability feed. The plugin developer had not pushed a patch. Attackers scanned for sites running that exact version, injected malicious code through the XSS, and added a mobile-only redirect.

Recovery took two days. Restore from backup, identify the entry point, remove the compromised plugin, scan every file for residual injections, change all passwords, resubmit to Google for a malware review.

What a Plugin Vulnerability Scanner Actually Checks

A free plugin security scanner cross-references each plugin you have installed against public vulnerability databases like WPScan and CVE records. The information you get back is more useful than star ratings:

Known vulnerabilities by version. If you are running plugin X version 2.4.1 and version 2.4.2 patched a critical XSS, the scanner tells you upgrade is required.

Last update date. Plugins not updated in over a year are higher risk regardless of install count. The WordPress core changes constantly, and unmaintained plugins drift out of compatibility.

Active install trend. Plugins losing installs faster than they gain them often signal abandonment or trust issues.

Public security advisories. Disclosures filed against the plugin in the last 12 months, with severity scores.

Make This Pre-Install and Recurring

Run the scan before installing any plugin. Run it monthly across all installed plugins to catch newly disclosed vulnerabilities in things you already trust.

The free Royal Plugins Plugin Security Scanner analyzes any wp.org plugin source against 20 security rules and generates a security badge plugin developers can display on their READMEs. No signup, no install, runs in under a minute per plugin.

For continuous monitoring of plugin vulnerabilities on a live site, including alerts when a disclosure drops for a plugin you have installed, GuardPress handles the recurring side. Use the free scanner for the pre-install vetting and one-off audits.

Both tools were doing their jobs. They were just doing different jobs, and most site owners do not realize there is a gap between them.

Internal Scanners and External Scanners Are Not the Same

A security plugin running on your WordPress install audits what it can see from inside the server. File integrity, login attempts, plugin versions, malware signatures, database changes. This is valuable. It is not the same as auditing what your site exposes to the public internet.

An external scanner connects to your domain the way a bot or attacker would. It does not have access to your file system. It cannot read your wp-config.php. What it sees is the rendered HTML, the HTTP response headers, the publicly accessible URLs, and the metadata your server happens to broadcast.

Those are the things attackers actually use to pick targets. Plugin scanners do not check most of them because they are not visible from inside the server.

What the External Scan Found

Five issues my premium security plugin never flagged:

WordPress version exposed. My pages broadcast the exact WordPress version in the HTML source. Attackers maintain databases of version-specific exploits, so this is the first thing automated scanners look for.

XML-RPC endpoint open. Wordfence saw login attempts and blocked some of them, but the XML-RPC endpoint itself was still publicly reachable. Attackers use it for amplified brute force and DDoS.

Five missing security headers. No Content-Security-Policy, no Strict-Transport-Security, no X-Frame-Options, no X-Content-Type-Options, no Referrer-Policy. Each missing header is a separate attack vector. None of them are checked by internal plugins because they are server-level configuration, not WordPress configuration.

Directory browsing enabled. Anyone could navigate to /wp-content/uploads/ and see a listing of every file ever uploaded. This reveals file paths, sensitive filenames, and structure that helps attackers plan further probes.

WP_DEBUG left on. A leftover from a troubleshooting session months earlier. Error messages including file paths and database queries were being exposed in production.

Total fix time once I knew what to fix: about 20 minutes.

Why You Need Both Kinds of Scanner

The internal plugin caught real-time things the external scanner cannot see: brute force login attempts, file changes, malware signatures in uploaded content. The external scanner caught configuration issues the internal plugin had no visibility into.

Either tool alone has blind spots. Together, they cover most of what you actually need.

If you only run an internal plugin today, schedule a monthly external scan as a complement. The free Royal Plugins WordPress Security Scanner runs 12 WordPress-specific checks from outside, in under a minute, with no signup or installation.

For a hardening layer that covers the WordPress-side controls an external scan cannot reach (login lockdown, 2FA, firewall rules, file integrity), GuardPress is the internal complement to the external scan. Run the external check first to see what is publicly visible, then close those gaps with hardening.

The theme was outputting JSON-LD with three separate errors. Google had been silently ignoring my structured data the entire time.

What Built-In Schema Actually Means

Themes that advertise schema markup typically generate Article, BlogPosting, or WebPage schema automatically. Sounds good. The problem is that “automatic” does not mean “valid.”

Schema markup has strict requirements. Article schema requires headline, image, datePublished, and author. The author has to be a Person or Organization object, not a plain text string. Dates have to be in ISO 8601 format. Images have to be reachable URLs.

A theme that hardcodes the author as a string (”By Jane Smith”) instead of a Person object outputs technically invalid schema. The page looks correct in the browser. The schema fails Google’s parser. Zero rich results.

These bugs are silent. There is no error message. Search Console will not warn you. Your theme dashboard will not tell you anything is wrong because the theme thinks it did its job.

The Three Errors on My Own Site

When I ran the validator on my homepage, here is what it surfaced:

Error 1: Author was a plain string. The theme output "author": "Royal Plugins" instead of "author": {"@type": "Organization", "name": "Royal Plugins"}. Required structure was missing.

Error 2: Date format was wrong. The theme used "datePublished": "April 2026" instead of "datePublished": "2026-04-15". ISO 8601 is required. Anything else fails.

Error 3: Image property was missing entirely. The theme generated featured images for visual display but never wrote them into the JSON-LD. Article schema requires at least one image.

Three quiet failures. Eight months of zero rich results.

How I Fixed It

I disabled the theme’s built-in schema and installed a dedicated schema plugin. I configured the plugin to output valid Article schema with all required properties. Then I revalidated every key page to confirm zero errors.

Within three weeks, Google started showing enhanced listings. Average CTR on page-one rankings rose from 4.1% to 7.3%. I did not write any new content. I did not build a single backlink. The only change was repairing the structured data.

Make Schema Validation Part of Your Workflow

Validate after every theme update, plugin install, or template change. Themes and plugins overwrite or duplicate structured data without warning, and silent failures can cost you months of rich result eligibility.

The free Royal Plugins Schema Markup Validator parses any URL or raw JSON-LD, checks 16 schema types, flags missing required fields, and surfaces deprecated properties. No signup.

If you want schema validation built into a broader SEO workflow that also catches GEO score, AI citation issues, and meta tag problems, SEObolt includes structured data audits as part of its core scan. Start with the free validator to see what your current setup is actually outputting.

The problem was not the words. The problem was that 60 characters of “good” advice does not match what Google actually displays. A SERP preview tool showed me exactly what was happening.

Character Count Is a Bad Proxy for Pixel Width

Google does not truncate titles by character count. It truncates by pixel width, which depends on the specific letters in your title. The word “millimeter” is 10 characters of skinny letters. The word “WordPress” is 9 characters but takes up significantly more space because of the W and the capital P.

Most SEO tools enforce a character limit (usually 60). The actual cutoff is around 580 pixels on desktop and around 920 pixels for descriptions. A title under 60 characters can still get truncated if the letters are wide. A title slightly over 60 characters can fit if the letters are narrow.

The only way to know is to render the title in a tool that simulates Google’s actual width.

What I Saw When I Previewed My Own Post

My title read: “Everything You Need to Know About WordPress Security Best Practices for Your Website.” Sixty-eight characters. Within range of most “guidelines.”

Google was rendering it as: “Everything You Need to Know About WordPress Secur...”

The most important words, “Security Best Practices,” were invisible. Visitors scanning the SERP saw a title about everything you need to know about WordPress and nothing telling them what they would actually learn. So they clicked the result above mine that was clearer.

I rewrote the title to “WordPress Security: 5 Fixes You Can Do in 10 Minutes.” Fifty-three characters. The full title rendered. Within one week the CTR jumped from 2% to 8.4%. Same content, same ranking, same audience. Different title.

A Real SERP Preview Saves You Hours of Guessing

Once you see the rendered version, the rewrite happens fast. The hard part is realizing the title was the problem in the first place. Most people blame ranking, content, or competition when it is actually the listing.

Things to test in a SERP preview:

Truncation. Does the title or description cut off mid-thought?

Keyword placement. Is the primary keyword visible in the rendered portion, not the truncated portion?

Hook strength. Does the listing give a reason to click compared to the results above and below?

Mobile vs desktop. Mobile cuts off sooner. A title that fits on desktop may truncate on mobile, and mobile is now over 60% of search traffic.

The free Royal Plugins SERP Preview Tool renders desktop and mobile simulations side by side. Type your title, URL path, and meta description, see the pixel-accurate result.

If you have ten posts ranking on page one with low CTR, run each one through a SERP preview before doing anything else. The fix is usually thirty seconds of editing. For a full SEO audit that flags low-CTR pages alongside title issues, SEObolt catches them at scale, but the free preview tool is where most title fixes start.

What I found: the green lights from your SEO plugin are not telling you what Google sees. They are telling you what your SEO plugin thinks it told the page to output. Those are two completely different things, and a free meta tag checker is the only way to spot the gap.

Why SEO Plugin Dashboards Are Misleading

Your SEO plugin does one job in the meta tag department. It generates a title and description and inserts them into the page header. What it does not do is verify those values survive every other piece of code that runs after it.

Here is what silently overrides your SEO plugin output:

Themes with their own SEO settings. Many themes inject their own meta tags after your plugin runs. The result is duplicate or conflicting tags that Google ignores.

Caching plugins. Some caching layers serve stale meta tags from a previous version of the page. You update the description; the cache serves the old one for hours.

AMP plugins. AMP versions of your pages often pull from completely separate meta fields your SEO plugin has no idea exist.

Page builders. Elementor, Divi, and Beaver Builder all have their own SEO modules. If they are turned on, they may overwrite or duplicate your global SEO settings.

Third-party plugins. Anything that adds OG tags, Twitter cards, or canonical URLs can stomp on your SEO plugin’s work without warning.

Your SEO plugin sees none of this. It checks the values in its own settings and reports back. The page Google actually crawls is a different document.

What I Found When I Looked at the Real HTML

I started using a free meta tag checker that bypasses the SEO plugin entirely. It fetches the page the way Google does, parses the rendered HTML, and shows every meta tag actually present.

Running my own homepage through it surfaced four problems Yoast had never mentioned:

A duplicate canonical tag pointing to two different URLs.

An Open Graph image with a URL that returned a 404.

Two robots meta tags, one of which inherited a noindex from a staging environment three months earlier.

A Twitter card type set to “summary” while my theme was also outputting “summary_large_image,” causing Twitter to render the wrong preview half the time.

None of those issues appeared in any plugin dashboard. They were only visible in the rendered output.

Make This a Quarterly Check

If your SEO plugin is the only thing you use to audit meta tags, you have a blind spot. Run an external check at least once a quarter and after any theme update, plugin install, or page builder upgrade.

The free Royal Plugins Meta Tag Checker reads the live HTML of any URL and surfaces every meta tag organized by category: SEO, social, technical. It flags duplicates, broken values, and missing required tags. No signup. No usage limit.

For a deeper workflow that audits meta tags alongside schema, GEO score, and AI search readiness, SEObolt covers the rest of the SEO stack. Start with the free checker first to see what is on your page right now.

Pretty Links Pro costs $199/year. ThirstyAffiliates Pro runs $149/year. BetterLinks Pro is $79/year. They all gate the features you actually need behind a paywall: geo-targeting, A/B split testing, automatic keyword linking, QR codes, and device-based redirects.

What if all of that was free?

The WordPress Affiliate Link Plugin That Charges Nothing

Royal Links is a free affiliate link management plugin by Royal Plugins that includes every feature its competitors lock behind premium tiers. No “lite” version, no feature gates, no upsells. Version 2.0 shipped everything for $0.

Here’s what you get without paying a cent:

Geo-targeting redirects. Send visitors to different affiliate URLs based on their country. Amazon affiliates running multi-region programs can route US visitors to amazon.com and UK visitors to amazon.co.uk automatically.

A/B split testing. Test multiple destination URLs and track which converts best. Real conversion data instead of guessing which landing page works.

QR code generation. Create downloadable QR codes for any link with scan tracking built in. Print marketing, product packaging, business cards.

Automatic keyword linking. Define keywords and Royal Links auto-converts them into affiliate links across your content. Set max occurrences per keyword to keep it natural.

Device-based redirects. Route desktop, mobile, and tablet users to different destinations. Send mobile visitors to an app store while desktop visitors hit a landing page.

Time-based redirects. Schedule destination swaps automatically. Run a Black Friday deal from November 25 to December 1, then redirect to the regular page.

What Else Is Included

Beyond the headline features, Royal Links handles the day-to-day link management that affiliate marketers need:

Branded short URLs on your own domain. Clean links that build trust instead of ugly tracking URLs.

Click analytics with browser, device, OS, referrer, and country data. A dashboard widget shows period-over-period comparison at a glance.

Broken link checker that monitors your destinations and flags dead links before they cost you commissions.

FTC affiliate disclosure notices that display automatically. Stay compliant without manually adding disclaimers to every post.

Password-protected links for exclusive deals and gated content.

301, 302, and 307 redirects with nofollow, sponsored, and UGC attribute options.

Switching Is Easy

Already using Pretty Links, ThirstyAffiliates, or BetterLinks? The built-in migration wizard imports your links, categories, and click history in one click. Existing short URLs keep working.

No Catch

There is no premium tier. There is no paid upgrade path. Every feature listed above ships in the free plugin on WordPress.org.

More free WordPress tools at royalplugins.com.

Over 1,000 accessibility professionals have signed a statement condemning accessibility overlays. The FTC has fined overlay providers for deceptive practices. Lawsuits against sites using overlays have increased, not decreased. Yet overlay companies continue to sell the promise that a single line of JavaScript will make your site compliant.

It won’t. And if you’re using one, you might be making things worse.

What Overlays Actually Do Wrong

Traditional accessibility overlays reparse your entire DOM, inject AI-generated ARIA attributes, and interfere with screen readers. Users who rely on assistive technology have repeatedly documented how overlays break the tools they depend on. The overlay sits between the user and your content, creating conflicts instead of removing barriers.

The core problem is philosophical. Overlays try to fix your site from the outside by overriding what the browser renders. Real accessibility comes from building it into the page itself.

A WordPress Accessibility Plugin That Isn’t an Overlay

Royal Access takes the opposite approach. Built by Royal Plugins, it’s a free WordPress accessibility plugin that gives visitors a floating toolbar with 14 controls to customize their browsing experience. Font size scaling, high contrast modes, dark mode, a bundled dyslexia-friendly font (OpenDyslexic), spacing adjustments, a reading guide, big cursor, animation controls, and more.

The key difference: Royal Access applies CSS classes based on user preferences. It doesn’t reparse the DOM. It doesn’t inject automated ARIA. It doesn’t interfere with screen readers. It works WITH assistive technology instead of against it.

What Happens Automatically

Beyond the toolbar, Royal Access applies four code-level fixes server-side through WordPress hooks:

Skip-to-content link so keyboard users can bypass navigation.

Focus indicators with consistent outlines on all interactive elements.

Viewport zoom fix that removes restrictive user-scalable=no tags.

Screen reader context added to “Read more” links with the post title.

No user action needed. These fixes apply automatically on activation.

Built for Privacy

All user preferences are stored in localStorage. No cookies, no server calls, no external dependencies. The entire frontend weighs under 60KB. The OpenDyslexic font only loads when a visitor activates it.

The admin panel includes a WCAG contrast checker, an accessibility statement generator, and an 8-item checklist showing which features are active. Everything is free with no premium tier, no account required, and no SaaS subscription.

The Right Way Forward

No plugin makes a site fully WCAG compliant on its own. That requires manual auditing, semantic HTML, proper alt text, and ongoing effort. But a tool that helps visitors customize their experience while applying real code-level fixes is a meaningful step in the right direction.

Install Royal Access from the WordPress plugin directory. It takes about two minutes. More WordPress tools at royalplugins.com.

Most WordPress backup solutions share the same problem: they’re overcomplicated. Dozens of settings, confusing scheduling interfaces, storage configurations that require a sysadmin to decipher. By the time you’ve figured out the setup, you’re not even sure your backups would work when you actually need them.

That’s not a backup strategy. That’s a liability.

What a WordPress Backup Plugin Should Actually Do

A backup plugin has one job. Take a snapshot of your site, store it somewhere safe, and let you restore it fast when things go wrong. Plugin updates that break your site, hacked databases, hosting failures, accidental deletions. These happen. The question is whether you can recover in minutes or spend days rebuilding from scratch.

SiteVault is a free WordPress backup plugin by Royal Plugins that strips away the complexity. Install it, pick your cloud storage, set a schedule, and forget about it until you need it.

How SiteVault Keeps It Simple

The free lite version gives you 30 manual backups with no account required and no external dependencies. The Pro version ($49/year) unlocks automated scheduling and cloud storage.

Here’s what you get across both tiers:

Cloud storage to 5 providers. Google Drive, Dropbox, Amazon S3, OneDrive, and FTP/SFTP. Store backups in multiple locations for redundancy.

Incremental backups. Only changed files get backed up after the first full snapshot. This saves storage space and reduces server load on shared hosting.

AES-256 encryption. Every backup can be encrypted before it leaves your server. If someone gains access to your cloud storage, your data stays protected.

One-click restore with a 99.9% success rate. Average restore time is under 5 minutes. Selective restore lets you pull back specific files or database tables instead of restoring everything.

Built-in staging. Create a password-protected copy of your site to test updates, theme changes, or plugin installs before touching production.

Site migration. Moving to a new host or domain? SiteVault handles URL replacement and serialized data automatically.

The Number That Should Keep You Up at Night

60% of businesses that lose their data shut down within 6 months. Your hosting provider’s backup is a single point of failure. If their infrastructure goes down, your backup goes with it. SiteVault stores encrypted copies across independent cloud providers so you’re never one failure away from losing everything.

Getting Started

Install SiteVault from the WordPress plugin directory, connect your cloud storage, and run your first backup. The whole process takes about 5 minutes.

More backup and security tools are available at royalplugins.com.

The gap between AI assistants and your WordPress site just closed. With a WordPress MCP plugin installed, tools like Claude, ChatGPT, and Gemini can directly create posts, upload media, manage comments, update menus, and handle dozens of other tasks without you touching the dashboard.

It sounds powerful because it is. It’s also exactly the kind of access that demands serious security.

What a WordPress MCP Plugin Actually Does

Model Context Protocol (MCP) is an open standard that lets AI assistants interact with external tools and services. Instead of copying content between ChatGPT and your WordPress admin, MCP gives the AI structured access to your site’s functionality.

Royal MCP is a free plugin by Royal Plugins that brings this to WordPress with 37+ tools covering posts, pages, media, comments, users, categories, tags, menus, post meta, plugins, themes, and more. It works with Claude Desktop, Claude Code, ChatGPT, GPT-4o, Google Gemini, Groq, Ollama, and LM Studio.

For WooCommerce users, it adds 9 additional tools for managing products and orders. Version 1.4.3 currently has over 400 active installs.

Why Security Matters

Here’s the uncomfortable stat: 41% of public MCP servers have zero authentication. That means nearly half the MCP tools people connect their AI to have no security layer at all.

When you give an AI assistant the ability to publish posts, delete pages, or modify user roles on your site, authentication isn’t optional. It’s the baseline.

Royal MCP takes a security-first approach:

API key authentication on every single request. No exceptions.

OAuth 2.0 with PKCE for standardized, secure authorization flows.

Rate limiting at 60 requests per minute per IP to prevent abuse.

Full activity audit logging so you can see exactly what any AI assistant did and when.

Sensitive data filtering to keep private information out of AI responses.

These aren’t premium add-ons. They ship with the free plugin.

The Practical Side

The real value shows up in daily workflows. Ask Claude to draft and publish a blog post. Have ChatGPT audit your categories and suggest a cleaner taxonomy. Let Gemini generate alt text for your media library. All without switching tabs or navigating menus.

Plugin integrations with WooCommerce, GuardPress, and SiteVault extend the toolset further. The plugin follows the MCP 2025-03-26 specification, so it stays compatible as the protocol evolves.

Getting Started

Install Royal MCP from the WordPress plugin directory, generate your API key, and connect your preferred AI assistant. The entire setup takes a few minutes.

If you’re exploring what AI can do for your WordPress workflow, Royal Plugins builds tools designed to make that connection secure and practical from day one.

Sites with strong Google rankings — page one, good backlinks, solid DA — are getting completely ignored by AI search engines. ChatGPT doesn’t cite them. Perplexity doesn’t pull from them. Google’s own AI Overviews synthesize answers from other sources entirely.

Meanwhile, some random page with half the backlinks and a fraction of the domain authority keeps showing up in every AI-generated answer.

What’s going on?

AI search engines rank content differently than Google’s crawler. They don’t care about your Domain Authority. They don’t check your backlink profile. They’re evaluating something else entirely — and the SEO industry is only now figuring out what that is.

It’s called Generative Engine Optimization — GEO — and it comes from actual peer-reviewed research (Princeton, IIT Delhi, published at ACM KDD 2024). Not marketing fluff. Real experiments measuring what makes AI engines cite one source over another.

The findings are wild.

The biggest factor is evidence density. Pages with specific statistics, named sources, and inline citations get cited dramatically more than pages with generic advice. The research found that adding direct quotations from authoritative sources improved AI citation visibility by roughly 43%. Adding statistics? About 32%.

Compare these two sentences:

“Experts recommend updating your plugins regularly.” — AI skips this.

“Patchstack reported 333 new plugin vulnerabilities in a single week in January 2026.” — AI cites this.

Same topic. Same general advice. But one gives the AI something concrete to reference, and the other gives it nothing.

The second factor is freshness. AI models prefer current information, and they’re surprisingly good at sniffing out stale content. If your “2026 guide” still has 2024 data in it, the model quietly moves on to something more recent. Your rankings don’t drop — you just don’t get cited.

The third is structure. AI engines favor answer-first formatting. If your page makes someone scroll past three paragraphs of context before reaching the actual answer, the model skips to a competitor who leads with it.

Here’s the uncomfortable part: you can score a 92/100 on traditional SEO and score a 34/100 on GEO. That means you’re perfectly optimized for a search paradigm that’s shrinking, and invisible to the one that’s growing.

I wrote a full breakdown of how GEO scoring works, why the gap between your SEO score and GEO score matters, and what the triple threat scoring model looks like in practice. It’s the most thorough piece I’ve done on this topic:

Your SEO Score Doesn’t Matter Anymore (And What Replaced It)

If you manage any kind of content strategy — blog, SaaS, e-commerce, agency — this is the blind spot you didn’t know you had. The people who figure it out early will own the AI citations for their industry. Everyone else will keep optimizing for Google’s crawler and wondering why their traffic is declining despite solid rankings.

The research is clear. The tools exist. The only question is how long you wait.

See you next week.

So I decided to pull the 50 most popular WordPress plugins by active installations — we’re talking Elementor, Yoast, WooCommerce, Jetpack, the household names — and audit them for bloat, outdated PHP support, known vulnerabilities, and maintenance activity.

What I found wasn’t great.

The Bloat Problem: Your Plugins Are Heavier Than Your Theme

Let’s start with file sizes. When you install a plugin, that entire ZIP gets unpacked into your wp-content folder. Every file gets loaded, parsed, and executed on every page request (unless the developer was careful about conditional loading — and most aren’t).

Here are the 5 heaviest plugins in the top 50:

Jetpack — 3M+ installs — 25.0 MB
MonsterInsights — 2M+ installs — 23.7 MB
Elementor — 10M+ installs — 18.4 MB
WooCommerce — 7M+ installs — 18.4 MB
OptinMonster — 1M+ installs — 12.4 MB

Jetpack ships at 25 megabytes. For context, the entire WordPress core is about 20 MB. You’re installing a plugin that’s larger than WordPress itself.

Now compare that to plugins that actually respect your server:

Classic Widgets — 2M+ installs — 9 KB
Classic Editor — 9M+ installs — 38 KB
WPS Hide Login — 2M+ installs — 50 KB
Akismet — 6M+ installs — 117 KB
Yoast Duplicate Post — 4M+ installs — 118 KB

Classic Widgets does its job in 9 kilobytes. That’s 2,778 times smaller than Jetpack. Both have millions of users. One of them isn’t slowing down anyone’s site.

The bloat isn’t just about disk space — it’s about execution time. More files means more autoloading, more database queries, more memory consumption. Stack five bloated plugins together and you’ve added 500ms+ to every page load before your content even renders.

The PHP Problem: Running 2006 Code in 2026

PHP 7.2 reached end-of-life in November 2020. PHP 7.4 hit EOL in November 2022. These versions no longer receive security patches. Running them is like leaving your front door unlocked and hoping nobody walks by.

So how many of the top 50 plugins still support these dead PHP versions?

PHP 5.2.4 — 2 plugins — EOL since 2011
PHP 5.3 — 1 plugin — EOL since 2014
PHP 5.5 — 1 plugin — EOL since 2016
PHP 5.6 — 4 plugins — EOL since 2018
PHP 7.0 — 4 plugins — EOL since 2019
PHP 7.2 — 8 plugins — EOL since 2020
PHP 7.4 — 23 plugins — EOL since 2022
PHP 8.1+ — 1 plugin — Currently supported
Not specified — 5 plugins

Read that again. Two plugins in the top 50 still officially support PHP 5.2.4 — a version released in 2006. One of them is File Manager, which has over 1 million active installations and hasn’t been updated since June 2025.

Only one plugin out of fifty requires PHP 8.1 or higher. One.

When a plugin supports PHP 5.x, it means the codebase is either ancient and untouched, or actively maintained with backward-compatible code that can’t take advantage of modern PHP security features like typed properties, enums, readonly classes, or fibers. Either way, you’re running legacy code on your production server.

And here’s the kicker: roughly 30% of WordPress sites in the wild are still running PHP 7.x. The plugins enable the bad behavior, and the bad behavior enables the plugins. It’s a cycle nobody wants to break because updating means losing users.

The Vulnerability Epidemic: 5 Hours to Exploitation

The numbers from Patchstack’s 2026 security report are genuinely alarming:

• 11,334 new WordPress vulnerabilities in 2025 (up 42% from 2024)

• 57% are exploitable by unauthenticated visitors — no login required

• Median time to first exploit: 5 hours after public disclosure

• 46% of vulnerabilities had no patch available when they were publicly disclosed

That last stat is worth sitting with. Nearly half of all disclosed WordPress plugin vulnerabilities had no fix available when they went public. That means attackers knew about the flaw, security researchers knew about the flaw, and the plugin developer either didn’t know or hadn’t shipped a fix yet. Your site was exposed with no option to protect it.

Here are real examples from the top installed plugins:

Really Simple Security (3,000,000+ installs)

CVE-2024-10924 — CVSS 9.8 (Critical) An authentication bypass that let anyone gain admin access without credentials. Wordfence called it “one of the most serious vulnerabilities we’ve reported in our 12-year history.” The irony of a security plugin having a critical security flaw wasn’t lost on anyone.

LiteSpeed Cache (7,000,000+ installs)

CVE-2025-12450 — High Severity A stored XSS vulnerability affecting all versions up to 7.5.0.1. Before that, a separate privilege escalation bug gave unauthenticated attackers full admin access. Seven million sites.

Post SMTP (400,000+ installs)

CVE-2025-11833 — CVSS 9.8 (Critical) Unauthenticated account takeover through password reset email interception. An attacker could take over any account on your site without knowing a single password.

These aren’t obscure plugins from unknown developers. These are tools installed on millions of sites, built by well-funded teams, and they still shipped critical vulnerabilities.

The Abandonment Crisis: 59% Left to Rot

This might be the scariest finding of all.

According to recent analysis, 59% of WordPress plugins — over 34,000 — have not been updated in more than two years. They’re effectively abandoned. No security patches. No compatibility updates. No one at the wheel.

Among those:

• 232 plugins with 10,000 to 999,000 active installations are abandoned

• 1,614 plugins were removed from WordPress.org in 2025 after developers couldn’t be contacted

• 150+ plugins were pulled in December 2025 alone due to unpatched security issues

WordPress.org shows “last updated” dates on every plugin page, but how many site owners actually check? You install a plugin, it works, you forget about it. Two years later, it’s a backdoor.

In our audit, the most concerning example was File Manager — over 1 million active installs, requires PHP 5.2.4, and last updated in June 2025. It gives users a full file browser inside WordPress admin. If that plugin has an unpatched vulnerability, an attacker has direct access to every file on your server.

What Should You Actually Do?

I’m not saying uninstall everything and hand-code your site. Plugins are the reason WordPress powers 40%+ of the web. But you should audit what you’re running:

1. Check the ZIP size. If a plugin is 10+ MB, ask yourself: does this feature really need that much code? Often the answer is no — and there’s a leaner alternative.

2. Check the PHP requirement. If it says PHP 5.x or even 7.0, that’s a red flag. The codebase is either ancient or deliberately holding back.

3. Check the last update date. Anything older than 6 months should be investigated. Anything older than a year should probably be replaced.

4. Check for known CVEs. Sites like Patchstack and WPScan maintain free vulnerability databases. Search your plugins before you install them.

5. Count your plugins. The average WordPress site runs 20-30 plugins. Every one is an attack surface. If you can consolidate or remove, do it.

At Royal Plugins, this is exactly why we built our suite the way we did. Every plugin requires PHP 8.0+ minimum — no legacy baggage. Every release goes through multi-engine security scanning before it ships. And we keep our plugins lean: SEObolt handles technical SEO without the 5+ MB overhead of the big SEO plugins.

We believe a WordPress plugin should do one job exceptionally well, in as little code as possible, on a modern stack. That’s it.

The Bottom Line

Your WordPress site’s security is only as strong as your weakest plugin. And right now, the ecosystem is shipping 36 new vulnerabilities per day, half of them without patches, on codebases that still support PHP versions from the Bush administration.

Audit your plugins. Check the data. And be a lot more selective about what you let run on your server.

Data sources: WordPress.org Plugin API, Patchstack State of WordPress Security 2026, WPScan Vulnerability Database, Wordfence Threat Intelligence. All data verified as of March 2026.

Royal Plugins builds lightweight, security-first WordPress plugins. Visit royalplugins.com to see our approach.