Retailers do not have a security year. They have a trading year, and Cloudflare work has to fit around it. The rules that protect checkout in March are the same ones that block a sale email's traffic in November, and the team that tunes them is usually the team that is busiest on the days it matters.
This post sets out what Cloudflare managed services for retail should cover for the rest of 2026 and into 2027: the dates to plan around, the controls each part of the shop needs, how to run a change freeze that still lets you fix things, and what to ask of whoever runs it.
Plan around the trading calendar
Most of the year's risk lands in a few weeks. Write the dates down and work backwards from them.
11 November 2026
Singles' Day
The first big sale of the season for retailers selling into Asia, and an early test of bot and rate limiting rules.
27 November 2026
Black Friday
The highest traffic of the year for most retailers, and the most automated traffic too.
30 November 2026
Cyber Monday
Online-only offers, more promo codes and a second wave of checkout traffic.
December 2026
Holiday orders and shipping cut-offs
Order-tracking pages and delivery promises carry the load; gift-card sales peak.
January 2027
Returns, sales and gift-card redemption
Return portals, store credit and balance checks become targets.
Three weeks before the first date, the configuration should be settled. That means rules reviewed, exceptions written, cache settings tested against a sale page, and a named person for every weekend in the period.
Give each route its own control
A shop is not one application. It is a set of routes with very different risks, and a single zone-wide setting fits none of them well.
| Route | What goes wrong | What to set |
|---|---|---|
| Home, category and product pages | Price scraping, inventory checks, cache misses during a sale | Cache rules for sale pages, bot settings that block known-bad automation, no challenges for real shoppers |
| Search and filters | Expensive uncached queries used to slow the site | Rate limits per IP, and per session where your plan allows it |
| Cart and limited-stock items | Bots holding stock or buying out a drop | Bot signals on add-to-cart for limited items, queue or waiting room for launches |
| Sign-in and account creation | Credential stuffing, fake accounts for promo abuse | Rate limits on failed sign-ins, Turnstile on account creation |
| Payment step | Card testing, failed payments that cost fees | Rate limits that count failed payments, a challenge for likely automation |
| Gift cards, promo codes, order lookup | Guessing valid codes and order numbers | Tight rate limits, identical responses for every invalid value, alerts on failure rates |
| Webhooks, mobile app, monitoring | Orders stuck "pending" or blank app screens when a rule catches them | Exceptions written before any rule goes live |
Our rate limiting guide has starting thresholds for sign-in and API routes. If a rule has ever stopped your own checkout, what happens when Cloudflare blocks checkout during a campaign covers how to find and fix it while the sale is still running.
Run a change freeze that still lets you fix things
Most retailers freeze changes before peak season. That is sensible for releases. It is dangerous for the edge, because the edge is where you respond to what the season brings: a new bot, a false positive on a promo page, a payment provider that changes its webhook addresses.
A freeze that works has three parts:
A settled baseline. Every rule, exception and cache setting reviewed and recorded before the freeze starts, so you know what "normal" is.
A list of changes allowed during the freeze. Typically: adding an exception for a blocked legitimate client, tightening a rate limit under attack, turning on a stronger challenge for one route, and rolling back any change made during the freeze.
An emergency path with names on it. Who can approve a change on a Saturday night, who makes it, and where it is recorded. Review every emergency change in the week after peak, and either keep it properly or remove it.
Our WAF change-control runbook walks through a single change with an owner, an approver, a record and a way back. The same shape works for a freeze; only the approver list changes.
Get ready for campaign traffic
A sale email or a paid campaign can multiply traffic within minutes, and the traffic looks unusual: many new visitors, landing on one page, arriving at once. Rules tuned on ordinary weeks can read that as an attack.
Before each campaign:
- Tell whoever runs Cloudflare the date, the time and the landing pages.
- Check the landing pages are cached at the edge, and that a cache rule does not cache anything personal, such as cart contents or prices for signed-in customers.
- Look at Security Events for the landing pages during the first hour, not the next morning.
- Agree in advance which rule gets loosened first if real shoppers are challenged, and which never does.
Put the payment page on the pre-peak list
Peak season is when payment pages change most. A sale adds a tag-manager rule, a new analytics pixel or a "buy now, pay later" widget, and each of those is another script running beside the card form. Since PCI DSS v4.0.1 made its payment-page script requirements mandatory in March 2025, every one of them needs a reason, an owner and a way to spot when it changes.
So treat the payment page like the rules in the freeze. Before the baseline is settled, list every script it loads and who asked for it, and agree that no new script goes on it during peak without the same approval as a rule change. On Cloudflare, Page Shield shows which scripts and connections each page uses and alerts when that list changes, which turns the agreement into something you can check. Your assessor still decides what meets the standard for your business.
What retail managed services should include
The controls above are not hard to describe. The work is in keeping them right through a season that changes week by week. When you compare Cloudflare managed services for retail, ask for these in writing:
A review of every route in the table above before peak season, with the exceptions written down.
A named contact for every weekend and holiday between Singles' Day and the end of January.
Response times that apply overnight and at weekends, not only in business hours.
A freeze policy that says which changes the provider can make without asking, and how each one is recorded.
Someone watching Security Events during each campaign launch you tell them about.
A report after peak: what was blocked, what was changed and what should stay.
How we run it
Vigilbase runs Cloudflare for retailers and online marketplaces. Our support follows the sun from teams in Kenya, South Africa, the UAE and Portugal, and on our Priority and Critical service levels that means 24/7 cover: a Black Friday night in New York or a Ramadan evening in Dubai is a working day for someone on our team. We are a Preferred Cloudflare Partner and ISO 27001 and SOC 2 Type 2 compliant. The response times for each service level are on our SLA page.
For a single shop on one domain, Vigilbase Shield is a monthly plan: managed WAF rules, DDoS protection and Super Bot Fight Mode, set up and tuned by our team. For several brands, regions or payment journeys, we sell Cloudflare Enterprise and run it under Managed Cloudflare.
To set the baseline before the freeze, run the Cloudflare Checkup on your account. It reads your zones without changing anything and reports how the WAF, bot and DDoS settings stand on each one.
How early should a retailer prepare Cloudflare for peak season?
Settle the configuration about three weeks before the first big sale date. That leaves time to review every route, write the exceptions for webhooks, apps and monitoring, test cache rules on a sale page and name who is on call each weekend.
Should we freeze Cloudflare changes during peak season?
Freeze releases and routine tuning, but keep an emergency path. Agree in advance which changes are allowed during the freeze, who approves them out of hours and where they are recorded, and review each one after peak.
Is Under Attack Mode safe to use on a shop?
Only as a last resort. It challenges every visitor on the zone, including paying customers, mobile apps and payment webhooks. A custom rule that challenges only the routes under attack usually stops the attack with less damage to sales.
What should a retailer check in Cloudflare before a sale email goes out?
Check that the landing pages are cached, that nothing personal is cached with them, that Security Events for those pages will be watched in the first hour, and which rule gets loosened first if real shoppers are challenged.
