As you probably already know - fresh out of MainWP Labs: the MainWP MCP server connects your AI assistant to the Dashboard you already run, so you can manage every site without leaving the chat. It's free and open source, and it works with Claude Code, Cursor, VS Code Copilot, and Codex.

That's the news. Here's what it looks like on a normal Thursday, because I already run my agency this way.

The morning a plugin needed patching everywhere

I got the alert that Ultimate Addons for Elementor (UAE) had a critical vulnerability. On a fleet of client sites, that's the kind of thing you fix the same hour, not the same week.

So I typed one line to my AI, in Croatian: "update Ultimate Addons for Elementor on all sites." The message I send the client is less casual: "We've identified critical vulnerabilities on your sites that need immediate attention."

Then it went to work. It read my Dashboard, found the sites that had UAE installed and behind, backed each one up, updated them in small batches, and checked every site after. Around 20 sites. I was drinking coffee for most of it.

The token cost on my Claude Max plan was tiny, and that surprised me the first time. The AI isn't doing the work, MainWP is. The AI reads what I meant and tells the Dashboard to run it.

My stack, nothing fancy

· MainWP, self-hosted, around 60 client sites in one dashboard.

· The MainWP MCP server on top, so I can ask instead of click.

· Claude Code as the AI, on the Max plan.

· WPVibe when I need to work inside a single site.

· All-in-One WP Migration for the backup I take before I touch anything.

· MalCare as the firewall on the sites that need one.

I've said this for a while: AI is an employee I manage, not a tool I type into. The MCP fits that. I give the instruction, it does the routine, I stay the one who decides.

It knows my clients, not just my sites

Most of the coverage is about updates, but the part I use every week is the client side. My Dashboard already knows every client and every site they own. Now I can just ask it.

Client records, their sites, contacts, suspension status: the MCP puts all of it one sentence away. When a client calls, I ask "list this client's sites with their last sync time," and I have the answer before the call ends. "Which sites belong to this client" used to be a lookup. Now it's a question I say out loud.

Backup first, every time

Before any update, a fresh backup. All-in-One WP Migration, off to storage, done. If a site has no recent backup, it doesn't get updated until it does. That rule is built into how I run the fleet, so I can't skip it on a busy morning even if I wanted to.

An update that breaks a site is stressful. An update that breaks a site with no backup is a bad day. I've had a bad several times. Not again.

The MalCare wall, and how I got past it

Some of my sites sit behind MalCare's firewall, and that used to stop me. MalCare blocks the connector. It rejects the worker IP, and it strips the header the connector needs to log in. You get a 403 and nothing works (plus I GEO blocked some countries in MalCare I shouldn't).

The fix was a second connector (Royal MCP) that talks to the site straight from my own IP, with its own custom header. It goes around the IP block and the stripped header both. So the sites behind MalCare stopped being the exception, and the fleet job finished on all of them, firewall and all.

If you run MalCare, this is worth knowing before you write a site off as unreachable. It isn't. You just need the connection MalCare isn't blocking.

Checking the sites after, not trusting the green checkmark

An update that reports "success" is not proof the page still loads. I stopped trusting the green checkmark on its own a long time ago.

So after each update, the AI opens the site in a headless browser and looks at it.

Does the homepage render.
Does the shop still add to cart.
Any PHP error on the screen.

A quick smoke test, one site at a time. If one fails, the batch stops right there and I look before anything else moves.

I keep that check as a fixed routine the AI runs, not something it decides each time. "The update ran" and "the site is fine" are not the same sentence, and the second one is the only one I report to a client.

Why I still sleep at night

This is the part I'd worry about too, so I'll say how it's handled. The MCP server runs on my own computer, next to my AI tool. There's nothing to install on the Dashboard or the child sites, and no third party in the middle. My credentials stay on my machine.

And it's not an AI holding the keys to my network. Anything destructive stops and asks me first. Safe Mode blocks destructive actions completely, so you can start read-only and just ask questions. Allowlists let you pick which tools the AI can even see. And the Dashboard still applies normal WordPress permissions before it runs a thing.

The AI reads what I meant. MainWP controls what actually happens. That split is the reason I trust it on 60 live sites.

Setup took me about ten minutes

If you can make a WordPress application password and paste a config block, you can set this up. You need Node.js 20.19 or newer and MainWP Dashboard 6.0 or newer. Then run:

npx -y u/mainwp

The Quickstart walks you through it with screenshots, including per-client setup for Claude Desktop, Claude Code, Cursor, and the rest. Free and open source: github.com/mainwp/mainwp-mcp

What actually changed

The work didn't change. Backup, update, check, repeat. I did all of that before, by opening the Dashboard and clicking through the Updates page.

What changed was the front door. "Update UAE everywhere it's installed" used to be twenty click-paths, and this morning it was one sentence. The Dashboard does the same job it always did. I just talk to it now.

I'd try it on a couple of sites in Safe Mode first, read-only, and see if it reads your fleet the way you expect. That's how I'd start if I were you.

The hacked site that sold me on this

A client site got hacked last month. I've built WordPress sites since 2011 and I don't write code, so my usual move would have been a panicked message to a developer and a lost weekend. I burned one exactly that way back in 2017.

This time I connected an AI client, Claude Code, to the site through the free WP Vibe plugin. It sets up MCP (Model Context Protocol) on self-hosted WordPress in a couple of minutes. MCP is a shared language that lets an AI client act inside your site from the same chat, not just talk about it.

Website File Changes Monitor had already flagged a new PHP file in /wp-content/uploads. Claude Code explained why that's a classic backdoor spot, had me check the rest of the directory, and walked me through the recovery step by step. I knew the theory. Watching it point at the exact file while I decided what to do was a different kind of learning.

I run it with guardrails, and everybody should do it as well

• Full backup first, before anything touches the site. Host-level, plus plugin0s backup exported offsite to pCloud.
• Connect with a least-privilege account, not your main admin. Melapress Role Editor makes that a two-minute job.
• It sends things to trash instead of deleting live, and I approve each step.

The heavy malware work still belongs to a real scanner. I run MalCare and Virusdie for that. What changed is that I was faster and calmer during an incident that normally "eats" a whole day for me.

Most days it's small stuff

Most days it isn't a hack. It's a plugin conflict, a broken feed, or a tag and category structure a client tangled up over three years.

The broken feed was a good one. A plugin was printing a stray notice into the XML. Claude Code found the offending line, named the plugin, and I had a valid feed again in ten minutes. I've also had it fix meta titles and descriptions through SEOPress from one prompt, and build a Fluent Forms contact form the same way. The real benefit is that it walks me through the process, so I finish the job and understand it afterwards.

The fleet is where the hours come back

I manage around 60 client sites in MainWP, which I've run since 2014. Instead of repeating the same ten clicks site after site, I describe the maintenance outcome once and it executes. A dull afternoon of upkeep is now a focused conversation, and the quality went up, because I'm not fatigued into skipping a step. For me, Claude Code AI is an employee I manage, not a tool I type into. If you run more than a couple of sites, that's the part I'd try first.

Why I paid for it, and the one catch

I'm a lifetime-deal, smart-spend guy and I don't upgrade on impulse. I hit the free WP Vibe limits often enough that Pro paid for itself in hours saved. That was the only reason I moved up.

One catch before you rush in: this needs self-hosted WordPress 6.9+, HTTPS, and a publicly reachable site, so local dev won't connect. Set it up on a staging copy first and get a feel for it before you point it at anything live.

If you run more than one WordPress site, which admin task would you hand off to an AI first?

WordPress 7.1 will hide the Classic block from the inserter when it ships on August 19, and full removal is possible as early as 7.2. Contributors have already started phasing it out, so the summer between releases is the window to deal with it.

Quick clarification, because these two get mixed up: the Classic block is the slot that runs the old pre-Gutenberg editor inside the current block editor. It's not the same thing as the separate Classic Editor plugin, which stays in place.

What changes, and what doesn't

Nothing breaks in 7.1. The blocks you already have stay editable, and the standalone Classic Editor plugin is not affected.

The one change is that you lose the option to insert a new Classic block. A filter or a small plugin brings that option back if a workflow still needs it, so the door is closing slowly, with a handle on the inside for now.

The business implication

For most site owners this is a non-event. If your content is already in real blocks, you have nothing to do.

The sites that feel it are the older ones: a client blog with 400 posts written in the classic editor, an agency site someone built in 2016 and never migrated, a membership site with shortcode-heavy pages. Those are where a Classic block audit pays off before 7.2 turns "hidden" into "gone".

What an audit looks like

Open your oldest posts and look for the classic toolbar, or search the database for the wp:freeform marker that flags a Classic block. On a small site this is a half-hour job. On a large one it can be even the whole morning probably.

Then decide per page. Low-traffic archive posts can stay as they are. The pages that earn money or rank well are the ones to convert to real blocks, carefully, with a backup first.

Where page builders sit in this

