WordPress 7.0 is delayed. We covered the reasons in Article 2 — Real-Time Collaboration has performance issues, the AI features are stable and not the cause, and the core team chose stability over shipping. Late April to early May is the realistic window.
That delay is a gift. Most agencies will waste it.
A PwC study published this week found that 74% of AI-generated business value is concentrating in just 20% of companies. Not because the technology is inaccessible — because the other 80% are waiting for things to feel "ready" before they act. The same dynamic plays out in every WordPress major release: a small group of agencies deploys confidently on day one because they prepared. Everyone else spends the first week reading "how to safely update" guides and fielding anxious client emails.
You have a window. Here are five things to do with it.
1. Audit Your Plugin Stack for WordPress 7.0 Compatibility
This is the unsexy one, so we're putting it first.
The most common WordPress update disaster is not a core bug. It is a plugin that breaks. Every major WordPress release triggers a wave of "my site is down" support tickets, and the root cause is almost always a plugin that wasn't tested against the new version. With WordPress 7.0 introducing a new AI layer, new database tables for Real-Time Collaboration, and raising the PHP minimum to 7.4 (PHP 8.3 recommended), the compatibility surface is larger than a typical point release.
What to do right now:
- Pull a full plugin inventory across your client portfolio. Not just the active plugins — the deactivated ones too. Deactivated plugins still load code on some hooks and can cause conflicts during major updates.
- Check each plugin's last update date and developer activity. A plugin that hasn't been updated in 12+ months is a risk. Check the plugin's changelog, support forum, and GitHub activity (if open source) for any mention of WordPress 7.0 or PHP 7.4+ compatibility.
- Flag plugins that interact with the editor. WordPress 7.0's Real-Time Collaboration changes how the block editor manages sessions. Any plugin that modifies editor behavior — custom blocks, editor extensions, content locking, revision management — should be tested first.
- Document everything in a shared spreadsheet. One row per plugin, columns for: plugin name, version, last update, developer status, WP 7.0 compatibility (confirmed / unknown / incompatible), and action required. When 7.0 ships, you update the ones that are ready and hold the ones that aren't.
This is boring work. It is also the difference between a controlled rollout and a fire drill.
2. Set Up Staging Environments for Every Client Site
If you don't have a staging environment for every client site you manage, the delay is your window to fix that.
Every major WordPress host offers one-click staging: WP Engine, Flywheel, Cloudways, Kinsta, SiteGround. If your clients are on hosts that don't offer staging, that is a separate conversation worth having — but it's not a blocker. Tools like InstaWP and TasteWP let you spin up disposable WordPress environments in seconds for testing.
Why this matters for 7.0 specifically:
WordPress 7.0 introduces a new database table for Real-Time Collaboration. Database schema changes are the updates most likely to cause problems with migration plugins, backup tools, and custom database queries. You want to discover those problems on staging, not on the production site that handles your client's revenue.
What to do right now:
- Create a staging environment for every client site that doesn't already have one.
- Install WordPress 7.0 RC on each staging site. The release candidate is available now. Test the update path, verify plugin compatibility (see point 1), and document any issues.
- Test the rollback path. Make sure your backup and restore process actually works before you need it. If you're using a host-provided staging tool, test the "push staging to production" and "restore from backup" workflows.
- Keep the staging environments active. When the final release ships, you'll re-run the update on staging with the production version, verify everything, and then push to production with confidence.
The time investment here is maybe 20 minutes per client site. The alternative is testing in production, which is never 20 minutes.
3. Brief Your Clients on the Delay — And Your Plan
Your clients are going to hear about WordPress 7.0. Some already have. The question is whether they hear about it from you — with a plan — or from a search result that makes them nervous.
This is a trust signal. The agencies that proactively communicate updates, delays, and plans are the agencies that retain clients through contract renewals. The ones that stay silent until a client forwards a TechCrunch article with "should I be worried?" are always playing defense.
What to send:
A short email — two to three paragraphs. Keep it simple:
- What happened: WordPress 7.0 was delayed 3-4 weeks for stability reasons. This is a responsible decision by the WordPress core team.
- What it means for them: Nothing changes for their current site. WordPress 6.x continues working exactly as it does today. No action needed on their end.
- What you're doing: You're using the delay to test compatibility, set up staging environments, and prepare for a smooth update when the release ships. You'll handle the update when it's ready.
That's it. Three paragraphs. No jargon, no fearmongering, no upsell.
The subtext of this email is: "You're paying us because we stay ahead of this stuff." That's worth more than any deliverable.
4. Evaluate WordPress 7.0's AI Features
WordPress 7.0's AI layer is not a gimmick. We published a full engineering assessment in Article 1 of this series, and the architecture is genuinely well-designed: a provider-agnostic AI Client, capability discovery via the Abilities API, and an MCP Adapter that exposes WordPress to AI agent toolchains.
But most agencies are going to ignore it, because "AI features" sounds like a buzzword, and agencies are busy.
Here's why that's a mistake: the AI Client and MCP Adapter are the infrastructure that every AI plugin will build on going forward. Understanding them now — even at a high level — positions you to advise clients when they inevitably ask, "Should we be using AI on our site?"
What to evaluate:
- The AI Client API. This is the
wp_mail()of AI — a standard interface for connecting WordPress to language models. If your clients ask about adding AI features to their sites (chatbots, content generation, summarization), the AI Client is how it'll work. You don't need to build anything yet. You need to understand the pattern. - The MCP Adapter. MCP — Model Context Protocol — has hit 97 million monthly npm downloads. WordPress adopting it means any AI tool that speaks MCP (Claude, Cursor, custom agents) can now interact with WordPress through a standardized interface. For agencies managing dozens of sites, this is the beginning of AI-assisted site management at scale.
- The Connectors Screen. WordPress 7.0 ships a centralized settings page for managing external service connections — AI providers first, but the architecture supports any external service. Know where it is and how it works so you can walk clients through it.
You don't need to become an AI expert. You need to be the person in the room who can explain what's possible and what's premature. That is the agency value proposition in 2026.
5. Fix Your Search Now — Not Later
Here's the thing nobody's talking about: WordPress 7.0 gives your site an AI brain. It does not give it AI search.
The AI Client connects to language models. The Abilities API discovers capabilities. The MCP Adapter exposes WordPress to external tools. None of that changes the fact that WordPress's default search is a MySQL LIKE query — the same basic keyword-matching pattern it has used since the mid-2000s. Your client's visitor searches for "team building activities" and gets nothing, because the post is titled "Employee Engagement Workshop Ideas." WordPress 7.0 does not fix this.
Your clients notice. Search is consistently one of the top UX complaints on WordPress sites, and it's the kind of problem that erodes trust quietly — visitors don't complain, they just leave. They search, get irrelevant results, and bounce. Your analytics show it if you look: high search exit rates, low click-through on search results, repeat searches with slightly different terms.
The delay is the perfect time to address this, because you're already setting up staging environments (point 2) and testing WordPress 7.0 compatibility (point 1). Adding a search upgrade to the same testing cycle costs almost nothing in additional effort.
We're biased — we make wpRag, an AI search plugin for WordPress — but we're not wrong: search is the feature your clients complain about that WordPress 7.0 specifically does not touch. The AI Client connects to language models. It doesn't index content, understand user intent, or fix the fact that searching for "team building activities" returns nothing when the post is titled "Employee Engagement Workshop Ideas." Worth exploring while you've got the time.
The broader point stands regardless of which tool you choose: the window between now and the WordPress 7.0 release is the cheapest time to test a search upgrade. You've already got staging environments running. You're already auditing plugins. Adding a search solution to the test matrix is 15 minutes of setup and a week of real data on whether it makes a difference. If it does, you roll it out to clients with their 7.0 update. If it doesn't, you've lost nothing.
The Window Closes When 7.0 Ships
The PwC data is instructive: 74% of AI value going to 20% of companies isn't a technology problem. It's a preparation problem. The companies in the 20% didn't have access to better AI. They started preparing earlier.
The same principle applies here, on a smaller scale. The agencies that use this delay window to audit, stage, communicate, evaluate, and upgrade will deploy WordPress 7.0 confidently — and they'll have already addressed the search gap that 7.0 doesn't touch. The agencies that wait will spend the first week after release doing everything on this list under pressure, with clients asking questions they haven't prepared answers for.
You have three to four weeks. Maybe less, if the WordPress core team moves faster than expected. Use them.
This is Article 3 in our WordPress 7.0 series. Read Article 1: Engineering Assessment for the full technical analysis of what's shipping, and Article 2: WordPress 7.0 Delayed for the context on the delay and what it means.
Next: Inside WordPress 7.0's AI architecture — a deep dive into the AI Client, Abilities API, and MCP Adapter for developers and technical decision-makers who want to understand exactly what they're building on.