更新をすぐ検索側に伝えられる？｜巡回を待たない知らせ方

「記事を更新しても、検索結果に反映されるまで時間がかかる」「巡回を待つしかないと思っていた」——更新の頻度が高いサイトを運営していると気になる点です。更新を検索側に伝える手段は、巡回を待つことだけではありません。こちらから知らせる仕組みが用意されています。この記事では、その仕組みと、使うときの注意点を整理します。

検索側が更新に気づくまで時間がかかるのはなぜか

検索の仕組みは、世界中のサイトを巡回して回る収集の役割と、集めた内容を整理して保存する登録の役割、そして問い合わせに応じて並べる表示の役割に分かれています。更新に気づくまでの時間の多くは、最初の収集の段階で生まれます。収集する側は、サイトごとに「だいたいこのくらいの頻度で変わる」という見立てを持っており、その見立てに沿って訪問の間隔を決めているためです。更新が少ないサイトほど訪問の間隔は空き、公開から気づかれるまでが長くなります。

この見立ては、過去の更新の実績から作られます。月に1本しか記事が増えないサイトを毎時間見に来る理由はありませんし、1日に何十本も入れ替わるサイトを週に1度しか見ないのも無駄が多い。収集する側は限られた資源を配分しているので、サイトの側から見れば、自分の更新の速さと訪問の間隔が噛み合わない期間が必ず生じます。立ち上げたばかりのサイトや、月に数本の更新にとどまる法人サイトで待ち時間が長く感じられるのは、この配分の結果です。

さらに、収集されたからといってすぐ登録されるとも限りません。収集は入口にすぎず、そのあとに内容の解析、重複の判定、既存の登録内容との比較が続きます。内容がほとんど変わっていない更新は、登録の側で優先されにくいこともあります。つまり待ち時間は「訪問までの時間」と「訪問後の処理の時間」の2段階でできており、サイト側から短くできるのは前半だけです。ここを理解しておくと、通知の効き目に過剰な期待をしなくて済みます。

巡回を待つ以外に知らせる道がある

収集する側の訪問を待つのは、いわば向こうから来てもらう受け身のやり方です。これに対し、サイトの側から「この住所の内容が変わりました」と知らせる方式が2021年に公開仕様として整えられました。検索の場を運営している側が共同で公開したもので、特定の会社の独自機能ではなく、誰でも実装できる公開された取り決めとして文書が出ています。

知らせる側は、変わった頁の住所を指定して送るだけです。受け取った側は、その住所を優先的に見に行く候補として扱います。重要なのは、送るのは住所であって、中身そのものではないという点です。内容の良し悪しを申告する仕組みではないので、送ったあとに実際に見に来て、内容を読み、登録するかどうかを判断するのは従来どおり相手側です。

この方式が受け入れられた背景には、双方の無駄を減らしたいという事情があります。収集する側は、変わっていない頁を何度も見に行く分の通信量と処理を減らせます。サイト側は、更新のたびに訪問を待たずに済みます。省資源という共通の利点があるからこそ、複数の運営者が同じ仕様に乗る形になりました。自社にとっては「早く伝わる」ことが利点ですが、相手にとっては「無駄な訪問を減らせる」ことが利点だという非対称は、送る件数の考え方にも関わってきます。

なお、この仕組みはあくまで補助です。サイトの構造がたどりにくい、内部の導線が切れている、といった根本の問題を抱えたまま通知だけ増やしても、収集の効率は上がりません。導線の設計や一覧の整理といった土台があってはじめて、通知が上乗せとして効きます。

更新を通知する仕組みはどう動くのか

動き方は3段階です。第1に、サイトの所有者であることを示す鍵となる文字列を用意し、その文字列を名前にしたファイルをサイトの直下に置きます。第2に、変更のあった頁の住所と、この鍵を添えて送信します。第3に、受け取った側が鍵ファイルを実際に読みに来て、送信者が本当にそのサイトを触れる立場なのかを確かめます。この確認があるので、他人のサイトの住所を勝手に送りつけることはできません。

鍵は決まった長さの範囲にある英数字の並びで、自分で作って構いません。作った文字列をそのままファイル名にし、ファイルの中身にも同じ文字列を書いて置くのが基本の形です。たとえば文字列が長い英数字の並びなら、その並びに拡張子を付けた名前のファイルを、サイトの一番上の階層に置きます。置き場所を深い階層にすると読みに来られない場合があるため、特別な理由がなければ直下に置くのが無難です。

