Next.js + Payload CMS vs WordPress: the 2026 breakdown

Where things stand in 2026: numbers, not opinions

WordPress isn’t dying. According to W3Techs as of July 21, 2026, it runs 41.2% of all websites and holds 59.1% among sites with a known CMS. The nearest competitor is several times smaller. This isn’t a market where the leader is wobbling.

What has changed is the direction. Share peaked at 43.6% in January 2025 and stood at 41.9% in the May 27, 2026 snapshot: down 1.7 percentage points in 16 months (Search Engine Journal). A one-off wobble in a counter is noise, but the monthly series from the same source shows five consecutive steps down, no rebound, and the last step is the largest. One caveat: the May snapshot was taken on May 27 while the others are monthly, so the size of the last step partly depends on the measurement date.

The methodology matters here. Both figures above come from the same W3Techs counter on different dates, based on the Tranco top 10M sample, not from two competing metrics. Always check the snapshot date: without it, any market share is rhetoric, and figures from datasets with a different sample can’t be compared with these.

The share is going to site builders, not frameworks

Year over year (May 2026), Wix gained 0.6 pp, Shopify 0.4, Squarespace 0.2 and Webflow 0.1 (SEJ). All four are website builders and e-commerce platforms, not frameworks. Share counters don’t show why a particular client moves there, and pinning it on a single reason would be speculation.

What is clear: Next.js doesn’t show up in this counter at all, because it isn’t a CMS, and Payload doesn’t register a noticeable share in W3Techs. So the claim that “everyone is moving to Next.js” isn’t supported by the numbers: WordPress’s decline and the choice of a custom stack are two different stories.

Four axes for the decision

Market share answers only one question: will the ecosystem disappear? It won’t. It doesn’t answer “what should we build,” so the decision breaks down into four measurable axes:

None of these axes is settled by “WordPress is more popular.” Each one has numbers for 2025–2026, and that’s what we go through next.

Performance and Core Web Vitals: where the seconds go

Core Web Vitals are the three Google metrics used to assess real visitor experience: LCP (how many seconds until the main element on screen appears), INP (responsiveness to clicks) and CLS (whether the layout jumps). A site “passes CWV” if all three are in the green for 75% of real visits.

According to the 2025 Web Almanac, 45% of WordPress sites pass all CWV on mobile. The web-wide average is 48% on mobile and 56% on desktop. A 3-point gap is within the normal spread between datasets, so a dramatic conclusion would be out of place. The defensible conclusion is more modest and still unpleasant: WordPress doesn’t beat the average web, even though it’s a managed platform and not the long tail of hand-rolled sites.

Where it ranks among platforms, and why it lags

Source: HTTP Archive Core Web Vitals Tech Report, April 2026. It’s a separate measurement with its own sample: you can’t subtract the Web Almanac figure from it and call the difference growth. Both reports agree on one thing: WordPress comes last among the major platforms.

The per-metric breakdown shows where the time goes: 84% have a “good” CLS, so WordPress layouts don’t jump, but only 53% have a “good” LCP (Web Almanac 2025). The chain looks like this: the page is assembled in PHP at request time → slow TTFB (time to first byte) → the browser starts loading the hero image late → poor LCP. Page caching fixes exactly this segment; the only question is whether it’s configured and whether it survives a cache purge. Client-side JS has little to do with it: WordPress core ships very little of it.

What we won’t show you: “WordPress vs Next.js in percent”

No such measurement exists in a primary source. The percentages floating around online contradict each other and are published without methodology; Next.js doesn’t appear in the HTTP Archive CWV tables at all. The comparison itself is methodologically flawed: the Next.js sample skews toward newer projects, while the WordPress sample includes the whole long tail of cheap sites on shared hosting. So the argument below is about mechanism, not percentages.

The mechanism that gives Next.js the edge

The page isn’t rebuilt on every request. SSG serves prebuilt HTML. ISR doesn’t run on a schedule: the visitor always gets a ready page from the cache, and once its freshness window expires, the first incoming request is served that same page while a background rebuild starts. Separately, there’s explicit revalidation by tag or path, for example from a CMS webhook at the moment of publishing.

