What Is availabilityEnds Schema?

availabilityEnds is a Schema.org property that states when the product or service included in an Offer stops being available. Schema.org accepts Date, DateTime, or Time values and lists the property for Offer, Demand, and ActionAccessSpecification.

The property describes an availability boundary, not a generic campaign deadline. A service package may stop accepting bookings before its price changes, while a product’s price may expire even though the product remains purchasable. The end date must therefore come from the operational rule controlling whether that particular item can still be obtained under the Offer.

Use it when the end is real, known, and useful to customers: ticket sales close at a defined instant, enrollment ends on a stated day, a seasonal rental stops being offered, or digital access is withdrawn at a scheduled time. If availability is open-ended, omitting the property is more accurate than publishing a guessed date.

1. Frame the decision raised by What Is availabilityEnds Schema.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Use a verified availability cutoff.
• Match the visible wording and page behavior.
• Omit unknown or open-ended dates.

availabilityEnds should communicate the real moment an offered item stops being available - nothing broader and nothing invented.

availabilityEnds is allowed on Offer, Demand, and ActionAccessSpecification. On most commercial pages, place it on the individual Offer whose product or service has the stated end boundary.

A Product page can contain several Offers for different sellers, regions, plans, or variants. Their availability windows may not match. Assigning one end date to every option can make a local deadline look universal. Model separate Offer nodes when commercial terms differ, then attach each end value only where it applies.

Review the entire relationship before publishing timing. The Offer should point to the correct item, and seller or provider identity should reflect the page. See itemOffered schema and seller schema for the surrounding graph. The date is meaningful only when the entity it qualifies is unambiguous.

• Evidence for Where Is availabilityEnds Allowed: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Identify who owns the cutoff.
2. Confirm the node supports the property.
3. Test every offer variation separately.

Attach availabilityEnds to the narrowest supported entity whose real availability ends at that time.

availabilityStarts marks the beginning of an availability window; availabilityEnds marks its end. Use one or both only when the corresponding boundary exists, and ensure the end occurs after the start for the same Offer and timezone.

Together, the properties can describe a finite availability window. They do not automatically describe campaign validity, price duration, fulfillment speed, or the page’s publication lifecycle. A launch page may exist before the start and remain online after the end while honestly explaining the closed offer.

Boundary logic should be tested as an interval, not as two unrelated fields. Normalize timestamps to the same instant standard, retain the market timezone for display, and reject reversed or zero-length intervals unless the business case deliberately represents a single instant.

1. Frame the decision raised by How Is availabilityEnds Different From availabilityStarts.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Validate start and end as a pair.
• Use the same Offer identity for both.
• Monitor behavior at both transitions.

Treat availabilityStarts and availabilityEnds as truthful boundaries of one offer window, not as decorative dates.

availabilityEnds tells when availability stops, while availability communicates the current availability state through an ItemAvailability value such as InStock, OutOfStock, PreOrder, or SoldOut. A date is not a state, and a state is not a cutoff.

An Offer can be InStock today and carry a future availability end because a seasonal sales window will close. After that moment, its state and user interface may need to change. If only the end timestamp updates while an enabled checkout and InStock markup remain, the page contradicts itself.

Build lifecycle rules that update all dependent representations from one source: inventory or access state, end timestamp, visible call to action, explanatory copy, feeds, and cached JSON-LD. Review our availability schema guide when choosing the state separately from its scheduled boundary.

• Evidence for How Is availabilityEnds Different From availability: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Read the current state from its owner.
2. Read the scheduled cutoff independently.
3. Verify the transition updates both.

Use availabilityEnds for timing and availability for state, then make both agree with what the customer can actually do.

availabilityEnds describes when the included product or service stops being available; validThrough describes the date after which an item is no longer valid. Those facts can occur together on an Offer, but they are semantically different.

An Offer may remain valid for contractual purposes while fulfillment slots have already closed. In another workflow, terms may expire while the underlying service remains continuously available under a new Offer. Copying one database “end date” into both properties conceals this distinction and makes later operational changes difficult to represent.

Name each timestamp before mapping it. Ask whether it closes access to the product or service, ends the validity of the commercial arrangement, or does both. If both properties are present, document why they share or differ in value and test examples where the dates diverge.

1. Frame the decision raised by How Is availabilityEnds Different From validThrough.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Label source fields by operational meaning.
• Do not duplicate dates merely for coverage.
• Test scenarios where validity outlives availability.

Choose availabilityEnds for availability and validThrough for validity, even when their timestamps happen to match.

availabilityEnds marks when the offered item stops being available; priceValidUntil is a Date after which a stated price is no longer available. A price can expire while the Offer continues at another price, so the properties are not interchangeable.

This difference is central to sale pages. “$79 through Friday” describes price validity, while “Registration closes Friday” describes offer availability. If both statements apply, the dates may be equal but still represent separate facts. If only the promotional price ends, keeping availability open is correct.

Schema.org accepts only Date for priceValidUntil, while availabilityEnds also accepts DateTime and Time. Do not reduce an exact availability cutoff to a price date simply because an existing template already supports it. Model the actual deadline and update visible pricing at the correct boundary.

• Evidence for How Is availabilityEnds Different From priceValidUntil: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Separate sale price from offer availability.
2. Map each deadline to its own source.
3. Test the price and checkout after expiry.

Use priceValidUntil for the price deadline and availabilityEnds for the item’s availability cutoff.

Use Date when the calendar day fully describes the end, DateTime when an exact instant matters, and Time only when a clock time is meaningful with sufficient context. For exact regional deadlines, include an explicit timezone offset.

A CMS-generated midnight can create false precision and even close an offer a day early for US users in another timezone. If the page says “Available through December 15,” a Date may be the honest representation. If ticket sales close at 8:00 p.m. Pacific, publish an offset-aware DateTime for that actual date.

Define whether the natural-language deadline is inclusive. Phrases such as “through Friday” and “ends Friday” can be implemented differently. The structured value, call-to-action behavior, and countdown must resolve to the same instant. Test daylight-saving transitions and regional storefront overrides rather than assuming a fixed offset year-round.

1. Frame the decision raised by Should You Use Date, DateTime, or Time.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Match precision to visible language.
• Resolve inclusive versus exclusive behavior.
• Test the intended US-market timezone.

Publish the least ambiguous value that fully represents the customer-facing cutoff.

Create the applicable Offer node, connect it to the correct item and commercial facts, then add availabilityEnds using the verified operational cutoff. Render the same truth in visible copy and make the transaction state change consistently at that instant.

Generate JSON-LD from the authoritative scheduling system rather than a manually maintained SEO field. The source should retain Offer identity, market timezone, start and end rules, status, seller, item, and change history. Templates should serialize values without silently converting blank fields to today or defaulting to midnight.

{
  "@context": "https://schema.org",
  "@type": "Offer",
  "itemOffered": {"@type": "Service", "name": "Holiday SEO Review"},
  "price": "399.00",
  "priceCurrency": "USD",
  "availabilityEnds": "2026-12-15T20:00:00-08:00"
}

• Evidence for How Do You Mark Up an Offer End Date: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Resolve the correct Offer.
2. Serialize its approved end value.
3. Verify behavior across the boundary.

An Offer end date is implemented correctly only when the source, visible page, transaction behavior, and markup agree.