この4段階のうち、つまずきやすいのは3つ目と4つ目の間です。送信そのものは受け付けられたのに、鍵のファイルが読めずに止まっている状態が起こりえます。設定の直後は、サーバーの記録を開いて鍵のファイルへの訪問があるかどうかを一度だけ確かめておくと、うまく動いていない状態に長く気づかないという事故を防げます。

対応している場と、送り先の共有

この仕様の特徴は、参加している運営者どうしで送られた住所を共有する点にあります。つまり、参加しているどこか1か所に送れば、同じ仕様に参加している他の場にも住所の情報が回ります。複数の窓口に同じ内容を送る必要はなく、送信先を1つに絞っても実質的に届く範囲は変わらない設計です。

参加している運営者には、この仕様を最初に公開した2社に加えて、各国の検索の場や、配信を担う基盤の事業者が名を連ねています。日本語圏の一般的な検索行動の大半を占める場が全て参加しているわけではないため、「これを入れれば検索全体に一気に伝わる」とまでは言えません。参加している範囲がどこまでかは仕様の公式な案内で更新されるので、導入を検討する時点で最新の一覧を確認するのが確実です。

送信先を1つに絞ってよいとはいえ、実務では自社が使っているCMSの拡張や配信基盤がどこへ送っているのかを把握しておく価値があります。送信先が変わったときに気づけるからです。設定の台帳に、鍵の文字列、鍵のファイルの場所、送信を担っている仕組みの名前、送信先の窓口の4点を書き残しておくと、担当が変わっても追えます。

大手の検索はこの通知を使っているのか

よく聞かれるのが、日本で最も使われている検索の場がこの仕組みを使っているのか、という点です。ここは慎重に書く必要があります。公式に参加を表明していない場については、通知が反映に効くとは言い切れません。効果の見立てを立てるときは、参加が明示されている場に対してだけ効くと考えるのが安全です。

では、参加していない場向けには手がないのかというと、そうではありません。従来からある一覧の地図の更新、更新日時の正しい記載、更新頻度に見合った内部の導線づくりといった手立ては引き続き有効です。また、個別の頁については各検索の管理画面から確認と登録の依頼を出せる場合があり、急ぎの1本にはそちらが向きます。手段は場によって使い分けるのが実際の運用です。

ここを取り違えると、投資判断を誤ります。「入れれば全ての検索で早くなる」という前提で工数を割くと、期待した変化が見えず、仕組みそのものを疑うことになります。参加している場での反映が早くなる、という範囲を最初に社内で共有しておけば、小さく入れて長く回す判断がしやすくなります。

導入に必要なものは鍵ファイルひとつ

必要なものは驚くほど少なく、鍵の文字列とそれを名前にしたファイル、そして送信の手段だけです。サーバーの設定を大きく変える必要はなく、既存の頁に手を入れる必要もありません。追加の費用も、多くの場合は発生しません。この軽さが、試しに入れてみる判断をしやすくしています。

ただし、置き場所の権限には注意が要ります。サイトの直下にファイルを置けない構成のサービスを使っている場合、この仕組みを入れること自体が難しくなります。また、社内の規定でサイト直下に素性の分からないファイルを置けない場合もあるため、何のためのファイルなのかを事前に説明できる材料を用意しておくと話が早く進みます。

• 鍵の文字列は秘密の情報ではないが、勝手に変えると送信が通らなくなるので設定台帳に必ず控える
• 鍵のファイルは誰でも読める状態にしておく必要がある。認証の内側に置くと確認が通らない
• サイトの引っ越しやサーバーの入れ替えのときは、鍵のファイルの移行を作業手順に入れる

導入の担当を誰にするかも決めておきます。CMSの拡張で自動化する場合は運用担当だけで完結しますが、自前で送信の処理を書く場合は開発の手が要ります。後者を選ぶと、担当者が異動したときに誰も触れない仕組みになりがちです。運用の続けやすさを優先するなら、拡張で済ませられるかをまず確かめる順番が現実的です。

送り方は3通りある

