Availability Blocks: Stock, Delivery, and Fulfilment

An availability block answers the buyer’s last operational question: can I obtain this item, by which method, and when? It keeps stock, delivery, collection, backorder, and discontinued facts in one extractable unit rather than scattering them between a badge, a checkout tooltip, and a shipping-policy page.

Why this element matters

Availability is not reassurance copy. It is a purchase constraint. A buyer who has chosen a product may still abandon the decision if the page cannot answer whether the selected variant is sellable, whether delivery reaches the required location, or whether it arrives before a real deadline. Precise availability reduces uncertainty at the moment uncertainty is most expensive.

The psychology is about control, not artificial urgency. “Only 2 left” can help someone judge risk when the number is true and current. The same message damages trust when it persists for days, resets after refresh, or refers to a warehouse that cannot serve the buyer. A useful block gives the reader facts needed to act: current status, destination, method, timing, conditions, and the next available action.

Machine extractability means a crawler, shopping agent, feed, or assistive technology can preserve the relationship between a variant and its fulfilment facts. A green dot beside “Available” is semantically weak: available for which color, location, method, and time? A labelled block can retain the complete answer.

Freshness matters because inventory is volatile. The content system should retrieve status from the commerce source of truth, while the visible timestamp and fallback policy make stale or unavailable data detectable. Search engines and AI systems must see the same material state a buyer sees; structured data cannot repair a contradictory page.

When to use it

Use an availability block when stock or fulfilment changes whether a reader can complete the intended action. It belongs on physical product pages, product listings where stock affects selection, tickets or inventory-limited offers, and commerce data endpoints designed for agents. It also works for pickup, local delivery, made-to-order lead times, backorders, pre-orders, and discontinued products.

Render the block per purchasable variant when size, color, pack, condition, seller, or location changes the answer. “In stock” for the product family is misleading when the selected size is unavailable. If a marketplace has several sellers, each offer needs its own price, availability, delivery promise, and seller identity.

Common near misses should stay outside this element:

• A service team’s next appointment is a booking slot, not stock availability.
• Opening times belong in hours and contact information; “open now” does not mean an item is present.
• A software feature’s release status belongs in product or release documentation unless access is genuinely capacity-limited.
• A promotion’s expiry is an offer condition, not an inventory state.
• A general shipping policy explains rules across orders; the availability block applies those rules to this item, destination, and time.
• A retailer’s marketing claim such as “ships fast” is not an estimate and should not occupy a delivery field.

The element writing rules take precedence: choose the block by purpose, not by its badge, card, or accordion styling. If the primary job is to state whether and how the selected item can be obtained, it is an availability block.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

Where to place it

Place the primary block in the purchase region, after the buyer has selected every variant that affects stock and immediately before the quantity control and purchase action. This order lets the page calculate one truthful state before presenting “Add to cart.” If variant controls sit above the price, place the block after those controls and update its accessible name with the selection.

On a category or listing page, use a compact status directly inside the matching product card. Link to the detail page for destination-specific dates unless the card can calculate them accurately. In a buying guide or review, place an editorially qualified status next to the merchant and verification time; do not imply that the publisher controls inventory.

The block may sit beside price when both refer to the same variant and seller. It may not sit beside a conflicting badge, an enabled purchase button for an unavailable item, an unrelated countdown timer, or a delivery claim based on another destination. Do not place a testimonial, promotional carousel, or cross-sell between the status and its next action. Do not hide discontinued status below reviews while leaving the former purchase control visible.

Mobile order must remain: selected variant, stock state, delivery or collection choices, conditions, then action. A sticky purchase bar may repeat a short state, but it must derive from the same source and never contradict the full block.

Anatomy

1. Context: identifies the exact product, variant, seller, and location to which the facts apply.
2. Stock status: uses one controlled state such as In stock, Low stock, Out of stock, Backorder, Pre-order, or Discontinued.
3. Quantity statement: gives a verified count or a non-numeric threshold label; it never manufactures scarcity.
4. Destination: names the country, region, postal code, or selected store used for the estimate.
5. Fulfilment method: separates shipping, local delivery, collection, and digital delivery.
6. Delivery or readiness window: shows an absolute date or bounded range, not “soon.”
7. Cut-off and conditions: states the timezone, order deadline, business-day assumption, membership requirement, or minimum order when material.
8. Unavailable policy and action: explains replenishment, substitution, backorder, notification, or archive behavior.
9. Freshness and source: records when the state was resolved and which authoritative service supplied it.
10. Commerce action: matches the state: purchase, pre-order, join waitlist, find another store, or view successor.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Design examples