Next.js 16 adds the Cache Components model on top of this: caching is strictly opt-in through the "use cache" directive, and everything unmarked runs at request time. The difference from a caching plugin isn’t the idea. It’s that each page’s mode is set in code and visible in review, rather than depending on settings that can be accidentally reset. This alone doesn’t guarantee a good LCP: images and templates can eat up the gains.

What a tenth of a second is worth

A 0.1-second speedup gave retail sites an 8.4% lift in conversions, according to “Milliseconds Make Millions” by Deloitte and Google, covering 30M+ sessions across 37 brands. Caveat: the study is about speed in general, not about moving from WordPress to headless. There’s no public case study of a WordPress → Payload migration with measured LCP and conversion; every such figure in agency blogs is published without methodology.

Security: 11,334 vulnerabilities in a year, and why WordPress core isn’t to blame

In 2025 the WordPress ecosystem logged 11,334 new vulnerabilities, 42% more than in 2024. The breakdown turns the usual argument on its head: 91% were in plugins, 9% in themes, and core itself had just 6 all year, all low priority (Patchstack, State of WordPress Security in 2026). Core is fine. The danger is what gets bolted onto it.

The response window is shorter than your update schedule

46% of 2025 vulnerabilities were disclosed publicly with no fix available: for almost half the holes, you learn about them before there’s a way to close them. For the most heavily attacked ones, the weighted median time to first exploitation is 5 hours, and about half of high-severity bugs are exploited within the first day; in 2018 the same window was 63 days (Patchstack). A policy of “we update plugins once a month in a maintenance window” simply doesn’t add up.

The same report demolishes two expensive myths. “Paid plugins are better quality”: premium and freemium plugins had 1,983 vulnerabilities, 59% of them high risk, with three times as many known exploited ones as free plugins. “Our host will protect us”: in penetration tests, hosts blocked only 12% of attacks on WordPress-specific vulnerabilities (Patchstack), due to inconsistent WAF configuration (the traffic filter in front of the site). Read it precisely: that’s the share of attacks blocked, not the share of hosts with protection, and a WAF doesn’t replace updating. All this while new plugins arrive faster than they can be reviewed: for 38.7% of plugins, authors never responded to review feedback (make.wordpress.org).

The other side: what a JS stack risks

Quoting WordPress numbers and none for JS would be cherry-picking. In December 2025, React Server Components turned out to contain CVE-2025-55182 “React2Shell” with a CVSS of 10.0: unauthenticated remote code execution on the server with a single POST request. Two days later it was added to the CISA KEV catalog, confirming exploitation in real attacks. Payload 3 runs inside Next.js and inherits all its CVEs, plus its own: 13 reviewed advisories, 3 of them critical.

Supply chain risk is a class of its own. 2025 was the worst year in npm’s history: the Shai-Hulud worm, the first self-replicating malware in the ecosystem, stole tokens and cloud keys and published infected package versions on its own; its second wave hit 796 packages and leaked secrets from more than 500 developers. And a production Next.js project pulls in hundreds of npm packages through its lockfile, not a dozen deliberately chosen dependencies.

Bottom line: which surface disappears and which appears

The defensible claim isn’t “Payload is more secure” but “the attack surface changes shape.” What disappears is the source of that 91%: third-party public plugins as a mass category (Payload’s catalog is orders of magnitude smaller, and you install a handful, deliberately), PHP execution in production, and mass scanning waves keyed to WordPress signatures. What appears is the supply chain, a CI runner holding production secrets with a blast radius wider than a single site, and the framework’s and CMS’s own CVEs, including critical ones that are fixed with a deploy, not an “Update” button. A WordPress plugin can be patched in a minute from the admin panel; Next.js needs a rebuild, so the vulnerability window here can even be longer.

What doesn’t change is the main thing: the obligation to update fast. Only what you update, and through which process, changes. Without an update policy, dependency audits and CI discipline, switching stacks buys you not security but a different to-do list.

