WordPress vs. Kirby CMS: Why We Chose Kirby Over WordPress

WordPress dominates the web: 59.1 % of all websites whose CMS we know use it (41.2 % of all websites). But most of those sites are static company pages that don't need a CMS — and for those, you pay with performance costs, security vulnerabilities, and plugin dependency hell.

We use Kirby CMS instead — a file-based, plugin-free CMS that does exactly what it's supposed to, and nothing more.

Why Kirby?

No database, no plugins

Kirby stores content as Markdown files on the filesystem. No MySQL instance, no 37 activated plugins, no monthly security updates for a plugin library that nobody maintains anymore.

• Performance: A Kirby request reads a file, renders it, done. No database joins, no plugin hooks, no cache warmup.
• Security: 90 % of WordPress security vulnerabilities come from plugins. Kirby has no plugin architecture in the classical sense — extensions are PHP classes you control yourself.
• Maintenance: A Kirby update is a git pull. No compatibility checks for 15 plugins, no "your site broke" email the next morning.

File-based instead of admin interface

In Kirby, you edit content directly as Markdown files — either locally in your editor or via the optional Kirby Panel. That has three advantages:

1. Version control: Your entire content is in Git. Every edit is traceable, reversible, branchable.
2. Editor flexibility: Use VS Code, Vim, Emacs — your preferred editor with syntax highlighting, linting, and autocomplete.
3. Deployment: git push to the server. No database export, no media sync, no migration.

Kirby vs. WordPress: The Numbers

The CVE gap is stark: WordPress core has 18,978 vulnerabilities in the NVD, and WordPress plugins add another 17,623. Kirby has 59 total — a 321× difference.

Kirby's built-in page cache and file-based architecture eliminate the database bottleneck entirely. For sites with hundreds of pages, Kirby recommends a nested filesystem structure to maintain performance.

Why Not WordPress?

WordPress isn't a bad product — but it's the wrong tool for static and semi-static websites.

The Plugin Trap

A client wanted a contact form. In WordPress: Contact Form 7 + Flamingo + SMTP plugin + anti-spam plugin + custom CSS for the form layout. Five plugins for one email.

In Kirby: A 20-line PHP script that uses mail() or SMTP. No dependency, no update obligation, no security hole.

Performance Costs

A WordPress request loads the core, initializes the database connection, runs through 15–30 active plugins, executes database joins for menus, sidebars, and widgets, renders the theme, and outputs the result. Result: 200–800 ms.

Kirby: Read file, parse Markdown, render template. 10–30 ms. The difference is measurable — and decisive for SEO and conversion.

Attack Surface

WordPress is a target because:

• 41.2 % of all websites use it → high ROI for attackers
• WordPress core has 18,978 CVEs; plugins add 17,623 more
• Every plugin expands the attack surface
• Many plugins are abandoned (no updates for years)
• Update cycles are irregular across 59,000+ plugins

Kirby has 59 CVEs total — a 321× smaller attack surface. Kirby has no plugin architecture in the classical sense: extensions are PHP classes you write or integrate yourself. The update system can be configured to security-only checks, and there are no abandoned third-party plugins to worry about.

Kirby in Practice

We run several Kirby sites — from corporate pages to blogs to documentation. The workflow:

1. Develop locally: git checkout -b feature/new-page
2. Write content: Create Markdown file, assign Kirby blueprint
3. Test: php -S localhost:8000 locally
4. Deploy: git push origin main → server pulls, Caddy serves

No admin login, no database session, no plugin configuration.

Migration from WordPress to Kirby

The typical migration path:

1. Export content: WP All Export or native XML export
2. Convert to Markdown: Script that converts HTML blocks to Markdown
3. Create templates: Kirby blueprints for each content type
4. Migrate media: Images into content/ folder, adjust paths
5. Deploy: Initialize Git repository, configure server

For 50–200 pages, 2–5 development days is realistic. After that, you have a system that runs maintenance-free.

Conclusion

WordPress is the right choice if you:

• Need a blog with 10,000 articles
• Need complex e-commerce functionality
• Have a team of 50 editors who need an admin interface

Kirby is the right choice if you:

• Have a corporate site with 10–50 pages
• Are self-employed and want a maintenance-free website
• Prioritize performance and security
• Want to work in Git

We've made the switch multiple times — and never used WordPress for a client project again.

Further Reading

• Kirby CMS — official project site
• Kirby Documentation
• WordPress market share — W3Techs
• Kirby vs. WordPress — community comparison