Case Study: Mitigating Automated Traffic & Bot Bursts on a WooCommerce Store

A high-selling, high traffic WooCommerce store operational since 2021 and hosted on SiteGround Cloud began experiencing intermittent CPU spikes, degraded response times, and checkout instability despite having full-page caching (WP Rocket), Redis object caching, and Cloudflare enabled.

Traffic analysis revealed approximately 10,000 requests within a 30-minute window (~5–6 RPS sustained) targeting dynamic WordPress endpoints, primarily:

• /admin-ajax.php
• WooCommerce AJAX endpoints
• /wp-admin/*

While volumetrically modest, the traffic targeted uncacheable, PHP-executed endpoints, resulting in PHP worker saturation and elevated CPU utilization.

The issue was not bandwidth exhaustion.
It was application-layer execution pressure.

Mitigation was achieved by:

• Upgrading to Cloudflare Pro
• Enabling Super Bot Fight Mode
• Implementing endpoint-specific rate limiting
• Activating Managed WAF rules
• Preserving checkout UX (no Under Attack Mode)

Post-mitigation:

• CPU stabilized within baseline range
• PHP worker contention resolved
• Checkout flow validated under load
• ~10–15% of traffic filtered at the edge
• No hosting upgrade required

The solution was architectural — not infrastructural scaling.

This store has been:

• Operational continuously since 2021
• Handling high order volumes seasonally and consistently
• Running WooCommerce at scale without major infrastructure overhauls
• Stable across multiple promotional cycles

Baseline performance metrics were historically predictable.
This was an anomaly — not organic growth pressure.

That distinction matters.

If infrastructure had been under-provisioned, we would have seen:

• Gradual degradation
• Peak-season correlation
• Worker exhaustion under legitimate campaign traffic

Instead, the instability was episodic and pattern-based.

Before launch — over 6 years ago — the store implemented proactive administrative hardening measures.

This was not a newly launched or poorly secured website.

This is a:

• High-selling WooCommerce store
• High-traffic since inception
• Operational continuously for 6+ years
• Stable infrastructure history

The default WordPress login endpoint (/wp-login.php) was masked prior to launch.

This means:

• Default login route was not publicly exposed
• Standard credential-stuffing scripts targeting /wp-login.php would fail
• Automated WordPress scanners could not discover login endpoint through default paths

This control had been operational and stable for years.

Additionally:

• XML-RPC was monitored and restricted
• No authentication flood patterns were detected in logs
• No brute force signature spikes were recorded during the incident window

The traffic burst was not authentication-oriented.

• Hosting Provider: SiteGround Cloud
• Application: WordPress + WooCommerce
• Caching Layer: WP Rocket (full-page cache)
• Object Cache: Redis
• CDN & Edge Security: Cloudflare (Free → Pro upgrade)

Client

   ↓

Cloudflare Edge (CDN + WAF + Bot Mgmt)

   ↓

Origin Server (SiteGround Cloud)

   ↓

Nginx / Apache

   ↓

PHP-FPM Workers

   ↓

MySQL

   ↓

Redis Object Cache

Typical PHP-FPM Configuration in managed cloud setups:

• 10–20 max children (varies by allocation)
• Memory-constrained worker pool
• CPU-bound execution per request

Important technical detail:

Each admin-ajax.php request:

• Boots full WordPress
• Loads theme functions
• Loads active plugins
• Runs hook stack
• May trigger WooCommerce session read/write

This is computationally heavier than serving cached HTML.

• Baseline CPU utilization: Stable
• Page load times: Within expected range
• No PHP worker exhaustion
• No database lock spikes

Redis hit ratio historically >90%
MySQL slow query log: No anomalies

Traffic spike detected
Approximately 10,000 requests in 30 minutes
Repeating load spike pattern

Observed:

• CPU usage sharply elevated
• PHP worker queueing
• Checkout delays
• Increased response times on dynamic endpoints

No corresponding increase in:

• Completed orders
• Add-to-cart events
• Session depth

This disconnect strongly suggested automation.

We ruled out:

• Legitimate marketing traffic
• Crawlers from verified search engines
• DDoS volumetric attack
• Database locking issues unrelated to traffic

Bandwidth usage remained normal.
Network interface did not saturate.

Therefore:

Not Layer 3/4 exhaustion.
Purely Layer 7 application pressure.

Patterns revealed:

• High concentration of requests to:
  • /admin-ajax.php
  • WooCommerce AJAX endpoints
• Repeated calls from varied IP ranges
• Non-human browsing patterns
• Sessionless requests
• No static asset preloading pattern

Human users typically load:

• HTML
• CSS
• JS
• Images
• Then AJAX

Bots directly hit endpoints.

Conclusion:

This was not bandwidth flooding.
It was application-layer request concentration on dynamic endpoints.

Observed CPU behavior resembled a “square wave” pattern:

• Rapid escalation to high utilization
• Sustained plateau
• Drop to baseline
• Repeated pattern

This suggests:

• Bursty automation
• Scripted polling behavior
• Bot clusters operating in cycles

If this were organic traffic, we would expect:

• Gradual ramp-up
• Distributed endpoint access
• Product page load predominance

Instead:

• High frequency on admin-ajax.php
• Minimal asset load distribution
• No conversion correlation

Key observation:

Even 5–6 RPS sustained can saturate PHP workers when endpoints:

• Perform nonce validation
• Trigger cart/session logic
• Execute database reads/writes
• Update session tokens

In WooCommerce:

Cart fragments (wc-cart-fragments) are especially expensive because:

• They regenerate mini-cart HTML
• They rely on session state
• They often perform database reads

Repeated invocation under bot automation magnifies load.

From a WooCommerce performance perspective:admin-ajax.php:

• Loads full WordPress bootstrap
• Executes plugin hooks
• Bypasses full-page caching
• Performs user/session checks
• Often triggers database queries

Additional technical factor:

WordPress AJAX requests do not benefit from opcode cache savings beyond PHP bytecode reuse.
Application logic still executes fully.

Common WooCommerce AJAX calls:

• Cart fragment refresh (wc-cart-fragments)
• Add to cart
• Checkout validation
• Shipping recalculation
• Payment gateway token verification

Each call:

• Initiates PHP execution
• May hit MySQL
• May access Redis
• Consumes a PHP-FPM worker

If PHP-FPM worker pool is limited (e.g., 10–20 workers):

Even moderate concurrent requests can:

• Queue requests
• Increase response latency
• Spike CPU
• Trigger cascading slowdowns

Important nuance:

CPU spikes are often secondary to worker saturation.
Queued requests compound latency.

Caching does not help here.

Because:

• These endpoints are intentionally dynamic.
• They are session-dependent.
• They must execute server-side logic.

Therefore:

The attack vector was not page rendering.
It was dynamic endpoint saturation.

Effective for:

• Product pages
• Static content
• HTML responses

Ineffective for:

• Logged-in sessions
• Cart endpoints
• Checkout
• AJAX calls

Helps:

• Reduce repeated DB queries
• Improve transient lookup speed

Does NOT:

• • Eliminate PHP execution
  • Prevent worker exhaustion
  • Stop request volume

Provides:

• CDN
• Basic DDoS mitigation

Does NOT provide:

• Advanced bot filtering
• Intelligent endpoint rate control
• Super Bot Fight Mode

Therefore:

The traffic reached the origin unfiltered.

Increase PHP workerThe objective:

Filter malicious or automated traffic before origin execution.

Not:

Scale CPU.
Upgrade hosting.

Enabled:

• Super Bot Fight Mode
• Advanced WAF rules
• Rate limiting controls
• Improved bot scoring

Justification:

WooCommerce is a transactional system.
Edge bot control is not optional at scale.

Settings:

• JavaScript detection: Enabled
• Optimize for WordPress: Enabled
• Definitely automated: Block
• Verified bots: Allow

Important:

Cloudflare bot scoring uses behavioral analysis and fingerprinting, not just user-agent matching.

This improves filtering accuracy compared to simple firewall rules.

Rule 1 — Protect admin-ajax.php

Condition:
URI Path contains “/admin-ajax.php”

Threshold example:
30 requests per 10 seconds per IP

Action:
Block for 10 minutes if exceeded

Rationale:
Legitimate users rarely hit AJAX endpoints at burst frequency.
Bots do.

Rule 2 — Protect wp-admin

Condition:
URI Path starts with “/wp-admin/”

Action:
Managed Challenge

This:

• Protects admin panel
• Minimizes friction for real users
• Enforces edge verification before origin

• Activated:
  • Cloudflare Managed Ruleset
  • OWASP protection

  Protects against:

  • Injection attempts
  • Exploit probes
  • Malformed payloads
  • Known vulnerability signatures

• CPU spikes during burst windows
• PHP worker queueing
• Checkout latency
• Repeated performance instability

Traffic volume: ~10,000 requests / 30 min
Filtered at edge: Minimal

• • CPU utilization stabilized within baseline range
  • No PHP worker exhaustion observed
  • Checkout flow tested end-to-end
  • No gateway disruption
  • ~10–15% of traffic classified and mitigated at edge

From a CTO perspective, infrastructure stability translates to:

• Reduced checkout abandonment
• Fewer failed payment attempts
• Lower hosting costs
• Reduced firefighting time
• Increased operational confidence

If checkout latency increases even by 1–2 seconds:

Conversion rates drop measurably.

By stabilizing execution layer performance:

• Revenue leakage during burst windows prevented
• Customer trust preserved
• Support overhead reduced

Additionally:

Avoided premature scaling decision.

Scaling without filtering would:

• • Mask the symptom
  • Increase cost
  • Leave vulnerability intact

If you run WooCommerce at meaningful traffic levels:

• • admin-ajax.php
  • /wc-ajax/*
  • /wp-admin/*
    

These are your most expensive routes.

Caching improves speed.
It does not eliminate abuse.Dynamic endpoints are always execution-bound.

Minimum:

• Bot detection
• Rate limiting
• WAF

Preferably at CDN layer.

Watch:

• PHP-FPM max children
• Slow logs
• MySQL query time
• Redis hit ratio
• Queue backlog

CPU alone is insufficient as metric.

If CPU spikes due to abusive traffic:Scaling increases capacity for abuse.Filtering removes root cause.

✔ Root cause logically derived
✔ Mitigation appropriate and proportional
✔ No overclaiming of DDoS
✔ No misattribution to database failure
✔ No unnecessary infrastructure scaling
✔ Business continuity preserved

From:

Hosting engineer perspective → Valid execution-layer diagnosis
DevOps perspective → Correct edge-first mitigation strategy
WooCommerce performance specialist perspective → Proper understanding of AJAX and PHP worker behavior,

This approach would pass scrutiny.

This incident reinforces a critical architectural principle:In modern eCommerce systems, performance stability is determined less by server size and more by intelligent edge filtering.Even moderate request volumes can destabilize WooCommerce if concentrated on dynamic endpoints.The solution is not always more infrastructure.Often, it is better traffic discrimination.