部 II 章 5

SEO

公開日：2026/06/09

検索フィールドの下にさまざまなウェブページがあり、Web Almanacのキャラクターがページに光を当てながら各種チェックを行っているヒーロー画像。

Amaka Chulwuma、 Chris Green と Sophie Brannon によって書かれた。

Jamie Indigo によってレビュ。

Augustin Delport と Chris Green による分析。

Michael Lewittes、 Montserrat Cano と Sharon McClintic 編集。

Sakae Kotaro によって翻訳された。

はじめに

検索エンジン最適化（SEO）は、オンラインで情報がどのように発見・理解されるかにおいて引き続き中心的な役割を担っています。SEOはウェブサイトが効果的にクロールされ、インデックスされ、検索結果に表示されるかどうかを決定する技術的・構造的・コンテンツ的な施策全般を包含します。

強固なSEOの基盤は、従来の検索エンジンでの視認性を支えるだけでなく、AIシステムがウェブコンテンツを新しい方法で解釈・要約し始めるにつれ、その重要性はますます高まっています。

2025年版Web AlmanacのSEOチャプターは、HTTP Archiveのクロール、Lighthouseレポート、Chrome User Experience（CrUX）レポート、およびカスタム指標からデータとインサイトを収集しています。ウェブの技術的な状態がどのように進化しているかを記録し、今日のオーガニック視認性に最も影響を与える要因を特定することが目標です。

多くのSEO指標がウェブ全体で安定している一方、それを取り巻く状況は急速に変化しています。AIクローラーの台頭、llms.txt の登場、機械可読性への関心の高まりは、最適化がもはやボットに 見つけてもらう だけでなく、ボットに 理解してもらう ことについてであることを示唆しています。オンライン検索のこうした変化するコンテキストは、今後の最適化にどのような影響を与えるのでしょうか。また、最新のデータポイントはすでにAIのSEOへの影響をどのように反映しているのでしょうか？

クロール可能性とインデックス可能性

ウェブコンテンツが検索結果で視認されるためには、まず検索エンジンのクローラーにクロールされ、インデックスされる必要があります。クロール可能性はボットがページを見つけてアクセスできるかどうかを決定し、インデックス可能性はそのページが検索結果に表示される資格があるかどうかを定義します。この2つの概念が合わさって、検索の視認性の基本要素を形成します。ボットに最初に発見・理解されなければ、ページはランク付けされたりユーザーに提供されたりすることができません。同様に、サイトがインデックス可能でなければ、コンテンツはAIプラットフォームで引用されません。

Googleのドキュメントは、クロールルールの遵守が robots.txt ファイルの存在だけでなく、そのファイルが正しく構成されているかどうかにも依存することを明確にしています。検索エンジンはまた、ディレクティブを効率的に解析し、一貫して解釈できるよう、実際の制限と標準化されたキャッシュ動作を適用しています。

同時に、Cloudflareが説明するように、robots.txt は常に遵守されるコマンドというよりも、行動規範として機能します。評判の良いボットはこれらのシグナルを尊重しますが、他のボットはまったく無視する場合もあります。この協調と予測不可能性の混在が現代のクロール環境を定義し、サイトが実際にクローラーアクセスをどのように管理しているかを検討する舞台を設定しています。

`robots.txt`

クローラーのためのウェブの事実上の「案内所」として機能する robots.txt ファイルは、ボットがサイトのどの部分が公開されているか、または制限されているかを確認する場所です。3年前にIETFがRobots Exclusion Protocol（RFC 9309）を標準化して以来、その構文、キャッシュ動作、エラー処理が明確に定義され、クローラーがアクセスルールを解釈するための安定したフレームワークが提供されています。

そのフレームワークを改良する取り組みは継続中です。2024年後半、IETFはREPextというワーキングドラフトを導入しました。これはRFC 9309を基に、レスポンスヘッダーとHTML meta タグを通じたページレベルのクロール制御を探求するもので、将来の実装をより細かく柔軟にする可能性があります。

しかし現時点では、robots.txt ファイルはクロール管理の基盤であり続けています。ほとんどのウェブサイトは有効なファイルを提供しており、省略しているのはごく少数です。省略しているサイトの場合、サイト所有者は複雑なボット固有のルールよりも、シンプルで普遍的なディレクティブを好む傾向があります。続くセクションでは、これらの傾向が2025年のデータにどのように現れているかを検討します。

`robots.txt` ステータスコード

robots.txt のステータスコード。 — 図5.1. `robots.txt` のステータスコード。

2025年には、robots.txt ファイルへのリクエストの85%が有効な200ステータスコードを返しており、2024年の84%から増加しています。この若干の上昇は、2022年の標準化の波及効果と、有効な robots.txt ファイルを提供するCMSのデフォルト設定の普及が続いていることを示唆しています。ただし重要なのは、200レスポンスはファイルが存在することを確認するだけで、そのディレクティブが正しいまたはサイトにとって有益であることを保証するものではありません。

有効な（200）robots.txt ステータスコードに関しては、モバイルとデスクトップの差はほぼ消失しており、現在モバイルはデスクトップよりわずか0.06%リードしています。これは業界が独立した「mドット」サイトから統一された設定のレスポンシブデザインへ移行していることを反映しています。

robots.txt ファイルに対する404エラーの割合は2024年の14%から13%に低下しました。見つからないファイルの減少は、クロール無制限をデフォルトとするのではなく、より多くのサイトが明示的に robots.txt ファイルを提供していることを意味します。

タイムアウトは約1.0%、403レスポンスは約0.5%、5xxは約0.1%です。まれではありますが、robots.txt ファイルへの5xxレスポンスは、キャッシュされたファイルまたは後続の成功したフェッチが利用可能になるまで、検索エンジンがサイトを一時的にブロック済みとして扱う原因になりえます。

`robots.txt` ファイルサイズ

robots.txt のサイズ。 — 図5.2. `robots.txt` のサイズ。

ほぼすべての robots.txt ファイルはサイズ制限（Googleは500KBの解析カットオフを強制）を大幅に下回っており、空のファイルを提供しないなどの標準に準拠しています。

ごく少数のサイトが完全に空の robots.txt ファイルを提供しており、現在デスクトップで1.8%、モバイルで1.7%と2024年からわずかに増加しています。ほとんどの主要クローラーは空のファイルを許可的に扱いますが、標準（RFC 9309）はこの動作を明示的に定義していないため、あまり知られていないボットによる一貫性のない処理の余地が残ります。制限が意図されていない場合は、有効なファイルまたは404を返すのがより安全なアプローチです。

2025年には、ファイルの98%が100KB未満であり、2024年からわずかに低下しています。年間のこの小さな変化は、安定した成熟した実装パターンを示しています。

100〜200KBのファイルは robots.txt の0.3%、200〜300KBはわずか0.1%を占め、前年からほぼ変化がありません。Googleが強制する500KBの解析カットオフを超えたサイトはわずか0.1%で、クローラー制限への強い準拠を確認しており、過大サイズの robots.txt ファイルはエッジケースであることを裏付けています。

robots.txt ファイルサイズがクロール可能性の障壁になることはほとんどありません。より差し迫った問題は、空または設定ミスのファイルで、クローラーがサイトルールを解釈する際に不確実性をもたらします。

`robots.txt` ユーザーエージェントの使用状況

robots.txt のユーザーエージェント。 — 図5.3. `robots.txt` のユーザーエージェント。

分析のため、クロールで識別されたすべてのユーザーエージェント名を小文字化し、サイト間の差異を無視しました。一部のクローラーはドキュメントで推奨する大文字化を提供していますが、robots.txt ファイルを処理する際には理論上、大文字と小文字を区別しないマッチングを使用する必要があります。

キャッチオールユーザーエージェント * は、今日の robots.txt ファイルで見られるクローラーディレクティブとして最も一般的なアプローチです。2025年には77%のファイルに表示されており、2024年から、また2022年の70%台半ばから若干増加しています。この着実な上昇は、ほとんどのサイト所有者が複雑なボット固有の指示を維持するよりも、広範な普遍的ルールを実装することを好むことを示しています。

robots.txt ファイルで特定のユーザーエージェントが言及されている場合、Googleの広告クローラー（adsbot-google）と ahrefsbots が昨年と同様にリードしています。

robots.txt ディレクティブにおける adsbot-google のターゲティングは2025年にデスクトップで9.8%、モバイルで9.5%に上昇しており、2024年のデスクトップ9.1%、モバイル8.9%と比較しています。

ahrefsbot も主要な名前付きクローラーであり続け、デスクトップの9.3%、モバイルの9.5%の robots.txt ファイルで指定されています。ahrefssiteaudit（デスクトップ4.6%/モバイル4.3%）と合わせると、大量のクロール活動を生み出しうるSEOツールのアクセスを制御することの継続的な重要性を反映しています。

