リストを「ただの箇条書き」で終わらせるな：Schema.org ItemListで検索エンジンに文脈を伝える技術
フロントエンド開発の現場で、`ul`や`ol`タグを使わない日はありませんよね。しかし、多くのエンジニアが「見た目のリストを作ること」に終始し、そのコンテンツが持つ「情報の序列」を検索エンジンに正しく翻訳できているかという点については、意外と無頓着です。
単なるマークアップで終わらせるか、検索エンジンに「これはランキングや順序立てられた価値ある情報だ」と明示するか。この差が、SEO的なパフォーマンスや、リッチリザルトという形で検索結果に現れる「クリック率」に直結します。
今日は、中級エンジニアの皆さんに、Schema.orgの`ItemList`を使ってリストを構造化データへと昇華させる、実務的なアプローチを伝授します。
—
ブラウザとクローラー、両方の視点を持つ
まず、大前提を整理しましょう。ブラウザは`ul`や`ol`を見て「ここはリスト構造だな」と理解し、ユーザーにインデントやマーカーを表示します。しかし、検索エンジンのクローラーは、そのリストが「おすすめのカフェランキング」なのか、「単なる注意書きの羅列」なのかを、文脈だけで判断しなければなりません。
ここで登場するのがSchema.orgのItemListです。これは、リストの内容が「順序づけられたアイテムの集合体である」ことを機械に伝えるための共通言語です。
特に、`ol`タグのように「順序に意味がある」コンテンツに対しては、`ItemList`を適切に適用することで、Google検索結果でリスト形式のプレビューが表示される可能性（リッチリザルト）を大きく引き上げることができます。
—
実践：JSON-LDで「リスト」を定義する
構造化データの実装において、今やJSON-LD一択です。HTML内に直接記述しても良いですが、管理のしやすさを考えれば、リストと構造化データは「密結合しすぎない」のがベストプラクティスです。
以下は、あるWebサービスで「フロントエンド学習のロードマップ」を想定した、実務でそのまま使えるサンプルコードです。
ここがプロのポイント
1. positionの整合性: JSON-LD内の`position`と、HTMLの物理的な順序は一致させること。ここがズレていると、検索エンジンは「構造化データが不正確である」と判断し、無視する可能性があります。
2. アクセシビリティとの両立: `ol`タグを使うことで、スクリーンリーダー利用者は「これは3段階の順序があるコンテンツだ」と正しく認識できます。構造化データは検索エンジン用、HTMLはユーザー用。この役割分担を意識してください。
3. URLの正規化: `url`プロパティには、必ず絶対パス（`https://…`）を指定してください。相対パスは構造化データとしては非推奨です。
—
よくある落とし穴：DL（記述リスト）は構造化すべきか？
現場でよく議論になるのが、「`dl`, `dt`, `dd`タグ（記述リスト）も構造化データにすべきか？」という点です。
結論から言うと、`dl`は「項目と定義」のペアであり、ランキングのような`ItemList`とは相性が良くありません。もし`dl`の内容を構造化したいなら、`ItemList`ではなく、`FAQPage`や`Product`（仕様項目）など、そのデータの意味合いに応じた別のスキーマタイプを検討すべきです。
「何でもかんでもItemList」にするのではなく、「これは順序に意味があるアイテムの集合か？」という問いを常に持つこと。これが、無駄な実装を避け、精度の高いSEOを実現するコツです。
—
まとめ：次にやるべきこと
今日紹介した`ItemList`の実装は、単なるSEO対策を超えた「コンテンツの品質証明」です。
実装が終わったら、必ずGoogleの[「リッチリザルト テスト」](https://search.google.com/test/rich-results)ツールを通してください。エラーが出ていないか確認するのはもちろんですが、「機械が自分の意図した通りに情報を読み取っているか」を視覚的に確認する癖をつけましょう。
フロントエンドエンジニアの仕事は、画面を描画して終わりではありません。その情報が、検索エンジンという「巨大な図書館」にどう格納されるかまで設計してこそ、一人前と言えるのではないでしょうか。
明日からのコーディングで、ぜひ「意味のあるリスト」を意識してみてください。では、また現場で会いましょう。
コメント