Skip to content
Products
AI Website Builder New VPS Hosting Cloud Servers Web Hosting Dedicated Servers Domains
Company
About Documentation Support Center Contact Get Started Call +91 75795 45488
Login
Hosting Panel — cPanel & Billing Console Panel — VPS Management
ALL SYSTEMS OPERATIONAL
WordPress

WooCommerce Abandoned Cart Recovery Not Working? Fix

Getwebup 6 min read

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.

Frequently asked questions

How long before WooCommerce considers a cart abandoned?

It depends on the plugin, not WooCommerce core - most default to somewhere between 1 and 24 hours of inactivity after items are added to the cart. You can usually adjust this threshold in the plugin's settings, but shortening it too much will fire recovery emails on people who were just still browsing.

Do abandoned cart plugins work for guest checkouts?

Yes, but only once an email address has been captured - usually at the checkout step where the customer types their email, or via an exit-intent popup. If a visitor never enters an email before leaving, there's nothing to send a recovery message to, regardless of how well tracking is configured.

Can a caching plugin really break cart tracking even if the rest of the site works fine?

Yes. Full-page caching only needs to interfere with the cart/checkout pages specifically - the rest of the site can cache perfectly normally while the session cookie that abandoned-cart tracking depends on never initializes correctly for guests.

Is it safe to delete rows from wp_woocommerce_sessions manually?

Yes, as long as you only delete rows where session_expiry has already passed and you take a database backup first. Deleting active, non-expired sessions will log out or lose the cart of anyone currently shopping.

Why do recovery emails work in my testing but not for real customers?

Test accounts are almost always logged in as admin, which many caching plugins automatically exclude from caching. That hides caching-related bugs from you. Always test the abandoned-cart flow in an incognito window with no active session, not from your admin account.

#woocommerce #abandoned-cart #cart-recovery #wp-cron #caching #wordpress

Keep reading

Chat with Support