Editor’s note (March 2026): This article is part of Blog Herald’s editorial archive. Originally published in 2009, it has been reviewed and updated to ensure accuracy and relevance for today’s readers.
Back in 2009, the WordPress community was wrestling with a question that seemed fairly technical on its surface: should WordPress MU — the multi-user version of the platform — be merged into core WordPress? At the time, it sparked genuine debate. Some saw it as an obvious step forward. Others worried about bloat, confusion, and the fate of a beloved niche project.
What actually happened is now a matter of record. WordPress 3.0 launched in June 2010, and with it came the feature we now call Multisite. The MU project was folded in, and the blogging world moved on. But revisiting that original debate reveals something worth thinking about — not just as a historical footnote, but as a lens for understanding how platform decisions ripple through the lives of publishers, bloggers, and content creators for years afterward.
What WordPress MU was, and why it mattered
WordPress MU (Multi-User) allowed a single WordPress installation to host multiple blogs. It was the engine behind WordPress.com and Edublogs — two of the largest blog hosting platforms of the era. For most individual bloggers, it was invisible infrastructure. But for anyone running a publishing network, an educational platform, or a content business with multiple properties, it was indispensable.
The problem was that MU and standard WordPress were developed in parallel, maintained by overlapping but not identical communities, and grew increasingly difficult to keep in sync. Plugins written for one didn’t always work on the other. Developers had to choose a lane. The friction was real.
When Donncha O Caoimh, the MU lead developer, announced the merge was coming, he acknowledged what it meant for the standalone project: it would effectively cease to exist. The code would live on, but the MU identity would not.
The case for merging — and why it played out well
The arguments for the merge were straightforward and, in hindsight, correct. Consolidating the codebase meant more developers working on the same underlying functionality. Bug fixes would come faster. Feature parity would no longer be an afterthought. And crucially, the whole ecosystem of plugins and themes would eventually need to work with only one target, not two.
That’s largely what happened. Today, WordPress Multisite — the official name for what MU became — is a mature, well-documented feature used by some of the world’s largest publishing operations. Hachette Book Group runs its catalog sites on it. Facebook uses it for marketing and localization properties. News organizations use it to manage regional editions and topic-specific verticals from a single installation.
For individual content creators and bloggers running multiple properties, the benefits remain compelling: one dashboard, shared themes and plugins, centralized updates, and lower hosting overhead. Managing multiple WordPress sites individually means logging in and out repeatedly, duplicating setup work, and applying the same updates across separate installs — friction that multisite largely eliminates.
The concerns that didn’t disappear
The original skeptics weren’t entirely wrong, though. Their concerns just evolved.
The worry about bloat and complexity was reasonable. Multisite does add a layer of technical overhead that standard WordPress doesn’t have. Setting it up requires editing configuration files. The choice between subdomain and subdirectory structure is made early and is very difficult to reverse. Not all plugins are fully compatible, and even those that are may require more expensive licenses to deploy network-wide.
There’s also the single-point-of-failure problem. With separate installs, if one site goes down, the others remain unaffected. With multisite, a server issue or a bad plugin can cascade across every site in the network. Restoring a single subsite from backup, without rolling back the entire network, is genuinely complex.
The concern about confused users and outdated terminology proved accurate too — just in a different way than expected. The MU brand disappeared, but the conceptual overlap between “a site,” “a network,” and “a subsite” in WordPress still trips people up today. The language of multisite has never been entirely intuitive.
What the platform decision debate still teaches us
What’s worth sitting with here isn’t the technical outcome — that’s settled. It’s the shape of the debate itself, and what it tells us about how bloggers and publishers should think about platform decisions.
When WordPress MU was absorbed into core, individual bloggers gained access to a powerful tool they’d previously never had reason to care about. That’s a good thing. But the conditions attached — that it required careful planning, specific hosting support, and ongoing technical maintenance — meant it was never going to be the right choice for everyone.
In 2025, the question of whether to use Multisite or separate installations is still very much alive, and the honest answer is the same as it was in 2009: it depends on whether your sites genuinely benefit from being connected. If the relationship between your properties is structural — shared users, shared branding, shared governance — multisite is elegant. If your sites are independent projects that happen to share an owner, separate installs will give you more flexibility and fewer headaches.
Platform consolidation tends to produce real efficiencies. But efficiency isn’t the only variable. The original debate about WordPress MU asked whether the gains for the many would outweigh the losses for the few. The merge happened, and broadly speaking, it worked out. But the underlying question — what does this decision cost, and who bears that cost? — is one worth asking every time a platform makes a move that feels obviously good.
Where multisite fits today
For bloggers thinking about running multiple content properties, WordPress Multisite remains one of the more underused options in the toolkit. Content producers can use it to run multiple niche blogs or separate different content types under a single installation — something that was exclusively available to large platform operators before 2010.
The infrastructure has matured considerably. Managed hosts like Kinsta, WP Engine, and Pantheon offer optimized multisite environments with proper container isolation and scaling support. The plugin ecosystem has caught up. Documentation is extensive.
What hasn’t changed is the fundamental calculus: multisite is a tool for a specific kind of problem. If you’re running one blog, it’s unnecessary complexity. If you’re running a network of five or more related properties and the management overhead is already becoming a burden, it’s worth serious consideration.
The merge that felt like a big moment in 2009 turned out to be exactly that — but the ripple effects are still being felt by anyone building a publishing operation on WordPress today. Understanding where that decision came from helps clarify why the platform works the way it does, and how to use it well.
