What Is validThrough Schema?

validThrough is the Schema.org property for the date after which an item is no longer valid. It accepts Date or DateTime and can qualify supported entities including Offer, PriceSpecification, Demand, FinancialIncentive, JobPosting, MonetaryAmount, LocationFeatureSpecification, and OpeningHoursSpecification.

The definition is about validity, not every kind of expiration. A product may remain available after a promotional Offer ends; a page may remain useful after its commercial terms expire; and a price may change while the Offer continues. Before adding validThrough, identify exactly which node becomes invalid after the boundary.

Use it for a real, documented validity end: offer terms cease, a price specification stops applying, a job posting closes, or a schedule is valid only through a known date. Do not invent far-future dates to make markup appear complete. Open-ended validity is better represented by omitting the property.

1. Frame the decision raised by What Is validThrough 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.

• Name the entity whose validity ends.
• Use a verified boundary.
• Keep page behavior consistent after expiry.

validThrough should express the verified end of validity for one supported item, not serve as a universal expiration field.

Schema.org lists validThrough on Demand, FinancialIncentive, JobPosting, LocationFeatureSpecification, MonetaryAmount, Offer, OpeningHoursSpecification, and PriceSpecification. Place the value on the node that owns the validity rule.

Entity selection changes the claim. An Offer can continue while one nested price expires, so a price deadline may belong on PriceSpecification rather than Offer. A JobPosting closure belongs to the job, while a special schedule end belongs to OpeningHoursSpecification. Visual proximity on a page is not semantic ownership.

Create an entity-to-source map before automating markup. Document the record that creates each node, the field supplying its end date, the timezone policy, and the visible text that confirms it. For Offer graphs, keep the item relationship clear with the itemOffered guide and the commercial party clear with the seller guide.

• Evidence for Which Schema Types Support validThrough: 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 the rule that expires.
2. Select its supported node.
3. Attach validThrough only to that node.

Correct placement follows the validity-bearing entity, not whichever node is easiest for the template to reach.

validFrom identifies when validity begins, while validThrough identifies the date after which the same item is no longer valid. Together they can define a finite validity window for one supported entity.

The pair must be checked as an interval. Both values should qualify the same node, use compatible precision and timezone logic, and follow chronological order. A start from an Offer cannot be casually paired with an end from its nested coupon or price component. That creates a window that has no business meaning.

Read the full validFrom schema guide when designing the start boundary. Normalize DateTime values for comparison but retain their original market context. Test before, during, and after the validity window so markup, visible terms, and user actions transition together.

1. Frame the decision raised by How Do validFrom and validThrough Work Together.
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 both fields together.
• Preserve node identity through the pipeline.
• Monitor both boundary transitions.

A validFrom–validThrough pair is useful only when it forms one coherent validity window for one entity.

validThrough marks when an item stops being valid; availabilityEnds marks when the product or service included in an Offer stops being available. Validity and availability may end at different times.

A seasonal service can stop accepting reservations today while existing Offer terms remain valid for customers who already booked. In another case, promotional terms expire tonight but the service remains available tomorrow under a new Offer. Copying the same date into both fields without evidence obscures these distinct customer states.

Ask whether the boundary controls the legal or commercial applicability of the marked entity, or whether it controls the ability to obtain the offered item. Use validThrough for the former. Use the availabilityEnds guide for the latter, and publish both only when both facts exist.

• Evidence for How Is validThrough Different From availabilityEnds: 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. Name each ending event.
2. Map it to the correct property.
3. Test examples where the dates diverge.

Use validThrough for validity and availabilityEnds for availability, even if one campaign calendar schedules both.

validThrough can end validity for several supported item types, while priceValidUntil specifically states the Date after which an Offer price is no longer available. A price deadline should not automatically end the whole Offer.

Consider a subscription that costs $49 through June 30 and $59 afterward. The Offer may continue, but the stated price has a deadline. In that case, priceValidUntil describes the price. If the complete commercial arrangement itself ends, validThrough on the Offer may be appropriate. Both require visible supporting terms.

Precision differs as well: priceValidUntil expects Date, while validThrough accepts Date or DateTime. Do not discard an exact validity instant merely because an existing product template only exposes a price date. Fix the data model so each boundary retains its meaning.

1. Frame the decision raised by How Is validThrough Different From priceValidUntil.
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.

• Separate price changes from Offer termination.
• Preserve the required precision.
• Verify price and transaction state after the date.

Use priceValidUntil for a price deadline and validThrough for the broader validity end of its supported node.

validThrough describes the date after which a supported item is not valid; expires describes when time-limited content is no longer useful or available and is used on CreativeWork and Certification. Choose according to the entity and meaning, not the shared idea of an ending.

A campaign article can remain useful after an Offer embedded within it expires. The Offer can carry validThrough while the article should not carry expires. Conversely, a time-sensitive video or news item may expire even though it has no commercial Offer. Certification is a special area where entity support overlaps but the specific intended claim still matters.

Do not remove pages automatically because their Offer validity ended. Preserving useful explanatory content, updating calls to action, and linking to a current option may serve users better. Content lifecycle and commercial validity should have independent policies.

• Evidence for How Is validThrough Different From expires: 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 whether content or terms expire.
2. Check the supported entity type.
3. Apply an independent page-retention decision.

Use validThrough for validity and expires for the supported content-expiration meaning; never collapse their lifecycle decisions.

Use Date when the day completely represents the validity end and DateTime when an exact cutoff matters. Include an explicit timezone offset when the instant depends on a US market or regional schedule.

“Valid through December 31” generally supports a Date. “Offer terms end at 11:59 p.m. Pacific on December 31” supports an offset-aware DateTime. Avoid a CMS-generated midnight when no time was promised; it can cause terms to appear expired early in some timezones.

Define inclusivity carefully because the property describes the date after when the item is not valid. Align natural-language copy, backend eligibility, countdowns, caching, and serialized data to the same interpretation. Test daylight-saving changes with the actual timezone for the scheduled date instead of reusing a fixed offset.

1. Frame the decision raised by Should validThrough Use Date or DateTime.
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 wording.
• Resolve inclusive end behavior.
• Test the intended market timezone.

The best validThrough value is the least ambiguous supported representation of the real validity cutoff.

Create the correct Offer, connect it to its item and seller, then add validThrough using the approved validity end. Generate the value from the commercial system of record and keep visible terms, actions, feeds, and caches synchronized.

A page can remain online after Offer validity ends, but it must stop presenting expired terms as currently actionable. At the boundary, disable or replace the transaction path according to the real workflow, update explanatory copy, and regenerate structured data. Do not merely remove one JSON-LD property while checkout continues under invalid terms.

{
  "@context": "https://schema.org",
  "@type": "Offer",
  "itemOffered": {"@type": "Service", "name": "Annual SEO Review"},
  "price": "499.00",
  "priceCurrency": "USD",
  "validThrough": "2027-12-31T23:59:00-08:00"
}

• Evidence for How Do You Mark Up validThrough on an Offer: 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 Offer identity and validity rule.
2. Serialize the verified end without fallback guesses.
3. Verify the live transition and cache refresh.

validThrough markup is complete only when the Offer’s source, visible terms, customer action, and structured data agree.