Why Umbraco, and not WordPress

It's the question we get most often: why Umbraco, when WordPress is free and everyone uses it? The honest answer: WordPress starts out cheap and gets expensive, while Umbraco starts out serious and stays manageable. That difference isn't in the core of either system — it's in everything you have to build around it. Prefer the facts next to this argument? See Umbraco vs WordPress: an honest comparison.

Umbraco has it built in

What you solve with plugins in WordPress is part of the system in Umbraco: multilingualism, custom content types and fields, media management, versioning, previews, user roles and permissions. No hunt for the plugin that almost does it, no subscription per feature, no thirty separate parts that all need updating individually.

Your content model follows your organisation

In WordPress, everything is fundamentally a post or a page, and everything beyond that gets bent into shape with custom fields and plugins. In Umbraco you model exactly what you have: a vacancy is a vacancy, a project is a project, a location is a location — with its own fields, its own validation and an editing environment built around it. Editors aren't filling in a form that happens to become a page; they're entering their own content.

Multilingualism is not an add-on

Multiple languages are built into Umbraco: a page exists in variants per language, each with its own publication status and its own workflow. In WordPress that's the domain of translation plugins, with all the integrations, licenses and upgrade dependencies that come with them. Exactly the place where things break when something ever needs to be migrated.

The plugin risk

This is the core of it — and it can be measured. Security firm Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem over 2025, 42% more than the year before. The breakdown:

• 91% was in plugins.
• 9% was in themes.
• In WordPress itself: 6 vulnerabilities, all low priority.

And for 46% no patch was available at the time of publication — the vulnerability was public, the fix was not.

So the problem isn't WordPress's code. It's the stack around it. Every plugin is effectively an extra vendor inside your website: with its own update rhythm, its own quality level and its own chance of being abandoned tomorrow. The more plugins, the bigger the attack surface — and the bigger the chance that an update to one part breaks another.

Source: Patchstack, State of WordPress Security in 2026 (figures for 2025).

To be fair: WordPress tops that list partly because it is by far the biggest platform, with tens of thousands of plugins and correspondingly many researchers looking at it. Umbraco has packages too, and they need maintenance too. The difference is in how many of them you need.

With Umbraco that surface is simply smaller. Less is needed, so less is exposed. And what does get added, we build ourselves, in code that we maintain and carry forward to the next version.

Since Umbraco 14 you can have the site updated through an API

This is the newest reason to pick Umbraco, and right now possibly the most enjoyable one. Since Umbraco 14 the entire backoffice runs on its own Management API: every screen an editor uses talks to that API under the hood. That is something rather different from an API bolted on afterwards — whatever a human can do in the backoffice, a program can do too by definition, because they use the same door. Umbraco ships a machine-readable description with it (an OpenAPI specification), so you never have to guess which fields a page has.

Umbraco 15 made it usable for integrations, with the API user: a user without a password that only signs in on behalf of a system. Such an API user is simply assigned a role, just like a colleague — these sections, these pages, these permissions. An integration that may only update vacancies can only update vacancies.

We saw what that yields first-hand recently. A request came in to refresh the vacancies on our own site, delivered as a Word document. No editor retyping four pages: the document in, the API user over it, and the vacancies were on the site in the right layout. That is exactly what makes this so pleasant — plenty of people find working in a CMS awkward, however good the backoffice is. You hand in what you already had, and it ends up where it belongs. We wrote the whole story up in updating Umbraco without going into the backoffice.

With one important safety valve: writing through the API is not the same as publishing. When an integration updates a page that is already live, Umbraco stores that as a pending change; visitors keep seeing the old version until a human hits publish. The machine does the typing, the editorial team keeps the last word.

An honest note belongs here too: WordPress has an API as well, in core since version 4.7 back in 2016, with built-in application passwords since 5.6. Anyone claiming it cannot be done has not looked. The difference is in how far that API reaches. Posts, pages, media and users are in there — but the very things that make a site its own fall outside it or have to be switched on separately: custom fields (ACF) are off by default in the API, custom content types have to be exposed explicitly, and a page built with a page builder such as Elementor sits in the database as one sealed blob. So an integration hits the wall at exactly the point where a site becomes distinctive. On top of that, a WordPress application password always inherits the full permissions of its user — narrowing it to a single content type is not possible.

When WordPress is perfectly fine

For a blog or a simple site of a few pages, WordPress is an excellent choice, and we're happy to say so. It tips over once structure comes into play: multiple languages, multiple content types, editorial teams with different roles, integrations with other systems, or security and compliance requirements. That is exactly the point where the plugin stack starts to strain — and where Umbraco hasn't even warmed up yet.

Not sure where your site stands? Let us know via the form below — we're happy to think along, even if the answer is "stay where you are for now".