What Kirby CMS allows that WordPress never will

WordPress is the most widely used CMS in the world. It powers more than a third of the web. Its community is vast, its plugin ecosystem covers almost every need. For a client who wants to manage a blog or a standard showcase site, it is often a reasonable answer.

But for a front-end developer building bespoke sites, WordPress is a permanent constraint. Kirby is a permanent freedom. This is not a matter of taste. It is structural.

With WordPress, the HTML is produced partly by the theme, partly by plugins, partly by Gutenberg. You never know exactly what will be rendered. Unnecessary classes, superfluous attributes, inline styles injected by third-party extensions: the final markup is rarely the one you would have written.

With Kirby, there are only the PHP templates you wrote. The generated HTML is exactly what was intended. Not one extra tag. That is the condition for serious pixel-perfect integration.

In WordPress, the back office is standard. You can customise it with plugins (ACF, Carbon Fields...), but that is a layer on top of a structure that was never designed for it.

In Kirby, YAML blueprints define exactly the fields each page type needs. A portfolio project page does not have the same fields as an article or a contact page. The back office reflects the real structure of the content. Clients only see what concerns them, in the order you decided, with the labels you chose.

That is an admin experience WordPress cannot reproduce without considerable complexity.

Kirby stores everything in text files. No MySQL, no queries, no migrations to manage during deployment. Content lives in folders, readable by any editor, versionable with Git.

Deploying a Kirby site means copying files. Backing up a Kirby site means backing up a folder. Debugging a content issue means opening a text file. This simplicity has concrete value, especially on projects where the client manages their own updates.

WordPress is the number one target for automated attacks on the web. Not because it is poorly designed, but because its prevalence makes it an obvious target, and its plugin ecosystem regularly introduces vulnerabilities.

Kirby has no database to attack, no third-party plugin installed by default, no admin interface accessible at a predictable URL. The attack surface is structurally smaller. For clients who host sensitive data or want to avoid emergency updates at 3am, that is a real argument.

The best tool is the one you do not hear. Kirby does not impose itself. It does not dictate a URL structure, a content format, a way of organising pages. It adapts to the project.

After years of working with both, I always come back to the same conclusion: WordPress is a platform you configure. Kirby is a tool you program. For a developer who wants genuine bespoke work, the difference is fundamental.