WordPress 7.0 shipped on 20 May, and most of the coverage has been breathless. Underneath the launch noise, three things arrived that genuinely matter to anyone running a university or society website: the Abilities API, an AI client in core, and a Connectors hub for the major model providers. Together they change where AI happens on your website — and that turns out to be the important part.
What actually shipped
The Abilities API is a registry. Plugins and themes can now declare, in a standard way, the things they can do — create a post, query members, regenerate a summary — with permissions attached. Before 7.0, every AI plugin invented its own way of poking at your site. Now there is one, and it respects your existing user roles.
The AI client in core means WordPress itself can talk to a language model — but only when you connect one. Nothing phones home by default. Connectors are how you do the connecting: official, auditable integrations for the major providers, configured by an administrator, in one place you can actually see.
If you have read our earlier piece on writing an enforceable AI policy, you will recognise why this matters. The biggest governance problem with AI features has been that they arrived scattered across a dozen plugins, each with its own API key in its own settings page, each sending your content somewhere slightly different. 7.0 gives you a single point of control — which means, for the first time, a single point of accountability.
What a university web team should actually do
Inventory what is already calling out. Before you add anything, list every plugin on your site that already talks to an AI service. You will probably find more than you expect. Anything that can move to a core Connector should; anything that cannot should justify itself.
Make the Connector decision a governance decision. Which provider, under what data-processing agreement, for which content — that is a decision for whoever owns your information governance, not for whoever happens to hold the admin password. The good news: it is now one decision, made once, rather than a dozen scattered defaults.
Pilot on one internal task, not your public pages. The wins we see in academic teams are the unglamorous ones: summarising a long committee document into a news brief, drafting alt text for a backlog of images, suggesting excerpts for old posts that never had them. Thirty-minute tasks that become three-minute tasks. Pick one, run it for a month, and measure.
Keep a human on publish. Nothing generated should reach a public page without a named person approving it. The Abilities API makes this easy to enforce — abilities respect capabilities, so your existing editorial roles are the guardrail. Use them.
What to leave switched off
- Public-facing content generation. Your research pages carry your institution’s name. Drafting assistance for a human editor: yes. Unreviewed generation: no.
- Anything that touches member data until your provider agreement explicitly covers it. A membership database is exactly the kind of personal data that AI enthusiasm forgets about.
- Features you cannot explain. If nobody on the team can say what a connected ability does with your content, it should not be connected. That rule has yet to fail us.
The quiet story of 7.0 is that WordPress has taken the position we have been arguing for two years: AI belongs inside your governance, on your infrastructure, under your roles — not bolted on around them. The institutions that treat this release as a governance opportunity, rather than a feature drop, will be the ones that get the time savings without the headlines.
