Why WordPress Does Not Work Well in the AI Age
WordPress built the modern web. But its plugin model slows pages down, makes AI agents work harder, and was designed for a time when building custom was expensive. That time has passed.
I have seen plugin catalogs take perfectly good sites from a PageSpeed score of 90 to the 40s. Not from neglect, but from doing exactly what the documentation says to do: install a form plugin, a caching plugin, a page builder, an SEO plugin, and a security scanner. Six plugins. Six codebases that never agreed to work together.
That is the plugin model working as designed. The question is whether the model still makes sense.
WordPress solved content management for a generation. The problem is that it did it in 2003, and the web has changed considerably since then.
What plugins actually cost
A typical business WordPress site runs 20 or more plugins. A 2026 independent benchmark that simulated a realistic business site used 30 active plugins including Elementor, WooCommerce, and Jetpack, and found 126 scripts and 89 stylesheets loading on a single page. Each plugin adds PHP to execute on every request, database queries to run, scripts to load in the browser, and stylesheets to serve whether the page needs them or not. The plugins do not coordinate. A caching plugin and a page builder can fight over output. An SEO plugin adds a full dependency tree to write a handful of meta tags.
On a clean WordPress install, PageSpeed Insights scores near 90. Add a page builder like Elementor or Divi and a realistic set of plugins, and the mobile score drops. That same 2026 benchmark measured a baseline of 63 on mobile and 78 on desktop before any optimization plugin was applied. Google's own Chrome UX Report data, analyzed by Search Engine Journal, found that only 43% of WordPress sites pass Core Web Vitals as of mid-2025, the lowest rate of any major CMS measured.
A Next.js site consistently scores 90 to 100 on PageSpeed Insights, according to multiple platform comparisons published in 2025 and 2026. The difference is architectural. Next.js renders pages at build time and serves them from a CDN edge. There is no PHP execution chain, no plugin stack, no database hit at request time. The page was already built. Delivery is the only work left.
PHP and AI agents
Most AI agents spend their working hours in TypeScript, JavaScript, and Python. That is where the tooling, the community examples, and the training data are most dense. PHP is not gone, but it is not where agents are most reliable.
When you point an agent at a WordPress codebase and ask it to build a feature, the agent has to navigate hooks, filters, action priorities, and plugin interdependencies. It often writes code that works in isolation but conflicts with an existing plugin, or targets the wrong PHP version running on the server. The agent does not know which plugins are active. It cannot see what the filter chain does to the output before the page is served.
I tried this with a simple custom field requirement. The agent produced code that looked correct and broke in production because an unrelated caching plugin rewrote the buffered output before the field could render. Finding the conflict took an hour. Building the feature took ten minutes.
A typed TypeScript codebase with a predictable schema gives agents a much cleaner surface. The types document the structure. The API is a function call, not a filter chain. When the agent builds a block and registers it, the block appears. What you asked for is what runs.
The assumption behind plugins
The plugin model was solving a real problem. Before AI agents, before modern tooling, building a custom feature meant hiring a PHP developer, writing the code, and maintaining it yourself indefinitely. Plugins let non-developers add contact forms, galleries, SEO tags, and security headers without touching code. The tradeoff was performance and complexity, but the alternative was expensive.
The assumption behind plugins is that building custom is slow and costly. That assumption has changed.
A vibe coder can describe a feature to an agent and have a working implementation in minutes. The agent writes TypeScript, reads the schema, and produces code that fits the existing codebase. There is no plugin to install, no compatibility table to consult, and no extra PHP in the request chain. The feature is reviewed, understood, and belongs to the codebase.
When building custom is cheap, plugins are not a productivity gain. They are a collection of dependencies with someone else's security surface, someone else's release schedule, and someone else's judgment about how the feature should work.
What a CMS for this era looks like
A CMS designed for how sites get built now should meet a few requirements.
Content should live in a real database with a typed schema. Agents can read a schema and build on it confidently. They cannot reliably reverse-engineer WordPress's serialized option tables or decode the block grammar inside a third-party builder's output.
The API should be predictable. A function that returns a post is better than a global variable passed through a filter chain. An agent working with a clean API makes fewer mistakes and produces fewer conflicts.
The baseline performance should be high before any optimization. A site should score above 90 on PageSpeed Insights on day one, without configuration, because it serves static pages from a CDN rather than executing PHP on every request.
There should be no plugin directory. If you need a feature, you build it. The agent writes the block, you review it, you ship it. The feature belongs to the project, not to an external package with its own changelog.
The CMS should also be readable by AI tools out of the box: canonical URLs, structured data, a sitemap, an RSS feed, and an llms.txt so that agents indexing or reading the site know what it contains.
Where Slim Minima fits
Slim Minima started from this problem. The existing options were either too heavy, too opinionated, or too raw for a developer who wanted to vibe code a site and hand it off to a client who could actually run it.
The stack is Next.js, TypeScript, and Neon Postgres. Media goes to Cloudinary. Pages are composed from typed blocks. The blog stores posts in the database and serves them as static pages. When you add a feature, you write TypeScript and register a block. The block appears in the admin editor. There is no plugin directory because there is no need for one.
New sites built on Slim Minima score consistently above 90 on Google PageSpeed Insights. That is not from a performance plugin or special CDN configuration. That is Next.js serving pre-built pages from the edge by default.
For AI agent compatibility, the repo ships with an AGENTS.md that tells the agent where to build and what to leave alone. There is also an MCP server, so agents can read and write content directly. The schema is typed, the API is a function, and the codebase is TypeScript throughout.
The real limitation: Slim Minima is not a drag-and-drop builder. Clients can edit page content block by block and publish posts without code, but they cannot restructure layout themselves without involving an agent. For clients who need full layout control on their own, WordPress with a page builder is the better fit. That is a genuine tradeoff and worth naming.
Who should still use WordPress
WordPress is the right choice for several situations.
If your client needs a large plugin ecosystem because the project requires features that would take weeks to build from scratch, WordPress has over 61,000 plugins ready to install. If the editorial team is established and comfortable with Gutenberg or a specific page builder, switching costs real time. If the site runs WooCommerce, migrating to a different stack means rebuilding the store from scratch.
WordPress also has 20 years of documented solutions, a global developer community, and a track record that matters in enterprise contexts.
The problem is not that WordPress is bad. It was built around constraints that no longer apply to a lot of new projects, and the plugin model that solved those constraints adds weight that was not there when those constraints existed. For a new marketing site with an agent-assisted build, those constraints are mostly gone.
Frequently asked questions
Does WordPress always score low on PageSpeed Insights?
A clean WordPress install scores near 90. The score falls as you add a page builder and plugins. A 2026 independent benchmark measured 63 on mobile as the baseline for a site running Elementor and 30 active plugins, before any optimization. Google's CrUX data shows only 43% of WordPress sites pass Core Web Vitals as of mid-2025, the lowest of any major CMS measured.
Are AI agents bad at PHP?
Not bad, but less reliable than with TypeScript or Python. Most agent tooling and training data is concentrated in JavaScript and TypeScript. WordPress's hook and filter system adds complexity that increases the chance of the agent producing code that conflicts with existing plugins or targets the wrong PHP version on the server.
Can you rebuild a WordPress site in Next.js?
Yes, and an AI agent can do most of the work. The strongest case is for simple marketing sites. A WooCommerce migration or a site with complex plugin dependencies is a larger project even with agent help.
What makes a CMS AI-agent friendly?
A typed schema, a predictable API, a readable codebase structure, and documentation written for agents. Slim Minima ships with AGENTS.md and an MCP server for exactly this reason. Canonical URLs, structured data, and an llms.txt help agents that are indexing or reading the site rather than building on it.
Is there a performance difference between WordPress and Next.js that is visible to users?
Yes. The 2026 benchmark found an unoptimized WordPress site with Elementor had an LCP of 5.4 seconds. Next.js sites score 90 to 100 on PageSpeed Insights by default because pages are served pre-built from a CDN. Google uses page speed as a ranking signal, so the gap affects organic search visibility, not just user experience.
Is Slim Minima a WordPress replacement for every project?
No. It is built for vibe coders building marketing sites and handing them to clients who need to manage content without code. It is not a WooCommerce replacement, not a large-plugin-ecosystem replacement, and not a drag-and-drop builder. It is a minimal CMS for a specific kind of project.
Related reading
My verdict
WordPress will not disappear. But the case for starting a new marketing site on WordPress in 2026 is weaker than it was five years ago. The plugin model slows pages down, makes AI agents work harder, and was designed for a time when building custom was expensive. That time has passed for most of the projects where it was always overkill.
If you are starting a new site and you plan to build with an AI agent, the stack matters more than it used to. A typed, database-driven CMS gives agents a clean working surface. A PHP plugin chain does not.