昨年、本当に可能だとは思わなかったマイルストーンを達成しました。同じスタック上で動作する3つの本番サイトを横断して、253,000個のプログラマティックページがインデックスされました。おもちゃのプロジェクトではありません。デモでもありません。実際のトラフィックと実際の収益を持つ実際のサイトです。

Deluxe Astrology（91,000ページ）、Not Another Sunday（137,000のベニュー掲載）、HostList（25,000のホスティング企業プロフィール）をどのように構築したのかを詳しく説明します。Supabaseクエリ、Next.jsのページアーキテクチャ、データパイプライン、そして最も重要なこととして、何が壊れたのか。かなり多くの物が壊れました。

オンラインのプログラマティックSEOコンテンツのほとんどは、ドキュメントに目を通して終わりにしたという感じです。これはそうではありません。私たちは1年以上これらのページをリリースし続け、Google Search Consoleのグラフを見つめ、クローブ予算制限に呪詛を放ち、ゆっくりと本当にスケーリングで機能するものを理解してきました。

目次

Programmatic SEO: How We Got 253K Pages Indexed with Next.js & Supabase

2025年のプログラマティックSEOが実際に意味すること

プログラマティックSEOは、テンプレートを使用して構造化データからスケーリングでページを生成することです。これが1文バージョンです。現実ははるかに複雑です。

2025年のGoogleのスタンスは明確ですが微妙です：彼らはプログラマティックコンテンツをプログラマティック_だから_罰することはありません。薄い、重複した、または役に立たない場合に罰します。Zapierの70,000個のインデックスされたページが$140M ARRに貢献している場合と、dev.toのケーススタディで287,000ページが近ゼロインデックス化された場合の違いは、1つのことに帰着します。各ページが、人間が検索バーに実際に入力したクエリに本当に答えているかどうかです。

Ahrefsデータは、すべてのウェブページの96.55％がゼロオーガニックトラフィックを取得していることを示しています。プログラマティックSEOは、同じコンテンツのバリエーションをただ立ち上げているだけの場合、この問題を増幅します。しかし、データが本当にユニークで、テンプレートが互いに意味のある違いのあるページを生成する場合は、仕事を大幅に解決することもできます。

私たちにとって機能する精神モデルは次のとおりです。すべてのプログラマティックページは、「これをブックマークするだろうか？」というテストに合格する必要があります。Googleから着陸したら、留まりますか？他の場所では見つけられないものを見つけられますか？答えが「いいえ」の場合は、公開しないでください。

3つのプロジェクト：本番の数値

実際に構築したもの、および数値の状況をレイアウトしましょう。

プロジェクト ページ コンテンツ タイプ 地理的範囲 主要な指標
Deluxe Astrology 91,000 星占い、有名人プロフィール、エンジェルナンバー、コスミックコイン、宝石、ヨガポーズ、ネームラボ、占星家ディレクトリ 30の言語 91Kのインデックスされたページ
Not Another Sunday 137,000 NRIスコア、写真、マップ付きのカフェ＆ロースターベニュー掲載 USA、UK、日本 137K固有のベニューページ
HostList 25,000 HostScoreアルゴリズムを使用したホスティング企業プロフィール 53カ国 25Kのインデックスされたプロフィール
合計 253,000

Deluxe Astrology：30の言語での91Kページ

Deluxe Astrologyは、単一言語の星占いサイトとして始まりました。規模は、コンテンツタイプと言語の交差点からもたらされました。考えてみてください。12のゾディアック記号×365日の毎日の星占い×30言語を持っている場合、1つのコンテンツタイプだけから131,000の潜在的なページにもう既にあります。私たちは選択的でした。すべての組み合わせがページを取得するわけではありませんが、占星術コンテンツの組み合わせ的な性質はpSEOに最適です。

有名人プロフィールセクションだけには28,840レコードがあり、各クロードによって充実しています。これには出生図分析、性格分析、および互換性インサイトが含まれています。データパイプラインについては後で詳しく説明します。

Not Another Sunday：137Kベニュー掲載

Not Another Sundayは、専門コーヒー発見プラットフォームです。すべてのカフェとロースターは、独自のNRI（Neighborhood Relevance Index）スコア、キュレーションされた写真、埋め込みマップ、営業時間、およびレビュー付きの一意のページを取得します。複数のAPI、ユーザー生成コンテンツ、および手動キュレーションからデータを引き出しています。

重要な洞察：ベニュー_が_同じではないため、2つのベニューページは同じに見えません。テンプレートは一貫していますが、データはそれを毎回異なって埋めます。ラテアートコンペティションを備えた4.8 NRIを持つ渋谷のカフェは、ホールセール限定操作を持つ3.2 NRIを持つブルックリンのロースターとは全く違って見えます。

HostList：53カ国の25Kホスティングプロフィール

HostListは世界中のホスティング企業をカタログ化しており、各企業にはHostScore、つまりアップタイム、価格設定、サポート応答性、およびユーザーレビューに基づくアルゴリズム評価があります。53カ国全体で25,000個のプロフィール。各プロフィール固有のパフォーマンスデータ、価格表、および比較ウィジェット付き。

スタック：Supabase、Next.js ISR、Vercel Edge

3つのプロジェクト全体で同じスタックを標準化しました。各部分が重要な理由は次のとおりです。

Supabase（PostgreSQL + pgvector）：データレイヤー全体はSupabaseに存在します。PostgreSQLは複雑なクエリに必要な関係構造を提供します（12月に生まれた同じ太陽記号で同じ職業でもあるミュージシャンであるすべての射手座の有名人を与えてください）、pgvectorはコンテンツ全体にセマンティック検索を強化します。Supabaseの無料層は500MBを処理します。Pro at $25/monthの場合、ページごとに8GB、無制限のAPI呼び出しを備えたデータベース。

ISR（段階的静的再生成）を使用したNext.js：すべてのページは、ビルド時または最初のリクエスト時に静的に生成され、スケジュールで再検証されます。つまり、Googleのクローラーは常に高速でプリレンダリングされたHTMLページにヒットします。クライアント側のJavaScript を待つロードスピナーではありません。generateStaticParamsでパス生成を使用してApp Routerを使用します。

Vercel Edge：デプロイメント、CDN、エッジミドルウェアすべて1つで。Vercelの月額$20/ユーザーのProプランにより、1TBの帯域幅が提供され、253Kページからのトラフィックを快適に処理できます。エッジミドルウェアはDeluxe Astrologyの30言語セットアップのジオルーティングを処理します。

3つのプロジェクトすべての総インフラストラクチャコストは約$150～200/月です。253,000ページをホストしており、毎月数百万のクロール取得します。プログラマティックサイトを構築していて、Next.js開発機能またはヘッドレスCMSアーキテクチャを検討している場合は、このスタックをお勧めします。

Programmatic SEO: How We Got 253K Pages Indexed with Next.js & Supabase - architecture

データパイプラインアーキテクチャ

データはプログラマティックSEOの成功を左右します。テンプレートは簡単です。数万ページの本当にユニークで高品質なデータを取得すること？それが難しい部分です。

私たちは、プロジェクト全体で4種類のデータソースを使用しています。

1. APIスクレイピング

Not Another Sundayは、Google Places API、Yelp Fusion API、および日本用の少数の地域APIからベニュー データを引き出します。Supabase Edge Functionsを介した毎夜のシンク ジョブを実行して、新しいベニュー、更新された営業時間、および閉じられた場所をチェックします。各APIレスポンスは、挿入前にスキーマに正規化されます。

2. 検証付きCSVインポート

HostListの初期データセットは、2年間でコンパイルされたホスティング企業の大規模なCSVから来ました。重複をチェックし、会社名を正規化し、不完全なレコードに旗を立てる検証パイプラインを構築しました。初期インポートの約30％は旗を立てられ、手動レビューが必要でした。

