WordPress for Blogs Is Dead, and WordPress Did It to Itself

WordPress for blogs is dead.

Not WordPress as software. Not WordPress as a CMS. Not WordPress for client-managed websites, large editorial teams, ecommerce, memberships, custom admin workflows, enterprise publishing, or the thousand weird use cases where WordPress still earns its keep.

WordPress as the default answer for “I need a blog” is dead. That version of WordPress had a hell of a run, but the world changed, the tooling changed, AI changed the cost of building things, and WordPress somehow responded by getting heavier, more complicated, more enterprise-brained, and less focused on the thing that made it dominant in the first place.

I have been developing WordPress sites since around 2011. Not tinkering with themes. Not installing page builders and calling it development. I mean building WordPress sites from the ground up, writing custom themes, custom plugins, custom integrations, custom blocks, weird migration scripts, fragile client workflows, and all the glue code that makes WordPress work in the real world.

I have shipped thousands of WordPress sites. I have worked on WordPress projects for Fortune 50 companies, members of Congress, legislative committees, advocacy organizations, and plenty of other groups that needed WordPress to do more than publish a few posts and look cute.

So when I say I would not build a blog in WordPress anymore, I am not saying it because I hate WordPress or because I never understood it. I am saying it because I know exactly what WordPress is good at, and a normal blog is no longer one of those things.

My blog is about WordPress, React, Web Components, programming, and whatever technical rabbit hole I am angry about that week. It is not built in WordPress. It is built in Astro.

That feels a little funny at first. A developer who writes about WordPress not using WordPress for his own blog sounds like a cheap dunk. It is not. It is the entire point.

If I were building a complex publishing system for a large organization, I would still consider WordPress. If I were building a site where non-technical users needed a familiar admin, roles, revisions, scheduling, media handling, forms, custom content types, permissions, and a whole ecosystem of plugins, WordPress might still make sense. If I were building WooCommerce, membership functionality, or a client site where the content team lives in the dashboard every day, WordPress might still be the right tool.

But a blog is not automatically a CMS-shaped problem anymore.

That sentence is where a lot of WordPress people are going to get mad, because for years “blog” and “WordPress” were almost the same thought. You wanted to publish posts, categories, tags, archives, feeds, comments, and pages. WordPress gave you all of that. It was cheap, widely supported, easy to install, easy to host, easy to extend, and backed by a massive community.

For a long time, that was enough. More than enough.

It is not enough anymore.

Static sites were always fast, but they used to be annoying

None of this means static sites are new. They are not. Jekyll, Hugo, Gatsby, Eleventy, and plenty of other tools have existed for years. Developers have been yelling about static sites forever, usually with the energy of someone who just discovered that a database query is slower than not doing a database query.

They were not wrong. Static sites were always compelling on performance, security, deployment simplicity, and cost. A pile of generated HTML, CSS, and JavaScript is hard to beat when the job is publishing content.

The problem was never that static sites were bad. The problem was that they were annoying enough to stay niche.

You had to be comfortable with local tooling, markdown, templates, build commands, package managers, deployment pipelines, and the general misery of modern JavaScript ecosystems. Gatsby in particular managed to make “static site” feel suspiciously close to “why is my laptop fan screaming?” Hugo was fast, but not exactly something I would hand to a normal content creator and expect them to enjoy. Jekyll had its moment, but it still lived in a developer-shaped world.

That is why WordPress kept winning. It was not always better. It was easier to justify.

AI changed that equation.

AI did not magically make everyone a good developer, and I do not want to pretend otherwise. You still need taste. You still need judgment. You still need to know when the model generated something stupid. But AI absolutely changed the amount of effort required to create, style, restructure, and deploy a static site.

That matters.

A few years ago, building a custom blog outside WordPress meant you needed to be comfortable doing most of the planning, design, implementation, refactoring, deployment, and content modeling yourself. Now I can use AI to explore the design, generate components, refactor layouts, create content structures, clean up CSS, wire up pages, review performance, and help me iterate in the same environment where the actual code lives.

That last part is important.

Connecting AI to WordPress gives AI access to WordPress. Connecting AI to the codebase gives AI access to the whole product.

The entire workflow is better outside WordPress

Building my Astro blog felt like the opposite of starting a WordPress blog.

With WordPress, the first step is usually compromise. You look for a theme that kind of fits what you want, then you spend the next several hours, days, or weeks undoing the parts of it that do not. The theme has opinions. The theme has styles. The theme has patterns. The theme has layout assumptions. The theme probably has WooCommerce styles even if you will never sell a damn thing. The theme tries to be useful to everyone, which means it starts by being slightly wrong for almost everyone.

Yes, I know you can build a custom WordPress theme. I have done that more times than I can count. That is exactly why I know how much ceremony comes with it.

