検索結果に表が出ない—divの疑似テーブルをtableに直す
丁寧に比較表を作った。なのに検索結果に出てくるのは、本文の途中の一段落だけ。——表そのものが引かれない理由は、中身より先にその表がHTMLの表として書かれていないことを疑う価値があります。
見た目は表。中身は <div> の入れ子。CSS の grid や flex で列を揃えているだけ、という作りです。画面上ではきれいに整います。けれどHTMLとしては、行も列も見出しセルも宣言されていません。人間の目には表でも、読み取る側には「連続したテキストのかたまり」に見えている可能性がある、ということです。
先に結論を言います。tableに直したから強調スニペットに出る、という話ではありません。自分のページを強調スニペットとして設定することはできない、とGoogleは明記しています。それでも直す価値があるのは、抜き出される側の形を整えるのが、こちらにできる数少ないことだからです。
強調スニペットは「選ばれる」もので、申請できない
強調スニペットは、検索結果の一番上に回答が書かれたボックスとして表示される枠です。表示される場所は一箇所ではありません。Googleの案内では、検索結果の一番上のほか、「他の人はこちらも検索」セクション内、ナレッジグラフ（ページの右側の情報）の横にも表示されるとされています。
選ばれ方についてGoogleはこう書いています。強調スニペットはGoogleが検出したウェブサイトから生成され、回答の適切さと有用性に基づいて選択される。そして、ユーザーの求めている回答がウェブサイトの短い文章の中で見つかるとGoogleが判断した場合に表示される、と。
では、こちらから「この表を使ってください」と指定できるのか。できません。検索セントラルの「自分のページを強調スニペットとして設定できますか？」という項目への答えは、はっきり「それはできません」です。ページの内容が強調スニペットにふさわしいとGoogleのシステムが判断すれば上位に表示される、という説明が続きます。
ここは押さえておいてください。マークアップは申請書ではありません。
「ページのどこか」までは特定されている
一方で、見落としやすい挙動がひとつあります。ユーザーが強調スニペットをクリックすると、強調スニペットに表示されているページのセクションに直接移動する。スニペットに表示されている位置まで自動的にスクロールし、サイト側でアノテーション（目印の注釈）を追加する必要はない、とGoogleは説明しています。ブラウザがその技術に対応していない場合など、うまく飛ばない例外はあるとも書かれています。
つまり、抜き出す側はページ全体をひとかたまりで見ているのではなく、どの部分を引いたかを保持しているわけです。ここから先はこちらの推論になりますが、部分として切り出しやすい形になっているかどうかは、無関係ではないだろうと考えられます。
構造は「必須」ではない。それでも整える理由
誤解のないように、公式が言っていないことは言わないでおきます。SEOスターターガイドは、サイトの構成について「今すぐ整理し直す必要はありません」とし、サイトが整理されていなくても、おそらくそのままの状態で検索エンジンが把握してくれるとまで書いています。これはサイト全体の構成についての話で、表のマークアップに直接触れたものではありません。裏を返せば、divで組んだ表が必ず無視される、と言い切れる材料もこちらにはない、ということです。
同じガイドが推奨しているのは、読みやすさの側からの構造化です。長い文章は段落や章などに分け、全体を見通せるように見出しを付けてください——これは検索エンジンのためというより、まず文章として整理せよ、という趣旨で書かれています。
ですから、以下は公式仕様ではなく、こちらの判断としての推奨です。行と列の対応や、項目の並列関係をHTMLの側で宣言してあるほうが、機械的に取り出すときの手がかりは多くなります。逆に <div> と CSS だけで組んだ表は、その手がかりを持ちません。見出し行がどれか、どのセルがどの列に属するか、HTMLからは判別できないためです。効果を保証はできませんが、失うものもない変更です。
自社ページの疑似テーブルを洗い出す5ステップ
推測ではなく、実際のHTMLを見ます。ブラウザの開発者ツールで一枚ずつ確認していると数ページで力尽きるので、取得して機械的に拾います。
- 表・箇条書きに見える箇所を目視で列挙する。 まず対象ページを開き、「これは表だ」「これは手順の並びだ」と読者が受け取る箇所に印を付けます。ここは自動化しません。人間が表だと思うかどうかが起点だからです。
- HTMLを取得して
<table>の数を数える。curl -s https://example.com/pricing | grep -c '<table'で、そのページに表要素がいくつあるかが出ます。手順1で3つ印を付けたのに 0 が返るなら、3つとも疑似テーブルです。 - 表組み風のクラス名を拾う。
curl -s https://example.com/pricing | grep -oE 'class="[^"]*(table|row|col|grid|cell)[^"]*"' | sort | uniq -c | sort -rn | headを流します。table-rowpricing-colのような名前が並び、かつ手順2が 0 なら、CSSで表を作っている証拠です。命名は開発者の意図の痕跡なので、よく効きます。 <table>はあるが<th>がないものを拾う。grep -c '<th'が 0 の表は、見出しセルの宣言がない表です。人間はいちばん上の行を見出しとして読みますが、HTMLとしては全部がただのデータセルです。ここは手順2で合格した表にも潜みます。- 箇条書き崩れと、レイアウト目的のtableを探す。
<br>の連打や、・で始まる<p>の連続は、<ul>で書かれるべきだったものです。逆に、段組みのために<table>を使っている箇所も控えます。こちらは意味のない表なので、外す側の候補になります。
手順4まで来ると、たいてい想定より多く見つかります。とくに古い記事と、CMSのテンプレート由来のブロックです。
どこから直すか
見つかったものを全部同時に直す必要はありません。何が失われているかで優先度が変わります。
| 見つかった形 | HTMLとして失われているもの | 直し方 | 優先度 |
|---|---|---|---|
| divとCSSの疑似テーブル | 行・列・見出しセルの関係すべて | <table> <thead> <tr> <th> <td> に置き換える | 高 |
<th> のない <table> | どの行・列が見出しかの情報 | 先頭行を <th scope="col"> に変える | 高 |
<br> 連打の擬似箇条書き | 項目が並列であるという情報 | <ul><li> に分解する | 中 |
手順を <ul> で書いている | 順序があるという情報 | <ol><li> に変える | 中 |
段組みのための <table> | （逆に、無い関係を宣言している） | CSSレイアウトに戻す | 低 |
一つめの疑似テーブルが、手順3で pricing-col が並んだあの状態です。ここは全部失われているので最優先。二つめは、手順4で <th> が 0 だった表がそのまま該当します。表の骨組みはあるので、直すのは一行ぶんで済みます。三つめと四つめは記事本文でよく出ます。とくに四つめ、手順を <ul> で書いているのは意外に多い。順番に意味があるのに、並列だと宣言してしまっている状態です。五つめだけは方向が逆で、消す作業になります。
優先度が「低」でも放置してよいわけではありません。レイアウト目的の表は、存在しない行と列の対応を宣言してしまっているので、読み取る側を積極的に誤らせます。
ワークスルー：料金プランの比較表を直す
3プランの比較表があるとします。手順3で plan-row plan-cell というクラスが並び、手順2は 0。典型的な疑似テーブルです。
もとのHTMLはこうなっています。
<div class="plan-table">
<div class="plan-row plan-head">
<div class="plan-cell">プラン</div>
<div class="plan-cell">月額</div>
<div class="plan-cell">対応サイト数</div>
</div>
<div class="plan-row">
<div class="plan-cell">ライト</div>
<div class="plan-cell">3,000円</div>
<div class="plan-cell">1</div>
</div>
</div>
読み取る側から見ると、これは「プラン 月額 対応サイト数 ライト 3,000円 1」というテキストの並びでしかありません。「ライトの月額は3,000円」という対応関係は、CSSを解釈して初めて復元できるものです。
直したあとがこちらです。
<table>
<caption>料金プランの比較</caption>
<thead>
<tr><th scope="col">プラン</th><th scope="col">月額</th><th scope="col">対応サイト数</th></tr>
</thead>
<tbody>
<tr><th scope="row">ライト</th><td>3,000円</td><td>1</td></tr>
</tbody>
</table>
変わったのは3点です。列見出しを <th scope="col"> で宣言したこと。各行の先頭（プラン名）を <th scope="row"> にして、その行が何についての行かを示したこと。<caption> で表全体の主題を持たせたこと。見た目はCSSで元通りにできます。
この形なら、「ライト」という行と「月額」という列が交差するセルが 3,000円 である、という関係がHTMLだけで読み取れます。スクリーンリーダーを使う読者にとっても同じで、こちらは効果が推測ではなく確実です。
よくある誤解を3つ
「tableに直せば強調スニペットに出る」。 出ません、というより、出るかどうかはこちらで決められません。前述のとおり、ページを強調スニペットとして設定することはできない、とGoogleが明記しています。マークアップは出やすさを上げるための申請ではなく、抜き出される側の形を整える作業です。Googleは、表示される強調スニペットは回答の適切さと有用性に基づいて選択される、と説明しています。形を整えるのは、その判断の手前でできることにすぎません。
「max-snippet を調整すれば表示をコントロールできる」。 これは方向が逆です。Googleは、max-snippet の値を低く設定すれば、そのページが強調スニペットに表示されなくなる、という保証はないと書いています。確実な解決策が必要な場合は nosnippet ルールを使用してください、というのが案内されている手です。いずれも表示を抑える側の指定で、出す方向に効かせるものではありません。
「とにかく表を増やせばいい」。 増やすのは表ではなく、表で表現すべき情報だけです。ポリシーに準拠していない強調スニペットはGoogleによって削除されることがあり、ルール違反のスニペットが多数あるサイトについても言及があります。中身のない表を並べる方向には、そもそも利得がありません。
直したあと、いつ確認するか
すぐには変わりません。SEOスターターガイドは、変更した結果がGoogle側に反映されるまでには時間がかかり、数時間かかる変更もあれば、数か月かかる変更もあるとしています。そのうえで、一般的には数週間待ってから検索結果への影響を確認することをすすめています。変更すれば必ず目に見える変化が現れるわけではない、とも書かれています。
なので、翌日に見て「効果がなかった」と結論を出すのは早すぎます。確認は状態で区切ります。
- 修正が読まれたか：直したページが再クロールされ、保存されているHTMLに
<table>や<th>が入っているか。ここが動いていなければ、その先は見ても意味がありません。 - 表示のされ方が変わったか：対象のクエリで、抜粋される箇所が段落から表・リストに変わっているか。変わらない場合も普通にあります。
- クリックの動きが変わったか：表示回数に対するクリックの割合。ここは順位の変動や季節の需要にも動かされるので、単独では判断材料になりません。
三つめまで到達しなくても、一つめと二つめが動いていれば作業としては成立しています。表示のされ方はGoogleが決めるためです。
そして、直す価値がいちばん高いのは検索結果ではなく、ページの内側かもしれません。行と列の関係が宣言された表は、支援技術でもデータ抽出でも、そのまま使えます。こちらは推測抜きで手に入ります。
見出しの付け方から構造を見直したい場合はh1が複数あるのは直すべき？見出し構造の判断基準も合わせてどうぞ。逆に、特定の箇所を抜粋させたくない場合の制御は検索とAI概要の引用を部分制御｜data-nosnippetの書き方で扱っています。
出典