WooCommerce CRO Technique

Add a sticky add-to-cart bar on WooCommerce mobile product pages

A mobile sticky add-to-cart bar keeps a purchase control reachable after shoppers scroll past the native product form on a WooCommerce product page. It helps most on long mobile PDPs where users browse images, reviews, returns or delivery content below the fold, and it should be judged on mobile add_to_cart per view_item, then mobile PDP conversion rate or RPV rather than on any promised uplift.

Summary

Bottom Line: On WooCommerce mobile product pages, a sticky add-to-cart bar usually works best as a compact secondary CTA that appears only after the main add-to-cart has scrolled out of view.

  • Prefer theme-native support in Kadence, Astra Pro or Flatsome before adding another plugin, because the feature already exists in those ecosystems and usually needs less custom front-end code.
  • Keep the bar compact on mobile. Baymard and NN/g both support sticky UI when it improves discoverability, but both also warn that oversized persistent elements can obstruct content and reduce the content-to-chrome ratio.
  • Variable products need extra QA. Astra’s built-in sticky bar renders the real add-to-cart form only for simple, external and subscription products; for other product types it outputs a link back to the product form instead. Kadence has also historically handled variable products by linking back to the form rather than completing the purchase from the sticky bar itself.
  • Measure this as a product-page experiment, not a visual tweak. In GA4, use view_item, add_to_cart, begin_checkout and purchase, and add custom sticky_atc_visible / sticky_atc_click events if you want to know whether the sticky bar is genuinely creating extra action.
  • Guard Core Web Vitals. Extra JavaScript and rendering work can worsen INP, and a bar that appears or disappears clumsily can hurt CLS.

How To Implement

  • Choose the lightest viable route first: theme-native, then a small tweak, then a plugin fallback

    • Kadence Pro: enable Appearance → Kadence → WooCommerce Addons, then go to Appearance → Customize → WooCommerce; Kadence adds Sticky Add To Cart under Single Product Layout.
    • Astra Pro: enable the WooCommerce module from Appearance → Astra Options, then edit Appearance → Customize → WooCommerce → Single Product; Astra exposes Sticky Add To Cart there.
    • Flatsome: the sticky option exists under Flatsome → Theme Options → WooCommerce → Product Page → Product Summary → Sticky Add to Cart. Public official Flatsome docs are sparse on this specific setting, so that admin path is best-verified via a third-party integration note rather than first-party docs.

  • Use the built-in option if it already matches your required behaviour on mobile

    If the built-in bar already appears only after scroll, respects your header, and gives you the content you need, stop there. This is usually safer than installing a broader floating-cart plugin, because extra JavaScript can add main-thread work that harms responsiveness.

  • Decide whether you need true variation mirroring or only a secondary route back to the form

    On many stores, the right answer is not “complete the whole variable-product selection in the sticky bar”, but “show the selected price/label if one is chosen, otherwise use the sticky CTA as a fast scroll-back to the real form”. That is because built-ins vary: Astra includes title and price in the sticky markup, but for non-simple product types it outputs a link back to the form rather than the full inline purchase controls. Kadence has historically treated variable products similarly.

  • For classic PHP-template themes, add the sticky shell via hooks, not via a hard template override

    WooCommerce’s classic single-product template runs the native add-to-cart through woocommerce_single_product_summary at priority 30, and Woo’s own theming guidance recommends hooks as the upgrade-safe way to add or move output. In practice, that means adding a sticky wrapper after the native add-to-cart output through a child theme or code-snippets plugin, rather than copying core template files unless you truly need structural changes.

  • For block themes and Site Editor stores, keep the real buying control inside the product template blocks

    In a block theme, edit Appearance → Editor → Templates → WooCommerce → Single Product. WooCommerce documents that the Single Product template contains blocks such as Product Price and Add to Cart with Options, and the newer Add to Cart + Options block adds richer variation handling and live variation-linked updates in newer WooCommerce releases. Use those blocks as the source of truth, then layer a lightweight sticky shell around them if needed.

  • Trigger the sticky bar only after the native CTA has left the viewport

    Use IntersectionObserver to observe the native add-to-cart form or button and show the sticky bar only when that target is no longer intersecting. This is the cleanest way to meet the UX requirement of “only when needed”, and it avoids covering content above the fold. If you build a custom bar, add bottom padding using env(safe-area-inset-bottom) so it clears iOS safe areas and home indicators.

  • Keep the mobile bar shallow and information-dense

    Aim for one row where possible: short product or variant label, current price, and one primary CTA. Keep tap targets large enough for touch, preserve whitespace around the CTA, and avoid turning the whole screen edge into a thick sticky slab. Baymard specifically warns against full-width sticky add-to-cart buttons with no breathing room, and NN/g warns that sticky UI on mobile must stay small enough to protect the content-to-chrome ratio.

  • If you need product/variation details visible on mobile, check your theme’s defaults before assuming you have them

    Astra is a good example: its sticky bar markup includes thumbnail, title and price, but Astra’s mobile CSS hides the title and price by default, leaving a more minimal bar on small screens. If your buyer needs variant and price confirmation in the sticky bar, you may need a small CSS/JS layer even when the theme feature is switched on.

  • Only use a plugin fallback if theme-native or a small tweak will not do the job

    If you need a plugin, favour something narrow and current rather than a bigger “floating cart” suite that solves a wider problem. For example, Simple Sticky Add To Cart For WooCommerce is a WordPress.org plugin whose listing shows it was updated recently, supports HPOS compatibility, and includes mobile/scroll controls in its changelog history. By contrast, broader sticky-cart products are often solving sitewide cart access rather than a narrow mobile PDP CTA problem.

  • QA the overlap and tracking edge cases before rollout

    Test on small iPhones and Android devices with cookie banners, store notices, live chat, sticky headers, and product-option fields turned on. Baymard explicitly warns that sticky elements such as chat can block critical page content on mobile, and option/add-on plugins can make sticky clones drift away from the real purchasing state. Measurement note: before launch, add custom events such as sticky_atc_visible and sticky_atc_click with a parameter like cta_surface = sticky|main, then register that parameter as an event-scoped custom dimension in GA4 so the test is diagnosable later. Also confirm any plugin fallback declares HPOS compatibility, because HPOS is enabled by default on new WooCommerce installs from 8.2 onward and extensions are expected to declare compatibility.