Every variant uses text as well as color, preserves the selected-item context, and exposes a timestamp or live-source contract.

In stock with fulfilment choices. Use when the item is sellable now. Separate online stock from store stock, and show one estimate per eligible method.

Low stock. Use only when a governed threshold is crossed. Show an exact count only if it is safe and sufficiently current; otherwise say “Low stock” and retain the timestamp.

Out of stock, replenishment expected. Disable the immediate purchase action unless backorders are accepted. State the expected range only when merchandising or supply data supports it.

Backorder or pre-order. Keep these states distinct. State when payment is authorized or captured, the expected dispatch or release date, cancellation terms, and whether mixed carts ship separately.

Discontinued. Remove active purchase controls and active-offer markup. Preserve useful specifications and support information, then identify an official successor only when the relationship is verified.

Store collection. Name the store, ready-by time, reservation duration, and any identification requirement. “Available nearby” is not sufficient when the buyer must travel.

Parameters

“Source” below means where the renderer obtains the value. Commerce systems remain responsible for the underlying claim.

The controlled status maps to commerce truth, not presentation: in-stock, limited, out-of-stock, backorder, preorder, or discontinued. A channel-specific value such as collection-only belongs to method, because an item can be in stock while available only through collection.

Syntax and code examples

The three forms encode the same selected SKU, state, delivery range, source, and action. A project must register the corresponding Hugo or WordPress adapter before using that syntax in production.

Portable Markdown directive

:::availability{status=in-stock sku="TJ-NV-M" destination="US-10001" method="shipping,collection" earliest="2026-08-31" latest="2026-09-01" cutoff="2026-08-28T14:00:00-04:00" checked="2026-08-27T09:42:00-04:00" source="inventory-api,fulfilment-api"}
## Availability

In stock online and ready to dispatch.
Action: [Add navy Trail Jacket, size M to cart](https://example.com/cart/add/TJ-NV-M)
:::

Hugo shortcode

{{< availability status="in-stock" sku="TJ-NV-M" destination="US-10001" method="shipping,collection" earliest="2026-08-31" latest="2026-09-01" cutoff="2026-08-28T14:00:00-04:00" checked="2026-08-27T09:42:00-04:00" source="inventory-api,fulfilment-api" >}}
## Availability

In stock online and ready to dispatch.
Action: [Add navy Trail Jacket, size M to cart](https://example.com/cart/add/TJ-NV-M)
{{< /availability >}}

All parameters are named. The example intentionally avoids mixing positional and named parameters.

WordPress

[availability status="in-stock" sku="TJ-NV-M" destination="US-10001" method="shipping,collection" earliest="2026-08-31" latest="2026-09-01" cutoff="2026-08-28T14:00:00-04:00" checked="2026-08-27T09:42:00-04:00" source="inventory-api,fulfilment-api"]
In stock online and ready to dispatch.
Action: <a href="https://example.com/cart/add/TJ-NV-M">Add navy Trail Jacket, size M to cart</a>
[/availability]

A native WordPress block should store these values as typed attributes rather than a single rich-text blob. Server-side rendering is preferred for the initial state; client-side personalization may refine the destination and estimate after consent or input.

Good and bad examples

Good

Navy Trail Jacket, size M — in stock online. Delivery to 10001 is estimated for 31 August–1 September with standard shipping. Order by 14:00 ET on 28 August. Store collection availability is checked separately. Inventory and delivery estimate checked at 09:42 ET on 27 August 2026.

This works because it binds the state to a selected variant, destination, method, date range, timezone, and verification time. The reader can act without interpreting an icon or opening a generic policy.

Bad

🟢 Hurry! Available now — selling fast. Delivery soon. Only a few left!

This fails because “available” has no variant, seller, or channel; “soon” has no destination or dates; “a few” has no governed threshold; and the urgency cannot be audited. The green icon also carries meaning that is absent from the text. Replacing the icon with a red one would not fix the missing facts.

Schema markup and accessibility

For a genuine purchasable item, the block can feed Product.offers through an Offer or AggregateOffer. Map the controlled visible state to the corresponding Schema.org availability URL, such as InStock, OutOfStock, BackOrder, PreOrder, Discontinued, or LimitedAvailability. Price, currency, seller, item condition, and URL must describe the same offer. Do not use InStock merely because another variant or seller has inventory.

Delivery facts may feed OfferShippingDetails: destination, handling time, transit time, rate, and eligible method must agree with the visible promise. Do not emit an active Offer for a discontinued item or leave stale offer markup behind when the visible action becomes a waitlist.

Structured data is an output of the commerce state, not a second inventory database. Generate the visible block, feed, and JSON-LD from the same resolved offer whenever possible. If they cannot update on the same schedule, publish the least permissive defensible state until synchronization completes.

Accessibility requires a text label for every status; color, animation, and icons may reinforce but never define it. Associate updates with the selected variant. When a variant or destination change updates the block asynchronously, move neither focus nor the reader unexpectedly; announce a concise result through an appropriately configured live region. Avoid repeating countdown announcements every second.

Delivery controls need explicit labels such as “Delivery postal code” and “Change collection store.” Dates must include the month in words where numeric order could be ambiguous, and cut-offs need a timezone. Disabled purchase controls need nearby text explaining why and offering the valid next action. Keep the full state available without hover and provide a server-rendered fallback when JavaScript fails.

Writing rules

Lead with the controlled status in two to six words: “In stock online,” “Backorder available,” or “Discontinued.” Follow with the consequence: ready to dispatch, expected release date, or no longer sold. Use one block per selected offer, not one block per warehouse record.

Use absolute delivery dates or a bounded two-date range. If the estimate changes by destination, name the destination. If no estimate is reliable, say what must happen before one can be calculated. “Usually,” “soon,” “fast,” and “should arrive” are not substitutes for a sourced range.

Keep the primary block to one status line, one to four fulfilment rows, one policy sentence of 10–45 words when needed, and one primary action. A low-stock label needs an approved threshold; an exact count needs a current source. Review the state continuously through system integration and test its fallback during every content QA cycle.

Use calm, operational language. Never include fabricated scarcity, anonymous popularity claims, unrelated discounts, testimonials, warranty detail, full returns terms, or generic shipping-policy copy. Never call a pre-order “in stock,” represent an unavailable item as “available to order” without saying backorder, or promise a date that the fulfilment system cannot support.

For discontinued items, say “Discontinued” rather than “Currently unavailable.” Explain whether support, parts, manuals, or an official successor remain available.

Post types that use it

The postTypes frontmatter field is the source for this implementation matrix.

QA checklist

• The status applies to the selected SKU, seller, channel, and location rather than the product family in general.
• Stock, sellability, fulfilment method, and delivery timing are separate fields and do not contradict one another.
• The inventory and fulfilment sources are authoritative, monitored, and named in the component contract.
• The checked time is present, includes a timezone, and meets the business’s freshness tolerance.
• Exact counts and low-stock labels use governed rules rather than promotional urgency.
• Every delivery estimate names or inherits a visible destination and uses an absolute date or bounded range.
• Backorder and pre-order states explain payment timing, expected dispatch or release, and cancellation conditions.
• Out-of-stock and discontinued states remove or replace the immediate purchase action.
• Visible content, feed data, checkout behavior, and Offer structured data describe the same state.
• Status is conveyed in text, dynamic changes are announced appropriately, and controls have explicit labels.
• The block remains meaningful without color, hover, animation, personalization, or JavaScript.
• Mobile and sticky purchase treatments derive from the same source and preserve the correct reading order.
• All three syntax examples map to the same typed fields without losing source or freshness data.

FAQ

Should an availability block show an exact stock count?

Only when the inventory system is authoritative, the count updates quickly enough, and exposing it creates no operational or security risk. Otherwise use a controlled status such as In stock, Low stock, Backorder, or Out of stock. Never invent urgency with an unverified count.

What should the block say when an item is out of stock?

State Out of stock, explain whether replenishment is expected, give a verified date or range when one exists, and offer a relevant next action such as a restock alert. Do not show a purchasable Offer or an active Add to cart action when checkout cannot accept the order.

How should backorders and pre-orders differ?

A backorder is an established item temporarily unavailable for immediate fulfilment; a pre-order is an item not yet released for normal sale. Label the state accurately, state when payment is taken, and give the expected dispatch or release date with any uncertainty.

Does an availability block require Offer schema?

No. The visible block must be accurate even without structured data. When the page describes a genuine purchasable offer, its visible state should align with the Offer availability value and any shipping details. Editorial mentions and unavailable catalog records must not be marked up as active offers.

Can delivery estimates be personalized by location?

Yes, if the destination is identified and a non-personalized fallback remains available. Announce dynamic changes to assistive technology, avoid using IP location as certainty, and keep the server-rendered stock state accurate for crawlers and users without JavaScript.