u/Upstairs_Control_611

We’re currently troubleshooting load spikes on a fairly large WooCommerce shop.

What we see in the logs:

• several thousand wp-cron.php requests per day
• many dynamic requests to admin-ajax.php, cart and Woo AJAX
• a noticeable number of 499 responses under load
• Action Scheduler itself is working, and the number of scheduled daily actions is not huge
• around 39 scheduled actions run daily, roughly 15 of them are CTX Feed related
• around 1,370 Action Scheduler jobs completed successfully yesterday
• the Action Scheduler queue runner itself also showed many aborted requests in the access log

Cloudflare is now in front of the site and already reduces a lot of static traffic, but wp-cron.php, admin-ajax.php and /cart/ are still among the busiest uncached dynamic paths.

So I’m considering disabling WP-Cron with:

define('DISABLE_WP_CRON', true);

and replacing it with a real server-side cron job, probably every 5–15 minutes.

For those running larger WooCommerce stores:

Did switching from WP-Cron to a real server cron noticeably reduce server load or 499/timeout issues for you?

Or did it mainly make cron execution more predictable without changing overall resource usage much?

I’m especially interested in real-world experience from stores with substantial bot/crawler traffic and lots of dynamic WooCommerce requests.

Today we ran into a pretty extreme WooCommerce traffic pattern on one of our stores.

In less than one hour our access log showed:

• 14,262 requests in total
• 7,048 actual requests containing ?add-to-cart=
• 2,435 requests containing remove_item=
• 6,921 different IP addresses among the add-to-cart requests

At the peak we saw around 235 add-to-cart requests in a single minute.

The requests were spread across a large number of products and IP addresses and looked nothing like normal customer behavior.

Eventually the shop started producing timeouts and upstream/FastCGI errors, so we temporarily switched the store to a static maintenance page to take PHP/WooCommerce out of the equation.

Interestingly, the requests continued hitting URLs such as:

/?add-to-cart=12345

and

/cart/?remove_item=...

even while the shop itself was behind the static page.

After some time the wave dropped significantly and we reopened the shop.

We’re now looking at the source IPs geographically to see if there’s a recognizable pattern, and we’ll probably move the protection in front of WordPress rather than trying to block thousands of individual IPs.

Has anyone else seen this specific WooCommerce cart-abuse pattern recently?

I’d especially be interested in whether you saw:

• large numbers of direct add-to-cart requests
• almost one new IP per request
• automated remove_item requests
• PHP/FastCGI workers getting saturated

If you reduced it successfully, was the effective fix at the webserver/WAF level or inside WooCommerce itself?

I’ve been chasing a strange issue on a managed WooCommerce server for a while now.

Most of the time the shop runs perfectly fine. Then, every now and then, WordPress suddenly throws:

Error establishing a Redis connection

with

Error while reading line from the server. [unix:/run/redis-.../sock]

At first I thought this was just one of those random backend hiccups. But I recently added an external uptime monitor, and that made the pattern a lot more interesting.

One example from today:

• a WooCommerce category returned 500 / 500 / 500
• a product page in the same run returned 500 / 200 / 200
• a few minutes later everything was back to normal again

The PHP log at almost exactly the same time showed repeated:

Predis\Connection\ConnectionException: Error while reading line from the server

And the stack traces were all over the place: WooCommerce Germanized, Elementor, YITH, WP-Cron, CTX Feed, WooCommerce core.

So this doesn’t really look like one specific plugin failing. They all just happen to hit Redis when Redis stops answering properly.

The odd part is that Redis itself does not always look dead.

Its own log still shows successful background saves like:

Background saving started
DB saved on disk
Background saving terminated with success

Before one of the incidents there were also several:

Slow script detected: still in execution after 5–7 seconds

messages.

The first time this happened today I was updating plugins and UpdraftPlus was doing automatic pre-update backups, so that looked like the obvious explanation.

Then the exact same Redis connection error came back later with no update and no backup running.

I’ve also seen this Redis error page a few times before, so it’s clearly not just today’s update session.

So I’m currently thinking less “plugin bug” and more something around Redis itself, the Unix socket, blocking scripts, resource limits, or the managed hosting setup.

Has anyone here seen a similar pattern?

Redis process appears to stay alive, but PHP/Predis temporarily can’t read from or connect to the socket, WooCommerce throws 500s, and a short time later everything recovers by itself.

What would you check first?

I’m starting to think that AI visibility tracking needs a model changelog.