今年注目すべき量で表示されたその他の名前付きクローラーには次のものがあります：

mj12bot（Majestic）: デスクトップ7.3% / モバイル7.3%
googlebot: デスクトップ6.2% / モバイル6.7%
nutch: デスクトップ5.0% / モバイル4.8%

`bingbot` は `robots.txt` でほとんど名指しされない

bingbot は robots.txt ファイルの名前付きユーザーエージェントの中で22位にランクし、robots.txt の3%未満に表示されます。ボットが robots.txt ファイルに表示される場合、ウェブサイト管理者がそのクローラーを許可、制限、またはクロール率の設定など、その動作を明示的に制御するほど関心を持っていることを意味します。低い表示率は無視されていることを示唆しています。MicrosoftのAIへの大規模な投資とBingへのChatGPTの統合にもかかわらず、クローラー自体は robots.txt ファイルでより目立つ存在にはなっていません。AI機能強化にもかかわらず、Bingのウェブフットプリントとサイトオペレーターにとっての重要性はほぼ変わらないままで、robots.txt ファイルで名指しされる gptbot のようなAI特化クローラーの急速な台頭との静かな対照をなしています（詳細は後述）。

名前付きユーザーエージェント使用の緩やかな増加

robots.txt のSEOツール関連ユーザーエージェント。 — 図5.4. `robots.txt` のSEOツール関連ユーザーエージェント。

全体として、2024年と比較して、2025年の robots.txt ファイルでは、普遍的なワイルドカード * のみに頼るのではなく、名前付きクローラーのディレクティブを含む割合がわずかに大きくなっています。たとえば、MJ12Botは昨年のモバイル6.6%から2025年のモバイル7.3%に上昇し、Googlebotはモバイル6.4%から6.7%に、Nutchはモバイル4.3%から4.81%に増加しました。これらの控えめな伸びは、普遍的な制御のシンプルさから離れることなく、重要な箇所でカスタマイズされたクロールルールを設定するサイト所有者が増えているという、段階的な改善を示しています。

特定のボットへの言及が増加する中での * の継続的な優位性は、実用的なバランスを示唆しています。普遍的なディレクティブが標準のままですが、ビジネス上の懸念がある箇所には対象を絞ったルールが追加されます。すべてのクローラーが * を一貫して解釈するわけではありません。GoogleのAdsBotはそれを無視し、Applebotは * を適用する前にGooglebotルールにフォールバックするため、特定のケースでは明示的なターゲティングが必要です。

`robots.txt` でAIクローラーを名指し

AIクローラーの台頭により、robots.txt は従来の検索最適化ツールからコンテンツ権限を管理するための広範なメカニズムへと変貌しました。2025年には、AI関連ボットをターゲットにしたディレクティブが2024年の水準から大幅に増加しました。

robots.txt のAI関連ユーザーエージェント。 — 図5.5. `robots.txt` のAI関連ユーザーエージェント。

前年比の比較は、採用の加速を明らかにしています：

gptbot: デスクトップ4.5%、モバイル4.2%と、2024年のデスクトップ2.9%、モバイル2.7%から約55%増加。
ccbot: デスクトップ3.5%、モバイル3.2%と、2024年のデスクトップ2.7%、モバイル2.4%から増加。
petalbot: 今年デスクトップ4.0%、モバイル4.4%；2024年には個別に追跡されていなかった。
claudebot: デスクトップ3.6%、モバイル3.4%と、2024年のデスクトップ1.9%、モバイル1.6%からほぼ2倍。

注目すべきは、2024年のデータには anthropic-ai（昨年デスクトップ2.0%、モバイル1.7%）や chatgpt-user（昨年デスクトップ2.0%、モバイル1.7%）などの広範なカテゴリーが含まれていたのに対し、2025年のデータはより特定のボットターゲティングを示しています。

今年AIクローラー分野に参入したその他のボットには、amazonbot（デスクトップ3.3%、モバイル3.0%）、google-extended（デスクトップ3.4%、モバイル3.0%）、perplexitybot（デスクトップ2.8%、モバイル2.7%）、chatgpt-user（デスクトップ2.8%、モバイル2.5%）、facebookbot（デスクトップ2.9%、モバイル2.5%）、meta-externalagent（デスクトップ2.8%、モバイル2.5%）があります。

ユーザーエージェントのターゲティング全体は年々緩やかに成長しているのに対し、AIクローラーの採用ははるかに急激です。2024年以降の gptbot のほぼ倍増、petalbot、claudebot などの測定可能な採用は、2023年のわずかな存在から2025年には数パーセントの採用率に達した、名前付きユーザーエージェントに対する robots.txt ディレクティブの最近の記憶の中で最も急速な拡張の一つを表しています。

この変化はサイト所有者に新たな複雑さをもたらしています。「このページは検索にインデックスされるべきか？」と問うだけでなく、「このコンテンツはAIモデルのトレーニングに使用されるべきか？」とも問わなければなりません。これらは異なるビジネス的・倫理的含意を持つ別々の考慮事項です。

robots.txt は、検索での視認性とデータの大規模収集からの保護のバランスを取る二重目的の制御ポイントになっています。AIモデルとクローラーが増殖するにつれ、このトレンドは激化する可能性があります。

`llms.txt`

llms.txt ファイルは、「推論時にLLMがウェブサイトを使用するのに役立つ情報を提供する」新しい標準として提案されています（llmstxt.orgより）。このテキストファイルはMarkdown形式のウェブサイトコンテンツの高度に簡略化されたバージョンを含み、LLMが生成レスポンスで取り込んで使用しやすくすることを目指しています。

この標準はまだ広く採用されておらず、SEO業界全体で議論の的となっています。Googleは llms.txt を使用していないとしばしば述べており、現在Googleのサービスは使用していません。しかし、Anthropicはllms.txt のリードを取っており、このフォーマットがモデル推論中のコンテンツ利用を管理・最適化するための信頼できるメカニズムへと発展するかもしれないという楽観論が高まっています。

`llms.txt` の採用率

llms.txt の使用がSEOやAI最適化に有効なアプローチであることが証明されるかどうかにかかわらず、このような新しいファイル形式と提案された標準の導入は、今後のウェブサイトの構築と最適化に影響を与える可能性があります。

2025年Almanacの一環として、ウェブ全体の llms.txt 採用レベルを評価するモニターを導入しました。

採用率は2%と比較的低いですが、llms.txt 形式がどれほど新しいか、および分析されたすべてのモバイルサイトで合計324,184の有効なファイルが確認されたことを考えると、これらの数値は依然として注目に値します。

これらの llms.txt ファイルの内容を掘り下げると、これまでのこの標準の採用について、そして将来この動きを促すものについていくつかの手がかりが見えます。

llms.txt ファイルの39.6%はAll in One SEOに関連
llms.txt ファイルの3.6%はYoast SEOに関連

これはこれらのCMS拡張が生成したファイルに（デフォルトで）残すコメントから得られましたが、llms.txt ファイルを持つウェブサイト所有者の相当数がCMS/アドオン拡張によって生成されていることを示しています。したがって、これが常に意識的な行為または llms.txt 標準の支持なのか、意図せぬ組み込みなのかは確認できません。

2025年1月以来、この新興標準への関心は高まり続けており、1〜2社の主要なAI企業の認知にかかっています。それでも、2026年の数字を見るのは興味深いでしょう。

ロボットディレクティブ

ロボットディレクティブは、特定のページがどのようにインデックスされ検索結果に表示されるかに対するページレベルの制御を提供します。robots.txt ファイルと同様の機能を持ちますが、両者は異なる目的を持ちます：

ロボット ディレクティブ は インデックスとサービング に影響する
一方 robots.txt は クロール を制御する

ディレクティブが適用されるためには、クローラーがページにアクセスできる必要があります。ページが robots.txt によってブロックされている場合、そのディレクティブが見られたり従われたりすることはないかもしれません。

ロボットディレクティブの実装

ロボットディレクティブを実装する主な方法は2つあります：

<meta name=robots> タグを使用する（ウェブページの <head> セクション内に配置）
X-Robots-Tag HTTPヘッダーを使用する

どちらの方法を選ぶかは、具体的なユースケースと利用可能な手段や方法によって異なります。

meta ロボットタグは主にHTMLページ向けで、ほとんどの主要なCMSでネイティブまたはアドオンを通じて広くサポートされており、その他の一般的でよくサポートされているフレームワークでも同様です。

X-Robots-Tags はPDFや文書などの他のHTML以外のファイルタイプにも実装できるという大きな利点があります。ただし、CMSユーザーにとっては設定が簡単でないことが多く、常に選択肢として使えるわけではありません。

