何が起きたか:Illyes氏が「分からない、確認が必要」と回答
Search Engine Journalの記事(見出し:「Google’s Illyes Unsure On Shifting unavailable_after Dates(GoogleのIllyes氏、unavailable_afterの日付をずらす件について確信を持てず)」)によると、イリェーシュ氏はLinkedIn上で、サイトがunavailable_afterの日付を安全に延長できるかどうかを確認しなければならないと述べました。記事によれば、氏の第一印象は本人が「直感(gut feeling)」と呼ぶもので、日付を先へ押し出すこと自体は問題ないというものでしたが、期限切れになった後に更新されるページでこのタグを信頼してよいかどうかは未決のまま残されました。
やり取りの冒頭でイリェーシュ氏は、「それはいい質問だ…まったく分からない、確認しないといけない(“that’s a great question… I have no idea, I have to check.”)」と応じています。Google側が公開の場で「分からない」と明言した形になり、記事はこの回答を起点に、unavailable_afterの仕様として確定している部分と、いまだ空白のままの部分を切り分けています。
そもそもunavailable_afterとは:指定日時以降は検索結果に出さないルール
unavailable_afterは、robots(ロボット)メタタグやX-Robots-Tag(エックス・ロボッツ・タグ)HTTPヘッダーで指定できるルールの一つです。Googleの公式ドキュメントは、このルールを「指定した日時以降、このページを検索結果に表示しない。日時はRFC 822、RFC 850、ISO 8601を含む(ただしこれらに限らない)広く普及した形式で指定する必要がある(“Do not show this page in search results after the specified date/time. The date/time must be specified in a widely adopted format including, but not limited to RFC 822, RFC 850, and ISO 8601.”)」と説明しています。
書き方は大きく2通りです。HTMLのhead要素に書く場合は、公式ドキュメントの例では <meta name="robots" content="unavailable_after: 2020-09-21"> のように記述します。HTML以外のファイルやサーバー側でまとめて制御したい場合は、HTTPレスポンスヘッダーとして X-Robots-Tag: unavailable_after: 25 Jun 2010 15:00:00 PST のように返します。掲載終了日があらかじめ決まっているページ、たとえば期間限定セールの告知や募集終了が確定している求人、開催日が過ぎるイベントの案内などが、このルールの想定される適用先です。ドキュメントはあわせて、「Googlebotは指定された日時以降、そのURLのクロール頻度を大幅に下げる(“Googlebot will decrease the crawl rate of the URL considerably after the specified date and time.”)」としています。
ここで押さえておきたいのが、公式ドキュメントが「robotsメタタグとX-Robots-Tag HTTPヘッダーは、URLがクロールされたときに発見される(“robots meta tags and X-Robots-Tag HTTP headers are discovered when a URL is crawled.”)」と明記している点です。ドキュメントは続けて、robots.txtでクロールがブロックされている場合には「インデックス登録や配信のルールに関する情報は発見されず、したがって無視される(“any information about indexing or serving rules will not be found and will therefore be ignored”)」としています。タグに何を書いても、Googleが実際にそのページを取得しない限り指示は届かない――この前提が、今回の論点の土台になります。
質問の中身:月に約1万件の新規掲載を抱えるクラシファイドサイトの相談
きっかけは、SEOコンサルタントのハビエル・ロレンテ・ムリージョ氏(Javier Lorente Murillo)がGoogleの検索チームに寄せた質問でした。記事によると、氏が相談したのはクラシファイド(classifieds:個人や事業者が売買・募集の広告を掲載する形式)サイトについてで、インデックスされているURLの中核が常時およそ5,000本あり、毎月およそ1万件の新規掲載が追加されます。そして掲載の大半は、24時間から72時間しか公開されません。
氏は、この短命なページにunavailable_afterを設定することで、404エラーの発生を避けつつクロールバジェット(crawl budget:Googleがそのサイトに割り当てるクロールの量)を管理しようと計画していました。ただし、このサイトではユーザーが広告を更新(renew)できるため、システム側が有効期限の日付を動的に書き換える設計になります。そこで氏は、更新のたびに変わり続ける日付を、Googlebotがやがて無視し始めるのではないかと尋ねました。
Illyes氏の回答:「後ろ倒しは問題ない」だが再クロールが前提
これに対しイリェーシュ氏は、「私の直感では、unavailable_afterの日付を後ろ倒しにするのは問題ない。ただし、新しい日付を『見る』ためには我々がそのページを再度クロールする必要があることを、念頭に置いておく必要がある。このルールはインデックス選定(index selection)以外の何にも影響せず、そこでは『もうこれを落としてよい』というシグナルとして働く(“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.”)」と回答しました。
さらに同じ投稿に付いた別のコメントへの返信で、氏はGoogleが安価な方法で確認するのではなくページそのものを取得することになると説明し、「我々がHEADリクエストを使うことはめったにないので、いずれにせよコンテンツをダウンロードすることになる(“we rarely see HEAD requests so we’d still download the content.”)」と述べています。HEADリクエストとは、ページ本文を受け取らずヘッダー情報だけを確認する軽量なリクエストのことです。つまり、日付の変更だけを低コストで拾い直してもらう手段は期待できず、日付を書き換えたページは通常のクロールで再取得されるのを待つことになります。
背景:公式ドキュメントが書いていること・書いていないこと
記事は、イリェーシュ氏の回答のうちどこまでが既存の公式情報に裏付けられているのかを切り分けています。unavailable_afterを「指定した日時以降そのページを検索結果に表示しないようGoogleに指示するルール」と説明する点、そして指定日時以降はGooglebotがそのURLをクロールする頻度が大幅に下がるという点は、いずれもドキュメントに書かれている内容です。robotsメタタグとX-Robots-Tagヘッダーが、URLをクロールしたときに検出されるという点、したがって変更後の日付は次回の取得時にしか現れないという点も同様だとしています。
一方で記事は、「その部分の回答は、Googleがすでに述べていることをなぞっている。このルールがインデックス選定以外には何も影響しないという主張は氏自身のものであり、ドキュメントには登場しない(“That part of his answer echoes what Google already states. The claim that the rule touches nothing beyond index selection is his own, and it doesn’t appear in the docs.”)」と付け加えています。公式見解と個人の見立てが同じ回答の中に混在している点に、注意を促した形です。
そして残された最大の空白として、記事は次の点を挙げます。「イリェーシュ氏は、Googleが最後に見た日付が、Googleがそのページに戻ってくる前に過ぎてしまった場合に何が起きるのかについては述べていない。それこそが、氏が確認しなければならないと言ったケースだ(“Illyes didn’t say what happens if the last date Google saw passes before it gets back to the page. That is the case he said he would have to check.”)」。さらに記事は、「更新のケースが未回答である以上、Googleから計画の拠り所になるものは何もない。結果を決めるのはGoogleがそのページをどれくらいの頻度でクロールするかであり、サイト運営者にそれは制御できない(“With the renewal case unanswered, there’s nothing from Google to plan around. What decides the outcome is how often Google crawls the page, and a site owner can’t control that.”)」としています。
実務への影響:期限付きページの運用で確認すべきこと
記事は結びで、判断の出発点は「そのunavailable_afterタグに何をさせようとしているのか(“The first call is what you’re asking the unavailable_after tag to do.”)」だとしています。そのうえで、「決まった日付以降にページを検索結果から外すこと。それがGoogleがこのタグについて文書化している用途だ。ページを生かし続けたまま、クロールを管理するためにこのタグに頼るというケースが、いまだ未解決のまま残っている(“Letting a page drop out of search results after a set date is what Google documents it for. Keeping a page alive while leaning on the tag to manage crawl is the case that’s still open.”)」とまとめています。記事によれば、公開時点でGoogleのドキュメントは、更新のたびに変わる有効期限については扱っていません。
この整理を自社サイトに当てはめると、確認すべき点は大きく二つに分かれます。一つは、そのページの公開終了日が本当に確定しているかどうかです。終了日が動かないページであれば、指定日以降に検索結果から外すという、ドキュメントが想定する使い方の範囲に収まります。もう一つは、掲載が延長され得るページでunavailable_afterに依存していないかどうかです。延長のたびに日付を書き換える運用では、Googleが次にそのページをクロールするまで新しい日付は認識されず、そのクロール頻度は運営側では決められません。
クロールバジェットの節約を狙ってこのルールを広く適用している場合は、対象URLの中に「期限が延びる可能性のあるページ」が混ざっていないかを棚卸ししておくと、想定外の脱落を避けやすくなります。あわせて、指定日時の書式が公式ドキュメントの示す形式(RFC 822、RFC 850、ISO 8601など)に沿っているか、そしてタグやヘッダーを設定したURLがrobots.txtでクロール禁止になっていないかも、実装時の基本的な確認事項です。クロールされなければ指示自体が発見されないという点は、ドキュメントが明記しているとおりです。
所感
ここからは記事本文にはない、Scale Basics編集部の見解です。今回のやり取りで実務者にとって重いのは、「日付を後ろ倒しにしてよいか」という許可の問題よりも、「新しい日付は次のクロールまで届かない」という構造のほうだと考えています。unavailable_afterは指定日時を過ぎるとクロール頻度が大幅に下がる仕様であるため、いったん期限切れとみなされたページほど、延長後の日付を読み直してもらう機会が細っていく可能性があります。掲載延長が日常的に発生する不動産、求人、中古売買のようなサイトでは、この一点の不確実性が在庫ページの露出に直結します。
日本の現場では、タグの実装は開発会社やインハウスのエンジニアが担い、掲載延長の運用ルールは事業部門や代理店が握っている、という分業が珍しくありません。unavailable_afterのように「実装の仕様」と「運用の頻度」が噛み合って初めて機能する設定は、この分業の境目でこそ抜けやすいものです。導入を検討するなら、掲載終了が確定しているページに限って適用し、延長があり得るページは別の設計(掲載終了時に適切なステータスコードを返す、一覧ページからの内部リンクで露出を制御するなど)に寄せるほうが、現時点では見通しの立つ運用になるはずです。Googleの回答がそろっていない領域に在庫の可視性を賭けるのは、優先度の高い施策とは言いにくいと考えます。
まとめ
・GoogleのGary Illyes氏がLinkedInで、unavailable_afterの日付を安全に延長できるかについて「分からない、確認しないといけない」と回答したとSearch Engine Journalが報じた
・質問したのはSEOコンサルタントのJavier Lorente Murillo氏で、常時約5,000本のURLがインデックスされ毎月約1万件の新規掲載が加わるクラシファイドサイトが対象。掲載の大半は24時間から72時間しか公開されない
・Illyes氏は「日付を後ろ倒しにするのは問題ないと思う」としつつ、新しい日付を認識するにはページを再クロールする必要があり、このルールはインデックス選定以外には影響しないと説明した
・Googleの公式ドキュメントは、指定日時以降そのページを検索結果に表示しないこと、指定日時以降はそのURLのクロール頻度が大幅に下がること、robotsメタタグやX-Robots-TagはURLのクロール時に発見されることを明記している
・記事は、Googleが最後に見た日付が再クロール前に過ぎた場合の挙動は未回答であり、更新のたびに変わる有効期限は公式ドキュメントでも扱われていないと指摘している
よくある質問
Q1: unavailable_afterとは何をするためのルールですか?
Googleの公式ドキュメントによれば、指定した日時以降そのページを検索結果に表示しないようGoogleに指示するルールです。HTMLのhead要素に書くrobotsメタタグと、HTTPレスポンスのX-Robots-Tagヘッダーのどちらでも指定でき、日時はRFC 822、RFC 850、ISO 8601といった広く普及した形式で記述します。ドキュメントは、指定された日時以降はGooglebotがそのURLのクロール頻度を大幅に下げるとも説明しています。掲載終了日が決まっているページを、その日以降は検索結果に出さないようにする用途が想定されています。
Q2: 掲載を延長して日付を後ろ倒しにした場合、Googleは新しい日付を見に来てくれますか?
GoogleのGary Illyes氏は、直感としては日付を後ろ倒しにすること自体は問題ないとしつつ、新しい日付をGoogleが見るためにはそのページを再度クロールする必要があると説明しています。robotsメタタグやX-Robots-TagはURLがクロールされたときに発見されるため、変更後の日付が反映されるのは次回の取得時です。ただし、Googleが最後に認識した日付が再クロールより前に過ぎてしまった場合にどうなるかは、Illyes氏自身が確認が必要だとしており、記事の公開時点で回答は出ていません。
Q3: 期限が延長される可能性のあるページでは、どう考えればよいですか?
記事は、まずそのタグに何をさせたいのかを判断の出発点に置くべきだとしています。決まった日付以降にページを検索結果から外すことはGoogleが文書化している用途ですが、ページを生かし続けたままクロール管理のためにこのタグに頼るケースは未解決のまま残っている、というのが記事の整理です。結果を左右するのはGoogleがそのページをどれくらいの頻度でクロールするかであり、それはサイト運営者側では制御できないとも指摘されています。
出典:Google’s Illyes Unsure On Shifting unavailable_after Dates(Search Engine Journal、Matt G. Southern氏、2026年7月29日)https://www.searchenginejournal.com/googles-illyes-unsure-on-shifting-unavailable_after-dates/584064/
参考:Robots Meta Tags Specifications(Google検索セントラル 公式ドキュメント)https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag
