WordPress vs Payload

WordPress and Payload solve different operating problems. WordPress is a publishing platform with a visual editor, themes, plugins and a long-established agency and hosting market. Payload is an open-source TypeScript application you install in a Next.js project, configure in code and deploy with its database and storage.

That distinction matters more than the label “headless”. WordPress can serve a headless frontend through its REST API, and Payload can render a complete website. The decision is about model ownership, editing and operations.

The short decision

Stay with WordPress when the team needs to publish pages quickly, relies on Gutenberg or a page-builder workflow, uses WooCommerce, or wants a managed host to carry routine infrastructure. The platform has a wide plugin market and a large pool of people who already know how to run it.

Choose Payload when the CMS is part of a product: a structured backend shared by a web frontend, mobile app, authenticated application or internal workflow. Payload gives developers collections, globals, authentication, REST, GraphQL and a Local API from one TypeScript config. Its official description covers the core model; the Payload concepts documentation explains how those APIs relate to the application.

The answer can also be “keep WordPress and add an API”. A REST endpoint does not require replatforming.

Editing, page building and governance

WordPress puts the editor at the centre. The Block Editor stores structured blocks, while the Site Editor lets users work with templates, template parts, navigation and patterns when the active theme supports them. Patterns are useful starting layouts. Current WordPress documentation distinguishes regular patterns, which become editable page content, from synced patterns, whose linked uses can update when the pattern changes. The Block Editor architecture guide documents that distinction.

That flexibility suits campaign teams and publishers. The delivered editing experience is the sum of the active theme, block settings, custom blocks and plugins. A visual page-builder site has a different governance and exit profile from a restrained core-block site. Test the actual editor with the roles your team will use.

WordPress supplies autosave, revisions and a Preview in new tab flow. Roles and capabilities cover common author, editor and administrator boundaries. Approval chains, granular editorial stages, field-level restrictions and audit requirements often come from plugins or custom code. The roles and capabilities documentation is the baseline; the installed extensions decide how far it goes.

Payload gives you a generated admin panel shaped by your config. A developer can add blocks, custom React components, validation and conditionally visible fields. When Versions are enabled, Payload can retain history, show diffs and restore a document; the version record includes the user who made the change according to the Versions documentation. Drafts add a separate unpublished state, access rules and scheduled publish options. Live Preview renders the frontend in an admin iframe and can use the unsaved document data, as the Live Preview documentation describes.

That is strong governance when the team wants a code-reviewed workflow. It is a build decision too. Someone has to design the editorial UI, define who can publish, decide which fields are localized, and maintain the preview route. Payload provides the primitives; your application or delivery partner supplies the policy.

Content model, APIs and product backends

WordPress’s standard content types are posts, pages, media and taxonomies. Custom post types and taxonomies can be exposed through the REST API by registering them with show_in_rest: true; custom fields need their own exposure and authentication decisions. The REST API handbook describes the public/private boundary and the API’s role in the Block Editor. GraphQL is available through established plugins, with schema and operational decisions attached to that plugin.

Long-lived sites can accumulate plugin tables, post metadata, shortcodes and block types. Inventory that history before estimating a move.

Payload collections and globals are declared in TypeScript. The same config drives the admin panel and generated REST and GraphQL APIs, while the Local API can call the backend directly from server code without an HTTP hop. The Local API bypasses access control by default: calls acting on behalf of a user need the appropriate user context and overrideAccess: false to enforce their permissions. Payload supports Postgres, MongoDB and SQLite through its database adapters. This is a useful shape for a product team that wants schema changes, access rules and API behaviour reviewed in pull requests.

Payload is also a backend toolkit. Its documentation lists authentication, uploads and access control alongside CMS features. That makes it suitable for an application with business rules. It does not make every integration automatic. Search, payments, email, translation providers and specialised commerce workflows still need a deliberate design and a maintained integration.

Permissions need a tier check. Payload’s core Access Control supports collection, global, field and operation rules, and the default behaviour requires an authenticated user. Payload’s enterprise page separately lists SSO and publishing workflows. A team should record which requirement is handled by core configuration, which needs application code, and which needs an enterprise agreement. The Access Control documentation also makes the enforcement boundary clear: rules run for operations, while Local API callers must choose carefully whether to keep or override them.

Commerce is the clearest boundary. WooCommerce gives WordPress a mature product with extensions, payment gateways, tax and fulfilment integrations. Payload can model commerce and connect to services, and its ecosystem includes commerce examples, but choosing it means owning the domain model and integration work. Treat Payload as a replacement only when that engineering ownership is the requirement.

Localisation and editorial operations

Payload localization is field-level. You declare the locales, mark the fields that vary, choose fallback behaviour and can flag right-to-left locales in configuration. The localization documentation says there is no documented limit on the number of locales. That precision is useful for products where a title, summary, slug, image caption and body have different translation rules.

WordPress core handles the language of the installation and provides the foundation for sites and networks. Multilingual content, translation memory, language-specific URLs and translation workflow are commonly supplied by plugins or multisite architecture. That market is broad, but evaluate the exact plugin’s data model and export path. A multilingual requirement is a workflow decision, not a language-selector checkbox.

Hosting, security and responsibility

With WordPress.org, you choose the host and carry the runtime: PHP, database, uploads, backups, updates, caching, hardening and plugin compatibility. A managed WordPress provider can package much of that work. WordPress.com is a different service with its own plans and restrictions; its current pricing page lists hosting, security protections and automatic core updates in the managed bundle, alongside plan-specific storage and plugin access. Use the live plan page for a quote because prices and inclusions change.

