Give each kind of product fact its own recheck trigger. Offer facts (price, stock, shipping) get rechecked whenever they change. Policy facts get rechecked whenever the policy is edited. Specifications get rechecked when the product, the supplier or the manual changes. Each also gets a calendar backstop, in case nobody notices the trigger.

Then keep four dates for every fact: when you saw it, when you verified it against a source, when it’s true from and until, and when it’s due for another look. A label like “updated 2026” is none of those.

This template is our proposal. No platform we read says how long an assistant keeps a fact it received, so the only freshness you control is upstream: in your own data and the feeds and catalogs it flows into.

Four dates, four different questions

Most product data carries one date, if any, and it usually means “someone saved this record”. That date can’t answer the questions that matter.

Date Question it answers Example
observed_at When did we see this value in a copy we don’t control? The catalog record showed USD 97.97 on October 26
last_verified_at When did someone confirm it against the source? Checked the noise figure against the test report on March 3
effective_from / effective_to When is the fact true in the world? Sale price valid November 28 to December 1; return policy v4 from January 1
recheck_by When does our confidence run out? Spec: on the next supplier change, or by June 30 at the latest

The first two get confused most. Seeing a value in a catalog record isn’t verifying it. Our own pages make the same split: a guide built on catalog records observed on October 26 can be checked on October 27, which means we re-read the sources, not that we searched the catalog again. Both dates are true. They answer different questions.

The freshness template

One row per kind of fact. The trigger is what should send someone to recheck. The backstop is our starting proposal for when no trigger has fired. Shorten it for anything you change often; nothing here is a platform requirement.

Kind of fact Recheck when Backstop if nothing fires (proposed) Cost of a stale value
Price and sale price Any price change; a sale starts or ends Daily spot check of top sellers A shopper sees one price and pays another
Stock and availability Sells out, restocks, a variant is discontinued Daily, per variant An assistant offers a size you can’t ship
Shipping cost, speed, destinations Carrier or rate change; a new market Monthly A “free shipping” or “ships to Canada” promise you can’t keep
Returns, exchanges, final sale Any policy edit; a SKU moved to final sale Quarterly, and before peak season A refund you didn’t plan for, or a refused one the shopper didn’t expect
Specifications (size, capacity, noise, runtime) New model or batch; supplier change; manual revised Every six months A wrong-fit purchase and a return
Materials, ingredients, formula Supplier or formula change On every reorder from a new supplier A safety or allergy problem, not just a return
Compatibility (“fits model X”) The compatible product line changes Quarterly The shopper’s newer model isn’t on your list
Certifications and test reports The certificate’s expiry date On the expiry date A claim you can no longer back
Reviews and ratings Your review app changes how it counts Monthly, comparing page and catalog Two rating figures with no label
Identity (GTIN, brand, model number) Relabel, new packaging, new GTIN Yearly The product gets matched to the wrong listing
Generated copies of your facts Any change to the source fact After every source change A platform’s summary keeps the old value

The last row matters more than it looks. Shopify marks its catalog description and its generated spec, feature and selling-point lists as Inferred, meaning generated or enriched by Shopify. You can’t edit those directly, so the only trigger you control is changing the source and then checking that the copy followed. Our claim-record guide shows how to track every copy of a fact; this template decides when to look at them.

What the platforms say about timing

Here is what the current documentation says, kept apart from what it doesn’t.

Source What it says Status
OpenAI shopping help Pricing and shipping updates may take some time to show in ChatGPT; OpenAI is working on faster updates Documented. No length given
OpenAI product feed reference Submit the current price and update it when a sale starts or ends. Sale, expiration and availability dates don’t schedule changes. pre_order and backorder don’t schedule a future stock change Documented, for direct feeds
OpenAI merchant page Shopping is live for ChatGPT users in the U.S.; Shopify and Etsy catalogs are already integrated Documented on a marketing page. Other markets: announced as “over time”
Shopify agentic storefronts help Shopify Catalog continuously updates your product data, so AI channels receive your latest inventory and prices Documented. No interval given
Google Merchant Center, Store Quality Policy changes such as returns can take up to 30 days to show in your store quality and badge status Documented, for that program only
Google AI features page Check that Merchant Center and Business Profile information is up to date Documented. No cadence
How long any assistant keeps a fact it received Nothing we read says Not documented

Two things follow.

A date in a feed doesn’t do the work for you. OpenAI’s feed reference is explicit that a sale end date won’t end the sale and a pre-order date won’t move the stock status. The update has to be sent when the change happens. If you sell on Shopify, you probably won’t upload that feed, since OpenAI says your catalog is already integrated. The rule still describes the safe assumption for any route: change the value at the time, not in advance.

“Continuously updates” is the platform’s half. Shopify says Catalog keeps your inventory and prices current for AI channels. OpenAI says there may be a delay before price and shipping changes show. Both can be true at once, and neither tells you the length of the gap. Your half is making sure the source value is right, so whatever gets copied is right.

