HostList.io の運営者が構築した、Helpful Content Update に対応するプログラマティック SEO。

2024年の初頭、HostListをサイドプロジェクトとして始めました。コンセプトは単純でした。インターネット上のすべてのウェブホスティング企業をカタログ化し、それぞれに実際のページと実際のレビューを提供し、ユーザーが本当に必要な方法でホストを比較できるようにするというものです。2年半が経過した現在、サイトには約28,000ページがあり、すべてが構造化データソースからプログラマティックに生成されています。私は個人的に、Helpful ContentアップデートがもたらしたあらゆるGoogleアップデートをサイトが乗り越える過程を見てきました。

プログラマティックサイトを始める際に誰も教えてくれないのは、作業の大部分は技術的ではなく編集的だということです。Next.jsの部分は2週間で完成します。Supabaseのスキーマ、インジェスションパイプライン、ストリーミングサイトマップ、schema.orgエミッター——これらはすべて解決済みのエンジニアリングです。残りの時間のほとんどは、28,000行のうちどれが実際にインデックスに値するのか、そしてテンプレートにどのような情報を追加すれば、データベース出力のようなものではなく実際のページとして読めるようになるのかを判断することに費やされます。

プログラマティックSEOを差し引きの学問として考えるようになりました。デフォルトの動きはすべての行を公開することです。正しい動きは、掲載するに値する行だけを公開し、その後、ページがサイトマップを埋めるため以上の理由で存在するようにするために十分な編集的文脈でそれらを包むことです。この2つのことを正しく実行すれば、Googleはコアアップデートの間、あなたを放っておきます。どちらか一方を誤れば、2四半期以内にインデックスされたページのほとんどを失います。

以下は、私がHostListで毎日実行するプレイブックであり、同じ形でクライアント業務に適用されています。これはマーケティングピッチではありません。実際のチェックリストです。

プログラマティックとして提案されてくるアイデアのほとんどは、プログラマティックであるべきではありません。電話での整理方法は、データセットが本当に興味深いかどうか、そして検索がロングテールにわたって本当に分断されているかどうかです。両方が真である必要があります。データセットが単なるSEOベイトで、検索があなたが想像するロングテールで本当に発生していない場合、プログラマティックは誤った形式であり、それでも先に進めば6か月以内にインデックスされたページを失うでしょう。

2026年に機能するパターンはほんの一握りで、かなり限定的です。比較サイトが機能するのは、検索者が既に関係者の名前を知っており、単にタイブレーカーが必要だからです。NotionとLinear、StripeとAdyen、CloudwaysとKinsta。ローカルインテント基本的に分断されており、誰もそれを大規模で手作業で書く人はほぼいないため、ロケーションページが機能します。エンティティ×フィルターの組み合わせが実際のボリュームを持つクエリを生成する場合、業界ディレクトリが機能します。HostList自体が正確にその形式を中心に構築されているため、それらを実行することからの失敗モードを知っています。用語が技術的に十分な場合、既存のウェブ上の回答が不十分な場合、用語集ページが機能します。計算自体とその下の方法論ページが検索者にとって実際の価値である場合、電卓ページが機能します。

私が提案されるすべてのほかのものは悪い版です。「100万ページの汎用コンテンツに自社ブランドを付けたいもの」という版で、通常は1四半期で有機トラフィックを10倍にすることを意図した成長実験としてパッケージされています。Googleは2022年後半のHelpful Contentアップデート以来、これに特に積極的であり、インデックス削除の波は加速しています。私は過去2年間に怠け者のプログラマティック作戦を試みた5つの異なるチームを見てきました。5つすべてが2四半期以内にインデックスされたページの大部分を失いました。長期的には誰にとってもより親切ですが、営業電話で不快なため、現在はこの作業を断っています。

3つのゲートはビルド時に実行され、どのページもサイトマップに到達する前に通過する。自動化されており手動レビューではない。なぜなら30,000 URLを手動レビューすることは実際のレビューではなく、それを装うことはデインデックスを遅延させるだけだからだ。

ゲート1は固有のデータである。HostListのCloudways管理型WordPress ホスティングについてのページを例にとれば、Cloudways固有のものが最低3つ必要だ。価格帯、機能リスト、地域、親会社、ユースケース。KinstaやWP Engineにも当てはまらないもの。ページが単に名前、ロゴ、および一般的な説明しか持たないのであれば、ゲートを通らない。サイトマップから除外される。ソースでnoindexが付く。データレイヤーは最終的には、チームが行を充実させるにつれて埋まり、ページはやがてインデックスに戻る道を開く。HostListでは現在、データベースのおよそ15%がこれだけの理由でサイトマップから除外されている。

ゲート2は編集的付加価値である。テンプレートはデータだけではできないことをしなければならない。比較、スコアリング、レコメンデーション、集約、長所と短所。データベースの行を良いタイポグラフィで単にレンダリングするだけのテンプレートでは足りない。タイポグラフィが良いとしても。このゲートはチームが実務で最も失敗しやすい。巧みなインジェスションを構築し、編集的ラッパーを見逃し、キーワード下で見た目が同じ2,000ページを出荷し、その後6ヶ月後にGoogleがそれらをデインデックスする理由に困惑する。ラッパーがあるからこそ、ページがサイトマップを埋めるための理由以上に存在することをGoogleに伝える。

ゲート3は真のクエリ意図である。すべてのURLは、人が実際に検索している可能性のあるクエリにマップされ、インデックスするに値する十分なボリュームが必要だ。月間50検索以下のクエリをターゲットとするページは、最初の2つのゲートを通過していても、通常はnoindexされる。なぜならサイトマップを汚染し、同じドメイン上の強いページのクロール予算を希薄化させるからだ。しきい値は業界によって変動する。隣接サイトのSearch Consoleデータを調べた後、プロジェクトごとに調整する。

インデックスから削除した最初のものはシンテール(thin tail)だった。データベースの約15%は、固有データのしきい値を満たさないためサイトマップから除外されている。名前、ロゴ、1行の一般的な説明だけを持つ行は、Googleが知るべきページではない。それをクロールするコストは、それをインデックスすることの価値より高い。5つ以上の強いリスティングを持たないカテゴリページも除外される。なぜなら薄いカテゴリは、スキーマが技術的に正しくても低労力として読まれるからだ。3件以下の結果を持つフィルタ組み合わせは、ビルド時のチェックによって自動的にnoindexされる。

保持して成長させたのは比較である。指定されたホスト間のヘッド・ツー・ヘッド(head-to-head)ページが、サイト上で最もコンバージョン率の高いページタイプであることが判明し、URL数の5%未満にもかかわらずすべてのコンバージョンの約30%を生成している。比較を別のテンプレートとして追加し、意図的にスケーリングした。強い固有データを持つカテゴリページも、一般的なバージョンを大幅に上回るパフォーマンスを示した。単なる「最高のWordPress ホスティング」ではなく、「10,000製品以下のWooCommerceストア向けの最高のWordPress ホスティング」。具体的。クエリベース。有用。修飾子が狭いほど、ページはより良いパフォーマンスを発揮する傾向があり、これはオンラインで読むSEOアドバイスの大部分に反する。

手書きのまま保持したページが重力の中心である。28,000ページのうち約200ページは完全に人間による編集記事である。方法論ページ、スコアリングルビック、「ホスティングプロバイダーの選択方法」ガイド、いくつかの強いカテゴリランディング。これらはプログラム的にはスケーリングできず、そもそもそのつもりではなかったが、トピック権威グラフで不均衡に大きな重みを持ち、すべてのリーフページはそれらにリンク戻す。27,800のプログラム的ページは200周回る。これが中核アップデートを生き残る構造だ。

データレイヤーはPostgresの上に置かれ、チームが既に実行している内容に応じてSupabaseまたは自己ホスティングのいずれかを通じて。すべてのファセット列は適切にインデックスされている。なぜならスケール時に、フィルタクエリの全テーブルスキャンは、ページ自体が遅くなるより前にボトルネックになるからだ。各コンテンツタイプは、実際のコンテンツと共に品質ゲート列(固有性スコア、完全性パーセンテージ、最終検証タイムスタンプ)を持つ専用エンティティテーブルを取得する。サイトマップ適格性ビューはしきい値以下の行を自動的にフィルタリングするため、サイトマップと基礎データは手動キュレーションなしで同期を保つ。

テンプレートは4つの形態がある。エンティティタイプごとの詳細テンプレート（ユニークデータ用の明示的なスロットと編集的な枠組みを備えた）。名前付きエンティティ間の比較用テンプレート（FAQPageスキーマ付き、ファーストパーティレビューが実際に存在する場合を除きAggregateRatingなし）。CollectionPageとItemListを使用したカテゴリおよびフィルタテンプレート（エンティティをページング、フィルタの組み合わせが無限重複URLを生成しないよう適切な正規URL処理付き）。および手書きの記事スキーマを使用した編集テンプレート（低ボリューム、高いトピックウェイト、リンクグラフの幹として扱われ、葉ではない）。

SEOスカッフォルディングはスケール時に最もチーム側が過小評価する部分である。サイトマップはテンプレートごとにチャンク単位でストリーム配信される。単一のsitemap.xmlは最大5万URLまでで、ほとんどのプログラマティックプロジェクトは初年度内にそれを超過するからだ。内部リンクはデータ自体から生成される—各ページはそのカテゴリ、ロケーション、名前付き競合他社、および機能重複による類似エンティティにリンクする。ビルド時のSEOリンターはデプロイごとにページのスライスをサンプリングし、H1カウント異常、メタディスクリプション範囲外、JSON-LD妥当性エラー、またはhreflangクラスタ整合性問題があれば、ビルドを失敗させる。ローンチ後、OtteryまたはProfoundを通じたAI Overview引用トラッキングは週単位で実行され、生成型検索エンジンがドメイン上のページを引用開始または引用停止した時点を検出する。

営業資料の理想的な価格ではなく、最近の実際のエンゲージメントから得た正当な範囲。1,000エンティティ未満の小規模プログラマティックビルドは6~9週間で18,000~30,000米ドルで実施。1,000~10,000エンティティ間の中規模作業（構造化データインポート付き）は8~14週間で30,000~60,000ドル。10,000~100,000エンティティ間のより大型プロジェクト（外部APIまたはスクレイピングソースに対するカスタム取り込みパイプライン付き）は12~18週間で50,000~90,000ドル。ローンチ後の継続運用、コンテンツ更新、品質ゲート保守のケアプランは月額500~3,000ドル。

各範囲にはデータスカッフォルディング、テンプレート、SEOリンター、および基本的な編集オーバーライド用管理ダッシュボードが含まれる。データ取得自体は含まれない。手動編集、スクレイピングインフラストラクチャ、サードパーティAPI費用、およびオリジナルブランドおよびデザイン作業はすべて別の請求項目である。有料トラフィック獲得もスコープ外である。プログラマティックSEOはオーガニック施策であり、有料メディアをエンゲージメントにバンドルしない。ほとんどのプロジェクトは各バンドの下位半分にきちんと収まる。上位半分はデータ取り込みまたは編集レイヤーが異常に複雑な、本当に複雑なビルド向けに存在する。