WordPressのアイキャッチ画像、どう設定するのがいい？
- max-image-preview:large――画像カードで表示されるための必須条件と、それを自動的に保証する仕組み
- robotsメタは、1つの指示ではなく複数の指示をまとめたものだ
- なぜDiscoverでは特に致命的なのか
- Discoverは本質的に、画像を中心としたカード型フィードだ。
- WordPressではデフォルトで有効になっているのに、なぜ改めて保証するのか
- 1つ目は、別のSEOプラグインがrobotsメタの出力を独自の方式で作り直し、この値を落としてしまうケースだ。
- 静かに崩れることが問題なのだ
- だから最後に、もう一度上書きすることにした
- それなら選択肢を残すより、常に最適な値に固定してしまうほうが、ユーザーにとって有益だと判断した。
- 1200pxのルールとの関係を正確に理解しておく必要がある
- SOHO SEOでアイキャッチ画像を設定する方法――結論
max-image-preview:large――画像カードで表示されるための必須条件と、それを自動的に保証する仕組み
前回の記事では、Article JSON-LDが記事の信頼性をどのように構造的に示すのかを取り上げた。
記事の最後で、robotsメタにmax-image-preview:largeを確実に設定することに少し触れたが、今回はこの項目だけを取り上げ、詳しく掘り下げていく。
一見すると些細なメタタグの値が、なぜDiscover掲載の必須条件になるのか。そして、なぜ「自動的に有効になっているから気にしなくていい」と安心できないのかを説明したい。
robotsメタは、1つの指示ではなく複数の指示をまとめたものだ
robotsメタタグを、「インデックスを許可するかどうかだけを決めるタグ」だと思っている人は多い。
noindexの管理機能を扱ったときにも、このタグについて触れた。
この後半の3つは、Googleが検索結果やDiscoverフィードで、そのページのコンテンツをどの程度大きく、どれだけ多くプレビュー表示するかを制限する指示だ。
max-image-previewの値は3種類ある。
none、standard、largeだ。noneは画像のプレビューを一切表示しない。standardは小さいサイズでのみ表示する。largeは大きな画像で表示できるようにする。
ここで重要な点を押さえておきたい。
実際に大きな画像で表示されるかどうかは、画像そのものの品質やサイズ、その他のシグナルを総合して決まる。
しかし、この上限がstandardやnoneに制限されていれば、どれほど良い画像を用意していても、そもそも大きなカードとして表示される資格がない。
なぜDiscoverでは特に致命的なのか
通常の検索結果では、この値が低くても影響は比較的小さい。
検索結果はテキストリンクの一覧が基本で、画像はあくまで補助的な要素だからだ。だが、Discoverは違う。
Discoverは本質的に、画像を中心としたカード型フィードだ。
ユーザーがスクロールしながら目にするのは、文章ではなく、大きな写真と短いタイトルである。
この形式自体が、画像に大きく依存している。
だからmax-image-previewがlargeで開放されていなければ、Discoverというチャンネルに参加する資格がないのに近い。私はこれを、「入場証を持たずにパーティー会場の前に立っている状態」にたとえている。
どれだけ良い服を着ていても、入場証がなければ中には入れない。
WordPressではデフォルトで有効になっているのに、なぜ改めて保証するのか
ここで、自然な疑問が浮かぶ。
WordPress 5.7以降、この値はデフォルトでlargeに設定されるとされている。それなのに、なぜSOHO SEOはこれを改めて強制的に保証するのか。私はこの疑問に、明確に答えられる。
実際に運用されているサイトを調べる中で、このデフォルト値が思った以上に簡単に崩れることを確認したからだ。
実際には、いくつかのシナリオがある。
1つ目は、別のSEOプラグインがrobotsメタの出力を独自の方式で作り直し、この値を落としてしまうケースだ。
WordPressコアのwp_robotsフィルターには、複数のプラグインが同時にフックできる。そのため、実行順によっては、後から実行されたフィルターが先に設定された値を上書きすることがある。
2つ目は、キャッシュプラグインやセキュリティプラグインが、ヘッダーやメタタグを最適化するという名目で、「不要に見える」タグを削除してしまうケースだ。
3つ目は、テーマのfunctions.phpに以前誰かが追加したカスタムrobotsメタの出力コードが残っていて、コアのデフォルト設定と衝突するケースである。
静かに崩れることが問題なのだ
私が本当に危険だと考えているのは、この問題が目に見えない形で起きることだ。
画像が壊れれば、画面を見ただけですぐに気づく。文字が表示されなければ、それもすぐわかる。
しかし、robotsメタの値がlargeからstandardにひっそり変わっていても、そのページを目で確認する限り、何の問題もないように見える。
ページは正常に表示され、画像もきちんと見える。
問題が表面化するのは、GoogleがそのページをDiscoverに表示するかどうかを判断する瞬間だけだ。
しかも、その判断結果がサイト運営者に直接通知されるわけではない。
原因と結果の間に大きな時間差があり、原因そのものも見えにくい。
だから最後に、もう一度上書きすることにした
この問題を解決するために、私が採用した方法はシンプルだ。
他のコードがこの値をどのように変更していたとしても、SOHO SEOがwp_robotsフィルターチェーンの最後で、もう一度largeを強制的に設定する。
元の値が何であったとしても、この項目だけを上書きする方式だ。
私はこれを「交渉の余地を持たせない項目」として扱った。
他のSEO設定については、ユーザーが選べる余地を残している。しかし、この値だけは例外とした。
理由は明確だ。これをlarge以外の値に意図的に設定したいユーザーを、私はほとんど想像できない。
画像のプレビューをわざと小さくしたり、完全に非表示にしたりしたいケースは、ほぼないからだ。
それなら選択肢を残すより、常に最適な値に固定してしまうほうが、ユーザーにとって有益だと判断した。
1200pxのルールとの関係を正確に理解しておく必要がある
ここで、前回のチェックリスト記事で扱った「アイキャッチ画像は1200px」というルールとの関係を明確にしておきたい。
max-image-preview:largeは、「Googleがこのページの画像を大きく表示してもよい」という許可である。
一方、アイキャッチ画像の1200pxという基準は、「実際に大きく表示する価値のある品質の画像があるかどうか」を示すものだ。許可だけあっても、画像の品質が低ければ、大きなカードで表示する理由はない。
逆に、画像の品質が十分でも、許可、つまりrobotsメタで制限されていれば、どれほど良い写真を用意しても、最初から候補から外されてしまう。
私はこの2つを1組の条件として設計し、チェックリストでも並べて配置した。片方だけを確認して安心してしまうのが、最もよくあるミスだ。
SOHO SEOでアイキャッチ画像を設定する方法――結論
max-image-preview:largeは、単なる1つのタグ値に見えるかもしれない。しかし実際には、Discoverという画像中心のチャンネルに参加するための最低条件である。
WordPressがデフォルトで有効にしてくれるからと安心するのではなく、複数のプラグインやテーマが重なって動く実際の運用環境では、この値がひっそり崩れる可能性があることを前提にすべきだ。
目に見えない場所で静かに壊れる問題ほど、人が毎回確認するより、システムが自動的に守る仕組みにしておくべきだと私は考えている。
次回は、インデックス管理グループのもう1つの軸である「インデックス選択」機能に進む。
アーカイブページだけを選んでnoindexにしながら、投稿と固定ページには決して影響を与えない安全装置をどのように作ったのかを取り上げる予定だ。
この記事はDECOBLOCKSを使ってデザインされています。