送信の方法は大きく3つに分かれます。1つ目は、決まった形式の住所をブラウザで開くだけの単発の送信です。1本の頁を急いで知らせたいときに使えます。2つ目は、複数の住所をまとめて送る形式です。一覧をまとめて処理するときや、大量に入れ替えたときに向きます。

3つ目は自動化です。CMSに拡張を入れて、公開ボタンを押したときに自動で送る形にするか、配信を担う基盤の機能として有効にする形にします。運用として続くのは、この自動化を選んだ場合がほとんどです。手作業の送信は最初の数週間は回りますが、更新の頻度が上がるほど抜けが増え、やがて誰も送らなくなります。

送り方	向いている場面	手間	抜けやすさ
単発で1本ずつ	価格や日付の急ぎの修正	小さい	抜けやすい
まとめて送る	一覧の入れ替え、移行後の一括通知	中くらい	回数が少なく管理しやすい
CMSや基盤で自動送信	日々の記事公開と修正	初回のみ	抜けにくい

導入の順番としては、まず単発の送信で仕組みが動くことを確かめ、そのうえで自動化に切り替えるのが安全です。いきなり自動化から入ると、動いていないのか、動いているのに反映が遅いだけなのかの切り分けが難しくなります。最初の1本を手で送り、鍵のファイルへの訪問が記録に残ることを見てから次に進みます。

1回に送れる件数と、送りすぎの線引き

まとめて送る形式では、1回の要求で最大1万件の住所を送れるとされています。この数字だけを見ると、サイトの全ページを毎日送ってもよさそうに思えますが、実際にはそうした使い方は想定されていません。送るのはあくまで「変わった頁」であって、全ての頁ではないからです。

変わっていない頁を繰り返し送ると、受け取る側から見れば無駄な訪問を誘発する行為になります。仕様の目的が双方の無駄を減らすことにある以上、目的に反する使い方です。極端な送りすぎが続くと、そのサイトからの通知の扱いが下げられる可能性も否定できません。「更新したときだけ送る」という基本を守るのが、長く効かせる条件です。

• 更新の有無にかかわらず、全ページの住所を毎日まとめて送る
• 同じ頁を1日に何度も送り、反映されないからと回数を増やす
• テスト環境や公開前の頁の住所を混ぜて送る
• 他社のサイトの住所を送って様子を見る

回数の目安を社内で決めておくとぶれません。たとえば「記事の公開と修正のたびに1回」「一覧の一括更新は日に1回まで」といった形です。自動化している場合は、短時間に同じ頁を何度も編集するとその回数だけ送信が走る設定になっていることがあるため、編集の途中では送らず、公開の確定時にだけ送る設定になっているかを確かめます。

削除した頁こそ知らせる価値がある

見落とされがちなのが、消した頁の扱いです。この仕組みは追加と更新だけでなく、削除された頁の住所を送ることでも使えます。受け取った側が見に行き、存在しないという応答を受け取れば、登録から外す判断が早まります。

法人サイトでは、この用途の価値が高い場面があります。終了したサービスの案内、募集が終わったセミナーの申込頁、改定前の価格が載っていた頁などは、残っていること自体が問い合わせの事故につながります。消してから検索結果に出なくなるまでの時間を縮められるなら、それは実務上の利益です。

ただし、消した頁の住所を送る前に、消し方が適切かを確かめる必要があります。存在しないという応答を返す形にしているのか、別の頁へ転送しているのか、残したうえで登録しない指定を入れているのかで、その後の扱いが変わります。転送している場合は転送先の住所を送るほうが素直です。消し方の設計が先で、通知はそのあとに来る作業だと考えてください。

通知しても順位は上がらない

最も多い誤解がここです。この仕組みは、気づかれるまでの時間を縮めるだけで、内容の評価には一切関与しません。送った回数が多い頁が優遇されることもありません。順位は従来どおり、内容と検索の意図との噛み合い方、サイト全体の状態、他のサイトからの参照といった要素で決まります。

この点を社内で先に共有しておかないと、導入後の評価がずれます。「入れたのに順位が変わらない」という報告が上がり、本来の狙いだった反映の速さが評価されないまま止まってしまうためです。導入の目的を「公開から表示までの日数」に置き、順位の指標とは分けて見るように最初から決めておきます。

逆に言えば、内容に問題がある頁を早く知らせても、早く評価が下がるだけです。公開前の確認を省いて速さだけを追うと、誤った価格や古い日付を素早く広める結果になりかねません。速さを手に入れたぶん、公開前の確認の重みは増します。通知を入れるなら、公開前の確認の手順も併せて締め直すのが筋の通った運用です。

送ったあとに何を確かめるか

送信して終わりにすると、動いていないことに気づけません。確かめる点は3つです。1つ目は、鍵のファイルへの訪問がサーバーの記録に残っているか。2つ目は、送信の応答が正常だったか。3つ目は、対象の頁が実際に検索の場で新しい内容に切り替わったか、です。

3つ目の確認は、頁の中の特徴的な語句で検索してみるのが手っ取り早い方法です。更新で新しく入れた語句が結果の抜粋に現れていれば、新しい内容で登録されています。古い抜粋のままなら、まだ切り替わっていません。日付を入れて比べるより、内容そのもので確かめるほうが確実です。

• 鍵のファイルへの訪問がサーバーの記録に残っているか
• 送信の応答が正常を示す値だったか（受理と反映は別であることに注意）
• 更新で足した語句が検索結果の抜粋に現れるようになったか
• 公開から切り替わりまでの日数を、導入前と後で比べているか

導入の効果を測るなら、導入前の数週間と導入後の数週間で、公開から表示の切り替わりまでにかかった日数の中央値を比べます。件数が少ないうちは平均より中央値のほうがぶれません。差が出ないなら、参加していない場が主な流入元になっている可能性が高く、そのときは別の手立てに切り替える判断ができます。

うまく届かないときに疑う3点

送っているのに何も変わらないときは、順に疑っていきます。第1に、鍵のファイルが読める状態にあるか。サイトの認証の内側に入ってしまっている、拡張子の扱いでファイルが返らない、誤って別の階層に置いている、といった原因が典型です。

第2に、送っている住所が正しいか。末尾のスラッシュの有無、先頭が現在の正式な形式になっているか、日本語を含む住所の変換が正しいか、といった点でずれが起きます。正式な形式と違う住所を送ると、別の頁として扱われて意味がなくなります。

第3に、そもそも対象の頁が登録できる状態にあるか。登録しない指定が残っている、別の頁を正式版として指し示している、収集を拒む設定に含まれている、といった状態では、いくら知らせても登録されません。通知は登録の可否を覆す仕組みではないためです。

この3点を順に潰しても変わらない場合は、参加していない場が主要な流入元になっているという結論に落ち着くことが多くなります。そこまで確かめたうえで「今の自社には効きにくい」と判断できたなら、それはそれで意味のある結果です。判断の材料が残るように、確認した内容を記録に残しておきます。

一覧の地図との役割の違い

更新を伝える手立てとして古くからあるのが、サイト内の住所を並べた一覧の地図です。こちらは「このサイトにはこういう頁があります」という全体像を渡すもので、網羅を伝える役割を担います。対して更新の通知は「この頁が今変わりました」という単発の合図で、速さを担います。狙いが違うので、どちらかで置き換えるものではありません。

一覧の地図には最終更新の日時を書く欄があり、収集する側はそれを見て訪問の優先度を決めることがあります。ただし、この日時が実態と合っていないサイトが多いため、参考程度にしか扱われないこともあります。日時を機械的に「今日」にしてしまう設定は、かえって信用を落とすので避けます。

	一覧の地図	更新の通知
役割	サイトの全体像を渡す	変わった1点を知らせる
更新の頻度	定期的に作り直す	変更のたびに送る
向く場面	新規公開、大規模な改修	価格や日付の修正、削除
効き方	網羅の抜けを減らす	反映までの時間を縮める

実務では両方を持つのが標準です。地図で網羅を担保し、通知で速さを補う。どちらか一方だけだと、抜けが残るか、反映が遅いままになります。地図の生成がCMSの標準機能で回っているなら、そこに通知の自動化を足すだけで両輪が揃います。

更新のたびに送るか、まとめて送るか

運用の設計で迷うのが送信の粒度です。更新のたびに1本ずつ送る方式は、速さが最大になります。一方、1日1回まとめて送る方式は、送信の回数が減り、短時間に何度も編集したときの重複送信を避けられます。

