PDP-005: Show a Delivery Date Estimate on the Product Page

A delivery date estimate on the product page is a specific arrival date, such as 'Arrives Thu 14 Mar', shown next to the add-to-cart button before the shopper commits to anything. In UXFix audits this is rule PDP-005, a high-impact, decision-stage check that our crawler verifies in the rendered DOM. Stores that show only a shipping speed like '3-5 business days', or that hide the date behind a ZIP form, do not pass.

What PDP-005 checks and why it sits in the decision stage

PDP-005 is one of the 115 rules in our rule book. Its definition is one sentence: the product detail page shows an estimated delivery or arrival date for the default shipping option, visible without interaction. It is tagged high for impact, decision for stage, and dom for detection method.

The stage tag matters. We split product page rules into discovery, evaluation and decision. Decision-stage rules are the ones that sit between the shopper being convinced and the shopper clicking the button. Price, stock status, returns and delivery date are the four questions almost every shopper resolves in that last second, and a missing answer to any of them sends them to a competitor tab.

The dom tag means our crawler does not judge this from a screenshot. It renders the page, waits for the network to settle, then searches the accessible text nodes and structured data for a date pattern within a fixed distance of the add-to-cart control. That is deliberate. If our parser cannot find the date, a shopping agent built on the same browser stack will not find it either.

The full list of what we check, and how the other 114 rules are tagged, is in All 115 Ecommerce Checkout UX Rules We Audit Against.

How we score it: Fail, Partial and Pass

We score PDP-005 on three tiers. The criteria are fixed so two auditors, or an auditor and a script, reach the same verdict on the same page.

The causes are predictable. Fails usually come from a theme with no shipping block, so shipping copy lives only in checkout. Partials come from a carrier API that is called only on ZIP entry, or a date placed in a 'Shipping and returns' accordion. Passes use geolocation or a default region to compute the date on load.

A few edge cases we get asked about, and how they score:

• 'Free shipping' with no date is a Fail for PDP-005. Cost is a separate rule. This rule is about time.
• 'Order in the next 2h 14m for delivery tomorrow' is a Pass, because 'tomorrow' resolves to a date and the countdown is tied to a real cutoff. It becomes a Fail if the countdown resets on refresh, which we test for.
• A date range like 'Arrives 12 to 14 March' passes. A range like 'Arrives in 5 to 15 days' is Partial. The difference is whether the shopper has to compute anything.
• A date shown only to logged-in users is Partial. Most product page traffic is not logged in.
• A date that appears in a sticky add-to-cart bar on scroll, but not in the first viewport, is Partial. The shopper who decides early never sees it.

What does a passing delivery date estimate look like on a real PDP?

Screenshots from audits are the fastest way to explain the tiers. We describe each one in text as well, because the text is what our parser and every AI agent actually uses.

Fail

Screenshot: a homewares PDP. Price, colour swatches, quantity picker and a black add-to-cart button. Below the button, three lines: 'Free shipping over $75', 'Easy returns', 'Secure checkout'. No date, no duration.

Caption: the DOM contains the string 'Free shipping over $75' and nothing that parses as time. The shipping policy page, two clicks away, says most orders arrive within 3-7 business days. Our parser never leaves the PDP, and neither does the shopper before deciding.

Partial

Screenshot: an apparel PDP. Under the size selector, a grey line reads 'Standard delivery: 3-5 working days'. Further down, inside a closed accordion titled 'Delivery and returns', a form asks for a postcode to 'check delivery date'.

Caption: the visible text is a duration, not a date. The shopper has to know whether today is a working day, whether the store ships on Friday, and whether 'working days' includes the day they order. The real date exists in the code but is rendered only after a form submission. A headless agent that does not submit forms sees the duration and stops.

Pass

Screenshot: an electronics PDP. Directly under the add-to-cart button, one line with a truck icon: 'Free delivery, arrives Thursday 14 March'. Next to it, a small 'to 94103' link that opens a ZIP editor. Nothing is collapsed.

Caption: the text node 'arrives Thursday 14 March' is in the first viewport, 48px below the button. The page also carries an Offer with shippingDetails whose deliveryTime matches the visible claim. The ZIP is inferred from IP on first load, and the shopper can correct it, but they never have to.

Why the date belongs on the product page, not only in checkout

The usual objection is that the date is already in checkout, so showing it earlier is duplication. It is not. Checkout is where the shopper confirms a decision. The product page is where they make it.

The two Baymard numbers, from its cart abandonment research, deserve a careful reading. 'Delivery was too slow' is a judgement, and a shopper can only make it if they know the date. When you show '3-5 business days', many shoppers assume the slow end and then add a buffer of their own. When you show 'Arrives Thursday', the same shipping service reads as faster because there is nothing to pad. Same carrier, same truck, different decision.

