Google supports the unavailable_after meta attribute, which will tell Google not to show this page in search results after the specified date/time. The problem with this, is that if you try to change the unavailable_after date later, Google might not pick up on it because Google may not try to crawl that page before the last given date.
Google first began supporting unavailable_after in July 2007 and it has been used primarily for content you don’t want Google to show in its index after the date you placed. It also has been used for products you no longer sell.
But Gary Illyes from Google added a bit more detail on this on LinkedIn when he was asked about using it as an alternative from using a 404 status code. This specific example is that the pages normally expire after 24 to 72 hours, they have “very short lifespans,” Javier Lorente Murillo wrote. But sometimes, those dates can be extended to beyond the 72 hours, if the advertiser wants to extend them.
Javier asked, “To prevent massive 404 errors and manage our crawl budget, we want to implement the unavailable_after meta tag across all short-lived listings. However, users can renew their ads, which means our system would dynamically push the unavailable_after date further into the future on the fly.” He continued to ask, “Are there any negative SEO implications if Googlebot sees the unavailable_after date constantly shifting forward on the same URL? Will Googlebot eventually start ignoring the tag due to these frequent changes, or is it completely fine to use it dynamically to manage indexation life-cycles in a high-turnover environment?”
Gary Illyes from Google responded:
My gut feeling is 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. It doesn’t have implications on anything but index selection, where it acts as a “you can drop this now” signal.
In short, this can work, but if you tell Google to drop the page at a specific date and time, Google might respect that and not check to see if there is a new date from the original date it crawled and processed. It just might not work, timing-wise.
I am wondering if those URLs should just set the unavailable_after date after it expires fully and just make the date to when it actually does expire. Of course, that might lead to the page showing in Google for longer…
Forum discussion at LinkedIn.