3. Claude AIエンリッチメント

ここが興味深くなります。Deluxe Astrologyでは、28,840の有名人レコードに基本的な伝記データ（名前、誕生日、生まれた場所）がありました。これは有用なページには十分ではありません。Claudeを使用しました（AnthropicのAPI）各レコードを、出生図の解釈、性格分析、キャリア互換性インサイト、および楽しい事実で充実させます。

重要なこと：私たちは何もないからコンテンツを_生成_するためにClaudeを使用しませんでした。私たちはそれを実際の天文学的データを_分析して解釈_するために使用しました。各有名人の出生図は、彼らの出生データから数学的に計算され、その後Claudeが占星術の解釈を提供します。基礎となるデータはユニークで検証可能です。AIレイヤーは深さを追加し、捏造ではありません。

これが簡略化されたバージョンの充実パイプラインです。

import anthropic
from supabase import create_client

client = anthropic.Anthropic()
supabase = create_client(SUPABASE_URL, SUPABASE_KEY)

def enrich_celebrity(record):
    natal_chart = calculate_natal_chart(
        birth_date=record['birth_date'],
        birth_place=record['birth_place']
    )
    
    prompt = f"""Given this natal chart data for {record['name']}:
    Sun: {natal_chart['sun_sign']} in {natal_chart['sun_house']}
    Moon: {natal_chart['moon_sign']} in {natal_chart['moon_house']}
    Rising: {natal_chart['ascendant']}
    
    Write a 300-word astrological personality profile focusing on 
    how these placements manifest in their career as a {record['profession']}.
    Include specific aspect interpretations."""
    
    response = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}]
    )
    
    supabase.table('celebrities').update({
        'natal_chart': natal_chart,
        'ai_profile': response.content[0].text,
        'enriched_at': 'now()'
    }).eq('id', record['id']).execute()

約1週間にわたってすべての28,840レコードを処理し、レート制限内にとどまるようにリクエストをバッチ処理しました。費用は約$180のAPIクレジットです。ほぼ29Kページをユニークなコンテンツで充実させるのに悪くない。

4. ユーザー生成コンテンツ

Not Another Sundayは、ユーザーからのレビューと写真の提出を受け入れます。このUGCは時間とともにページを益々ユニークにし、コンテンツが新鮮でコミュニティ主導であることをGoogleに示します。

Googleが嫌わないページテンプレートアーキテクチャ

ほとんどのプログラマティックSEOプロジェクトが失敗するところはここです。彼らはテンプレートを次のように作成します。

<h1>{City} {Service} Directory</h1>
<p>Looking for {service} in {city}? Browse our directory of {count} providers.</p>

それは薄いコンテンツです。Googleはそれを知っています。ユーザーはそれを知っています。これをしないでください。

私たちのテンプレートアーキテクチャは、すべてのページに5つのユニークな要素があることを保証します。

  1. ユニークなH1：パターンに挿入される{name}にすぎません。H1構造はコンテンツタイプと文脈修飾子によって異なります。

  2. ユニークなメタ説明：ブランクが入力されたテンプレートではなく、実際のページデータから生成されます。

  3. ユニークなボディコンテンツ：これが大きなものです。各ページには、そのエンティティに固有の400～2,000語のコンテンツがあります。有名人の場合、それは彼らの出生図分析です。ベニューの場合、それらのNRI分解、近所文脈、およびメニューハイライトです。ホスティング企業の場合、それはHostScore分解、特定のアップタイム率、および価格表です。

  4. 構造化データ（schema.org）：すべてのページは、その種類に適切なJSON-LDマークアップを取得します。有名人の場合はPerson、ベニューの場合はLocalBusiness、ホスティング企業の場合はOrganization。

  5. 内部リンク：各ページは、実際のデータ関係に基づいて5～15の関連ページにリンクしています。有名人ページは、同じ太陽記号、同じ職業、または同じ生年を持つ他の有名人にリンクしています。ベニューページは近くのベニューと同じNRIスコアを持つベニューにリンクしています。