判断の基準は「その更新が遅れると誰が困るか」です。価格、開催日、在庫、募集の締切といった誤った内容が残ると実害が出る情報は、更新のたびに送る価値があります。反対に、文章の言い回しを整えた程度の修正は、まとめて送っても支障ありません。全ての更新を同じ扱いにせず、種類で分けるのが現実的です。

運用としては、CMSの中で「重要な修正」の印を付けられるようにし、印が付いたときだけ即時に送る、それ以外は日次でまとめる、という二段構えが扱いやすい形です。印を付ける判断は編集の担当が行い、送信の仕組みは自動で回す。人が判断する部分と機械が回す部分を分けておくと、担当が変わっても崩れません。

法人向けサイトで効きやすい場面

効き目が実感しやすいのは、更新の内容が「時間に敏感」な場面です。セミナーの申込頁で満席になったとき、サービスの提供地域が広がったとき、採用の募集が締め切られたとき。いずれも古い内容が残ると、問い合わせの対応工数が無駄に増えます。

もうひとつは、大規模な改修の直後です。住所の付け方を変えた、階層を作り直した、といった改修のあとは、新しい住所を早く伝えられるかどうかで、移行期間中の取りこぼしの量が変わります。転送の設定を済ませたうえで、新しい住所をまとめて送っておくと、古い住所が結果に残り続ける期間を短くできます。

逆に、効きにくいのは更新が月に数本にとどまるサイトです。もともと訪問の間隔がそこまで問題にならないため、通知を入れても体感の差が出ません。この場合は、通知そのものより、更新の頻度を上げるか、1本あたりの内容を厚くするほうが効きます。手立ての選び方は、自社の更新の頻度から逆算するのが筋です。

入れる前に社内で合意しておくこと

技術的には簡単でも、社内の合意がないまま入れると後で揉めます。第1に、サイトの直下にファイルを1つ増やすことの了解。情報システムの部門が管理しているサイトでは、ファイルの追加に申請が要ることがあります。

第2に、公開のボタンが通知の送信を伴うようになることの周知です。これまで「とりあえず公開して後で直す」という運用をしていた場合、その未完成の状態が早く伝わってしまいます。下書きの状態で公開しないという運用の徹底が、通知の導入とセットで必要になります。

第3に、効果の測り方の合意です。前述のとおり順位では測れないので、「公開から検索結果の内容が切り替わるまでの日数」を指標に置くことを、導入前に決めておきます。指標を決めずに入れると、数か月後に「結局効いたのか分からない」という評価になり、次の改善につながりません。

よくある質問

鍵の文字列は他人に知られても問題ないのですか

鍵のファイルは誰でも読める状態に置く必要があるため、文字列そのものは公開情報です。他人に知られること自体は前提の設計になっています。ただし、他人が同じ鍵を使って自社の頁の住所を送ることはできてしまうので、第三者が勝手に送った結果として意図しない頁が通知される可能性は残ります。実害が出る場面はまれですが、気になる場合は複数の鍵を使い分ける方法も用意されています。

送信の応答が正常なら、必ず反映されますか

いいえ。応答が示すのは「受け付けた」ことであって、「見に行った」ことでも「登録した」ことでもありません。受理されたあとに実際に見に行くかどうか、見た結果を登録するかどうかは相手側の判断です。応答だけを見て安心せず、実際の検索結果で内容が切り替わったかを確かめてください。

既存の記事を一括で送り直すのは有効ですか

内容を実際に見直したのであれば有効です。文章を書き足した、情報を最新に更新した、といった実体のある改訂であれば、その頁の住所を送る意味があります。一方、日付だけを書き換えて中身が変わっていない状態で送っても、見に来た側は変化がないと判断するだけで、良い結果にはつながりません。

まとめ

更新をサイト側から知らせる仕組みは、公開仕様として誰でも入れられ、必要なのは鍵のファイル1つと送信の手段だけです。効くのは「気づかれるまでの時間」であって順位ではないこと、参加している場に限って効くこと、変わった頁だけを送るのが前提であることの3点を押さえれば、取り違えずに運用できます。価格や締切、削除といった古い内容が残ると実害の出る更新から入れてみて、公開から表示の切り替わりまでの日数で効果を測ってください。速さを手に入れたぶん、公開前の確認は今まで以上に大切になります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。