2022年、あるクライアントがローカルサービスディレクトリの構築に£40,000を費やすのを見ました。デザインは素晴らしい。きれいなAirtableベースから自動生成された80,000ページ。3月にローンチ。6月には214ページがインデックスされ、何もランクインしていませんでした。問題はアイデアではなく、ディレクトリは今でもプログラマティックSEOの数少ない施策の1つで、深刻なオーガニックトラフィックに成長する可能性があります。問題は、技術的には完璧でしたが戦略的には完全に間違っていたことです。
このポストはその過ちを回避することについてです。
---
2026年のディレクトリにおけるプログラマティックSEOが実際に意味すること
人々はこのフレーズを1つのことのように使っていますが、そうではありません。ディレクトリの場合、プログラマティックSEOは1つのテンプレートと構造化されたデータソースから、数百から数千のロケーション、カテゴリ、属性スコープのページを生成し、各ページがGoogleに手書きの競合他社よりもランクインする理由を与える方法で実行することを意味します。
ほとんどのディレクトリがつまずく部分はそこだ。
2026年版のこのゲームは2019年よりも難しくなっています。Googleのヘルプフルコンテンツシステムは2023年後半からコアランキングアルゴリズムに組み込まれているため、シンテンプレートページはページレベルだけでなくサイトレベルで低く評価されます。1つの悪いバッチでドメイン全体が沈む可能性があります。見たことがあります。Seahawkは2023年後半に旅行アグリゲータープロジェクトを持っていて、各12,000都市ページはおおよそ90語とリスティングテーブルで、ローンチから8週間以内にドメイン全体のクロールバジェットを最低限に引きずり下ろしました。
だから基準値は高くなっている。ただし機会はいまだに莫大だ。
---
データレイヤーがすべてだ
幅広さではなく深さを持つソースから始める
ほとんどのディレクトリビルダーは「50,000件のリスティングをどうやって取得するか」と問う。本来なら「各リスティングについて実際に何を知っているのか、他には誰も知らないことは何か」と問うべき。
100kレコード未満の小中規模プロジェクトではAirtableを使い、それより大きいものにはSupabaseまたは単純なPostgreSQLセットアップを使います。ツール自体より重要なのはスキーマです。データベースのすべてのリスティングには、差別化されたページコンテンツを生成できるフィールドが必要です。名前、住所、電話番号だけではなく、設立年、価格帯、平均レビューセンチメント、検証済みレビュー数、専門分野、最後の確認日、市街地中心部からの距離、物理的な場所があるか遠隔のみかといったことを考えてください。
フィールドが多いほど、オンページで差別化する角度が増える。シンプルにそれだけだ。
スクレイピング vs. ライセンスデータ vs. ユーザー投稿
正直なところ、3つすべてに役割があり、私は3つすべてを使用してきました。
- スクレイプされたデータは高速で安価ですが、急速に低下します。2021年にCompanies Houseデータをスクレイプしたイギリスの会計士ディレクトリを運営していましたが、14ヶ月以内にレコードの23%が古くなっていました。
- ライセンスデータフィード（Dun & Bradstreet、Yext、または業種別APIなど）は高価ですが正確です。収益化モデルがそれに対応している場合は価値があります。
- ユーザー投稿のリスティングは始まりは遅いですが、Googleが報酬を与える新鮮性シグナルを生成します。リスティングが200個の合計でも、初日から「リスティングを請求する」フローを追加してください。
18～24ヶ月でトラフィックを複合するディレクトリはほぼ常に、ライセンスされたシードデータと継続的なユーザー貢献を混ぜるものだ。
---
テンプレートアーキテクチャ：誰も話さない部分
ほとんどのチュートリアルがスキップすることはこれです。ランクインするプログラマティックディレクトリと完全に濾過される1つの違いは、通常データレベルではなくテンプレートレベルにあります。
1つのテンプレートでは不十分です
最低3つのテンプレート層が必要です：
- ハブページ、「ロンドンの弁護士ベスト」スタイル。競争が激しく、編集的なトーン、手動でキュレーションされたか大幅に充実したもの。これらはリンクをポイントするページです。
- カテゴリ×ロケーションページ、「マンチェスターのファミリーロー弁護士」。ミッドテール。これはより多くテンプレート化できますが、本当にユニークなデータ（レビュー数、平均手数料帯、注目すべきリスティング）を引き出す少なくとも1つの動的セクションが必要です。
- 個別リスティングページ、葉ノード。これはデータの豊かさによって生き残るか消滅するかが決まります。すべてのリスティングページが同じ60語の説明と電話番号を持っている場合、Googleはそれをすぐに理解します。
過去2年間に4つのディレクトリプロジェクトでこの分割をテストしました。明確な3階層のヒエラルキーを持つものは、インデックス作成の最初の90日以内にGoogle Search Consoleのインプレッションデータでフラットアーキテクチャを一貫して上回りました。偶然ではありません。
実際に役立つ動的コンテンツブロック
AI生成の定型文でページを詰め込むのをやめます。代わりに、以下を取得するテンプレートロジックを構築します。
- 同じ郵便番号地区内の関連掲載
- 自社アナリティクスから「閲覧済みカテゴリ」も
- 「最終更新」タイムスタンプ。実際に正確なもの（JSで今日の日付を単に挿入したものではなく）
- ユーザーレビュースニペット、3つのレビューしかなくても、3つの本物は0個の偽物に勝ります。
リーフノードのリスティングページに訪れたユーザーが、自分でGoogleで検索しただけでは得られない何かを持ち帰ることが目標です。
---
内部リンク：最も活用されていないランキング要因
ぶっちゃけ言うと、ほとんどのプログラマティックディレクトリは内部リンク構造が致命的です。ページは存在します。でも役に立つところには何もリンクしていない。Googleのクローラーが訪問して、行き止まりだと判断して、そのサブディレクトリ全体の優先度を下げてしまいます。
ディレクトリの適切な内部リンク構造はおおよそこんな感じです：
- ホームページ → トップハブページ（手動キュレーション、8～15リンク）
- ハブページ → カテゴリ×地域ページ（動的、リスティング数に基づく）
- カテゴリ×地域ページ → 個別リスティング（ページネーション、1ページあたり最大20～25件）
- 個別リスティング → 関連するカテゴリ×地域ページ（2～3件の文脈関連リンク）
- 個別リスティング → 距離ベースのクエリで「近くの」リスティング
その最後のもの、近くのリスティングは過小評価されています。リスティングノード内で検索可能なウェブを作成し、Googlebot がハブに戻ってバウンスするのではなくサイト内を移動し続けるようにします。2024年初頭にバーミンガムのクライアント向けのデンタルディレクトリでこれを実装し、GSCからのクロールレートは6週間以内に3.4倍増加しました。
ローンチ後ではなく、ローンチ前にScreaming Frogを使ってリンクグラフを監査してください。無料層は最大500 URLに対応しており、テンプレートのサニティチェックに十分です。
---
大規模なインデックス化対応——火傷を避ける方法
Googleはあなたの8万ページすべてをインデックスしません。それを受け入れてください。それに合わせて対応しましょう。
私が使っている実践的なアプローチ：
- ローンチ日のサイトマップには、ハブページとカテゴリ×ロケーションページのみを送信する
- Googlebotがリーフノードを発見するのはサイトマップではなく内部リンクを通じて行わせる
- 薄い、重複している、またはデータが少ないリスティングページを充実させるまでnoindexを積極的に使用してください
- GSCでクロール予算レポートを設定し（設定 → クロール統計）、最初の3ヶ月間は週1回チェックする
noindexのアドバイスはいつも反発を食らいます。「でも全ページをインデックスしたいです！」そうですね。Googleも全ページが良好であることを望んでいます。40,000個の薄いページをインデックスして、同時にドメインオーソリティが健全という状態は持つことができません。どちらか一つを選んでください。
もう1つ：ページネーション。適切な場所ではrel="next"とrel="prev"を正しく使いますが、ページネーション済みカテゴリページが本当に必要かどうかも検討してください。最近の3つのプロジェクトでは、ページネーション済みリスティングをJSロード型の「さらに表示」アプローチ（クローラー用の静的フォールバック付き）に置き換え、60日以内にGSC内でより整理されたインデックス作成パターンを確認しました。
---
大規模なコンテンツ充実化—正気を失わずに
よし。薄いページが死を招くことは認めたな。では、コンテンツライターのチームなしで 2万ページのリスティングを実際に充実させるにはどうするか？
実務で機能するいくつかのアプローチ：
- 構造化されたレビュー集約。Google Business ProfileのデータをそのAPIから取得するか、ToSが許す範囲でTrustpilotやYelpから慎重にスクレイピングする。星評価とレビュー数を構造化データとして表示するだけでも、測定可能な差別化を生む。
- 自動化された鮮度シグナル。毎週リスティングにアクセスして、ビジネスウェブサイト、電話番号、住所が変更されていないか確認するスクリプトを書く。レコードを更新する。ページに「最終確認日」を表示する。これだけで、法律相談ディレクトリのバウンスレートが18%低下した。人は現在のデータを信頼する。
- LLMを使った要約、慎重に使用する。十分な生データがあるリスティングについては、GPT-4を使って構造化された要約を生成している。ただし、プロンプトはそのリスティングの特定のデータフィールドに厳密に制限されており、汎用的な説明文を生成しているわけではない。すべての要約は、類似性チェック（全体のコーパスに対する基本的なコサイン類似度スクリプトを使用）でフィルタリングされ、重複に近いアウトプットを本番前に検出する。
---
マネタイズモデルはあなたのSEOアーキテクチャを形作る
これは人々を意表に突かせます。ディレクトリからお金を稼ぐ計画のやり方は、優先順位を付けるページ、必要なデータの深さ、ランキングに必要なコンテンツ充実化に費用を割けるかどうかに直接影響します。
一貫して機能しているモデルは3つあります。
- 有料リスティング・フィーチャード配置。シンプル。事業者が料金を支払って、より高い位置に、または拡張プロフィール付きで表示される。無料ティアの成長を促し、マーケットプレイスのダイナミクスを作る。
- リード生成。問い合わせフォームの送信を取得し、企業に売却します。コンバージョンあたりの収益は高いですが、フォーム送信に必要な信頼を獲得するために、かなり充実したリスティングページが必要です。
- アフィリエイト／リファラル。ソフトウェア、ファイナンス、ホスピタリティのような、確立されたアフィリエイトプログラムがある分野で効果がある。SaaSツールカテゴリのニッチディレクトリは、キーワードターゲティングが適切であれば、5,000ページ未満で月10,000～30,000ポンドのこのモデルで達成できる。
テンプレートを設計する前に、モデルを選択する。リード生成ディレクトリは、初日からすべてのリスティングページに信頼シグナルとコンバージョン要素が組み込まれている必要がある。後から追加するのは、見た目よりもいつも複雑になる。
---
FAQ
プログラマティックSEOはGoogleの2024年アルゴリズムアップデート後も機能しますか？
そう、だが「十分」のしきい値は、2年前よりもはるかに高くなっている。2024年3月のGoogleコアアップデートは、多くの薄型プログラム型サイトに大きな打撃を与えた。特にテンプレート化されたAIコンテンツに頼り、ユニークなデータがないサイトが受けた。データの深さが本物でエンティティ関係が明確なサイトは問題なく乗り切った。一部の業界では、これらのサイトは薄型の競合他社がフィルタリングされたため、実際に成長を遂げた。
初日にはどのくらいのページ数で立ち上げるべきですか？
Googleのコンセプトを実証するのに必要な最少限です。私は50,000の薄いページより、500の本当に良いページで立ち上げることを好みます。まずハブページと上位20のカテゴリ×地域の組み合わせを構築してください。インデックスされるのを待ち、早期のランキング信号を得て、その後はロングテールをバッチで展開します。初月に100,000ページに急いで到達するのはほぼ常に間違いです。
どのCMSまたはテックスタックを使うべきですか？
ほとんどのクライアントについては、カスタムポストタイプとACF Proでデータベースから引き出すWordPressを使用している。派手ではないが、構築が速く、引き継ぎが簡単で、SEO向けのプラグインエコシステム（特にRank Math）が成熟している。より大規模なプロジェクト（5万ページ以上）については、Next.jsとPostgreSQLまたはSupabaseバックエンドでヘッドレス化する傾向がある。Next.jsのSSG/ISR機能は、スケールでクロール動作をクリーンに保つのに本当に役立つ。
プログラマティックディレクトリがランキングされ始めるまでどのくらいかかりますか？
現実的には、アーキテクチャが正しく実装されており、Googleが明示的に大規模な確立されたブランドを優先していない業界であれば、意味のあるトラフィックまでに6～9か月。4か月で牽引力を得た例外的なケースと、18か月かかった残念なケースを見てきた。最も重要な変数は、正直に言うと、トピカルオーソリティ、つまりサイトが初日から特定の業界でいかに明確に専門知識を確立するかである。
---
ディレクトリSEOプレイブックは死んでいない。Googleによって適切に価格差別化されただけだ。2023～24年に焼かれたオペレーターのほとんどは、価値ではなくボリュームのために構築していた。まず価値のために構築する。深いデータ、誠実な充実、Googleが実際にどのようにクロールするかを尊重するリンクアーキテクチャ。ボリュームは時間をかけて自動的に対応される。常にそうだった。