Black Friday 2026 Site Readiness: 3-Week Checklist

TL;DR

Black Friday is on 27 November 2026 and Cyber Monday on 30 November. With about three weeks left, focus on the path that earns money, not the homepage: product page, cart and checkout. Freeze scope in week one, cut third-party scripts, load-test the whole purchase journey, check payments and stock sync, and set up monitoring and a rollback plan. The timeline table below is built for a late start; you fill in the pass/fail thresholds from your own baseline.

Peak weeks rarely break a store because of the homepage. They break it at checkout, in a payment callback, in a stock sync or because of a script nobody remembers adding. So the plan below looks at the purchase path and at change control more than at design.

Why peak weeks break stores

Traffic arrives in bursts, often right after an email or an ad goes out, not smoothly across the day.
Checkout is the most fragile part: it depends on payment providers, stock, shipping rules, discount logic and several scripts at once.
Teams make late changes. A new banner, a discount app or a tracking tag added in the last week is a common cause of trouble.
Nobody owns the whole path. Marketing, development and operations each look after a piece.

Name one person who owns the sale readiness and one who has authority to say “no” to late changes.

T-21 to T-0 timeline

You can copy this table and fill in your own thresholds from your last campaign or a normal week. We do not give universal numbers, because they depend on your platform, catalogue and traffic.

When	Goal	Checks	Your threshold (fill in)
T-21 to T-18 (about 6 – 9 Nov)	Baseline and scope	Record current speed on home, category, product, cart, checkout. List every script and app. Write the sale calendar.	Baseline numbers saved
T-17 to T-14 (10 – 13 Nov)	Freeze scope	No new features after this date except fixes. Decide who can approve exceptions.	Freeze date agreed
T-13 to T-10 (14 – 17 Nov)	Weight and scripts	Remove or defer third-party scripts and apps you do not need. Compress images. Check caching.	Weight / script count target
T-9 to T-7 (18 – 20 Nov)	Load test	Test the full journey: browse, add to cart, checkout, pay. Raise load in steps until it degrades.	Max load before errors
T-6 to T-4 (21 – 23 Nov)	Payments, stock, discounts	Test every payment method. Check stock sync. Test discount stacking and codes.	All tests pass
T-3 to T-1 (24 – 26 Nov)	Launch prep	Monitoring, alerts, on-call roster, rollback plan, status page, customer support briefing.	Alerts firing in a test
T-0 (27 – 30 Nov)	Run	Watch three times a day. Only planned changes.	Daily review

If you are starting later than this, see “Late-start variant” below.

Set targets from your last campaign and the forecast

Before you test anything, you need a target for what the store must handle.

Take the highest-traffic day you have had (a past sale, a big email) and note sessions per hour and orders per hour.
Add a margin based on the extra spend you plan. If ads budgets will go up (see our ads checklist), traffic will rise too.
Define peak behaviour, such as how many people check out at once, as a proportion of sessions you can see in your analytics.

Use these as test targets, not as promises. If you have no history, test in steps until something breaks and use that as your known limit.

Week 1 of the plan: freeze scope and audit scripts

Freeze scope. After the freeze date, only fixes. Ask for a written reason for every exception.
List every third-party script and app. Include tag managers, chat widgets, review apps, A/B tools, retargeting pixels and personalisation tools. For each one, ask: do we need it during the sale, and what happens to checkout if it fails?
Remove or defer what you do not need. Fewer scripts mean fewer failure points and often faster pages.
Lock tracking. Do not change analytics and ad-tag setups in the last week. If you use server-side tracking, check it is stable; see server-side tracking with Google Tag Manager.

Week 2: load-test the full journey

A test that hits only the homepage tells you little.

Test the whole path: browse, search, add to cart, apply discount, checkout, pay.
Do it on a staging copy with real-looking data, not on live checkout with real payments.
Raise load in steps and note where errors or slow responses start. That point is the “knee”: your known limit.
Check what happens above the limit: a queue, a clear error message or a crash.
Follow your platform’s guidance. Hosted platforms often restrict load tests or handle capacity for you, so read the vendor’s rules before testing and ask support if unsure. This matters for hosted checkouts.