meta ロボットはロボットディレクティブを実装するための最も広く使われている方法で、デスクトップページの47.0%、モバイルページの47.9%に表示されており、X-Robotsはデスクトップ0.6%、モバイル0.7%で大差で2番手につけています。

meta ロボットを実装しているページ数は昨年記録されたデスクトップ45.5%、モバイル46.2%から増加しており、前年比（YoY）の成長を示しています。対照的に、X-Robots-Tag の実装はYoYでほぼ変わっていません。インナーページはロボットディレクティブを持つ可能性が50%で、ホームページの46%と比較しています。

一部のページ（デスクトップとモバイルの両方で0.4%）では meta ロボットと X-Robot-Tag の両方が同時に実装されています。この0.4%という数字は昨年から安定していますが、2つの実装方法間で矛盾するシグナルが生成される可能性が高まるため、広く推奨されている慣行ではありません。

ロボットディレクティブのルール

実装方法はロボットディレクティブの一側面に過ぎません。ディレクティブルールがページやドキュメントをどのように処理するかを決定します。

ルールはコンマ区切りの値として meta ロボットまたは X-Robots-Tag のいずれかに追加できます。

ディレクティブルールの調査では、レンダリングされたHTMLに依存しました。

最もよく使われる2つのルール follow と index は、noindex や nofollow などの反対の目的を持つ他のルールがない場合のデフォルト値とみなされ（Googleには無視されます）。

これらを含めることは、ロボットがページをインデックスし、そこからリンクをたどるべきであることを意味します。モバイルでの follow と index の使用率はそれぞれ60.5%と59.3%であり、これらの2つのタグが一緒に見られ、一般的に補完的であることを意味しています。

技術的に不要な meta ロボットルールの組み合わせがこれほど多い可能性のある原因のひとつはYoast SEOで、index,follow をデフォルトで適用します。Yoastはホームページでのをてのセオツール/プラグインの使用を見ると約16%の採用率（デスクトップとモバイル）を持ち、識別されたすべてのSEOツールのうち、70%近くの時間で使用されています。

nofollow と noindex は次に最もよく使われる meta ロボットルールで、使用頻度はかなり低く、デスクトップページの2.8%、モバイルページの2.4%に表示されます。

meta ロボットディレクティブのもう一つの要素は name 属性で、これらのディレクティブが特定のロボット/クローラーのユーザーエージェントを対象にしているかどうかを指定できます。たとえば、一部のクローラーが特定のルールを必要とし、他のクローラーがそうでない場合に動作をカスタマイズできます。

この属性内で最もよく名前が挙がるクローラーは2024年と一致しており：bingbot、msnbot、googlebot、google-news がデフォルトの robots とともに最も頻繁に表示されます。

msnbot は bingbot に置き換えられたレガシークローラーです。ロボットディレクティブへの継続的な存在は、古いクローラー名の更新や削除の遅れを示唆しています。この遅れの追加の証拠は、max_image_preview、max_snippet、max_video_preview などの新しいロボットルールが googlebot と bingbot には一般的に適用されているが、msnbot には適用されていないという事実に見られます。

`indexifembedded` タグ

現在よく確立されたMetaロボットルールである indexifembedded は、iframeコンテンツが埋め込まれているページの一部として扱われるようにしたい場合を指定できる非常に特定のタグです。これを機能させるには noindex とペアにする必要があり、現在Googleのみがサポートするルールです。

iframe コンテンツでの indexifembedded の使用 — 図5.11. `iframe` コンテンツでの `indexifembedded` の使用

iframeコンテンツ内では、indexifembedded ルールはほぼ90%の時間（デスクトップ88.9%、モバイル87.7%）で見つかります。興味深いのは、2022年から2024年にかけて使用率が上昇した後、2025年には99.9%の使用率から低下したことです。

無効な `<head>` 要素

検索エンジンのクローラーはコンテンツを解析する際にHTML標準に従います。発生しうる問題の一つは、ページの <head> 内に無効なHTML要素が見つかる場合です。これにより <head> が暗黙的に早期終了したと見なされ、残りのすべての <head> 要素がページの <body> 内に含まれるようになります。

SEOへの悪影響が最も大きいのは、title、canonical タグ、hreflang、Metaロボットディレクティブなどの重要なメタデータが無効な head 要素の下に配置されている場合（body 内に含まれることでそれらが機能しなくなります）です。

<head> に無効なHTMLがあるページ — 図5.12. `<head>` に無効なHTMLがあるページ

今年見つかった無効なhead要素は2024年のデータで見られた下降傾向を継続しており、前年比でページの <head> セクションの無効な要素が再び少なくなっています。

2025年には、デスクトップページで10.1%の無効な <head> 要素、モバイルページで10.3%の無効な要素が見られます。2024年のデータ（デスクトップ10.6%、モバイル10.9%）と比較すると、デスクトップで4.7%、モバイルで5.2%の低下を表しています。

「無効な」<head> 要素の定義には、W3C標準に基づいていないページの <head> に含まれるものすべてが含まれます。Google検索のドキュメントによると、<head> で使用できる有効な要素は8つあります。これらは：

<title>
<meta>
<link>
<script>
<style>
<base>
<noscript>
<template>

2025年に最も多く見られる無効な要素は2024年のデータと同じです：<img>、<div>、<a> タグ。

無効な <img> タグについては、2024年は2022年から急増が見られましたが、2025年の結果はより安定しています（今年はデスクトップ27.2%、モバイル23%に対し、昨年はデスクトップ29%、モバイル22%）。具体的には、デスクトップの使用率は低下し、モバイルは小幅に増加しています。

<div> タグはデスクトップ11.5%、モバイル10.6%で目立った変化はありません。<a> タグも同様に昨年からほとんど変化がなく、デスクトップ5.2%、モバイル4.9%です。

正規化

canonical タグは、重複またはほぼ重複するページが存在する場合に、どのバージョンが主要なページであるかを検索エンジンに伝えます。これらがなければ、クローラーはランキングシグナルを分散させ、クロールバジェットを無駄にし、検索結果に誤ったURLを表示する可能性があります。これらがあれば、すべての権限とインデックス優先度が単一の決定的なページに集中します。

canonical タグはディレクティブ（meta ロボットのような）ではなく、正しく実装することでランキング問題を最小化する支援シグナルを提供する「強いヒント」です。

canonical タグの使用がまた増加しており、昨年のモバイルとデスクトップの両方65%から、2025年にはデスクトップ68%、モバイル67%に増加しました。

canonical の使用状況 — 図5.14. `canonical` の使用状況

ページはそのcanonical URLが異なる場所を指す場合に「正規化されている」と言います。正規化されたページも今年増加しており、2024年のデスクトップ6%、モバイル8%から2025年にはデスクトップ7%、モバイル9%に増加しました。

`canonical` の実装

Canonical タグはMetaロボットと同様に、HTTPレスポンスの一部またはページの head 内に実装できます。各実装方法の背後にある動機は、プラットフォームや要件によって異なり、それぞれにメリットとデメリットがあります。

ページの head 内の Canonical（rel="canonical"）は最もよく使用されており（ほとんどのCMSで標準化されているため）、ページのcanonical URLを示します。

HTTP canonicalも同じことができ、PDFなどの他のファイルタイプにも使用できるという追加の利点があります。ただし、CMSユーザーには広く実装されておらず、より高度な技術的理解が必要です。

HTTPのcanonical実装は rel="canonical" タグと比較してまだ非常に低く、2025年にはデスクトップ0.6%、モバイル0.5%となっています。このデータは2024年の数値（デスクトップ0.7%、モバイル0.6%）からわずかな低下を表しています。

生のcanonicalタグとレンダリングされたcanonicalタグ

ページの head 内に配置される rel=canonical タグは、サイトの構築方法に応じて、生のHTML、レンダリングされたHTML、またはその両方に表示されます。ただし、最も信頼性の高いアプローチは、レンダリング後も変更されないことを保証するために、生のHTMLに canonical タグを含めることです。

JavaScriptで駆動されるページの場合、canonicalタグはページのレンダリングが完了した後にブラウザで挿入または更新されることがよくあります。生/レンダリングのcanonicalsの結果から、生のHTMLにcanonicalが欠如しているがレンダリングされたDOMに存在するケースは約2%のみです。これは、ほとんどのサイトが生のHTMLにcanonicalを含めることを選択し、ページレンダリング時に削除されないことを示しています。

2025年のデータでは、生のHTMLのcanonicalsの数値はデスクトップ64.4%、モバイル64.27%と2024年のデータと同等です。しかし、レンダリングされたcanonicalは2025年にデスクトップ66%、モバイル66.1%に増加しており、昨年のデスクトップ64%、モバイル65%と比較しています。

canonicalの矛盾

JavaScriptを使用して head 内でcanonicalタグをレンダリングすることは機能しますが、エラーの余地が増えるため、静的なサーバーサイドのcanonicalタグが一般的により安全なオプションです。canonicalタグが一致しない場合、その使用が損なわれ、予期しない結果を引き起こす可能性があります。canonicalの不一致は2024年の数値から0.1%低下し、デスクトップとモバイルの両方で0.8%から今年0.7%に減少しました。

canonical の不整合 — 図5.16. `canonical` の不整合

ページエクスペリエンス

ページエクスペリエンスは、コンテンツの内容やランキングの高さを超えて、ユーザーがウェブページを操作する際に実際にどのように感じるかを捉えます。2020年にGoogleのランキングシステムの一部として導入され、これらのシグナルはページ速度、モバイルのレスポンシブ性、視覚的安定性、セキュリティなどの使いやすさの要因を測定します。Googleはその後、独立したページエクスペリエンスシステムをコアランキングフレームワークに統合しましたが、基礎となる指標はSEOとUXの両方のベストプラクティスを引き続き導いています。

2025年、データは技術的に成熟しているが、エクスペリエンスの品質においてまだ不均一なウェブを反映しています。HTTPSの採用はほぼ普遍的になり、モバイルフレンドリーさは差別化要因というよりも期待事項となり、Core Web Vitalsは実世界のパフォーマンスを定量化するための業界標準となっています。それでも、これらの進歩にもかかわらず、レンダリングの遅さからインタラクティビティの不一致まで、摩擦ポイントは依然として存在し、ユーザーエクスペリエンスはコンプライアンスと同様に一貫性についてであることをサイト所有者に思い出させています。

HTTPS

HTTPSはユーザーとウェブサイト間のデータ交換を保護するために導入され、情報を傍受や改ざんから守ります。後にGoogleのアルゴリズムで正式なランキングシグナルとなりました。

2025年、HTTPSの使用率はデスクトップページの91.7%、モバイルページの91.5%に達しており、2024年の約89%からわずかに増加しています。HTTPSがウェブのほとんどのデフォルトとなったため、成長は鈍化しています。残る小さなギャップは、まだ移行していない古いまたはメンテナンスが少ないサイトを表しています。その結果、HTTPSはユーザーと検索エンジンの両方にとって、差別化要因というよりもベースラインの期待として機能するようになっています。

それでも、完全な普遍的な暗号化は簡単ではありません。Googleの透明性レポートは継続的な障害を記録しています。一部の国や組織はHTTPSトラフィックをブロックまたは低下させ、技術的な能力が限られている組織は優先度を下げる場合があります。Googleの製品でさえ課題に直面しており、ユーザー所有ドメインの証明書管理（例：Blogger）は、それらのドメインがネイティブにHTTPSをサポートしていない場合に複雑になる可能性があります。これらの制約は、なぜ少数のサイトがまだ遅れをとっているかを説明するのに役立ちます。

モバイルフレンドリー

Googleは2023年にモバイルファーストインデックスへの移行を完了しました。つまり、ウェブサイトのモバイルバージョンが検索ランキングを決定するようになりました。以下のデータは、これに応じてサイトがモバイルフレンドリーなデザインプラクティスをどれだけ採用しているかを調べています。

`viewport` メタタグ

viewport メタタグは、ページがさまざまな画面サイズにわたってどのようにスケールおよび表示されるかを定義し、レスポンシブウェブデザインの重要な要素です。モバイルブラウジングの台頭とともに導入され、ユーザーが水平にズームやスクロールをすることなく、コンテンツがさまざまなデバイスにスムーズに適応することを保証します。

meta viewport の使用状況 — 図5.18. `meta viewport` の使用状況

viewport メタタグの使用はほぼ普遍的で、デスクトップページの93.1%、モバイルページの95.2%に表示されています。これは、レスポンシブデザインの原則が現代のウェブサイトで広く使用されていることを示しています。デスクトップとモバイルの差が小さいことは、開発者が別々のモバイルとデスクトップのコードベースを維持するのではなく、すべてのデバイスで一貫したレスポンシブデザインアプローチを使用していることを意味し、モバイルフレンドリーなデザインプラクティスの成熟を示しています。

`Vary` ヘッダーの使用状況

かつて動的配信の標準ツールだった Vary: User-Agent header は今やほぼ絶滅状態です。2025年には、ページの約1%しか含んでいませんが、ほぼすべてのサイトが統一されたレンダリングを選択しています。この変化は、viewport メタタグの普及（95%超）とGoogleのモバイルファーストインデックスへの移行と一致しており、サイトの別々のモバイルとデスクトップバージョンを維持する必要性を減少させました。ウェブは主にレスポンシブなシングルバージョンデザインに集約されています。

読みやすいフォントサイズ

読みやすさはモバイルエクスペリエンスの最も基本的な側面の一つです。ユーザーはズームや目を細めることなく快適にコンテンツを読めるべきで、アクセシビリティ標準もそれを強化しています。Web Content Accessibility Guidelines（WCAG）によると、ボディテキストは少なくとも16px（1rem）で、レイアウトや機能を損なわずに200%までスケールできる必要があります。

Lighthouseの読みやすいフォントサイズ監査は同様のベンチマークを使用し、可視テキストの60%未満が 12px を超えるページにフラグを立てます。2025年には、モバイルページの92%がこのテストを通過しており、2024年のパフォーマンスを反映し、ほとんどのサイトがホームページとインナーページの両方で基本的な読みやすさ標準を満たしていることを示しています。

Core Web Vitals

Core Web Vitalsは、読み込み（Largest Contentful Paint、LCP）、インタラクティビティ（現在はInteraction to Next Paint、INPで測定）、視覚的安定性（Cumulative Layout Shift、CLS）に焦点を当て、実際のユーザーがページをどのように体験するかを測定します。

図5.22. 良好なCore Web Vitalsエクスペリエンスの割合（モバイル）

2025年、Core Web Vitals全体のパフォーマンスは数年間の着実な前年比改善を経てほぼ安定しています。デスクトップはCore Web Vitalsパフォーマンスで引き続きリードし、約60%のページが「良好」な総合Core Web Vitalsエクスペリエンスを提供しており、モバイルの50%強と比較しています。この差は、より高速なハードウェア、より強力な接続、レイアウト制約が少ないといったデスクトップの固有の優位性を反映しています。

両プラットフォームにわたって、CLSが最も強い指標で、約75%のページが合格しています。しかし、LCPはモバイルで55〜60%近くにとどまり続けており、読み込み速度が今日のウェブサイトにとって最も持続的なCore Web Vitalsの課題であることを示しています。研究が示すように、これはユーザー満足度に影響し、特にAI駆動の環境でオンラインコンバージョンにも影響を与える可能性があります。

2024年3月、特にモバイルで見られる目立つ低下は、Googleの2024年3月のFirst Input Delay（FID）からInteraction to Next Paint（INP）への置き換えへの移行を反映しています。INPは展開前にパフォーマンスツールに表示され始め、FIDがしばしば見落としていたレスポンシブネスの問題を露呈する、より厳しいしきい値を導入しました。この段階的な変化は「良好な」ユーザーエクスペリエンスと見なされるバーを引き上げ、変更が発効したときの変動を説明しています。

画像の `loading` プロパティの使用状況

loading 属性はブラウザに画像をいつ取得してレンダリングするかを伝えます。速度とリソース使用のバランスをとるのに役立つ組み込みのパフォーマンスヒントです。動作を決定する2つの主な値があります：

lazy: 画像が画面に表示されるまで読み込みを遅延させ、初期ページの重さを減らし、体感パフォーマンスを向上させます。
eager: ページが読み込まれるとすぐに画像を取得し、ヒーローバナーやロゴなどのアバブザフォールドビジュアルの即時表示を確保します。

この属性により、開発者は異なるコンテキストで読み込み動作を微調整し、重要なビジュアルを優先しながら重要度の低いものを後回しにして読み込み時間と帯域幅効率を向上させることができます。

画像の loading プロパティ — 図5.23. 画像の `loading` プロパティ

2025年、約68%の画像（デスクトップとモバイルの両方）に画像読み込み属性が設定されておらず、読み込み動作はブラウザのデフォルトに任されています。一方、約26%が遅延読み込みを使用し、わずか4〜5%のみが明示的にeager読み込みを使用しています。

ホームページの画像 loading プロパティ — 図5.24. ホームページの画像 `loading` プロパティ

インナーページの画像 loading プロパティ — 図5.25. インナーページの画像 `loading` プロパティ

このパターンはページタイプ全体で一貫しています：

ホームページ: デスクトップ27.3%、モバイル27.7%が遅延読み込み
インナーページ: デスクトップ25.6%、モバイル25.3%が遅延読み込み

