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でない、ジェネリックでないフィールドの数をカウントし、閾値以下のものにフラグを立てる。典型的には12中7を最小値として使用している。クリアしないレコードは「スタブ」カテゴリーに入り、noinexのシンページを取得するか、ページを作成しない。 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ページに追加するのはリッチリザルトのためだ。それは理解できる。だが私は、スキーマの完全性を品質ゲートの代理指標として扱い始めた。
ページのスキーマにnullまたはプレースホルダー値が30%以上含まれていれば、基盤となるデータが有用なページを作成するには不足していることを示しています。そこで、パイプラインにスキーマバリデータを組み込みました。使用している型について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日追加するだけです。代替案は、コアアップデートで完全に打たれた後に再構築することで、それはそれより多くのコストがかかります。両方やったので知っています。