内部リンク部分は、インデックス化に対する最も重要な要因であることが判明しました。修正セクションでの詳細情報。

実際のコード：Supabaseクエリからレンダリングされたページまで

Not Another Sundayベニューページの実際のフローを見せましょう。これは本番コードで、読みやすくするために少し簡略化されています。

まず、Supabaseクエリレイヤー：

// lib/queries/venues.ts
import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
)

export async function getVenueBySlug(slug: string) {
  const { data, error } = await supabase
    .from('venues')
    .select(`
      id, name, slug, description, nri_score,
      address, city, country, lat, lng,
      opening_hours, photos, menu_highlights,
      created_at, updated_at,
      venue_reviews (
        id, rating, body, author_name, created_at
      ),
      venue_tags (
        tag:tags ( name, slug )
      )
    `)
    .eq('slug', slug)
    .eq('status', 'published')
    .single()

  if (error) throw error
  return data
}

export async function getRelatedVenues(venueId: string, city: string, nriScore: number) {
  const { data } = await supabase
    .rpc('get_related_venues', {
      p_venue_id: venueId,
      p_city: city,
      p_nri_score: nriScore,
      p_limit: 12
    })

  return data ?? []
}

get_related_venues関数は、NRIスコアの近さでソートされた近くのベニューを返すSupabaseのPostgreSQL関数です。

CREATE OR REPLACE FUNCTION get_related_venues(
  p_venue_id UUID,
  p_city TEXT,
  p_nri_score NUMERIC,
  p_limit INT DEFAULT 12
)
RETURNS TABLE (
  id UUID, name TEXT, slug TEXT, 
  nri_score NUMERIC, city TEXT, country TEXT
) AS $$
BEGIN
  RETURN QUERY
  SELECT v.id, v.name, v.slug, v.nri_score, v.city, v.country
  FROM venues v
  WHERE v.id != p_venue_id
    AND v.status = 'published'
    AND v.city = p_city
  ORDER BY ABS(v.nri_score - p_nri_score) ASC
  LIMIT p_limit;
END;
$$ LANGUAGE plpgsql;

次にApp Routerを使用するNext.jsページコンポーネント：

// app/venues/[country]/[city]/[slug]/page.tsx
import { getVenueBySlug, getRelatedVenues } from '@/lib/queries/venues'
import { VenueHeader } from '@/components/venue/VenueHeader'
import { NRIScoreCard } from '@/components/venue/NRIScoreCard'
import { VenueMap } from '@/components/venue/VenueMap'
import { ReviewSection } from '@/components/venue/ReviewSection'
import { RelatedVenues } from '@/components/venue/RelatedVenues'
import { venueJsonLd } from '@/lib/schema/venue'
import { notFound } from 'next/navigation'

export const revalidate = 3600 // ISR: revalidate every hour

export async function generateMetadata({ params }: Props) {
  const venue = await getVenueBySlug(params.slug)
  if (!venue) return {}

  const reviewCount = venue.venue_reviews?.length ?? 0
  const avgRating = reviewCount > 0
    ? (venue.venue_reviews.reduce((sum, r) => sum + r.rating, 0) / reviewCount).toFixed(1)
    : null

  return {
    title: `${venue.name} -- Specialty Coffee in ${venue.city} | NRI ${venue.nri_score}`,
    description: avgRating
      ? `${venue.name} in ${venue.city} scores ${venue.nri_score}/10 NRI. Rated ${avgRating}/5 from ${reviewCount} reviews. ${venue.description?.slice(0, 80)}...`
      : `${venue.name} in ${venue.city} scores ${venue.nri_score}/10 on our Neighbourhood Relevance Index. ${venue.description?.slice(0, 100)}...`,
    alternates: {
      canonical: `/venues/${params.country}/${params.city}/${params.slug}`
    }
  }
}

