Sticky Add to Cart Button: How We Score Rule PDP-003

A sticky add to cart button keeps the primary purchase control on screen while the shopper scrolls a long product page, usually as a compact bar pinned to the bottom edge on mobile or under the header on desktop. UXFix rule PDP-003 fails any product page where the add to cart control leaves the viewport and nothing persistent replaces it before the shopper reaches the end of the page. It is a medium severity, decision-stage, flow rule.

What PDP-003 actually checks

PDP-003 is one of the 115 rules in our fixed rule book. We run it on the live product page at a 390 pixel mobile viewport and a 1440 pixel desktop viewport, scrolling in fixed increments and recording whether an enabled add to cart control is present inside the viewport at each step.

The rule only applies to long pages. We define long as any product page where the content below the primary add to cart button is more than two viewport heights on mobile. A short page with the button, a paragraph and a footer does not need a sticky bar and does not get penalised for not having one.

The three outcomes are stated as conditions you can test yourself with a phone and a thumb.

A "scroll depth" here means one full viewport height. So the fail condition in plain English is: the shopper scrolls twice, the button is gone, and it never comes back until they scroll all the way up.

We treat a "Buy now" or express payment button as an acceptable persistent replacement only if it also adds the item to the cart or opens a cart drawer. A "Notify me" or "View similar" control does not count, and neither does a sticky header with a cart icon but no add action.

Why does the add to cart button disappear on long product pages?

Because the page got longer and the button did not move. Ten years ago a typical product page was an image, a title, a price, a button and a paragraph. Today the same page carries a comparison table, a size guide, three accordion blocks, a reviews module with filters, a shoppable video and a recommendations carousel. The button is still at the top.

NN/g's eye-tracking study on scrolling and attention found that users spend 57% of their page-viewing time above the fold, and 74% within the first two screenfuls. That is often read as "put everything at the top". The more useful reading for a product page is that the shopper who does scroll past two screens is the one doing real evaluation work, reading reviews and checking dimensions. That shopper is closer to buying than the one who bounced at the fold, and you have just hidden the button from them.

In UXFix audits of 137 failing mobile pages, the median failing page places the reviews module 3.1 viewport heights below the primary button. A shopper who reads two reviews and decides to buy has to scroll back roughly four screens, find the button, and confirm the variant they picked is still selected. Some do. Some open a new tab to a competitor instead. We cannot see which, and neither can your analytics if you only track add to cart events.

Those figures come from the 312 product pages UXFix audited in the most recent quarter, mostly Shopify, WooCommerce and Salesforce Commerce Cloud stores in the 1 to 50 million revenue range. Most of the clean passes were on themes that ship the bar by default.

Sticky add to cart on mobile: what fail, partial and pass look like

The examples below are anonymised from real audits. Each is described as the screenshot caption would read, so you can check your own page against the same observations without the image.

Fail: apparel store, 6,200 pixel product page

Observed on a 390 by 844 viewport: primary button at 620 pixels from the top. Size selector above it. Below the button, a fabric story, a size guide accordion, a "Complete the look" carousel, 48 reviews with a filter bar, and a footer. The button left the viewport at 1.1 scroll depths. Nothing replaced it. The header was sticky but contained only a logo, a search icon and a cart icon with a count.

What this costs: the shopper who checks the size guide, which is the most common reason to scroll on apparel, has to travel back up to buy. If they had not yet picked a size, the size selector is also up there.

Partially affected: supplements store, Shopify theme with a paid sticky bar app

Observed: a bar appeared at the bottom edge after 1.4 scroll depths. It showed the product name and an "Add to cart" button. It did not show the price, and it did not show the flavour or pack size the shopper had selected. When the shopper tapped the button, the page jumped back to the top to show the variant selector, which is the exact trip the bar was meant to remove.

The bar also covered the last two footer links, "Shipping" and "Returns", at the bottom of the page. That is a separate deduction under our footer accessibility check, but it also fails the obscuring clause of PDP-003.

Pass: furniture store, custom theme

Observed: the primary button sat at 560 pixels. The moment it crossed the top edge of the viewport, a 64 pixel bar slid up from the bottom containing a 40 pixel thumbnail, the selected finish, the price including the currently selected delivery option, and a full-width "Add to cart" button with a 48 pixel tap height. The bar respected the iPhone home indicator safe area. When the shopper focused the postcode field in the delivery estimator, the bar hid until the keyboard dismissed. At the footer, the bar stayed but the page had 80 pixels of bottom padding so no link was covered.

On desktop the same store used a slim top bar under the header rather than a bottom bar, which is the more common desktop pattern and equally acceptable under the rule.

How to implement a sticky add to cart on Shopify and custom themes

On Shopify, several current themes ship the behaviour natively. If your theme already has a "sticky add to cart" or "sticky product form" toggle in the theme editor, turn it on, then audit it against the partial conditions above. Native implementations usually get the price right and often get the variant wrong, so test a product with variants specifically.

If your theme lacks it, you have two routes. An app from the Shopify App Store is faster and is what most of our partially affected pages used. The recurring defects were missing variant state, covering the footer, and injecting the bar late enough to cause layout shift. A theme-level implementation takes a developer a few hours and avoids all three, because it can read the same variant state object the main form uses.

The structural pattern is small. The important details are in the behaviour, not the markup.

<div class="sticky-atc" data-sticky-atc hidden>
  <img class="sticky-atc__thumb" src="" alt="">
  <div class="sticky-atc__meta">
    <span data-sticky-variant>Size M / Navy</span>
    <span data-sticky-price>49.00</span>
  </div>
  <button type="button" data-sticky-submit class="btn btn--primary">Add to cart</button>
</div>

Whether you build or buy, check these behaviours before you ship. Start with the trigger and the state the bar carries.

• Trigger on visibility, not on a pixel offset. Use an intersection observer on the primary button and show the bar when it leaves the viewport. Pixel offsets break the moment a promo banner changes the layout.
• Mirror variant and quantity state. When the shopper changes size in the main form, the bar updates. When they tap the bar's button, submit the same form or call the cart API with the same variant ID. Do not scroll them back up.
• Handle the unselected state. If the product requires a variant and none is chosen, the bar should either open the variant picker in a drawer or read "Choose a size" and remain visible. Sending an error toast from the bottom of a 6,000 pixel page is a partial fail.

Then check what the bar covers and what it does to the layout.

• Reserve space. Add bottom padding to the page equal to the bar height once it is shown, so it never covers the footer, the cookie banner or a chat launcher. Position the chat launcher above the bar, not behind it.
• Avoid layout shift. Inject the bar in the initial HTML with the hidden attribute and toggle it, rather than appending it from a script that loads after the page paints. Late injection shows up in your Cumulative Layout Shift score and in shoppers mis-tapping the thing that moved.

Next, the two accessibility clauses we deduct against most often.

• Respect the keyboard and focus. Hide the bar while a text input is focused on mobile. WCAG 2.2 success criterion 2.4.11, Focus Not Obscured, requires that a focused element is not fully hidden by author-created content, and a bottom bar over a focused field is the textbook violation. The WCAG quick reference has the exact wording.
• Meet target size. WCAG 2.2 sets a 24 by 24 CSS pixel minimum at level AA and a 44 by 44 target for the enhanced criterion. A thumb on a moving bar deserves the 44. We deduct under partial when the button is under 44 pixels tall.

Finally, check the desktop stack and what an agent sees.

• Keep the bar out of the way of the sticky header on desktop. Two pinned bars on a 1440 by 800 laptop can eat a quarter of the vertical space. On desktop, a 56 pixel top bar that replaces the header once the button scrolls away is the cleaner pattern.
• Give it real text for agents. AI shopping agents that read the DOM look for the same button the shopper does. Duplicate controls with identical labels are fine as long as both work; a bar that is an image or an icon-only button is not. Our crawlability checklist for AI agents covers the rest of what agents need from a product page.

Does a sticky add to cart button improve conversion rate?

We are asked this on almost every audit call, and the honest answer is that we score compliance, not lift. We do not run A/B tests on client stores, so we do not have a controlled percentage to give you, and we will not borrow one from an app listing.

What we can say is grounded in the rule book. PDP-003 is medium severity because it does not block a purchase, it adds friction to one. The shopper can always scroll back. Compare that to a high severity rule like an unlabelled required field at checkout, which some shoppers cannot get past at all. Baymard's product page research puts the persistent add to cart in the same category: a mobile usability issue that causes needless scrolling and interrupts the evaluation sequence rather than a hard blocker.

The measurable outcome you can track yourself is behavioural. Before you ship the bar, record two events: add to cart clicks and the scroll depth at which each click happens. On a failing page every click happens in the first screen, because that is the only place the button exists. After you ship the bar, the distribution spreads down the page. Clicks from the bar at three or four screens deep are purchases from shoppers who were reading reviews or the size guide when they decided. Those are the shoppers you were previously sending back up.

If that distribution does not move at all after a fortnight, either your page is not actually long for most shoppers, or the bar has one of the partial defects above and people are not using it. Both are worth knowing.

A PDP UX checklist for the sticky bar

Use this before you ask us to re-audit, or as the acceptance criteria you hand to a developer or an app vendor. Every line maps to a clause in the PDP-003 rubric or to a neighbouring rule we check on the same page.

First, confirm the rule applies and the bar appears.

• The primary add to cart button is enabled and visible in the first viewport on a 390 pixel wide mobile screen.
• Below that button, the page runs longer than two viewport heights on mobile. If not, you do not need the bar and can stop here.
• A persistent add to cart control appears as soon as the primary button leaves the viewport, on both mobile and desktop.
• The persistent control shows the selected variant and the current price, including any active discount.

Second, check what happens when the shopper uses it.

• Tapping the persistent control adds the selected variant to the cart or opens a cart drawer. It does not navigate away and does not scroll up.
• With no variant selected, the control opens the variant picker in place or shows an inline prompt, and stays visible.
• The control is at least 44 CSS pixels tall on mobile and has a text label, not only an icon.
• The bar hides while a text input is focused on mobile, and never covers a focused element on desktop.

Third, check layout and the edge cases.

• The page has bottom padding equal to the bar height, so footer links, the chat launcher and the cookie banner remain reachable.
• The bar is present in the initial HTML and toggled, so it causes no layout shift on load.
• Out of stock variants disable the bar's button with a clear label rather than removing the bar. Our piece on out of stock pages explains why removing the control entirely costs you the back-in-stock signup.
• The desktop version does not stack with a sticky header to consume more than 120 pixels of an 800 pixel tall viewport, which is the threshold in the UXFix rubric.

If you want the surrounding context for this rule, the full list of what we check on product, cart and checkout pages is in all 115 checkout UX rules we audit against. PDP-003 sits in the product page group alongside variant selection, price visibility and stock messaging, and it is the one most often fixed within a week of the report landing, because the fix is mechanical.

Frequently asked questions