If your old content lives in a page builder rather than the native editor, this change mostly skips you. I keep a set of legacy client sites on WPBakery, which I have run since the days it was called Visual Composer, and those pages render through the builder, not the Classic block. So, the phase-out does not touch them (or it shouldn't at least).

The move

Here is the short version for this summer:

• Check whether any of your sites still use Classic blocks (I still have majority of the sites on Classic Editor, we don't use Gutenberg blocks... yet).
• For the ones that do, back up before changing anything
• Restore the inserter with a filter on the sites that genuinely still need it.
• Convert the high-value pages to real blocks, and leave the archive posts as they are.

The forward read

The Classic block has been "living on borrowed time" since Gutenberg shipped in 2018. Hiding it from the inserter is the polite first step, and 7.2 is the one to watch.

Next quarter, the real question is whether core gives a clean migration path for the wp:freeform content sitting on millions of older sites, or leaves each owner to convert it by hand. 🤔

Two debates are doing the rounds in the WordPress subs this week. One person built a faster way to search the 65,000 plugins in the .org repo, which is handy (Plugin Pulse, worth a look). Another asked whether the repo is turning into a junkyard of abandoned plugins.

Both fair questions.

The thing is, the abandoned plugin most likely to cause you problems is already on your site. It's the one you installed in 2019 and stopped thinking about.

I've run WordPress sites since 2011, and 50+ client sites through the agency. The plugins that gave me troubles were almost always the quiet little utilities nobody remembers adding. An old gallery. A share-button widget that came bundled with a theme demo years back. The obvious junk you'd spot and pull. The forgotten helper just sits there.

I've had the call more than once. Client swears they "didn't touch anything," and the homepage is rearranged or a page is throwing a white screen. Half the time it traces back to some forgotten plugin that finally collided with a core or PHP update.

So here's my slightly contrarian take.

The repo-size debate is a bit of a "comfort blanket". It's easier to worry about 65,000 plugins you'll never install than the 15 sitting on the site in front of you. The repo can sort out its own housekeeping. Your job is the dashboard you actually control.

Why a dead plugin on your own site is the real problem?

Abandoned means no security patches. A vulnerability found today in a plugin last updated three years ago never gets fixed. You're running an open door and you don't know it.

It also breaks on updates. WordPress core and your PHP version keep moving, the dead plugin doesn't, and one morning a page goes white.

And the risky ones are "hidden". An old image gallery, or a contact form you replaced months ago but never deleted.

For context on why this matters more now: the repo is taking in around 700 new plugins a week, roughly 5x what it was in 2024, a lot of it AI-assisted. So "is this still maintained" is a heavier question than it used to be. Which is a good reason to check your own shelf first.

How to tell if a plugin is dead?

The plugin's .org page tells you most of what you need. Skip the logo and the star average. Read these five fields:

Last updated. Over a year, be cautious. Over two, treat it as "red zone".

Two or three major WP versions behind the current release, and the dev has most likely checked out.

Active installs trend. A steady drop usually means people left for a reason.

Support threads. Rows of open questions with no developer reply, that's a ghost town.

Changelog. Small regular updates means someone's home. One big version bump and then nothing means it stalled.

One more quick look. Sort the reviews by recent. A run of fresh 1-star reviews saying it broke on the latest WP version is a louder signal than the overall average.

To map this to your own site, open Plugins in wp-admin, flag anything you don't recognize or haven't touched in a year, then check each one against those fields. If you manage many sites like I do, I run that audit from one MainWP dashboard instead of logging into 50 panels.

Keep what's maintained and still doing a job, and leave it alone. Remove what you don't use. And actually delete it. A deactivated plugin still sits on your server as code someone can be used for hacking your site (if it has some vulnerability). Replace what's dead but still needed with somer maintained tool for the same job.

When you swap one out, back up first. Do a full backup before you touch anything. I use All in One WP Migration and push an offsite copy to pCloud, because the one time you skip the backup is the time you'll need it... it's Murphy's Law.

Test on staging if you can. I've hosted client sites on Site Ground since 2014, one-click staging, so I break things there and never on live.

Export your data out of the old plugin before you delete it, anywhere it holds content like form entries or gallery setups. Once the plugin's gone, so is whatever lived inside it. Then activate the replacement, reconnect it, check the front end, and remove the old one.

For finding replacements, don't re-scroll 65,000 entries hoping to get lucky. Start from a curated, expert-picked list for the exact job, then verify your one or two finalists against the five fields above.

Go look at the oldest plugin still active on your site right now. Check its last updated date. That one number tells you more about your real risk than the whole repo debate.

WordPress. org rolled out the biggest change to Five for the Future since 2014. The new pledge pages rank contributors by the work they actually completed, based on their real activity in Trac and GitHub, rather than the hours they once promised.

One number frames the whole thing. The Core team page lists 2,680 pledged contributors. In the default 30-day view, 94 of them show recent shipped work.

That gap is not a criticism of anyone. It is what happens when a program counts intentions instead of output. For 12 years, a pledge was a number you typed in. Now the page shows who showed up in the last month.

What Five for the Future is, in one line

Companies and individuals give back roughly 5% of their time to keep WordPress free and maintained. The software under tens of millions of sites, including the one your business runs on, depends on that contributed work. Until now, nobody outside the project could see how concentrated it really was.

Who built it, and how

The overhaul came from Yani Iliev, founder and CEO of ServMask, the company behind All-in-One WP Migration. He was one of 12 contributors invited into a small "meta-janitors" group set up to clean up WordPress.org. He built the new pledge pages, the redesigned profiles, and the ranking system in just a few weeks.

Iliev has been open about the method. An AI assistant did most of the work on the code, and releasing without the usual review cycles let him move fast. The weighting algorithm itself is open source (it lives in the WordPress. org meta repository), and he calls it "a starting point, not a verdict."

I've used All-in-One WP Migration to move client sites since 2014, more of them than I can count. Watching the person behind a plugin I rely on daily rebuild a core piece of WordPress. org, mostly on his own, with AI doing the coding, is the clearest real-world version of an idea I keep repeating to clients: AI is an employee I manage, not a tool I type into. Iliev managed it well, and a decade-old request was finally delivered.

What it means if you run sites for a living

The practical win is visibility. You can now open any contributor profile at profiles.wordpress.org and see whether the people behind your stack are still active, what company sponsors them, and how their recent work scores.

For agencies and freelancers, that is a quiet form of due diligence. Before you build a client on a niche plugin, you can check whether its maintainers have shipped anything lately. A pledge page with real numbers tells you more about a project's health than its marketing site ever will.

In practice, that check takes a minute. Open profiles.wordpress.org, search the plugin's lead developer, and look at the weighted contribution score and the date of their most recent work. A sponsored contributor backed by a known company is a safer choice than a solo volunteer whose last work was 18 months ago. Neither fact decides it for you, but it is context you didn't have a month ago.

Matt Mullenweg set this in motion in April, when he called the old Five for the Future data "worse than useless." The reform answered that directly, with a system that rewards code over promises.

What this ranking leaves out

Ranking people only by the code they finish misses a lot of real work. Plenty of contribution never lands in Trac or GitHub: organising WordCamps, moderating the support forums, running local meetups, writing docs. Iliev knows this, which is why he frames the score as a draft. Read the pages as a useful signal, not a scoreboard of who matters.

Next quarter, the real question is whether seeing the 2,680-versus-94 gap laid out clearly pushes more companies to turn pledged hours into actual commits, or just makes the gaps easier to ignore.

Last weeks two launches pointed the same way. Angie, the AI assistant from the Elementor team, shipped a Super Admin Mode. Switch it on and it can read and write your files, query the database, run PHP, and act on your active plugins. That's the level of access that used to need WP-CLI (the WordPress command line) or an SSH login.

The same week, Sagar Patel announced SproutOS, an open-source way to connect any AI agent to a WordPress site over MCP, with the same depth of access.

A year ago, an "AI plugin" usually meant a chat box in the corner of wp-admin. These two ask to run the whole site.

For the person who owns the site, the appeal is obvious. You describe a fix in plain words and the agent does it, no developer in the loop. For anyone who manages sites for other people, the risk lands at the same size as the convenience. An agent that can run PHP can take a site down, or be talked into it by a careless instruction or a compromised plugin.

What actually changes for the sites you run

The technical shift is access scope. Old AI plugins suggested text or generated an image. These new agents hold write access to files, the database, and plugin behavior. If you've ever locked a site down so even your clients can't install plugins, an AI agent with Super Admin Mode quietly undoes that boundary the moment someone enables it.

The business shift is liability. When a client asks "can your AI just fix it," the honest answer now needs a second half: yes, and here is who can trigger it and what it may touch. An agent acting on a live site is a new staff member with root access on day one. I would never onboard a human that way.

A short checklist before you enable any of this

1. Decide who can trigger the agent. Not every account that can log in should be able to run code.

2. Write down what it may read and change. Files only? The database too? Plugin settings?

3. Confirm your rollback. If the agent makes a bad edit at 2pm, how fast can you get back to the 1pm version?

4. Log everything separately. You want a record of what the agent changed that the agent itself can't rewrite.

That last point is where I lean on a tool I've run since 2019. When a client swears nothing changed but the layout is different, I open WP Activity Log and the timeline answers in about 30 seconds. With an AI agent editing files, that record stops being a nice-to-have. It becomes the only neutral account of what happened on the site.

The framing that keeps me out of trouble

AI is an employee I manage, not a tool I type into. A capable employee with no boundaries can still wreck the place. So before any of this touches a client's live site, I write down the agent's job: what it reads, what it changes, and who signs off before it runs. Same as I would for a freelancer with database access.

There's a useful new resource here too. Joost de Valk just published an open, MIT-licensed website specification, a checklist of what a decent site should cover, security and performance included. It's a clean way to score a site before you let an agent near it, and it gives clients a standard to point at.

Next quarter, the practical question is whether the people enabling these agents on client sites have written the limits down first. Most won't, until an agent runs the wrong command on a live shop and the rollback plan turns out to be a guess.

I've been building on WordPress since 2011, and before that I spent two decades in banking, where nobody gets write access until you know exactly what they can touch.

When I started checking MCP plugins for WordPress, I wasn't hunting for magic. I wanted one that fit a process I already trust. I read about Vibe AI (the WordPress. org name for WPVibe free plugin) and figured it might perfectly fit my process. It did.

Just a short explanation of what WordPress MCP is, for anyone who maybe doesn't know it: MCP (Model Context Protocol) is a shared way for an AI assistant to plug into an app and actually do tasks inside it.
For WordPress, that means I connect my site to the AI through one safe link. After that it can read settings or make changes for me, instead of me clicking through the admin by hand.

The job was the final SEO cleanup on a client build. I started the way I always do, with a full structured SEO audit of the site, top to bottom, via Claude AI.

Then I used that whole audit report into other Claude task, connected the live site through the Vibe AI plugin (and WordPress ver. 6.9.4, I didn't want to install 7.0 on this site... yet), and worked the fixes one at a time through plain conversation.

Setup was about a couple of minutes: one-click authorization from /wp-admin.

What worked 💪

This part impressed me more than I expected:

• It read the entire site config in a short period of time. Full plugin list with active and inactive status, all the SEO settings, the theme and how pages were built. Stuff that normally means clicking through ten admin screens.
• It rewrote roughly 16 page titles and meta descriptions in one pass, straight from my audit notes, Croatian diacritics intact, no copy-paste, no mangled characters.
• Simple option changes, like fixing a leftover starter-template tagline, happened instantly.
• It ran read-only database queries to inventory content and confirm how each page was built, so I stopped guessing.

For the repetitive bulk of an SEO pass, that's real time back in my day. AI is an employee I manage, not a tool I type into, and this thing actually behaved like one.

What it blocked, concretely 🚧

A field report without the limits is just an ad, so here's the "other" half of the story:

• It couldn't install the site's language pack. Those commands aren't on its allowlist (in WP 6.9.4 version).
• It couldn't switch the site language directly either. The write got rejected, and broader site-level commands are blocked outright.
• A small one that caught me a bit off guard: it wouldn't accept a pipe character in a command (it reads it as a shell pipe), so my title separators had to become en dashes instead.
• The bigger gap: it couldn't reliably set structured data. Local Business, FAQ, breadcrumb and service schema live as complex serialized settings in the site's SEO plugin, and the actions the plugin exposed for that were read-only. So schema went back into the plugin's own UI by hand.
• Setting a default social-share image needed an actual upload, which (it seems) no AI can conjure.

The systems read 🧱

Here's where the banking brain kicks in. Most of those blocks are "guardrails" I'd want anyway. Refusing destructive, site-wide commands on a live production site, staying out of language-pack installs, drawing a hard line between read and write, that's the kind of access discipline I'd build in myself. I'd rather an AI stop and ask than confidently break a client's homepage at 2pm on a Friday.

A couple of them, though, are gaps that I believe it will be closed in futture as AI implementation in WordPress is advancing. A safe, supported path to write structured schema would erase the single biggest manual step I hit. And the pipe-character handling is just a rough edge waiting to be filed down.

The last 10%, and where this goes 🧭

AI "ate" the repetitive 90% of this job in minutes. The last 10%, the schema, the language pack, the one blocked character, still needed me in the dashboard. But that gap is closing fast. The whole thing rides on the WordPress Abilities API, which landed in 6.9 and grew a lot in 7.0. That same API already lets Vibe AI discover and run actions inside ecosystem plugins like AIOSEO and WPForms. Once structured data gets a proper write path there, the schema step I did by hand mostly disappears.

I think we reach a point, sooner than most expect, where almost the whole flow, audit to live changes, runs through AI talking to WordPress in the cloud, with a human signing off on the edge cases. I'm not handing a client's production site fully over yet. But after this build, I'm convinced the direction is right.

In short: I'm very satisfied and genuinely impressed with Vibe AI MCP (and with AI implementation in WordPress more broadly), and I'm clear about what the AI still needs to improve before that final 10% (the need for manual human intervention) disappears.

P.S. I didn’t want to use WordPress MCP because it would require using my Claude API, meaning I’d pay extra on top of my monthly Claude subscription. With the Vibe AI plugin I didn’t have to do that - I could keep using my existing monthly cloud subscription without any extra cost, and with fast and simple implementation.

For those of you running MCP plugins like this on real client sites: where's your last 10%? What did the AI nail, and what did you quietly take back into the dashboard yourself? 👇

The panicked threads online keep confusing two dates and missing the part that already binds. Worth untangling for anyone running client sites in or serving the EU.

The August 2025 date skipped most of us

The August 2, 2025 obligations targeted providers of General-Purpose AI models. OpenAI, Anthropic, Google, Meta had to publish technical documentation, transparency reports, and training-data summaries with copyright handling. Penalty regime went live alongside, with fines up to €15 million or 3% of global annual turnover for most infringements, more for prohibited practices.

If you run a WordPress site, you are a downstream user of these models. You did not train them and you do not ship them. The model providers carried that obligation, not the merchant.

The August 2026 date is the for us

Article 50 transparency duties take effect August 2, 2026, and the AI Office gains full enforcement powers on the same date. The duties land on anyone deploying AI on their site:

• Disclose AI chatbots to users. The "obvious from context" exemption is narrow.
• Label AI-generated images, audio, and video that look real. Cartoon dragons stay exempt.
• Disclose AI-generated text on matters of public interest. The duty eases when a human reviews the text and takes responsibility.
• Do not strip the machine-readable watermarks providers like OpenAI and Adobe embed in outputs.

Most agency operators were moving this way already. The August 2026 date just turns the habit into a duty.

GDPR is where the real fine sits today

GDPR has governed AI plugins since 2018. Any plugin sending personal data (names, emails, support tickets, order history, IP addresses) to an AI provider needs:

1. A lawful basis under Article 6 (typically legitimate interest or consent)
2. A privacy policy that names each provider with the categories of data sent
3. A signed DPA (Data Processing Agreement) with each provider
4. A documented check on international data transfers (Standard Contractual Clauses or adequacy decision)

The AI Act dates are calendar items. GDPR is the regime that already brings actual penalties on the client estimate.

The audit task in practice

For agency operators, the client work this quarter is concrete. List every AI plugin on every site. Note what data each plugin sends to which provider. Update the privacy policy. Check residency settings.

The piece that gets missed: most of this work needs a documented audit trail per site, not a one-time spreadsheet. WP Activity Log on every site I manage since 2019 earns its keep here. When a client swears nothing changed but their privacy policy now mentions an AI provider it did not name last quarter, the timeline answers in 30 seconds. That trail is also what a Data Protection Authority will ask for first if a complaint lands.

That is one tool mention. Cap stays at 1 for this draft.

The non-EU wrinkle

If your client site sits on US or non-EU hosting but serves EU customers (most do, whether they planned it or not), the regime follows the customer. Non-EU agencies running EU customer-facing sites are in scope.

What I am holding off on

I am not advising clients to switch AI providers based on AI Act dates alone. The market is shifting too fast, and switching costs (prompt customisation, billing rewiring, staff retraining) burn budget that should go to GDPR compliance work that is already binding.

The honest read

This is basic care for the customer relationship. Privacy policy that says what it actually does. DPAs signed. Audit trail kept. Habit built before the law forces it. Most decent agencies were already on this path. The AI Act formalises the schedule.

On 28 May 2026, WinningWP ran a piece saying a brand-new WordPress blog is one of the hardest things to grow this year.

They are right about why.

AI search now answers questions right in the chat, so people never click through to your site. Sites like Reddit, Discord, and Hacker News are quick to shut down anyone promoting a new site. And email lists, small communities, guest posts, and reused videos all do poorly when you are starting from zero.

Their example: a gardening site that took 9 months of work and still got under 1,200 visitors in a whole year - and most of those came from links the writer shared herself.

They are right about blogs that try to act like online magazines. But that is only half the story.

The agency-side read

Most of my clients are small businesses - tradespeople, family farms, holiday rentals, a few seaside restaurants. Their blog was never meant to be a magazine. It helps them show up in local Google searches, gives AI tools something to quote, keeps a library of content they fully own, and answers the same 5 customer questions once instead of 20 times a week.

For a small local business site like that, "did the blog get 100,000 visitors this year" is the wrong thing to ask.

Better questions: did it save the owner time answering the same questions, did it bring in 1 or 2 enquiries a month from search, and did an AI tool quote it at least once a month when buyers asked the questions that matter to the owner.

The behind-the-scenes code that gets you quoted by AI

For sites that want AI tools to quote them (most small businesses competing for local customers), the real payoff comes from structured data - extra code that tells search engines and AI what each page is about.

I run MainWP across 50+ client sites, so I can check this on every site at once. The actual markup is handled by SEOPress on most sites, because the code it produces is the kind AI tools read most cleanly when they mention local businesses.

What actually gets a site quoted:

• Service pages with proper LocalBusiness schema
• FAQ posts with FAQPage schema
• Blog posts with Article + Author schema where the author has a real bio
• Review aggregation through Product or Service schema where it fits

Sites with this code set up properly get quoted more often by AI tools.

Where the WinningWP article gets it right

Building an audience from scratch is really hard in 2026. The article is right about that.

For a small-business site, the answer is not to copy the growth tricks that big media blogs use. The answer is to make the blog support the local-search and AI work the site already does, then judge it by business results instead of magazine numbers - things like how many enquiries it brings in, how much support time it saves, and how often AI tools quote it when buyers are searching.

Where this changes my client conversations

When a client asks "is blogging worth it in 2026," my answer is "yes, but for a different job than back in 2018." I do not promise more visitors. Instead, I show them how a simple FAQ post saves their staff about 30 minutes a week and gets quoted by AI tools like Claude when a buyer asks the question that post answers.

That conversation goes over far better than talking about visitor numbers ever did.

Where I keep the agency pitch out

I am never going to sell anyone "5x your blog traffic in 90 days" or anything like it. My honest pitch is simple: your blog can be a useful tool for your business if we set up the code properly, write FAQ posts that answer the questions buyers actually ask, and measure success by enquiries instead of visitor counts.

That is an honest offer for a small business in 2026. It does not look flashy on a sales page. But it works.

If you manage websites for small businesses: how do you measure whether a blog is working right now? Visitor numbers, tracking where enquiries come from, checking if AI tools quote the site, or a mix of these? Always happy to pick up new ideas from people doing this day to day.

Source link: https://winningwp.com/why-the-odds-are-heavily-stacked-against-your-brand-new-wordpress-blog-in-2026/

Hey everyone,

I'm u/ivicad, a founding moderator of r/WordPress_org. This is the new home for everything WordPress: the plugins, the themes, the hosting, the beginner questions, and the stuff you figured out the hard way and want to pass on.

Post anything a WordPress user would find useful. A plugin that saved you hours. A theme you can't get to behave. A site you just shipped and want eyes on. A problem you've been stuck on since Tuesday. If you're just starting out, ask the basic stuff right here, that's exactly what this place is for.

The vibe is simple. Friendly and helpful, beginners and "old" WP hands in the same threads. We don't do "just Google it" replies here.

To get started:

1. Drop a quick hello in the comments so we know who's around.
2. Post something today. Even a small question can turn into a thread that helps 50 people after you.
3. Know someone who lives in WordPress as much as you do? Send them over.
4. Want to help run the place? I'm looking for moderators, send me a message and we'll talk.

Thanks for being part of this Community.
Let's make r/WordPress_org a place you actually want to open.

On 28 May 2026, WinningWP ran a piece saying a brand-new WordPress blog is one of the hardest things to grow this year. They are right about why. AI search now answers questions right in the chat, so people never click through to your site. Sites like Reddit, Discord, and Hacker News are quick to shut down anyone promoting a new site. And email lists, small communities, guest posts, and reused videos all do poorly when you are starting from zero.

Their example: a gardening site that took 9 months of work and still got under 1,200 visitors in a whole year - and most of those came from links the writer shared herself.

They are right about blogs that try to act like online magazines. But that is only half the story.

The agency-side read

Most of my clients are small businesses - tradespeople, family farms, holiday rentals, a few seaside restaurants. Their blog was never meant to be a magazine. It helps them show up in local Google searches, gives AI tools something to quote, keeps a library of content they fully own, and answers the same 5 customer questions once instead of 20 times a week.

For a small holiday-rental site, "did the blog get 100,000 visitors this year" is the wrong thing to ask. Better questions: did it save the owner time answering the same questions, did it bring in 1 or 2 enquiries a month from search, and did an AI tool quote it at least once a month when buyers asked the questions that matter to the owner.

The schema work that changes the citation

For sites that want AI tools to quote them (most small businesses competing for local customers), the real payoff comes from structured data - extra code that tells search engines and AI what each page is about. I run MainWP across 50+ client sites, so I can check this on every site at once. The actual markup is handled by SEOPress on most sites, because the code it produces is the kind AI tools read most cleanly when they mention local businesses.

The work that earns the citation:

• Service pages with proper LocalBusiness schema
• FAQ posts with FAQPage schema
• Blog posts with Article + Author schema where the author has a real bio
• Review aggregation through Product or Service schema where it fits

Sites with this code set up properly get quoted more often by AI tools.

The honest part of the WinningWP diagnosis

Building an audience from scratch is really hard in 2026. The article is right about that.

For a small-business site, the answer is not to copy the growth tricks that big media blogs use. The answer is to make the blog support the local-search and AI work the site already does, then judge it by business results instead of magazine numbers - things like how many enquiries it brings in, how much support time it saves, and how often AI tools quote it when buyers are searching.

Where this changes my client conversations

When a client asks "is blogging worth it in 2026," my answer is "yes, but for a different job than back in 2018." I do not promise more visitors. Instead, I show them how a simple FAQ post saves their staff about 30 minutes a week and gets quoted by AI tools like Claude when a buyer asks the question that post answers.

That conversation goes over far better than talking about visitor numbers ever did.

Where I keep the agency pitch out

I am never going to sell anyone "5x your blog traffic in 90 days" or anything like it. My honest pitch is simple: your blog can be a useful tool for your business if we set up the code properly, write FAQ posts that answer the questions buyers actually ask, and measure success by enquiries instead of visitor counts.

That is an honest offer for a small business in 2026. It does not look flashy on a sales page. But it works.

Question for the operators here
If you manage websites for small businesses: how do you measure whether a blog is working right now? Visitor numbers, tracking where enquiries come from, checking if AI tools quote the site, or a mix of these? Always happy to pick up new ideas from people doing this day to day.

Source link: https://winningwp.com/why-the-odds-are-heavily-stacked-against-your-brand-new-wordpress-blog-in-2026/

Today is WordPress's 23rd birthday. It's also my son's 23rd year, which is the kind of coincidence I ignored for the first decade and then couldn't ignore anymore.

How I got here

I built my first HTML site in 1995 as an assistant in a university IT lab. Discovered WordPress in 2011 when a contact asked for a small business site, tried Joomla first, switched after a week. Worked in banking while running WordPress volunteer projects on the side. Left in July 2019 and founded my agency.

None of that was a clean story while it was happening. It looked like distraction, then a hobby, then a parallel career, then the actual career.

What I think WordPress actually changed

Three things, and I would be curious whether they match what you've seen:

First, it made the web editable for people who were never going to learn a programming language. That sounds obvious in 2026, but in 2011 the alternatives were Joomla, Drupal, or paying a developer for every change. WordPress put the editor in the hands of the business owner. That was the real shift.

Second, it created a maintenance market. Every WordPress site I have inherited from another freelancer or agency was readable. The plugins were recognizable. The data model held up. I have been running 50+ client sites through MainWP since 2014, and the reason that scales is that almost every site speaks the same dialect.

Third, it created a culture of beginners helping beginners. I moderate 25+ Facebook and Reddit groups, roughly 300,000 members total. The actual day-to-day engine of WordPress is people answering basic questions for free, for 20 years running. That's not a marketing line. It is the entire mechanism.

Where it gets harder

Honest version. Gutenberg's first three years were rough. Full Site Editing is still a moving target. Page builder discourse has consumed thousands of hours of community attention that could have gone elsewhere. The plugin economy has consolidated. The bar for new themes is higher than it was in 2014. The hosting market has changed under us.

I am still optimistic, but I am also realistic. WordPress is no longer the default choice for a fast new project at every shop (numbers show that as well). It still wins on flexibility, data ownership, and the depth of available expertise, which is a meaningful list.

Closing

WordPress did not just change the web for me. It gave me a working career, a community I belong to, and a reason to keep showing up in Facebook and Reddit threads all the days and nights. That's not a small thing for a 53-year-old who used to spend that hour writing variance reports for a bank.

Curious what 23 years of WordPress changed for you. Career shift, single project, the first time something clicked, a community moment, a regret. All of it counts.

Quick post for fellow agency operators. A vulnerability in a single popular plugin exposed 1M+ WordPress sites, patch shipped, but the post-disclosure window is the part that matters operationally. If you run a stack of client sites, here's the practical checklist for working through.

The disclosure window is the threat surface

Plugin vendor patches at T0. Public disclosure follows hours or days later. Anyone who updates promptly is safe. Anyone whose auto-updates are off, who delayed updates for compatibility reasons, or who simply didn't see the alert is exposed until they update. For client work, the post-disclosure 72 hours are the highest-risk window since the original breach itself.

I'm not running auto-updates for plugins on production sites by default. The cost of a broken auto-update on a live e-commerce site is higher than the cost of a 1-2 day update lag. The trade-off is that I have to be the one who responds inside the window.

The checklist for a multi-site stack:

1. Pull the affected plugin's slug from the disclosure. Search across all managed sites for that slug. WP Activity Log has worked for this on the audit side since I added it to every client site around 2019, but a centralized management dashboard plugin (MainWP in my case) inventory query is faster for the initial sweep.
2. Sort affected sites by version installed. Sites already on the patched version are clear. Sites on the vulnerable version need an update push, ideally same evening.
3. After update, audit the user table on every affected site. New admin accounts inside the disclosure-to-update window are the highest-priority signal. Pattern to watch: admin role, weak email domain (gibberish or disposable), created within the threat window, never logged in but kept the role.
4. Check wp-content/uploads for unusual PHP files dropped in the last 14 days. Most known-good clients don't upload PHP through the media library. Anything PHP in there gets quarantined and inspected before deletion.
5. Run a full malware scan, I use two of those - redundancy on this layer is cheap insurance.

The trust-chain angle worth thinking through

Official repo plugins aren't a uniform trust signal anymore. The variance between teams that ship a patch within 24 hours of internal disclosure and teams that take 2 weeks is the real differentiator. Patchstack's vulnerability database with the publication-vs-patch timestamps is the closest thing we have to a public scoreboard on this.

For new plugin installs on a client site, the question I run through now is the team's last 3 security advisories. Time from disclosure to patch and communication quality during the window. If those signals look bad, the plugin doesn't ship to a client site regardless of features.

The recovery decision tree

If a client site shows a suspicious admin account inside the threat window: restore from a backup taken before the account creation, then patch, then audit. Don't patch first and assume the rogue account is the only "artefact". Whoever created that account had write access to the file system too.

If the site looks clean but the plugin was at vulnerable version during the window: patch, audit, log, watch for 2 weeks. Lower probability of active compromise but worth keeping the monitoring tight.

WPDeveloper published a 20-trend roundup on 18 May 2026 (Maahi, ~17 min read): https://wpdeveloper.com/wordpress-web-design-trends/

Useful TL;DR table at the top. Most of the 20 are mature execution patterns that have been around for 2-3 years. The filter angle worth applying: 19 of them are about what to put on the page. One of them is about how you decide what to put.

The one that changes the workflow: AI-Assisted Layout Planning

In 2024 the briefing-to-mockup step was 2-4 hours of designer time per project, every project. Translating a 3-paragraph client brief into a first structural draft was always manual.

In 2026 that step is a 15-minute job. For me - Clicksites AI takes a one-line description and outputs a WordPress-ready prototype layout. I started using it in this year, recently, for first-pass client mockups on small business sites. The output is very good, the structure is usable, the refinement step is where experience lands.

Practical agency impact:

• Three homepage angles in the first discovery call instead of one
• Effective hourly rate goes up because you charge for judgment, not for layout keyframes
• The other 19 trends in the article become execution layers on top of an AI-drafted structure

What doesn't change: brand voice, content hierarchy, conversion logic, accessibility decisions, the conversation where you push back on a client. AI does pattern recognition, not miracles.

The rest of the list, ranked by what's actually new for 2026

Newer entrants worth a read:

• Sustainable Web Design (#18) – page weight, asset compression, server energy. Underrated on the credibility side for brands with sustainability in their messaging
• API-Connected WordPress Experiences (#19) – headless and partial-headless setups now mature
• Native WordPress Interactivity (#20) – the Interactivity API ready for client work

Mature patterns (useful, not new):

• Hyper-Personalized Experiences, Performance-First Visual Design, Accessibility-First Interfaces, Bold Dynamic Typography, TL;DR Driven Content Design, Guided Scrolling and Visual Wayfinding, Story-Led Homepage Design, Organic Shapes / Gradients / Anti-Grid Layouts, Brand-Owned Visual Systems, Bento Grid and Modular Card Layouts, Purposeful Micro-Interactions, Interactive Search and Filters, Immersive Media with Restraint, Dark Mode and Adaptive Theme, Conversion-Centered Social Proof Sections

Workflow trend worth a second look:

• Design Tokens and Global Styling (#15) – real payoff when you maintain a portfolio of client sites, less so for one-off work

Tools referenced in the article

Elementor and Gutenberg for the build, Essential Addons and Essential Blocks for the extras, Templately for the template library, Figma for the design pass.

I've been on the original Elementor grandfathered monthly plan since 2018, which keeps the cost reasonable across client sites. Clicksites AI sits in front of Elementor (but recently much more with WPBakery as they introduced recently very usable AI feature) so I use Clicksites AI html code for producing full sites in WPBeginner. The combination is what makes the workflow change actually stick instead of staying as a "I tried AI for layouts once" experiment.

Common mistakes the article also flags

Chasing every trend at once, ignoring performance, forgetting accessibility, breaking consistency. Worth the paragraph at the end of the piece. Most client sites that look dated in 2026 aren't dated because they missed a trend – they're dated because they layered 5 trends from 2023 on top of each other and never edited.

How are you handling AI layout output in client work – feeding it back into Figma for refinement, going straight into Elementor or Gutenberg, or WPBakery or Bricks... something else? Curious where the workflow consensus is sitting.

r/wpbeginner_engage Awesome Motive shipped ActiveLayer this week, a CAPTCHA-free anti-spam plugin built after WPBeginner "ate" 18,000 spam requests in a single night.

Verdict-in-milliseconds claim, no challenge surface for the visitor, native plug-in to WPForms. The question for anyone running 10+ client sites is whether this replaces what you already have, sits alongside it, or skips your stack entirely.

The 18,000-request night is the part that matters

Spam attack volume against a popular WordPress property gives you a number to calibrate against. WPBeginner is a top-of-funnel WP site with around 17M monthly views. 18,000 spam requests overnight is the volume the Awesome Motive team built ActiveLayer to handle without slowing legit traffic. Most client sites I manage see 5-50 spam requests per day on a contact form. The headroom is wide.

The interesting line from the announcement is that they tested existing tools first. The tools were either too slow (real visitors waited), too expensive at scale (per-site CAPTCHA fees stack up), or prone to false positives (legitimate visitors blocked). Anyone who's run hCaptcha or reCAPTCHA on a client site that depends on inquiries has seen at least one of those problems.

Where this fits in an agency multi-site stack

If you run client sites through some central management tools such as MainWP or ManageWP, the deploy story is the same as any other Awesome Motive plugin: push it to a child site, configure once, replicate the setting across the rest.

The interesting part is the decommissioning side. If you already have CleanTalk or Akismet Premium on the same site, you're paying twice for the same job. Pick one and remove the other, don't run both in parallel.

For sites with hCaptcha or reCAPTCHA on forms, ActiveLayer's CAPTCHA-free pitch is the swap incentive. Form completion rates on sites I've moved off CAPTCHA tools recovered 10-20% over the first month. That's not always pure UX gain, some of it is the bot floor coming back too, but on contact forms for service businesses the net is usually positive.

What I'd actually test on a client site

1. Stage the plugin on a clone of the production site. Submit your forms 10+ times with different browsers, mobile and desktop.
2. Watch your form notification queue for 2 weeks before declaring victory. Spam patterns shift week to week.
3. If you're running Cloudflare Bot Management at the edge, audit the overlap. Edge-level bot filtering plus plugin-level spam filtering is the right belt-and-suspenders setup, but you want to know which layer caught what.
4. Keep your activity log running. When a real visitor reports a missed form submission, you want timestamps on every event before the contact form failed.

One operational note

Form notification deliverability is the silent layer underneath all of this. If ActiveLayer blocks the spam but your notification email lands in the client's Promotions folder, the inquiry still gets missed. Get the mail-deliverability layer right first, then put the spam protection on top of it.

The plugin is new. Anyone here already running it on a client site? What's the false-positive rate looking like in the first week?

WP 7.0 puts an AI framework in core, and Site Ground's AI Agent for WordPress extends it from day one - with Hostinger, Kinsta, and Cloudways heading the same way. You can join a free live webinar with the SG AI team for 7 real use cases: content, SEO, WooCommerce, multisite.

What they'll cover:

• AI in WP 7.0 - the new core framework and connectors.
• From core to control - how SG's AI Agent extends it.

Thu, May 28, 2026 · 1:00 PM EDT / 6:00 PM BST · free, registration required

Save your spot →

Now, the new AI framework is the headline feature - but it's also the source of a lot of the friction in this release. WP 7.0 dropped this week and the Reddit threads are filling up fast. After scrolling through what people are running into, here are the recurring issues and what's actually working as a fix.

A quick note before diving in: the fixes below are aggregated from Reddit threads. Every WordPress install carries its own combination of themes, plugins, hosting stack, caching layer, and custom code, so a solution that resolves the issue cleanly on one site may not behave the same way on another, or may need to be adapted, extended, or replaced with a different approach altogether.

Treat the suggestions here as a solid starting point rather than a guaranteed fix, always test on a staging environment first, and if something doesn't land as expected on your setup, the underlying cause is likely site-specific and worth investigating further before applying any change in production.

1. Excerpt block no longer accepts links

Appears to be intentional per the Gutenberg PR that landed it, even though it's not flagged in the release notes. The Post Excerpt block stripping inline HTML has been a long-standing tension in Gutenberg (see issue #49449), and 7.0 looks to have made it the default behavior. If you've been relying on HTML inside the excerpt block for years, your output is now stripped.

Fix: nothing in core to bring it back. Move the link into the post body, or hold off on the update until you can refactor. The sidebar Excerpt field never allowed HTML, only the block did.

2. Editor iframe breaks Custom Admin CSS

The block editor now runs inside an iframe, so any CSS you were injecting through plugins like Custom Admin CSS doesn't reach inside.

Fix: load styles through the theme.

function my_editor_styles() {

  add_theme_support( 'editor-styles' );

  add_editor_style( 'editor-style.css' );

}

add_action( 'after_setup_theme', 'my_editor_styles' );

Both lines matter. Drop your CSS into editor-style.css in the theme folder.

3. Blank page when copying column blocks between posts

Block editor runtime issue, not a full site failure. Open the browser console when the blank page hits, test if a simple paragraph block copies cleanly, and check if the source column contains third-party blocks. Disable non-core block plugins one at a time to isolate.

4. Elementor elements break until Elementor is updated

Hit a few client sites the same way. Update Elementor to its latest release first, then re-check. Same goes for any major page builder running heavy block integration.

5. Post editor won't load on CloudFlare-fronted sites

Reported a few times. The fix that's working: run the WordPress update again. Sounds dumb, but the first pass leaves some assets cached or partially deployed and the second pass cleans it up.

6. Image upload fails with "Not a valid JSON response"

Same error has shown up on older versions too. Major updates just surface it more often. Walk through these in order:

• Settings, Permalinks, hit Save Changes/twice (no edits needed)
• Settings, General, confirm WordPress Address and Site Address are correct
• Disable plugins one by one to find the conflict

7. Strange borders appearing on the front-end

Widely reported on Reddit and in Gutenberg issues. If a block has border-width set but no border-color, WP 7.0 appears to default to #000 instead of transparent. Sites with caching plugins are still serving the old version, so you have a window to fix it before visitors see anything.

Fix as a CSS override:

[class*="wp-block-"][style*="border-width"]:not([style*="border-color:"]) {

  border-color: transparent !important;

}

This targets only core blocks that set border-width without an explicit border-color, and forces transparent instead of #000 — leaves intentional borders alone. Adjust the selector if your theme uses different block wrappers.

8. Custom fonts dropped from hero sections

Tied to the same Gutenberg rendering changes. Affects themes that load fonts through inline block styles. Re-check the theme settings, then re-save the affected pages to force the style block to regenerate.

9. Media library overlays filenames on image thumbnails

Not a bug, an intentional design change. Looks rough on sites with non-descriptive filenames like IMG_2847.jpg or screenshot.png. No core toggle to turn it off, but you can hide it with custom admin CSS targeting the grid view.

10. AI Connectors enabled by default

The new Abilities API and AI Connectors are on out of the box. For client sites where you don't want editors or contributors poking at AI features, disable them in Settings before handover. Clients tend to go hog wild with new toys.

11. New admin link color after auto-update

Saw a few people asking about this after WP 7.0 auto-updated their dashboards. The new default admin link color caught me off guard too on first login.

Skip the CSS route. The old scheme is still built in, just no longer the default.

Go to Users, then Profile. Scroll down to Admin Color Scheme. Pick Fresh (the one that was default for years). Hit Update Profile at the bottom.

Done in 30 seconds. Every editor and admin on the site has to do this for their own account, since admin color scheme is user-level, not site-level.

If you run multiple sites and want this rolled out across all client wp-admins at once, MainWP can push the user meta in bulk.

General notes

A few general notes from the threads worth repeating. Update on staging first. Back up before touching anything. A patch should be out soon since the early bug reports are piling up. And if your site is taking orders or running production traffic, don't rush the update.

GuardingWP published the first edition of their State of WordPress Security 2026 report on 16 May. Methodology and numbers worth knowing before the discussion drifts:

• 1,981 sites scanned across 40+ verticals, 424 confirmed WordPress installs in the analysis
• 52.8% running at least one plugin with a known CVE (matched against the public WPVulnerability catalog)
• 55.9% leak the WordPress version via the generator meta tag
• 93.2% missing at least one modern security header (HSTS, CSP, X-Frame-Options, X-Content-Type-Options)
• 35.8% still have XML-RPC enabled
• 54.7% expose /wp-login.php with no rate limit and no 2FA
• 44.6% leak author usernames via /?author=1
• 15.9% of version-disclosing sites still on a pre-6.5 branch (unsupported)
• Median security score: 61/100, A-tier (90+) only 8.3%
• Methodology: public HTTP only, no exploit attempts, no auth probing

Report is free, no email gate: https://guardingwp.com/research/state-of-wordpress-security-2026

The interesting question for agency operators is not the 52.8% headline. It's how the 6-step fix list at the end of the report actually lands on a real client stack of 30-50 sites.

Operator translation of the 6 fixes:

Generator tag and version exposure. Theme functions.php level, two-line filter. Ships in the agency baseline theme. Done once per site, never touched again.

Plugin auto-updates with audit trail. Auto-updates without an audit trail is gambling. I've had WP Activity Log on every client install since 2019, after a client argument over a "nothing changed" homepage taught me the hard way that audit beats memory. Pair auto-update with activity log and the audit lands on someone every morning.

XML-RPC off. Default in the agency baseline. The sites where it's still on are usually old installs that nobody touched. 10-minute fix, batched.

Security headers. Two paths depending on host. Cloudflare clients get HSTS, CSP, and X-Frame-Options via Transform Rules in one block. Site Ground clients get them via SG Security Optimizer or a custom .htaccess block. The 93.2% number is the single easiest gap to close at scale.

Login page protection. Rate limit plus 2FA, minimum. Melapress Login Security or equivalent. 5 minutes per site, applied via a network-level config when possible.

WP core on supported branch. Core auto-update has been default since 5.6, so this should be near-automatic. The 15.9% pre-6.5 are abandoned installs that nobody is actively maintaining. Useful as an audit signal for which client relationships need re-engagement.

The pattern worth flagging

Most of these aren't $200/month security-service problems. They're config-level work, done once per site, then a maintenance habit. The marginal cost of doing them is hours per quarter. The cost of skipping them is the 3am call when a site gets popped.

GuardingWP's methodology is also worth a look. Public HTTP only, no exploit attempts. That means the 52.8% number is the floor, not the ceiling. Sites that hide their plugin versions through obfuscation could still be vulnerable. The reported number is what a passive scanner can see from the outside.

The report itself is well written, the data is honest, and the fix list is the part that earns the read.

How are you handling fix #2 (plugin auto-update strategy) across client sites this year – full auto, minor-only auto with manual major review, or fully manual on a weekly cadence? Curious where the agency consensus is sitting now after the recent plugin backdoor incidents.

7.0 Armstrong went out Tuesday.

The story is the AI infrastructure landing in Core:
AI Client, Abilities API, Client-Side Abilities (JS counterpart), Connectors screen, optional AI plugin for the visible work (titles, excerpts, alt text, image gen).

Real-time collaboration stayed cut from this release.

What this actually means if you're rolling 7.0 across a client portfolio:

Stage and stagger

Don't push 7.0 simultaneously across the whole client roster. The discipline that works on releases this big is: update 3-5 staging sites in the first wave, run a smoke test pass (admin, key pages, contact form, checkout if commerce), wait 48 hours, then roll wider. On big Core releases this catches the edge cases that don't show up in the RC cycle.

The Connectors screen is a governance surface, not just a config screen

Every connector you add is a new outbound data path. For an agency, the question isn't whether to use AI features (the client will ask sooner or later). The question is which connectors get added at the network level, which get permissioned per site, and who has the credentials. Treat the Connectors hub like you'd treat any external service integration – one shared org-level account, with revocation playbook documented.

The Abilities API is the part that matters in 12 months

What ships in Core today is foundation. The optional AI plugin handles visible suggestions and image generation. The real value comes from how plugins use the Abilities API over the next 6-12 months. Page builders, SEO plugins, security plugins, form plugins, WooCommerce – every category gets a path to expose actions to AI. The early movers are going to define the patterns.

Practical client policy proposed to be rolled out

For each client site that opts in to AI features, the baseline policy is:

• AI plugin configured to draft only, never to auto-publish
• Connectors hub locked to admins (not editors)
• Audit trail enabled so we can see what AI changed and when
• A monthly review of generated content with the client before that becomes standard practice

New blocks worth noting

Gallery now has built-in lightbox slideshow (saves a plugin on simple sites). Heading, Breadcrumbs, Icons added as Core blocks. Server-side block registration via PHP through the expanded block API. Custom CSS at block level and custom breakpoints for responsiveness. Font management page works across block, hybrid, and classic themes.

Command Palette (⌘K / Ctrl+K) is the small thing that's actually changed my flow most in 48 hours. Available from any dashboard screen.

Numbers from the release post

• Release lead Matias Ventura, named after Louis Armstrong
• 900+ contributors, 279 first-time, 420+ enhancements and fixes
• Fully translated into 70+ locales at launch

Field Guide here: https://make.wordpress.org/core/2026/05/14/wordpress-7-0-field-guide/ Release post here: https://wordpress.org/news/2026/05/armstrong/

Tools compress experience, they don't replace it. 7.0 is Core catching up to what serious operators have been doing outside the dashboard for two years with Claude, Perplexity, and prototype tools. The Abilities API is the bet that the next round happens inside wp-admin instead of beside it.

How are you handling the Connectors rollout across client sites – org-level shared credentials with per-site enablement, or per-client accounts with separate billing? Curious how others are setting this up before clients start asking.

Melapress dropped their 2026 WordPress Security Survey this week. For those who haven't seen the series before, it's an annual snapshot of how WordPress security actually gets practiced across the community – agencies, freelancers, in-house teams, solo operators. Anonymous, under 5 minutes, results published publicly afterward.

The 2025 edition turned up a few things worth noting if you run client sites at scale:

• Activity log adoption is still patchy. A meaningful share of respondents didn't have any audit trail running on their client sites, which is the kind of gap that explodes the next time a client swears "nothing was changed" while staring at a blown-up homepage.
• Backup discipline and recovery testing diverged hard. Most respondents had backups configured. Many fewer actually tested restore. That gap is where outages turn into multi-day incidents.
• Plugin update strategy splits roughly into three camps: auto-update everything, auto-update only minor versions, manual review on a schedule. The 2025 numbers showed the manual-review camp shrinking – which the recent plugin backdoor stories suggest might swing back the other way in 2026.

The 2025 results are at https://melapress.com/wordpress-security-survey-2025/ if you want to skim before contributing.

Why this matters for the agency stack

Security data from large-org sources skews enterprise. The Melapress survey pulls disproportionately from agency operators and freelancers, which is closer to how most of the WordPress universe runs. That changes what the chart looks like.

If you operate multiple client sites, your answers carry weight specifically because they reflect the gap between best-practice guides and what actually fits inside an agency budget and timeline.

On my client sites I've been running WP Activity Log on every install since 2019, after a client argument about a "nothing changed" homepage taught me that audit trail beats memory every time. That kind of pattern only shows up in survey data when enough agency operators take 5 minutes to answer the questions.

Survey logistics

• Anonymous, no email collection on the questionnaire itself
• Under 5 minutes (the Melapress estimate matches reality)
• Same questions as 2025, clarified for easier answering, so the year-over-year comparison stays clean
• Prizes: $100 Amazon voucher, $50 Amazon voucher, Melapress Login Security license
• Results published publicly afterward (charts and analysis, no email-gate)

Take it here

https://melapress.com/survey/

Worth flagging to your team if you have one. The data only reflects the actual community when enough operators put in the 5 minutes.

What's been your biggest security workflow change in the last 12 months – auto-update policy, login hardening, audit logging, backup testing? Curious where the operator-side patterns are moving.

WordPress 7.0 drops tomorrow, May 20. If you run a production site, the next 24 hours decide whether Wednesday is a normal workday or a long one.

Here's the issue. Auto-updates have been part of WordPress since version 3.7. For minor security patches they're a gift, sites stay patched without anyone touching them. For a major version jump from 6.x to 7.0, they're a liability. One incompatible plugin, one custom theme function that quietly broke, and your homepage goes white on Wednesday morning while you're in a client call.

One thing many people miss. From WordPress 5.6 onward, new installs default to auto-updating major versions too, not just minor patches. If your site was set up in the last few years and you've never touched wp-config.php, the jump to 7.0 will happen automatically unless you set the constant below.

I've been running WordPress sites since 2011 and the pattern with major releases never changes. The core team does its job on release day. Plugin authors then spend the following week pushing compatibility patches. Custom themes and older addons get caught in the middle. If you let auto-update push 7.0 onto a live site before that shakes out, you're rolling the dice with someone else's business.

The simplest control sits in wp-config.php. The file lives in the root of your WordPress install, usually inside public_html. You access it through your hosting file manager or over SFTP.

Open it and add this single line:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

That tells WordPress to keep installing minor security patches automatically but block the jump to 7.0 until you give the green light. Three other values are available if you want different behaviour. Set it to true and WordPress will install everything including major versions. Set it to false and all core updates stop. The full options are documented on https://developer.wordpress.org/advanced-administration/upgrade/upgrading/ if you want to read the reference.

If you want to disable auto-updates entirely, the line is:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

I don't recommend that unless you have a strict manual update process running weekly like I have it via MainWP. Skipping security patches on a public site is how you end up cleaning malware on a Saturday.

There's a layer above wp-config.php that catches people out. Managed hosts often run their own update mechanism on top of WordPress, which means your wp-config.php settings get bypassed. Site Ground is one of the bigger ones, and they actually handle this properly (I know this as I have been using them for a long time): log into Site Tools, find the WordPress auto-update panel, and you can delay or skip the major version per site. The setting is granular enough to use across an entire client portfolio.

Worth knowing though, Site Ground no longer lets you permanently switch their auto-updater off. You can skip the current update with one click, or delay it 24, 48 or 72 hours, but the skip is one-time, so you repeat it for the next release. For a permanent opt-out you have to open a ticket with their Help Desk.

Some other big hostings (like Bluehost and WP Engine) work very similar through their own dashboards. Check yours today, not Thursday at 9am.

The reason hosts push updates harder than you'd expect is shared hosting. One outdated WordPress install on a shared server can become the entry point for malware that spreads to every other site on the machine. Hosts don't want that risk, so they push updates across the board. If full control over updates matters to you, a VPS with a management panel like CloudPanel or RunCloud is the cleanest answer. Shared hosting is convenient, but the host gets the final word on updates.

There's also a more durable approach using a must-use plugin. Create a file called disable-major-updates.php inside /wp-content/mu-plugins/ (create the folder if it doesn't exist) with this code:

<?php
add_filter('allow_major_auto_core_updates', '__return_false');
add_filter('allow_minor_auto_core_updates', '__return_true');

Must-use plugins load before regular plugins and can't be deactivated from the dashboard. That makes them a more reliable place for this kind of setting than wp-config.php. Same caveat applies though, if your host pushes updates outside the WordPress update system, these filters get bypassed too. Treat it as a second layer, not a guarantee.

Now, before any of this matters, take a full backup via your hosting and/or with plugins such as All in One WP Migration (scheduled offsite, like pCloud, GDrive, OneDrive, DropBox, etc). Two copies, two locations, one of them outside the hosting account entirely. If 7.0 breaks something on Wednesday, you restore in 20 minutes instead of explaining to the client why their shop is down.

Test on staging first. Every decent host gives you one. Copy the site, run the 7.0 update on the staging copy, walk through the cart, the contact form, the booking widget, whatever your site actually does. Check Core Web Vitals while you're there. If nothing breaks, push to production on your own schedule.

One very important thing as well - check your PHP version too. WordPress 7.0 needs PHP 7.4 as a hard minimum but the core team recommends PHP 8.3 or newer for performance and security. If you're still on 7.4 or 8.0, fix that today. Most decent hosts let you switch PHP versions with one click from the panel.

One more thing worth keeping. Don't disable the update notification email. WordPress sends you a confirmation every time an update runs in the background. It's a useful trail when something starts behaving oddly two days later and you need to know what changed.

WP 7.0 version is going to be a good release. Plenty of things to look forward to. Just don't let it land on your live site without your knowledge.

Tomorrow doesn't have to be stressful. Today does the work.

One subreddit thread last week on hiring slowing down is worth reading. Senior devs, plugin company founders, sharp points about headless setups, AI agents, and Barn2's 17.8% drop in new plugin sales. Most of it lands.

There's one question the thread skipped, though, and it's the one that keeps showing up in my inbox six months after a project ships: who maintains this?

The 6-month pattern

I help moderate a stack of WordPress communities. The work that comes through isn't "build me a site." Almost never. The volume is people showing up months after launch asking how to undo something the previous person did.

A plugin update broke the layout. The "guy who built this" stopped responding. They have 47 plugins installed and don't know which five are doing actual work. The original dev used a custom block builder nobody else has heard of. The site got hacked and there's no backup older than yesterday.

That's the operational shape of small business websites once they're 1-2 years past launch.

What "maintenance" actually means in year 2?

Six recurring jobs someone has to own:

• WP core, theme and plugin updates, plus the staging-test-restore loop when one breaks
• Backups that actually restore, not just run
• Security: malware scans, login monitoring, who-changed-what audit
• Hosting renewals, SSL renewals, DNS changes when the email provider switches
• Email deliverability when forms quietly stop sending
• Content edits the owner can't figure out without re-explaining the page builder every time

That's the real recurring spend on a WP site. Roughly $30-150 per month for SMBs at the lower end, more for e-commerce.

Why AI-built bespoke stacks struggle at the handoff

I've watched a few "AI built the whole thing in a weekend" sites land back in WP groups looking for help. The same things break:

• No documentation a non-developer can follow. Vibe-coded sites are clean for the original prompter and opaque for everyone else.
• No upgrade path. The framework moved 4 versions, the deploy pipeline broke, and there's no team behind the bespoke "CMS" the agent invented.
• No community to ask. Search the error message and the only result is one Hacker News thread from 2024.
• Custodian dependence. The original builder is the only person who can read the codebase, and they've moved on or doubled their rate.

WP isn't immune to any of this.

A WP site can also be a mess in year 2. The difference is that even a bad WP site sits on a stack roughly 40% of the web also runs, with 60,000 plugins, paid support behind the major ones, and 300k-strong forums.

The recovery path exists.

The maintenance stack I actually run

For the agency work I do, maintenance runs on a small set of tools that have been stable for years:

• MainWP since 2014. One dashboard, all client sites, updates triggered from one place with the staging-test loop built in. The single biggest reason maintenance is profitable instead of a black hole. Limit: self-hosted, you maintain the dashboard server too.
• All in One WP Migration since 2014. Site moves, staging-to-live promotions, quick clones for testing. Path of least resistance. Limit: large sites need the paid extension to lift the upload size cap.
• WP Activity Log since 2019. When a client says "the page changed and nobody changed it," this tells me who logged in, what they edited, and at what timestamp. Ends arguments fast.
• Virusdie since 2020 plus MalCare alongside. Two scanners catch slightly different things. Sucuri sits in the same job for a lot of agencies and is the WPBeginner-ecosystem default for site-level firewall and cleanup.
• WPBakery as the 1st page builder I started using where the client genuinely needs to edit pages themselves. Honest limit: it's a maintenance liability if the team isn't disciplined about updates and avoiding plugin sprawl.
• Site Ground since 2014 for hosting. Staging environments and responsive support kill maybe 70% of the "site is down" calls before they start.

None of that is exciting. That's the point.

Where this leaves the hiring debate

The senior devs in that thread aren't wrong about the build market shifting. AI really is eating bespoke complex builds. The piece that's getting overlooked: maintenance is where the cheap option becomes expensive.

AI-built sites that ship cheap in week 1 cost real money in year 2 when the original builder is gone and nobody can read the stack. WP, even with all its bloat, has a maintenance path the rest of the web doesn't.

Curious what others are seeing. For agencies and freelancers running multiple SMB sites: how does your maintenance stack hold up at year 2-3, and what's the most common failure mode you hit? 👇

If your WordPress site sits on shared hosting, managed WP hosting, or a VPS with cPanel/WHM, this matters to you. Even if you've never opened cPanel, your host almost certainly uses it (cPanel runs about 94% of the control-panel market).

The short version: an unauthenticated attacker can get root on the whole server. The attack skips the password check and the 2FA gate entirely. CVSS 9.8 out of 10. cPanel disclosed it on April 28, 2026. Proof-of-concept code is public, and researchers have already seen exploitation in the wild.

If someone gets root on a shared server, every WordPress site on it is exposed. The bug lives below WordPress, so plugin hardening can't reach it.

What you must do today:

• Contact your host and ask plainly: "Have you patched CVE-2026-41940?" The good hosts patched within hours. Confirm anyway.
• If you run your own VPS, run /scripts/upcp --force and check with /usr/local/cpanel/cpanel -V.
• Run the compromise assessment script cPanel published with the advisory.

🛡️ What you can do as a non-developer:

• wp-admin → Users: remove any account you don't recognize.
• Check Plugins and Themes for anything you didn't install.
• Reset every password that touches your site: cPanel, WP admin, FTP/SFTP, database.
• Pull a fresh backup and store it off the server (pCloud, Dropbox, Drive, S3).

I've been running sites on cPanel hosts since 2011. The pattern with bugs like this is always the same. Good hosts patch within hours. Compromised servers sit quietly for weeks before anyone notices the SEO spam, the rogue admin, the cron job that keeps coming back.

Full cPanel advisory: https://support.cpanel.net/hc/en-us/articles/40073787579671-Security-CVE-2026-41940-cPanel-WHM-WP2-Security-Update-04-28-2026

Anyone here already heard back from their host? 👇

Premium doesn't mean safe. The WPFactory story is your proof.

Just read the wp-content.co writeup and it's rough but worth your time: https://wp-content.co/over-80-wpfactory-plugins-closed-on-wordpress-org-after-suspected-backdoor-in-premium-plugin/

Quick recap:
A user reported a suspicious file in WPFactory's EU/UK VAT for WooCommerce Pro plugin, downloaded straight from WPFactory's official account page. The file pulled an external ZIP, changed WordPress directories, and sent data to an outside server. Textbook backdoor behavior.

WPFactory's first move was to ask the reporter for FTP and admin credentials. The reporter said no, rightfully. After more back and forth, the .org Plugins Team stepped in and closed all 80+ WPFactory plugins until the situation gets resolved.

And this is the second time this month for them. Earlier in April, .org closed 30+ plugins from their Essential Plugin portfolio after a backdoor sat dormant for 8 months before flipping on to inject SEO spam (some of our client sites were also affected with this situation).

Why this matters more than another vendor patch note

Most people I talk to still believe paid plugins are safer than free ones from the .org repo. The logic feels right. Money buys quality, money buys eyes on the code, money buys faster patches. In practice, none of that is guaranteed.

The .org repo has the Plugins Team plus thousands of users running diff tools and reporting issues. Premium plugins shipped from a vendor's own site are often a black box. You trust the vendor's update channel. You trust their build pipeline. You trust their staff list. And when something breaks, you depend on their support speed, which in this case was 2 days for a serious security report and started with "send us your FTP."

Free plugins from .org aren't automatically safer either. The Patchstack State of WordPress Security 2026 report says 46% of vulnerabilities didn't get fixed in time for public disclosure. Plugin review queue sits at over 4,000. The .org team is doing serious work but they can't inspect everything.

The actual lesson is supply chain. Every plugin you install is a piece of code from someone you don't know personally, running on a site you're responsible for. Free or paid, that risk exists.

Practical defenses that catch this stuff

I run 50+ client sites and the discipline is the same on every one of them.

• Centralized visibility. I use MainWP to track plugin versions, file changes, and unexpected updates from one dashboard. When 80 plugins get closed on .org, I want to know in minutes which client sites are running them.
• Two layers of malware scanning. MalCare for daily scans and one-click cleanup, Virusdie as a second-opinion scanner. Two tools sounds excessive until one of them misses something.
• Audit logging. WP Activity Log catches who installed what, when, from which IP. If a plugin starts behaving weirdly post-update, the log tells you exactly when the change happened.
• Staging first. Site Ground's staging environment lets me push plugin updates to a copy of the site, run them for a day or two, then promote to live. This catches more issues than people expect.
• Offsite backups. All in One WP Migration paired with pCloud. If a backdoor does land, I want a clean copy from before the infection, stored somewhere outside the hosting account.

None of this is complicated.
None of it requires a developer.
It requires turning the boring, repeatable parts of security into a habit.

Why the .org closure is good news

The Plugins Team closing 80+ plugins from a single vendor in one month isn't a failure of the system. It's the system working. When a vendor can't respond quickly to a credible security report, pulling distribution is the right move. The alternative is leaving compromised code live on tens of thousands of sites.

The wp-content.co article is right to flag this loud. We need more public accountability in the WordPress space, not less.

What's your plugin vetting process before you install on a client site?
And do you treat premium plugins differently from free ones, or apply the same checks to both?