export default async function VenuePage({ params }: Props) {
  const venue = await getVenueBySlug(params.slug)
  if (!venue) notFound()

  const related = await getRelatedVenues(venue.id, venue.city, venue.nri_score)

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(venueJsonLd(venue)) }}
      />
      <article>
        <VenueHeader venue={venue} />
        <NRIScoreCard score={venue.nri_score} breakdown={venue.nri_breakdown} />
        <VenueMap lat={venue.lat} lng={venue.lng} />
        <section className="venue-body">
          <h2>About {venue.name}</h2>
          <p>{venue.description}</p>
          {venue.menu_highlights && (
            <>
              <h3>Menu Highlights</h3>
              <ul>
                {venue.menu_highlights.map(item => (
                  <li key={item}>{item}</li>
                ))}
              </ul>
            </>
          )}
        </section>
        <ReviewSection reviews={venue.venue_reviews} />
        <RelatedVenues venues={related} currentCity={venue.city} />
      </article>
    </>
  )
}

revalidate = 3600に注意してください。これはISRです。ページは最初のリクエスト時に静的に生成され、1時間キャッシュされます。Googleのクローラーは常に高速HTMLを取得します。新しいデータは次の再検証サイクルに流入します。これはクローブ予算に大きく影響します。

何が壊れたのか、そしてどうやって修正したのか

これはほとんどのケーススタディが不正直になるところです。彼らは数ヶ月のデバッグなしに結果を見せています。3つの大きな問題がありました。

問題1：Deluxe Astrology——クローブ予算の飢餓

91,000ページとフラットなサイトマップ構造でローンチしました。Googleは最初の月に約12,000ページをインデックスしてから...停止しました。GSCカバレッジレポートは、数万のURLについて「発見——現在インデックスされていない」を示しました。

問題は2つありました。まず、サイトマップは91,000のURLを含む単一ファイルでした。Googleは最大50,000をお勧めしていますが、その制限内でも、単一の大規模なサイトマップはプライオリティを示しません。次に、内部リンクが弱かった。多くのページはサイトマップを通じてのみアクセス可能で、オンページリンク経由ではありませんでした。

修正：

  1. サイトマップ再構築：モノリシックなサイトマップをカテゴリベースのサイトマップに分割しました。sitemap-celebrities.xml、sitemap-horoscopes-en.xml、sitemap-horoscopes-es.xmlなど。各10,000未満のURL。

  2. 内部リンクの大規模改修：すべてのページの文脈的なクロスリンクを追加しました。有名人ページは関連する有名人（同じ黄道帯、同じ職業、同じ生年）にリンクしています。星占いページはそのサイン用の有名人プロフィールにリンクしています。すべてのページが少なくとも8つの他のページに接続されています。

  3. 薄いページの削除：200語未満の独自コンテンツを持つ約4,000ページを削除しました。これらはほとんどが自動生成された組み合わせページで、価値を追加していません。ページ数が少ないですが、品質が高くなります。

これらの変更後、インデックス化は12Kから91Kまで約10週間で上昇しました。内部リンク化は最大のレバーでした。

問題2：HostList——ISR設定ミス

HostListは、すべてのページでexport const dynamic = 'force-dynamic'でローンチしました。つまり、すべての単一リクエスト（Googlebot クロールを含む）が毎回Supabaseに時間の実行をヒットしました。Googleは1日あたり数千ページをクロールしているため、Supabaseインスタンスはハンマーで叩かれ、応答時間がスパイク、一部のページはクロール中にタイムアウトしました。

修正： export const revalidate = 3600に切り替えました。ページは静的にキャッシュされ、100ミリ秒以下で機能します。Supabaseは1日あたり1回のリクエストごとに1回だけヒットします。p95応答時間は2.8秒から47ミリ秒に低下しました。Googlebotは、待ち回ることがないため、1日あたり3倍多くのページをクロールしました。

