2023年初頭、旅行クライアントが理想的なセットアップのように見えるものを持ってきました。彼らは14,000の地域ページを持っていました。英国のすべての都市、すべての行政区、すべての郵便番号地区です。すべてホテルとレストランのデータベースから自動生成されていました。クリーンなテンプレート。まともな内部リンク。そしてランクインしていました。約4ヶ月間。
その後、2024年3月のコアアップデートが来ました。彼らは6週間で有機トラフィックの71%を失いました。私は3週間かけてフォレンジック分析を行いました。コンテンツは正確には間違っていませんでした。ただし、空っぽでした。すべてのページは同じ3つのことを若干異なる順序で述べていて、Googleは明らかにそれを誰かに提供する価値がないと判断していました。私たちは適切な品質ゲートを使ってパイプラインを再構築し、5ヶ月以内にピークの60%まで回復しました。完璧ではありません。ですが、私に残った教訓です。March 2024 core update hit. They lost 71% of their organic traffic in six weeks. I spent three weeks doing the forensics. The content wasn't wrong exactly. But it was hollow. Every page said the same three things in slightly shuffled order, and Google had clearly decided it wasn't worth serving to anyone. We rebuilt the pipeline with proper quality gates and recovered to 60% of peak within five months. Not perfect. But a lesson that's stayed with me.
プログラマティックSEOは、エージェンシーツールキットの中でも最も強力なツールの1つです。しかし、スロップの余地はほぼゼロになりました。
pSEOパイプラインで「品質ゲート」が実際に意味すること
この用語は緩く使われていますので、Seahawkで私がそれをどのように使うかについて正確に説明させてください。
クオリティゲートとは、ページが公開される前に—または公開され続けるために—通過しなければならないチェックポイント付きのルールまたはテストである。これは雰囲気的なチェックではない。特定の、測定可能な閾値で、ページを通すか、修正のために差し戻すか、完全に廃棄するかのいずれかを決定する。checkpointed rule or test that a page must pass before it gets published — or before it stays published. It's not a vibe check. It's a specific, measurable threshold that either lets a page through or sends it back for revision (or kills it entirely).
これはコンテンツの継続的インテグレーションのようなものと考えてほしい。デベロッパーはユニットテストに落ちるコードをプッシュしない。あなたもコンテンツテストに落ちるページを公開すべきではない。この類似性は完璧ではないが、役に立つほど十分に近い。
クオリティゲートのないパイプラインは、単なるコンテンツスパムマシンだ。そして2024年において、Googleの分類器はそれを大規模に検出するのに十分な性能を持っている。
ゲートが必要な3つのレイヤー
私は3つの時点でゲートを構築している：
- 生成前—コンテンツが書かれる前。データ品質チェック。このエンティティは、独立したページをサポートするのに十分なユニークな属性を持っているか？ — before any content is written. Data quality checks. Does this entity have enough unique attributes to support a distinct page?
- 生成後—AIまたはテンプレートがコンテンツを生成した後。長さ、ユニーク性、エンティティカバレッジの自動スコアリング。 — after the AI or template has produced content. Automated scoring for length, uniqueness, entity coverage.
- 公開後監視—継続的。インプレッションやクリック率が低下したページは、人間によるレビューのためにフラグが立てられる。 — ongoing. Pages that drop in impressions or click-through rate get flagged for human review.
ほとんどのチームは中間レイヤーのみを構築する。これが彼らが失敗する理由だ。
データ充足性の問題（ほとんどの人がスキップする）
ここが重要だ — プログラマティックコンテンツの最悪の問題は、1文字も書く前に始まる。スプレッドシートで始まるのだ。
ソースデータがエンティティあたり12個の属性を持っていて、そのうち9個がレコードの80%で同じなら、プロンプトがいくら賢くても、ほぼ重複したページを量産することになる。2021年にSeahawkで構築した弁護士ディレクトリでこれを学んだ。6,000件の法律事務所エントリがあった。そのうち約4,200件は、名前、郵便番号、業務分野以外に特に特徴がなかった。6,000件すべてを公開したが、Googleがインデックスしたのは1,800件程度だ。
生成前のゲート：データの豊富さのスコアリング。今は、テンプレートに触れる前に、すべてのデータセットを簡単なPythonスクリプトを通す。レコードあたりのnull以外で、汎用的でないフィールドの数をカウントして、閾値以下のものにフラグを立てる — 典型的には最低7/12を使う。クリアしなかったレコードは「スタブ」カテゴリーに入り、noindex付きの薄いページか、ページなしになる。 I now run every dataset through a simple Python script before we touch a template. It counts the number of non-null, non-generic fields per record and flags anything below a threshold — I typically use 7 out of 12 as a minimum. Records that don't clear it go into a "stub" category that gets a thin page with noindex, or no page at all.
これは派手ではない。だが、構築全体のクロール効率に最大の影響を与えた唯一の変更だ。
生成後のユニークネススコアリング
では、データが最初のゲートをクリアした。コンテンツは生成された。次は何か？
公開する前に、ユニークネスのスコアを付けること — ウェブに対してではなく、自分たちのページコーパスに対してだ。内部の重複コンテンツがより一般的な問題であり、あなたがより直接的にコントロールできる問題だ。
このために2つのツールの組み合わせを使う：
- [Copyscapeのバッチ API](https://www.copyscape.com/api.php) — インデックスされた既存URLに似すぎているページにフラグを立てる for flagging pages that are too similar to existing indexed URLs
- カスタムコサイン類似度スクリプト（Pythonのsentence-transformersを使用）で、新しいページを同じテンプレートファミリー内の構造的に最も似た50ページに対してスコアリングする
私のしきい値はコサイン類似度0.82です。それ以上はすべて手動レビューに回します。0.91以上は削除するか大幅に修正します。
はい、これはパイプラインに摩擦を加えます。それで構いません。摩擦が目的です。
「ユニーク」が実際に意味すべきこと
本当にユニークというのは、単に文を並び替えたものではなく、このエンティティだけが答えられる質問にページが応じることを意味します。都市のランディングページであれば、ハイパーローカルなデータ — 実際のイベントリスト、実在するローカル統計、地域の情報源からの具体的な引用です。製品比較ページであれば、これら2つの特定の製品を区別するデータポイント、名詞を入れ替えただけの定型的な導入部分ではありません。this entity can answer. For a city landing page, that's hyper-local data — real event listings, actual local statistics, a specific quote from a local source. For a product comparison page, it's data points that differentiate these two specific products, not a boilerplate intro with swapped nouns.
Googleの有益なコンテンツに関する独自のガイダンスは常にこう述べてきました。分類器がそれを積極的に強制するようになっただけです。 has always said this. The classifier just got aggressive about enforcing it.
エンティティカバレッジ: 誰も話さないゲート
これを理解するのに時間がかかりました。その点は悔しいです。
プログラマティックビルドのすべてのページは名目上「何か」 — 場所、製品、人物、サービス — についてです。エンティティとその属性は、名前の明記、意味的な関連付け、構造化データを通じてコンテンツ内で一貫して表現されるべきです。されていなければ、800語あってもページは薄く読まれます。
私は現在、生成されたすべてのページに対してspaCyを使用した軽量のNLP処理を実行して、以下をチェックしています:spaCy to check that:
- プライマリエンティティが最初の100語以内に名前で挙げられている
- 少なくとも4つの意味的に関連するエンティティまたは属性がボディに表示される
- ページには、エンティティに固有の少なくとも1つの事実が含まれている（モデルによる幻想ではなく、ソースデータから取得）
最後のチェックは今のところ手動である。これを自動化したいが、スケール時に偽陽性が多すぎずに信頼性の高いクロスリファレンス検証を行う方法をまだ構築していない。これを解決したのであれば、本当に知りたい。
Thin-Page トラップ：noindex すべき場合と削除すべき場合
ページが生成を通過したとしても、薄いままかもしれない。データが不足していたり、エンティティが不明確であったり、出力が技術的にはユニークだが特に有用でない場合がある。
どうする？
これが私の決定木である—簡潔にしたが、大体こういう考え方をしている：
- ページが GSC で90日間ゼロの検索インプレッションを記録した場合：削除して最も関連のある親へ301リダイレクトする。delete and 301 to the nearest relevant parent.
- ページがインプレッションを記録していても CTR が 0.5% 未満でバックリンクがない場合：noindex にして親またはカテゴリページに統合する。noindex and consolidate into a parent or category page.
- ページがインプレッションと合理的な CTR（1%以上）を持つが、平均掲載順位が低い場合（40位以上）：保持するが、コンテンツ拡充を優先する。keep, but prioritise for content enrichment.
- ページが成果を上げているなら、そのままにしておいて、自分自身を疑うのをやめるべきだ。leave it alone and stop second-guessing yourself.
代理店のオーナーが静かに成約していたページをnoindexにしているのを見た回数は数え切れない。壊れていないものを直すな。
構造化データを品質シグナルとして（リッチリザルト対策だけではなく）
ほとんどの人がスキーマをpSEOページに追加するのはリッチリザルトのためだ。それは理解できる。だが私は、スキーマの完全性を品質ゲートの代理指標として扱い始めた。
ページのスキーマに30%を超えるnullプレースホルダー値がある場合、それは基盤となるデータが有用なページを生成するには希薄すぎることを示している。そのため、パイプラインにスキーマバリデーターを組み込んだ。使用しているタイプのSchema.org仕様に対して、必須プロパティと推奨プロパティをチェックする。このチェックに失敗したページは、エンリッチメントキューに戻される。Schema.org spec for whatever type we're using. Pages that fail this check go back into the enrichment queue.
Googleはスキーマの完全性を直接的なランキングシグナルとして使用しているか？単純な方法ではほぼ確実に使用していない。だが完全で正確なスキーマを持つページは、完全で正確なデータを持つページである傾向が強い。そしてそうしたページはランク付けされる傾向がある。相関が十分に強いため、たとえそれがメカニズムでなくても、スキーマの品質を有用な診断方法として扱う。those pages tend to rank. The correlation is strong enough that I treat schema quality as a useful diagnostic even if it's not the mechanism.
公開後の監視：機能し続けるゲート
品質ゲートは一度限りのものではない。ページは劣化する。データは古くなる。1月には問題がなかったページも、世界が変わってコンテンツが変わらなければ、10月には薄くなっているかもしれない。
管理している大規模なpSEOプロパティごとに、Screaming Frogを使用して月次クロールを実行し、以下にフラグを立てている：Screaming Frog on every large pSEO property we manage, flagging:
- ボイラープレート削除後の単語数が350語未満のページ
- タイトルタグがサイト内の3ページ以上と一致しているページ
- 内部リンクがゼロで指しているページ（孤立リスク）
これらをGSCのAPI経由でエクスポートしたデータと照合します。具体的には過去60日間でインプレッション数が40%以上減少したページを探しています。Screaming Frogでフラグが立てられ、かつGSCで減少しているページ（この交差点）が優先度の高いレビュー対象になります。and declining in GSC) is the high-priority review queue.
正直なところ、このモニタリングステップはほとんどのエージェンシーがコーナーを切る場所です。明らかな形で請求できないからです。しかしこのステップが、pSEOビルドが次のコアアップデート後も持続するか崩れるかを分ける要素です。
FAQ
AIを使ってコンテンツを生成すると自動的にGoogleペナルティが発動しますか？
いいえ。GoogleはAI生成コンテンツがガイドライン違反ではないことを明言しています。問題は役立たないコンテンツです。それがどのように作成されたかは関係ありません。シグナルは出所ではなく品質です。手書きの薄っぺらい重複ページは同じ扱いを受けます。重要なのは、そのページが代替案よりもユーザーのクエリに実際に適切に応えているかどうかです。応えていなければ、制作方法は無関係です。unhelpful content that's the problem, regardless of how it was produced. The signal is quality, not origin. A manually written page that's thin and duplicative will get treated the same way. What matters is whether the page genuinely serves the user's query better than the alternatives. If it doesn't, the method of production is irrelevant.
プログラマティックビルドで「多すぎる」ページ数はいくつですか？Googleが疑わしく思う前に。
正確な数字はありません。オンラインで見かけた具体的な数字は全て作られています。重要なのはインデックス登録されたページ数とランキング中のページ数の比率です。20,000ページあってインプレッション数が400ページだけなら、クロールバジェットと品質の問題です。Googleは残りを無視し始めます。20,000個の平凡なページより3,000個の強いページを公開する方がいいです。インデックスカバレッジ率が見るべきメトリクスです。ページ数の絶対値ではなく。
AI低品質ペナルティを受けた後、回復できますか？
そうです。ただし時間がかかりますし、直線的ではありません。冒頭で触れた旅行クライアントは回復しましたが、5ヶ月間にわたる継続的な作業が必要でした。最悪のページを削除し、中程度のものを統合し、上位のパフォーマーを充実させる作業です。最も影響力のあった単一のアクションは、インデックスを14,000ページから約4,200ページに削減したことでした。直感に反していますが、データがそう示していたのです。
大規模なサイトの中で「粗悪な」ページを特定する最速の方法は何ですか？
過去16週間のGSC パフォーマンスデータ全体を取得してください。0以上の表示回数がありながらもCTRが0.8%未満で、平均掲載順位が35より悪いページでフィルタリングします。そのコホートがあなたの問題セットです。単語数と内部リンク数と照合してください。低CTR、低単語数、孤立したページの重複は、プログラマティック構築のどの部分でも最も弱い部分です。
---
大規模での構築は、悪く構築する許可を与えません。私が説明したゲートは、新しいpSEOプロジェクトのセットアップ時間にして2～3日程度加わります。別の方法——コアアップデートに完全にやられた後に再構築する——はそれよりもはるかに多くのコストがかかります。両方のやり方をやってみたので知っています。