If ChatGPT changes its search behavior, source selection or citation weighting, a brand can lose visibility without changing anything on its website.

The same applies to Google AI Overviews layout changes, Reddit citation drops, Perplexity source behavior or Gemini updates.

Without logging these changes, it’s easy to misread the data. So my question:

How do you track changes in ChatGPT, Gemini, Claude, Perplexity or AI Overviews?

Official release notes?

Third-party monitoring?

Your own prompt tests?

Manual changelog?

What actually works for you?

I’m especially interested in how people separate site-side changes from model-side or source-selection changes.

I’m starting to think that AI visibility tracking needs a model changelog.

If ChatGPT changes its search behavior, source selection or citation weighting, a brand can lose visibility without changing anything on its website.

The same applies to Google AI Overviews layout changes, Reddit citation drops, Perplexity source behavior or Gemini updates.

Without logging these changes, it’s easy to misread the data. So my question:

How do you track changes in ChatGPT, Gemini, Claude, Perplexity or AI Overviews?

Official release notes?

Third-party monitoring?

Your own prompt tests?

Manual changelog?

What actually works for you?

I’m especially interested in how people separate site-side changes from model-side or source-selection changes.

I found a noticeable number of Generative AI impressions in Google Search Console and I’m trying to understand how people are treating this in reporting.

Are you using it as a separate AI visibility layer, blending it into normal organic impressions, or mostly ignoring it until the data becomes clearer?

The part I’m unsure about is what the metric actually proves.

It may show that a URL appeared in a generative AI surface, but it does not necessarily tell us:

- whether the brand was mentioned

- whether the page was cited

- whether the answer used the content as evidence

- whether the user saw the source

- whether it influenced the decision

- whether it should be compared to classic organic impressions

So I’m wondering whether this is useful reporting data, or just another visibility layer that needs a lot of context before it becomes meaningful.

How are you handling Generative AI impressions in GSC?

Separate report?

SEO report footnote?

Early signal?

Ignore for now?

I ran into this while comparing AI visibility screenshots and tracker outputs over time.

I’m starting to think AI visibility tracking needs its own “historical memory” layer.

Not just daily screenshots or citation counts.

A few things seem to happen at the same time:

1. SERP elements are getting harder to parse.

Some Google result features no longer expose the original target URL cleanly. A tracking system may see a Google redirect or an encrypted URL and suddenly attribute a result to google.com instead of the actual publisher.

2. AI citation mix can shift after model or retrieval updates.

In some monitoring examples, brand sites gain citations after one update, while media, review or comparison sites lose. In other cases, the opposite happens.

The point is not which category wins on one day. The point is that the source mix can change quickly.

3. Different AI systems evaluate the same domains differently.

A domain can lose organic visibility in Google, while still getting cited by Copilot or Perplexity. That makes “AI visibility” less stable than a simple rank position.

So the practical problem is this:

When a dashboard shows a visibility drop, how do we know whether it is real?

Did the brand actually lose visibility?

Did the model change its source preference?

Did a parser fail because the SERP markup changed?

Did the result still exist, but under a different URL or source attribution?

Did the answer role change from citation to mention, shortlist or recommendation?

For SEO, we got used to thinking in rankings and URLs.

For AI visibility, historical data is not just an archive. It is part of the measurement context.

I think we may need to store much more history:

- prompt / query

- model or AI system

- full answer

- cited sources

- mentioned brands

- answer role

- SERP feature type

- title

- URL

- domain

- source type

- previous known attribution

- date

- model / update markers

- parser or extraction rule version

Otherwise, we may end up discussing “visibility losses” that are actually tracking artifacts.

Curious how others are handling this:

How do you separate a real AI visibility change from a measurement problem?

I recently came across a WordPress performance pattern that I think is easy to underestimate.

The issue was not bot traffic volume alone. The real problem was the URL pattern the bots discovered.

In one public case from a large WordPress blog, threaded comments created many URLs with parameters like:

?replytocom=123

Crawlers followed those links across many posts.

Because each parameter created a unique URL, cache was much less useful. The requests reached WordPress/PHP/database instead, and PHP-FPM became the bottleneck.

The useful fix was to reduce those requests before WordPress had to process them:

- redirect or block ?replytocom URLs before WordPress starts

- discourage those URL patterns in robots.txt

- block crawlers that create load but no useful value

- treat server capacity as a safeguard, not the only solution

I have seen a similar pattern in WooCommerce logs with different URL types:

