WooCommerce Abandoned Cart Recovery Not Working? Fix

· 6 min read · 23 views · Getwebup

You turned on abandoned cart recovery, waited a week, and the dashboard still says zero. Or worse - it's tracking carts fine, but the recovery emails never land in anyone's inbox. Here's what's actually breaking it and how to fix each cause.

Symptom: Carts Aren't Tracked, or Recovery Emails Never Send

Usually one of two things is happening:

  • The plugin (CartFlows, Abandoned Cart Lite, FunnelKit, or WooCommerce's own Marketing > Cart Recovery) shows 0 or near-0 abandoned carts, even though you can see real guest traffic hitting the checkout page.
  • Carts show up in the log correctly, but the follow-up email that's supposed to fire 1 hour / 24 hours later never actually reaches the customer.

These two symptoms have almost entirely different causes, so let's split them.

Cause 1: Full-Page Caching Is Hiding the Cart From WooCommerce

This is the single most common reason abandoned cart tracking silently fails. If you're running LiteSpeed Cache, WP Rocket, W3 Total Cache, or a Cloudflare page rule that caches everything, the cart and checkout pages can get served from cache instead of being generated fresh per visitor.

When that happens, WooCommerce's session cookie (woocommerce_cart_hash / wp_woocommerce_session_*) either doesn't get set correctly or gets served to the wrong visitor. The abandoned-cart plugin hooks into that session to know a cart exists - if the session never initializes properly, there's nothing to track.

The Fix

Exclude cart-related pages and endpoints from full-page caching. Every major caching plugin has a WooCommerce-aware setting for this, but it's worth confirming it's actually on:

  • LiteSpeed Cache: Cache tab → confirm "Do Not Cache URIs" includes /cart/*, /checkout/*, and /*?add-to-cart=*. LSCWP usually auto-detects WooCommerce and adds these, but plugin updates have been known to reset custom rules.
  • WP Rocket: under "Advanced Rules," WooCommerce pages are excluded by default if the plugin detects WooCommerce - verify under Settings → WP Rocket → Cache that "Never cache logged-in users" doesn't accidentally exclude your test as a logged-in admin (that hides the bug from you, not from real guests).
  • Cloudflare: add a Cache Rule that bypasses cache for /cart/, /checkout/, and any URL containing wc-ajax=. If you're on the free plan, use Page Rules instead with "Cache Level: Bypass."

After adding the exclusion, test in an incognito window (not logged in, no cache-busting plugin running) and add something to the cart. Check WooCommerce → Status → Logs for a fatal-cache or session-related entry if it still doesn't register.

Cause 2: WP-Cron Isn't Actually Running

Abandoned cart plugins schedule their "check for abandoned carts" and "send recovery email" jobs through WP-Cron, which only fires when someone visits the site. Low-traffic stores, or sites where DISABLE_WP_CRON is set in wp-config.php without a replacement cron job, will queue events that never actually run.

The Fix

Check whether WP-Cron is disabled and, if so, whether a real cron job is calling it:

grep DISABLE_WP_CRON /home/username/public_html/wp-config.php

If that returns define('DISABLE_WP_CRON', true);, go to cPanel → Cron Jobs and confirm there's an entry like:

*/5 * * * * wget -q -O /dev/null "https://yourdomain.com/wp-cron.php?doing_wp_cron"

If there's no cron entry at all, either remove the DISABLE_WP_CRON line (let WordPress trigger it on page loads) or add the cron job above. You can confirm cron is healthy right now with WP-CLI from cPanel Terminal or SSH:

wp cron event list --fields=hook,next_run_relative | grep -i cart

If you see the abandoned-cart hook listed but its "next run" time keeps drifting further into the future instead of firing, that confirms cron events are queuing but not executing - the real cron job is missing or pointed at the wrong domain/path.

Cause 3: Recovery Emails Are Scheduled but Never Delivered

If carts are tracked correctly and the plugin's log shows "recovery email sent," but the customer never got it, this isn't a cart-tracking problem anymore - it's a mail delivery problem, same as any other WordPress transactional email. Abandoned cart plugins almost always use wp_mail() under the hood, which on shared hosting frequently gets flagged as spam or blocked outright unless you're using authenticated SMTP.

The Fix

  1. Install WP Mail SMTP (or similar) and connect it to an authenticated provider - your cPanel mailbox, Google Workspace, or a transactional service like SendGrid/Brevo. Don't rely on PHP's default mail() function for anything customer-facing.
  2. Send yourself a test abandoned-cart email and check the raw headers for SPF/DKIM pass/fail.
  3. Check WP Mail SMTP → Email Log (or your provider's dashboard) to see if the send actually succeeded or silently failed.

If you're still fighting this after setup, our WordPress SMTP troubleshooting guide covers the deeper causes.

Cause 4: The Sessions Table Is Bloated and Slowing Everything Down

Every guest cart creates a row in wp_woocommerce_sessions. On a store that gets steady traffic but few completed checkouts, this table can grow into the hundreds of thousands of rows over a year, and WooCommerce doesn't always clean up expired sessions promptly - especially if a cron misfire (see Cause 2) also broke the session garbage collection.

A bloated sessions table doesn't just slow down cart tracking - it slows down every page load that touches cart state, which compounds the abandonment problem you're trying to fix.

The Fix

Check the table size first:

SELECT COUNT(*) FROM wp_woocommerce_sessions;
SELECT COUNT(*) FROM wp_woocommerce_sessions WHERE session_expiry < UNIX_TIMESTAMP();

If the second query returns a large number, those are stale rows safe to remove:

wp option get woocommerce_db_version
wp db query "DELETE FROM wp_woocommerce_sessions WHERE session_expiry < UNIX_TIMESTAMP();"

Take a database backup before running any DELETE, and confirm WooCommerce → Status → Tools doesn't already have a built-in "clear expired transients" action that does this more safely for your version.

Quick Reference

SymptomLikely CauseWhere to Check
Zero carts tracked despite real trafficPage cache hiding the sessionCache plugin's WooCommerce exclusions
Carts logged, no recovery email ever firesWP-Cron not runningwp cron event list, cPanel Cron Jobs
Email log shows "sent" but nothing arrivesUnauthenticated mail sendingWP Mail SMTP email log, SPF/DKIM
Site slow, cart data inconsistentBloated sessions tablewp_woocommerce_sessions row count

Prevention

  • Add cache exclusions for cart/checkout the same day you install a caching plugin - don't wait for abandoned-cart reports to reveal the gap.
  • Set up a real system cron for wp-cron.php on any store with irregular traffic; don't depend on visitor-triggered cron for anything time-sensitive.
  • Run a monthly check on wp_woocommerce_sessions row count so it doesn't creep up unnoticed.
  • Test the full abandonment flow yourself every few months - add to cart, leave it, and confirm the email actually lands, not just that the plugin log says it fired.

Questions people actually ask