Record the result and compare it with the target you set earlier.

Week 3: payments, stock and discounts

Payment methods: test every enabled method end to end, including failed payments, 3-D Secure steps and refunds. Consider whether a second payment option makes sense if your main provider is a single point of failure. Check your provider’s status page and limits in their documentation.
Stock sync: make sure stock updates between your warehouse, ERP and store. Overselling at peak is expensive.
Discount stacking: test combinations of codes, automatic discounts, gift cards and free-shipping thresholds. Errors here cost money quickly.
Shipping and delivery messages: cut-off dates and delivery estimates should be accurate and visible.
Emails and notifications: order confirmations and shipping emails should send correctly under load.

Core Web Vitals on cart and checkout

Speed matters most where people pay. Google’s published “good” thresholds, from web.dev, are:

Largest Contentful Paint (LCP): 2.5 seconds or less.
Interaction to Next Paint (INP): 200 milliseconds or less.
Cumulative Layout Shift (CLS): 0.1 or less.

Measure these on product, cart and checkout, not just on the homepage, and use field data where you have it. Common causes of poor results on checkout pages are heavy scripts, large images, layout shifts from late-loading banners and slow responses from third parties. For fixes, see our developer-friendly guide to Core Web Vitals and technical SEO for Core Web Vitals.

Launch week: monitoring, rollback and on-call

Monitoring: uptime checks on key pages, error-rate alerts, checkout conversion tracking and payment failure alerts.
Rollback plan: know how to revert the last deployment and who can do it. Rehearse it once.
On-call roster: a named person for each of development, operations, payments and customer support, with a backup, for the sale days.
Status communication: a plan for what you tell customers if something fails.
Feed and ads alignment: product data and prices in your shopping feed should match the site. See the Performance Max audit checklist and Merchant Center setup.

Cyber Monday day-of monitoring box (30 Nov)

Check at three fixed times and record what you saw.

09:00: site up, checkout works with a real test order, payment methods respond, stock looks right, no spike in errors.
14:00: checkout conversion rate against the day’s normal, failed payments, slow pages, support tickets mentioning the site.
21:00: orders against plan, stock-outs, anything to fix before tomorrow, and a note for the after-event review.

Late-start variant: if you have one week left

If you are reading this close to the event, do this in order:

Freeze changes today.
Remove scripts you do not need.
Test checkout and every payment method manually.
Set up uptime and payment-failure alerts.
Write down who is on call and how to roll back.

Skip anything that needs a big change. A small, stable store beats a half-finished improvement.

After the event

Save the data: peak traffic, error rates, slow pages, what failed, and what you would change. Next year this becomes your baseline. The same plan works for any large sale, so keep it as a template.

Frequently asked questions

How early should I start preparing my store for Black Friday? Ideally eight to twelve weeks ahead for larger stores. If you have about three weeks, use the timeline above and focus on the purchase path.

How do I load-test a checkout without hurting real customers? Use a staging environment with realistic data and test payments, and follow your platform’s rules for load testing. Do not run heavy tests against live checkout during business hours.

Should I have a second payment gateway? It reduces the risk of a single point of failure, but it adds setup and testing work. Weigh the cost of lost orders during an outage against the effort, and check your provider’s reliability information.

What should I freeze in the last week? New features, theme changes, new apps and scripts, and tracking changes. Allow only fixes with a written reason.

Which Core Web Vitals matter most on cart and checkout? All three count, but INP (responsiveness) and layout stability (CLS) are the ones shoppers feel when they tap buttons and enter details. Measure product, cart and checkout separately.

Want a pre-peak store review?

We can review speed, checkout and tracking and tell you what to fix before the sale, and quote the work. See our e-commerce and marketplace development service or contact us.