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. 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:
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 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, 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
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.
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.
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.
