---
title: "Payload CMS vs WordPress: 7 Critical Mental-Model Shifts"
slug: "payload-cms-vs-wordpress-mental-model-shift"
published: "2026-08-14"
updated: "2026-08-18"
categories:
  - "Payload"
tags:
  - "Payload CMS"
  - "WordPress to Payload migration"
  - "Payload vs WordPress"
  - "Blocks field"
  - "Next.js"
  - "collections schema"
  - "wp_postmeta replacement"
  - "block-to-component mapping"
  - "Payload Next.js integration"
  - "Typed fields"
  - "Headless CMS migration"
llm-intent: "reference"
audience-level: "intermediate"
framework-versions:
  - "payload cms"
  - "next.js"
  - "react"
  - "typescript"
  - "wordpress"
status: "stable"
llm-purpose: "Payload CMS replaces WordPress themes with collections, Blocks and Next.js—learn the key differences, wp_postmeta mappings, and start your migration plan…"
llm-prereqs:
  - "Access to Payload CMS"
  - "Access to Next.js"
  - "Access to React"
  - "Access to TypeScript"
  - "Access to WordPress"
llm-outputs:
  - "Completed outcome: Payload CMS replaces WordPress themes with collections, Blocks and Next.js—learn the key differences, wp_postmeta mappings, and start your migration plan…"
---

**Summary Triples**
- (Payload CMS, uses, explicit collections to model data instead of a shared wp_posts table)
- (Blocks field, maps, each blockType directly to a React component for rendering)
- (Presentation, lives in, a Next.js application, not inside the CMS (no theme picker))
- (wp_postmeta, is replaced by, typed fields declared on a Payload collection schema)
- (Taxonomies (wp_terms/taxonomy), map to, relationship fields referencing taxonomy collections)
- (Template hierarchy, is replaced by, block-to-component mapping and application routing)
- (Fields in Payload, are, declared in code at schema definition time (not registered at runtime))
- (WordPress-to-Payload migration, requires, an export-transform-import workflow plus building Next.js renderers for Blocks)
- (Menus, widgets, and theme features, should be, modeled as collections/fields and implemented in the Next.js app)

### {GOAL}
Payload CMS replaces WordPress themes with collections, Blocks and Next.js—learn the key differences, wp_postmeta mappings, and start your migration plan…

### {PREREQS}
- Access to Payload CMS
- Access to Next.js
- Access to React
- Access to TypeScript
- Access to WordPress

### {STEPS}
1. Understand Payload's data model
2. Map WordPress concepts to Payload
3. Design explicit collections and schemas
4. Use Blocks fields for composition
5. Implement block-to-component rendering
6. Plan migration and inventory

<!-- llm:goal="Payload CMS replaces WordPress themes with collections, Blocks and Next.js—learn the key differences, wp_postmeta mappings, and start your migration plan…" -->
<!-- llm:prereq="Access to Payload CMS" -->
<!-- llm:prereq="Access to Next.js" -->
<!-- llm:prereq="Access to React" -->
<!-- llm:prereq="Access to TypeScript" -->
<!-- llm:prereq="Access to WordPress" -->
<!-- llm:output="Completed outcome: Payload CMS replaces WordPress themes with collections, Blocks and Next.js—learn the key differences, wp_postmeta mappings, and start your migration plan…" -->

# Payload CMS vs WordPress: 7 Critical Mental-Model Shifts
> Payload CMS replaces WordPress themes with collections, Blocks and Next.js—learn the key differences, wp_postmeta mappings, and start your migration plan…
Matija Žiberna · 2026-08-14

WordPress developers moving to Payload tend to ask the same question early on: which theme controls how a site looks? I've fielded that question from more than one experienced WordPress team, and it always points to the same gap. Payload organizes a site around three ideas instead: explicit collections that define your data, a Blocks field that defines page composition, and a Next.js application that owns presentation.

This guide walks through that model directly: how WordPress's generic post table compares to Payload's explicit collections, how a Blocks field turns into rendered React components, why there's no theme switcher to look for, and what an honest WordPress-to-Payload migration actually requires.

## The question that gives it away

The theme question carries a WordPress assumption: that a CMS owns the public site and hands out presentation through a theme. Payload works from a different premise. Collections model data. A Next.js application renders it. There's no theme picker in Payload's core, because nothing in Payload plays that role.

Here's the quick map I give teams before we touch any code:

| WordPress concept | Payload equivalent | Key difference |
|---|---|---|
| Post type (`wp_posts` + `post_type`) | Collection | Each collection has its own explicit schema, not a shared table |
| Custom field (`wp_postmeta`) | Typed field on a collection | Fields are declared in code, not registered by a plugin at runtime |
| Taxonomy (`wp_terms`) | Relationship field | Modeled as a typed relationship to another collection |
| Active theme | Next.js application | Presentation lives in application code, not inside the CMS |
| Template hierarchy | Block-to-component mapping | A block's `blockType` selects a React component directly |

The rest of this guide fills in why each row works the way it does.

## Why WordPress developers reach for a theme

WordPress grew from a blogging tool into a general-purpose CMS, and its data model still shows that history. Pages, posts, attachments, revisions, and custom post types all live in the same `wp_posts` table, separated only by a `post_type` column, [as WordPress's own Theme Handbook documents](https://developer.wordpress.org/themes/classic-themes/basics/post-types/). Most custom fields sit in `wp_postmeta` as key-value rows, taxonomies spread across `wp_terms` and two join tables, and plugins add whatever additional tables they need.

That structure is genuinely flexible. A plugin can register a new post type, attach metadata to it, and hand rendering to the active theme, all without touching WordPress core. Years of working inside that pattern train a very specific instinct: put the content somewhere generic, attach fields after the fact, and let the theme decide how it looks. It's a reasonable instinct. It just doesn't carry over.

## What Payload asks instead

Payload describes itself as a config-based, code-first CMS and application framework, and that framing matters more than it sounds. You don't start with a generic bucket and layer meaning onto it later. You start by defining the domain directly.

A site managing products, recipes, and events gets three separate collections, each with its own schema:

```text
Products   → SKU, brand, ingredients, variants, regulatory content
Recipes    → ingredients, instructions, allergens, prep time
Events     → date, location, capacity, related products
```

A Payload collection is a group of documents that share one schema, defined once in TypeScript. From that definition, Payload generates the admin interface and the REST and GraphQL APIs for managing those documents. The question a Payload collection answers isn't "what kind of post is this?" It's "what entity does this application actually manage?"

## Collections model data. Blocks model composition. Components render it.

The next mix-up is treating collections, blocks, and frontend components as the same thing. Each one has a distinct job:

| Concept | Responsibility |
|---|---|
| Collection | Defines a document type and its data model |
| Field | Defines a value, relationship, or validation rule |
| Blocks field | Stores an ordered array of typed content sections |
| Block config | Defines the data editors can enter for one section type |
| React component | Renders that block or document |
| Next.js route | Composes the full page and application shell |

A Payload Blocks field stores an array of typed objects, each with its own schema, so an editor can build a page from sections like a hero, a product listing, or a call to action. Each entry stores a `blockType`, which is exactly the block's slug. The frontend reads that `blockType` and maps it to a React component — this is precisely what the `RenderBlocks` component in Payload's official website template does.

Here's the full pipeline, from request to rendered page:

![Payload page rendering pipeline: request a page, fetch the Page document, read the Blocks field, match block type to component, render in Next.js](./payload-rendering-pipeline.svg)

Payload models the editable structure. Your application renders it. Once that split is clear, most of the remaining confusion clears up with it.

For a working implementation of this exact pattern, see [Payload CMS Next.js: Build One Dynamic page.tsx Route](https://www.buildwithmatija.com/blog/payload-nextjs-single-dynamic-page), which walks through a single dynamic route handling block rendering and tenant-aware queries together.

## There's no theme, because presentation moved outside the CMS

In classic WordPress, the active theme holds template files like `single.php` and `archive.php`, and WordPress picks between them using its template hierarchy. With Payload and Next.js, the public interface is application code: headers, footers, product cards, and design tokens are React components and layouts, full stop.

That split becomes obvious once you draw it:

![WordPress keeps its theme inside the CMS; Payload hands all presentation to an external Next.js application](./wordpress-vs-payload-data-model.svg)

> [!NOTE]
> This can look like a theme system from the outside, especially once a project supports several brands off one Payload instance. It isn't one. There's no built-in theme switch — it's application architecture that a team designs on purpose.

If one Payload installation serves several brands, some components stay shared and others stay brand-specific:

```text
Shared      → product data model, SEO fields, media handling, base blocks
CanPrev     → header, product grid, hero variants, design tokens
Orange Naturals → header, product carousel, hero variants, design tokens
```

The incoming hostname resolves the active site, and site context determines which navigation loads, which design tokens apply, and which block variants editors can use. For guidance on choosing what counts as a tenant boundary in a setup like this, see [Payload CMS Tenant: How to Choose the Right Boundary](https://www.buildwithmatija.com/blog/payload-cms-tenant-durability-boundary).

Asking "where is the theme?" points a project in the wrong direction. The more useful question is which presentation decisions belong to application code, which belong to site configuration, and which editors should control directly.

## Choosing how a listing renders per brand

A related question comes up almost as often: what if one brand shows products as cards and another shows them as a list? In WordPress, the instinct is to look for a separate archive template. In Payload, the decision comes down to who should control it:

| Approach | Who controls it | When to use it |
|---|---|---|
| Variant field on the Product Listing block | Editors, per page | Different pages on the same brand need different layouts |
| Default set in site configuration | Whoever manages that brand's settings | Every listing on a brand should look the same by default |
| Brand-specific component chosen by route | Developers | The decision should never change without a deploy |
| Fully separate route layouts | Developers | Brands share little enough that conditionals would be worse than duplication |

Payload doesn't prescribe one answer here, because this is application design, not CMS theme selection.

## Migrating without reproducing wp_posts

Migration is where the WordPress mental model gets expensive if it survives the move. A weak migration asks how to reproduce every `wp_posts` row and `wp_postmeta` key inside Payload. A stronger one asks what the data actually means, where its source of truth lives, and what the target collection should look like.

That means doing the forensic work first: inventory every post type, taxonomy, and plugin-owned table; measure actual field population instead of trusting the admin screen; identify which fields originate outside WordPress entirely; and only then define Payload collections and relationships. The goal isn't rebuilding WordPress inside Payload — it's recovering the business model WordPress was representing and expressing it cleanly in the new system.

[Complete 2026 WordPress to Payload Migration Guide](https://www.buildwithmatija.com/blog/wordpress-to-payload-migration-guide) covers the step-by-step version of this, including ACF field mapping, HTML-to-Lexical conversion, and keeping redirects SEO-safe.

## FAQ

**Does Payload CMS have a theme system like WordPress?**
No. Payload has no built-in theme or template-selection mechanism. Presentation lives entirely in your Next.js application code — headers, footers, and page layouts are React components you own directly.

**Can I reuse WordPress plugins in Payload?**
Not directly. WordPress plugins are PHP and tied to WordPress's hooks and `wp_posts` structure. Payload's equivalent is a plugin system built for its own config, and most WordPress plugin functionality gets rebuilt as either a Payload collection, a custom field, or application logic in Next.js.

**What replaces wp_postmeta in Payload?**
Typed fields defined directly on a collection. Instead of a plugin registering a meta key at runtime, every field a document can hold is declared in the collection's schema up front, with full TypeScript types.

**Do I need Next.js to use Payload CMS?**
Payload's admin panel and Local API can run without Next.js powering your frontend, but the official templates and most production setups pair Payload with Next.js, since Payload 3.x is built directly on top of it.

**Can one Payload installation power multiple brands or websites?**
Yes. A single instance can serve multiple brands by resolving the active site from the incoming hostname, then using that context to control navigation, design tokens, and which block variants are available — without any of it depending on a theme switch.

## The takeaway

WordPress earned its architecture over two decades of supporting an enormous plugin and theme ecosystem, and it still does that job well for content-first sites. Payload was designed later, for a different job: typed application data with a frontend the engineering team owns outright. Recognizing which job you're actually solving for is most of what makes the switch between them straightforward.

Once that's settled, the rest of Payload reads clearly: collections define what the content is, fields define its structure, blocks define composable sections, and your Next.js application decides how all of it looks.

For a grounded look at what running Payload in production actually involves once you're past this first mental shift, see [Payload CMS in Production: Honest Answers Developers Need](https://www.buildwithmatija.com/blog/payload-cms-in-production-honest-answers).

Let me know in the comments if you have questions, and subscribe for more practical development guides.

Thanks,
Matija

## LLM Response Snippet
```json
{
  "goal": "Payload CMS replaces WordPress themes with collections, Blocks and Next.js—learn the key differences, wp_postmeta mappings, and start your migration plan…",
  "responses": [
    {
      "question": "What does the article \"Payload CMS vs WordPress: 7 Critical Mental-Model Shifts\" cover?",
      "answer": "Payload CMS replaces WordPress themes with collections, Blocks and Next.js—learn the key differences, wp_postmeta mappings, and start your migration plan…"
    }
  ]
}
```