WordPress Holiday Traffic: How to Prepare Your Site for the Peak

To get a WordPress site ready for holiday traffic, serve as many pages as possible from cache, keep the cart, checkout and account pages out of that cache, move images and static files to a CDN, clean up the database and scheduled tasks, and test the site under load on staging. Then freeze changes before the peak so nothing new breaks on your busiest days.

WordPress holiday traffic: why sites break

A WordPress page that is not cached is built by PHP and the database on every visit. That is fine at normal traffic. When a promotion email goes out or Black Friday (27 November 2026) starts, hundreds of people can arrive in the same few minutes, and each uncached request needs its own PHP process. On shared hosting the number of those processes is limited, so the site slows down, then starts returning errors.

The goal is that most visitors never reach PHP, and the requests that must (cart, checkout, account, search) are as light as possible.

Page caching, and what must not be cached

Page caching stores the finished HTML of a page and serves it directly, from your host’s server cache or a caching plugin. Use one page cache, not two stacked.

Cache these

• Home page, category pages, product pages, blog posts and landing pages for logged-out visitors.
• Static files: CSS, JavaScript, fonts and images, with long browser cache lifetimes.

Never cache these

• Cart, checkout and My Account pages, plus any order confirmation page.
• Any request from a logged-in user, including customers and shop managers.
• Requests carrying WooCommerce session cookies such as woocommerce_items_in_cart and wp_woocommerce_session_, so a shopper with items in the basket always sees their own basket.
• Pages with personal data or form nonces that expire.

Most WooCommerce-aware caching plugins exclude these by default. Check the list anyway if you have a custom checkout URL or a quote cart.

This site takes the idea to its end: WordPress stays the CMS, but the public pages are a Next.js static export served by Apache on shared hosting, pre-rendered and rebuilt when content changes. A store does not need to go that far, but the principle holds: fewer PHP requests, more capacity.

Object cache, database and cron

Persistent object cache

A persistent object cache (usually Redis or Memcached) keeps repeated database query results in memory. It helps most on pages you cannot page-cache: cart, checkout, account and wp-admin. Availability depends on your hosting plan, so check before buying a plugin for it.

Database clean-up

Take a backup first, then look at:

• Expired transients left in the options table.
• Autoloaded options: data loaded on every request. Old plugins often leave large autoloaded entries behind after being removed. Site Health may flag this.
• Post revisions and auto-drafts on large content sites.
• Old completed scheduled actions in WooCommerce, which can build into a very large table.

Do this weeks before the peak, not the night before.

Cron and scheduled actions

WP-Cron runs scheduled tasks when someone visits, so on a busy day visitor requests also trigger background work. A common change is to run it from a real server cron job instead. In wp-config.php:

define( 'DISABLE_WP_CRON', true );

Then add a cron job in your hosting panel that calls wp-cron.php every few minutes, for example:

*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Only disable WP-Cron once the server cron is confirmed to be running, or scheduled posts, emails and renewals will stop.

In WooCommerce > Status > Scheduled Actions, check the Pending and Failed lists. A long pending queue before the sale is a warning sign. Move heavy jobs (feed exports, stock syncs, backups) to the night in your customers’ time zone.

CDN and image weight

A CDN serves images, CSS and JavaScript from servers close to the visitor, so those requests never reach your hosting account.

Images are usually the heaviest part of a product page. Before the peak:

1. Check that product and banner images are resized to the size they are displayed at, not uploaded straight from a camera.
2. Serve modern formats such as WebP where your setup supports it.
3. Lazy-load images below the fold, but not the main product image or the hero banner, which affect Largest Contentful Paint.
4. Check new holiday banners, often the largest file on the page.

Measure the result with your own pages. Google’s “good” thresholds for Core Web Vitals are LCP up to 2.5 seconds, INP up to 200 ms and CLS up to 0.1 at the 75th percentile, and the field data in Search Console tells you how real visitors experience your site.

Hosting limits, load testing and monitoring

Know your shared hosting limits

Shared plans cap CPU, memory and PHP or “entry” processes. Hit the cap and visitors see errors. Ask your host which limits apply, where to see usage in the panel, and whether they can be raised temporarily for the sale. Ask now, not on 27 November.

Load testing on staging

Load test a staging copy, never the live payment flow. Start with simulated visitors on cached pages, then add add-to-cart requests, which bypass the page cache. Increase load step by step and note where responses slow and which page type causes it. If staging runs on a different plan from live, treat the results as a rough guide.

Uptime monitoring

Set up an external monitor on the home page and one product page, every few minutes, alerting by email or phone. Add a keyword check on checkout if your monitor supports it. Decide in advance who receives alerts and what they do first.

Timeline and pre-peak freeze

1. This week (from 26 October): confirm hosting limits, check caching exclusions, set up uptime monitoring, and create a staging copy.
2. Before Dhanteras (6 November) and Diwali (8 November) if you sell in India: finish image work, database clean-up and the cron change, then test checkout.
3. Two weeks before Black Friday (by 13 November): load test on staging, fix what it finds, update plugins and themes for the last time.
4. From about 20 November to 30 November (Cyber Monday): change freeze. No plugin updates, no theme changes, no new tracking scripts unless something is broken. Content and prices only.
5. On the day: watch uptime alerts, the Scheduled Actions queue and the hosting usage graph. Place a real test order early in the morning.
6. December: lift the freeze briefly for any fixes, then freeze again from mid-December through Christmas Day (25 December) and Boxing Day (26 December) if those are big days for you.

Take a backup at the start of each freeze and write down how to restore it.

Sites such as the Oakleigh Watches WooCommerce website and the Pleasant View Garden Centre WordPress website are the kind where the busy season matters and the dynamic pages must keep working while the rest is cached. If you want this checklist worked through on your own site, you can hire a WordPress developer for holiday performance work. For store-specific changes such as checkout or order flows, see WooCommerce development.

Frequently asked questions

How do I know if my WordPress site can handle Black Friday traffic?

Load test a staging copy including cart requests, and check which hosting limits you hit. Last year’s peak in your analytics tells you how many visitors to plan for.

Should I cache the WooCommerce cart and checkout?

No. Cart, checkout and My Account pages, and any visitor with items in the basket, must bypass the page cache. Cache product and category pages instead.

Do I need to upgrade my hosting before the holidays?

Not always. Fix caching, images and background jobs first, then load test. If the test still hits your plan’s limits, ask your host about a temporary upgrade for the sale period.

When should I stop updating plugins before Black Friday?

About a week before. Finish updates and testing by mid-November, then freeze from around 20 November until after Cyber Monday on 30 November.

If you want a second pair of eyes on your site before 27 November, send me the URL and what worries you.