A caveat without which these numbers are misleading: the annual statistics rely on a single vendor that sells WordPress protection, so it counts what it protects against, and there’s no cross-validation. And the denominators aren’t comparable: on one side, an entire ecosystem with tens of thousands of plugins; on the other, one framework and one CMS.

Platform control: who can switch off your updates

Security updates for WordPress plugins and themes reach your site from one place: the wordpress.org servers. That channel has been switched off before, and the precedent is documented.

Timeline: how an entire host got cut off

• September 25, 2024: hosting provider WP Engine was blocked from wordpress.org. Its customers stopped receiving plugin and theme updates, even though they had no part in the dispute.
• October 12, 2024: the ACF plugin (2M+ installs) was forcibly taken over and renamed without its owner’s consent.
• December 10, 2024: a federal court issued a preliminary injunction ordering WP Engine’s access to be restored within 72 hours.

What matters isn’t the cutoff itself but how it ended: reversing it took a court order, not negotiation. A customer who lost security updates had no leverage at all. All they could do was wait for the outcome of someone else’s lawsuit.

The proceedings revealed one more detail: wordpress.org is personally owned by Matt Mullenweg, not by the nonprofit WordPress Foundation. The patch delivery channel for the entire platform is privately owned by one person. And the case isn’t closed: discovery closed on May 14, 2026, no trial date has been set, and it’s expected in late 2026 or early 2027.

The best risk indicator is what the ecosystem itself is doing. The FAIR Package Manager under the Linux Foundation, announced on June 5, 2025, states its goal plainly: remove the single point of failure in the delivery of core, plugins and themes. Alongside it is AspirePress’s mirror of the wordpress.org API, with the AspireUpdate plugin that lets you choose an alternative update source.

The flip side: Payload changed hands too

Payload was acquired by Figma on June 17, 2025; the price wasn’t disclosed. The promise is that the product stays open source and “nothing changes for users in the near future.” One consequence is already visible: as of July 21, 2026, the payloadcms.com/cloud page has neither pricing nor sign-up, only a Figma banner. Managed hosting from the vendor is effectively unavailable, which leaves self-hosting.

But the risk works differently. Payload is released under the MIT license, with the code in an open monorepo: 43,723 stars (snapshot of July 21, 2026). You install updates as regular npm packages. npm is a centralized registry too, and that’s worth admitting honestly. The difference is elsewhere: versions are pinned in the lockfile, an update is a separate step in your build rather than a command pushed to a live site from outside, the registry can be mirrored with standard tools, and MIT code can be forked.

With WordPress, the patch delivery channel is built into the running site, there’s only one, it’s under private control, and there’s already a precedent of it being cut off for an entire host.

The editor experience: Gutenberg vs the Payload admin

The “which is easier for editors” debate comes down to taste. Two measurable questions are more useful: what share of changes can the editor make on their own, and can they break the layout or markup in a way that a search engine notices before they do? WordPress wins on the first and loses on the second.

The WordPress directory has 64,078 plugins, so almost any block can be added without a developer. The price is arbitrary spacing and columns that fall apart on mobile, plus third-party code in every plugin.

In Payload, the content structure is defined in the config: the editor sees specific fields and can’t insert an arbitrary block, new ones are written by developers, and the directory has around 160 plugins. For a small team publishing news and product cards, that’s a plus. For a “we build our own promo landing pages” workflow, it’s a minus.

Everyday editorial work: what’s built in and what you pay developers for

Multilingual: core feature vs paid plugin

WordPress core has no multilingual support, and both standard solutions are paid: WPML sells three yearly tiers, and Polylang Pro is licensed per site. In Payload, localization is built into core and free: you translate fields, not documents, and all languages live inside a single document.

Three caveats are better learned before you start. The decision “this field is translatable” is made once: switching it back changes the data structure and the translations are lost. A locale translates but doesn’t filter: where there’s no translation, the query returns the default language (discussion in the repository). There’s no translation workflow: in WordPress that’s a line on the license invoice, in Payload it’s a line in the development estimate.