You still need WordPress running. You still need hosting. You still need a database. You still need local development. You still need deployment. You still need to think about plugins, updates, image handling, caching, security, SEO, and whatever pile of PHP hooks and filters your specific build requires. If you want the site to be fast, you now also get to spend time fighting the weight of the platform you chose before you even wrote anything.

With Astro, I started with the site I wanted.

I was not overriding someone else’s design. I was not inheriting CSS for features I did not need. I was not trying to convince a theme to stop being itself. I was working directly with my content, my components, my layout, and my styles.

That changes the entire feeling of the project.

If I want a new section, I add it. If I want to rethink the way posts are displayed, I do that. If I want to move a component, split a layout, change a design system token, or make the homepage feel more like me, I am not negotiating with a theme, a plugin, and a database-backed admin UI. I am changing the site.

Deployment is the same story. Connect the repo, push to GitHub, deploy the built site. DigitalOcean, Netlify, Vercel, Cloudflare Pages, and plenty of other providers can handle this kind of workflow without turning the whole thing into a fragile production ritual. AI can work locally or in the cloud, help me iterate on a branch, and let me merge when I am happy.

That is a better model for a developer blog than logging into wp-admin and pretending the dashboard is still the center of the universe.

WordPress is still useful, but not for this by default

WordPress people sometimes hear criticism of WordPress as an attack on every use case WordPress still serves. That is not what I am saying.

WordPress is still useful when the CMS is the product. It is useful when the admin experience matters more than the codebase. It is useful when a non-technical team needs to manage content, upload media, schedule posts, review revisions, manage pages, assign roles, and work inside a familiar interface. It is useful when the site is part of a larger business workflow and the plugin ecosystem saves months of custom development.

There are real cases where WordPress is still the pragmatic choice. A law firm site with a marketing team. A university department. A nonprofit with distributed content editors. A WooCommerce store. A membership site. A media organization with approval workflows. A campaign site with forms, landing pages, custom post types, and admin controls for staff who are never going to open VS Code.

Fine. Use WordPress.

The problem is that WordPress people got too used to treating every publishing problem as if it belonged in WordPress. That was convenient for a long time because the alternatives were either too technical, too limited, too ugly, too expensive, or too much work.

That is not true anymore.

A developer blog does not need the full weight of WordPress. A personal technical site does not need a database. An agency owner’s opinion blog does not need a theme marketplace. A simple content site does not need a plugin ecosystem just to publish text, images, code snippets, and links.

• A blog needs to be fast.
• It needs to be readable.
• It needs to be easy to write for.
• It needs to be easy to change.
• It needs to be easy to deploy.
• It needs to stay out of the way.

WordPress used to be the thing that stayed out of the way. Now it often feels like the thing you have to get around.

WordPress forgot its own 80/20 rule

The most frustrating part is that WordPress already had the right philosophy.

WordPress did not win because core tried to do everything. WordPress won because core did enough, the plugin and theme ecosystem handled the rest, and the community made the whole thing feel bigger than the software itself.

The official WordPress philosophy page still says this under “Clean, lean, and mean”:

The core of WordPress will always provide a solid array of basic features. It’s designed to be lean and fast and will always stay that way. We are constantly asked “when will X feature be built” or “why isn’t X plugin integrated into the core”. The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. If we stick to the 80% principle then this should never happen.

We are able to do this because we have a very capable theme and plugin system and a fantastic developer community. Different people have different needs, and having the sheer number of quality WordPress plugins and themes allows users to customize their installations to their taste. That should allow all users to find the remaining 20% and make all WordPress features those they appreciate and use.

That is a great philosophy.

It is also why the current direction feels so disconnected.

WordPress is trying to ship real-time collaboration. WordPress is shipping AI provider connectors. WordPress is building more and more machinery into core-adjacent workflows. At the same time, in the year 2026, you still cannot set a basic meta description value for a page without an SEO plugin or custom code.

That is insane.

Not “slightly annoying.” Not “an interesting product prioritization debate.” Insane.

A meta description is one of the most ordinary publishing fields imaginable. Every normal website owner understands the basic idea of “what text should Google and link previews use to describe this page?” Maybe Google ignores it sometimes. Maybe social platforms use different tags. Maybe SEO people can argue about the exact value. Fine.

But the fact that WordPress can be chasing collaborative editing and AI connectors while punting basic page metadata to plugins tells you everything about the priority problem.

The community side of that bargain is what I unpack in WordPress Forgot Why WordPress Won.

Real-time collaboration is not the 80%

The real-time collaboration work is a perfect example.

The official Make WordPress post on real-time collaboration feedback says the feature is being developed for WordPress 7.0. It also says WordPress VIP customers had beta access starting in October 2025, and that feedback came from larger organizations with multi-person editorial teams across news, media, higher education, research institutions, and enterprise publishing.