What the received record tells an agent about age

We checked what one route actually sends. Across all 1,620 results in our snapshot of 162 Shopify agent-catalog searches on October 26, 2026, no field in the returned products or variants carried a date or time. No “last updated”, no “price valid until”, no “verified on”. Availability was a plain true or false: true on 1,617 results, false on 3.

So an agent reading that record can’t tell whether a price was set this morning or last spring. It has to trust that the platform kept the record current. That’s an inference from one response type: other catalog calls may carry more, and an assistant may track timing on its own side. But it’s a strong reason not to rely on a date the record doesn’t carry. Your recheck dates live in your own records, and their job is to keep the values that get copied correct.

Worked case: a discount that went stale in a name

A real record shows how a price fact escapes every recheck. In the same snapshot, the search “resistance bands for physical therapy after knee surgery” returned a set of loop bands at position 4, listed at USD 97.97. Its option names carried discounts: “5 Band Set, 5-140 lb (Save 6%)”, “3 Heavy Band Set, 70-215 lb (Save 7%)” and others. The returned variant’s selected band option was labelled “5 Band Set (Save 10%)”, which isn’t in the option list at all (the variant title stayed the product name). The description said “40 layers of premium latex”; Shopify’s generated spec list said “30-layer premium latex”. The variants guide has the full record.

We can’t tell which discount is current, or which layer count is right. What the template shows is why nobody would have caught it.

Fact in this record Kind of fact Where it lives now Would a price recheck catch it?
“Save 6%”, “Save 7%”, “Save 10%” Price Inside option names No. Names aren’t checked when prices change
Resistance ranges such as “5-140 lb” Specification Inside option names Only if names are part of the spec recheck
“40 layers” against “30-layer” Specification Description, and a generated copy Only if generated copies are rechecked
In stock: true Availability Variant field Yes, if stock is on a daily trigger

The fix is structural before it’s a schedule. Take the discount out of the name and express it as a sale price against the regular price, so it’s rechecked with every other price. Put the resistance range in its own field, on a specification trigger. Settle the layer count against the manufacturer’s document, then add the generated copy to the “after every source change” row.

Decorative dates are not freshness

A freshness label changes what a page says about time. It doesn’t change what anyone checked.

In our own simulation, a freshness label did nothing. In a Claude-only screening round of our product-pick test, adding “New 2026 / Bestseller” to vague product copy scored 0 of 108 for each of the two products. That’s a supplied-snippet test with invented products, not live behaviour. It does show that a year label can’t stand in for a missing fact.

A build date isn’t a check date either, including ours. Each page on this site has a data version, and the homepage’s carries a generated field. In a build we made on the evening of October 27, Toronto time, it read 2026-10-28, because it records the build date in UTC. It says when the file was made. It says nothing about when any fact on the page was verified. That’s why our articles carry separate published, updated and checked dates, and why every claim carries its own source date.

Apply the same test to your own store. For every date a shopper or an agent can see, ask: what event does this date record? If the answer is “the page was saved” or “the theme was rebuilt”, it isn’t a freshness signal, however recent it looks.

Run it on one product

  1. List the facts. Take one best-seller and list every fact on its page: price, stock per variant, shipping, returns, each specification, materials, compatibility, certifications, rating.
  2. Classify each using the template’s rows.
  3. Fill the four dates. Leave last_verified_at empty where nobody has checked. An empty date is honest; a guessed one isn’t.
  4. Set the triggers. For each row, name the event and who hears about it: the person who changes prices, the person who changes suppliers.
  5. Pull facts out of names. Any price, discount, range or size inside a title or option name gets its own field.
  6. Check the copies. After the next change, look at the received record a day later and note what it shows. That’s an observed_at, not a verification.

For reconciling price and stock between your page, feed and markup when they already disagree, see our price-mismatch guide. For publishing your facts and their dates as data alongside the page, see machine-readable product twins.

How we checked

On October 27, 2026 we re-read OpenAI’s shopping help page, its products feed reference (Stable) and its merchant page; Shopify’s agentic storefronts help page; and Google’s Store Quality and AI features pages. We quoted or paraphrased only what they say now.

We re-read all 162 saved responses from our Shopify agent-catalog snapshot of October 26, 2026 (top 10 per search, no buyer context) with a script. It walked every key in every returned product and variant, looking for names containing date, time, updated, created, modified, expiry, valid, stamp or a trailing _at, and found none. It also counted availability values: 1,617 true and 3 false. Each result carried one variant. For the resistance-band listing (position 4), we confirmed the option names, the returned variant’s name, the USD 97.97 price, the description’s “40 layers” and the generated “30-layer”. We didn’t query the catalog again.

The generated value comes from our own local build output on October 27. Store and brand names are withheld.

Your next step

Open your best-selling product and find every price, discount or size that lives inside a name rather than a field. Move each one into its own field. Then write the trigger for the three facts most likely to go stale (usually price, stock and the returns window) and the name of the person who’ll hear when they change.