Roles and approvals: Payload’s main weakness

WordPress wins this one outright: a Contributor can’t publish, so the “author writes → Pending Review → editor publishes” flow works without plugins. In Payload, roles are ordinary user fields, permissions are defined by access functions, and there are exactly two statuses: draft and published.

A multi-step workflow in WordPress also needs plugins, but there you buy something ready-made, while in Payload you commission development. Payload claws back ground with field-level permissions (the SEO block for the SEO specialist, the price for the category manager) and with document locking: in WordPress core, two authors overwrite each other’s changes.

Where Payload is objectively worse for editors

1. No roles or multi-step approvals: any intermediate status or editorial calendar is custom development.
2. No translation workflow: with several languages and external translators, a WPML license is cheaper than development.
3. Weak admin search: full-text search means listing fields in code and indexing them by hand.
4. Preview is front-end work, and drafts and versions are off by default: if nobody mentioned them at the start, the editorial team will discover they’re missing at the worst possible moment.

Integrations and API-first: one codebase, one TypeScript, zero network hops

Payload lives inside Next.js, not next to it

A CMS and a front end are usually two projects with HTTP in between. Payload 3.x installs inside Next.js: a (payload) route group with the admin panel and API appears in /app (docs). That means one repository, one build, one deploy. The flip side is coupling to Next.js: you’ll have to keep its version within the supported window.

Local API: the same operations, no network

Payload offers REST, GraphQL and the Local API: the first two over HTTP, the third in Node on the server, in the same process.

const payload = await getPayload({ config })
const { docs } = await payload.find({
  collection: 'products',
  where: { slug: { equals: slug } },
})
const product = docs[0] // typed as Product

There are no HTTP requests to the CMS here: payload.find goes straight to the database, with no JSON serialization and no network latency. In the docs’ words, “you don’t need to deal with server latency or network speed whatsoever” (Local API). Caveat: Payload has no “Local API vs REST” benchmarks, only a qualitative claim, and we don’t use numbers from blogs.

A consequence of the typing: there’s no DTO layer between the database and the component, so referencing a renamed field is a build error, not an empty spot on the page. Types don’t update themselves: generate:types is part of the build. REST and GraphQL are still there: a mobile app or a CRM gets data through the API instead of scraping HTML.

A store synced with your ERP: where custom gets expensive

The “one codebase” argument runs into a wall with an online store whose inventory and accounting live in an ERP system. Syncing with an ERP is rarely a simple file export: the site has to implement the exchange the ERP expects, with all its modes and data formats.

Off-the-shelf platforms have already paid for this layer: WooCommerce covers ERP sync and payment gateways with ready-made extensions. Custom builds don’t have it: Payload’s e-commerce plugin is official but in beta (docs), and its only payment adapter is Stripe. Any other gateway, ERP sync or tax receipts means custom development.

The compromise is headless WooCommerce: a Next.js storefront on the free Store API (docs), with the store mechanics handled by extensions. A fully custom store is justified when the product model is non-standard, accounting lives in the ERP, and the budget covers building sync, payments, receipts and inventory from scratch, plus ongoing support.

The database stays yours

Payload runs on MongoDB, PostgreSQL or SQLite (docs). On Postgres, content is stored in a relational schema: a products table with columns, not meta fields in a shared table. The flip side: Payload generates the schema itself, so leaving it means manual work on the schema, and field changes require migrations in CI (migrations).

The entry requirements: Node.js ≥ 20.9.0 and a compatible Next.js (installation), plus a database, file storage, email and a CDN (deployment). None of this will run on cheap shared hosting.

SEO: what’s true and what’s myth

The JavaScript myth

“Search engines don’t index JavaScript” is false: the major search engines have rendered JS for years. But rendering is a separate, deferred step, and not every crawler executes JavaScript at all. That’s why Google’s own JavaScript SEO guide still calls server-side rendering or prerendering a good idea: it makes the site faster for both users and crawlers.

