WooCommerce adds a layer of complexity to WordPress caching and performance that trips up a lot of site owners. The problem is that WooCommerce pages — cart, checkout, account — are dynamic by nature. They show different content to different users. Cache them aggressively and you get customers seeing each other’s cart items. Don’t cache at all and your site crawls. Getting the balance right requires specific configuration at every layer of your stack.
This post covers the WooCommerce-specific issues we found and fixed on this very site — kindoflost.com — including a stubborn checkout URL problem that resisted every normal fix, a cart caching issue that was showing stale items, and the specific plugin settings that keep WooCommerce and caching working together without conflict.
The Core Problem: Dynamic Pages and Aggressive Caching Don’t Mix
When you set up Cloudflare and WP Optimize to cache your site aggressively (which you should), you also create a risk for WooCommerce. Here’s the failure mode: a visitor adds Item A to their cart. The cart page gets cached. The next visitor loads the cart page and sees Item A already in their cart — even though they never added anything.
This isn’t hypothetical. It’s exactly what was happening on this site before we fixed the bypass rules. The solution is to explicitly exclude WooCommerce pages from every caching layer. Not just Cloudflare — every layer.
Here’s the exclusion list that needs to be consistent across all your caching tools:
- /cart/
- /checkout/
- /my-account/
- Any page with a WooCommerce shortcode or block
In Cloudflare, this is handled by the bypass cache rule we set up in Post 2. In WP Optimize, go to WP Optimize → Caching → Advanced and add these paths to the exclusion list. Both tools need to have matching exclusions or you’ll get inconsistent behavior depending on which cache layer serves the request.
The Checkout Slug Problem (And How We Finally Fixed It)
This was the most frustrating issue in the entire audit. The checkout page on this site was accessible at /checkout-2/ instead of /checkout/. WooCommerce uses the checkout page’s ID internally, so the store worked fine — but the URL looked unprofessional and the cache bypass rule for /checkout/ wasn’t matching the actual URL.
The cause: a draft page with the slug “checkout” was sitting in the database, blocking the active checkout page from using that slug. WordPress won’t assign a slug that’s already in use — even by a draft. So the active page got bumped to checkout-2.
We tried several approaches before finding one that worked:
- Trashing the draft from the WordPress UI: Wouldn’t delete.
- Quick Edit to change the slug first: Didn’t work.
- phpMyAdmin SQL query to delete by post_name: Ran but deleted nothing — the table prefix wasn’t wp_, so the query targeted the wrong table silently.
- Code Snippets PHP to force-delete by querying the database: Worked on the second attempt once we used
$wpdbdirectly so it picked up the correct table prefix automatically.
The working snippet, via Code Snippets → Add New, Front-end only:
add_action( 'init', function() {
global $wpdb;
$post_id = $wpdb->get_var(
"SELECT ID FROM {$wpdb->posts}
WHERE post_type = 'page'
AND post_status = 'draft'
AND post_name = 'checkout'
LIMIT 1"
);
if ( $post_id ) {
wp_delete_post( intval( $post_id ), true );
}
} );Activate, visit the homepage once to trigger it, then deactivate and delete the snippet. The draft was gone, and the active checkout page could finally claim the /checkout/ slug.
Lesson learned: if a phpMyAdmin query runs but seems to do nothing, check your table prefix. WordPress defaults to wp_ but many installs use a custom prefix. Using $wpdb->posts in PHP is safer than hardcoding the table name in SQL.
The Cart Caching Issue That Needs a Hosting-Level Fix
Even after setting up Cloudflare bypass rules and WP Optimize exclusions, the cart on this site was still occasionally showing stale content. The culprit turned out to be HostGator’s server-level cache — a caching layer that operates independently of Cloudflare and WordPress, at the hosting infrastructure level.
This is a layer most site owners don’t know about. HostGator’s shared hosting runs its own caching system that can serve cached versions of pages regardless of what Cloudflare or WP Optimize are configured to do. And unlike Cloudflare and WordPress caching, you can’t configure it yourself — it requires contacting HostGator support directly.
The fix: contact HostGator support and say exactly this: “Please exclude /cart/ and /checkout/ from server-level caching on my account. My WooCommerce cart is showing stale cached content to customers.” Their support team can add these exclusions at the server level. It’s a routine request they handle regularly.
If you’re on a different host, the same issue can occur with any host that runs server-side caching. The fix is the same — contact support with the specific paths you need excluded.
Scoping PayPal to WooCommerce Pages Only
Covered in detail in Post 4, but worth reiterating here in the WooCommerce context: PayPal’s JavaScript SDK loads on every page by default. On a blog post, it serves no purpose and adds significant Total Blocking Time.
The Code Snippets fix to scope it correctly:
add_filter('woocommerce_paypal_payments_sdk_components_hook', function($components) {
if (!is_cart() && !is_checkout() && !is_product()) {
return [];
}
return $components;
});After this fix, PageSpeed scores on non-WooCommerce pages improved noticeably — particularly Total Blocking Time, which is the metric most sensitive to heavy third-party JavaScript.
reCAPTCHA on PayPal Checkout
One additional WooCommerce-specific fix worth mentioning: fraud protection on the checkout page. WooCommerce PayPal Payments includes a built-in fraud protection setting under WooCommerce → Settings → Payments → PayPal → Fraud Protection. We set this to Basic, which adds lightweight checks without adding friction for real customers.
We also verified that reCAPTCHA was active on the checkout to prevent automated form submissions. If you’re running WooCommerce without any form of bot protection on checkout, it’s worth adding — checkout form spam and card testing attacks are common on small stores.
WooCommerce Caching Checklist
- Add /cart/, /checkout/, /my-account/ to Cloudflare bypass cache rule
- Add the same paths to WP Optimize caching exclusions
- Verify your checkout page is using the correct slug (/checkout/ not /checkout-2/)
- Contact your host to exclude /cart/ and /checkout/ from server-level caching
- Scope PayPal SDK to cart, checkout, and product pages only
- Enable WooCommerce PayPal fraud protection (Basic minimum)
- Add reCAPTCHA to checkout if not already present
- Test the full purchase flow after any caching change: add to cart → checkout → confirm order
→ Continue to Post 6: Lessons Learned and Final Results
← Back to Post 4: How to Speed Up a WordPress and WooCommerce Site on Shared Hosting
Things that I use, like, and am affiliated with:
Mint Mobile offers great cell phone service for $15 flat, get $15 off using the link. Get discounted phones with service activation and no contract.
I never spend money before I check Mr Rebates or Rakuten to get cashbacks, rebates, discounts, coupons or cheaper gift cards.