LinkedIn アカウントを開設しました: Google 検索でサイトを見つけやすくするためのニュースやリソースについては、LinkedIn アカウントをフォローしてください。

Google 検索で Signed Exchange の利用を開始する

Google 検索は Signed Exchange（SXG）を利用して、ユーザーのプライバシーを保護しながらコンテンツをプリフェッチできます。具体的には、AMP または非 AMP を問わずウェブサイトが SXG に対応している場合、Google 検索したときに返される、関連する結果の主要なリソースのいくつか（HTML、JavaScript、CSS、画像、フォントなど）を、プライバシーに配慮した形でプリフェッチできます。

ユーザーが最終的に結果をクリックした時点で主要なリソースがすでに使用可能になっているため、ウェブページが表示を開始するまでの時間が大幅に短縮され、ユーザーエクスペリエンスが向上します。これにより、コンテンツに関する Largest Contentful Paint（LCP）スコアが低減する可能性があります。Google 検索では、SXG の使用をランキングの直接的な要因として考慮することはありませんが、ページエクスペリエンスはランキングに影響するため、LCP の低減はランキングに影響を与える可能性があります。

SXG を実装する

SXG を実装するには、web.dev の詳細ガイドに沿って進めてください。実装したら、SXG でのパフォーマンス改善の測定と最適化に関するこちらのガイドをご覧ください。

AMP ページについては、amp.dev の詳細ガイドに沿って進めてください。

Google 検索に関するその他の要件

Google は SXG のキャッシュを使用してコンテンツをプリフェッチします。このようなキャッシュに保存された SXG は複数回配信される場合があります。

Google 検索に最新のコンテンツが表示されるようにするには、SXG の有効期限の値を適切に設定します。目安として、有効期限は次の両方の日数よりも短く設定してください。

HTTP ヘッダーによって決まるキャッシュの有効期限
コンテンツが JavaScript またはインライン JavaScript で作成された場合は 1 日後。それ以外の場合は 7 日後

複数のデバイスに配信された場合にコンテンツが適切に表示されるようにするには、次のようにします。

ショッピングカートなど、パーソナライズされたコンテンツは遅延読み込み要素に移動し、SXG 対応から外します。または、Vary: Cookie 符号付きヘッダーを追加します。このヘッダーを含む SXG は、サイトの Cookie を持たないユーザーにのみ表示されます。
レスポンシブウェブデザインでページをビルドします。または、パソコン用ページとモバイルページを別々の URL で配信するか、supported-media meta タグを使用して、レスポンシブデザインでないことを示すアノテーションをページに付けます。たとえば、ページの <head> 要素に次のタグを追加します。
```
<meta name=supported-media content="only screen and (max-width: 640px)">
```

SXG のモニタリングとデバッグを行う

SXG をデバッグするために使用できるツールの一覧については、web.dev の SXG ツールに関するガイドをご覧ください。

Googlebot が SXG を解析できない場合は、Accept ヘッダーに application/signed-exchange;v=b3 が含まれていない URL を再クロールして、text/html のバリアントを取得することもあります。SXG のインデックス登録でエラーが発生した場合、Google 検索は SXG を含まない元の URL にリンクします。

AMP ページについては、Search Console の AMP ステータスレポートを使用して、SXG エラーをモニタリングします。

Google SXG のキャッシュをデバッグする

SXG がキャッシュ要件を満たしているかどうかを判別するには、Chrome 拡張機能の SXG Validator を使用します。

または、Google SXG キャッシュに直接クエリを実行することもできます。たとえば、SXG URL が https://signed-exchange-testing.dev/sxgs/valid.html の場合は、対応するキャッシュ URL を次のように作成します。

https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid.html

サブドメインと URL パスのサフィックスを計算するアルゴリズムは AMP Cache の場合と同じですが、インフィックス文字列 /doc/-/ は異なります。

レスポンスが SXG の場合は、配信元サーバーからのレスポンスが Google SXG のキャッシュ要件を満たしていることを意味します。それ以外の場合は、理由を示す HTTP ヘッダーが含まれます。

Warning ヘッダーが存在する場合、エラーのために SXG がキャッシュ要件を満たせなかったことを意味します。
Location ヘッダーが存在する場合、キャッシュにまだフェッチされていないことを意味します。これは SXG のエラーではありません。

レスポンスに関係なく、キャッシュに保存されている URL のコピーを更新するために、元の URL に対するリクエストがキューに追加されます。このリクエストの実行のタイミングと有無については、サイトの Googlebot のクロール頻度など、いくつかの要因によって決定されます。

SXG のキャッシュは、SXG 署名の expires 値、または SXG レスポンスの符号なしヘッダーの有効期間を超えて保存されることはありません。

AMP ページについては、URL 検査ツールを使用してキャッシュエラーをデバッグできます。