The correct conclusion: server-side rendering is the mode search engines themselves prefer. Next.js serves HTML from the server by default. WordPress also renders HTML on the server and loses nothing here. The loser is the third option: a React SPA without SSR, where the browser receives an empty <div id="root">. That’s what to talk clients out of, and it isn’t a WordPress vs Next.js argument.

Where the difference is real and where it isn’t

It isn’t about the CMS as such: no search engine awards points for a platform, and speed is measured with the same Core Web Vitals whatever the stack (see above).

The real difference is where technical SEO lives. Canonical tags, hreflang, the sitemap, robots rules and Schema.org markup are defined in application code on Next.js: they’re versioned, go through review and ship together with the rest of the code. In WordPress, the same things live in the settings of an SEO plugin, a third-party extension with its own update cycle and its own conflicts with other plugins.

The main risk isn’t the platform, it’s the migration

German agency 4eck Media moved to Strapi + Nuxt and wound the project down by December 2025: organic visibility dropped by more than 90% (a secondary source, retold on an agency blog). That’s not an argument against headless but against a badly executed move: the search engine doesn’t know “it’s the same site,” it sees new URLs without 301 redirects, lost canonical tags and missing markup. That’s why the SEO side of a migration is planned before the first line of front-end code, not after launch.

Three-year cost of ownership, not launch price

The development price is one line out of five: there’s also hosting, support, licenses and incident response. Count 36 months: over that horizon, running costs are comparable to the development budget, while over a single year whoever has the cheaper launch wins.

A caveat we can’t skip: there’s no public methodological study of three-year website TCO. Industry rankings don’t publish price breakdowns by stack. What follows is our own model, built from published agency price lists, with every component tied to its own source and date.

Launch and infrastructure: the ranges overlap

Agency price lists from 2026 put a template site, a custom build, a WordPress site from a studio and a Next.js/React site into brackets that overlap completely. The claim that “Next.js starts where WordPress ends” doesn’t hold up. The spread within each bracket comes down to scope, not stack.

Infrastructure costs have nearly converged: Payload needs a Node runtime, meaning a VPS instead of shared hosting, but an entry-level VPS now costs about the same as a shared plan. Over a month, the difference is a rounding error.

Support: the biggest line over time

Agencies sell basic support packages, comprehensive packages with an SLA, and ongoing development retainers. Over 36 months even the mid tier adds up to roughly the cost of the entire build, and the top tier to several times more. One caveat settles half the arguments: published support rates are the same for any platform, with no separate pricing for WordPress and custom builds. You pay for hours and an SLA; there’s no public data showing that WordPress costs more to support.

What differs isn’t the price but the nature of the work: with WordPress it’s updating third-party plugins and themes, with Payload it’s npm dependencies and schema migrations. It’s not cheaper by definition, only if the process is automated.

A line item that a custom build doesn’t have at all is premium plugins: Yoast SEO Premium, WP Rocket and the like. They’re billed every year, or the updates stop.

36 months: the summary

This is a model based on published price ranges, not a measured sample: the totals are added up from price lists with different sources and dates. It covers a corporate website without a store, since that’s what the cited sources price. Support is deliberately identical in both columns because its price doesn’t depend on the platform. The low end for Next.js was raised to the level of custom development in general. Domain, SSL, content, SEO and later improvements are excluded: they’re the same for both columns.

At the low end, WordPress is cheaper: the Next.js path costs 1.6 times more, even over three years. In this scenario WordPress has no paid licenses and no expensive hosting, and nothing makes up for the difference at launch: the site is simple and support is on the basic plan.

The gap only flips at the high end, and only by 5%: when you need custom design, a full set of plugins and premium support. Five percent over three years is less than a single year of rising development prices, so the honest wording isn’t “Next.js is cheaper to own” but “in the high-end scenario, the difference falls within the model’s margin of error.” The simpler the site, the more the launch price decides, and the less the platform choice can be justified by money.

Headless WordPress: the obvious compromise and its cost

