SEO対策の一環で構造化データ(JSON-LD)を見直したところ、使っているWordPressテーマ「Cocoon」の標準機能だけでは足りていない部分がありました。今日はその調査と対応の記録です。
記事ページには足りない項目があった
Cocoon本体のテンプレートファイルを実際に読んでみると、記事ページのArticle用JSON-LDにはheadline・image・datePublished・authorは出力されているものの、Googleが推奨しているpublisher(運営組織名とロゴ)が含まれていませんでした。
さらに調べると、そもそもJSON-LDを出力する関数がis_singular()のときしか呼ばれない実装になっていることが分かりました。つまり、トップページやカテゴリページのような個別記事以外のページには、構造化データ自体が一切出ていなかったことになります。
裏取りしたら、意外と情報が古かった
対応を考える前に、まず現時点でのGoogleの推奨事項を確認しました。よく言われる「Sitelinks検索ボックス」機能は、実は2024年11月にGoogle側で廃止済みだったんです。この機能に使うSearchActionのマークアップは、もう表示上の意味がほとんどありません。
一方でWebSiteスキーマ自体(name/urlのみのシンプルなもの)は、「モバイル検索結果でURLの代わりに太字のサイト名を表示する」という別の機能のために今も使われている、という情報を見つけました。同じ「WebSiteスキーマ」という言葉でも、何年か前の記事を参考にすると廃止済みの機能を前提にした説明をしてしまうところでした。SEO系の情報は鮮度を意識して調べないといけないなと、改めて感じた場面です。
実装は、車輪の再発明をしないことを意識した
Cocoon本体のファイルは直接編集せず、子テーマのfunctions.phpから対応することにしました。ちょうど以前、JSON-LD内のHTMLエスケープを修正するために、wp_headの出力をバッファリングして文字列置換する仕組みをすでに作っていたので、それを拡張する形でpublisherを注入する処理を追加しました。イメージとしては、こんな形のJSONを最終的な出力に差し込む形です。
"publisher": {
"@type": "Organization",
"name": "サイト名",
"logo": {
"@type": "ImageObject",
"url": "ロゴ画像のURL",
"width": 1672,
"height": 542
}
}トップページ用には、新しくWebSiteとOrganizationをまとめた@graph形式のJSON-LDブロックを追加しました。
検証はパースまで確認してから公開した
実装して見た目が整っているだけで満足せず、実際に出力されたJSON文字列をjson.loads()でパースして、構文エラーなく読み込めることまで確認してから公開しました。構造化データは「それらしく見えるHTML」を書くだけでは意味がなく、実際に有効なJSONとして解釈できるかどうかが重要だからです。
構造化データは「ランキング要因」ではない、という前提も確認した
ついでに、構造化データそのものの位置づけも確認し直しました。Article構造化データは検索順位を直接押し上げる要因ではなく、あくまでTop Stories等の表示条件に関わる「表示可否のシグナル」だという説明が公式のドキュメントにありました。今回の対応も、それ単体で検索順位が上がることを期待したものではなく、あくまで表示され得る条件を満たしておく、という位置づけで進めています。過度な期待をせず、地道に整えておくものだと捉えています。
まとめ
テーマが標準で用意してくれている機能でも、実装の中身を読んでみると条件分岐の隙間から抜け落ちているケースがあります。今回は「個別記事以外のページに構造化データがまるごと無かった」という、見た目には気づきにくい抜け穴でした。SEO系の対応は、公式の最新情報を確認しながら、既存の仕組みに乗せる形で無理なく直していくのがちょうどいいと感じています。
この記事が参考になったら、応援クリックをお願いします
