SEOのためのセマンティックHTML
セマンティックHTML要素(article、section、nav、header、main、aside)が、検索エンジンがページのメインコンテンツを識別するのにどのように役立つか — ランキング要因ではない理由と、各要素の正しい使い方。
言語
セマンティックHTMLは、<main>、<article>、<section>、<nav>、<header>、<aside>などの要素を使用して、コンテンツがどのように見えるかだけでなく、何であるかを説明します。これはランキング要因ではありません — John Muellerはこれを「魔法の乗数ではない」と呼び、<article>は検索において「特別な効果はない」と述べています。それが行うのは、Googleがメインコンテンツと定型文をより確実に分離するのを助けることです(Googleのcenterpiece注釈は、マークアップに関係なくNLPを介してこれを行いますが、クリーンなセマンティクスは推測作業を減らします)、支援技術を助け、JavaScriptをレンダリングしないAIクローラーを助けます。BingのFabrice Canelはこれを「SEOの利点」としてより強く表現しています。同じ考え方はランドマークを超えて広がります:ナビゲーションには<a href>を、アクションには<button>を、表形式データには実際の<table>を、画像には目的に基づいたaltテキストを、ネイティブの開示ウィジェットには<details>/<summary>を使用します — そして、<section>のネストによって見出しレベルを暗示するという古くて実装されていない「ドキュメントアウトラインアルゴリズム」に頼らないでください。正しい使い方は存在よりも重要です:ページごとに<main>を1つ、自己完結型コンテンツには<article>、見出しを持つテーマ別グループには<section> — <div>の置き換えではありません。これをセマンティックSEO(トピック/エンティティ戦略)と混同しないでください。
Evidence for this claim Semantic HTML uses elements according to their defined purpose and structural meaning. Scope: HTML element semantics. Confidence: high · Verified: WHATWG HTML: Semantics Evidence for this claim Native semantic HTML exposes built-in roles and supports accessible structure when elements are used correctly. Scope: W3C guidance on semantic HTML and accessibility. Confidence: high · Verified: W3C WAI: HTML and accessibilityTL;DR — セマンティックHTMLとは、コンテンツが何であるかを説明するタグを使用することを意味します —
<article>、<nav>、<main>、<header>— すべてを単純な<div>で囲む代わりに。これにより、検索エンジンやスクリーンリーダーがページを理解しやすくなりますが、 ランキング要因ではありません。<article>を使用してもランキングは上がりません。 同じルールはランドマーク以外にも適用されます:リンクには<a href>、アクションには<button>、 表形式のデータには<table>、画像には実際のaltテキスト。適切なタグを 使用すれば、ほとんど完成です。
セマンティックHTMLとは
ウェブページのすべての部分はHTML要素で構築されています。セマンティックHTMLとは、 コンテンツが実際に何であるかに一致する要素を選択することを意味し、すべてに 汎用のラッパーを使用するのではありません。
同じページ構造のこれら2つのバージョンを比較してください:
<!-- Non-semantic: "div soup" -->
<div class="top"> ... </div>
<div class="menu"> ... </div>
<div class="content"> ... </div>
<div class="sidebar"> ... </div>
<div class="bottom"> ... </div><!-- Semantic: the tags describe the roles -->
<header> ... </header>
<nav> ... </nav>
<main> ... </main>
<aside> ... </aside>
<footer> ... </footer>どちらも画面上では同じように見えます — スタイリングはCSSが処理します。違いは、 2番目のバージョンは機械(検索エンジン、スクリーンリーダー、AI クローラー)に、どの部分がナビゲーションで、どれがメインコンテンツで、どれが サイドバーかを伝えることです。1番目のバージョンでは、誰もが推測することになります。
実際に使用する要素
<header>— ページの上部(またはセクションの上部)にある導入コンテンツ。<nav>— ナビゲーションリンクのブロック。<main>— ページの主要でユニークなコンテンツ。1ページに1つ。<article>— 単独で成立する自己完結型のコンテンツ(ブログ投稿、 プロダクトカード、コメント)。<section>— 独自の見出しを持つコンテンツのテーマ別グループ。<aside>— メインコンテンツに付随するコンテンツ(サイドバー、コールアウト)。<footer>— 締めくくりのコンテンツ(著作権、二次リンク)。
同じ「適切なタグを使用する」という考え方は、ページレイアウトレベル以下にも適用されます:リンクには<a href>、
ページ内アクションには<button>、実際の表形式データには<table>、そして
画像には目的に基づいたaltテキスト。スタイルを適用した<div>から作られた偽のリンクは、
最も一般的なアクセシビリティの見落としです — 完全なリストは「詳細」タブを参照してください。
多くの人が誤解していること
コンテンツを<article>で囲んでもランキングは上がりません。 Googleの
John Mueller氏は、<article>要素はGoogle検索において「特別な効果はない」と述べており、
セマンティックHTMLは「魔法の倍率ではない」と述べています。セマンティックHTMLは検索エンジンが
ページを理解するのを助けます — ただ、ランキングを上げるためのレバーではないだけです。
価値は実際にありますが、「ランキングポイント」ではないだけです。クリーンなセマンティックマークアップにより、 検索エンジンがメインコンテンツを定型文(メニュー、フッター、広告)から 区別しやすくなり、スクリーンリーダーを使用する人々にとってページが適切に機能し、 AIツールが読み取りやすくなります。これらはすべて実行する正当な理由です — そのどれもが「ランキング要因だから」ではありません。
もう1つの落とし穴:セマンティックHTMLは「セマンティックSEO」と同じではありません。 セマンティックHTMLは マークアップ構造に関するものです。セマンティックSEOはコンテンツ内のトピックとエンティティに関するものです。 同じ言葉でも、まったく別のものです。
全体像 — 各要素が何を伝えるか、GoogleとBingが実際に何を言っているか、メインコンテンツ抽出にどのように適合するか、 そしてレトロフィットのチェックリスト — をご希望ですか?詳細タブに切り替えてください。
Evidence for this claim Semantic HTML uses elements according to their defined purpose and structural meaning. Scope: HTML element semantics. Confidence: high · Verified: WHATWG HTML: Semantics Evidence for this claim Native semantic HTML exposes built-in roles and supports accessible structure when elements are used correctly. Scope: W3C guidance on semantic HTML and accessibility. Confidence: high · Verified: W3C WAI: HTML and accessibilityTL;DR — セマンティックHTMLは、要素を意図された構造的な意味のために使用します(
<main>、<article>、<section>、<nav>、<header>、<aside>)。これにより、マークアップはコンテンツが何であるかを伝え、見た目ではありません。これはランキング要因ではありません — Mueller氏は「魔法の乗数ではない」と述べ、<article>には「特別な効果はない」としています。実際に何をするかというと、曖昧さを減らすことです:Googleの中心的な注釈は、マークアップがセマンティックであるかどうかに関係なく、NLPを介してメインコンテンツをボイラープレートから分離しますが、クリーンなセマンティクスはその作業をより信頼性の高いものにします。BingのFabrice Canel氏はこれをより強く表現しています(「SEOにおいて有利」)— 私はそのギャップを正直に指摘し、無理に調和させたりはしません。Google自身のスターターガイドは、ウェブの大部分が有効なHTMLではないため、仕様のセマンティクスに依存することはほとんどないと述べています。正しい使用法が存在よりも重要です: 自己完結型コンテンツには<main>を1つ、<article>を、見出しを持つテーマ別グループには<section>を使用します —<div>の代わりではありません。同じテストは<a href>と<button>(ナビゲート対アクション)、表形式データ用の実際の<table>、目的に基づいた画像のaltテキスト、開示ウィジェット用の<details>/<summary>にも適用されます — また、<section>のネストが見出しレベルを暗示するとは頼らないでください。その「ドキュメントアウトラインアルゴリズム」は実装されたことがなく、仕様はもはやそのようにアウトラインを定義していません。セマンティックHTMLとセマンティックSEOを混同しないでください。
セマンティックHTMLとは実際には何か
セマンティックHTMLとは、伝えるために設計された構造的な意味に基づいてHTML要素を選択する実践であり、すべてに<div>と<span>を使うのではありません。<article>、<section>、<nav>、<header>、<main>、<aside>、<footer>はそれぞれ役割を宣言します。マークアップはページの一部が何であるかを説明します。CSSはそれがどのように見えるかを決定します。Google自身の開発者スタイルガイドは、このルールをこれ以上ないほど簡潔に述べています:「HTML要素を、設計された目的のために使用してください。」
人々を混乱させることの1つ:クラス名はセマンティクスを作成しません。<div>にclass="article"やclass="main-nav"と名前を付けても、<article>要素のコンテンツモデルや<nav>要素の暗黙のナビゲーション役割は与えられません — ブラウザ、スクリーンリーダー、クローラーにとっては、依然として汎用の<div>です。セマンティクスは選択した要素に存在し、スタイルやラベル付けの方法には存在しません。
この記事は、セマンティック要素に特化しています。より広い「GoogleがHTMLをどのように解析するか、見出し階層、妥当性」の全体像は、このページが属するHTML SEOハブに属しています — ここで再議論するのではなく、相互参照します。
セマンティックHTMLは実際にSEOに役立つのか?
短い答え:それは理解を助けますが、ランキング要因ではなく、2つのエンジンはそれを少し異なる方法で捉えています。正直なバージョンは次のとおりです。
Googleの見解
Googleの見解は、John Mueller氏によって繰り返されていますが、セマンティックHTMLは行う価値があるがランキングのレバーではないというものです。Search Engine Journalが報じたように、Mueller氏は「セマンティックHTMLはページを理解するのに役立ちます。ただし、ウェブサイトをより高いランキングにするための魔法の乗数ではありません。」と述べ、さらに別途:「セマンティックHTMLを使用してください。それはランキング要因ではありませんが、私たちのシステムがあなたのコンテンツをよりよく理解するのに役立ちます。」
<article>要素について具体的に言うと——皆がよく尋ねるあの要素ですが——Mueller氏はOffice Hoursセッションで率直に述べています:<article>要素は*「Google検索において特別な効果はありません」*。そして、それでも使う理由についても付け加えています:「アクセシビリティやセマンティックな理由で特定の種類のマークアップを使うことがあるので、SEOだけに焦点を当てないでください。」 (翻訳) 「アクセシビリティやセマンティックな理由で特定の種類のマークアップを使うことがあるので、SEOだけに焦点を当てないでください。」
Googleはまた、完璧なセマンティクスに依存していないと明言しています。SEOスターターガイドでは、「見出しをセマンティックな順序にすることはスクリーンリーダーにとって素晴らしいことですが、Google検索の観点からは、順序を無視して使っても問題ありません。ウェブ全般は有効なHTMLではないため、Google検索がHTML仕様に隠されたセマンティックな意味に依存することはほとんどありません。」 (翻訳) 「見出しをセマンティックな順序にすることはスクリーンリーダーにとって素晴らしいことですが、Google検索の観点からは、順序を無視して使っても問題ありません。ウェブ全般は有効なHTMLではないため、Google検索がHTML仕様に隠されたセマンティックな意味に依存することはほとんどありません。」これは重要なニュアンスであり、矛盾ではありません。セマンティックHTMLは周辺的な部分で役立ち、完璧である必要はなく、スコア化されるシグナルでもありません。
Googleがメインコンテンツを見つける仕組みとの関係
セマンティックHTMLがランキング要因ではないにもかかわらず役立つ仕組みは次のとおりです。Googleは、ページが何についてのものかを判断する前に、ページのメインコンテンツをボイラープレート(ナビゲーション、ヘッダー、フッター、サイドバー、広告)から分離する必要があります。Martin Splitt氏はその仕組みを次のように説明しています:「例えば、Centerpiece Annotationと呼ばれるものがあり、セマンティックコンテンツを調べる他のアノテーションもいくつかあります。」 (翻訳) 「例えば、Centerpiece Annotationと呼ばれるものがあり、セマンティックコンテンツを調べる他のアノテーションもいくつかあります。」Googleがトピックを把握する方法は、タグ名ではなく、コンテンツに対する自然言語処理です:「ここで取得したテキストコンテンツ全体に対して行ったすべての自然言語処理から、これは主にトピックA、ドッグフードについてであるように見えます。」 (翻訳) 「ここで取得したテキストコンテンツ全体に対して行ったすべての自然言語処理から、これは主にトピックA、ドッグフードについてであるように見えます。」そして、残りは重み付けを下げます:「ボイラープレートのように見えるものを特定し、それも異なる重み付けがされます。」 (翻訳) 「ボイラープレートのように見えるものを特定し、それも異なる重み付けがされます。」
重要な点:その抽出は、マークアップがセマンティックであるかどうかに関係なく機能します。Googleは完全に<div>で構築されたページでも解きほぐすことができます。しかし、セマンティックHTML5が役立つかどうかを直接尋ねられたとき、Splitt氏の答えは「役立ちますが、私たちが探しているものはそれだけではありません。はい。」 (翻訳) 「役立ちますが、私たちが探しているものはそれだけではありません。はい。」でした。つまり、セマンティックHTMLはスコアを上げるのではなく、Googleがすでに行っているステップの推測作業を減らすのです。それがまさに、ランキングシグナルではなく信頼性と効率性のシグナルである理由です。それが何をしないかを正確に言うと:正しいセマンティックマークアップは、特定の検索表示を保証するものでもありません。これは、リッチリザルトを管理する適合ルールとは別のレイヤーです(詳細は後述)。
Bingの見解(そしてなぜ異なるのか)
BingはこれをGoogleよりも強く表現しており、私はその違いを隠すのではなくそのままにしておきます。MicrosoftのFabrice Canel氏は、正しく実装されたセマンティックHTML5を含むページは、そうでないページよりも*「SEO上のアドバンテージ」*があると述べています。これはGoogleの「理解に役立つ」という主張よりも強い主張です。BingはセマンティックHTML5を直接SEOのアドバンテージに結び付けています。両エンジンは「機械的に役立つ」という点では一致していますが、同じ言葉を使っているわけではなく、競合するガイダンスを読むときにはその点を知っておくべきです。明確に言っておきますが、どちらもリンクや関連性のようにスコア化されたランキング要素として説明しているわけではありません。
主要なセマンティック要素とその正しい使い方
存在すること自体が重要なのではなく、正しい使い方が重要なのです。最も一般的な失敗パターンは、セマンティックタグを装飾のように散りばめることや、各要素の意味を考えずに<div>を<section>に置き換えることです。
<header>と<footer>
<header>は導入コンテンツを保持し、<footer>は締めくくりのコンテンツを保持します。そして、両方とも文脈に依存します。ドキュメントレベルでは、<header>はサイトのバナー、<footer>はサイトのフッターです。しかし、<article>や<section>の内部にネストして、そのブロック自体の導入と締めくくりをマークすることもできます(記事のタイトルや著者名を<header>に、タグを<footer>に)。これらは複数あっても構いません。ただし、それぞれがその文脈の導入または締めくくりのコンテンツをラップしていることを確認してください。任意のボックスをラップするのではありません。
<nav>
<nav>はナビゲーションリンクの主要なブロック(プライマリメニュー、パンくずリスト、ページ内目次など)に使用します。ページ上のすべてのリンクグループに使うものではありません(本文中の関連記事リストは<nav>である必要はありません)。すべてのリンククラスタを<nav>でラップするとシグナルが薄まります。本当のナビゲーションのために予約しておきましょう。
<main>
<main>はページの主要でユニークなコンテンツ(サイト全体で繰り返されない部分)をラップします。よくつまずくルールは、ページごとに<main>は1つだけであるべきで、<article>、<aside>、<header>、<footer>、<nav>の内部にネストしてはいけないというものです。これは「ここが重要なコンテンツです」という最も明確なシグナルです。
<article>と<section>(誰もが間違えるポイント)
ここが正しく理解すべき違いです:
<article>は自己完結型で、独立して配布可能なコンテンツに使用します。ページから取り出してフィードに落としても意味が通じるものです。ブログ投稿、ニュース記事、商品カード、フォーラムの投稿、個々のユーザーコメントなどです。単独でシンジケーションできるなら、それは<article>です。<section>は、独自の見出しを持つべきテーマ別のグループです。「レビュー」ブロック、「仕様」ブロック、章などです。テスト方法:コンテンツに見出しがなくても意味が通じないなら、それはおそらく<section>ではありません。また、CSSを適用するためだけに使っているなら、<div>にすべきです。
<section>は汎用のラッパーではありません。セマンティックな意味のないスタイリングフックが必要な場合は、<div>を使用してください。それがまさに<div>の役割です。「よりモダンに感じる」という理由で<section>を使うのは、最も一般的な誤用です。
<aside>
<aside>は周囲のコンテンツから逸脱したコンテンツ(サイドバー、プルクォート、関連リンクボックス、広告セットなど)をマークします。「これは関連しているが、本筋ではない」というシグナルを送ります。これはまさにGoogleが描こうとしているボイラープレートとメインコンテンツの区別です。視覚的に横にあるからといって使うのではなく、コンテンツが本当に二次的である場合に使ってください。
ランドマークロールを正しく設定する(そしてアウトラインの神話)
各ランドマーク要素は、支援技術が直接読み取る特定の暗黙のARIAロールにマッピングされます。これは非視覚ユーザーがナビゲートするのと同じ計算された構造であり、推測するのではなく実際のマッピングを知っておく価値があります:
| 要素 | 暗黙のロール | 注記 |
|---|---|---|
<header>(ドキュメントレベル) | banner | トップレベルでのみ — <article>/<aside>/<main>/<nav>/<section> 内にネストされている場合、ランドマークロールはありません。 |
<footer>(ドキュメントレベル) | contentinfo | 同じ注意点 — ネストされている場合、ランドマークではありません。 |
<nav> | navigation | |
<main> | main | |
<aside> | complementary | |
<article> | article(ランドマークではない) | ドキュメント構造ロールであり、ナビゲーション可能なランドマークの1つではありません。 |
<section> | region — ただしアクセシブルな名前がある場合のみ(例:見出しを介して) | 名前のない <section> には暗黙のロールがまったくないため、<div> の代わりとして使用しないもう1つの理由です。 |
廃止に値する俗説が1つあります:<section> をネストしても、その見出しに暗黙の下位ランクが与えられるわけではありません。初期のHTML5では、セクショニング要素内のネストの深さから見出しの実効レベルを計算するドキュメントアウトラインアルゴリズムが定義されていました — そのため、ネストされた <h1> は理論上 <h2> のように「動作」できました。しかし、どのブラウザやスクリーンリーダーもそのアルゴリズムを実装したことはなく、WHATWG仕様 はその後、より単純な定義を採用してそれを廃止しました:アウトラインはドキュメント内のすべての見出しをツリー順に並べたものにすぎません。<h1>–<h6> のレベルを明示的に、実際に読みたい順序で記述してください — ネストの深さはその作業を代行してくれません。
リンクとボタン — アクション対ナビゲーションのテスト
これはランドマーク要素ではありませんが、ウェブ上で最も一般的な意味論の間違いです:<a href> が適切な場所でスタイル付きの <div> や <span>(または <button>)を使用する、またはその逆です。WHATWG仕様 は明確です — href 属性を持つ <a> はネイティブのハイパーリンクメカニズムであり、<button> 要素 はアクションをトリガーするためのラベル付きインタラクティブコントロールです。テストは簡単です:これはユーザーを何かへ連れて行きますか(新しいURL、新しいページ、フラグメント)? <a href> を使用してください。現在のページで何かを行いますか(フォームの送信、モーダルのオープン、設定の切り替え)? <button> を使用してください。一方を他方のように見せるスタイリングは、ネイティブの性質を変えません — クリックハンドラーを持つ <div> は、role、tabindex、キーハンドラーで自分で再構築しない限り、ネイティブのキーボードアクティベーションも正しいアクセシブルロールも得られません。正しい要素を使用してください。
テーブルは表形式データ用であり、レイアウト用ではない
コンテンツに実際に行と列がある場合 — 比較表、価格グリッド、データセット — スタイル付き <div> のグリッドではなく、実際の <table> を使用してください。WHATWGテーブル仕様 は実際のデータモデルを定義しています:<caption> はテーブルに名前を付け、<th> ヘッダーセル(scope 付き)は、支援技術が数字の羅列ではなく「価格、$49」とアナウンスできるようにする行/列の関係を確立します。<div> から構築された視覚的にテーブル状のグリッドには、そのような関係データは一切含まれていません — 見た目は正しくても、読み上げは正しくありません。ページレイアウトに <table> を使用しないでください。それはこのプラクティスが置き換えた古い誤用です。
代替テキストは画像の目的によって異なる
<img> には alt 属性が必要ですが、WHATWG仕様の要件 は目的に依存しており、万能ではありません:商品写真には表示されている内容の説明が必要です;純粋に装飾的な画像には alt=""(欠落ではなく空)を指定して、支援技術がファイル名をアナウンスする代わりにスキップできるようにします;リンクでもある画像には、画像だけでなくリンクの宛先やアクションを説明する代替テキストが必要です。「SEOのため」にすべての画像にキーワードを詰め込んだ代替テキストをデフォルトにしないでください — それは間違ったテストです。正しいテストは:スクリーンリーダーユーザーが知る必要があるが、そうでなければ見逃してしまう情報は何か?
ネイティブの開示ウィジェット:<details> と <summary>
「クリックして展開」するコンテンツ(FAQ、仕様書、ネタバレテキストなど)には、
<details>/<summary> ペア
がネイティブの開閉ウィジェットです。<summary> は常に表示されるラベルで、
<details> 内のコンテンツは要素の open 状態に基づいて表示・非表示が切り替わり、
JavaScript は不要です。キーボードサポートと適切なアクセシビリティセマンティクスが標準で備わっており、
カスタムの <div> と JavaScript によるアコーディオンを自作するのは、
ブラウザがすでに提供している動作を再実装することになります。ただし、公開前に実際の
ターゲットブラウザとスクリーンリーダーでテストしてください。<details>/<summary> の
レンダリングとアクセシビリティツリーへの公開は、ブラウザと支援技術の組み合わせによって
歴史的にばらつきがあるため、確認していない同等性を想定しないでください。
セマンティックHTMLとSEOに関するよくある誤解
- 「
<article>でコンテンツを囲むとランキングが上がる。」 いいえ — Mueller氏によると、<article>要素は 「Google検索において特別な効果はありません。」 - 「セマンティックHTMLはランキング要因である。」 いいえ — 「魔法の乗数ではない」 そして 「ランキング要因ではありませんが、当社のシステムがコンテンツをよりよく理解するのに役立ちます。」
- 「Googleは有効かつ厳密なセマンティックHTMLを要求する。」 いいえ — スターターガイド によると、 ウェブの大部分は有効なHTMLではなく、Googleは 「HTML仕様に隠されたセマンティックな意味にほとんど依存できない。」
- 「SEOのためには見出しの順序が完璧でなければならない。」 スクリーンリーダーは気にしますが、Googleのランキングは 気にしません(同じスターターガイドの記述)。より深い見出し階層の扱いは HTML SEOハブに属します — これは簡潔なバージョンにすぎません。
- 「セマンティックHTMLとセマンティックSEOは同じものである。」 いいえ — 一方はマークアップ構造であり、 もう一方はトピック/エンティティのコンテンツ戦略です。この2つを混同するからこそ、「セマンティック」という クエリの検索結果の多くが間違ったトピックについてのものになっています。
- 「構造化データがあればセマンティックHTMLは不要になる。」 いいえ — これらは補完関係にあります。 セマンティックHTMLは、あなたの構造化データに、より 信頼性の高い基盤を与えます。置き換えるものではなく、JSON-LDがdivスープを修正するわけでもありません。そして どちらも結果を保証するものではありません:Google自身の構造化データ入門 は、サポートされているマークアップを使用してもリッチリザルトが保証されるわけではないと明言しています — 特定の検索機能の対象となるかどうかは、マークアップ(セマンティックHTMLまたはJSON-LD)が技術的に有効かどうかとは 別のルールセットです。
- 「
<section>をネストすると、その見出しに暗黙の下位ランクが与えられる — ネストしたセクション内で<h1>から<h2>に下げる必要はない。」 いいえ — これは HTML5の古い 文書アウトラインアルゴリズム の名残であり、セクショニング要素のネストから暗黙の 見出しランクを計算していたはずのものです。ブラウザやスクリーンリーダーがこれを実装したことは一度もなく、WHATWG HTML仕様 はもはやそのようにアウトライン計算を定義していません — 今日のアウトラインは単に「文書内のすべての見出しをツリー順に並べたもの」です。<section>/<article>のネストがどれだけ深くても、明示的で正しい順序の<h1>–<h6>を使用してください。 見出しレベルの作業をネストに任せないでください。
セマンティックHTMLとセマンティックSEO — 混同しないでください
同じ単語を共有しているため、これらは常に混同され、両方の検索結果を汚染しています:
- セマンティックHTML = マークアップ — ページを構造化するために使用する要素。
- セマンティックSEO = コンテンツ戦略 — エンティティと関連概念を中心にトピックオーソリティを構築する(AI検索やコンテンツのピラーの下に位置するもので、ここではありません)。
「セマンティックSEO」というクエリからトピックモデリングを期待してここにたどり着いた場合、それは別の記事です。これは厳密に要素についてのものです。
セマンティックHTMLとAI/LLMクローラー
ここでセマンティックHTMLは静かにより関連性を増しています。これは業界の意見であり、エンジンの公式見解ではないと明記しておきます。多くのLLMクローラーやAI回答エンジンはJavaScriptをレンダリングせず、配信されたHTMLを解析します。クリーンなセマンティックマークアップは、深くネストされた<div>スープよりもはるかに扱いやすいです。バリー・アダムスが言うように、「ChatGPTが数百(または数千)のネストされた<div>タグを解析するよりも、数十のセマンティックHTMLタグを解析する方がはるかに簡単です。」 そしてより広く、「ウェブページのセマンティックHTMLマークアップは、機械システムがコンテンツとその価値をよりよく理解するのに役立ちます。」 ジョノ・アルダーソンも同じ将来を見据えた主張をしています — サイトは「インターフェース。API。データセット。」 であり、単なる視覚的な体験ではない — そして彼の一言が正しい使用法のすべての議論です:「すべてが<div>や<span>なら、何も意味を持ちません。」 これらすべてを、マークアップをクリーンに保つための良い方向性の理由として扱ってください。GoogleやBingからの約束としてではありません。
既存ページの監査とリフォーム方法
ほとんどの実際のサイトはすでにdivスープであり、一夜で再構築するものではありません。実用的なリフォームの順序:
- まずランドマークを確立する。
<main>が正確に1つ、ドキュメントの<header>、<footer>、プライマリメニュー用の<nav>があることを確認します。これらのランドマーク要素は、メインコンテンツの抽出とアクセシビリティの両方に最も効果的です。 - 自己完結型ブロックを
<article>に変換する。 ブログ投稿、製品カード、コメント — フィードで単独で存在できるもの。 - 本物のテーマグループを
<section>に変換する — ただし、実際の見出しがある場合のみ。見出しがない場合は、<div>のままにします。 - サイドバーや関連コンテンツボックスを
<aside>に移動する。 - 偽のリンクと偽のボタンを修正する。 クリックハンドラー付きのスタイル付き
<div>は、<a href>(ナビゲートする場合)または<button>(ページ上で動作する場合)にする必要があります — これは通常、キーボードとスクリーンリーダーユーザーにとって最も価値の高い単一の修正です。 <div>のテーブル状グリッドを実際の<table>に変換する コンテンツが本当に表形式の場合、ヘッダーセルには<caption>と<th>を使用します。- 過剰に変換しない。 純粋にスタイリング/レイアウトのフックとして使用される
<div>は正しいです。すべてにセマンティック要素が必要なわけではなく、強制することはそれ自体が間違いです。 - 推測せずに検証する。 ブラウザのDevToolsでアクセシビリティツリーを確認します — マークアップが生成するランドマークロールが表示され、これは機械が読み取るのと同じ構造です。
HTML SEOハブへの位置づけ
この記事は、親のHTML SEOハブの下にある詳細な記事の1つで、検索エンジンがHTMLをどのように解析して使用するかという広い問題をカバーしています — 見出し階層、HTMLの妥当性、寛容なパーサーが乱雑なマークアップをどのように処理するか。このページはセマンティック要素自体に焦点を当て、それらのトピックはハブとその関連記事に任せることを意図的にしています。セマンティックHTMLは構造化データとも直接連携します:マークアップはスキーマに信頼できる基盤を提供し、両者は補完的な役割を果たします。
FAQ
セマンティックHTMLはSEOに役立ちますか、それともアクセシビリティのためだけですか? 両方です — 検索エンジンがメインコンテンツを識別するのに役立ち、アクセシビリティにも不可欠です。ただし、ランキング要因ではありません。
<article>タグを使用するとランキングが向上しますか? いいえ。Mueller氏によると、それは「Google検索において特別な効果はありません。」
<article>と<section>の違いは何ですか? <article>はフィード内で単独で成立する自己完結型のコンテンツです。<section>は独自の見出しを持つテーマ別のグループです。どちらも<div>の代替ではありません。
ページに複数の<main>要素を含めることはできますか? いいえ — ページごとに<main>は1つだけです。
Googleはページをランク付けするために有効なHTMLを要求しますか? いいえ — ウェブの大部分は有効なHTMLではなく、Googleは「HTML仕様に隠されたセマンティックな意味にほとんど依存できません。」
セマンティックHTMLはセマンティックSEOと同じですか? いいえ — 一方はマークアップであり、もう一方はトピック/エンティティのコンテンツ戦略です。
クリック可能な要素には<a>と<button>のどちらを使うべきですか? その動作によります。URLやフラグメントに移動する場合は<a href>を使用します。現在のページでアクションを実行する場合(送信、トグル、モーダルを開く)は<button>を使用します。スタイルを適用した<div>とクリックハンドラで偽装しないでください。
<section>をネストすると、使用すべき見出しレベルが変わりますか? いいえ。HTML5の古いドキュメントアウトラインアルゴリズム — セクショニングのネストから暗黙の見出しランクを計算するもの — は、どのブラウザやスクリーンリーダーにも実装されたことはなく、現在の仕様もそのようにアウトラインを定義していません。ネストの深さに関係なく、明示的で正しい順序の<h1>〜<h6>を使用してください。
正しいセマンティックHTMLや構造化データはリッチリザルトを保証しますか? いいえ。Google自身の構造化データのドキュメントによると、サポートされているマークアップは特定の検索表示を保証するものではありません — 機能の対象となることは、マークアップが技術的に有効かどうかとは別です。
Evidence for this claim Semantic HTML and search structured data are distinct layers: native elements describe document content and controls, while supported structured-data markup supplies feature-specific machine-readable properties; valid markup does not guarantee a rich result or ranking gain. Scope: supported structured-data features Confidence: high · Verified: Introduction to structured data markup in Google SearchAIまとめ
Advancedバージョンの簡潔な見解:
- セマンティックHTML = 意図された意味のために要素を使うこと(
<main>、<article>、<section>、<nav>、<header>、<aside>、<footer>)— マークアップがコンテンツが 何であるかを表す。CSSは見た目を担当する。 - ランキング要因ではない。 Mueller氏:「魔法の乗数ではない」;
<article>要素は Google検索において「特別な効果はない」。アクセシビリティや明確さのために使うものであり、ランキングポイントのためではない。 - メインコンテンツ抽出に役立つ。 Googleの中心的な注釈は、マークアップに関係なくNLPを介してメインコンテンツを定型文から分離する(Splitt氏)ため、divの羅列でも機能する—しかしセマンティックマークアップは推測の手間を減らす。Splitt氏:「それは私たちの助けにはなりますが、私たちが探している唯一のものではありません。」
- Googleは有効なHTMLを要求しない。 スターターガイド:ウェブの大部分は有効ではないため、Googleは「HTML仕様に隠されたセマンティックな意味にほとんど依存できない」。
- Bingはより強く表現する。 Fabrice Canel氏:セマンティックHTML5は「SEOにおいて優位性」を与える。その差を正直に指摘する—Bingの表現はGoogleより強い;どちらもスコア化されたランキング要因とは呼んでいない。
- 正しい使い方が存在よりも重要:
<main>は1つ;<article>は自己完結型;<section>は見出しを持つテーマ別グループであり、<div>の代わりではない;<nav>は主要なナビゲーションのみ;<aside>は補足的なコンテンツ。 - ランドマーク要素は特定の暗黙のARIAロールに対応する(
<header>→banner、<nav>→navigation、<main>→main、<aside>→complementary、<footer>→contentinfo— ドキュメントレベルでのみ;セクション内にネストされた場合はランドマークではない)。<section>はアクセシブルな名前がある場合のみランドマーク(region)になる;<article>はランドマークではない。 - ドキュメントアウトラインアルゴリズムの神話:
<section>をネストしても、その見出しに暗黙の下位ランクが与えられるわけではない。そのアルゴリズムはどのブラウザやスクリーンリーダーでも実装されたことはなく、WHATWG仕様ももはやそのようにアウトラインを定義していない—明示的な<h1>–<h6>レベルを書くこと。 - ランドマークを超えて: ナビゲーションには
<a href>を使い、ページ内アクションには<button>を使う;表形式データには実際の<table>(<caption>/<th>付き)を使い、<div>グリッドは使わない;画像には目的に基づいたaltテキスト(装飾用はalt="");ネイティブの開閉ウィジェットには<details>/<summary>—公開前にブラウザ/ATレンダリングをテストする。 - AI/LLMの観点(業界の意見): LLMクローラーはJSをレンダリングしないことが多いため、クリーンなセマンティックHTMLはネストされた
<div>よりも解析しやすい(Adams氏、Alderson氏)。 - セマンティックSEO(エンティティ/トピック戦略)と混同しないこと — 同じ言葉でも別のもの。構造化データはセマンティックHTMLを補完するものであり、置き換えるものではない。どちらもリッチリザルトやランキング向上を保証するものではない。
公式ドキュメント
検索エンジンと標準化団体からの一次情報のドキュメントとスタイルガイド。
- SEOスターターガイド — 「重点を置くべきでないもの」セクション(見出し順序やセマンティックな意味の注意点を含む)。
- Googleデベロッパードキュメントスタイルガイド — HTMLとセマンティックタグ付け — 「HTML要素を、設計された目的のために使用する」。
- web.dev — HTMLを学ぶ:セマンティックHTML — ランドマーク要素とそのアクセシビリティロールに関するGoogle自身の学習モジュール。
標準・リファレンス
- MDN — セマンティクス(用語集) — セマンティック要素と非セマンティックなラッパーの正規の定義。
- WHATWG HTML Living Standard — セクション —
<article>、<section>、<nav>、<aside>、<header>、<footer>の定義、コンテンツモデル、および文書のアウトラインの現在の(アルゴリズムに基づかない)定義。 - WHATWG HTML Living Standard — リンク —
<a>要素とハイパーリンクのセマンティクス。 - WHATWG HTML Living Standard — button 要素 — ネイティブの対話型コントロールのセマンティクス。
- WHATWG HTML Living Standard — 表形式データ —
<table>、<caption>、ヘッダーセルとデータ関係のセマンティクス。 - WHATWG HTML Living Standard — 画像 — 目的・文脈に応じた
<img>の代替テキスト要件。 - WHATWG HTML Living Standard — details 要素と summary 要素 — ネイティブの開示ウィジェット。
- MDN — ARIA ロールリファレンス — セクショニング要素の暗黙のランドマークロールマッピング。
- W3C WAI — ページ構造チュートリアル — ネイティブのリージョンと見出しが支援技術のナビゲーションをどのようにサポートするか。
Bing / Microsoft
- Kalicube — HTML5 セマンティックタグ(Fabrice Canel) — Canel のセマンティック HTML5 に関する「SEO 上の利点」という見解の出典。
ソースからの引用
Google と Bing からの公式声明。ソースページが対応している場合、各リンクは引用箇所にジャンプするディープリンクです。
Google — ランキング要因ではない(John Mueller)
- “Semantic HTML does help to understand a page. However, it’s not a magical multiplier for making a website rank higher.” (翻訳) 「セマンティック HTML はページの理解に役立ちます。ただし、ウェブサイトのランキングを上げる魔法の倍率ではありません。」 — John Mueller(Google)、Search Engine Journal 経由。 報道を読む
- “Please use semantic HTML. It’s not a ranking factor, but it can help our systems to understand your content better.” (翻訳) 「セマンティック HTML を使用してください。ランキング要因ではありませんが、当社のシステムがコンテンツをよりよく理解するのに役立ちます。」 — John Mueller(Google)、同じ出典。 報道を読む
Google — <article> 要素について(John Mueller)
- “The
<article>HTML element does not have any particular effect in Google Search.” (翻訳) 「<article>HTML 要素は Google 検索に特別な影響を与えません。」 — John Mueller(Google SEO オフィスアワー)、Search Engine Journal 経由。 報道を読む - “Sometimes there are accessibility or semantic reasons to use a specific kind of markup, so don’t only focus on SEO.” (翻訳) 「特定の種類のマークアップを使用するには、アクセシビリティやセマンティックな理由がある場合があります。SEO だけに焦点を当てないでください。」 — John Mueller(Google SEO オフィスアワー)、同じ出典。 報道を読む
Google — メインコンテンツの抽出(Martin Splitt)
- “We have a thing called the Centerpiece Annotation, for instance, and there’s a few other annotations that we have where we look at the semantic content.” (翻訳) 「例えば、Centerpiece Annotationというものがあり、セマンティックコンテンツを調べるための注釈が他にもいくつかあります。」 — Martin Splitt(Google)、Search Engine Journal経由。 報道を読む
- “We figure out what looks like boilerplate and then, that gets weighted differently as well.” (翻訳) 「定型文のように見えるものを特定し、それも異なる重み付けをしています。」 — Martin Splitt、同じ出典。 報道を読む
- “It does help us, but it’s not the only thing that we look for. Yes.” (翻訳) 「確かに役立ちますが、私たちが探しているのはそれだけではありません。はい。」 — Martin Splitt、セマンティックHTML5がGoogleに役立つかどうかという質問に直接回答。 引用にジャンプ
Google — 有効な仕様のセマンティクスに依存しない(SEOスターターガイド)
- “Having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn’t matter if you’re using them out of order. The web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.” (翻訳) 「見出しをセマンティックな順序で配置することはスクリーンリーダーにとって素晴らしいことですが、Google検索の観点からは、順序を無視して使用しても問題ありません。一般的にウェブは有効なHTMLではないため、Google検索がHTML仕様に隠されたセマンティックな意味に依存することはほとんどありません。」 — Google SEOスターターガイド。 引用にジャンプ
Google — 要素を目的に合わせて使用する(スタイルガイド)
- “Use HTML elements for the purposes that they were designed for.” (翻訳) 「HTML要素は、設計された目的のために使用してください。」 — Googleデベロッパードキュメントスタイルガイド。 出典を読む
Bing / Microsoft(Fabrice Canel)
- Microsoft BingのFabrice Canel氏は、正しく実装されたセマンティックHTML5を含むページは、そうでないページよりもSEOで有利になると述べています。Bingの表現はGoogleの「理解に役立つ」よりも強いものですが、それでもスコア化されたランキング要素として説明されているわけではありません。 言い換えであり、逐語的な引用ではありません。これは一次ソース(Bing)から直接取得したものではなく、二次的な引用(Kalicube)を通じて得られたものです。直接の引用として扱う前に、元の文言を確認してください。 出典を読む
#:~:text=ディープリンクが付いています。その他は出典記事にリンクしています。 このブロックにはどの要素が必要か?
article対section対divの問題(および残りのランドマークの選択)は、スタイルの好みではなく、本物の分岐です。各ステップで正直に答えてください。テストは常に「このコンテンツが実際に何をするのか」であり、「どちらがよりモダンに見えるか」ではありません。
Choosing the right semantic element
やってはいけないこと
これらは、上記の神話が指し示す実際の間違いです。それぞれについて、なぜ間違っているのか、代わりに何をすべきかを説明します。
-
ランキング向上を期待してコンテンツを
<article>で包むこと。 なぜ間違いか:Mueller氏は、この要素は”Google検索において特別な効果はありません。“と述べています。代わりにすべきこと:コンテンツが本当に自己完結している場合(フィード内で単独で成立できる場合)に、アクセシビリティと明確さのために<article>を使用します。SEOの手段としてではありません。 -
セマンティックHTML全般をスコア化されたランキング要因として扱うこと。 なぜ間違いか: それは”魔法の倍率ではない”ため、追い求めるスコア化されたシグナルはありません。代わりにすべきこと: その作業を、実際の(ランキングとしては測定不能でも)見返りがある理解・アクセシビリティへの投資として予算化し、期待される向上を見込むランキングプロジェクトとしては扱わないこと。
-
Googleのために完璧な見出し順序や厳密な妥当性にこだわること。 なぜ間違いか: Google自身のスターターガイドは、“ウェブ全般は有効なHTMLではないため、Google検索がHTML仕様に隠されたセマンティックな意味に依存することはほとんどない。“と述べています。代わりにすべきこと: 見出しの順序と妥当性を、スクリーンリーダーとユーザーのために修正すること — それが実際に重要となる場所です — Googleがそれをスコアリングしているからではありません。
-
「よりモダンに感じる」という理由で
<section>を<div>の代替として使うこと。 なぜ間違いか: 見出しのない<section>はテーマ別のグループではなく、装飾にすぎません — これはこの要素の最も一般的な誤用です。代わりにすべきこと: ブロックが独自の見出しなしでは意味をなさない場合は、<div>を使用すること。 -
セマンティックHTMLとセマンティックSEOを混同すること。 なぜ間違いか: 一方はマークアップ構造であり、もう一方はトピック・エンティティのコンテンツ戦略です — これらを混同すると、実際の目標に対して間違ったものを最適化することになります。代わりにすべきこと: この2つを分けておくこと。この記事は要素のみについて扱います。
-
構造化データがすでに存在するという理由でセマンティックHTMLを省略すること。 なぜ間違いか: JSON-LDはdivスープを修正せず、構造化データはマークアップ構造の代わりにはなりません。代わりにすべきこと: 両方を使用すること — 構造化データはセマンティックな基盤の上に載るものであり、それを置き換えるものではありません。どちらもリッチリザルトを保証するものではなく、それはマークアップの妥当性とは別の適格性の問題です。
-
見出しを「あたかも」下位レベルであるかのように機能させるために
<section>要素をネストすること。 なぜ間違いか: これはHTML5の古いドキュメントアウトラインアルゴリズムに依存していますが、そのアルゴリズムはどのブラウザやスクリーンリーダーも実装したことがなく、現在のWHATWG仕様でもそのように定義されていません。代わりにすべきこと: 明示的で正しい順序の<h1>〜<h6>レベルを記述すること — 実際に意図する見出しのランクの代わりにネストの深さを使わせないでください。 -
<a href>や<button>の代わりにクリックハンドラ付きの<div>を使用すること。 なぜ間違いか:role、tabindex、キーハンドラで両方を手動で再構築しない限り、ネイティブなキーボード操作と正しいアクセシブルなロールを失います。代わりにすべきこと: アクションがどこかにナビゲートする場合は<a href>を、現在のページで何かを行う場合は<button>を使用すること — そしてネイティブな動作を無料で手に入れましょう。
ランドマーク要素の概要
この記事で取り上げる7つの要素、それぞれが実際に何のためにあるのか、そして避けるべき誤用パターン。
| 要素 | 用途 | よくある誤用 |
|---|---|---|
<header> | 導入コンテンツ — サイトバナー、または記事・セクション自体のタイトルや著者名 | 実際には導入ではないコンテンツに使用する |
<nav> | 主要なナビゲーション — プライマリメニュー、パンくずリスト、ページ内目次 | すべてのリンクの集まり(関連記事リストなど)を<nav>で囲み、シグナルを薄める |
<main> | ページの単一の主要かつ固有のコンテンツ | <main>を複数持つ、または<article>/<aside>/<header>/<footer>/<nav>の中に入れ子にする |
<article> | フィード内で単独で成立する自己完結型コンテンツ(投稿、商品カード、コメント) | ランキングを上げるためだけに使用する — Mueller氏によれば「特に効果はない」 |
<section> | 独自の見出しを持つテーマ別のコンテンツのグループ | 見出しも実際のテーマもない汎用の<div>の代わりとして使用する |
<aside> | 付随的なコンテンツ — サイドバー、プルクォート、関連リンクボックス、広告 | 実際に二次的な内容だからではなく、視覚的に横にあるというだけで使用する |
<footer> | 締めくくりのコンテンツ — サイトフッター、または記事・セクション自体のタグやメタデータ | ブロックの下部にあるものなら何でも置く場所として扱う |
簡単な目安: ブロックが単独でシンジケーションできるなら<article>、見出しがないと意味が通じないなら<section>、どちらでもなければ<div>です。
ランドマークを超えて: インタラクティブ要素とデータ要素
| 要素 | 用途 | よくある誤用 |
|---|---|---|
<a href> | URLやフラグメントへの移動 | スタイルを適用した<div>/<span>とURLを変更するクリックハンドラでリンクを偽装する |
<button> | 現在のページでのアクション(送信、トグル、開く) | スタイルを適用した<div>でボタンを偽装する — ネイティブのキーボード操作とロールが失われる |
<table> | 実際の表形式データ(<caption>/<th>付き) | 実際のデータではなくページレイアウトに使用する(またはそれを装った<div>グリッド) |
<img alt="..."> | 画像が何を示しているかの説明(その画像が存在する理由に基づく) | キーワードを詰め込んだaltテキスト、または装飾画像でのalt=""の欠落 |
<details>/<summary> | JavaScript不要のネイティブな開閉ウィジェット | ネイティブ要素を使わずに<div>+JavaScriptでアコーディオンを再構築する |
HTML改修のためのプロンプト
この記事が扱う特定のタスク(divスープの発見と正しいセマンティックマークアップへの変換)のための、そのまま使えるプロンプトです。ページのHTML(レンダリングされたDOMではなく、ソース表示)を以下のいずれかと一緒にAIアシスタントに貼り付けてください。
divスープを指摘し、置き換えを提案する
Here is the HTML for one of my pages. Identify every <div> or <span> that is standing
in for a semantic landmark, and suggest the correct replacement element from this list:
header, nav, main, article, section, aside, footer. For each suggestion, explain which
test it passes (e.g. "this could stand alone in a feed, so it's an <article>" or "this
has its own heading and one theme, so it's a <section>"). Flag any block that should
stay a <div> because it's purely a styling/layout hook.
[paste HTML here]ランドマークの構造エラーをチェックする
Review this page's HTML for these specific structural mistakes: more than one <main>
element, a <main> nested inside <article>/<aside>/<header>/<footer>/<nav>, a <nav>
wrapping something that isn't major navigation, or a <section> with no heading. List
each problem found with the line/snippet and the fix.
[paste HTML here]改修の優先順位を決める
Given this page's HTML, tell me which landmark to fix first for the biggest
accessibility and main-content-extraction benefit: establishing <main>/<header>/
<footer>/<nav>, converting self-contained blocks to <article>, converting themed
groups to <section>, or moving sidebars to <aside>. Order the fixes and say what
"done" looks like for each.
[paste HTML here] ランドマークが意図した構造と一致している
実行するテスト: 改修後のページでブラウザのDevToolsアクセシビリティツリー(Chrome/Edge: DevTools → Elements → Accessibilityペイン)を開きます。
期待される結果: リストされたランドマークロール(banner、navigation、main、complementary、contentinfo)が、実際に書いたセマンティック要素と一致している — main/“main”ロールが1つ、bannerが1つなど。
失敗の解釈: ランドマークロールが欠落または重複している場合、マークアップが意図した構造を生成していないことを意味します(例: 2つ目の<main>、または変換されるべきだった<div>)。
監視期間: 即時 — 改修のデプロイ直後に確認します。
ロールバックのトリガー: main/“main”ランドマークが複数ある、またはランドマークが不適切な場所に入れ子になっている(例: article内のmain)場合は、元に戻してマークアップを再確認します。
ページごとに<main>は正確に1つ
実行するテスト: レンダリングされたHTML(またはソース表示)に対してgrep -o "<main" page.html | wc -lを実行するか、DevToolsのElementsパネルで<mainを検索します。
期待される結果: 正確に1件の一致。
失敗の解釈: 0件の一致はプライマリコンテンツのランドマークが設定されていないことを意味し、複数の一致はメインコンテンツに関する「最も明確な単一シグナル」が曖昧になっていることを意味します。
監視期間: デプロイ時に即時。
ロールバックのトリガー: 正確に1つ以外の数。
レンダリングしないクローラーも構造を認識する
実行するテスト: プレーンなHTTPクライアント(curl または「ページのソースを表示」、レンダリングされたDOMではない)でページを取得し、セマンティック要素が生のレスポンスに存在することを確認します。クライアントサイドのJavaScriptによって後から注入されるものではありません。
期待される結果: <header>、<nav>、<main>、<article>/<section>、<aside>、<footer> がすべて初期HTMLペイロードに含まれていること。
失敗の解釈: セマンティックタグがJS実行後にのみ表示される場合、JavaScriptをレンダリングしないクローラー(上記のAI/LLMクローラーの点を参照)は構造をまったく認識できません。
監視期間: 即時 — テンプレートやJSフレームワークがページのレンダリング方法を変更するたびに再確認します。
ロールバックのトリガー: セマンティックランドマークがレンダリングされたDOMには存在するが、生のHTMLレスポンスには存在しない場合。
見出しレベルは明示的であり、ネストから継承されない
実行するテスト: ブラウザのDevToolsアクセシビリティツリー(またはアウトライン確認拡張機能)で、見出しレベルをドキュメント順にリストし、各見出しがネストされた <section>/<article> 要素内にどれだけ深く配置されているかに関係なく、ソース内の実際の <h1>–<h6> タグと比較します。
期待される結果: 各見出しの報告される見出しレベルが、そのリテラルなタグと一致すること(<h2> は、いくつのセクションにネストされていてもレベル2として報告される)— ネストによる暗黙の降格はありません。
失敗の解釈: テンプレートやコンポーネントライブラリが <section> のネストに依存して見出しのランクを「自動的に」下げている場合、その前提は成立しません — 古いドキュメントアウトラインアルゴリズムは実装されたことがなく、現在の仕様はそのようにアウトラインを計算しません。実際の見出しタグを修正してください。
監視期間: 即時、および新しいテンプレートやコンポーネントパターンがネストされたセクションを導入するたび。
ロールバックのトリガー: 見出しのレンダリング/アナウンスされるレベルが、リテラルな <h1>–<h6> タグと一致しない場合。
偽のリンクと偽のボタンはキーボードでアクセス可能であること
実行するテスト: キーボードのみを使用してページをタブ移動し、Enter/Spaceですべてのクリック可能な要素をアクティブにしてみてください。別途、アクセシビリティツリーで各クリック可能な要素が報告するロールを確認します。
期待される結果: ナビゲートする要素は link(ネイティブの <a href>)を報告し、ページ上で動作する要素は button(ネイティブの <button>)を報告し、両方とも追加の role/tabindex/キーハンドラーコードなしでキーボードから到達可能かつアクティブ化可能であること。
失敗の解釈: クリックハンドラーを持つ <div> または <span> がキーボードから到達できない、または link/button の代わりに汎用ロールを報告する場合、ARIAでパッチを当てるのではなく、ネイティブ要素に変換する必要があります。
監視期間: 即時 — インタラクティブ要素へのコンポーネントライブラリやデザインシステムの変更後に再確認します。
ロールバックのトリガー: キーボードだけで到達またはアクティブ化できないクリック可能なコントロールがある場合。
自分でテスト: セマンティックHTML
セマンティックHTMLとそれがSEOに与える影響(および与えない影響)に関する5つの簡単な質問。各質問に回答を選び、確認してください。
変更履歴
2026年7月18日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。