A reasonable objection: don’t change the CMS, keep WordPress as the back end and build the front end in Next.js. It works, but you pay in a different currency.

How it works and what works

Content is served over an API: REST has been built into core since 4.7, and the de facto standard is WPGraphQL, with 30,000 installs. Editors stay in Gutenberg, the archive and roles don’t need migrating, and the front end gets Next.js speed. For a large editorial team, that’s valuable.

Faust.js from WP Engine was supposed to be the bridge to Next.js, but in February 2025 the Faust team stopped being a WP Engine product team, the product became a “Toolkit for Next.js,” and App Router support was deprecated. No end-of-life has been announced.

What breaks

Draft previews. The standard Preview button doesn’t work; WP Engine’s solution only reached 1.0.0 on December 15, 2025.

Front-end themes and plugins. Forms (Contact Form 7 has 10,000,000 installs), page builders and page caching depend on theme rendering, which no longer exists. Blocks arrive serialized: the front end has to render each one.

SEO and ACF go through bridge plugins. The gap is striking: with Yoast at 10,000,000 and ACF at 2,000,000 installs, their bridges have 10,000 and 10,000. Comments and search don’t render: everything that worked on its own in WP has to be rewritten or replaced with services.

What headless doesn’t solve

The installation remains a live PHP system that needs updating, and it has to expose /wp-json/, because that’s its transport. In July 2026 a critical RCE was found right there: wp2shell (CVE-2026-63030), an authentication bypass in /wp-json/batch/v1, patched in 6.8.6, 6.9.5 and 7.0.2. The only fix is the patch; mass exploitation hasn’t been confirmed yet.

The cost

Two hosting bills, two CI/CD pipelines, two domains. A WordPress back end whose hosting grows with traffic, plus Vercel Pro billed per seat for the front end: several times the cost of a single hosting plan.

More expensive than the money is the update chain: WPGraphQL → the ACF and Yoast bridges → Content Blocks → FaustWP → Next.js, each link with its own breaking changes; FaustWP shipped five releases in five weeks.

Who it’s for

A large editorial team with thousands of articles that’s deeply rooted in Gutenberg, or a case where WP is needed as the back end for several front ends. It doesn’t work as a way to “free up marketing”: the effect is the opposite, and changes start depending on developers.

Honestly: when WordPress is the right choice and where Next.js + Payload loses

Four situations where WordPress is objectively better

A short lifespan. A campaign landing page for a year or eighteen months, with no in-house developer: a marketer makes the edits and a contractor is brought in by the hour. A WordPress launch is cheaper, and the savings from Next.js only pay off over a long run that doesn’t exist here.

You need the features in two weeks. Multilingual content, a filterable catalog, sending leads to an email platform: on WordPress these are ready-made plugins from the official directory; on Payload they’re sprint tasks. The community directory has around 160 plugins and not a single theme, and the front end is written in React by hand.

A broad contractor market. There’s no in-house IT team, and the contractor gets replaced every couple of years based on price rather than résumé. On one large job board we checked on July 21, 2026, there were 236 openings mentioning WordPress versus 119 for Next.js.

Mainstream e-commerce. A few hundred products, standard logic (cart, promo codes, card payments) and no programmer on staff. WooCommerce powers 4.53 million of the 13.6 million stores tracked by StoreLeads: its strength is precisely the mass market.

Caveat: job board counts reflect employer demand, not the number of available contractors, and the vendor calculates market share with its own methodology. Treat these as orders of magnitude.

Bus factor: what if your contractor disappears

Three things work in Payload’s favor. MIT and an open monorepo: the code can’t be revoked, and updates are npm packages with versions pinned in the lockfile. A standard database: PostgreSQL or MongoDB can be read with any client. A standard stack: your successor is a TypeScript/React developer, and that market is comparable to PHP’s. On the same job board, 799 openings for PHP versus 790 for React (July 21, 2026).