Payload is MIT-licensed and can run anywhere that supports its application and database. Payload’s production guidance calls out the database, persistent file storage, email provider and CDN as separate deployment concerns, with adapters for providers such as S3 and Vercel Blob. Read the deployment documentation as an operating checklist. Payload Cloud deployment of new projects is currently paused following Payload’s move into Figma; existing Cloud projects continue to run, and Payload confirms that self-hosting remains supported in its Cloud update. A delivery partner or internal platform team can run the deployment, with backups, access, upgrades and incident ownership set in the operating agreement.

Security follows the same boundary. WordPress security depends on the host, core, theme and plugin update chain. Payload supplies authentication and access functions, while your team secures the app, secrets, database, storage and deployment pipeline. Ask both vendors and partners where logs, backups, patching and response live, then write those answers into the operating agreement.

Cost and migration checks

WordPress.org software is GPLv2 or later and Payload core uses the MIT licence. Neither has a core software licence charge in the ordinary self-hosted setup. The comparison needs at least hosting, database, file storage, CDN, email, backups, monitoring, security maintenance, paid extensions, engineering time and exit work.

WordPress.com offers a managed baseline with hosting and protection included. Payload’s free open-source core leaves infrastructure and engineering as explicit lines, and a delivery partner can own that operating work. Payload lists SSO and publishing workflows among enterprise features, so verify which capabilities belong to the core, your build or a commercial agreement before pricing. Price the same editors, locales, environments, traffic, media volume and retention period on both sides.

Migration cost is driven by the estate’s shape. Inventory custom post types, wp_postmeta, ACF fields, Gutenberg and third-party blocks, shortcodes, media, authors, comments, taxonomies, plugin tables and the live URL set. Preserve old URLs with a redirect map and test structured data, canonicals, feeds, sitemaps and language alternates. The WordPress migration reference covers extraction and transformation detail; the CMS migration guide covers the staged playbook. This comparison keeps the decision boundary separate from those implementation instructions.

Which team should choose which?

Pick WordPress for a content team launching a conventional site, a publication with established editorial habits, a marketing organisation that needs a page builder, or a business that depends on WooCommerce extensions. It is also the sensible choice when the current site works and the proposed benefit is only that another CMS feels newer.

Pick Payload for a TypeScript team building several channels from one model, an application with domain-specific permissions, or an organisation that wants schema and infrastructure decisions in its own repository. Budget for product engineering and operations from day one.

Before choosing, ask each option to demonstrate the same workflow: create a structured page, save a draft, preview an unsaved change, route it through review, publish a scheduled locale, restore a previous version, expose it to a second frontend and remove an editor. Record every manual step, extension, API call and owner. The result will tell you more than a feature checklist.

Two realistic decision scenarios

An established publisher with WordPress investments. A publisher has a decade of posts, an editorial team that uses the Block Editor daily, ACF fields for its section pages, and WooCommerce subscriptions. Its priority is a new language and a faster preview environment. The first recommendation is to keep WordPress: the existing content, commerce extensions and editor are productive assets. The team can add a multilingual plugin, tighten its block and role rules, and put a managed host in charge of updates and backups. A migration to Payload becomes reasonable only if the second language exposes a model shared by an app and several regional frontends, or if plugin and custom-field maintenance is already blocking releases. A new typed API alone does not justify moving the subscription system.

A multilingual product team starting from a clean model. A product company is launching a Next.js application, an authenticated partner portal and a public marketing site in four locales. Editors need field-level permissions, preview against the real frontend and scheduled publishing. There is no WordPress estate or WooCommerce dependency. Payload is a strong fit because the collections, access rules, REST/GraphQL APIs and admin UI can share one TypeScript codebase. The team still needs a hosting owner, persistent media storage, email, backups and an editorial workflow. If procurement later requires SSO and a packaged approval process, the enterprise feature boundary can overturn the initial recommendation: the team should price that agreement or compare a managed WordPress service with the required extensions before committing.

The scenarios are illustrative. Test the actual team, integrations and compliance requirements before treating either decision as a template.

A buyer’s evaluation checklist

Start with the content team. Give editors a page brief containing a reusable section, an image with focal-point and alt-text requirements, a related item and two locales. Ask them to draft, review, preview and schedule it. Count the clicks, outside tools and administrator actions.

Then give the brief to engineering. Ask for the API response used by web and mobile, the schema change for one field, the permission rule that keeps contributors from publishing, and the rollback procedure. Include the actual WordPress theme/plugins or Payload config and deployment pipeline. A generic demo hides recurring decisions.

Record operational answers alongside feature answers:

• Who patches the runtime, database and extensions, and how is an urgent security update tested?
• Where do media, backups, logs and secrets live, and how is a restore rehearsed?
• Which integrations are licensed, which are custom, and who owns them after launch?
• What is the export format for content, relationships, users, media and redirects?
• Which team owns the frontend preview, search indexing, cache invalidation and scheduled jobs?

The choice is sound when the winning system makes recurring work visible, assigns it to a capable owner and fits the team’s publishing habits. A demo that skips those questions is incomplete.

A note on our position

WAYF is a Payload Partner agency and contributes to its open source, so we have an interest in this comparison. We use Payload when its code-defined model, APIs and application ownership fit the product. We also recommend keeping WordPress when its editor, plugins, commerce ecosystem and operating arrangement are the better match. A delivery partner can run either stack; the choice should follow the client’s content model and operating requirements.

If you choose Payload, WAYF’s Payload development service covers the build. For a move from an existing CMS, plan the replatforming around the content, infrastructure and editorial controls that need to move.