Choosing between WordPress and Next.js without making it a personality test
A practical way to choose a web stack by looking at the people, workflow, and likely changes behind the project.
Developers can turn a technology choice into an identity surprisingly quickly. One person always reaches for WordPress. Another insists that every serious site should be a React application. The conversation becomes much easier when the question changes from “Which tool is better?” to “What does this project need to keep doing after launch?”
I work with both visual platforms and code-first stacks, and neither wins by default. The useful answer usually appears in the operating reality around the website: who updates it, what changes, which systems it depends on, and who will maintain the result.
Start with the person who owns the next update
A site does not stop being a product when it goes live. Someone will need to publish a page, change an offer, replace an image, or connect a new service. The stack should make those ordinary changes feel ordinary.
If a marketing team publishes frequently and wants to work visually, WordPress can be a strong fit. The development work is then less about handing over unlimited control and more about creating useful boundaries: reusable sections, global styles, sensible fields, predictable image ratios, and a preview editors can trust.
If every update needs to become a pull request, that may be reasonable for a developer-owned site. It is less reasonable for a communications team working to its own publishing schedule. A technically elegant repository can still create an awkward organisation-wide workflow.
Next.js makes more sense when the people changing the product already work through a development process, or when changes affect behaviour rather than only content. The important question is whether the normal update path matches how the team actually works.
Separate the publishing system from the frontend
WordPress and Next.js are not exact opposites. WordPress is primarily a content management system with a rendering layer. Next.js is an application framework that can receive content from local files, an API, a headless CMS, or WordPress itself.
Needing an editor does not automatically require a traditional WordPress frontend. A headless setup can combine structured publishing with application behaviour, but it also introduces another system boundary, preview requirements, and deployment coordination.
Two connected systems are justified when they solve two real problems. If conventional WordPress or local MDX already meets the requirements, separating the frontend or adding a CMS only creates more ownership work.
Look at the shape of content and change
“How often will it change?” is not quite enough. A better question is “What kind of change will happen?”
A blog may publish every week while its layout stays stable. A dashboard may publish no editorial content while its interactions evolve every sprint. An events site may keep the same interface but depend on scheduled entries, categories, permissions, and archived content. These are different forms of change even when the visible page count looks similar.
WordPress is useful when content changes often inside known patterns. Posts, landing pages, case studies, and resources can be modelled clearly, then assembled through controlled templates or reusable blocks.
Next.js becomes attractive when the patterns evolve alongside application behaviour. Complex state, authenticated areas, personalised views, real-time data, or tightly coordinated interactions belong more naturally in an application architecture. Using plugins to imitate that architecture can make the boundary between content and product logic difficult to understand.
Before choosing, I want to know which entries relate to each other, who can publish, whether previews matter, and how content moves between environments. Those answers reveal more than a list of page templates.
Count the hidden responsibilities
A custom stack can look clean in a repository while quietly creating work elsewhere. Someone still has to handle previews, images, redirects, user roles, scheduled publishing, search, forms, revisions, and metadata. These features shape whether the site remains comfortable to operate.
WordPress has established answers for many of them, but core, themes, plugins, backups, and security still need an owner. A page builder can simplify editing while increasing the controls and dependencies that require attention.
Next.js has a different maintenance profile: dependencies, hosting, builds, content validation, APIs, and deployment access still need ownership. Even a mostly static site needs a clear publication and recovery process.
Cost should include this continuing work, not only the first build. I compare licences and hosting with developer involvement, editorial friction, upgrades, and handover.
Test integrations at their boundaries
Integration requirements can clarify the decision. A straightforward marketing site may only need forms, analytics, metadata, and an email platform. Either stack can support those needs, so the team and publishing workflow remain more important.
The choice becomes more specific around membership, product data, internal APIs, gated resources, multilingual workflows, or checkout. I look at the source of truth, authentication, error ownership, credential management, and who can diagnose a failure later.
A plugin is not automatically a shortcut, and custom code is not automatically more robust. If an integration forces either platform to behave against its strengths, that is a warning.
Choose a hosting model the team can operate
Hosting is part of the product decision. WordPress expects a database, media storage, backups, caching, and an update strategy. Next.js may use static output, server rendering, functions, or a Node process. Each choice changes deployments, previews, logs, and recovery.
I prefer the model the responsible team can support. Domain and hosting ownership, failure notifications, reproducible builds, backups, and revision recovery should be clear before handover. A sophisticated setup with unclear ownership is less dependable than a modest, documented one.
Compare realistic project shapes
For a company marketing site with several editors, regular landing pages, and familiar integrations, I would begin by evaluating WordPress. Its editorial strengths match the operating model, provided the editing surface stays focused.
For a developer portfolio or documentation site maintained through Git, a statically generated Next.js site with local content may be simpler. There is little value in creating an administration layer when the owner is comfortable editing files and deployments are automated.
For a customer portal with authentication, account state, and data from several services, I would begin with the application requirements. Next.js may fit the frontend, while help pages or marketing content can still come from a CMS.
For a publication with several non-technical authors, approvals, scheduling, and a deep archive, the content operation deserves priority. A code-first frontend can still work, but only if the editorial system and preview workflow are treated as first-class parts of the project.
These are starting points, not rules; their value is making the constraints visible.
Use a practical decision process
Before choosing, I write down who will operate the site, what they will change most often, which integrations carry real risk, and what maintenance somebody must own. I then sketch the simplest credible architecture for each option.
I ask a short set of questions:
- Can the normal editor publish safely without developer help?
- Does the project need content patterns, application behaviour, or both?
- Which responsibilities are solved by the platform, and which are moved elsewhere?
- Can the team operate the hosting and deployment model?
- What is the likely path when the website becomes more complex?
The simplest implementation is not necessarily the one with the fewest files or the quickest first week. It is the one that meets the real requirements without hiding future costs.
Sometimes that is a carefully built WordPress site with a restrained editor. Sometimes it is a statically generated Next.js site with local content. Sometimes it is an application connected to a dedicated content system. The important part is that the stack follows the constraints instead of the developer’s self-image.
Good work is not proved by how much code was written or which logo appears in the repository. It is proved by how comfortably the website continues to work for the people who inherit it.