There is a second effect that is easy to miss. A shopper who cannot see the date on the PDP but wants the item for a specific day has to add to cart, start checkout, and possibly enter an address to find out. Some of that traffic then shows up in your analytics as checkout abandonment, when the real cause was a product page that made them go looking. We cover that downstream symptom in Why Shoppers Abandon Checkout When Delivery Dates Aren't Shown.

Our own audit data lines up with this. Across 312 product pages UXFix audited in the last two quarters, 41% had no date and no duration in the first viewport, and a further 34% showed a duration only. Just a quarter passed PDP-005 outright. Given how often shipping is one of the two or three things a shopper checks before buying, that is a large amount of easily fixed friction.

What AI shopping agents read in your DOM

An AI shopping agent, whether it is a browsing mode inside a chat assistant or a purpose-built buying bot, does not look at your page. It reads the DOM as text, sometimes the accessibility tree, and sometimes the JSON-LD. When a user asks it to find something that arrives before Saturday, the agent needs a literal date string to compare against. A duration forces it to guess, and most agents will either skip your product or repeat the range with a hedge that makes you look uncertain next to a competitor who names the day.

This is why PDP-005 is a dom check and not a visual one. Three things make your date legible to an agent:

• It is a real text node, not text baked into an image or drawn on a canvas.
• It is present in the initial render or shortly after, not only after a form submission or a click.
• It is duplicated in structured data, so an agent that reads JSON-LD first gets the same answer as one that reads visible text.

Schema.org's OfferShippingDetails type is the standard way to express the third point. Google documents how it reads this markup in its merchant listing structured data guide. A minimal example that matches the Pass screenshot above:

{
  "@context": "https://schema.org",
  "@type": "Offer",
  "price": "129.00",
  "priceCurrency": "USD",
  "availability": "https://schema.org/InStock",
  "shippingDetails": {
    "@type": "OfferShippingDetails",
    "shippingRate": { "@type": "MonetaryAmount", "value": "0", "currency": "USD" },
    "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "US" },
    "deliveryTime": {
      "@type": "ShippingDeliveryTime",
      "handlingTime": { "@type": "QuantitativeValue", "minValue": 0, "maxValue": 1, "unitCode": "DAY" },
      "transitTime": { "@type": "QuantitativeValue", "minValue": 2, "maxValue": 3, "unitCode": "DAY" }
    }
  }
}

Note that the markup expresses handling and transit windows, not a calendar date. That is fine. Agents can compute a date from it. What they cannot do is compute anything from an empty field, or from a visible date that contradicts the markup. In audits we flag a mismatch between the two as a separate defect, because an agent that sees 'arrives Thursday' in text and a five-day transit window in JSON-LD has to pick one, and it may pick the worse one.

If your store is being skipped by assistants for reasons beyond delivery, the wider set of blockers is in Why AI Shopping Agents Abandon Checkout on Your Store.

How to get to a Pass on your store this week

Most stores that fail PDP-005 already have the data. The carrier rates and transit tables that drive checkout can drive the PDP too. The work is mostly plumbing and placement.

1. Pick a default region. Use IP geolocation, a previously entered address, or your single largest shipping region. Show the date for that region on first load, and label it, for example 'to 94103' or 'to the UK'.
2. Compute the date, not the duration. Take your handling time, your carrier transit table for that region, your cutoff hour and your non-shipping days, and resolve them to a calendar date on the server. Return the date as text.
3. Place it within 300px of add to cart, in the first viewport at 375px wide as well as on desktop. If your button is sticky on mobile, the date belongs in the static block the shopper sees before scrolling, not only in the sticky bar.

Those three steps get you to a Pass. Three more keep the date trustworthy for shoppers and agents.

4. Make the region editable in one step. A small link that opens an inline ZIP field is enough. Do not require the shopper to use it.
5. Emit matching OfferShippingDetails markup from the same computation.
6. Handle the states where you do not know. Preorder items should say 'Ships from 2 April'. Made-to-order items should say 'Arrives 20 to 24 March' with a wider range rather than nothing. Out-of-stock items are a separate rule with their own fix.

Two implementation traps come up repeatedly in audits. The first is timezone. A shopper in Sydney ordering at 9am local sees 'order by 3pm today' computed against a US warehouse clock and gets a date that is off by a day. Compute cutoffs in the warehouse timezone but display the resulting date in the shopper's.

The second is caching. If your PDP is cached at the CDN for six hours, a date computed at 2pm is wrong by 4pm when the cutoff has passed. Either compute the date in a small uncached fragment, or cache with a key that includes the cutoff window.

If you sell across several carriers with different speeds, show the default option's date and a link such as 'Faster options at checkout'. Do not list four dates on the PDP. One clear date beats a table the shopper has to read.

Frequently asked questions