Against it: a successor has to learn not just React but the specifics of the project, such as Next.js caching, migrations and the Payload Config, and that takes weeks. And you can’t fall back on the vendor: as of July 21, 2026, payloadcms.com/cloud lists no pricing, so self-hosting is the only option.

WordPress’s advantage isn’t the number of people who know it, but how far down the market goes: a typical WP site can be picked up over a weekend by a contractor at any level, down to a beginner freelancer. Nobody knows how many people have hands-on Payload experience; there’s no data. But a WP site gets picked up along with its legacy: a page builder and forty plugins come with the same snowball of technical debt. In practice, the bus factor depends not on the stack but on what the client holds: the repository, access credentials, a database dump, a README. Without those, it’s one everywhere.

What WordPress does well

Auto-updates work: two months after release, WordPress 7.0 runs on 61.05% of installations that report to wordpress.org. Version 7.0, “Armstrong,” brought an AI Client and the Abilities API into core, plus an admin redesign (wordpress.org). And the complaints about security and speed are aimed at plugins, themes and hosting, not at core.

Where Payload is objectively worse

Database schema migrations. According to the docs, on Postgres, when you add a field or collection, the database has to be brought in line with the Payload Config by hand; otherwise you get read and write errors. In WordPress, plugins change the schema themselves.

Entry threshold and hosting. Node.js, TypeScript, React Server Components, Next.js caching: this is developer territory, not a control panel. Shared hosting won’t do: you need a Node runtime.

Maturity. 906 open issues, and version 4.0 hasn’t shipped yet and changes core primitives.

Moving off WordPress is hand-written. There’s no universal importer: Payload’s guide suggests writing your own script, because there are too many WordPress configurations for one tool to handle.

Migrating from WordPress: a step-by-step plan and where it costs you

Step 0. A criterion, not a matter of taste

Migrate only when three conditions hold at once: the site will live for years, not a season; it has real search traffic you’d hate to lose; and integrations are planned: a CRM, an ERP, a catalog, a customer portal. If even one is missing, it’s cheaper to clean up your current WordPress: prune plugins, upgrade PHP, deal with the images.

Steps 1–4. Inventory, schema, content transfer, media

Export the full list of URLs and write down the plugins: not their names, but what each one actually does. Forms, redirects, structured data and custom fields will all have to be rebuilt by hand. At the same time, record a speed baseline: LCP, CLS, INP and, separately, TTFB. It isn’t part of Core Web Vitals, but it’s exactly what drags LCP down on WordPress. Without a “before” measurement, you have nothing to prove the “after.”

Next, define collections, fields and access rules in the Payload Config, and commit the generated types to git: the whole front end relies on them. Content is transferred by a script through the Local API. There’s no universal importer, so it’s always custom work tailored to a specific set of plugins, and it should be a separate line in the estimate.

Where media files physically live is decided before the first deploy. On a platform with an ephemeral file system, local storage is out: the Payload docs put it bluntly, “any files uploaded to your server only last until the server restarts” (Payload). On a VPS with a persistent disk it works, but object storage is easier to back up and survives a move more gracefully.

Step 5. The SEO layer: this is where money gets lost

The riskiest step. You need a one-to-one 301 redirect map from old URLs to new ones, canonical tags, a sitemap, robots rules, structured data, titles and descriptions. Agencies’ estimates of visibility loss after a botched migration are published without methodology: they illustrate the scale of the risk, not a measured probability.

Steps 6–7. Production setup and cutover

Choose where the hosting and database live with your data obligations in mind: any inquiry form means collecting personal data, and personal data protection laws may dictate where it can be stored. On the technical side, payload migrate runs in CI before the build. For a serverless setup, check the Postgres connection pool in advance: exhausting it is a known problem. The cutover happens via DNS, with the old site running alongside for a while; after that, monitor indexing in Google Search Console and other search engines’ webmaster tools, and compare speed against the baseline.

Define the acceptance criterion before you start

Not “it looks nice,” but: rankings preserved, plus a measured improvement in LCP and TTFB. There’s no public case study of a WordPress → Payload migration with disclosed speed and conversion figures, and the numbers in agency blogs are published without methodology. The only honest basis is your own before-and-after measurements.

