BloggerブログのJSON-LDの構造化データのSEO対策のためのカスタマイズについて

結城永人 -2018年8月11日 (土)

Bloggerの2017年の公式テーマのContempoとSohoとEmporioとNotableの記事／追加ページにはJSON-LDの構造化データがデフォルトで付けられている。

Google推奨のJSON-LDの構造化データはSEO対策に相応しい
Bloggerの新テーマのJSON-LDの構造化データのソースコード
インデックスページの記事毎のJSON-LDの構造化データを削除する
インデックスページに専用のJSON-LDの構造化データを付ける方法
JSON-LDの構造化データのソースコードのサンプル
新テーマのテンプレートへのマークアップの仕方

Google推奨のJSON-LDの構造化データはSEO対策に相応しい

JSON-LD（推奨）
ページの見出しや本文の <script> タグ内に埋め込まれる JavaScript 表記。このマークアップにはユーザーに表示するテキストをそのまま挿入しないため、ネストされたデータアイテム（Event の MusicVenue の PostalAddress の Country など）を簡単に表現できます。また、コンテンツ管理システムの JavaScript コードや埋め込みウィジェットなどの方法でページのコンテンツに動的に挿入される JSON-LD データも、Google は読み取ることができます。

構造化データの仕組みについて｜Google Developers

近年、Googleが推奨する方式のマークアップで、内容もリッチリザルト（豊富な検索結果）向けに充実しているんだ。Search GalleryのArticleのAMP（検索エンジンから高速表示されるサイト作成）用と同じで、Bloggerの公式テーマはAMPには対応してないけれども記事／追加ページのタイトルや画像や日時などがNon-AMP／AMP以外でリッチリザルトに含まれている。Googleなどに確実に使われるわけではないけれども検索結果で目立つ可能性があるわけなんだ。加えて構造化データがしっかり付いていると検索エンジンがサイト内容を把握するのも速やかになってSEO対策に役立つはずだし、Bloggerの2017年の公式テーマはアクセスアップに繋がると期待される利点を新しく持っている。従来のシンプルと動的ビューと画像ウィンドウとAwesome Inc.とウォーターマークとエスィリアルと旅行にもMicrodataの構造化データが付いているけれども不要なマークアップが行われたり、リッチリザルトに必要な項目が不足した状態だから構造化データテストツールにかけてチェックしてもエラーが出てしまってSEO対策にさほど効果的ではなかったはずなので、テンプレートとしてContempoとSohoとEmporioとNotableでは大きく改善された部分といって良い。Bloggerの新テーマのJSON-LDの構造化データのソースコード

