Headless WordPress handles high traffic well when the public front end is pre-rendered HTML: a Next.js static export serves finished pages from the web server or a CDN, so a traffic spike never reaches PHP or the database. WordPress stays the editing tool, and only the genuinely dynamic parts (forms, search, cart and checkout) still call it, which is where you plan for load.
Why pre-rendered HTML holds up under a spike
On a normal WordPress site, every uncached page view runs PHP, loads plugins and queries MySQL. Page caching helps, but caches get cleared or bypassed by logged-in users and query strings. When a sale email goes out, those uncached requests slow the server down.
With a static front end, the work happens once, at build time. Next.js fetches content from WordPress, renders every page to an HTML file, and the server just sends files. Serving a static file is about the cheapest thing a web server does, and it scales the same way whether a handful or thousands of people open the page.
This is how my own site works. WordPress stays the CMS: I write in wp-admin, Rank Math holds the SEO fields, and forms are handled by WordPress. The public site is a Next.js static export, served by Apache on ordinary shared hosting from a _site folder. Every page is pre-rendered HTML. When content changes in WordPress, a rebuild is triggered, and the new files replace the old ones. Visitors never touch WordPress when they read a page.
What still hits WordPress
Static does not mean everything is static. Anything that depends on the visitor or changes by the second still needs a server. For sale season, these are the parts to load-test.
Forms
Forms post to WordPress (for example a form plugin’s REST endpoint) or to a form service. The page is static; the submission is not. Add spam protection, because bots find exposed endpoints quickly.
Search
Site search can query the WordPress REST API on each keystroke, which puts load straight back on PHP. For a catalogue that changes rarely, a search index generated at build time and searched in the browser removes that load completely. For large or fast-changing catalogues, a hosted search service is the usual choice.
Cart, checkout and account pages (WooCommerce)
For a headless WooCommerce store, product and category pages can be static, but the cart, checkout, payment and “my account” pages cannot. They are personal to each shopper. Common approaches are to call the WooCommerce Store API from the browser for the cart, and to hand the shopper to a WooCommerce-rendered checkout page for payment. Either way, those requests reach WordPress, so the server must still cope with concurrent checkouts. Headless takes browsing off the server; it does not make checkout free.
Stock and prices
A static product page shows the price and stock level at the time of the last build. During a sale, prices change and stock runs out. Either rebuild on every change, or fetch live price and stock in the browser after the page loads, and always let the cart be the final word.
Rebuild-on-publish: keeping static pages current
The workflow that makes this practical:
- An editor publishes or updates a post, page or product in WordPress.
- A small hook in WordPress (a plugin or a few lines in the theme) sends a request to the build process.
- The build runs
next buildwith static export, pulling content from the WordPress REST API or GraphQL. - The new HTML files are deployed over the old ones, ideally switched in one step so visitors never see a half-updated site.
The Next.js setting for a static export is a single line in next.config.js, and trailingSlash matches WordPress’s default URL style:
module.exports = {
output: 'export',
trailingSlash: true,
};Static export has limits you should know before you choose it: no server-side rendering on request, no API routes, no middleware, and no redirects defined in the Next.js config. Redirects move to the web server (an .htaccess file on Apache, or your CDN’s rules). Build time also grows with the number of pages, which matters if a sale needs dozens of price changes in an hour.
Keeping URLs and SEO identical when migrating
A headless migration should be invisible to Google. When I moved this site, the old WordPress URLs were kept identical. My checklist:
- Same URLs, same trailing slash. Crawl the live site before you start and export every URL. After the build, compare the list. Any URL that changes needs a 301 redirect.
- Same titles, descriptions and canonicals. Pull them from the SEO plugin through its API rather than retyping them. Check your SEO plugin’s headless or REST options.
- Structured data. Product, breadcrumb and organisation schema must be output by the new front end. It does not carry over by itself.
- XML sitemap and robots.txt served at the same addresses, listing the front-end URLs, not the WordPress back-end domain.
- Block the back end from indexing if WordPress moves to a subdomain, so the same content is not indexed twice.
- Internal links in post content still point at the old domain if WordPress moved. Rewrite them at build time.
After launch, watch the Pages and sitemap reports in Search Console for a few weeks.
Trade-offs, and when it is not worth it
Headless adds a second codebase, a build pipeline and a deployment step. Things you lose or must rebuild:
- Page builders and many plugins that output front-end HTML (sliders, popups, galleries) do not render on the new front end.
- Draft previews need extra work so editors can see unpublished content.
- Content changes are not instant; they wait for the build.
- Your WordPress developer now also needs to know React and Next.js.
It is usually not worth it when the site is small and a good page cache plus CDN already copes; when most of your peak load is cart and checkout rather than browsing; when editors depend on a page builder for landing pages; or when there is no one to maintain the front end after launch.
It suits content-heavy sites and catalogues with campaign spikes. Two projects in my portfolio show the range: PlantVers Wholesale, a headless WooCommerce and Next.js store, and SwimWay, headless WordPress with forms and integrations.
Timeline: what to do before and after this sale season
- Now to mid-November: do not start a headless migration before Black Friday (27 November 2026). There is not enough time to build, test and let Search Console settle. Instead, check your page caching, CDN and hosting limits, and load-test checkout.
- Black Friday 27 November to Cyber Monday 30 November: record server load, slow pages and any errors. This is the evidence for whether headless would help.
- After Christmas and Boxing Day (25 and 26 December): review the data. If browsing traffic, not checkout, caused the slowdowns, plan the migration for the quiet months so it is stable well before the next sale season.
If you are weighing up a move, my headless WordPress development service page explains how I scope and run these projects.
Frequently asked questions
Can headless WordPress handle Black Friday traffic better than normal WordPress?
For browsing traffic, yes, when the front end is pre-rendered, because page views no longer run PHP or database queries. Cart and checkout still run on WordPress, so a headless store still needs a server that can handle concurrent checkouts.
Will I lose my Google rankings if I go headless?
Not if URLs, titles, descriptions, canonicals, structured data and sitemaps stay the same. Most ranking drops after migrations come from changed URLs without redirects or missing metadata.
Do my WordPress plugins still work with a Next.js front end?
Admin and API-based plugins (SEO fields, custom fields, REST forms) usually do. Plugins that output front-end HTML must be rebuilt as React components or replaced.
How quickly do content changes appear on a static headless site?
As soon as the rebuild finishes and deploys. Build time depends on the number of pages and the hosting, so measure it on your own site before relying on it during a sale.
If you want a second opinion on whether headless suits your store before the next sale season, send me the URL and tell me where it slows down.