Quick answers

Is WordPress dying? Should you still consider it in 2026? It isn’t dying: according to W3Techs it remains the most widely used CMS, and the nearest competitor is several times smaller. But its share keeps falling, measurement after measurement, with no rebound: the direction has changed. It’s worth considering where it’s objectively better: a short site lifespan, ready-made features needed now, a broad contractor market, e-commerce on WooCommerce.

How much more does a Next.js + Payload site cost, and when does the difference pay off? At launch, a custom Next.js build is noticeably more expensive than a simple custom WordPress site. That’s an order of magnitude from agency price lists, not an independent study. Over time the biggest line is support: over three years it’s comparable to the cost of the entire build. There’s no universal break-even point: if the site lives a year, look at the launch cost; if three or more, look at running costs.

Is it true that search engines struggle to index React and Next.js sites? No. The major search engines have executed JavaScript for years, and server-side rendering or prerendering is still what they recommend. Next.js serves HTML from the server by default, exactly the preferred mode, just like WordPress. What remains problematic is a React SPA without SSR, where the crawler receives an empty <div id="root">.

Where can a Next.js + Payload site be hosted? Anywhere that runs Node.js: Payload is MIT-licensed and self-hosted, and Next.js is a regular Node application, so a standard VPS or a cloud platform will do. Shared hosting won’t: you need a Node runtime plus a database, file storage and email. Payload’s own managed hosting isn’t available right now, so self-hosting is the way. If the site collects personal data through forms, choose the hosting location with your data protection obligations in mind.

Can a content manager run a Payload site the same way as a WordPress one? Run it, yes; extend it, no. The editor sees only the fields and blocks defined in the config: they can’t insert an arbitrary block, but they can’t break the layout either. For a small team publishing news and product cards, that’s simpler. For a “we build our own promo landing pages over the weekend” workflow, it’s a minus: every new block is a developer’s job, and Payload’s plugin directory is incomparably smaller than WordPress’s.

What happens to Payload now that Figma owns it? Are we heading for vendor lock-in? One consequence is already visible. As of July 21, 2026, payloadcms.com/cloud has neither pricing nor sign-up: there’s nowhere to get managed hosting from the vendor, which leaves self-hosting. But the risk profile differs from WordPress’s: an MIT license, an open monorepo, and updates as ordinary npm packages with versions from the lockfile, not a command pushed to a live site from outside. The real lock-ins are the dependency on Next.js and the fact that Payload generates the Postgres schema itself: leaving means manual work on the schema.

What to do next

1. Check your project against the three migration conditions. A lifespan of years, real search traffic, integrations on the roadmap. If even one is missing, it’s cheaper to clean up your current WordPress: plugins, PHP version, images.
2. Record a baseline before any work. LCP, CLS, INP and TTFB, since TTFB is what most often drags LCP down on WordPress. Without a “before” measurement, you can’t prove the effect “after.”
3. Inventory your plugins. A list of URLs and a list of plugins noting what each one does: forms, redirects, structured data, custom fields. Some will turn out to be dead weight; the rest will have to be rebuilt by hand. That’s a separate line in the estimate, not something “included in the content transfer.”
4. Plan the SEO layer before the first line of front-end code. A one-to-one 301 redirect map, canonical tags, sitemap, robots rules, structured data, titles and descriptions. This is where organic traffic most often gets lost.
5. Plan the production setup and the rough edges. Hosting and database chosen with your data obligations in mind, object storage for media, payload migrate in CI before the build. Separately, keep in mind that Payload 4.0 comes with an admin redesign, so editors will need retraining.
6. Lock in the acceptance criterion before you start. Not “it looks nice,” but: rankings preserved, plus a measured improvement in LCP and TTFB against the baseline from step 2.

If you want an outside view, get in touch: we’ll record an LCP and TTFB baseline for your current site, inventory your plugins and estimate the migration using the steps in this article. Examples of sites we build on Next.js are in our case studies.