テンプレートのBlog1のidのwidgetタグに含まれている。<b:includable id='postMeta' var='post'> <b:include data='post' name='postMetadataJSON'/> </b:includable>このままだと全ての項目が自動的に出力される。カスタマイズするためには実際のJSON-LDのscriptタグのソースコードに分解しなくてはならない。<b:includable id='postMetadataJSON' var='post'> <script type='application/ld+json'> { "@context": "http://schema.org", "@type": "BlogPosting", "mainEntityOfPage": { "@type": "WebPage", "@id": "<data:post.url.canonical.jsonEscaped/>" }, "headline": "<data:post.title.jsonEscaped/>", "description": "<b:eval expr='(data:post.body snippet { length: 150, links: false, linebreaks: false, ellipsis: true }).jsonEscaped'/>", "datePublished": "<data:post.date.iso8601.jsonEscaped/>", "dateModified": "<data:post.lastUpdated.iso8601.jsonEscaped/>", "image": { "@type": "ImageObject", "url": "<b:eval expr='(data:post.featuredImage ? resizeImage(data:post.featuredImage, 1200, "1200:630") : "https://lh3.googleusercontent.com/ULB6iBuCeTVvSjjjU1A-O8e9ZpVba6uvyhtiWRti_rBAs9yMYOFBujxriJRZ-A=w1200").jsonEscaped'/>", "height": <b:eval expr='data:post.featuredImage ? 630 : 348'/>, "width": 1200 }, "publisher": { "@type": "Organization", "name": "Blogger", "logo": { "@type": "ImageObject", "url": "https://lh3.googleusercontent.com/ULB6iBuCeTVvSjjjU1A-O8e9ZpVba6uvyhtiWRti_rBAs9yMYOFBujxriJRZ-A=h60", "width": 206, "height": 60 } }, "author": { "@type": "Person", "name": "<data:post.author.name.jsonEscaped/>" } } </script> </b:includable>

参考サイト

postMetadataJSON [GV2]

Blog1のウィジェットのincludeのnameのpostMetadataJSONで呼び出される実際のソースコードのincludableのidが示されている。カスタマイズする場合には<b:includable id='postMetadataJSON' var='post'>中略</b:includable>をbody内のBlog1のTypeのWedgetタグに他のタグと分けて配置する。またはpostMetadataJSONのnameのincludeタグの中身の<b:include data='post' name='postMetadataJSON'/>をpostMetadataJSONのidのincludableタグの中身の<script type='application/ld+json'>中略</script>と置き換える。JSON-LDの項目はSchema.orgのFull Hierarchy（完全階層）などを参照しながら他にも自由に種々と追加できる。Bloggerの公式テーマの構造化データのマークアップそのものはGoogleのリッチリザルトに対応しているし、恐らくSEO対策では十分だろうからさらに編集する必要はないかも知れない。追記：2021年11月に確認すると著書ページのURLが推奨項目としてリッチリザルトに求められるように変わったので、修正するソースコードを掲載した。Bloggerのプロフィールを作成していれば独自タグを使ってauthorのurl、さらに画像も登録してあれば追加できる。"author": { "@type": "Person", "name": "<data:post.author.name.jsonEscaped/>", "url": "<data:post.author.profileUrl.canonical/>", "image": { "@type": "ImageObject", "url": "https:<data:post.author.authorPhoto.image.jsonEscaped/>", "height": <data:post.author.authorPhoto.height/>, "width": <data:post.author.authorPhoto.width/> } }著者ページのURLが「url」の項目になり、これがないとGoogleのリッチリザルトに対応しなくなったから新しく追加しなくてはならない。著者の画像が「image」の項目で、内容を示す「@type」と共に画像の「url」と「height」（縦幅）と「width」（横幅）を記載している。サンプルのソースコードは項目の値にBloggerのdataタグを使って出力しているけれどもURLは文字列、画像のサイズは数値で入力しても構わない。Bloggerのプロフィール以外の著者のURLや画像を記載したい場合はBloggerのdataタグは全く使えないので、必ずそれぞれの値を個別の文字列や数値で入力しなくてはならない。特殊なのは「publisher」（公開主）のnameが「Blogger」になっている。扱いがソーシャルメディアのようなところに幾らか違和感を覚える。一般サイトならばサイト名を入れて「organization」（組織）のtypeとして他の項目を纏めるべきだろう。デフォルトで少しも修正したくならないわけではない。しかしやっているのはBloggerブログとサイトとWebサービスを併せて捉えるかぎりは誤りではないのも確かだ。作成上、明らかな気がかりが一つあってトップやアーカイブなどのインデックスページのソースコードにも掲載される記事毎にJSON-LDの構造化データが記載されてしまうので、何とかしたくなる。SEO対策で必ずしも悪くはないかも知れないけれどもインデックスページは記事ページではないから全て削除して専用のマークアップを行いたくなる。何れも、結構、長いので、幾つも記載されるとインデックスページの表示速度を下げるのは間違いない。不要ならば残しておくのは利用者の利便性を欠くと共にSEO対策も含めてアクセスアップに不利だし、記事の構造化データは記事ページだけに付いていれば十分だと考える。インデックスページの記事毎のJSON-LDの構造化データを削除するBlog1のウィジェットのincludeの出力をcond属性によって記事／追加ページだけに振り分けるとインデックスページは除外される。<b:includable id='postMeta' var='post'> <b:include cond='data:view.isSingleItem' data='post' name='postMetadataJSON'/> </b:includable>Bloggerの新テーマのインデックスページに掲載されるJSON-LDの構造化データは基本的に記事ページだけだけれどもJSON-LDの構造化データそのものはデフォルトで追加ページにも対応しているんだ。当のincludeの出力を記事ページだけに制限してしまうと追加ページで記載されなくなってSEO対策に勿体ないから残しておきたいし、一緒に含めるのが好ましい。インデックスページに専用のJSON-LDの構造化データを付ける方法トップやアーカイブなどのインデックスページに専用のJSON-LDの構造化データを付けると記事／追加ページとは区別して検索エンジンに個別のサイト内容を伝えられるようになる。JSON-LDの構造化データのソースコードのサンプル<script type='application/ld+json'> { "@context": "http://schema.org", "@type": "CreativeWork", "mainEntity": { "@type": "Blog", "@id": "<data:blog.url.canonical.jsonEscaped/>" }, "name": "<data:blog.pageTitle.jsonEscaped/>", "alternateName": "キャッチフレーズ", "description": "<data:blog.metaDescription.jsonEscaped/>", "image": "インデックスページの画像URL", "publisher": { "@type": "Organization", "name": "Blogger", "logo": { "@type": "ImageObject", "url": "https://lh3.googleusercontent.com/ULB6iBuCeTVvSjjjU1A-O8e9ZpVba6uvyhtiWRti_rBAs9yMYOFBujxriJRZ-A=h60", "width": 206, "height": 60 }}, "author": { "@type": "Person", "name": "作者名" }} </script>※帯文字の部分は固定値で入力する。Bloggerのインデックスページはトップとアーカイブとラベルが含まれている。CreativeWork（創作活動）のtypeからページのmainEntity（主要部）のtypeをBlog（ブログ）にして記載している。独自タグを使って主要部分のサイトアドレスのidはインデックスページの個別のサイトアドレス、ページタイトルのnameは個別のタイトルタグ、説明文のdescriptionはBloggerの設定の検索設定のメタタグの説明が全てのインデックスページに共通で自動的に記載される。サイト内容の補足としてサイトの別名のalternateNameを使ってキャッチフレーズを固定値で記載しているけれども不要ならば外して構わないだろう。画像のimageは専用の画像URLをブログ内や外部サービス（画像URLを取得できるImgurなど）から取得として固定値で記載する。公開主のpublisherと作者のauthorは記事／追加ページのJSON-LDの構造化データを踏襲している。ただし作者名はインデックスページで出力する独自タグがないみたいなので、固定値で記載する設定にした。追記：Bloggerのプロフィールやプロフィールの画像を設定してあれば独自タグで追加することもできる。"author": { "@type": "Person", "name": "<data:post.author.name.jsonEscaped/>", "url": "<data:posts.first.author.profileUrl.canonical/>", "image": { "@type": "ImageObject", "url": "https:<data:posts.first.author.authorPhoto.image.jsonEscaped/>", "height": <data:posts.first.author.authorPhoto.height/>, "width": <data:posts.first.author.authorPhoto.width/> } }インデックスページは記事／追加ページのようにリッチリザルトに対応するものではないけれども検索エンジンに多くの情報を使えるには追加すると良いと思う。JSON-LDの項目はSchema.orgのFull Hierarchy（完全階層）などを参照しながら他にも自由に種々と追加できる。新テーマのテンプレートへのマークアップの仕方インデックスページの構造化データだから振り分けの独自タグを使って記載しなくてはならない。<b:if cond='data:view.isMultipleItems'> インデックスページのJSON-LDの構造化データ </b:if>マークアップの場所はサンプルのソースコードでは「description」（説明）のdata:posts.first.bodyの独自タグがBlogのwidget内でしか使えないので、そのどこかになる。一般的にいうとJSON-LDの構造化データはブラウザに表示されず、コンテンツとは別物なので、どこに置くかはhtmlのbody内にかぎらず、head内でも大丈夫だし、クローラー（検索ロボット）はサイトに訪問すると読み取るけど、しかし「description」のdata:posts.first.bodyなどの使用範囲が決められたBloggerの独自タグを使う場合は合わせなくてはならない。Blogのwidget内に置くとすると全体的な位置取りを決めているmainのidのincludable内のコンテンツを出力するsuper.mainのnameのincludeタグの前後が最も簡単だと思う。ContempoとSohoとEssentialの例<b:widget id='Blog1' locked='true' title='ブログの投稿' type='Blog' visible='true'> （中略） <b:includable id='main'> （中略） <b:include name='super.main'/> <b:if cond='data:view.isMultipleItems'> インデックスページのJSON-LDの構造化データ </b:if> （中略） </b:includable> （中略） </b:widget>Emporioの例<b:widget id='Blog1' locked='true' title='ブログの投稿' type='Blog' visible='true'> （中略） <b:includable id='main'> <b:include name='noContentPlaceholder'/> <b:include name='super.main'/> <b:if cond='data:view.isMultipleItems'> インデックスページのJSON-LDの構造化データ </b:if> </b:includable> （中略） </b:widget>Notableの例<b:widget id='Blog1' locked='true' title='ブログの投稿' type='Blog' visible='true'> （中略） <b:includable id='main' var='this'> （中略） <b:include data='this' name='super.main'/> （中略） <b:if cond='data:view.isMultipleItems'> （中略）インデックスページのJSON-LDの構造化データ <b:else/> <b:include data='this' name='super.main'/> </b:if> （中略） </b:includable> （中略） </b:widget>分かり難ければmainのidのincludableの閉じタグの</b:includable>の直前でも位置取りは変わらないけれども、一応、super.mainのnameのincludeタグの近くに記載するとソースコードとして纏まりがある。Notableはインデックスページと記事／追加ページの二つのsuper.mainのnameのincludeがあるので、注意しなくてはならない。最初のものがインデックスページの分になる。インデックスページに振り分けられたところだから構造化データには振り分け用のifタグを付けなくて構わない。

コメント