画像読み込み属性の欠如が多いことは、遅延読み込みの採用がパフォーマンス重視のサイトに集中している一方、多くの他のサイト（おそらくレガシーまたはCMS駆動のサイト）が明示的な読み込み戦略を実装していないことを示唆しています。loading="lazy" のほぼ普遍的なブラウザサポートとレスポンシブデザインを考慮すると、大多数の画像が体感パフォーマンスを向上させ帯域幅使用を削減するために明示的な遅延読み込みの恩恵を受けられます。

iframeの `lazy` 読み込みと `eager` 読み込み

iframe の画像読み込みプロパティ — 図5.26. `iframe` の画像読み込みプロパティ

iframeに loading="lazy" を追加するだけで、ビューポートの近くまで読み込みが遅延され、YouTube埋め込みで約500KB、Facebookウィジェットで約200KBを節約できます。しかし、2025年にiframeの読み込み属性は依然として著しく十分に活用されておらず、デスクトップページの91.5%、モバイルページの91.2%がiframe読み込みプロパティを宣言していません。これは2024年のデスクトップ92.8%、モバイル92.6%からわずかに低下しています。

明示的なiframe遅延読み込み属性は約13%のページに表示されており（3.5%が単独、9.3%が欠如宣言と混在）、しばしば宣言のないiframeと一緒に一貫性なく適用されています。前年と同様に、このパターンは出版社が制御を制限されている広告、動画、分析ダッシュボードなどの埋め込みサードパーティ要素の優位性を反映していると思われます。明示的な eager 宣言は事実上存在しないままで（デスクトップとモバイルの両方で0.2%）、単にブラウザのデフォルトを再述するだけです。大幅なパフォーマンス向上の機会があるにもかかわらず、iframeの遅延読み込みの採用は画像の遅延読み込みよりもはるかに遅れています。

この不一致は主に、広告、動画プレーヤー、分析ダッシュボードなどのサードパーティの埋め込みがiframeの使用を支配している方法を反映しています。これらの要素は外部で制御されているため、出版社は読み込み動作を定義したり属性を直接追加したりする能力が限られています。多くの場合、サードパーティのスクリプトは読み込み後に動的にiframeを注入するため、クローラーと監査はiframeが存在していても loading 属性を検出しません。その結果、表面上「欠如している」属性の一部は、真の省略ではなく測定における可視性のギャップを表している可能性があります。

これはまた開発者の優先度付けとも関係しています。チームは通常、制御が難しく増分的な利益が小さいiframe動作に対処する前に、ファーストパーティアセット（画像、スクリプト、Core Web Vitals）のパフォーマンスの最適化に焦点を当てます。

オンページ

ページ構造は現在のAI駆動の環境においても依然として重要です。タイトル、メタディスクリプション、見出しは意味と意図を伝え、メディア属性は明確さとアクセシビリティを強化します。2025年のデータは、これらの要素の使用全体における安定性を示しており、大きな変化ではなく漸進的な調整を反映したわずかなシフトのみです。

メタデータ

title タグとメタディスクリプション — 図5.27. `title` タグとメタディスクリプション

title タグの採用はほぼ普遍的なままで、2025年にはデスクトップページの98.62%、モバイルページの98.54%にわずかに増加しており、2024年のデスクトップ98.0%、モバイル98.2%から上昇しています。この安定性は、検索結果でタイトルが広く書き換えられているにもかかわらず、SEO戦略における要素の永続的な役割を反映しています。出版社はまだ、表示制御に関係なくtitleタグを基本的なものとして見ているようです。

一方、メタディスクリプションは異なる軌跡をたどっています。2022年のページの71%への表示から2024年のデスクトップ66.7%、モバイル66.4%へと低下した後、2025年にはデスクトップ67.7%、モバイル67.2%にわずかに回復しました。採用率は2022年の以前の水準には完全に回復していませんが、今年の上昇はGoogleが書き換えることがあっても、出版社がクリックスルーの最適化とクロスプラットフォームの一貫性のためにメタディスクリプションに価値を見出し続けていることを示唆しています。

`title` 要素の長さ

title タグはユーザーとアルゴリズムの両方にとってページのトピックの最も明確なシグナルの一つですが、その効果は部分的に長さに依存します。短すぎるとコンテキストが不足し、長すぎると検索結果で切り捨てられるリスクがあります。2025年のデータは、出版社が2024年からほとんど変化なく、安定した中間点の周りにクラスタリングし続けていることを示しています。

中央値のtitleタグはデスクトップとモバイルの両方で12単語を含み、昨年から変わっていません。75パーセンタイルでは18単語に増加し、90パーセンタイルではデスクトップで24単語、モバイルで25単語に延びます。

中央値のtitleの長さはデスクトップで77文字、モバイルで79文字で、2024年とほぼ同じです。75パーセンタイルでは116〜117文字に上昇し、90パーセンタイルでは150〜154文字に達します。

これらの数値は、よく引用されるtitleの「安全な範囲」である50〜60文字を大幅に上回っており、表示が切り捨てられても出版社がキーワードカバレッジとコンテキストを優先していることを示唆しています。

2024年から2025年にかけてこのパターンが継続していることは、Googleの書き換えプラクティスを反映している可能性もあります。タイトルはSERPで頻繁に変更されるため、出版社はピクセルパーフェクトな表示制限に合わせて細かく調整する動機が少なくなっています。

メタディスクリプションの長さ

分布パターンは2022年から2024年の急激な成長の後、ほぼ安定しています。今年のデータは以下を示しています：

中央値（50パーセンタイル）: デスクトップとモバイルの両方で40単語、274文字と、2024年から変わりませんが、2022年の中央値19単語、約135文字の2倍以上です。
10パーセンタイル: 4単語、約69〜70文字と、昨年と同じです。
25パーセンタイル: 18〜19単語、166〜168文字。
75パーセンタイル: 51単語、329〜330文字。
90パーセンタイル: 79単語、533〜537文字。

この分布は、出版社が快適な範囲に落ち着いていることを確認しています：内容を提供するのに十分な長さで、一般的には約80単語または約540文字以下に抑えられています。Googleが頻繁にスニペットを書き換えても、適切に構造化されたディスクリプションを維持することで、サイト所有者はコンテンツが他の場所でどのように表示されるかに一定の影響力を持てます。

実際には、スニペットの表示はピクセル幅によって制限されており（デスクトップで約920〜980px、モバイルで680px）、切り捨ては文字幅によって異なります。

このパターンが続けば、適切に構造化されたメタディスクリプションは従来のSERPシグナル以上のものになります：ページがAI駆動の要約や引用のために表示されるかどうかを決定するのに役立ちます。

見出しタグ

適切に構造化された見出しはテキストをフォーマットするだけでなく、ページの論理的な流れをマッピングし、読者とクローラーの両方を主なアイデアに案内します。2025年のデータは、すべての主要タグにわたる安定性を示しており、昨年からわずかなシフトのみです。

<h1>: デスクトップページの71%、モバイルページの70%に存在します。空でない使用はわずかに低く、両方で66%です。
<h2>: 最も広く採用されており、デスクトップページの72%、モバイルの71%で、ほぼすべてが空でありません。
<h3>: 60%のページで使用されており、58%が空でなく、2024年から変わっていません。
<h4>: デスクトップページの37%、モバイルの36%に存在し、35〜36%が意味のあるコンテンツを含んでいます。

見出しタグの採用は明らかに頭打ちになっています。以前の年には <h1> の成長と <h3>/<h4> の低下が見られましたが、2025年は安定したパターンを確認しています。

空でないデータは特に示唆に富んでいます。「存在する」と「空でない」のギャップは今やわずか数パーセントポイントで、2022年（デスクトップの <h1> の約6%が空）の大きなギャップと比較しています。これは、空の見出しが例外ではなく標準となった、よりクリーンでより意味的に構造化されたマークアップを示唆しています。

アクセシビリティとSEOを超えて、この見出し構造の改良はより広いトレンドとも一致しています：出版社がAI駆動プラットフォームのためにオンページの明確さを最適化しています。AIの概要、要約ツール、引用システムがクリーンなセマンティック階層に依存して情報を抽出・帰属させるようになるにつれ、適切に構造化された見出しはページのアイデアがAI出力で正確に表現・クレジットされることを保証する一部となっています。

それでも進歩には限界があります。<h1> はページの70%に表示されていますが、空でないのは66%のみです。この4%のギャップは上限効果を示しており、採用率が100%に達することは考えにくい自然な上限です。シングルページアプリやミニマリストのホームページなど、一部のデザインは意図的に意味のある <h1> をスキップします。これらのケースはエラーではなくデザインの選択を反映しています。

画像