How To Measure

Key KPI — Mobile add-to-cart rate on product pages. In practice, read this as mobile add_to_cart relative to mobile view_item on PDPs, then look at mobile PDP conversion rate and RPV as second-order outcomes. GA4’s ecommerce model is built around events such as view_item, add_to_cart, begin_checkout and purchase.

GA4 event(s) / report — Use view_item, add_to_cart, begin_checkout and purchase. Read them in a GA4 Exploration or in the Monetization / Ecommerce purchases report, with a comparison or segment for device category = mobile and a PDP-only page set. Google’s tech details documentation confirms that device category is automatically populated as desktop, mobile or tablet.

Scroll-to-ATC behaviour — The clean version is to log custom sticky_atc_visible and sticky_atc_click events and report them by cta_surface. If you cannot add custom events immediately, GA4’s default scroll event is a rough proxy for deep-scroll users, but note that it fires only the first time a user reaches roughly 90% vertical depth, so it is not a perfect “scrolled past native CTA” measure.

What success looks like — A credible win is: higher mobile add_to_cart rate on PDPs, then either higher mobile PDP conversion rate or higher mobile RPV, with checkout completion at least flat. Because this technique mainly changes product-page reachability rather than checkout mechanics, it should usually move earlier-funnel product-page behaviour first.

Guardrail metrics — Do not accept gains if AOV falls sharply, checkout completion (begin_checkout → purchase) worsens, or mobile LCP / INP / CLS regress. Google’s current “good” thresholds remain about LCP ≤ 2.5s, INP ≤ 200ms, and CLS ≤ 0.1 at the 75th percentile. Also watch analytics volume after consent, because UK/EEA consent mode means some users will not be trackable until they grant permission.

Pitfalls

  • Myth: “A sticky add-to-cart bar always increases sales.” It does not. The strongest independent evidence supports the usability logic of keeping the primary purchase action reachable and visually distinct, but Baymard and NN/g also warn that sticky UI can become obstructive if it is large, redundant or badly timed. Treat it as a testable hypothesis, not a universal uplift tactic.
  • Mistake: installing a broad floating-cart plugin when you only need a mobile PDP secondary CTA. A sitewide sticky or floating cart solves a different problem from a mobile product-page sticky add-to-cart. Woo’s marketplace description for Sticky Cart for WooCommerce makes clear that it is a broader sticky-cart pattern that appears across the site, whereas this technique is about the product page only.
  • Mistake: assuming variable products will “just work” in the sticky bar. They often do not. Astra’s implementation is explicit: simple, external and subscription products get the real form in the sticky bar, while other types get a link back to the form plus price. Kadence’s historical notes point in the same direction. If your store relies heavily on size, colour or bundle choices, this is the first QA path to test.
  • Mistake: letting the bar obscure banners, notices or content on small screens. Baymard warns that sticky mobile elements such as chat can block critical content, and NN/g warns that sticky UI should maximise the content-to-chrome ratio. On real stores, that means checking cookie banners, promo bars, chat widgets, and native store notices together rather than in isolation.
  • Mistake: shipping the visual change without instrumentation. If you cannot separate clicks on the main CTA from clicks on the sticky CTA, you will struggle to tell whether the bar created incremental action or merely moved existing intent. GA4 supports custom event parameters and event-scoped custom dimensions specifically for this type of reporting.

Examples

FAQs

Sources & Further Reading

Want us to implement this for you?

We run measured CRO consultancy for WooCommerce. If you want help prioritising, testing & implementing these improvements, tell us about your store.

Book Pilot

About This Page

  • Written By: Eliot Webb – Founder & WooCommerce CRO Consultant
  • Last Reviewed: 5 Jun 2026
  • Last Updated: