PDP-002: Put the Add-to-Cart Button Above the Fold on Mobile

On mobile, the add-to-cart button should be fully visible on a 375 by 667 pixel viewport before the shopper scrolls, either inline in the page or as a sticky bar that is present on load. That is what UXFix rule PDP-002 checks. In our audits, a buy button that only appears after a swipe past the hero gallery and the variant pickers is one of the most common high-severity product page failures we find.

What PDP-002 checks, and how we score it

PDP-002 is one of the 115 rules in the UXFix rule book, and it sits in the product page group with a high severity weighting. The rule in one sentence: on a mobile product page, a working add-to-cart control must be fully visible within a 375 by 667 CSS pixel viewport on first paint, without scrolling, tapping or dismissing anything.

We check it with a screenshot, not the DOM. The auditor loads the PDP at 375x667, waits for the page to settle, captures the viewport and looks for the button. If a person holding the phone in one hand cannot see the entire button, the rule does not pass, whatever the HTML says about where the element is.

A few clarifications from cases we see every week.

• A "Notify me when back in stock" button in the same position counts as the CTA for an out-of-stock variant. Availability handling is scored under a separate rule.
• A "Select options" or "Choose size" button counts as partial, not pass, because the shopper still has to work out where the options live.
• A cookie banner that covers the button counts against you. The shopper sees the banner, not the button.
• A sticky bar that is present on load counts as fully visible. A sticky bar that only slides in after the shopper scrolls past the inline button does not, because on first paint there is nothing to tap.

Why does the add-to-cart button end up below the fold on mobile?

Nobody designs a product page with the buy button hidden. It happens by accumulation. Each element above the button is reasonable on its own, and together they push the button off the bottom of the screen.

Here is a typical stack on a Shopify or Magento theme, measured on a 375 pixel wide viewport:

• Announcement bar: 36 to 44 px
• Sticky header with logo, search and cart icon: 56 to 72 px
• Breadcrumb: 24 to 32 px
• Square hero image at full width: 375 px
• Thumbnail strip or dot pagination: 40 to 72 px
• Product title across two lines: 56 px
• Price and review stars: 48 to 64 px

Add it up and you are at roughly 635 to 715 px before a single variant picker appears. The viewport is 667 px tall. The button is already gone, and you have not yet placed a size selector, colour swatches or a quantity stepper.

Three things make it worse. The first is portrait photography. Fashion and home goods stores ship 4:5 or 2:3 product images, so the hero alone can run 470 to 560 px tall. The second is variant pickers rendered as full-width rows of radio buttons rather than a compact swatch row or a dropdown. A size picker with eight sizes that wraps to two rows costs another 100 px. The third is late-loading widgets: a reviews summary, a pay-in-four banner or a shipping estimator that injects itself above the button after first paint and shoves everything down.

Most themes are designed on desktop first, where the gallery sits on the left and the buy box on the right, both visible at once. When that two-column layout collapses to one column on a phone, the gallery goes on top and the buy box goes underneath. The theme did exactly what it was told. Nobody checked the result on a 667 px tall screen.

Why it matters: what the shopper does on the first screen

Shoppers do scroll on mobile. That is not the argument. The argument is about what happens on the first screen and what the shopper concludes from it.

Nielsen Norman Group's 2018 eye-tracking study on scrolling and attention found that people spend 57 percent of their page viewing time above the fold and 74 percent within the first two screenfuls. Attention falls away steeply after that. If your button first appears at 900 px, it sits in the zone where most of the attention has already been spent.

There is a second effect. A shopper who lands from a paid ad or a Google Shopping result has already seen the product and the price. They arrive intending to buy, or to check one specific thing such as whether their size is in stock. If the first screen shows them a photo they have already seen plus a title, the page has told them nothing new and asked nothing of them. A visible CTA is what turns a landing into a decision.

Baymard Institute maintains a mobile ecommerce UX benchmark within its wider ecommerce UX research precisely because the same buy box behaves differently once it collapses into one column. Our own audits show the same pattern. Across 250 mobile PDPs scored in the last quarter, 41 percent failed or partially failed PDP-002, and the fails cluster in fashion and home goods where portrait photography is standard. Buy button visibility is one of the twelve product page issues we cover in why shoppers leave your product page without buying.

Fail, partial and pass: screenshot examples from real audits

Every PDP-002 finding in a UXFix report ships with an annotated 375x667 screenshot. We draw the viewport boundary as a red line at 667 px and box the add-to-cart control wherever it actually sits, even if that is off-screen. Here are the three tiers as they appear in reports, with the alt text we attach to each image.

Fail: home goods store, portrait hero

The first screen shows an announcement bar, a header, a 4:5 hero image at 469 px tall, and the first line of the product title. Price, reviews, a three-row size picker and a two-row colour picker all follow. The add-to-cart button first becomes fully visible at 1,040 px, more than one and a half screens down. There is no sticky bar. A shopper arriving from an ad sees a photo they have already seen and nothing to tap.

Alt text: "Mobile product page at 375x667 showing a tall hero image and product title. The add-to-cart button is 373 px below the viewport edge. UXFix PDP-002 fail."

Partial: fashion store, clipped button

This store has a square hero and a compact swatch row, and the layout nearly works. The button's top 22 px poke above the bottom edge of the viewport, so the shopper sees a sliver of black with no readable label. Tapping the sliver works, but nothing tells them it is a button. On scroll, a sticky bar slides in from the bottom, which confirms the store knew there was a problem and solved it for everyone except the person who has not scrolled yet.

Alt text: "Mobile product page at 375x667 with the add-to-cart button clipped at the bottom edge, label not visible. UXFix PDP-002 partial."

Pass: consumer electronics store, short gallery

The hero gallery is capped at 300 px tall and cropped to 5:4, with swipe for more angles. One dropdown handles the storage variant. Title, price, star rating and the full "Add to cart" button all fit, with the button's bottom edge at 641 px. There is also a sticky bar containing the price and a second button, present on load, which means the button stays visible even after the shopper scrolls into the description.

Alt text: "Mobile product page at 375x667 showing hero image, price and a fully visible Add to cart button above the viewport edge. UXFix PDP-002 pass."

If you publish your own audit screenshots, mark them up so search engines and AI assistants can read what each one demonstrates. We use schema.org ImageObject nested inside the Article, with the rule ID and tier in the description:

{
  "@type": "ImageObject",
  "contentUrl": "https://example.com/audits/pdp-002-fail-375x667.png",
  "width": 750,
  "height": 1334,
  "caption": "UXFix PDP-002 fail: add-to-cart button 373 px below the 375x667 viewport edge",
  "description": "Annotated mobile product page screenshot. Red line marks the 667 px fold. Add-to-cart control boxed below the fold."
}

How to test it and how to fix it

You do not need our tooling to run the mobile CTA visibility test. You need ten minutes and a browser.

1. Open Chrome DevTools, toggle the device toolbar, and pick the iPhone SE preset or set 375 by 667 with a device pixel ratio of 2.
2. Disable cache and hard reload the product page. Wait until the network is idle so late-loading widgets have settled.
3. Do not dismiss anything. Do not scroll. Take a screenshot of the viewport.
4. Check that the entire button, including its bottom edge, is inside the shot and that the label says what tapping it does.
5. Repeat for the product with the most variant options in your catalogue, and for an out-of-stock product.
6. Repeat with the cookie banner in its default first-visit state.
7. Repeat on a real phone in Safari with the address bar and bottom toolbar showing, because the usable height is smaller than 667 px there.

If the button fails, fix it in this order. The cheap fixes come first and usually get you to a pass without a sticky bar.

• Cap the hero gallery height at 400 px or 60vh on mobile. Crop portrait images to square or 5:4 for the hero and keep the full crop for the zoom view.
• Collapse variant pickers. Colour swatches in one scrollable row. Sizes in a dropdown once you have more than six options.
• Remove the breadcrumb on mobile. Merge the announcement bar into the header or make it dismissable and remember the dismissal.
• Move the reviews summary and any pay-in-four banner below the button. They support the decision; they are not the decision.
• Reserve space for late-loading widgets with a fixed min-height so they cannot shift the button after first paint.

When the layout still cannot fit, add a sticky add-to-cart bar. Done well it is a pass on its own; done badly it creates new problems. The bar should be present on load, 56 to 64 px tall, pinned to the bottom with padding for the safe-area inset on notched phones, and show the current price alongside the button. The button target should be at least 44 by 44 px. WCAG 2.2 sets a 24 by 24 px minimum at level AA and 44 by 44 at AAA in its target size criteria, and on a thumb-driven screen you want the higher figure.

The bar also has to know about variant state. If a size is required and none is selected, tapping the sticky button must open the size picker with a visible prompt. A sticky button that silently does nothing, or throws a red error somewhere off-screen, scores worse in our audits than no sticky bar at all.

One more reason to care. The vision-based AI shopping agents we test against take a phone-sized screenshot and look for a buy control, much as we do. When the button is not in that first capture, some agents scroll and recover, others report that the product cannot be purchased. Give the button an accessible name of "Add to cart" as well, so DOM-based agents find it without needing the screenshot. The same discipline pays off further down the funnel, which is why the fold check reappears among the mobile checkout mistakes we score, and why PDP-002 is listed alongside the rest of the 115 rules we audit against.

Frequently asked questions