2025年の画像使用データは以前の年との幅広い一貫性を示していますが、サイトの上位層に向けて画像使用が劇的にスケールアップすることも強調しています。

中央値（50パーセンタイル）では、ホームページにはデスクトップで20枚、モバイルで19枚の画像があります。
75パーセンタイルでは、画像数はデスクトップで44枚、モバイルで41枚に増加します。
90パーセンタイルでは、画像の使用はデスクトップで85枚、モバイルで80枚にさらに跳ね上がります。

比較すると、25パーセンタイルはわずか8枚の画像で、ホームページデザインの幅広いバリエーションを示しています。しかし分布全体にわたって、デスクトップとモバイルの数値は密接に一致しており、レスポンシブデザインプラクティスがデバイス間で画像使用を一貫させていることを示唆しています。

`alt` 属性

alt 属性はアクセシビリティの中心であり、検索での画像インデックスもサポートしています。今年は採用に着実な改善が見られ、全体的に欠如している属性が減っていますが、注目すべき空白値のわずかな増加もあります。

中央値では、モバイルページの画像の60%が alt 属性を含んでおり、2024年の58%から増加しています。90パーセンタイルでは採用率が100%に達し、出版社の相当数がすべての画像に一貫してalt テキストを適用していることを示しています。

中央値では、モバイルページの画像の15%が空白の alt 値を持っており、2024年の14%からわずか1ポイント増加しています。75パーセンタイルでは58%が空白で、90パーセンタイルでは90%が空白となり、いずれも昨年より1ポイント高くなっています。増加は小さいですが、すべての採用が意味のある説明に転換されているわけではないという懸念を示しています。

中央値のページは再び alt の欠如が見られず、12〜13%のページが完全に欠如していた2022年からのポジティブなトレンドが続いています。

より広い変化は「欠如」から「空白」へのシフトのようです。画像には属性が配置される可能性が高くなっていますが、常に説明的なコンテンツが伴うわけではありません。空白は省略より望ましいですが、スクリーンリーダーと検索エンジンに対して限られた価値しか提供しません。

空白の増加は劇的ではなく小さく安定しているものの、技術的なコンプライアンスと意味のあるアクセシビリティの差を依然として浮き彫りにしています。2025年のホームページ画像数が最少8枚から80枚以上にわたることを考えると、思慮深いaltテキストの重要性は増すばかりです。ウェブは明らかに正しい方向に進んでいますが、課題はカバレッジの進歩がアクセシビリティと意味においても進歩をもたらすことを保証することです。

動画

ウェブ上での動画の採用は続いて成長していますが、緩やかです。2025年には、デスクトップページの6.40%、モバイルページの5.68%に動画要素が含まれており、2024年のデスクトップ5.87%、モバイル5.13%からわずかに増加しています。デスクトップページはまだモバイルよりも動画を多く掲載しており、昨年と同じギャップを繰り返しています。

この控えめな成長は、画像と比較して動画の制作および実装コストが高いことを反映しているかもしれません。しかし、長期的なトレジェクトリは上昇傾向のままです。SEOがより包括的になり、ブランディングがウェブ全体で最も強いシグナルの一つとして浮上するにつれ、動画は権威とクロスチャネルの視認性を強化する上でより大きな役割を果たす可能性があります。

より大きな課題は最適化です。動画がより頻繁に登場している一方で、2024年にVideoObjectマークアップを使用したのはページの0.9%のみで、ほとんどの動画コンテンツがリッチリザルトに見えないままになっています。構造化データの採用が増えるまで、動画のSEOポテンシャルの多くは未活用のままです。

リンク

リンクは依然として重要性の重要なシグナルです。しかし、リンクが多いだけでランキングが上がる時代はほぼ終わりました。今日のリンクシグナル（内部・外部）はコンテンツの品質、関連性、ユーザーエクスペリエンスとバランスよく組み合わされています。

2025年のデータは、リンクプラクティスが成熟していることを示しており、説明的なアンカー、内部ナビゲーション、外部参照において安定したパターンが見られ、関係を修飾するためのrelなどの属性の選択的な使用もあります。

非説明的なリンク

2025年、ほとんどのサイトが「ここをクリック」や「もっと読む」などの漠然とした表現よりも説明的なアンカーテキストを提供し続けています。これはLighthouseのテスト合格率に反映されており、ホームページとインナーページの両方で高い水準を維持しています。

2024年: ホームページはデスクトップ84%、モバイル91%で合格し、インナーページはデスクトップ86%、モバイル92%とより強い結果でした。
2025年: ホームページはデスクトップ84.64%、モバイル86.64%とほぼ変わらず、しかしインナーページはデスクトップ92.42%、モバイル93.45%に改善しました。

ホームページとインナーページの差は持続しており、インナーページが一貫して約6〜9ポイント高くなっています。これはホームページが汎用のナビゲーションとプロモーション用CTAに依存しやすい一方、インナーページは自然とより説明的なコンテキスト・コンテンツ駆動のリンクを使用しているためと考えられます。デバイス間のパリティは近く、レスポンシブデザインプラクティスがデバイス間のアクセシビリティ標準を効果的に維持していることを示しています。

全体として、説明的なリンクプラクティスは成熟しており、前年比のわずかな変化のみです。残る機会は、漠然としたCTAがまだ最も一般的なホームページリンクの明確さを改善することにあります。

発信リンク

2025年の発信リンクは、内部および外部リンクの両方で安定したパターンを示しています。内部リンクが優勢で、中央値ではデスクトップページが同一サイトへの43リンク、モバイルページが39リンクを含んでいたのに対し、90パーセンタイルではそれらの数字が174と161に跳ね上がりました。

上位に向けた急激な上昇は、大規模または複雑なサイト（ニュースメディア、eコマースプラットフォーム、エンタープライズポータルなど）がメガメニューや密集したフッターを通じて広範なナビゲーションを表示する方法を反映しているかもしれません。デスクトップページは一貫してモバイルよりも数リンク多く表示していますが、開発者は使いやすさのために小さな画面でメニューを合理化しながらも、主要なパスウェイは維持しています。

外部リンクははるかに少ないままです。中央値のページはデスクトップとモバイルの両方でわずか6つの発信リンクを含んでおり、90パーセンタイルでもその数は25と24にしか達しません。これは2022年を反映した2024年でも記録されたフラットなトレンドを継続しています。

内部リンクは長年にわたって着実に成長している一方、外部リンクは保守的なままで、おそらく出版社がユーザーを自分のエコシステム内に留めることに焦点を当てていることを反映しています。合わせて、これらの数値は成熟した均衡を示唆しています。内部リンクはナビゲーションとクロール可能性をサポートするために成長する一方、外部リンクは控えめなレベルで安定しています。

アンカーの `rel` 属性の使用

rel 属性はもともと検索エンジンのためにリンクを修飾するためのものでしたが、今日最も一般的な使用はセキュリティに焦点を当てています。2025年、noopenerはページの40.9%に、noreferrerは25%に表示されます。どちらもランキングには影響しませんが、タブハイジャックを防いで参照データを隠すことでサイトの健全性を高めユーザーを保護するため、広く採用されています。

検索関連の修飾子については、nofollow が32.3%のページで引き続き優位を占め、2024年の水準とほぼ同じです。対照的に、より特定的な sponsored と ugc 属性はそれぞれ0.5%で停滞したままです。Googleが細かい分類を推進する取り組みにもかかわらず、採用は動いておらず、ウェブマスターが「nofollow 対通常リンク」の大まかな区別を超えた価値をほとんど見出していないことを示唆しています。

総合すると、データはrel属性の使用パターンがほぼ安定していることを示しており、前年比の動きはほとんどありません。セキュリティプラクティスが使用をリードし、SEO修飾子は安定したままで、実験的な属性は勢いを示しません。dofollowやfollowなどの古い属性でさえ、0.5%未満のページにとどまっており、古いSEOの神話がウェブの小さな隅で実際の影響なく反響し続けていることを思い起こさせます。

アンカー rel 属性の使用 — 図5.43. アンカー `rel` 属性の使用

ワード数

ワード数はSEOで長い間議論されてきた点で、コンテンツの品質や徹底さの代理指標として扱われることが多くあります。それにもかかわらず、ページの適切な長さについてのコンセンサスはほとんどありません。このセクションでは、生のページとレンダリングされたページにわたるワード数の分布を検討します。

レンダリングされたワード数

レンダリングされたワード数とは、JavaScriptが実行された後のページ上の可視の単語数を指します。

ホームページのレンダリングされたワード数

