Choosing a CMS Is an Editorial Decision
The decision most independent publishers treat as technical is actually editorial. Which content management system you write in shapes how you write, how frequently you publish, what kinds of content feel natural versus effortful, and how much cognitive overhead gets consumed by the platform before any writing happens. Getting this decision wrong is not catastrophic — migration is possible, if annoying — but getting it right from the start eliminates a category of friction that compounds over time.
WordPress is the default choice for a reason. It is the most widely deployed CMS on the internet, which means the largest ecosystem of themes, plugins, documentation, and support forums. For publishers who need flexibility — multiple content types, custom post formats, complex navigation, e-commerce integration, membership paywalls — WordPress’s extensibility is genuinely difficult to match. The editorial interface has matured significantly since the block editor replaced Classic in 2018. For most publishing use cases involving regular contributors or non-technical editors, WordPress remains the practical default.
Its costs are real. A WordPress installation is a running application with a database, a PHP runtime, and a plugin stack that must be maintained, updated, and secured. Attack surface is substantial — WordPress is the most targeted CMS precisely because it is the most common. Performance requires deliberate management: caching layers, image optimization, careful plugin selection. A neglected WordPress installation degrades faster than most publishers expect.
Static site generators — Hugo, Eleventy, Astro — offer a different set of tradeoffs. The output is pre-built HTML: there is no database to attack, no server-side execution at request time, and hosting is trivially inexpensive on platforms like Cloudflare Pages or Netlify. Hugo in particular is absurdly fast to build — a site with thousands of posts compiles in seconds. For publishers with technical fluency who write primarily in Markdown and publish on a predictable cadence, a static site generator eliminates entire categories of operational maintenance.
The limitation is the other side of the same coin. Static sites do not handle dynamic functionality natively. Comments, search, membership, and form submissions require third-party integrations or client-side JavaScript, each adding complexity that partially cancels the simplicity gains. Non-technical contributors will find the workflow — write Markdown, commit to Git, push to trigger a build — opaque without significant setup work.
Ghost occupies an interesting middle position: a purpose-built publishing platform with a cleaner editorial interface than WordPress, native newsletter and membership functionality, and a Node.js architecture that is easier to reason about than WordPress’s PHP stack. It is less extensible than WordPress and less minimal than a static generator, which makes it the right choice for a specific kind of publishing operation — the independent writer or small editorial team whose primary product is long-form content and direct reader relationships.
The honest answer to the CMS question is that the right tool depends on what you are building and how you work. The dishonest answer is any universal recommendation. The useful exercise is to be precise about what your publication actually needs, identify which platform’s strengths align with those needs, and treat the operational costs of each option as real rather than dismissible.