Running a Next.js storefront for WooCommerce in production

Before launch, one host ran everything. Afterwards the storefront deploys to Vercel or another Node host, WooCommerce stays on WordPress hosting, and each side has its own updates, logs and failure modes. Your team keeps the same admin for products, coupons and refunds. What is new is a second deploy pipeline and a dependency between the two: every cache refresh, cart call and checkout handoff crosses from one host to the other.

• Storefront side: Next.js releases, dependency updates, cache rules and the CDN
• WordPress side: core, WooCommerce and plugin updates, PHP version and the database
• Between them: API credentials, webhook secrets and the revalidation endpoint
• On both: uptime checks, because either one going down breaks a purchase

The speed comes from serving pre-rendered pages, and the risk is showing a price or an availability that has since changed. The arrangement that works: catalog content is cached aggressively and invalidated when a product is updated, while price and stock are re-checked at the moment a shopper adds to cart, and again at checkout. A stale page then can never turn into a wrong order. In practice a catalog page can sit five minutes stale and still be safe, while the add-to-cart call is never cached at all. Any supplier who cannot describe how their build handles this has not run a storefront where a promotion changed prices mid-afternoon.

Cache invalidation usually rides on WooCommerce webhooks: a product.updated event posts to the storefront, which checks the X-WC-Webhook-Signature header against the shared secret and revalidates that product's pages. The failure mode is quiet. WooCommerce disables a webhook after five consecutive failed deliveries by default, so a storefront outage of a few minutes, or one bad deploy of the revalidation route, can leave the webhook switched off while the admin looks normal. From then on, edits stop reaching the storefront and nobody is told. Two defenses are worth the setup time. A time-based revalidation on every product page caps how stale a page can get, whatever happens to the webhook. And a daily check that the webhook's status is still Active catches the switch-off before customers do.

WP-Cron is not a real scheduler. It runs only when a request reaches WordPress, and a cached storefront sends WordPress far fewer requests than a theme did, especially overnight. Everything WooCommerce schedules runs through it: the daily woocommerce_scheduled_sales event that starts and ends sale prices, Action Scheduler jobs, and the queued webhook deliveries described above. A sale set to start at midnight can start hours late. The fix costs ten minutes: set DISABLE_WP_CRON in wp-config.php and have the server's own cron call wp-cron.php every minute. Skip this on a store with no scheduled sales and a busy admin team, and you will rarely see the effect; on a store that runs timed promotions it is not optional.

A CSV import that touches 5,000 products can queue one product.updated webhook per product. WordPress then has to send 5,000 HTTP requests through Action Scheduler, and every page they mark stale regenerates on its next visit with fresh calls back into the WordPress API. On modest hosting, that is enough to slow the admin and the cart for everyone at once. Run large imports off-peak, or pause the webhook and revalidate by tag once the import finishes. Which API each template reads from also changes this load; the WooCommerce REST API for headless storefronts page covers that choice.

The frontend can be deployed on Vercel or another Node-compatible host while WooCommerce stays on WordPress hosting. The split lets the customer-facing application use edge caching, preview deployments, rollbacks and modern CI without moving the commerce database. The backend still needs healthy hosting, secure webhooks and reliable API responses. A slow WordPress host stays slow behind a fast frontend, because every API call and every revalidation still waits on it, so fix the host first if that is where the time goes. The trade-offs of running WooCommerce behind Vercel are covered separately.

If WordPress stops answering, already-generated pages keep serving: Next.js keeps the last successfully generated version when a regeneration fails, so category and product pages stay up. Cart, checkout and account pages do not, because they need WooCommerce live. That asymmetry is good for crawlers and bad for monitoring, since a homepage check reports green while nobody can buy. Point uptime checks at the Store API cart endpoint and at the checkout page, not only at the storefront's front door.

Every storefront change ships as a deployment with its own preview URL, so a new product template is reviewed on real catalog data before it reaches customers. On Vercel, Instant Rollback points production back at the previous deployment without a rebuild, so a bad release is undone in the time it takes to click it. Editors previewing unpublished WordPress content on the storefront use Next.js Draft Mode, which has to be wired up once, or the Preview button in WordPress keeps opening the old theme's rendering instead of the storefront. Plugin and WooCommerce updates belong on a staging copy first, since a plugin can change an API response shape the storefront depends on.

Lab scores move on launch day; the numbers that count do not. Chrome UX Report field data is a rolling 28-day window, so the Core Web Vitals report in Search Console shows a blend of old theme and new storefront for about four weeks. Watch the Page indexing report and server logs for 404s from URLs the redirect map missed during that period, and judge LCP, INP and CLS only once the window has turned over.

A storefront is a codebase, and it needs the same care as any other: dependency updates, a place to deploy from, someone who can change it. Budget for hosting the application, a few hours a month of maintenance, and a plan for who responds when a dependency ships a breaking change. Against that, the WordPress side usually shrinks and frontend plugin licenses fall away. You trade a monthly license for control, and control has an owner or it decays. A store that redesigns every few years and has nobody to own a codebase is better off on a well-tuned theme; one that wants the ownership handled can use ongoing maintenance and support instead of hiring for it.