「SEOに強いHTMLの書き方」についての個人的な見解
「SEO に強い HTML の書き方」というツイートがそこそこバズっていて、その内容に対して駆け出しエンジニアの方たちが「参考になった」などと称賛の声を挙げていたのを見かけて思うところがあったのでこの記事を書きました。
元ツイの概要は次の通り。
- body > main > article > sectionに
- h1は 1 ページに 1 つ（要キーワード）
- 見出しタグは毎度 section で囲む
- ヘッダーメニューは nav で囲む
- 画像に適切な alt を設定する
- title / description を書く
- 階層を意識して書く
- div はあまり使わない
- 画像は p で囲む
この記事は元ツイおよび元ツイの投稿者を批判する意図で書いたものではなく、あくまで挙げられている内容に対する個人的見解をまとめたものです。 正しいか正しくないかをそれぞれの項目のはじめに書いていますが、あくまで僕個人の考えであってデファクトスタンダードではないことはご理解ください。
加えて「SEO に強い」とはあるものの、 挙げられている内容の多くがページ評価には「直接は」影響しない(結論) と考えているので、別視点からの見解が多く含まれていることをご了承お願いします。
body > main > article > section に
入れ子ルールには間違いはないが、コンテンツによっては必ずしも正しいとは限らない。
- section の中に article を含めても構わない。
- article は仕様によればサイトの中で完全もしくは自己完結した構造を表すため、コンテンツによっては article を利用することが不適切な場合もある。
- ただし、それが「サイトの中で完全もしくは自己完結した構造」かどうかは実装者の価値観に委ねられるところもあり、その article の利用が正しいか正しくないかの判別は各々の価値観に影響してしまうこともあり難しい。
- 現在の HTML の仕様の article の項目には 「ページの主要コンテンツがすべての 1 つの自己完結型の組成物である場合、そのコンテンツは article でマークしても良いが、その場合は技術的に冗長である」 との記述がある。
- ただし、冗長なだけであって禁止されているわけではないので、何か意図がある場合には主要コンテンツが 1 つの自己完結型の組成物であっても article で囲っても問題はないと思う。
- 一部の支援技術は article で囲んだ要素の開始・終了を読み上げることも考慮する。
仮に article と section を両方使うとなったら僕もbody > main > article > sectionのようにマークアップすると思うし、これに関しては問題はないと思う。あと、ランドマークやセクショニング要素を積極的に使おうとする姿勢は褒めるべき。
h1 は 1 ページに 1 つ（要キーワード）
なんとも言えない。「h1 は 1 ページに 1 つでなければならない」という文脈なら間違い。「個人やチームで h1 は 1 ページに 1 つというルール付けをしている」のなら正しい。どちらにせよ h1 はほぼほぼ SEO には影響しないものだと思っている。
- 現在の HTML の仕様では複数の h1 要素の利用が許容されている。
- Google のジョン・ミューラー氏はウェブマスター向けの動画で 「 h1 はページの中で好きなだけ使っていいし、あってもなくても検索には影響はない」 という旨を語っている。
- Zenn を立ち上げた catnose(@catnose99)氏は以前『Zenn に必要な SEO 対策』という記事(現在は削除されてます)にて、順位が安定している数十記事の h2 をすべて h1 に切り替えてその後の検索順位の検証を行ったところほとんど影響がなかったと述べている。
- 同様の実験をした記事においても統計的に有意な差は見られなかったという結果もある。
現在の仕様で認められているやり方で、かつ Google 自体が公に h1 は検索には影響はないと発表しているのにも関わらず、もし現在でも h1 は SEO に関係しているとなったらGoogle には失望する。
ただし、あくまで SEO に影響しないというだけであって見出し設計そのものは重要。見出しはアクセシビリティに大きく影響するため。
- 先程の Google のジョン・ミューラー氏はウェブマスター向けの動画で h1 の利用について検索には影響は無いとしつつ 「ユーザビリティの観点から見ると、改善するほうが理にかなっているかもしれない」 と述べている。
- 支援技術利用者の多くは見出しジャンプ機能を利用して Web サイトを利用している。WebAIM のアンケート結果によると約 7 割の方が利用しているそう。
- 支援技術は見出しを明確に読み分ける。
また、検索エンジンはtitle 要素が見つからなかった場合は h1 を代用として使うこともあるという点も留意したほうが良い。つまり、h1 とタイトルが同じような内容になるのは問題ではないし、あくまで責務が違うだけで役割は一緒だと思っている。
h1 をロゴに指定するのはどうなんだ論争が Twitter で定期的に勃発するのでついでに自分の考えを述べておくと、トップページのサイトタイトルとロゴの文言が同じなら h1 はロゴに指定したほうが良いというのが個人的な見解。加えて、支援技術利用者の 6 割が「ページタイトルを h1 に指定するのが好ましい」というWebAIM のアンケート結果もある。もちろん、ここらへんは各々の価値観に依るのでこれが正解・不正解とかは無い。
あとは、チーム内のコーディング規約的に複数の h1 要素を許容しないほうが見出し設計の引き締めに貢献できる可能性はある。
参考サイト
見出しタグは毎度 section で囲む
これは間違い。見出しを毎度 section で囲む必要は無い。
仮に見出しを毎度 section で囲むとなったら、以下のマークアップはアウトライン的に意図しない構造になってしまう。
<main>
<section>
<h1>会社概要</h1>
</section>
<section>
<h2>社長による挨拶</h2>
</section>
</main>
section や article を利用する場合は見出しを含めることが推奨されている(※念の為に触れておくと section の中に見出しがなくても仕様違反ではない)が、見出しだけでも暗黙的にアウトラインが形成されるため必ずしもセクショニングコンテンツで囲む必要はない。
ただし、基本的には暗黙的なアウトラインは避けて明示的にしたほうが良い。
例えば以下のマークアップだと注釈は「本日のイベント」の持ち物であることが望ましいが、section を無くして暗黙的に形成すると「ビンゴ大会」の持ち物になってしまう。
<section>
<h2>本日のイベント</h2>
<section>
<h3>くじびき</h3>
<p></p>
</section>
<section>
<h3>ビンゴ大会</h3>
<p></p>
</section>
<p>※非常事態宣言を受けてイベント終了時刻は20時となります。</p>
</section>
ヘッダーメニューは nav で囲む
SEO には直接影響しないとは思いつつ、多くの場合においてこれは正しい。
- ナビゲーションを nav で囲うことでドキュメント内の主要なナビゲーションだと解釈することができるようになる。
- ナビゲーションを nav で囲うことで支援技術のランドマークジャンプ機能を用いて利用者はそこへジャンプすることが可能となる。
- ナビゲーションを nav で囲んでいない場合、既に訪れたサイトでヘッダーの内容を読み上げる必要が出てしまう。
nav 要素にはaria-labelもしくは不可視の見出しを含めた上でaria-labelledbyでラベル付けすることを推奨する。ラベル付けをすることでその nav 要素が「何のナビゲーションなのか？」を支援技術利用者に伝えることができるため。このラベルはジャンプ機能でも読み上げられるので、ドキュメント上に nav 要素が複数あっても目次となるメインメニューを的確に選択できるようになる。
<nav aria-label="サイト内メニュー">
<ul>
<li></li>
<li></li>
</ul>
</nav>
<nav aria-labelledby="aria-global-nav">
<h2 id="aria-global-nav" class="visually-hidden">サイト内メニュー</h2>
<ul>
<li></li>
<li></li>
</ul>
</nav>
後者のマークアップの場合は見出しジャンプ機能でもナビゲーションへジャンプできるため、より親切な設計かもしれない。
また、ヘッダーのナビゲーションとは違うが、パンくずリストも「現在位置」等とラベリングした上で nav 要素で囲んでおくと良いだろう。
<nav class="breadcrumb" aria-label="現在位置">
<ol class="breadcrumb__list" itemscope="itemscope" itemtype="http://schema.org/BreadcrumbList">
<li class="breadcrumb__item" itemprop="itemListElement" itemscope="itemscope" itemtype="http://schema.org/ListItem">
<a class="breadcrumb__link" href="#" itemprop="item">
<span itemprop="name">ホーム</span>
</a>
<meta itemprop="position" content="1" />
</li>
<li class="breadcrumb__item" itemprop="itemListElement" itemscope="itemscope" itemtype="http://schema.org/ListItem">
<a class="breadcrumb__link" href="#" itemprop="item">
<span itemprop="name">会社概要</span>
</a>
<meta itemprop="position" content="2" />
</li>
<li class="breadcrumb__item" itemprop="itemListElement" itemscope="itemscope" itemtype="http://schema.org/ListItem">
<a class="breadcrumb__link" href="#" itemprop="item" aria-current="page">
<span itemprop="name">業務内容</span>
</a>
<meta itemprop="position" content="3" />
</li>
</ol>
</nav>
画像に適切な alt を設定する
これは正しい。ただし、検索エンジン意識というよりかは支援技術を利用して訪れているユーザーに「その画像がどういった画像なのか？」という画像の意図を伝えるアクセシビリティ面が大きい。何かしらの事情で画像が読み込めなかった場合には alt 属性に指定した代替テキストが表示されることも意識したほうが良い。
ただし、SEO 目的でその画像が本来持っていない情報を alt 属性で持たせたり、過剰にキーワードを持たせるのは NG。
- 画像が持つ情報が過不足なくユーザーに伝わるように記述する。「イメージ 1」「画像」のような alt 属性だったら無いほうが良い。
- 前後の文脈を含めて読み上げたときに自然な文章になるように記述する。
- 画像を説明するキャプションが続く場合は、alt 属性を空にするなどしてキャプションと重複しないようにする。
- 「〜の写真」「〜の様子」といった具体的な説明をする。
- 「写真:」や「グラフ:」といった接頭詞を付与して、画像の種類を伝える。
- テキストを画像化した場合は、そのテキストをありのまま alt 属性に指定する。文章を加える・削るといった行為はしない。
- 5 段階評価のスターなど、グルーピングされた画像はグループの一つの画像に代替テキストを提供してそのグループの全ての画像を説明する。
- クリッカブルマップは img 要素で全体の説明を行い、area 要素で各リンク先の説明を記述する。
装飾目的の画像やユーザーにイメージを膨らませるために用いる画像など、代替テキストが不要な場合でも空の alt 属性を指定して alt 属性自体は省略しないようにする。alt 属性が無いと支援技術は画像パスを読み上げてしまうため、支援技術を利用しているユーザーにとっては非常に使いにくいサイトになってしまう。
個人的な見解としては alt 属性の記述をコーダーに任せるのではなく、他のテキストと同様にコンテンツのライターが書いた方がいい気がする。
参考サイト
- alt 属性の良い事例(つけ方・書き方)｜情報バリアフリーポータルサイト
- 正しいイメージタグの扱い方をレクチャー｜ HI-ROKI ｜ note
- 世界一「雑」に説明するセマンティック・マークアップの手順（3）｜にゃんこ@マークアップの人｜ note
title / description を書く
これは正しい。discription の有無はページの評価には影響しないものの、リザルトを育ててクリック率を上げるという意味では検索最適化である。
title について
- 多くの支援技術は最初にページのタイトルを読み上げる。タイトルが適切でなかったり、指定されていない場合は訪れた際にそのページが目的のページかどうかが判断できなくなる可能性がある。
- タイトルが指定されていない場合は検索エンジン側でタイトルを生成するため、意図しない検索結果になる可能性もある。
- ぺージのタイトルは Web ブラウザのブックマーク登録の際にも使われることを意識する。
- Goolge の検索結果に表示されるタイトルの文字数には制限があるため、日本語で 30〜33 文字程度で記述するのが理想的。
description について
- 文字数が約 120 字と制限があるため、description の内容は 120 字以内に収まるようにしておくと良い。
- description だけに限らないけれど、重要なことはなるべく先頭に書いた方が良い。文章を最初の方しか読まないで判断する人も多いため。
Twitter 見てるとツイートの最初の部分しか読まないでマウント取ってきたりする人多いでしょ？
参考サイト
- アクセシビリティガイドライン > 15. ページのタイトル(title 要素)は、ユーザーがページの内容と役割を識別できるものを付ける。 ： 三井住友銀行
- HTML の<head> – どんなことを書くの？【テンプレコード付き】 | webliker
階層を意識して書く
これは正しい。アウトラインの大切さについては「見出しタグは毎度 section で囲む」の項目で触れたとおり。
特にコメントすることはない。
div はあまり使わない
言い方が良くない。div の数が SEO に影響するなら、多くの Web サイトは SEO でマイナス評価になってしまう。
適切な意味のあるタグを使った上で、どれにも当てはまらない場合は最後の手段として div を使うとするならば正しい。このことは仕様書にも「他の要素が適切でない場合、著者は最後の手段の要素として div 要素を検討することを強く推奨する。div 要素の代わりにより適切な要素を使用することは、読者に対してより良いアクセシビリティと著者に対するより容易なメンテナンス性につながる。」と書かれている。
過去ツイでも触れたが、僕は初めは div や span を封じてマークアップを行い、CSS 設計をする段階(レイアウトを実現するための HTML を追加する段階)で div や span の利用を解禁している。こうすることでセマンティックなマークアップを保ったまま思う存分 div や span を使うことができるようになる。
あとは過去の投稿でも触れたが、CSS 設計的には div や span が増えることを気にしないほうが良い。
本当に不要な div や span は淘汰すべきではあるが、HTML は情報構造に意味づけを主とする言語。レイアウトや装飾にも紐付いているので、コンポーネントそのものとコンポーネントを配置するレイアウトの要素で分けるなど、あえて div と span を増やして冗長にコーディングすることも大切である。
確かに div を極限まで減らしてシンプルに書いた方が HTML の見た目はすっきりだろう。しかし、要素を減らすことで減った要素が持っていたスタイリングのルールを残った要素に受け継ぐこととなり、要素それぞれが持つ責任が重くなる。それゆえ保守性や拡張性に影響が出るかもしれない。
意味のある div や span なら積極的に使おう。要素の持つスタイリングの責任は分散しよう。何度も言うようだけれど将来の予期せぬ変更を意識した冗長なコードは保守性につながる。
むしろ、タグの数を一つでも減らしたいという理由で不安定で保守性や拡張性の低いスタイル指定をしてしまうことを避けるべきだ。
div や span が少ないコードは美しいという風潮があるが、そういったコードに限って保守や運用が困難なパターンが多い。HTML のリファクタリングよりも CSS のリファクタリングのほうが圧倒的に難易度が高いということは意識しておいたほうが良い。
SEO にはあまり関係ない。
画像は p で囲む
画像を p で囲むことには問題はないが、言い方に語弊があるという印象。
- 必ずしも画像を p で囲む必要はない。コンテンツ・モデルに違反していなければ何で囲っても OK。
- もっと言えば、img 要素は何かしらのタグで囲まずに裸のまま置いても問題はない。
- ある画像がある段落の内容の一部 or 全部であればその画像を p で囲めば良い。
- ある画像がコンテンツの注釈として用いられ、その画像があっても無くても困らない場合は figure で囲めば良い。ただし、alt 属性に適切な代替テキストを記述した場合に限られる。
- ある画像が装飾目的のものであれば空の alt 属性を指定した上で div や span で囲む、もしくは裸のまま置いておけば良い。
- 要は画像を置いた後に文脈に合わせて適切なタグで囲む・囲まないかの判断をすればいいと思う。
HTML とは関係ない話ではあるが、ブロック的な画像は何かしらで囲っておいたほうがスタイリングしやすくなるため僕自身は画像を裸のまま置くことはあまりない。CSS 無効時の見た目も気になるし。
あと、これは多分偉い人に怒られそうだけど、高度なセマンティクスな HTML は更新する人のスキルが疎らな場合、それがかえって厳しいルールとなってそのルールを守るためにある程度の知識が更新者に必要になるため注意。コピペして済ましてしまう人も多く、知識に乏しい人や仕事がいい加減な人が更新する場合にはセマンティクスが裏目に出ることがあるということを意識しておくと良いかもしれない。
なので、なんか危なさそうな感じの人が更新する可能性がある場合には figure とか複雑な要素は使わずに更新者の選択肢を絞れるところまで絞るために敢えて div で囲んでおくのも一つの方法だと思う。
でももちろん良くないと思うので、何かいいアイデアを持っている人がいたら教えてほしい。
SEO にはあまり関係ない。
個人的な結論
- 一番の SEO はユーザーに利益があるサイトを作ることだと Google エンジニアが仰っていた。
- マークアップそのものは検索順位には直接は影響しないものだと思っている。
- SEO に影響しないならマークアップは適当では良いかと言われるとそんなことはない。マークアップそのものは至極大切。
- マークアップはアクセシビリティに影響するものが多く、マークアップを尊重するか否かでユーザーの機会損失を防げる可能性がある。
- 実装者が「ユーザーに利益があるサイト」を作るためにできることは、しっかりとしたマークアップを施してユーザビリティやアクセシビリティを万全とすること。
- もちろん肝心のコンテンツが微妙ならダメだけど、ユーザビリティやアクセシビリティが優れたWebサイトは「ユーザーに利益があるサイト」と認められて検索順位に間接的に影響するかもしれない。
- マークアップを疎かにするメリットが無いから、SEO 抜きにしてもしっかりやっといたほうがいいとは思う。
個人的には SEO を第 1 にコンテンツ制作やマークアップを行うのではなく、多くのユーザーにとって利益のある Web サイトを作ることを第 1 にして、その結果 SEO も施されているというのが理想形だと思う。だから SEO を考えないことが SEO なのかも知れない（語彙力不足）。
今回の「SEO に強い HTML の書き方」で挙げられた項目はSEOを焦点にした場合は疑問はあるものの、セマンティクスやアクセシビリティ面を考慮したら一部引っかかる点こそあれど、しっかり説明付ければ言っている自体は至極まっとう…なのかもしれない。説明が足りなかっただけだと思うし、SEO を焦点に当てなければ荒れはしなかっただろう。
あとは実装者にできる SEO は Search Console のエラーを地道に潰すことくらい。
駆け出しエンジニアに伝えたいこと
例の「SEO に強い HTML の書き方」ツイートには多くの称賛のリプや引用 RT が駆け出しエンジニアの方から寄せられていましたが、そういった方々は流れてくる情報を盲信するのではなく「どうしてそれが SEO に効果があるのか」などをしっかり調べてから判断する癖をつけておくと良いと思います。
これは僕のツイートや記事にも言えることで、この記事にも間違いがあるかもしれませんし、皆さんにとって正しい内容ではないと思います。大切なのは、誰かが発信した情報を思考停止で鵜呑みにするのではなく、自分で理解を深めようとアクションを起こすことだと思います。この記事にも「僕の解釈を含んだ情報」が多く含まれていますからね。
僕含めて人間誰でも誤った情報を発信してしまうことはありますし、それは仕方がないものだと思っています。ただ、そういった情報が自分にとって正しいものなのかどうか、それを見抜く鑑識眼を身に着けて欲しいと駆け出しエンジニアの方にそっと伝えておきます。
Discussion