Why I moved my website from WordPress to Statamic

I moved this website from WordPress to Statamic after five years, and the reason fits in one picture. Customizing WordPress is like operating on a body: every change means cutting into something that was never designed to be opened, then stitching it closed and hoping nothing reacts. Customizing Statamic is like having a zip on that same body. You open it, change what you need, close it, and it opens the same way next time.

This is written for Laravel developers choosing a CMS for their own site or a client's. If you have never opened a code editor, the section on where WordPress is still the right choice is the one for you.

Why customizing WordPress feels like surgery

WordPress is a blogging engine that grew into everything else, and it grew on the outside. A custom field, a new content type, a cache, a reordered admin menu: none of it is the platform's job, so each one arrives as a plugin written by a different team, or as code dropped into a theme's functions.php and hooked into someone else's lifecycle.

Every one of those is an incision. The site works, but it is held together by stitches you did not all make yourself, and every core, theme or plugin update is a chance for one of them to open. My own site was built with Divi, and the problem was never how the pages looked. It was that every change I actually wanted sat underneath the page builder, where it was not built to let me in.

Statamic built WordPress's plugins into one platform

The first thing I noticed in Statamic was how much of my old plugin list I no longer needed, because it was already there. It reads as if someone took every custom part a serious WordPress site ends up with and built them into one product, with one control panel.

Custom fields. In WordPress they come from a plugin such as ACF, with its own field groups, its own screens and its own storage rules. In Statamic they are the core of the product: every kind of entry has a blueprint, a list of the fields it actually has, drawn from more than 40 fieldtypes. You build it in the control panel or write it as YAML, and either way it is a file in your repository.

Caching. WordPress needs a caching plugin with its own settings page and its own rules for when to purge. Statamic ships static caching: switch it on in a config file and pages are served as plain HTML. Saving an entry clears that entry's page, and a few lines of config tell it which listing pages to clear along with it.

The admin menu. Reordering, renaming or hiding items in the WordPress admin is another plugin. In Statamic it is a setting in the control panel's own preferences.

One style for every screen. This is the one I felt most. Every WordPress plugin brings its own admin screen, its own vocabulary, its own banners and its own idea of where settings live, so the dashboard slowly turns into a dozen products sharing a sidebar. In Statamic, an addon or a custom field uses the control panel's own components, so it looks like it was always there.

Adding a custom collection is a breeze

Say you want a new kind of content: articles, case studies, talks. In WordPress you register a custom post type, in code or through yet another plugin:

add_action('init', function () {
    register_post_type('article', [
        'label' => 'Articles',
        'public' => true,
        'has_archive' => true,
        'rewrite' => ['slug' => 'articles'],
        'supports' => ['title', 'editor', 'thumbnail'],
        'show_in_rest' => true,
    ]);
});

That gives you a title and an editor. The fields that make an article an article still come from a custom fields plugin, or from meta boxes and a save handler you write yourself, and the templates are found through WordPress's file-naming hierarchy.

In Statamic the same collection is one short YAML file:

title: Articles
template: articles/show
taxonomies:
  - tags
route: '/articles/{{ slug }}'
date: true
sort_dir: desc

Its fields are a blueprint beside it:

title: Article
tabs:
  main:
    sections:
      -
        fields:
          -
            handle: title
            field:
              type: text
          -
            handle: excerpt
            field:
              type: textarea
          -
            handle: content
            field:
              type: bard

By the way, both the collection and its blueprint YAML files are created automatically by using the control panel interface, you don’t need to build the files yourself. 

Add an index template and a show template and you are done. The route, the fields and the templates all live in files you can read, diff and review in a pull request. This site runs five content collections that way (projects, articles, blog, media and products), each with fields of its own, and adding one takes minutes only.

Styling works like any Laravel app

A WordPress theme is styled through a parent theme, a child theme, the customizer, a page builder's own CSS panel and, too often, an edit made straight on the live server. Knowing which of them wins takes experience you would rather spend on the site.

A Statamic site is a Laravel application, so styling it is Laravel development. Templates are files in resources/views, written in Antlers or Blade, and this site uses Tailwind and Vite like any other Laravel project. I change a template locally, see it immediately, commit it and deploy. When a page needs real logic, it is a controller and maybe a service class exactly as it would be anywhere else in Laravel.

Where WordPress is still the right choice

WordPress is simple for someone who does not write code, and that deserves credit. Install it, pick a theme and start writing, or pick a page builder and drag your sections into place. Hosting for it is everywhere and cheap. If that describes you, you do not need Statamic, and this article is not an argument that you do.

But if you are a Laravel developer and you want a CMS that makes you smile whenever you open it to customize something, instead of one that gives you headaches and eats your time, Statamic is a no-brainer.

What I wish Statamic would change: Pro features sold one by one

Statamic Core is free and covers most of what a site like this needs. It has two limits that matter: one admin user account and one form. Everything beyond that comes with Statamic Pro, which at the time of writing costs $349 per site for the first year and an optional $99 a year after that for updates. Pro bundles unlimited users with roles and permissions, revisions, the REST and GraphQL APIs, multi-site and multilingual, white labelling and Git integration.

The bundle is the problem in my opinion, because a real project rarely needs all of it:

• On one site, I only need the multilingual feature.

• On another, I only need several users with permissions.

• On another, I only need more than one form.

Each time, the client pays for the whole of Pro to unlock one feature of it, and for a small client that price can be the reason a project ends up on something other than Statamic instead.

Statamic already sells a paid feature on its own. SEO Pro is a separate addon, a one-time $75 per site. I would like the Pro features to work the same way: multilingual, users and permissions, and forms each available as an addon of its own, with the full Pro licence kept for the projects that genuinely use everything in it.

Statamic vs WordPress: the verdict

After five years on WordPress, I do not miss the surgery. With Statamic every customization goes through a seam that was designed to open, and closing it afterwards leaves nothing to heal. If you are a Laravel developer choosing a CMS, try it on your own site first: Core is free, and Pro is free while you develop.

The full story of the rebuild, from Divi to the fields and features it runs now, is in the case study of this site. And if you want a Statamic or Laravel site built, or a WordPress one moved across, that is the work I do.