Fake WooCommerce Orders: Protect Your Ads Data and Crawl Access

A run of one dollar orders landing overnight looks like an operations headache, and it is. It is also a marketing problem. Card testing orders flow into the same analytics, conversion tags and bidding systems that decide where your ad budget goes, and some of the fixes can change how search engines reach your store. Here is how to stop the orders while keeping your data and your crawl access clean.

The video works through a real case: an Australian WooCommerce store that normally takes around five orders a day woke up to three pages of fake orders, all for the same tiny amount. It covers four fixes in order of effort: WooCommerce rate limiting, Cloudflare country filtering, a fraud plugin and Stripe Radar.

What card testing looks like

Card testing is someone with a list of stolen card numbers using your checkout to find out which ones still work. The small amount is the giveaway: a charge of a dollar or so confirms a card without drawing attention. The orders arrive in waves, often a handful per hour overnight, and the owner finds a wall of identical low-value orders in the morning.

The direct damage is covered in the video. If you use a 3PL (a third-party shipping or fulfilment partner), any order that goes through can enter the shipping queue and be dispatched before anyone checks it, which is a real risk over a weekend. Your merchant facility may also take a dim view of a store processing a stream of fraudulent attempts and, in the worst case, shut the account down.

Why fake orders skew your marketing numbers

Any test order that succeeds lands on the order received page and fires exactly the same tags as a genuine sale. The effects outlast the attack:

• Google Ads conversions: purchases credited to campaigns that did not earn them. If you use Smart Bidding on conversions or conversion value, the bidding model learns from those fake sales and shifts spend towards whatever traffic it thinks produced them.
• GA4 ecommerce reports: inflated transactions, a sharp fall in average order value and a conversion rate that suddenly looks better than it is. Any landing page or checkout test running at the time is contaminated for the affected days.
• Audiences: purchaser lists built from the purchase event now include fraudsters, so customer exclusions and similar-audience targeting are slightly off.

None of this shows up in a rankings report, which is why it gets missed. Order counts rise, dashboards look healthy, and the only obvious signal is average order value dropping off a cliff.

The four fixes, from lightest to strongest

1. WooCommerce rate limiting. In WooCommerce settings, under Advanced and Features, enable rate limiting for checkout and the Store API. It accepts three requests per 60 seconds before locking. Card testing usually arrives too slowly to trip it, but it does no harm on a store without heavy cart or API traffic.
2. Cloudflare country filtering. If you only sell to certain countries or continents, a Cloudflare rule that challenges traffic from everywhere else is very effective, and it makes the store a harder target for scrapers and other junk traffic in general. It is not an option if you ship worldwide.
3. A fraud plugin. FraudLabs Pro is free up to 500 orders a month, which suits a small store, and screens for repeat orders and multiple orders from one IP address. The paid Anti-Fraud for WooCommerce extension adds checks such as whether the order location matches the billing and shipping details. One signal the video mentions: an order where every field is typed in lower case can be a red flag. Start with the free option and move up if it misses too much.
4. Stripe Radar. If you take payments through Stripe, Radar screens out fraudulent payments, at an extra cost. Try a fraud plugin first.

Keep search engines out of the country filter

The Cloudflare rule is the one fix with an SEO side effect, so set it up carefully. The example rule in the video challenges traffic from outside North America, with three exceptions that matter:

• Known bots pass straight through, so Google, Bing and AI crawlers are never challenged. Googlebot crawls mostly from the United States, so a country rule for a store anywhere else would challenge Google on nearly every visit without this exception.
• The path used for SSL certificate validation is excluded, so certificate renewals keep working.
• User agents containing “uptime” are excluded, so monitoring does not report false outages.

Expect to adjust it. Shipping integrations, order management software and other services that call your store’s API can get caught. The advice in the video is to add the rule, watch Cloudflare’s security log to see what it is stopping, and add exceptions (usually by user agent) for anything legitimate.

Measuring the clean-up

• Search Console, Crawl stats: check the response breakdown in the week after adding the Cloudflare rule. A jump in non-200 responses to Googlebot means an exception is missing. Run a URL Inspection live test on a product page and a category page to confirm Google can still fetch them.
• Google Ads: if fake purchases were recorded as conversions, retract them with conversion adjustments (this needs the order ID to be passed with the conversion), or at least note the affected dates so nobody mistakes them for a good week.
• GA4: record the attack window in your reporting notes and compare transactions and average order value with the same period beforehand.
• WooCommerce: count orders under a few dollars per day. When that count drops to zero and stays there, the fix is holding.

The best outcome is a dull one: order counts that match real demand, conversion data you can safely bid on, and a crawl stats chart that never noticed anything happened.