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週間以内にドメイン全体のクロール予算を底に引きずり落とした。Google's Helpful Content system has been baked into the core ranking algorithm since late 2023, which means thin templated pages get downweighted at a site level, not just a page level. One bad batch can tank your whole domain. I've seen it. Seahawk had a travel aggregator project in late 2023 where 12,000 city pages -- each with roughly 90 words and a listings table -- dragged the entire domain's crawl budget into the floor within eight weeks of launch.
だから基準値は高くなっている。ただし機会はいまだに莫大だ。
---
データレイヤーがすべてだ
幅広さではなく深さを持つソースから始める
ほとんどのディレクトリビルダーは「50,000件のリスティングをどうやって取得するか」と問う。本来なら「各リスティングについて実際に何を知っているのか、他には誰も知らないことは何か」と問うべき。
100kレコード未満の小中規模プロジェクトではAirtableを使い、それより大きいものにはSupabaseまたは単純なPostgreSQLセットアップを使います。ツール自体より重要なのはスキーマです。データベースのすべてのリスティングには、差別化されたページコンテンツを生成できるフィールドが必要です。名前、住所、電話番号だけではなく、設立年、価格帯、平均レビューセンチメント、検証済みレビュー数、専門分野、最後の確認日、市街地中心部からの距離、物理的な場所があるか遠隔のみかといったことを考えてください。Supabase or a straightforward PostgreSQL setup for anything larger. The tool matters less than the schema. Every listing in your database should have fields that can generate differentiated page content. Not just name, address, phone. Think: year founded, price range, average review sentiment, number of verified reviews, specialisms, last verified date, distance from city centre, whether they have a physical location vs. remote-only.
フィールドが多いほど、オンページで差別化する角度が増える。シンプルにそれだけだ。
スクレイピング vs. ライセンスデータ vs. ユーザー投稿
正直なところ、3つすべてに役割があり、私は3つすべてを使用してきました。
- スクレイプされたデータは高速で安価ですが、急速に低下します。2021年にCompanies Houseデータをスクレイプしたイギリスの会計士ディレクトリを運営していましたが、14ヶ月以内にレコードの23%が古くなっていました。 is fast and cheap but degrades quickly. I ran a UK accountants directory in 2021 that scraped Companies House data. Within 14 months, 23% of the records were stale.
- ライセンスデータフィード（Dun & Bradstreet、Yext、または業種別APIなど）は高価ですが正確です。収益化モデルがそれに対応している場合は価値があります。(think Dun & Bradstreet, Yext, or vertical-specific APIs) are expensive but accurate. Worth it if your monetisation model supports it.
- ユーザー投稿のリスティングは始まりは遅いですが、Googleが報酬を与える新鮮性シグナルを生成します。リスティングが200個の合計でも、初日から「リスティングを請求する」フローを追加してください。 start slow but create the freshness signals Google rewards. Add a "claim your listing" flow from day one, even if you have two hundred listings total.
18～24ヶ月でトラフィックを複合するディレクトリはほぼ常に、ライセンスされたシードデータと継続的なユーザー貢献を混ぜるものだ。
---
テンプレートアーキテクチャ：誰も話さない部分
ほとんどのチュートリアルが省略することを説明しよう。ランクインするプログラマティックディレクトリと無限に濾過される1つの違いは通常、データレベルではなくテンプレートレベルにある。
1つのテンプレートでは不十分です
最低3つのテンプレート層が必要です：
- ハブページ -- 「ロンドンで最高の弁護士」スタイル。高い競争、エディトリアルトーン、手動でキュレートされたか大幅に充実させたもの。リンクをポイントするページはこれらだ。 -- "Best Solicitors in London" style. High competition, editorial tone, manually curated or heavily enriched. These are the pages you point links at.
- カテゴリ × 地域ページ -- 「マンチェスターのファミリーロー弁護士」。ミッドテール。これらはよりテンプレート化できるが、少なくとも1つの動的セクションが本当にユニークなデータ（レビュー数、平均手数料括弧、注目のリスティング）を引き出す必要がある。 -- "Family Law Solicitors in Manchester". Mid-tail. These can be more templated but need at least one dynamic section that pulls genuinely unique data (review counts, average fee bracket, notable listings).
- 個別リスティングページ -- リーフノード。これらはデータの豊かさで生死が分かれる。すべてのリスティングページが同じ60語の説明と電話番号を持っていれば、Googleはそれに素早く気づく。 -- The leaf nodes. These live or die by data richness. If every listing page has the same 60-word description and a phone number, Google will figure that out fast.
過去2年間に4つのディレクトリプロジェクトでこの分割をテストしました。明確な3階層のヒエラルキーを持つものは、インデックス作成の最初の90日以内にGoogle Search Consoleのインプレッションデータでフラットアーキテクチャを一貫して上回りました。偶然ではありません。Google Search Console impression data within the first 90 days of indexing. Not a coincidence.
実際に役立つ動的コンテンツブロック
AI生成の定型文でページを詰め込むのをやめます。代わりに、以下を取得するテンプレートロジックを構築します。
- 同じ郵便番号地区内の関連掲載
- 自社アナリティクスから「閲覧済みカテゴリ」も
- 「最終更新」タイムスタンプ。実際に正確なもの（JSで今日の日付を単に挿入したものではなく）
- ユーザーレビュースニペット、たとえ3つのレビューしかなくても -- 3つの本物は0個の偽物より優れている。
リーフノードのリスティングページに訪れたユーザーが、自分でGoogleで検索しただけでは得られない何かを持ち帰ることが目標です。
---
内部リンク：最も活用されていないランキング要因
ぶっちゃけ言うと、ほとんどのプログラマティックディレクトリは内部リンク構造が致命的です。ページは存在します。でも役に立つところには何もリンクしていない。Googleのクローラーが訪問して、行き止まりだと判断して、そのサブディレクトリ全体の優先度を下げてしまいます。
ディレクトリの適切な内部リンク構造はおおよそこんな感じです：
- ホームページ → トップハブページ（手動キュレーション、8～15リンク）
- ハブページ → カテゴリ×地域ページ（動的、リスティング数に基づく）
- カテゴリ×地域ページ → 個別リスティング（ページネーション、1ページあたり最大20～25件）
- 個別リスティング → 関連するカテゴリ×地域ページ（2～3件の文脈関連リンク）
- 個別リスティング → 距離ベースのクエリで「近くの」リスティング
最後のこれ――近くのリスティング――は過小評価されている。リーフノード内にクローラブルなウェブを作成して、Googlebotがハブに戻って跳ね返るのではなく、サイト内を移動し続けるようにする。2024年初頭にバーミンガムのクライアントの歯科ディレクトリで実装したところ、6週間以内にGSCのクロール率が3.4倍に上がった。
ローンチ後ではなく、ローンチ前にScreaming Frogを使ってリンクグラフを監査してください。無料層は最大500 URLに対応しており、テンプレートのサニティチェックに十分です。Screaming Frog to audit your link graph before you launch, not after. The free tier handles up to 500 URLs, which is plenty for a sanity check on your templates.
---
大規模なインデックス化対応——火傷を避ける方法
Googleはあなたの8万ページすべてをインデックスしません。それを受け入れてください。それに合わせて対応しましょう。
私が使っている実践的なアプローチ：
- ローンチ日のサイトマップには、ハブページとカテゴリ×ロケーションページのみを送信する
- Googlebotがリーフノードを発見するのはサイトマップではなく内部リンクを通じて行わせる
- 薄い、重複している、またはデータが少ないリスティングページを充実させるまでnoindexを積極的に使用してください
noindexaggressively on thin, duplicate, or low-data listing pages until you can enrich them - GSCでクロール予算レポートを設定し（設定 → クロール統計）、最初の3ヶ月間は週1回チェックする
noindexのアドバイスはいつも反発を食らいます。「でも全ページをインデックスしたいです！」そうですね。Googleも全ページが良好であることを望んでいます。40,000個の薄いページをインデックスして、同時にドメインオーソリティが健全という状態は持つことができません。どちらか一つを選んでください。noindex advice always gets pushback. "But I want all my pages indexed!" Yeah. And Google wants all of them to be good. You can't have 40,000 thin pages indexed and also have a healthy domain authority. Pick one.
もう1つ：ページネーション。適切な場所ではrel="next"とrel="prev"を正しく使いますが、ページネーション済みカテゴリページが本当に必要かどうかも検討してください。最近の3つのプロジェクトでは、ページネーション済みリスティングをJSロード型の「さらに表示」アプローチ（クローラー用の静的フォールバック付き）に置き換え、60日以内にGSC内でより整理されたインデックス作成パターンを確認しました。rel="next"and rel="prev"where appropriate, but also consider whether you need paginated category pages at all. On three recent projects I replaced paginated listings with a JS-loaded "show more" approach (with a static fallback for crawlers) and saw cleaner indexation patterns in GSC within 60 days.
---
大規模なコンテンツ充実化—正気を失わずに
よし。薄いページが死を招くことは認めたな。では、コンテンツライターのチームなしで 2万ページのリスティングを実際に充実させるにはどうするか？
実務で機能するいくつかのアプローチ：
- 構造化されたレビュー集約。Google Business ProfileのデータをそのAPIから取得するか、ToSが許す範囲でTrustpilotやYelpから慎重にスクレイピングする。星評価とレビュー数を構造化データとして表示するだけでも、測定可能な差別化を生む。Pull from Google Business Profile data via their API, or scrape (carefully) from Trustpilot or Yelp where ToS allows. Even a star rating + review count displayed as structured data adds measurable differentiation.
- 自動鮮度シグナル。リスティングを毎週チェックするスクリプトを書いて、ビジネスウェブサイト、電話番号、住所が変わっていないか確認する。レコードを更新する。ページに「最終確認日時」を表示する。これだけでも、法務ディレクトリのバウンス率が18%低下した――人々は最新データを信頼する。Write a script that hits your listings weekly and checks whether the business website, phone, or address has changed. Update the record. Show the "last verified" date on the page. This alone reduced our bounce rate on a legal directory by 18% -- people trust current data.
- LLM支援サマリー、慎重に使用。生データが十分にあるリスティングについて、GPT-4を使って構造化されたサマリーを生成している。ただし、プロンプトはそのリスティングの特定のデータフィールドに厳密に制限されている――汎用の説明文ではない。すべてのサマリーは、公開前に重複を検出するために類似度チェック（全コーパスに対して基本的なコサイン類似度スクリプトを使用）でフィルタリングされる。I do use GPT-4 to generate structured summaries for listings where we have enough raw data. But the prompt is tightly constrained to the specific data fields for that listing -- it's not generating generic blurb. And every summary is filtered through a similarity check (I use a basic cosine similarity script against the full corpus) to catch near-duplicate outputs before they go live.
---
マネタイズモデルはあなたのSEOアーキテクチャを形作る
これは人々を意表に突かせます。ディレクトリからお金を稼ぐ計画のやり方は、優先順位を付けるページ、必要なデータの深さ、ランキングに必要なコンテンツ充実化に費用を割けるかどうかに直接影響します。
一貫して機能しているモデルは3つあります。
- 有料リスティング・フィーチャード配置。シンプル。事業者が料金を支払って、より高い位置に、または拡張プロフィール付きで表示される。無料ティアの成長を促し、マーケットプレイスのダイナミクスを作る。Simple. Businesses pay to appear higher or with enhanced profiles. Incentivises you to grow the free tier to create the marketplace dynamic.
- リード生成。問い合わせフォームの送信を取得し、企業に売却します。コンバージョンあたりの収益は高いですが、フォーム送信に必要な信頼を獲得するために、かなり充実したリスティングページが必要です。You capture enquiry form submissions and sell them to businesses. Higher revenue per conversion but requires significantly richer listing pages to earn the trust needed for form fills.
- アフィリエイト／リファラル。ソフトウェア、ファイナンス、ホスピタリティのような、確立されたアフィリエイトプログラムがある分野で効果がある。SaaSツールカテゴリのニッチディレクトリは、キーワードターゲティングが適切であれば、5,000ページ未満で月10,000～30,000ポンドのこのモデルで達成できる。Works well in verticals like software, finance, or hospitality where there are established affiliate programmes. Niche directories in SaaS tool categories can hit £10k-£30k/month on this model with under 5,000 pages if the keyword targeting is right.
テンプレートを設計する前にモデルを選ぶ。リード生成ディレクトリは、初日からすべてのリスティングページに信頼シグナルと変換要素を組み込む必要がある――後から追加するのは聞こえほど簡単ではない。
---
FAQ
プログラマティックSEOはGoogleの2024年アルゴリズムアップデート後も機能しますか？
そう、だが「十分に良い」のしきい値は、わずか2年前と比べても大幅に高くなっている。2024年3月のGoogleコアアップデートは、テンプレート化されたAIコンテンツに依存する多くのシン・プログラマティックサイトに大きな打撃を与えた――特にユニークデータがないものは。genuine dataの深さと明確なエンティティ関係を持つサイトは問題なく乗り切った。垂直分野によっては、シンの競合が除外されたため、これらのサイトは実際に地盤を拡大した。March 2024 Google core update hit a lot of thin programmatic sites hard -- particularly those relying on templated AI content with no unique data. Sites with genuine data depth and clear entity relationships weathered it fine. In some verticals, those sites actually gained ground as thin competitors got filtered out.
初日にはどのくらいのページ数で立ち上げるべきですか？
Googleのコンセプトを実証するのに必要な最少限です。私は50,000の薄いページより、500の本当に良いページで立ち上げることを好みます。まずハブページと上位20のカテゴリ×地域の組み合わせを構築してください。インデックスされるのを待ち、早期のランキング信号を得て、その後はロングテールをバッチで展開します。初月に100,000ページに急いで到達するのはほぼ常に間違いです。
どのCMSまたはテックスタックを使うべきですか？
ほとんどのクライアントについて、私はWordPressをカスタム投稿タイプとACF Proを使ってデータベースから引き出す形で使用している。地味だが、構築が速く、引き継ぎが簡単で、SEOのためのプラグインエコシステム（特にRank Math）が成熟している。スケールが大きいプロジェクト――50,000ページ以上――では、通常、Next.jsとPostgreSQLまたはSupabaseバックエンドを使ってヘッドレスで行う。Next.jsのSSG/ISR機能は、スケール時にクロール動作をクリーンに保つために本当に有用だ。WordPress with a custom post type and ACF Pro pulling from a database. It's not glamorous but it's fast to build, easy to hand off, and the plugin ecosystem for SEO (Rank Math, specifically) is mature. For higher-scale projects -- over 50,000 pages -- I'll typically go headless with Next.js and a PostgreSQL or Supabase backend. The SSG/ISR capabilities in Next.js are genuinely useful for keeping crawl behaviour clean at scale.
プログラマティックディレクトリがランキングされ始めるまでどのくらいかかりますか？
現実的には、アーキテクチャをきちんと構築できていて、Googleが大手の確立したブランドを明確に優遇していない業界にいるなら、意味のあるトラフィックまで6〜9ヶ月かかります。4ヶ月で勢いをつけた例外的なケースも見ていますし、18ヶ月かかった残念なケースもあります。正直なところ、最も重要な変数はトピカルオーソリティです。つまり、初日からサイトが特定の業界における専門性をどれだけ明確に確立できるかということです。
---
ディレクトリSEOの戦術は廃れていません。Googleが適切に価格差別化しただけです。2023〜24年に失敗した運営者のほとんどは、価値ではなくボリューム狙いで構築していました。まず価値を狙って構築してください。深いデータ、正直なエンリッチメント、Googleが実際にクロールする方法を尊重したリンクアーキテクチャです。ボリュームは時間とともに自動的に増えていきます。常にそうなってきました。