That may be valuable feedback. I am not saying those users do not matter. I am saying that when an open source core development post is talking about WordPress VIP customers and large enterprise editorial organizations, the average WordPress user is allowed to wonder who the damn software is being built for.

Real-time collaboration might be great for The Big Important Publishing Team with editors, reviewers, approvals, production workflows, and a dozen people touching the same article. It might be useful for WordPress VIP customers. It might be useful for large media companies and universities.

That is not the 80%.

Most WordPress users are not trying to recreate Google Docs inside wp-admin. Most WordPress users are trying to publish a page, update their homepage, add a post, fix an image, install a form, or figure out why the editor feels slower than it should.

For a normal blog, real-time collaboration is not just unnecessary. It is the kind of feature that makes people question whether WordPress remembers who it is supposed to serve.

AI connectors are the wrong kind of AI

The AI connector work has the same problem.

The Make WordPress post introducing the Connectors API in WordPress 7.0 says the initial focus is AI providers, with standardized API key management, provider discovery, and an admin UI for configuring AI services. It also references built-in connectors for Anthropic, Google, and OpenAI.

That sounds modern. It also sounds like WordPress solving the wrong problem.

Most novice WordPress users are not going to understand API keys, provider billing, environment variables, PHP constants, database-stored credentials, model differences, token usage, or why their ChatGPT subscription does not automatically cover OpenAI API usage. They are going to install something, paste something, get confused, maybe spend money in the wrong place, and end up with a worse version of something they could have done directly in ChatGPT, Claude, or Cursor.

The more technical users have the opposite problem. If you know how to use AI well enough to get meaningful results, why are you trying to cram that workflow into WordPress?

Use AI where the whole project lives.

Use it in the editor. Use it in Cursor. Use it in Claude Code. Use it against your repo. Use it to refactor components, generate layouts, improve content structure, clean up styles, write tests, and ship changes through Git.

AI inside WordPress can help with content. AI inside the codebase can help with the entire site.

That is the difference.

If you do not know how to use AI deeply, WordPress AI connectors probably will not save you. If you do know how to use AI deeply, WordPress probably becomes less necessary for a blog.

That is a brutal place for WordPress to be.

I dig into that mismatch in WordPress AI Connectors Solve the Wrong Problem.

The market is starting to notice

I do not want to overstate market-share data. WordPress is still massive. It still powers a gigantic portion of the web. Nobody serious should pretend it is disappearing overnight.

But the trend is not nothing.

Search Engine Journal recently covered W3Techs data showing five consecutive quarters of modest WordPress market-share decline beginning in 2025. The same piece says WordPress dropped from 43.20% in December 2025 to 41.90% by May 27, 2026.

That does not prove every argument in this post. It does not prove Astro is eating WordPress. It does not prove AI caused the decline. It does not prove the WP Engine fight caused the decline, even though the timing is not exactly flattering.

It does show that WordPress is no longer in the comfortable position of assuming its dominance is permanent.

That is the part WordPress should be worried about.

The threat is not one static-site generator. The threat is not Astro specifically, even though Astro is great. The threat is that the old reasons for choosing WordPress are becoming weaker at the exact moment WordPress is becoming harder to defend as the simple choice.

WordPress used to win by being obvious. Now it has to be argued for.

That is a very different position.

WordPress did this to itself

The sad part is that I still like WordPress for a lot of things.

I like the hook system. I like how much you can bend it. I like how far a good developer can push it. I like custom post types. I like the plugin ecosystem when it is solving the right problem. I like that non-technical users can log in and manage real content without touching code. I like that WordPress made publishing accessible to millions of people and gave an entire generation of developers a way to build useful things quickly.

WordPress mattered. WordPress still matters.

But WordPress for blogs is dead because the job changed and WordPress refused to stay focused.

It kept adding. It kept expanding. It kept trying to become the editor, the page builder, the collaboration tool, the enterprise CMS, the AI integration layer, the design system, the application platform, and the everything machine.

That was never the magic.

The magic was that WordPress was a flexible publishing shell with a massive community around it. The magic was that core did the common things, and the community handled the weird things. The magic was that WordPress gave people just enough structure to publish without turning every site into a software architecture debate.

Now the software feels like it wants to do everything, while the web around it has moved on.

For a blog, I do not want everything.

• I want control.
• I want speed.
• I want a clean design.
• I want simple deployment.
• I want Git.
• I want AI working with the whole project, not trapped inside an admin screen.
• I want to change the site without fighting a theme.
• I want to publish without carrying around a database, a plugin stack, a caching strategy, and a pile of legacy decisions from a platform trying to serve every possible user at once.

That is why my blog is not in WordPress.

And if you are a WordPress developer, agency owner, or long-time WordPress user who feels like the platform has been drifting away from the people who made it successful, I do not think you are imagining it.

WordPress is still useful when you need a CMS.

A blog is no longer automatically a CMS-shaped problem.

That is the problem WordPress has not accepted yet.