2025年のモバイルホームページの中央値は378単語を含んでおり、2024年の中央値364単語からわずかに増加しています。デスクトップホームページのレンダリングされた中央値ワード数も前年比でわずかに増加しており、2025年は413単語（2024年の400単語から増加）を示しています。モバイルとデスクトップのレンダリングされたワード数は2022年以降、デスクトップ中央値421単語、モバイル366単語だったものが低下を見せています。2025年のデスクトップとモバイルのパリティは昨年と比較してわずかに近づいており、モバイルとデスクトップのホームページワード数の差がわずか35単語に縮小し、デスクトップとモバイルのパリティが36単語だった2024年のレポートから1減少しています。これは年間を通じての一定の一貫性を示しています。

インナーページのレンダリングされたワード数

インナーページはホームページと比較して単語数が少ない傾向があります。2025年のモバイルインナーページの中央値はデスクトップで339単語、モバイルで323単語でした（デスクトップの中央値が333、モバイルが317だった2024年から増加しています）。

ここでのパーセンタイルは、インナーページの全データセットに対するページのワード数の位置を表しています。たとえば、90パーセンタイルはテストされたページの90%より多くの単語を持つページを反映しています。興味深いことに、50パーセンタイルまでは、デスクトップのインナーページが一般的にモバイルのインナーページより多くの単語を持つ傾向がありますが、パーセンタイルが高くなるにつれて差が縮まります。90パーセンタイルでは、デスクトップと比較してモバイルのインナーページワード数が大幅に増加しています。このトレンドは、デスクトップが常に高いワード数を持つホームページコンテンツでは見られません。

生のワード数

生のワード数とは、JavaScriptの実行またはDOMやCSSOMへのその後の変更の前に、サーバーから配信される元のHTMLに含まれる単語の総数を指します。

ホームページの生のワード数

2025年のページの生のワード数の中央値は、デスクトップユーザーエージェントで340単語、モバイルで316単語と、デスクトップで330単語、モバイルで311単語だった2024年からわずかに増加しています。

インナーページの生のワード数

どのパーセンタイルでもモバイルがデスクトップより多くの単語を含まなかったホームページの生のワード数とは異なり、インナーページの可視ワード数は75パーセンタイル以上でデスクトップページがモバイルページより少ない単語数を示しています。

レンダリングされたワード数と生のワード数

ホームページでレンダリングされたワード数と生のワード数を比較すると、差異は小さく、中央値ではデスクトップで18%、モバイルで16%の差を示しています。これはモバイルで成長が見られており、2024年はわずか14%でした。

すべてのパーセンタイルにわたって、デスクトップユーザーエージェントに提供されるホームページは、モバイルと比較してレンダリング後に可視化される単語の割合が高くなっています。これはモバイルでのアコーディオンのような、DOMにレンダリングされていてもコンテンツが非表示になる一般的なレイアウトによるものと思われます。

モバイルとデスクトップのすべてのパーセンタイルにわたる最大の差異はわずか2%で、10パーセンタイルのような低いパーセンタイルでは等しいワード数を示しています。

ホームページのレンダリングされたワード数と生のワード数

2025年、10パーセンタイルでデスクトップ37%、モバイル34%と大幅な上昇が見られ、2024年のデスクトップ28%、モバイル22%と比較しています。

インナーページのレンダリングされたワード数と生のワード数

インナーページのレンダリングされたワード数と生のワード数の差は10パーセンタイルで最大のギャップが見られ、アコーディオンやタブレイアウトなどのモバイルブレークポイントでHTMLには存在するがモバイルでは非表示になっているコンテンツへの依存によるものと思われます。25、50、75パーセンタイルではわずか1%の差でギャップが縮まり、90パーセンタイルでは2%となります。

このパターンは単語が多いほど、クライアントサイドのレンダリングへの依存が少ないようで、これは2024年のチャプターでも同様でした。

構造化データ

直接のランキング要因ではないものの、構造化データは検索エンジンがページのコンテキストを理解するのを助け、検索エンジン結果ページ（SERP）でリッチリザルトを表示するための強力な手段として引き続き重要です。

構造化データは、大規模言語モデルがページの「内容」だけでなく「意味」を理解するためにも活用されるようになっています。MicrosoftはBingがschema.orgマークアップを使用して、専門家記事・製品・レビュー・FAQをBing ChatやCopilotが区別できるようにしていることを認めています。GoogleのAIオーバービューの動作も同様の依存を示唆しており、GPTBotなどのクローラーは状況によってはHTML内に埋め込まれたスキーマを解析できます。

ホームページの構造化データ

図5.50. Home page use of structured data by format

構造化データの全体的な使用率は、2024年のデスクトップ48%・モバイル49%と比べ、2025年はデスクトップ・モバイルともに50%に成長しました。

大半のサイトは生のHTMLで構造化データを提供しており、JavaScriptで追加するケースはモバイル・デスクトップともに2%のみ（2024年から変化なし）です。

GoogleはJavaScriptで注入されたスキーマも処理できますが、初期HTMLに含めることで処理の遅延・クロールの問題・ユーザー体験の低下を防ぐことができます。

JSON-LDはホームページで圧倒的に人気のフォーマットで、2024年のデスクトップ41%・モバイル40%と比べ、2025年はデスクトップ・モバイルともに43%を占めています。

Googleは通常、JSON-LD構造化データの使用を推奨しています。実装・保守が最も簡単なためですが、MicrodataやRDFaなど他のフォーマットもクロール・解析は可能です。Microdataの使用率はデスクトップ・モバイルともに2024年比で1%低下しています。

インナーページの構造化データ

図5.51. Inner page use of structured data by format

インナーページでは若干の差異が見られ、Microdataはモバイル・デスクトップともに19%、JSON-LDはデスクトップ39%に対してモバイルは37%となっています。

これはホームページが最も多くのSEO対策を受けており、OrganizationやWebsiteスキーマなどのグローバルサイトテンプレートを通じて、手動またはJSON-LDで直接実装される可能性が高いためかもしれません。ホームページはリッチリザルトやブランドナレッジパネルで優先されることが多いため、JSON-LDの採用率はデバイス間でより高く一貫している傾向があります。

一方、製品ページや記事ページなどのインナーページは、デスクトップとモバイルのテンプレートによって異なる動的またはCMS生成マークアップに依存することが多く、若干の差異が生じます。

最も人気の高い構造化データタイプ

最も人気の高い構造化データタイプ上位2位に大きな変化はなく、2022年・2024年・2025年を通じてWebSiteとSearchActionが最も人気です。これらはGoogleのサイトリンク検索ボックスを機能させるものですが、視覚的には2024年11月に廃止されました。ただし、それを支える構造化データを削除する必要はありません。

Organizationスキーマの人気が若干上昇し、2025年のデータでは初めてWebPage スキーマ（WebSiteスキーマと混同しないでください）を上回りました。

WebSiteスキーマは引き続きすべての構造化データタイプの中で最も人気で、2025年のモバイルでは2024年の35%・2022年の30%と比べ36%に若干増加しました。モバイルの構造化データ使用率は年ごとの差異が小さいです。

インナーページでは、ListItem構造化データが引き続き最も人気のインナーページスキーマタイプですが、モバイルの使用率は2024年の30%から2025年の27%に低下しています。

興味深いことに、WebSite構造化データはホームページ固有のスキーマタイプであるにもかかわらず（少なくともGoogleによれば）、インナーページでも3番目に人気の構造化データタイプです。これは多くの種類のスキーマがCMSレベルでテンプレート化されており、インナーページにも複製されているためかもしれません。

スキーマの使用状況の詳細については、専用の構造化データチャプターをご覧ください。

AMP

Accelerated Mobile Pages（AMP）はかつて、特にモバイル検索におけるパフォーマンスと視認性を高める近道として推進されていました。しかし、すべてのページに直接パフォーマンス指標を提供するCore Web Vitalsが登場したことで、AMPの役割は急激に縮小しました。2025年のデータでは、ホームページ・インナーページを通じて採用率は一貫して低く、1%を下回るままです。残存する使用はニッチなまたはレガシーな実装を反映しており、主流の戦略とはなっていません。

ホームページのAMP使用状況

AMPマークアップの採用は2025年も極めて低い水準にとどまり、インナーページではすべてのデバイスタイプでわずかな使用しか見られません。rel=amphtml が最も一般的なシグナルで、デスクトップページの0.8%、モバイルページの0.9%に出現しています。HTML AMPはモバイルページのわずか0.1%に見られ、デスクトップではほぼゼロです。AMP EmojiやAMP HTML + Emojiなど他のバリアントはほぼ存在せず、0.2%以下です。

2024年と比較すると、全体的な状況は停滞と言えます。2024年に見られた若干の上昇は継続せず、使用率は引き続き1%を大きく下回ったままです。GoogleがTop Storiesの要件からAMPを外したことと、Core Web VitalsがユニバーサルなパフォーマンスメトリクスとしてAMPの地位を確実にフリンジテクノロジーに押し込んでいます。