問題3：Not Another Sunday——国全体での重複コンテンツ

いくつかのカフェチェーン複数の国で操業しています。東京のスターバックスリザーブとロンドンのスターバックスリザーブは、テンプレートがブランド情報を強調したため、初期段階では非常に類似したページコンテンツを持っていました。

修正： ロケーション固有のコンテンツの重み付けを大幅に高めました。近所の説明、近くのベニューの比較、ローカルレビューセンチメント、および国固有の価格設定は、各ページの70％以上を構成しています。ブランド情報は小さなセクションです。Googleはこれらを近似複製として旗を立てなくなりました。

結果：ホッケースティックと誠実な失敗

3つのプロジェクト全体のGSC Data構成では、古典的なホッケースティック曲線が示されています。Googleのクローラーが当社のドメインに信頼を獲得したときは、フラットで数週間、指数関数的な成長です。

メトリック 1か月 3か月 6か月 12か月
インデックス化されたページ合計 18,200 67,000 189,000 253,000
毎日のオーガニッククリック 340 2,100 8,400 19,600
すべてのクエリの平均位置 42 28 16 11
クロールリクエスト/日（すべてのサイト） 4,200 12,800 31,000 48,000
月次Supabaseコスト $75 $75 $125 $150
月次Vercelコスト $40 $60 $60 $60

しかし、失敗についても正直に言いましょう。12ヶ月後、約8％のページはまだ「発見——現在インデックスされていない」で機能しています。これらは傾向として、最小限のトラフィック可能性があるページです。低検索ボリューム言語での特定の天使の番号ページ、または小市場のホスティング企業。より多くの内部リンクでそれらをインデックス化する可能性がありますが、ROIはそこにはありません。

また、4か月周辺で、Deluxe AstrologyのトラフィックがGoogleコアアップデート後30％下降した期間がありました。当社の側に変更がないまま6週間で回復しました。しかし、これはストレスの多い週でした。プログラマティックサイトは、Googleがページコーパス全体にわたって品質シグナルを再評価するため、コア更新中より揮発性であるように見えます。

このスケールで何か構築することを検討している場合、当社のアプローチと価格設定を価格ページで詳しく説明しました。純粋な静的pSEOのためのAstroベースの静的サイト生成——当社も実験しました——当社のAstro開発機能を確認してください。

プログラマティックSEO vs 従来のコンテンツ：どちらをどのような時に使うか

プログラマティックSEOは編集コンテンツの代替品ではありません。異なる仕事のための異なるツールです。

係数 プログラマティックSEO 従来のコンテンツ
最適 データ駆動型クエリ（「渋谷で最高のカフェ」、「レオ星占い今日」） 意図駆動クエリ（「ポーオーバーコーヒーの淹れ方」）
コンテンツユニークネス ページごとのユニークなデータから来ます ユニークなパースペクティブ/リサーチから来ます
スケーリング速度 1週間あたり1,000+ページ 週あたり2～5記事
保守負担 データベース更新、テンプレート修正 定期的なコンテンツ更新
Googleトラスト構築 より遅い（スケーリングで品質を証明する必要があります） より速い（各部分は個別に判断されます）
リスクプロフィール より高い（薄いコンテンツペナルティはサイト全体に影響します） より低い（1つの悪い記事はドメインをタンクしません）

甘い場所はその両方を組み合わせています。Not Another Sundayには137Kプログラマティックベニュー ページ_および_200+コーヒー文化、醸造方法、都市固有のカフェクロール ルートに関する編集ガイドがあります。編集コンテンツはE-E-A-Tシグナルを構築し、ドメイン全体を持ち上げ、プログラマティックページを高速化するのに役立ちます。

FAQ

プログラマティックSEOで現実的にインデックスできるページ数は？

それはドメイン権限とコンテンツ品質に完全に依存します。バックリンクプロフィルが強い確立されたドメイン上では、100K+ページの90%+インデックス化率を見てきました。新しいドメインは苦労します。dev.toケーススタディ、新鮮なドメインで287Kページをほぼゼロ索引化することは例外ではなく、規範です。1,000～5,000の高品質ページから始めて、権限を構築してから、スケール化します。

