Expiring items

What Google requires

Fresh data, refetched inside every 30 day window

Product data expires 30 days after Google last successfully processed it. Every fetch of your feed resets the clock for the products in it, so a healthy scheduled fetch means no product ever approaches the edge. The optional expiration_date attribute can only shorten this window, never extend it, and a date more than 30 days out is invalid on its own.

What happens if you do not

The catalogue thins out silently

When a scheduled fetch breaks, the feed URL starts failing, a password changes, an export job dies, nothing visible happens for days. Then products start expiring in the order they were last refreshed, and impressions decay with them. Because it is an absence rather than an error, it is routinely discovered weeks late. A hand-uploaded file has the same clock ticking from the moment of upload.

How to fix it by hand

Automate the refresh, then leave it alone

• Serve the feed from a URL on a scheduled fetch, or from a Google Sheet Merchant Center reads daily, rather than uploading by hand.
• Check the last-fetch date in Merchant Center when anything about the pipeline changes.
• Use expiration_date only for products that genuinely must stop early, and keep it inside the 30 day horizon.

Which of our checks apply

Two checks apply, read from the scanner's registry

The scan validates every expiration_date in the file. The corrections themselves live in a Google Sheet that Merchant Center reads every 24 hours, and that daily read is what keeps the corrected data from ever hitting the 30 day edge.

• expiration_date_pastblocks
• expiration_date_too_far_aheadblocks

The quicker way

Let the scan find them

The scan catches the expiration dates that are already wrong in the file, before the quiet clock does. The scan to identify errors is free and shows every finding before you pay anything. You only pay for the fix.

Scan your feed