ホームページ対インナーページのAMP使用状況

2024年はホームページがインナーページよりわずかにAMPを採用している傾向がありましたが、2025年はその逆となっています。rel=amphtml はインナーページの1.7%に出現するのに対し、ホームページは1.0%です。HTML AMPも同様で、採用率は現在均等（各0.1%）に分かれています。

国際化

hreflang属性は国際サイトや多言語ウェブサイトにとって重要な機能であり、検索エンジンがユーザーに適切な言語や地域バージョンのページを提供するのを助けます。2025年、hreflangはおよそ20%のページに出現しています。採用は国際ターゲティングが最も大きな影響を持つホームページで優先されることが多く、インナーページはカバレッジが一貫していません。成長は継続していますが、広く使用される少数の言語に集中しています。

`hreflang` の実装

現在、5ページに1ページがhreflangマークアップを含んでいます。生（デスクトップ）は20.3%、生（モバイル）は19.7%で、レンダリング後はそれぞれ20.8%・20.2%とわずかに高い値です。これはhreflangタグを持つページが9〜10%程度だった昨年の数値のほぼ2倍です。

HTTP hreflangはほぼ消滅しており、デスクトップページの0.2%・モバイルページの0.1%が使用しているのみです。これは2024年のすでに小さなシェアと一致しており、HTTPSが国際化ウェブサイトのほぼすべてでデフォルトとなったことを裏付けています。

生とレンダリング後の値の近似性（1%未満の差）は、hreflangを実装しているほとんどのサイトが技術的に正しい方法で実装しており、レンダリング後も維持されていることを示しています。これはギャップがわずかに大きかった2024年からの改善です。

hreflang の実装方法 — 図5.57. `hreflang` の実装方法

ホームページの `hreflang` 使用状況

ホームページでの hreflang 使用は依然として少数の値に高度に集中しています。英語（en）が引き続き支配的で、デスクトップホームページの7.4%、モバイルの7.3%に出現し、x-default がデスクトップ7.2%・モバイル6.9%で続いています。

フランス語（モバイル3.2%）・ドイツ語（モバイル3.1%）・スペイン語（モバイル3.0%）などの第2言語グループが次のティアを形成し、イタリア語・ロシア語・ポルトガル語・オランダ語・日本語は2.5%未満にとどまっています。

この集中は、hreflang の採用がページ全体の20%をカバーするまでに成長したにもかかわらず、その大半が広くターゲットとされる少数の視聴者層に集中していることを示しています。

2024年に en がデスクトップ・モバイルともにホームページの8%に出現していたのと比べ、2025年のデータは若干の低下を示しています。ただし、第2言語群の採用は安定しており、全体的な分布は年を通じて一貫しています。

インナーページの `hreflang` 使用状況

インナーページでのhreflang採用はホームページのパターンを反映していますが、わずかに低い水準です。英語（en）がデスクトップページの7.6%・モバイルの6.9%でトップを占め、x-defaultがデスクトップ7.4%・モバイル6.8%で続いています。フランス語（インナーモバイルページの3.2%）・ドイツ語（モバイル3.1%）・スペイン語（モバイル3.0%）が次のティアを形成し、他のすべての言語値は2.5%未満にとどまっています。

2024年にデスクトップのx-defaultとenが8%近くだったのと比べ、2025年の数値はわずかな低下を示しています。この分布は、hreflangがインナーページよりもホームページで優先される傾向にあることを再確認するものです。フランス語・ドイツ語・スペイン語の緊密なクラスタリング（インナーモバイルページで3.0〜3.2%）は、英語以外の多言語ウェブ採用の大部分が欧州主要市場によって推進されていることを裏付けています。

結論

AIサーチがコンテンツの発見方法を再形成する中、ウェブの基本原則はかつてないほど重要です。心強いことに、データはその基盤が揺るぎないことを示しています。

クロール可能性とインデックス可能性は依然として強固です。ほとんどのサイトが有効な robots.txt ファイルと canonical タグを提供しており、マークアップの品質は年々改善しています。robots.txt 自体の役割も進化しており、アクセスのゲートキーパーからコンテンツ使用意図の宣言へと移行しています。数百万のファイルが gptbot や claudebot などのAIクローラーに明示的に対応するようになっています。強固な meta ロボットの採用と安定したカノニカルシグナルと合わせて、これらの技術的な柱は人間とマシン主導の検索システムの両方にとって信頼できる基盤を提供しています。

これらのアクセスシグナルを超えて、ウェブの中間層——ページエクスペリエンス・パフォーマンス・オンページ構造——が心強い安定性を示しています。HTTPSの採用は91%を超え、Core Web Vitalsは歴史的に高い水準で横ばいとなり、タイトル・ディスクリプション・見出しなどのオンページメタデータは検索とAI主導のインデックス作成の両方に向けて最適化が進んでいます。構造化データの採用率は50%に達し、ほとんどの実装は直接HTMLに埋め込まれています。これらはすべて、クローラーとモデルによる、より速く・よりクリーンな解釈を確保するためのものです。

llms.txt はウェブがAIシステムに直接語りかけるための最新の実験です。サイトオーナーは、コンテンツがAIによってどのようにランク付けされ・読まれ・再利用されるかについて考えるよう招かれています。採用率はまだ低く（約2%）、意図的な戦略よりもCMSプラグインによって推進されていますが、その存在はマインドセットの転換を示しています。llms.txt が標準になるか脚注にとどまるかは、2026年に持ち越される重要な問いです。

この進歩の多くは、ベストプラクティスをデフォルトで組み込むようになったCMSプラットフォームから生まれており、ウェブ全体の技術的なベースラインを静かに引き上げています。テクニカルSEOの全体的な軌跡は心強いものです。ウェブは1年前よりも一般的により一貫性があり・クロールしやすく・意味的に高度になっています。

SEO担当者は長年、これらの基本原則——構造化データ・メタデータ・クリーンなアーキテクチャ——が重要であることを知っていましたが、絶え間ないアルゴリズムの変動が、しばしばそれらを手っ取り早い戦術よりも二次的なものと感じさせていました。しかし今、大規模言語モデルがコンテンツの解釈と引用のために構造化され適切にラベル付けされたデータにますます依存するようになった今、それらの同じ基本原則が再び実証されています。基礎は時代遅れになったことはなく、今後もそうなることはないでしょう。

結果を調べる

結果を表示クエリを表示編集を提案する翻訳ヘルプ

著者

Amaka Chulwuma
Amaka-maxi amaka-chukwuma-jubilee

AmakaはSEOおよびコンテンツストラテジストで、過去7年間にわたりブランドのオンラインプレゼンスを形成してきました。英国、米国、オーストラリアのエージェンシー（Whitecoat SEOやSwitch Key Digitalを含む）で勤務し、法律、医療、家庭サービス、B2B分野のクライアントのためにコンテンツシステム、テクニカルSEOの基盤、検索主導のストーリーテリングを構築しています。その仕事は明確さ、思慮深い戦略、共感のミックスを反映しています。仕事以外でも同じ姿勢を持ち込んでおり、特に毎日の最良の部分である娘との時間を大切にしています。
Chris Green
@chrisgreenseo @chris-green.net chr156r33n chrisgreenseo https://www.torquepartnership.com/

Chris GreenはTorque Partnershipのテクニカルディレクターであり、15年以上のサーチ業界のベテランです。Fortune 500企業に対して、検索戦略やブランド・アルゴリズム・AIシステムの進化する関係性についてアドバイスしています。
Sophie Brannon
@SophieBrannon SophieBrannon

Sophie Brannonはアトランタを拠点とするStudioHawk USの共同創設者兼ディレクターです。エージェンシー、社内、コンサルタントにわたる10年以上のSEO経験を持ち、eコマース、金融、ゲーム、ヘルス、SaaSなど幅広い業界で活動してきました。Sophieはオーガニック成長に対して戦略的かつデータドリブンなアプローチを採用し、テクニカルSEO、ユーザーエクスペリエンステスト、コンテンツ、デジタルPRを通じてブランドの持続可能なスケールを支援しています。SEOをアクセスしやすくし、次世代の検索マーケターを育成することに情熱を持っています。

引用

BibTeX

@inbook{WebAlmanac.2025.SEO,
author = "Chulwuma、AmakaとGreen、ChrisとBrannon、SophieとIndigo、JamieとDelport、AugustinとLewittes、MichaelとCano、MontserratとMcClintic、Sharon",
title = "SEO",
booktitle = "2025 Web Almanac",
chapter = 5,
publisher = "HTTP Archive",
year = "2025",
language = "日本語",
doi = "10.5281/zenodo.18246492",
url = "https://almanac.httparchive.org/en/2025/seo"
}