【E-E-A-T×データベース型サイト】「薄いページ」と判定されないための情報設計～東京・札幌のWEB・システム・コンテンツ制作＞ブレッセ
【E-E-A-T×データベース型サイト】「薄いページ」と判定されないための情報設計
「2,000ページを自動生成」—この言葉を聞いて、多くの人が真っ先に思い浮かべるのは「質より量の粗製濫造」ではないでしょうか。
実際、Googleのスパムポリシーでは「有用性の低い自動生成コンテンツ」が明確に禁止対象として挙げられています。データベース型SEOは、この一線のすぐ隣で成立している手法です。
ただし、Googleが本当に問題視しているのは「自動生成」という手法そのものではありません。単一のデータソースをそのまま複製しただけの、独自の価値を持たないページの量産です。
裏を返せば、独自の価値さえ作り込めれば、自動生成は禁止どころかむしろ強みになります。ここでいう「独自の価値」は、大きく2つに分けられます。ひとつは実際に訪れた人にしか書けない一次情報。もうひとつは、バラバラに存在する情報を独自の切り口で整理し、比較・検索可能にする構造化の価値です。
弊社の自社メディア「しあわせのスイーツ」が2,000ページ超のインデックスを達成できた背景には、この2つの価値をどう設計に組み込んだかという判断があります。本記事では、その具体的な設計思想と実装のポイントを解説します。
Googleが「薄いページ」と判定する基準
スパムポリシー上の位置づけ
Google検索セントラルのスパムに関するポリシーでは、「大量生成されたコンテンツの不正使用」が明確にスパム行為として定義されています。ここでの問題は、生成方法がAIであれ人力であれ、テンプレートの機械的な複製であれ変わりません。ポイントは多くのページがユーザーを助けるのではなく主にサイト所有者の利益のために生成されているかどうかであり、多量の独自性に欠けるコンテンツが同種の他ページと比較して訪問者にほとんど価値を提供しない場合にスパムと判定されます。 Techsuite
つまり、禁止されているのは「自動化」という手法そのものではなく、「独自性・有用性のない自動化」です。この違いは重要です。Googleも公式ブログの中で、コンテンツがどのように制作されたかではなく、その品質に重点を置く姿勢を長年にわたり貫いてきたと明言しています。
言い換えれば、「2,000ページを自動生成する」という行為自体がリスクなのではなく、その2,000ページが「ユーザーにとって価値のある独自の情報を持っているか」「単一ソースの複製に留まっていないか」が判定基準になります。データベース型SEOがこの一線をどう越えないか—それが本記事のテーマです。
テンプレート文がそのまま「薄い」と判定される典型パターン
前節で見た通り、Googleが問題視するのは「独自性・有用性のない自動化」です。ここでは、データベース型SEOで実際に陥りやすい3つのパターンを具体的に見ていきます。
パターン1：差し替え変数だけが違う紋切り型の説明文
「〇〇（店舗名）は、〇〇（エリア名）にあるスイーツ店です。〇〇（ジャンル名）を提供しています。」——このように、店舗名・エリア名・ジャンル名の3つだけを差し替えて、文章の骨格が完全に同一なテンプレートは典型的な薄いページです。
2,000ページあっても、Googleのクローラーからは「実質1パターンのページが2,000回繰り返されている」と映ります。人間の目には店舗ごとに違って見えても、文章構造の類似度という観点では、これは前節で触れた「内容が類似する複数のページ」にほぼ該当します。
パターン2：外部APIのデータをそのまま流用しただけの情報
Google Places APIなどから取得した店舗名・住所・評価点・営業時間を、加工せずにそのままページに流し込むケースです。この情報は、Googleマップや他の口コミサイトにも同じ形で存在するため、ページ単体で見たときに「他では得られない情報」が一切ない状態になります。
データの取得元が同じである以上、これは「フィードや検索結果をスクレイピングして生成する行為」に近い構造的リスクを抱えています。API由来のデータは「土台」として使うのは問題ありませんが、それだけで1ページを完結させてしまうと薄いページ判定のリスクが高まります。
パターン3：掛け合わせページの機械的な量産
「エリア×ジャンル」のような掛け合わせ一覧ページを機械的に全組み合わせ分生成すると、該当店舗が1〜2件しかない掛け合わせページが大量に生まれます。これは検索結果の一覧をそのままページ化しているだけの状態に近く、独自の編集価値がほとんどありません。
該当件数が極端に少ない掛け合わせは、ページとして公開する前にnoindex化するか、そもそも生成しない基準を設ける必要があります（この間引き基準は、次回記事「大量生成ページのインデックス管理」で詳しく扱います）。
テンプレートを「可変」にする設計
前節で挙げた3パターンに共通するのは、「変数が少なすぎる」「ソースが単一」という構造的な問題です。ここでの対策は、テンプレートそのものを捨てることではなく、テンプレートが生み出すバリエーションの幅を意図的に広げることです。
差し替え変数を増やす
店舗名・エリア名だけを変数にしていると、文章の骨格が固定されたままになります。弊社の実装では、以下のような複数軸を変数として組み込み、変数の組み合わせ次第で文章の骨格自体が変わるロジックを採用しています。
- 営業時間の特徴（早朝営業／深夜営業／不定休など）
- 価格帯（1,000円台のカジュアル利用／3,000円以上の特別な時間として使える店など）
- 混雑傾向（週末は行列ができる／平日午後が狙い目など）
- 席数・空間の特徴（テラス席あり／個室完備／カウンターのみなど）
重要なのは、これらの変数を単に文章の一部に差し込むのではなく、変数の組み合わせによって使う文型そのものを分岐させることです。たとえば「深夜営業×カジュアル価格帯」の店舗と「早朝営業×特別な時間」の店舗では、紹介文の切り口や強調するポイントが自然に変わるようロジックを組んでいます。これにより、同じテンプレートエンジンから生成されていても、Googleのクローラーから見た文章構造の類似度が大きく下がります。
データソースを複数掛け合わせる
変数を増やしても、データの出どころが単一（Google Places APIのみ）であれば、根本的な解決にはなりません。弊社では、1ページの情報を以下のように複数ソースから構成しています。
- 基礎データ：Google Places APIから取得する住所・営業時間・評価点などの定量情報
- 独自収集データ：実際の訪問メモ、撮影した写真、担当者の所感
- ユーザー投稿データ：レビュー・写真（現在拡充を進めている募集施策と接続する部分）
基礎データはあくまで「骨格」であり、そこに独自収集データとユーザー投稿データが重なることで、初めてページとして独自の価値を持ちます。逆に言えば、独自収集データやユーザー投稿データがまだ存在しない店舗ページは、構造的に薄いページのリスクを抱えたままの状態です。この状態のページをどう扱うか（公開を保留するか、reviewingステータスに留めるか）という運用判断も、テンプレート設計と一体で考える必要があります。
独自情報・一次情報をどう載せるか
前節では、独自収集データとユーザー投稿データを重ねることで初めてページが独自の価値を持つ、と述べました。ここからは、その独自情報を実際にどう載せるかという話に入ります。E-E-A-Tの4要素は抽象的な概念に見えますが、データベース型サイトにおいては、それぞれ具体的な「ページ上の構成要素」に落とし込むことができます。
「Experience」を担保する要素
E-E-A-Tの先頭に置かれたExperience（経験）は、大量生成ページにとって最も獲得が難しく、同時に最も模倣されにくい要素です。他サイトが同じAPIから同じデータを引いてきても、経験だけは複製できないからです。
実際に訪問して撮影した写真が、その最も分かりやすい担保になります。ここで重要なのは、ストックフォトや店舗提供画像との差を、ユーザーにもクローラーにも認識できる形で示すことです。撮影日を表示する、店内の様子や実際に注文した商品といった「提供画像には存在しない画角」を含める、ファイル名とalt属性を店舗名・メニュー名から機械的に生成する——これらはテンプレート側で自動化できる領域です。ただし独自画像を増やせばページは重くなるため、配信基盤側の手当てと一体で進める必要があります。独自性のために表示速度を犠牲にすれば本末転倒になります。
店主インタビューや実食コメントは、他サイトに構造的に存在しない一次情報です。ここでのポイントは、自由記述の文章としてではなく、分解可能なフィールドとして格納することです。「いつ訪問したか」「何を食べたか」「その時どうだったか」を個別に持てば、前節で扱った可変テンプレートが一次情報を変数として扱えるようになります。逆に担当者のメモがテキストのまま手元に残っている状態では、2,000ページのどこにも反映されません。
ユーザー投稿レビュー・写真は、Experienceの三つ目の層です。運営者一人の経験には量的な限界がありますが、訪れたユーザーの経験は蓄積とともに増えていきます。一方で、投稿が集まるにはトラフィックが必要で、トラフィックが伸びるにはコンテンツが必要という循環構造を持つため、立ち上がりが最も遅い要素でもあります。したがって投稿枠は「集まったら作る」のではなく、投稿ゼロの状態でも破綻しない表示分岐をあらかじめテンプレートに組み込んでおく必要があります。現在進めている投稿ユーザー募集施策は、この枠を埋めていくための取り組みにあたります。
「Expertise」「Authoritativeness」「Trustworthiness」の担保
残る三要素は、Experienceと違って仕組みで担保できる領域です。裏を返せば、仕組みを用意していなければ確実に欠落します。データベース型サイトは自動生成の性質上、著者情報が抜け落ちやすい構造を持っているため、ここはテンプレート側で埋めておく設計が望まれます。
執筆者・監修者情報の明示は特に重要なポイントです。弊社サイトでは「編集部」が責任をもって情報発信を行っています。何店舗を実際に訪問しているのか、どういう基準で店舗を選定しているのか、運営体制はどうなっているのか。これらを運営者情報ページにまとめ、各店舗ページから確実にリンクを通していきます。親しみやすさを生みますが、それ単体では専門性の証明になりません。「誰が」ではなく「どういう経験の蓄積を持つ誰が」を示すことが、ExpertiseとAuthoritativenessの実体になります。
情報の更新日時・出典の明示は、店舗情報を扱うサイトでは特に重みを持ちます。営業時間や価格は変動する情報であり、いつ時点の情報なのかが示されていなければ、ユーザーにとっての実用価値が下がります。基礎データがAPI由来であること、独自情報が実訪問由来であることを分けて表示すれば、情報の性質の違いも同時に伝わります。
訂正フローの存在を示すことは、見落とされがちですが、Trustworthinessに直接効きます。掲載情報の誤りを報告できる導線がページ上に存在し、報告があれば修正されるという運用が示されていること。これは「完璧な情報を出す」という主張よりも、はるかに現実的で信頼できるシグナルになります。
AI生成文と人の監修の線引き
前節までの内容は、突き詰めれば「どこまで自動化し、どこから人が関与するか」という一点に収束します。データベース型SEOにおいて、この線引きは品質管理そのものです。
どこまでAIに任せ、どこで人が介在するか
弊社では、ページを構成する情報を性質によって明確に分けています。
自動化して問題ない領域は、定型的な基礎情報の整形です。住所の表記ゆれの統一、営業時間の読みやすい形式への変換、価格帯の分類、アクセス情報の生成——これらは事実の整形であり、人が手作業で行っても結果は変わりません。むしろ機械的に処理したほうが表記の一貫性が保たれます。ここに人手をかける必要性は低いといえます。
人の監修・追記を必須とする領域は、独自性と体験の記述部分です。実訪問に基づく描写、店主の言葉、味や雰囲気についての評価——ここをAIに任せた瞬間、その文章は「実際には誰も行っていない店の紹介文」になります。これは品質以前に、事実に反する内容になってしまいます。前節で挙げた「薄いページ」の三パターンのうち、パターン1（紋切り型の説明文）が生まれる最大の原因が、まさにこの線引きの失敗にあります。
そして、この線引きを運用者の心がけではなく、システム上の制約として実装することが重要です。弊社ではreviewingステータスを設けており、独自情報の追記と人の確認が完了していないページは、この状態に留まります。人が見ていないページが自動的に公開されることはない、という構造をワークフローに埋め込んでいるわけです。ステータス管理は一見すると地味な仕組みですが、数千ページ規模になったとき、品質を担保できる唯一の現実的な手段になります。
「AIが書いた」ことを隠さない設計思想
ここで一つ、前提を整理しておきます。Googleは、AIが生成したという事実そのものを問題視していません。 問題視されているのは、検索順位の操作を主目的として、品質管理のない大量のコンテンツを生成する行為です。前節で引用した品質に関するガイドラインが問題としているのも、生成手段ではなく「独自性・有用性のない自動化」でした。
この整理から、一見すると逆説的な結論が導かれます。品質管理のプロセスが存在すること自体が、信頼性のシグナルになるということです。
「AIを使っていません」と主張するサイトと、「基礎情報の整形は自動化していますが、独自情報の記述と最終確認は必ず人が行っています」と明示するサイトを比べたとき、後者のほうが運用実態として信頼できます。前者は検証不可能な主張であり、後者は検証可能なプロセスの開示だからです。
したがって弊社では、自動化の使用を隠すのではなく、どこを自動化し、どこに人が介在しているかを開示する方向を取っています。これは倫理的な建前ではなく、E-E-A-TのTrustworthinessに対する実務的なアプローチです。プロセスを説明できないサイトは、品質を証明する手段を持ちません。
実際に「薄いページ」と判定されたら何が起きるか
最後に、ここまでの対策を怠った場合に何が起きるかを、実際の症状として整理しておきます。
Search Console上での見え方として最初に現れるのが、「クロール済み – インデックス未登録」というステータスです。これはページ数の増加に対してインデックス数が伸びない、という形で観測されます。念のため補足すると、これは技術的な不具合ではありません。クローラーはページに到達しており、内容も取得できています。その上で、Googleが「このページを索引に加える価値はない」と判断した結果がこのステータスです。robots.txtやサイトマップを見直しても解決しないのは、そもそも技術的な問題ではないからです。
似たステータスに「検出 – インデックス未登録」がありますが、こちらはクロール自体が後回しにされている状態で、原因が異なります。まずはどちらの内訳が多いのかを確認することが、対処の出発点になります。
部分的な対処としては、noindex化・類似ページの統合・削除という選択肢があります。判断の軸は「そのページが単独で検索意図に応えられるか」です。前節で触れた、該当店舗が1〜2件しかない掛け合わせページなどは、統合または生成停止の対象になります。ただし、どのページをどの基準で間引くかという具体的な判定手順は、次回記事「大量生成ページのインデックス管理」で扱います。ここでは「放置してはいけない」という認識だけ共有しておきます。
サイト全体への波及リスクが、最も見落とされやすく、最も深刻な部分です。薄いページは、それ単体でインデックスされずに終わるだけではありません。同種のページが大量に存在することで、サイト全体の品質評価が押し下げられ、本来評価されるべきページまで巻き添えにする可能性があります。手間をかけて作った独自性のあるページが伸びない原因が、実は隣にある数百の薄いページにある、という状況は珍しくありません。
なお、クロールバジェットの毀損についても言及しておきます。ただし正確に言えば、数千ページ規模のサイトでクロールバジェットが主要なボトルネックになることは稀です。Googleが明確に問題になるとしているのは、より大規模なサイトです。弊社のような規模で優先して警戒すべきは、クロール効率よりも前述の品質評価の波及のほうです。ここを取り違えると、対処すべきでない箇所に労力を割くことになります。
[ 貴社サイトのデータベース型SEO 無料設計診断はこちらから ]