Google Still Won't Say If Refreshing Expiry Dates Works—And That's The Problem

2026-07-29 — marketing strategy SME India

Someone asked Google whether it's safe to keep extending an expiry date on product listings as users renew their ads. A straightforward question about a straightforward use case.

No clear answer came back.

Gary Illyes from Google Search responded on LinkedIn with a gut feeling instead. He thinks pushing the unavailable_after date forward is probably fine. But then he folded in a caveat—Google has to crawl the page again to see the new date. Which means the old date might already be gone before the bot shows up to check.

That's the catch nobody fully mapped.

Here's what happened. An SEO consultant named Javier Lorente Murillo was working with a classifieds site running about 5,000 core listings plus roughly 10,000 new ones each month. Most stay live for 24 to 72 hours. He wanted to use the unavailable_after tag to keep Google from crawling dead listings and wasting budget on 404s. Users can renew ads, so the expiry date would shift forward dynamically each time.

Simple request, right?

Illyes said he had to check. His first read—his words, not mine—was that "it's fine to push forward the unavailable_after date BUT you need to keep in mind that we'll need to crawl the page again to 'see' the new date." He also clarified that Google downloads the full page instead of using cheap header checks, so every refresh costs bandwidth.

That's not actually reassuring.

What Illyes didn't confirm—and what he admitted he'd need to verify—is what happens if the old expiry date passes before Google crawls again. If you set a date for Tuesday, then renew it for Friday, but Google doesn't check until Wednesday, does it drop the page from search results between Wednesday and Friday? Does it respect the new Friday date because it hasn't processed the old Tuesday date yet? Does the system get confused?

Nobody knows. Actually, that's not quite right—someone at Google probably knows. But it's not documented anywhere.

Google's official documentation covers unavailable_after as a way to tell search to stop showing a page after a specific date and time. It mentions that Googlebot crawls those URLs less often after the cutoff. The documentation does not address renewable listings or dates that shift with each user action.

The real issue is that the tag was designed for static expiry—an event page that ends on a known date, a promotion with a fixed deadline, content that's meant to age out once. Not for systems where the expiry keeps moving target. Most consultants get this wrong, including us sometimes. You assume the tool works the way you need it to. Then you find out mid-rollout that Google left a gap in the spec.

Illyes offered another detail worth parsing. Google would fetch the page instead of just checking the header. That costs more bandwidth and crawl budget than a quick HTTP HEAD request. So if your listing site renews thousands of items daily, you're asking Google to re-download content it's already seen. Using robots tags to manage crawl budget means blocking non-essential pages so bots spend time on pages that matter. Flipping the date repeatedly might waste budget instead of saving it.

Without a documented answer, sites renewing listings are working without a published rule. You're guessing based on a gut feeling from a Googler. That's fine for a prototype. It's not fine for a production system handling thousands of items.

The whole thing exposes a pattern. The documented use case is letting a page drop out of search results after a set date. The undocumented case—keeping it alive while moving the expiry forward—is the one that matters for most marketplaces. Google has a tool. Google uses the tool internally. But they haven't said whether the tool works the way real businesses need it to.

So classifieds sites, marketplaces, event portals—anyone with short-lived, renewable content—either bets on Illyes' gut or finds another approach.