薄いコンテンツペナルティを回避するためのページごとの最小コンテンツは何ですか？

1ページあたり少なくとも400語のユニークコンテンツ、構造化データ、画像、および内部リンクを目指しています。しかし、単語数だけがメトリックではありません。それはページが既に存在するものよりもユーザーのクエリに答えているかどうかについてのものです。200語のページ、ユニークなデータテーブルとマップを持つページ、2,000語の一般的なテキストのページを上回る可能性があります。

プログラマティックSEOはGoogleの2025年有用コンテンツアップデート後もまだ安全ですか？

はい、しかし、本当に有用なページを作成している場合のみです。Googleの2025年のアップデートは、検索トラフィック以外を提供せずにキャプチャするためにのみ存在する低品質のプログラマティックコンテンツを具体的に対象としています。Zapierのような場所（70Kページ、$140M ARR）は、ページが実際の問題を解決するため、繁栄し続けています。ペナルティを受けているサイトは、その背後に実際のデータなしに「Best {service} in {city}」のバリエーションを生成しているものです。

Supabase、Vercelを使用したプログラマティックSEOスタックの費用はいくらですか？

3つのプロジェクトスタックは約$150～200/月で実行されます。Supabase Proは1プロジェクトあたり月額$25です（当社は3つのインスタンスを使用しています）。Vercel Proは$20/ユーザー/月です。ClaudeのAPIを介したAIエンリッチメント28,840レコードは約$180の1回限りコストでした。50K未満のページのほとんどのプロジェクトでは、インフラストラクチャコストが月額$50～100と予想します。

Googleでプログラマティックページをインデックスする のにどのくらい時間がかかりますか？

サイトマップの初期クロールには2～4週間かかると予想します。ただし、大規模ページセットの完全なインデックス化には3～6か月かかります。経験は、ホッケースティックパターンを示しています。最初の6～8週間の遅いクロール、Googleは品質を評価します。その後、コンテンツがインデックスする価値があると判断すると、高速に加速します。内部リンクとサイトマップ構造がこのタイムラインに大幅に影響します。

プログラマティックSEOページ用にNext.js SSRまたはISRを使用すべきですか？

ISRで、ほぼ常に。SSR（force-dynamic）は、クローラーリクエストがデータベースにヒットすることを意味し、スケーリングでパフォーマンスの問題を作成し、クローブ予算を遅いレスポンスで浪費します。ISR revalidate = 3600（または毎日の更新のために86400も）で、静的サイトのパフォーマンスの動的データ鮮度を取得します。HostListの場合、force-dynamicからISRへの切り替えで、応答時間は2.8秒から47ミリ秒に低下しました。

100K+ページにわたって内部リンクを処理するにはどうすればよいですか？

データベース駆動型の関連コンテンツクエリ。すべてのページは、実際のデータ関係に基づいて8～15の関連ページを見つけるクエリを実行します。同じカテゴリ、スコアの類似性、地理的近接性、共有属性。ページにランダムにリンクしないでください。リンクはユーザーとGoogleの両方に文脈的な意味がある必要があります。Supabaseでこれらの関係を効率的に計算するためにPostgreSQL関数を使用しています。

プログラマティックSEOで人々が犯す最大の間違いは何ですか？

ページ品質の代わりにページ数に焦点を当てています。10,000の優れたページは、100,000の平凡なページを毎回上回ります。Deluxe Astrologyで4,000の薄いページを削除し、残りのページをインデックス化_増加_を見ました。Googleは薄いページをシグナルとして解釈し、あなたのサイト全体がサイト全体が低品質である可能性があります。プログラマティックページをしっかりした方法で構築する準備ができたら、当社のチームに連絡してください。これらのレッスンを学ぶ必要がないようにしました。