Perplexityに引用されるのは、必ずしも記事の質が最も高いからではありません。ユーザーが質問した時点で「最新であり、情報が古くないとすぐ確認できる」ページだから選ばれるケースも少なくありません。Perplexityにおいて、コンテンツの鮮度は順位を少し押し上げる加点要素ではなく、候補ソースに入るための条件です。2年前に書かれた優れた分析記事でも、更新されていない古いページに見えれば、時宜性が問われる回答では見送られます。その結果、情報が新しく、サーバーの応答も明確な、内容では劣る記事が選ばれることがあります。
Perplexityはどこから「鮮度」を読み取るのか
まず、2つの仕組みを分けて考えましょう。Perplexityは独自のインデックスを運用する一方、ユーザーから質問を受けた際にWebページをリアルタイムで取得する機能も備えています。インデックスの構築を担うクローラーがPerplexityBot、回答時にページ内容を確認するのがPerplexity-Userです。つまり、鮮度シグナルは「インデックス時」と「回答時」の2つのタイミングで読み取られます。両方の時点で確認される「このページが最後に更新された日時」が、一貫していて信頼できる状態にする必要があります。価格、バージョン、規制、年次データなど、時間の影響を強く受ける質問では特に重要です。モデルは、最近更新され、その事実を裏付けるシグナルがあるページを選びやすくなります。
- HTTPレスポンスヘッダー：Last-ModifiedとETag。クローラーが条件付きリクエストを行い、「前回のクロール後に変更があったか」を判断するために使います。
- sitemap.xmlのlastmod：優先的に再訪すべきURLをクローラーに伝えます。
- ページ内の構造化データ：Article／BlogPostingのdateModifiedとdatePublishedにより、コンテンツ側が申告する公開・更新日時をモデルが把握できます。
- ページ上に表示する日付：記事の冒頭や末尾に記載する「最終更新日」は、人にもモデルにも読み取られます。
- コンテンツ自体の時宜性：記事内の年、バージョン番号、最新データが、申告された更新日と整合しているかも確認されます。
まずはサーバー側の鮮度シグナルを正す
多くのチームは本文の更新に力を注ぐ一方で、サーバーが返すLast-Modifiedの誤りや欠落を見落としています。これは最もよくある問題であり、比較的修正しやすい箇所です。正しい運用は、ページの実質的な内容が変わるたびにLast-Modifiedを現在の日時へ更新し、変更がなければ元の値を維持することです。コンテンツのフィンガープリントとなるハッシュ値のETagも併用すれば、クローラーはIf-Modified-SinceまたはIf-None-Matchを使った条件付きリクエストを送信できます。ページに変更がなければ、サーバーはHTML全体を送らずに304 Not Modifiedを返し、変更があれば新しいコンテンツとともに200を返します。フロントエンドフレームワークやCDNを利用するサイトでは、初期設定のままだと毎回200が返り、Last-Modifiedもコンテンツの更新日時ではなくデプロイ日時を示すことがあります。すると、すべてのページが「たった今更新されたように見えるのに、実際には何も変わっていない」という矛盾した状態になります。
条件付きリクエストがクロール頻度を左右する理由
クローラーが各Webサイトに割り当てられるリソース、いわゆるクロールバジェットには限りがあり、無制限に巡回するわけではありません。サーバーが304で「変更なし」と素早く返せれば、節約したリソースを実際に更新されたページの再訪へ回せるため、再クロールまでの間隔を短縮できます。反対に、クロールのたびにページ全体をダウンロードさせられ、明確な更新日時も確認できなければ、クローラーは「このサイトのシグナルは信頼できない」と学習し、再訪頻度を下げます。クライアント向けのGEO監査でも、このレイヤーを修正した後、重要ページが再クロールされるまでの間隔が大幅に短くなるケースは、よく見られる所見の1つです。
sitemapのlastmodは正確でなければならない
sitemapのlastmodは、クローラーが巡回の優先順位を決める重要な手掛かりですが、正確でなければ意味がありません。よくある誤りは、サイト全体をデプロイするたびに、すべてのURLのlastmodを当日の日付へ更新することです。これはクローラーに「サイト全体が毎日変わっている」と伝えるのと同じです。実際のコンテンツが変わっていないことはすぐに見抜かれ、やがてsitemap全体の信頼性が下がり、本当に更新したページのシグナルまで弱くなります。lastmodにはビルド日時を一括適用せず、URLごとにコンテンツが実際に変更された日時を反映させてください。再訪する価値のあるURLだけを含め、ページネーション、タブページ、パラメータ付きページを詰め込んでシグナルを薄めないことも重要です。
dateModifiedとページ上の表示日を一致させる
構造化データのdateModified、HTTPのLast-Modified、sitemapのlastmod、ページ上に表示する「最終更新日」。この4つは、同じ更新日時を示す必要があります。schemaでは本日更新、ページには前年の日付、サーバーヘッダーにはまた別の日時が記録されている、といった矛盾があると、モデルにとってはノイズになり、鮮度の申告を保守的に疑うしかありません。実務では、コンテンツ管理システムに保存された実際の変更日時など、単一のデータソースに更新日時を集約し、4カ所すべてをそこから出力します。これにより、各シグナルの不一致を防げます。datePublishedには初回公開日を保持し、dateModifiedには最後に実質的な変更を行った日時を設定してください。どちらも必要です。
更新頻度：情報が古くなるページにリソースを集中する
すべてのページを頻繁に更新する必要はありません。サイト全体を定期的に改修しようとすれば、運用リソースが分散するだけです。まず、コンテンツを2種類に分けます。1つは価格、製品比較、連携サービス一覧、年次トレンド、規制、バージョンなど、時間の経過で古くなる情報です。もう1つは、用語の定義や原則の解説など、比較的変化しにくい情報です。前者には定期的なレビューサイクルを設け、情報が変わり次第更新し、4つの日時シグナルも同期させます。後者は、実質的な追記や変更がある場合にだけ更新します。「更新すべきか」の判断基準はカレンダーではなく、内容に実質的な変化があるかどうかです。1語だけ変更して更新日を新しくしても、モデルには見抜かれ、信頼が高まることはありません。
鮮度で問われるのは「どれだけ頻繁に変更したか」ではなく、「変更する理由があり、4カ所のシグナルが一致しているか」です。クローラーが信頼するのは、頻繁でも中身のない変更ではなく、予測可能で誠実なメンテナンスのリズムです。— Tenten GEO
再取得：Perplexityに命令はできないが、可能性は高められる
- robots.txtでPerplexityBotとPerplexity-Userをブロックしていないことを確認します。両方を許可しなければ、それ以降の対策は機能しません。
- 重要ページを更新したら、そのURLのLast-Modified、sitemapのlastmod、schemaのdateModifiedを同時に更新し、3つを一致させます。
- サーバーの応答時間を短縮し、変更のないページには304を正しく返します。クロールバジェットを、更新したページへ振り向けられる状態にします。
- 検索流入などのアクセスが多く、頻繁に巡回されるページから、新たに更新したページへ内部リンクを張ります。既存ページの再訪頻度を生かし、新しいページをより早く発見してもらいます。
- 更新後は、自社のメールマガジン、コミュニティ、外部から参照されるページなど、別のチャネルにも新たなクロールのきっかけを作り、早期に取得される可能性を高めます。
ここまでの施策は、アルゴリズムの機嫌を取るためのものではありません。実際に行った更新を、Perplexityに速く、正確に読み取ってもらうための整備です。多くのWebサイトが抱える問題は、コンテンツの質ではなく、鮮度シグナルの矛盾によって、良質な記事が古いページとして見過ごされていることです。Last-Modified、sitemap、schema、ページ上の表示日という4領域のどこで不整合が起きているか確認したい方は、30分のGEO診断（/contact）をご予約ください。Perplexityに見送られる原因となっているシグナルの欠落を、その場で明確にします。
