The engine underneath is good enough to build the next decade on. The dashboard we all learned on is the part showing its age. Telling the two apart is most of the job.
For about two years, from 2011 to 2013, I helped run eleven newspaper mastheads on WordPress. It was the canada.com portal, on WordPress VIP, and on a heavy news day it carried the sort of traffic that turns a hosting bill into a boardroom conversation. What stays with me all these years later is how seldom the engine underneath got in the way.
WordPress ran a newsroom that size and mostly just worked. The content held its shape. The pages served. The part that showed its age, then and still now, was the screen we sat in front of all day, never the engine behind it.
So here is the question I keep turning over, and I think anyone who publishes for a living should turn it over too. Can you safely bet the next decade of your publishing on WordPress? My answer is yes, with one condition. You have to be clear-eyed about which part of WordPress you are betting on.
Picture an old house with good bones. The foundation is square, the framing is solid, the plumbing and the wiring run everywhere you need them. And then there is the kitchen, laid out in 1985 for one person making toast, and today the whole family cooks in it at once. Nobody in their right mind jackhammers the foundation because the kitchen is cramped. You keep the house and you rebuild the kitchen for the way people cook now. WordPress is that house. The foundation is worth another decade. The kitchen is the conversation we keep avoiding.
The engine is the part worth betting on
Let me spend real words on what WordPress gets right, because the strengths are easy to take for granted once you have lived on them for years.
Start with the data model. Posts, postmeta, taxonomies, the relational structure holding them together. It is clean, it is durable, and it has barely needed to change in twenty years because it was designed well the first time. I have poured a lot of odd content into that model over the years, from straight news to courses to catalogues, and it bends to the shape of the work without fighting me. A good data model is quiet. You only ever notice a bad one, and this is a good one.
Then there is core itself. It is fast, and it is mature in the way that only software with two decades of hard use behind it can be. The edge cases have been found. The performance work has been done. When I ran those eleven mastheads, the platform was not the thing keeping me up at night, and that is a high compliment for any piece of infrastructure.
The REST API matters more than most people give it credit for. It is a real decoupling surface, which means any interface you can imagine can sit on top of WordPress and talk to the content underneath. Most people have only ever seen one way into WordPress, the dashboard. The REST API quietly offers all the others.
And then the openness, which I think matters most of all. WordPress is GPL. You own your data, you can export it, and there is no vendor holding the door shut behind you. Two decades of plugins, themes, hosts, and people who know the system are all sitting there in the open. That is not a small thing. That is the whole reason to build on WordPress instead of renting space inside somebody else’s closed platform.
Those are the bones. They are good bones. I would build on them for another ten years without a second thought.
wp-admin is the part showing its age
Now the kitchen.
wp-admin is a legacy interface, and I mean that with real respect. It was not designed badly. It was designed for a 2005 blog, and then for twenty years we bolted screens and menus and settings onto it one at a time, each one sensible on its own, until the whole thing became a museum of every decision WordPress ever made, good, bad, and indifferent. The threads holding it together are starting to show.
And the museum keeps its old exhibits on display. Post formats arrived in 2011 to let a theme present a post as a quote, an aside, or a gallery, and most themes never really adopted them, but the idea is still wired into the system. The links manager, the blogroll every site once kept, was quietly retired from the menu more than a decade ago and never fully left. Trackbacks and pingbacks still have their checkboxes, mostly catching spam now. Each of these was a fair idea in its moment. Together they are why someone opening WordPress for the first time meets options for things almost nobody has done in years. A twenty-year dashboard has to keep making room for every feature the project ever shipped, including the ones that quietly went nowhere.
Here is the mismatch. That dashboard, built to help one person publish a blog, is now asked to run a newsroom with forty editors, a course platform with a thousand learners, and a shop with real inventory, sometimes all on the same install. It can do those jobs. People do them every day. But the interface was never designed for any of them. Every one of those users is working around the dashboard rather than with it, learning menus that have nothing to do with their actual job, because the dashboard is the only door WordPress ever really finished building.
That is the part aging out. Not the engine. The engine is fine. The way we ask people to drive it is the problem.
I feel this most sitting across from a client. After nearly twenty years building on WordPress, I still cannot honestly justify the full dashboard to a small-business owner who takes one look and feels swallowed by it. So more and more, I just take it away. I build them something that shows only the few things they came to do, and let the rest of wp-admin disappear from their day. They get more done, and they never once miss the menus I removed. I have been quietly building the argument of this piece into real client sites for years, one removed dashboard at a time.
The modern doors already work
Here is the part that should change how you think about the dashboard. wp-admin is not the only way into a WordPress site. It is the oldest and the most visible one, and people mistake visible for necessary. It is neither.
WP-CLI drives the whole system from the command line. The REST API opens the content to any application that asks. Application passwords let a tool authenticate without a person typing anything. And when a site has none of that wired up cleanly, a browser automation can still reach in and do the work a person would have done by hand. In my own practice I lean on those paths every day. An Artificial intelligence (AI) agent I built reaches into a WordPress site through the command line and the REST API and gets real work done, no dashboard in sight.
That is not a someday. It works right now, on the WordPress you already run. Which lets us be honest about what wp-admin actually is: the legacy interface, the one you fall back to when you cannot connect a modern tool, or you just need to fix one small thing in a hurry. A fallback is a fine thing to keep. It is a strange thing to build an entire platform around. The future is already moving through every other door in the building.
The future is purpose-built tools on the engine
Here is where I get genuinely optimistic, because the fix is already visible if you know where to look.
The interface a person uses shapes how they think about their work. I wrote a whole separate piece on how your tools already decided how you work, and it holds double for publishing. Hand an editor the full WordPress dashboard and you have told them their job is to manage a website. Hand that same editor a tool built only for the editing they do, and you have told them their job is to publish. Same engine underneath. Completely different work.
So the future I see is many purpose-built tools rather than one better dashboard for everyone. Each one designed for a single job, all sitting on the same WordPress engine. An editor gets a newsroom tool that knows what a newsroom does and never once mentions the word plugin. A course builder gets a tool for building courses. A shop owner gets a tool for running a shop. wp-admin becomes one client of the platform among many, rather than the platform itself.
You can already see the pull toward this in public. WP Engine Newsroom is an enterprise WordPress publishing platform built around editorial workflow, governance, and analytics rather than around the old dashboard. It is one company reading the same signs the rest of us can read. The people doing serious publishing want a tool for their job, not a tour of the whole system.
What I would build if I had the resources
Let me put my own cards on the table, because opinion pieces should cost the writer something.
If I had real resources to make WordPress publishing sustainable for the next decade, here is what I would do, and I would do it decisively rather than halfway.
Start by separating the interface from the engine on purpose, and treat the REST and data layer as the actual product. The main surface, not a side door for developers. Everything else becomes a client of it.
From there, build purpose-built tools for specific jobs and let them be as focused as they need to be. A real newsroom tool where wp-admin is never in the writer’s way. A course-building tool for the people who build courses. And where a native, app-like experience fits the work better than a browser tab, I would build that and stop apologizing for it. The job decides the shape of the tool, not habit.
And the part I would defend hardest: keep the data model and the openness exactly as they are and treat them as the moat. The whole reason to build any of this on WordPress instead of a slick closed platform is that when you are done, you still own everything and you can still walk out the door with it. The moment you trade that away for a prettier interface, you have just built somebody else’s walled garden with extra steps.
That is the vision. A focused tool for the person doing the job, the WordPress engine humming underneath and keeping the data model, the speed, and the openness, and the dashboard finally allowed to be one option instead of the only one.
Who wins when the interface gets out of the way
This is not an abstract platform argument. It changes the day for real people, and for three of them in particular.
Newsrooms and publishers feel the mismatch most, so they win first. An editor on deadline wants one thing: to get the story right and get it live before anyone else does. A tool built for exactly that, sitting on the WordPress engine, gives them the speed and the editorial guardrails without the tour through settings that have nothing to do with the story. The engine was always up to the newsroom job. Now the interface can be too.
Small business owners win the hardest, and they are the ones nobody builds for. The owner who just wants to update their hours, post today’s special, or add one photo opens the dashboard and feels stupid. That is not their failing. It was built for people who manage websites and handed to people who run bakeries. Give that owner a tool for the one thing they came to do, or let them ask for it in plain language and watch it happen, and a barrier that has kept small businesses at arm’s length from their own websites for twenty years simply falls away.
Schools win in a way that matters more than convenience. wp-admin has real accessibility gaps, and in a school a gap like that is a door held shut. A staff member who relies on a screen reader and a student who works by keyboard deserve an interface built for them from the start, not a legacy dashboard they have to fight. Purpose-built tools can be accessible on the first day rather than the last, and access that used to depend on wrestling the interface can be handled cleanly, even in plain conversation. Accessibility stops being a remediation project and becomes the way the tool works.
The honest risk
I would be doing you a disservice if I told you only the hopeful half.
Here is the tension, and it is the whole point of this piece. If the WordPress world does not build these focused tools, the closed platforms will. They already out-design us on experience, because designing one clean interface for one job is far easier when you own the whole stack and owe nobody an open door. Openness is a real advantage, but it is not a magic one. It does nothing for you if nobody wants to sit in front of your interface long enough to notice they own their data.
That is the race. WordPress can win the next decade of publishing on the strength of its engine and its openness, but only if the interface stops being a reason people leave. The bones are good enough to win with. The open question is whether we build a house people actually want to live in, or whether we keep polishing a kitchen from 2005 and wonder why the family keeps eating out.
Where this leaves you
If you run a publishing operation and you are weighing WordPress against a closed platform for the next decade, my honest advice is to split the two questions the way I have here. Judge the engine on its own merits and it holds up: the data model, the speed, the openness, all still worth betting on. Judge the interface separately, and go looking for the focused tool that fits your actual workflow, whether that comes from the wider ecosystem or from a partner who builds it for you. Helping publishers make exactly that call is a lot of what I do, and you can see how I think about it on my work with publishers page.
Bet on the engine. Be impatient with the interface. The next decade of WordPress publishing depends on us telling those two apart.
Leave a reply