- ?add-to-cart= URLs

- filter/sorting parameters

- product search URLs

- feed URLs

- session/cart-related URLs

- crawler-generated parameter combinations

The takeaway for me:

Request count by bot name is not enough.

A crawler requesting cached canonical pages is one thing. A crawler requesting thousands of unique parameter URLs that trigger PHP, database queries, sessions or cart logic is a very different problem.

Do you analyze crawler traffic by URL type, not only by bot name?

And for WordPress/WooCommerce specifically:

- do you block or redirect ?replytocom URLs?

- where do you handle it: WordPress, server rules, CDN/WAF, robots.txt?

- have you seen bots following ?add-to-cart= or other non-cacheable WooCommerce URLs at scale?

Not looking for hosting recommendations. I’m interested in the WordPress/WooCommerce handling of crawler-generated URL explosions.

I noticed something unusual in the access logs of a WooCommerce shop and would be interested if others have seen the same behaviour.

Over several days, meta-externalagent accounted for roughly 10% of all requests.

What surprised me is that it was not only requesting normal product pages or Open Graph preview URLs. It also requested URLs such as:

?add-to-cart=...

and other WooCommerce URL variants, including /feed/.

I would have expected a preview or AI-related crawler to request product pages, images, metadata or maybe feeds — but not necessarily add-to-cart URLs.

Has anyone else seen meta-externalagent requesting WooCommerce ?add-to-cart URLs in their logs?

Is this usually caused by links exposed somewhere in the HTML, feeds, structured data, tracking links, cached pages, or something else?

I am not trying to block it at this point. I am mainly trying to understand whether this is normal crawling behaviour for WooCommerce sites or whether it points to something in the shop output that should be cleaned up.

During a discussion in our team, an interesting question came up that we haven't seen discussed anywhere yet.

Suppose an online shop regularly publishes the best-selling products from a defined period (e.g. the last quarter), based on verified completed customer orders.

Do you think this kind of transparent product-level purchase data could become an additional trust signal for AI systems such as ChatGPT, Gemini, Claude or Perplexity?

We're not talking about customer psychology or marketing.

The question is whether this type of publicly available, verifiable purchase evidence could help AI systems assess the credibility or relevance of a brand or product in the future.

Or would it be completely irrelevant compared to signals like reviews, citations, documentation and brand mentions?

I'm genuinely interested in hearing arguments from both sides, especially if you've been working on GEO or AI search.

I spent the weekend trying to understand why one of my WooCommerce stores suddenly behaved strangely.

Symptoms:

Database grew to 1.3 GB
PHP error log exploded to 7.9 GB
Random database lock errors
Deadlocks in Action Scheduler
INSERT command denied messages
Background processing running almost continuously

At first I suspected:

Redis
WP Rocket
a custom JSON-LD plugin I was developing
a recent server upgrade

None of them were the cause.

After digging through the database I found this:

wc_run_batch_process
status: complete

1,072,113 actions

The args field pointed to:

Automattic\WooCommerce\Internal\DataStores\Orders\DataSynchronizer

The interesting part:

The store has only 600+ orders.
Only 1 pending Action Scheduler job existed at any given time.
As soon as one batch completed, the next one was immediately scheduled.

So this wasn't a growing queue.

It looked like an endless loop:

pending
↓

complete
↓

schedule next batch
↓

pending
↓

...

The issue only became obvious after comparing the Action Scheduler tables with the HPOS configuration.

I'm still investigating the exact trigger, but if your WooCommerce database suddenly starts growing at an unusual rate, check your Action Scheduler before assuming it's a database or server issue.

Sometimes the problem isn't the database.

It's the background worker that never stops scheduling itself.

Has anyone experienced a similar HPOS / DataSynchronizer loop?

I noticed an interesting behavior while deleting products in a larger WooCommerce catalog.

I deleted products in several bulk actions (20 products per batch). The products did not seem to be permanently deleted immediately.

Instead:

• deletion tasks appeared under Scheduled Actions
• first under "Pending"
• after more bulk deletions, some actions became "Overdue"
• Woo then displayed something like: "The next queue will start in xx seconds."

After the next queue started, around 40-50 products seemed to be permanently deleted in one run.

My impression is that WooCommerce intentionally processes product deletions in batches and inserts pauses between queue runs instead of continuously processing everything.

Questions:

• Is this expected behavior of Action Scheduler?
• Have others observed similar behavior on larger catalogs?
• Did you notice increased database activity while processing large deletion batches?

