会員限定記事をインデックスさせるペイウォール構造化データの書き方

会員限定の記事も検索から読者を連れてきてほしい。でも、Googleには本文を読ませて、読者にはログインの壁を見せる。これは「見せる中身を変えている」ことにならないか。そこで手が止まっている担当者は多いと思います。

答えを先に書きます。Googleは、有料や会員登録が必要な区画を構造化データで示すための専用ドキュメント「定期購入とペイウォール コンテンツ」を公開しています。やることは3つです。記事全体に isAccessibleForFree: false を付ける。制限している区画を hasPart の中で cssSelector を使って指し示す。そして、宣言した区画と、実際に読者から隠している範囲を一致させる。最後の「一致」が崩れると、マークアップを入れた意味が薄れます。

なぜ「Googleにだけ全文」は不安になるのか

不安の正体から整理します。

Googleのスパムポリシーは、人を欺くコンテンツや検索順位の操作を防ぐことを目的にしていて、禁止される主な行為の一つにクローキングを挙げています。会員限定記事では、Googlebot（Googleの巡回ロボット）が受け取るHTMLと、ログインしていない読者が目にする画面とで、本文の量が違うことがあります。ここが「見せる中身を変えている」に見えるわけです。

ただ、Google自身が、有料や会員限定の区画を示すマークアップの書き方をドキュメントとして用意しています。つまり、制限のある記事を検索に載せること自体は想定された使い方です。問題になりうるのは、違いがあることではありません。違いを宣言せずに放置すること、そして宣言と実態がずれていることです。これは公式の記述をもとにした当社の整理ですが、実装の判断軸としてはこれで足ります。

もう一点。ペイウォールのドキュメントには、ガイドラインに違反するとページが検索結果に表示される対象外になるおそれがある、と書かれています。あわせて「スパムに該当する構造化マークアップ」を読むよう案内しています。マークアップを入れれば安全、ではありません。正しく書いて初めて守りになります。

公式のマークアップの形

ドキュメントの例は、ニュース記事（NewsArticle）に対して次のような JSON-LD を書く形です。

{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.org/article"
  },
  "isAccessibleForFree": false,
  "hasPart": [
    {
      "@type": "WebPageElement",
      "isAccessibleForFree": false,
      "cssSelector": ".section1"
    }
  ]
}

公式の例でも、途中のプロパティは ( ... ) として省略されています。上のコードは、ペイウォールに関わる部分だけを抜き出したものです。実際の記事では、ふだん Article 系の構造化データに書いている項目と組み合わせます。

それぞれの役割は次のとおりです。

表の3行目に注目してください。公式の説明は「ペイウォールの内側（または定期購入や登録が必要）」です。お金を取る記事だけでなく、無料の会員登録をしないと読めない記事も、この区画の考え方に入ります。

書式についても一言。ペイウォールの区画を示す方法としては、JSON-LD とマイクロデータが受け付けられる、とドキュメントに書かれています。どちらで書くか迷う場合は、別記事の判断基準が使えます。

ワークスルー：冒頭だけ無料の会員限定コラムに入れる

具体例で1回通します。/column/sales-meeting というコラムがあり、冒頭の数段落は誰でも読めて、その先はログインした会員だけが読める作りだとします。CMS のテンプレートで全コラム共通に出力しているので、1本直せば全記事に効く前提です。

1. 制限区画を1つの要素で囲む。 会員限定の本文を <div class="paywall-body"> のような要素で丸ごと囲みます。クラス名は見た目用ではなく、この用途専用の名前にしておくと、デザイン変更で消される事故が減ります。無料部分と会員部分が交互に並ぶレイアウトなら、まず区画をまとめられないか検討します。まとめられなければ、hasPart に区画を複数並べます。
2. JSON-LD を書く。 記事全体に "isAccessibleForFree": false、hasPart に WebPageElement を1つ置き、その中で "isAccessibleForFree": false と "cssSelector": ".paywall-body" を指定します。無料記事のテンプレートには出さないよう、会員限定フラグで出し分けます。
3. セレクタが当たるかを確かめる。 ブラウザの開発者ツールのコンソールで document.querySelectorAll('.paywall-body').length を実行します。会員としてログインした状態で 1（区画が1つの場合）になれば、セレクタと本文がつながっています。0 なら、クラス名の打ち間違いか、テンプレートの別の分岐を見ています。
4. Googlebot が受け取ったHTMLを見る。 Search Console の URL 検査ツールでそのURLを調べ、「クロール済みのページを表示」を開きます。ここではHTTPのリクエストとレスポンス、返されたHTMLを確認できます。返されたHTMLに、手順2の JSON-LD と、手順1で囲んだ区画の両方が入っているかを見ます。
5. 「差分」と「宣言」を突き合わせる。 手順4のHTMLと、ログインしていない状態でブラウザに出る本文を比べます。違いが .paywall-body の中身だけなら、宣言と実態が一致しています。区画の外（たとえば冒頭の無料部分や見出し）まで違っていたら、宣言していない差分が残っています。

この例では、手順3で 0 が返ってきたとしましょう。調べると、テンプレートの改修で会員限定部分のクラスが member-only に変わっていた。JSON-LD 側は .paywall-body のままです。つまり、Googleには「この区画が制限されている」と伝えているつもりで、実際には存在しない要素を指していた、という状態です。直し方は2通り。HTMLに paywall-body を戻すか、JSON-LD のセレクタを .member-only に合わせるかです。どちらでもよいのですが、片方だけ変えて済ませる運用はやめたほうが安全です。

見落としやすい3つの落とし穴

手順を通すと、つまずく場所がだいたい決まってきます。

一つめは、さきほどのクラス名の変更です。HTMLのクラスは見た目の都合で変わります。JSON-LD のセレクタは誰も見ていません。だから、ずれます。テンプレートの改修レビューで「cssSelector に使っているクラスを変えていないか」を確認項目に入れておくと、手順3の失敗を事前に止められます。

二つめは、AMP ページを併用している場合です。ドキュメントは、ボットに対するアクセスの方針を AMP ページと通常ページで同じにするよう書いています。そうしないと、Search Console に中身の不一致エラーが出ることがある、という記述です。通常ページだけ直して AMP 側を忘れる、という形で起きます。

三つめは、マークアップへの期待のかけすぎです。構造化データは、Googleがページの中身を理解する助けになり、リッチリザルト（検索結果での拡張表示）につながることがあるもの、と公式に説明されています。ペイウォールの区画を示すマークアップも、制限のある記事を正しく理解してもらうためのものです。入れたから順位が上がる、という種類の施策として扱わないほうが、効果の読み違いを防げます。

自分の記事を当てはめる点検表

最後に、その場で自分の会員限定記事を当てはめられるよう、判断の基準を1枚にまとめます。

全部が合格になって、はじめて「宣言した違いだけがある」状態です。手動による対策の対象になった場合、Search Console の「手動による対策」レポートとメッセージで通知があり、問題を直して再審査をリクエストする機会がある、とスパムポリシーには書かれています。ただ、通知を待つより先に、この表で自分から確かめておくほうがずっと楽です。

構造化データを JSON-LD とマイクロデータのどちらで書くか迷う場合は「JSON-LDとMicrodataの違い｜どちらで書くかの判断基準」を、Search Console に構造化データの警告が出たときの直す順番は「構造化データのエラーと警告｜直す順番の決め方」を参照してください。会員登録の案内を全画面で出している場合は「ポップアップ広告は順位を下げる？公式の線引き」もあわせて確認しておくと安心です。