Environment:

• WooCommerce 10.7.0
• WordPress 7.0
• Elementor 4.1.1 / 4.1.0
• Astra theme

Setup:
Germany, Austria and Switzerland were configured in the same shipping zone.

Behaviour:

• Logged out: shipping costs displayed correctly.
• Logged in: no shipping costs displayed on checkout.
• Order confirmation also showed inconsistent behaviour.

What finally fixed it was disabling:

WooCommerce → Settings → Shipping → Shipping options → "Hide shipping costs until an address is entered."

After unchecking that option, Woo immediately detected Germany correctly and the shipping costs appeared again.

Has anyone seen similar behaviour recently, especially with logged-in users and shipping zones that include multiple countries?

Hey everyone,

since April 27, one of my larger WooCommerce shops started generating a lot of log files named like:

place-order-debug-bbbdcbf4

Inside the logs I see entries such as:

[Shortcode #1] Place Order flow initiated  
[Shortcode #2] Session updated with checkout data and totals calculated  

The context includes an order_uid, but it looks like a UUID, not a normal WooCommerce order ID.

Backtrace points to:

WC_Checkout->process_checkout  
WC_AJAX::checkout  

What’s interesting is the pattern:

• Apr 27: first appearance
• Apr 28–29: almost no logs
• Apr 30: massive spike again

So it doesn’t look like a constant bug — more like something triggering checkout requests in waves.

My questions:

1. Has anyone seen place-order-debug-* logs recently? Is this new in WooCommerce?
2. Could this be bots repeatedly hitting the wc-ajax=checkout endpoint?
3. Any known plugins or themes that might trigger repeated checkout AJAX calls?
4. Where would you start debugging this — frontend JS or server/access logs?

Thanks

Hi all,

I’m dealing with a persistent and rather unusual WordPress compromise affecting multiple domains within the same hosting account, and I’m trying to identify the actual entry vector.

Key observations:

• Administrator accounts are being created directly in the database, not via WordPress
  • no username/email set
  • identical password hashes across multiple accounts
  • fake registration dates (e.g. 2020)
  • no recorded login activity
• Wordfence reports no modified core, plugin, or theme files
• NinjaFirewall logs repeatedly show: Database changes detected - [administrator account] with IP 0.0.0.0 → no HTTP request context
• Access logs show no matching requests at the corresponding timestamps
• Databases are configured for localhost access only (127.0.0.1)

Attack pattern:

1. Admin accounts appear (direct DB insertion)
2. Shortly after, on at least one affected domain:
   • a file manager plugin gets installed (legitimate plugin, not modified)
3. Some domains show:
   • suspicious sitemap.xml with large sets of pre-generated URLs (SEO spam preparation)
   • Google Search Console activity for domains not actively managed

Important context:

• Not all domains are affected, but multiple sites in the same account show related behavior
• No obvious malware found in WordPress files
• No clear HTTP-based attack trace
• Behavior strongly suggests server-side execution or lateral movement

Working assumptions:

• Direct DB manipulation via:
  • local script execution (PHP CLI?)
  • compromised hosting environment
  • or abuse of a vulnerable application layer component

Questions:

1. Has anyone encountered this pattern (direct DB user injection + 0.0.0.0 firewall logs)?
2. What are realistic vectors for creating WP admin users without HTTP traces?
3. Any known techniques for lateral movement between WP installations within the same account?
4. Where would you focus next: server-level audit, DB credential reuse, or application layer?

At this point it does not look like a typical WP file-based compromise, but rather something executing within the server context.

Any insight or similar cases would be greatly appreciated.

Thanks!

Hot take:

GEO may have a prompt research problem more than a content optimization problem.

SEO had keyword research.

But where is the equivalent for real AI prompts?

Most GEO tools seem to monitor curated prompt sets — but what if many of those prompts don’t reflect how people actually use AI search?

Example:

A tool might track something like:

“loft studio Düsseldorf”

But a real AI user might ask:

“Where can I find a loft photo studio near Düsseldorf for business portraits?”

That changes:

* what prompts matter

* what content gets cited

* how “AI visibility” should even be measured

I’m starting to think prompt research may become for GEO what keyword research was for SEO.

Some GEO tools may be optimizing for synthetic prompts, while users ask something else entirely.

Curious what others think:

Are we still doing SEO-style keyword thinking in AI clothing?

Or are people seeing good approaches to real prompt research already?

Without prompt research, GEO may optimize answers to questions nobody asks.