ContentfulのSEO
ContentfulはHTMLを生成しません。SEOはフロントエンドの仕事です。レンダリング方式、SEOコンテンツモデル、サイトマップ、Preview APIの保護、リダイレクト、JSON-LDを日本語で解説します。
言語
このページには証拠シグナルが1件あります
- 関連するライブツールRaw vs. Rendered HTML Checker
ContentfulはヘッドレスCMSであり、API経由でコンテンツを配信するだけでHTMLは生成しません。そのため、SEOの結果はすべて利用するフロントエンドで決まります。レンダリングが最重要で、SSGとSSRは完成したHTMLを配信するため安全ですが、CSRはGoogleでは遅く、Bingや多くのAIクローラーでは失敗します。ContentfulにSEO機能は組み込まれていないので、メタデータ、サイトマップ、robots.txt、リダイレクト、hreflang、構造化データと明示的なSEOフィールドをフロントエンドに実装します。Preview APIの下書きはrobots.txtだけに頼らず、ホストレベルのnoindexまたは認証で保護します。
TL;DR — Contentfulはコンテンツを保存して構造化する場所であり、Webページを構築する場所ではありません。Next.jsやAstroなどで作った別のWebサイトへAPI経由でコンテンツを渡し、検索エンジンが実際に見るのはそのサイトです。つまりContentful自体がSEOを行うわけではなく、組み込みのタイトルタグ、サイトマップ、
robots.txtもありません。ヘッドレス構成の大原則は、サーバー上またはビルド時にページを生成して検索エンジンへ本物のHTMLを渡し、タイトル・説明・サイトマップなどのSEOの基本を自分で再構築することです。
Contentfulとは何か
ContentfulのSEOをめぐる混乱は、1つの点を理解するとほぼ解消します。ContentfulはWebサイトではなく、コンテンツリポジトリです。 WordPressのような従来型CMSでは、文章を書く場所とWebページに変換する場所が同じシステムです。Contentfulではそれらが分離しています。Contentfulでコンテンツをモデル化・作成し、APIを通じて生のデータ（JSON）として配信します。Next.js、Astro、Gatsby、Nuxtなどで作った別のWebサイトがそのデータを取得し、人間と検索エンジンが見る実際のページを構築します。
Evidence for this claim Contentful is a headless content platform that delivers structured content through APIs rather than a coupled page renderer. Scope: Contentful platform architecture; the consuming frontend determines HTML output. Confidence: high · Verified: Contentful: What is headless CMS?そのため「ContentfulはSEOに向いていますか？」という質問への正直な答えは、Contentful自体にはSEO機能がほとんどない、です。SEOを決めるのは、Contentfulからデータを取得してページを生成するフロントエンドです。
ContentfulにSEOは組み込まれていない
WordPressから移行した人がつまずきやすい点です。Contentfulの中にYoastのようなプラグインはありません。Contentfulはタイトルタグ、メタディスクリプション、サイトマップ、§robots.txt§、構造化データ、canonicalタグを標準で提供しません。そうしたものはフロントエンドの責任です。
- タイトルタグまたはメタディスクリプション
- XMLサイトマップ
- §
robots.txt§ - 構造化データ
- canonicalタグ
これは欠陥ではなく、Contentfulの仕事ではないというだけです。これらはすべて、フロントエンドのビルド工程やリクエスト処理の中で実装します。ContentfulのSEOガイドは機能一覧ではなく、ContentfulフロントエンドにSEOを組み込むための実装ガイドです。
最も重要な判断：レンダリング
Googlebot（または人）がページを要求したとき、完成したHTMLはどこで作られるのでしょうか。安全な答えは2つ、リスクのある答えは1つです。
- ビルド時（SSG） — ページをプレーンなHTMLファイルとして事前生成します。SEOに適しています。
- リクエストごとのサーバー（SSR） — サーバーが完全なページを構築して返します。これもSEOに適しています。
- 訪問者のブラウザー（CSR） — サーバーはほぼ空のシェルを返し、あとからJavaScriptが埋めます。これがリスクのある方式です。
GoogleはCSRのページを最終的には読めますが、処理は遅く、信頼性も下がります。Bingや、ChatGPT・Perplexityのようなツールの背後にいる多くのAIクローラーは、空のシェルしか見ないことがあります。見つけてほしいContentfulページは、サーバーまたはビルド時にレンダリングしてください。
Evidence for this claim Google processes JavaScript pages through crawling, rendering, and indexing, so content absent from initial HTML depends on rendering. Scope: Google Search; this does not characterize every non-Google or AI crawler. Confidence: high · Verified: Google: JavaScript SEO basics実際にあなたが行うこと
- ContentfulのコンテンツモデルにSEOフィールド（メタタイトル、メタディスクリプションなど）を追加し、編集者が入力できるようにする。
- 開発者がそのフィールドをページのHTMLへ接続する。
- フロントエンドまたはホストでサイトマップとrobots.txtを構築する。
- ステージングとプレビューをGoogleから除外する。ここから公開環境へ漏れることがよくあります。
4つのレンダリング方式、実際に使えるSEOコンテンツモデル仕様、Delivery APIからのサイトマップ、Preview APIの保護、リダイレクト、構造化データまで詳しく知りたいですか？ Advancedタブへ進んでください。
TL;DR — ContentfulはAPIファーストでHTMLを生成しないため、検索エンジンが見るのはフロントエンドの出力だけです。SEOの結果はすべてフロントエンドの判断になります。SSGとSSRは完成したHTMLを配信するのでGoogle、Bing、AIクローラーで安全です。CSRはリスクがあり、Googleのインデックスは遅く、Bing・Yandex・Baiduや多くのAIボットではインデックスされないことがあります。Dynamic Renderingは非推奨です。Contentfulには組み込みSEOがないため、コンテンツモデルの明示的なSEOフィールド（ページ内統合または専用型）、
<head>へのメタデータ、Delivery APIからのサイトマップ（noindexや非自己canonicalを除外）、ホスト層のrobots.txt（JS/CSSをブロックしない）、サーバー側リダイレクト、コンテンツ型からのJSON-LD、Contentfulのロケールデータからのhreflangを実装します。Contentful固有の最大のリスクはPreview APIです。下書き・ステージングはホストレベルのX-Robots-Tag: noindexまたは認証で保護し、robots.txtだけに頼らないでください。
すべてを決めるアーキテクチャ上の要点
Contentfulはコンテンツリポジトリであり、Webサーバーではありません。 RESTのContent Delivery APIとGraphQL APIで構造化されたJSONを返しますが、HTMLをレンダリングしたり返したりはしません。検索エンジンはContentfulを直接見るのではなく、データからフロントエンドが生成したものを見ます。したがってSEOの結果は、次の2点で決まります。
Evidence for this claim Contentful exposes published content through its Content Delivery API and GraphQL Content API. Scope: Contentful API delivery; frontend rendering remains separate. Confidence: high · Verified: Contentful: Content Delivery API- フロントエンドフレームワーク（Next.js、Astro、Gatsby、Nuxt、SvelteKit）がContentfulのデータをどう扱うか。
- サイトマップ、robots.txt、リダイレクトなどの補助インフラをホスティング／CDN層に実装したかどうか。
これは私のJavaScript SEOガイド でも述べている点です。WebはプレーンHTMLから移行しましたが、SEO担当者はそれに抗うのではなく、受け入れられます。JavaScriptはSEOに悪いものでも邪悪なものでもありません。ただし、どうレンダリングするかがすべてです。ContentfulはヘッドレスCMS SEOの専門的な応用です。隣接記事を1本だけ読むなら、それを読んでください。
レンダリングがContentful SEOの最重要判断
Contentfulはクローラーから見えないため、フロントエンドのレンダリング方式によって、コンテンツがそもそもインデックスされるかどうかが決まります。推奨順は次のとおりです。
SSG／静的レンダリング。 ビルド時にHTMLを生成し、CDNから静的ファイルとして配信します。初回リクエストから完全なHTMLを返し、TTFBも非常に速い、SEOの最良ケースです。トレードオフは鮮度で、変更には再ビルドが必要です（ISRで緩和できます）。AstroとGatsbyはSSGが中心で、Next.jsは§getStaticProps§または静的ルートをルート単位で使います。
SSR — サーバーサイドレンダリング。 リクエストごとにHTMLを生成します。常に最新で、初回取得時から完全にレンダリングされたHTMLです。インフラコストは高くなります。Contentful自身が述べるように、“server-side rendering is guaranteed to provide results if done right.” (翻訳)「サーバーサイドレンダリングは、正しく行えば結果を保証します。」Next.jsのgetServerSideProps、Nuxt SSR、SvelteKit、Remixが該当します。
ISR — インクリメンタル静的再生成。 静的ページを再検証期間の後にバックグラウンドで再生成します。1時間ごと、1日ごとに変わるコンテンツには有力な中間案です。ただし期間後の最初のリクエストが、まだ古いキャッシュページを受け取る罠に注意してください。そのリクエストがGooglebotになる可能性もあります。
Hybrid。 ルートごとにSSG／SSR／ISRを組み合わせます。大規模なContentfulサイトでは最も実用的で、Contentfulも標準の推奨としています。“Hybrid rendering combines the benefits of SSR and CSR, serving content within initial HTML while still maintaining a more flexible front end. This approach to JavaScript rendering is most ideal for serving content to users and search engines alike.” (翻訳)「ハイブリッドレンダリングはSSRとCSRの利点を組み合わせ、より柔軟なフロントエンドを保ちながら初期HTMLにコンテンツを含めます。この方式はユーザーと検索エンジンの双方にコンテンツを提供するのに最適です。」
CSR — クライアントサイドレンダリング。 最小限のシェルを送り、ブラウザーのJavaScriptがContentfulからコンテンツを取得してDOMを構築します。SEOには最も不利です。Googleは後続のレンダリングウェーブへ回すため、タイミングが予測できません。Bing、Yandex、Baiduはインデックスしないことがあり、AIクローラーのレンダリングもプロバイダーごとに異なります。初期HTMLだけを使う取得者には空のシェルしか見えません。CSRへ移行したサイトでは40〜80%のトラフィック減少が記録されています。サーバーレンダリングのないReact／Vue／AngularのSPAはここをデフォルトにするため、見つけてほしいものにはCSRを避けてください。
Bingの点は強調する価値があります。誰もがGoogleを重視しすぎるからです。CSRだけのContentfulデプロイは、Googleがうまく処理できてもBing SEOの失敗です。 GoogleのJavaScript処理が改善しているとしても、SSR／SSGを選ぶ十分な理由になります。
Dynamic Renderingは非推奨
ユーザーにはSPAを提供し、ボットには事前レンダリング版を提供する方式は、かつては妥当な回避策でした。Googleは方針を変え、現在は*“server-side rendering, static rendering, or hydration”* (翻訳)「サーバーサイドレンダリング、静的レンダリング、またはハイドレーション」を勧めています。Dynamic Renderingは*“creates additional complexities and resource requirements.”* (翻訳)「複雑さとリソース要件を追加する」回避策だと説明しています。自動的にクローキングになるわけではありませんが、新しいContentfulフロントエンドをこれを前提に設計しないでください。
SEOのためのContentfulコンテンツモデルを作る
モデル化するまでContentfulは何も与えてくれません。コンテンツモデル自体がSEOの基盤です。Contentfulの表現では、“A content model comprises the structure and organization of your content, and it serves as the foundation of everything you can accomplish.” (翻訳)「コンテンツモデルはコンテンツの構造と編成を定義し、達成できることすべての基盤になります。」パターンは2つあります。
- 統合型 — SEOフィールドを各ページのコンテンツ型に置きます。単純で、小規模サイトに適しています。
- 専用SEOコンテンツ型 — 各ページ型から再利用可能な
seoMetadata型を参照します。単一の真実のソースになり、サイト全体で更新しやすくなります。複雑なサイトではこちらを標準に勧めます。
各ページ（または専用型）に置く基本的なSEOフィールドは次のとおりです。
| フィールド | 型 | 備考 |
|---|---|---|
seoTitle | Short text | 必須。約60文字のバリデーション |
seoDescription | Short text | 100〜150文字 |
canonicalUrl | Short text | 任意。サイトをまたぐcanonicalの場合だけ |
noindex | Boolean | 編集者の切り替え → meta robots とサイトマップ除外を制御 |
nofollow | Boolean | 任意 |
ogImage | Media（アセットリンク） | Open Graph／ソーシャル用 |
ogTitle／ogDescription | Short text | 任意。SEOフィールドと異なる場合 |
noindexの切り替えには、意味のあるヘルプテキストを付けます。Contentfulが推奨する編集者向け文言は、“Selecting yes will keep the page from showing up in organic search results.” (翻訳)「はいを選ぶと、このページはオーガニック検索結果に表示されません。」です。ただしヘッドレスの落とし穴を忘れないでください。フロントエンドが値を読み取り、サーバー側の<head>にタグとして出力するまで、これらのフィールドは何も起こしません。カスタムcanonicalUrlを設定しないページにも自己参照canonicalが必要です。ページネーション、タグ、フィルターなどの自動生成ページでこれを忘れることが、Contentfulのcanonicalバグで最もよくある原因です。
メタデータ、サイトマップ、robots.txt — プラグインを再構築する
メタデータは、フレームワーク標準のヘッド管理を使ってSEOフィールドから<head>へマッピングします。Next.js App RouterのgenerateMetadata（相対canonicalが壊れないようmetadataBaseを設定）、NuxtのuseSeoMeta、Gatsbyの<Seo>／react-helmet、またはAstroのレイアウト<head>が候補です。信頼性の原則は、HTMLレベルのメタデータはJavaScript注入のメタデータより強いということです。初回取得時にGoogleが見られ、AIクローラーにもその時点で見えるからです。
サイトマップは自分で構築する必要があります。Contentfulにはありません。公開済みエントリをDelivery APIへ問い合わせ、ページネーションします（APIは1回の結果数に上限があるため、skip／limitでループします）。noindex: trueのエントリや自己参照でないcanonicalを除外し、https://domain.com/sitemap.xmlにXMLを出力します。SSGではビルド時に生成し、SSRではContentfulへ問い合わせてXMLを返す専用の/sitemap.xmlルートを用意します。公開量が多いサイトではコンテンツ型ごとに分割・再生成し、古くならないようにします。
robots.txtはホスティング層に置きます。 Vercel、Netlify、Cloudflare Pagesなどで管理し、Contentfulには置きません。サイトマップを指し、ステージング／プレビューのホストを別に扱います。絶対に破ってはいけないルールは、.jsや.cssをDisallowしないことです。レンダリングを完全に妨げます。
ステージングとPreview APIを保護する — Contentfulで最も危険な部分
Contentfulには2つの配信エンドポイントがあります。公開コンテンツを返すContent Delivery APIと、別のキー／エンドポイントで下書きコンテンツを返すContent Preview APIです。Preview APIを使うプレビュー／ステージングフロントエンドは公開到達可能なことが多く、Googleに見つかると別ホスト上にサイト全体の重複がインデックスされます。
多くのガイドが誤る落とし穴は、robots.txtが助言であってアクセス制御ではないことです。GoogleはDisallowを尊重してパスをクロールしませんが、ステージングURLがメール、Slack、別サイトなどのどこかからリンクされていれば、クロールせずに発見・インデックスできます。プレビュー環境は次のように保護してください。
- すべてのプレビュールートにホストレベルの
X-Robots-Tag: noindexHTTPヘッダーを付ける（CDN／エッジで設定し、CSRシェルがレンダリングしないかもしれない遅いJavaScript注入のmetaタグにしない）。 - 認証（署名付きトークンまたはログインゲート）を使う。
- ステージングが本番URLを自己canonicalにしないよう、環境に応じたcanonicalを出力する。
短命のプレビューホストを使い、Search Consoleで予期しないドメインを監視してください。早期警告になります。
ヘッドレスContentfulでのリダイレクト
Contentfulもリダイレクトを処理しません。実用的なパターンは3つあります。
- Contentfulでリダイレクトをモデル化する — source、destination、type（301／302）フィールドを持つ
redirectコンテンツ型を作り、サーバー／エッジ層でエントリを読み取って本物のHTTPリダイレクトを返します。ContentfulのComposable Redirectワークフローは編集者向けに、“open an existing piece of content (or create a new page), indicate that this page will be located at a different URL by updating the URL path, set up a redirect to indicate that the page has moved permanently.” (翻訳)「既存のコンテンツを開く（または新しいページを作る）、URLパスを更新して別のURLに置かれることを示す、ページが恒久的に移動したことを示すリダイレクトを設定する」と説明しています。 - Webhook＋自動化 — Contentfulの公開WebhookをMake／Zapierとリダイレクトマイクロサービス（EasyRedir、redirect.pizza）へ送ります。
- 編集者に違いを教える：301はリンクエクイティを渡しますが、302は渡しません。 JavaScriptリダイレクト（
window.location）は遅く、エクイティを渡さない可能性があり、Google以外のクローラーが追わないこともあるため避けます。
構造化データ、hreflang、パフォーマンス
構造化データは、ヘッドレスの方が簡単になる珍しい領域です。Contentfulの構造化されたコンテンツはJSON-LDに自然に対応します。FAQ型はFAQスキーマ、Article型はArticle／BlogPosting、Product型はProductを出力し、OrganizationスキーマはグローバルなSite Settings型に置きます。フロントエンドがコンテンツフィールドからJSON-LDを生成してサーバー側で注入し、編集者はJSON-LDを書きません。 レンダリングを変えた後はRich Results Testで検証します。
多言語／hreflang。 Contentfulにはフィールドレベルのローカライズ機能があり、APIリクエストのlocaleパラメーターにen-USやde-ATのようなISOコードを使えます。ただしこれはコンテンツの配信であり、SEOシグナルではありません。フロントエンドがContentfulのロケールデータからhreflangタグを生成し、すべてのローカライズページにx-defaultを含める必要があります。hreflangは<head>、HTTPヘッダー、XMLサイトマップのいずれに置いても有効です。Contentfulフロントエンドでは<head>が一般的です。
パフォーマンス。 ContentfulのDelivery APIはグローバルCDNから配信され、高いキャッシュヒット率がビルド時またはサーバーレンダリング時のTTFBを助けます。ただし実ユーザーのTTFBとLCPはContentful APIのレイテンシーより、フロントエンドのホストとレンダリング方式に左右されます。したがってCore Web Vitalsには、Contentfulそのものより静的AstroやNext.jsの静的／ISRなど、フレームワークの選択がはるかに重要です。
トラフィックを落とさずContentfulへ移行する
ヘッドレスSEOが実際に壊れるのは移行時です。典型的な失敗は、301の破損（カテゴリ、タグ、ページネーション付きアーカイブを特に忘れやすい）、移行されなかったメタデータ、CSRへ黙って切り替わったレンダリング方式です。公開前に、投稿だけでなくすべてのURLを棚卸しし、完全な301マップを作り、新フロントエンドのメタデータとcanonicalを検証し、前後でScreaming Frogのクロールを比較し、Google Search ConsoleとBing Webmaster Toolsの両方へサイトマップを再送信し、Googlebotが実際に何をレンダリングしたかの真実のソースとしてURL検査を使ってください。
関連記事：ヘッドレスCMS SEO、JavaScript SEO、より広いレンダリングのトピックです。Contentful SEOは、これら3つを専門化した応用にすぎません。
AI要約
Advanced版の要点をまとめます。
- Contentfulはコンテンツリポジトリであり、Webサーバーではありません。 RESTとGraphQL APIでJSONを返し、HTMLは生成しません。検索エンジンが見るのはフロントエンドの出力だけなので、SEOの結果はすべてフロントエンドの判断です。
- レンダリングが最大のレバーです。 SSGとSSRは完全なHTMLを配信するため安全です。ISR／ハイブリッドは有力な中間案で、CSRはリスクがあります（Googleのインデックスは遅く、Bing／Yandex／Baiduや多くのAIクローラーではインデックスされないことがあります）。Googleが対応できても、CSRだけのContentfulサイトはBing SEOの失敗です。
- Dynamic Renderingは非推奨です。GoogleはSSR、静的レンダリング、ハイドレーションを勧めています。
- Contentfulに組み込みSEOはありません。 タイトルタグ、サイトマップ、robots.txt、スキーマ、canonicalは提供されないため、すべてフロントエンドで構築します。
- SEOフィールドを明示的にモデル化します。
seoTitle、seoDescription、canonicalUrl、noindex（meta robots とサイトマップ除外を制御）、ogImageを使います。型に統合しても、再利用できる専用SEO型にしても構いません。フロントエンドがそれらをサーバーレンダリングされた<head>へ出力するまで、フィールドは何もしません。自己参照canonicalも忘れないでください。 - サイトマップはDelivery APIへ問い合わせ、ページネーションし、noindexまたはcanonical化されたエントリを除外してXMLを出力します。robots.txtはホスティング層に置き、
.js／.cssを決してブロックしません。 - Preview APIのリスク： 下書き／ステージングはホストレベルの
X-Robots-Tag: noindexまたは認証で保護します。robots.txtだけでは不十分です（リンクされたURLはクロールされなくてもインデックスされます）。 - リダイレクトはサーバー側で行います（Contentfulでモデル化するか、Webhook＋リダイレクトサービスを使う）。301はエクイティを渡し、302は渡しません。JSリダイレクトは避けます。
- JSON-LDはコンテンツ型から生成してサーバー側で注入し、編集者は記述しません。hreflangはContentfulのロケールデータからフロントエンドが生成します。組み込みローカライズは配信機能であり、SEOシグナルではありません。
- 移行は壊れた301、失われたメタデータ、意図しないCSRで失敗します。公開前に完全なURL棚卸しとリダイレクトマップを作り、Googlebotが実際に見たものの真実のソースにはURL検査を使います。
公式ドキュメント
検索エンジンとContentfulの一次資料です。
- JavaScript SEOの基本を理解する — クロール→レンダリング→インデックスの流れ、JS canonical、SPAのソフト404s、History APIの指針を説明します。
- Dynamic Rendering（非推奨の回避策） — 非推奨になった理由と、代わりに使うSSR、静的レンダリング、ハイドレーションを説明します。
- 検索関連のJavaScript問題を修正する — レンダリング済みDOMの問題とステートレスレンダリングを診断します。
- コンテンツ主導Webアプリのレンダリング — ヘッドレスChromeによるSSRとコンテンツサイトのトレードオフを説明します。
- robots.txtの概要 — Contentfulでホスト層に構築するrobots.txtの役割と限界を説明します。
Bing／Microsoft
- Bing Webmaster Guidelines — JavaScriptレンダリングとサイトマップ／robotsの扱いに関するBingの厳しい立場です。
- IndexNow ／ indexnow.org — Contentfulの公開Webhookと接続するプッシュプロトコルです。
Contentful
- Contentful SEOガイド — Contentful自身の複数章からなるガイドです。機能一覧ではなく、SEOをContentfulフロントエンドへ組み込むためのガイドとして読みます。
- ヘッドレスSEOの解説 — ハイブリッドレンダリングの推奨を含む、Contentfulのレンダリングの説明です。
- SEO向けコンテンツモデル — コンテンツモデルをSEOの基盤とする章です。
- Content Preview API — インデックスから除外すべき下書きコンテンツのエンドポイントです。
- 環境と環境エイリアスのベストプラクティス — ステージングとプレビュー環境の扱いです。
原文からの引用
Contentful SEOに関係する、記録に残る発言です。各リンクは引用箇所へ直接移動するディープリンクです。
Contentful — SEOのためのレンダリング
- “Serve the elements you deem essential to your page in the initial HTML layer to search engines.” (翻訳)「ページに不可欠だと考える要素を、検索エンジン向けの初期HTML層で提供してください。」 — Contentful『Headless SEO Explained』。 引用へ移動
- “Hybrid rendering combines the benefits of SSR and CSR, serving content within initial HTML while still maintaining a more flexible front end. This approach to JavaScript rendering is most ideal for serving content to users and search engines alike.” (翻訳)「ハイブリッドレンダリングはSSRとCSRの利点を組み合わせ、柔軟なフロントエンドを保ちながら初期HTMLにコンテンツを含めます。この方式はユーザーと検索エンジンの双方への提供に最適です。」 引用へ移動
- “server-side rendering is guaranteed to provide results if done right.” (翻訳)「サーバーサイドレンダリングは、正しく行えば結果を保証します。」 — Contentful『Will search engines index my content? It’s all in the rendering』。 引用へ移動
Contentful — コンテンツモデルとリダイレクト
- “A content model comprises the structure and organization of your content, and it serves as the foundation of everything you can accomplish.” (翻訳)「コンテンツモデルはコンテンツの構造と編成を定義し、達成できることすべての基盤になります。」 — Contentful『SEO向けコンテンツモデル』。 引用へ移動
noindex編集者トグルについて：“Selecting yes will keep the page from showing up in organic search results.” (翻訳)「はいを選ぶと、このページはオーガニック検索結果に表示されません。」 — Contentful『Technical SEO Elements』（推奨される編集者向けヘルプテキスト）。 引用へ移動
Google — Dynamic Renderingは非推奨
- “Instead, we recommend that you use server-side rendering, static rendering, or hydration as a solution.” (翻訳)「代わりに、解決策としてサーバーサイドレンダリング、静的レンダリング、またはハイドレーションを使うことを勧めます。」 — Google Search Centralドキュメント。 引用へ移動
Patrick Stox — JavaScriptとヘッドレスSEO
- “JavaScript is not bad for SEO, and it’s not evil.” (翻訳)「JavaScriptはSEOに悪いものでも邪悪なものでもありません。」 — 私の『JavaScript SEO Issues & Best Practices』（Ahrefs）。 引用へ移動
- “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” (翻訳)「どのようなSSR、静的レンダリング、プリレンダリングの構成でも検索エンジンには問題ありません。」 引用へ移動
2つのチェックリスト：Contentful SEOの健全性と移行
Contentful SEO健全性チェック
- ページはクライアント側JavaScriptが実行された後だけでなく、初回リクエストでHTMLとしてコンテンツをレンダリングする（SSG／SSR／ハイブリッド）。
- 見つけてほしいコンテンツページがCSRに依存していない（Bingと多くのAIクローラーを思い出す）。
- SEOフィールド（
seoTitle、seoDescription、canonicalUrl、noindex、ogImage）がコンテンツモデルにある（統合型または専用SEO型）。 - フロントエンドがフィールドを読み取り、サーバーレンダリングされた
<head>へ出力する（View Source／URL検査で確認）。 - カスタム
canonicalUrlがなくても自己参照canonicalが出力される。 - Delivery APIからサイトマップを生成し、ページネーションし、
noindexとcanonical化されたエントリを除外する。 -
robots.txtはホスティング層で配信し、サイトマップを指し、.jsや.cssをブロックしない。 - プレビュー／ステージングはホストレベルの
X-Robots-Tag: noindexを返すか認証で保護する（robots.txtだけではない）。 - リダイレクトはサーバー側の301（Contentfulでモデル化するかWebhook＋リダイレクトサービス）で、JSリダイレクトではない。
- JSON-LDはコンテンツ型から生成してサーバー側で注入し、Rich Results Testに通る。
- hreflang（
x-defaultを含む）はContentfulのロケールデータからフロントエンドが生成する。
移行チェックリスト（従来型CMS → Contentful）
- 完全なURL棚卸し — 投稿だけでなく、著者、タグ、ページネーション付きアーカイブ、パラメーターURLも含める。
- 変更されるすべてのURLについて、公開前に301リダイレクトマップを作る。
- 新フロントエンドで、URLごとにメタデータ（タイトル、説明）を移行・検証する。
- 新フロントエンドでcanonicalタグを検証する。
- レンダリング方式がSSG／SSR／ハイブリッドであることを確認する（CSRを意図せずデフォルトにしない）。
- 構造化データをコンテンツ型から再構築し、検証する。
- サイトマップをGoogle Search ConsoleとBing Webmaster Toolsへ再送信する。
- クロール比較（Screaming Frog）を公開前後で行う。
- Googlebotが何をレンダリングしたかの真実のソースとしてURL検査を使う。
メンタルモデル
1. Contentfulはクローラーから見えない。 検索エンジンが見るのはContentfulではなく、フロントエンドの出力だけです。Contentful SEOの問題を調べる前に、「このURLでフロントエンドが実際にどんなHTMLを配信しているか」を答えます。ContentfulのエントリではなくView Source／URL検査を見てください。ほぼすべての問題はそこから解けます。
2. レンダリング方式の判断ルール。 コンテンツの更新頻度と、あらゆる場所でインデックスさせる必要性で選びます。
- ほぼ静的（ブログ、ドキュメント、マーケティング）→ SSG（再ビルドまたはタイマー付きISR）。
- 常に最新である必要がある（価格、在庫）→ SSR。
- 1時間／1日単位で変わり、静的配信速度もほしい → ISR（古いページを返す最初のリクエストに注意）。
- 大規模で混在するサイト → ハイブリッド。
- 順位付けやAI引用を望む公開コンテンツ → CSRは決して使わない。
3. 「プラグインがしていたことを再構築する」。
ContentfulはSEOを提供しません。WordPressプラグインの各機能は、意図的な実装工程になります：コンテンツモデルのSEOフィールド → <head>へのマッピング → サイトマップ → robots.txt → canonical → 構造化データ。「何かが足りない」なら、誰もそれを構築していないのです。
4. URLの単一の真実のソース。
canonical、サイトマップのエントリ、hreflang、内部リンクは、単一のSITE_URLとフレームワークのルーティングから導出します。CMS、フレームワーク、コンポーネント層で手作業に組み立てたスラッグを使いません。真実のソースを1つにすればcanonicalの分裂を防げます。
5. robots.txtは助言であり、制御はnoindex。
プレビュー／ステージングをインデックスから除外するには、ホストレベルのnoindexヘッダーまたは認証を使い、robots.txtだけに頼りません。リンクされたURLはクロールされなくてもインデックスされるからです。本物のページを削除する場合はクロールを許可したままnoindexを返します。
Contentful SEO — 早見表
レンダリング方式の比較
| 方式 | HTMLを作る場所 | SEO | 向いている用途 | 注意点 |
|---|---|---|---|---|
| SSG | ビルド時 → 静的ファイル | ✅ 最良 | ほぼ静的なコンテンツ | 再ビルドまで古い。規模が大きいとビルドが遅い |
| SSR | サーバー、リクエストごと | ✅ 最良 | 常に最新のコンテンツ | インフラコストが高い。TTFBがやや高い |
| ISR／ハイブリッド | 静的＋タイマー再生成／混在 | ✅ 良好 | 1時間／1日単位、大規模サイト | 再検証直後の最初のリクエストは古いページを返す |
| CSR | ブラウザー内 | ⚠️ リスクあり | ログイン済みダッシュボードだけ | Bing＋AIクローラーには空のシェル。レンダリング待ちがある |
誰が何を構築するか
| Contentfulが提供するもの | フロントエンド／ホストで構築するもの |
|---|---|
| コンテンツ保存＋コンテンツモデル | タイトルタグ＋メタディスクリプション |
| REST＋GraphQL Delivery API | XMLサイトマップ（Delivery APIから） |
| Content Preview API（下書き） | robots.txt（ホスティング層） |
| フィールドレベルのローカライズ（ロケールデータ） | canonicalタグ＋hreflang |
| APIレスポンス用のグローバルCDN | 構造化データ（JSON-LD） |
| 環境／環境エイリアス | サーバー側301リダイレクト |
推奨するSEOコンテンツフィールド
seoTitle（必須、約60） · seoDescription（100〜150） · canonicalUrl（任意） · noindex（Boolean → meta robots **＋**サイトマップ除外） · nofollow（任意） · ogImage · ogTitle／ogDescription（任意）
早いルール
- ContentfulはHTMLを生成しない — SEOはすべてフロントエンドが決める。
- robots.txtで
.js／.cssを決してDisallowしない。 - canonicalは1つの
SITE_URLから作る絶対URLをサーバー側で出力し、自己参照canonicalを含める。 - プレビュー／ステージングはホストレベルの
X-Robots-Tag: noindex＋認証で保護し、robots.txtだけにしない。 - サイトマップはDelivery APIへ問い合わせ、ページネーションし、noindex／canonical化されたエントリを除外する。
- 301はエクイティを渡し、302は渡さない — JSリダイレクトは使わない。
- CSRだけはBing SEOの失敗であり、多くのAIクローラーから見えない。
- Dynamic Renderingは非推奨 — SSR／静的レンダリング／ハイドレーションを使う。
公開済みルートとライブ出力を比較する
フロントエンドのルート棚卸しから代表的な公開URLを§urls.txt§へ書き出します。これで、クローラーから見えるステータス、タイトル、canonicalを取得できます。
while IFS= read -r url; do
html=$(mktemp)
status=$(curl -sSL -o "$html" -w '%{http_code}' "$url")
title=$(grep -Eio '<title>[^<]*</title>' "$html" | head -1)
canonical=$(grep -Eio '<link[^>]+rel=["'"']canonical["'"'][^>]*>' "$html" | head -1)
printf '%s\t%s\t%s\t%s\n' "$status" "$url" "$title" "$canonical"
rm -f "$html"
done < urls.txtコンテンツモデル、レンダリング、移行を変更した後に同じサンプルを実行し、出力を差分比較します。公開または共有されたスクリプトからPreview APIへ問い合わせないでください。
Contentfulフロントエンド向けのツール
- Render Gap Analyzer — クライアント側実行後にだけ現れるContentfulのフィールドやリンクを見つけます。
- Staging vs. Production SEO Diff — メタデータ、ディレクティブ、canonical、構造化データのリリース差分を比較します。
- Sitemap Validator — 公開状態とルート状態が意図したサイトマップ一覧を作るか確認します。
- Schema Validator — コンテンツモデルのフィールドから組み立てたJSON-LDをテストします。
- Redirect Chain Mapper — 移行とスラッグ変更のリダイレクトマップを検証します。
時間を使う価値のある資料
私の関連記事
- JavaScript SEO Issues & Best Practices — レンダリング方式、Googlebotの挙動、CSRとSSR、JS canonicalに関する主要な参考資料です。Contentfulフロントエンドに直接関係します。
- React SEO — Contentful＋Next.jsスタックでよく使うReact固有のパターンです。
- Canonicalization — Contentfulを含むヘッドレスCMSでcanonical問題が起きやすい理由を扱います。
- Core Web Vitals — CWVを左右するのはContentful APIではなく、フレームワークとホストの選択です。
私の講演
- How Search Works （SlideShare）— クロール、レンダリング、インデックス、ランキングという、Contentfulフロントエンドが満たすべき流れを説明します。（定型の免責：これは私の理解であり、100%完全または正確だと保証するものではありません。）
このサイトの関連記事
- ヘッドレスCMS SEO — 親テーマです。Contentful SEOはその専門的な応用です。
- JavaScript SEO — すべての基礎にあるレンダリングの原則です。
業界の資料
- Contentful SEOガイド （Contentful）— プラットフォームの現行挙動を知る出発点ですが、機能一覧ではなく実装ガイドとして読みます。
- SEO向けコンテンツモデル （Contentful）— 最も強い章で、コンテンツモデルに特化しています。
- 検索エンジンはコンテンツをインデックスするか？レンダリングがすべて （Contentful）— プラットフォーム自身が、レンダリングがインデックスを決めると説明します。
- Composable URLリダイレクト （Contentful）— 編集者向けのリダイレクトモデル化ワークフローです。
- Contentful SEO：4つの主要機能 （WebStacks）— エンタープライズ向けに整理された独立した見解です。
- ヘッドレスCMS SEO：よくある落とし穴を避ける （Successive Digital）— Contentfulにも関係する典型的な失敗を扱います。
- 2026年のSEO向け最良ヘッドレスCMS （FocusReactive）— アーキテクチャの選択がSEOへ波及する過程を詳しく扱います。
Contentful構築で何度も見る間違い
Contentful SEOが失敗する、繰り返し現れる具体的なパターンです。仮説上のリスクではなく、フロントエンドチームが急いで出荷し、レンダリング済み出力を誰も確認しなかったときに実際に起こるものです。
生のCSRシェルを標準フロントエンドとして出荷する
SSRフレームワークのないプレーンなReactまたはVueのSPAを選ぶのは、Contentfulで最も多い間違いです。取得して描画したい開発者にとって最短だからです。なぜ間違いか： GoogleのCSRインデックスは遅く予測できず、Bing、Yandex、Baidu、多くのAIクローラーはJavaScriptをまったくレンダリングしないことがあり、空のシェルを見ます。**代わりに：**初回リクエストで本物のHTMLを送るNext.js、Astro、Nuxt、Gatsby、SvelteKitを選び、CSRではなくSSGまたはSSRを標準にします。
robots.txtでPreview APIを隠せると信じる
§/preview§やステージングのサブドメインを§robots.txt§でブロックし、それで十分だと考えることです。なぜ間違いか： robots.txtは助言でありアクセス制御ではありません。ステージングURLがメール、Slack、別サイトなどでリンクされていれば、Googleはクロールせずにインデックスできます。**代わりに：**すべてのプレビュー／ステージングルートでホストレベルの§X-Robots-Tag: noindex§ヘッダーを返し（CDN／エッジで設定し、遅いJS注入のmetaタグにしない）、認証も使います。
自動生成ページの自己参照canonicalを忘れる
まれなサイト横断canonical用にcanonicalUrlフィールドを追加し、それでcanonicalタグが「処理済み」だと思うことです。**なぜ間違いか：**カスタムcanonicalUrlがなくてもすべてのページに自己参照canonicalを出力する必要があります。ページネーション、タグ、フィルターなどの自動生成URLで最も見落とされ、重複コンテンツ問題の出発点になります。**代わりに：**すべてのテンプレートで、1つのSITE_URLから作った自己参照canonicalをデフォルトにし、本当に別ドメインをcanonicalにする必要がある場合だけ上書きします。
robots.txtで§.js§や§.css§をブロックする
ホスティング層で広い§Disallow§ルールを書き、アセットのパスまで捕まえることです。**なぜ間違いか：**GooglebotがContentfulフロントエンドのレンダリングに必要なJavaScriptとCSSを取得できなければ、完成ページがまったく見えません。部分的な問題ではなく、レンダリング全体が壊れます。**代わりに：**Disallowを実際のステージング／管理者パスへ限定し、robots.txtテスターで§.js§／§.css§を取得できることを確認します。
SEOフィールドをコンテンツモデルへ追加して接続しない
編集者が入力できるようseoTitle、seoDescription、noindexをモデル化し、それで作業完了だと考えることです。**なぜ間違いか：**ヘッドレス構成ではContentfulは値を保存するだけで、フロントエンドがそれを読み取り、サーバーレンダリングされた<head>へ出力する必要があります。レスポンスヘッダーまたはmeta robotsタグに接続されていないnoindexトグルは何も保護しません。**代わりに：**DevToolsではなくView Sourceで、すべてのSEOフィールドがCMSエントリだけでなく初期HTMLレスポンスへ出ていることを確認します。
リダイレクトに§window.location§を使う
フロントエンドコンポーネントからクライアント側JavaScriptリダイレクトを返すことです。**なぜ間違いか：**JSリダイレクトは遅く、301のようにリンクエクイティを渡さない可能性があり、Google以外のクローラーは追わないことがよくあります。**代わりに：**サーバー／エッジ層で本物のHTTP 301を返します。リダイレクトをContentfulエントリとしてモデル化するか、Webhookからリダイレクトサービスへ送っても構いませんが、HTMLを返す前に必ず解決してください。
よくあるContentful SEO問題と修正方法
Contentfulサイトで実際に現れる問題を、症状、考えられる原因、修正が効いたことを確認する方法の順に調べます。
ステージングまたはプレビューがGoogleに表示される
症状： §preview.example.com§のようなサブドメインのプレビュー／ステージングURLがGoogle検索結果またはSearch Consoleのインデックスカバレッジに現れます。
**考えられる原因：**環境が§robots.txt§だけに依存し、URLがクロールせずに発見できる場所からリンクされました。
**修正：**すべてのプレビュールートにホストレベルの§X-Robots-Tag: noindex§ヘッダーを追加するか、認証の背後に環境を置きます。プレビューURLへ§curl -I§を実行してレスポンスにヘッダーがあることを確認し、数日かけてSearch ConsoleからURLが消えるか監視します。
ページは公開できるのに、いつまでもインデックスされない
症状： Contentfulでは公開済みでURLも解決しますが、Search Consoleが長期間「検出 — インデックス未登録」と表示するか、検索に現れません。 **考えられる原因：**フロントエンドがクライアント側（CSR）で、Googlebotが2回目のJavaScript実行クロールを待つことになり、そのキューが遅く保証されません。 **修正：**View Sourceで初回リクエストに何が出るか確認するか、Render Gapで生HTMLとレンダリング済みDOMを比較します。SEOコンテンツが生HTMLにないなら、ルートをSSRまたはSSGに切り替えます。再クロール後、URL検査の「クロール済みページを表示」タブで確認します。
ページネーション、タグ、フィルターで重複コンテンツ警告が出る
**症状：**ページネーション付きアーカイブ、タグページ、絞り込み一覧などの自動生成Contentfulページで、Search Consoleが「重複、Googleがユーザー指定と異なるcanonicalを選択」と報告します。
考えられる原因：canonicalUrlフィールドが空のときのデフォルトがなく、テンプレートに自己参照canonicalが実装されていません。
**修正：**影響を受けたURLのcanonicalをCanonical Checkerで確認し、1つのSITE_URLから作った自己参照canonicalをすべてのテンプレートのデフォルトにします。デプロイ後、同じURLでタグが自分自身を指すことを再確認します。
サイトマップにエントリがない、または入れるべきでないページが含まれる
**症状：**サイトマップのエントリ数がContentfulの公開エントリ数と合わない、またはnoindexページがサイトマップに現れます。
**考えられる原因：**サイトマップを作るDelivery APIクエリがskip／limitのページネーションをループしておらず、静かに切り詰められています。またはnoindex: trueや自己参照でないcanonicalを除外していません。
**修正：**サイトマップ生成スクリプトにページネーションループとnoindex／canonicalフィルターがあるか監査し、サイトマップのエントリ数を公開エントリの新しいDelivery APIクエリと比較します。正しくなったらSearch ConsoleとBing Webmaster Toolsへ再送信します。
構造化データを追加したのにリッチリザルトが現れない
**症状：**FAQ、Article、Productのコンテンツ型にJSON-LDを追加しましたが、Rich Results Testで適格な項目がなく、SERPにもリッチリザルトが出ません。
**考えられる原因：**JSON-LDがハイドレーション後にクライアント側で注入され、Googleが取得する生レスポンスにない、またはコンテンツ型からの必須フィールドマッピングがありません。
**修正：**DevToolsではなくページをView Sourceで見て、初期レスポンスに<script type="application/ld+json">ブロックがあることを確認します。次にSchema ValidatorまたはGoogleのRich Results Testで検証します。修正後に再テストしてください。マークアップが有効になっても、リッチリザルトが現れるまで数日から数週間かかることがあります。
このContentfulルートにはどのレンダリング方式を使うべきか？
レンダリングは、検索エンジンとAIクローラーがコンテンツを見られるかどうかを決める唯一の判断です。ルートまたはテンプレートごとに考えてください。同じContentfulサイトでも、セクションによって答えが異なることがあります。
Which rendering mode should this route use?
Contentfulへ移行してトラフィックが落ちた — 次に行うこと
従来型CMSからの移行後にトラフィックが落ちるという、Contentfulで最も一般的な失敗を調べる手順書です。順番に進めてください。各手順が修正を指すか、次に調べる場所を示します。
-
低下が移行と実際に一致するか確認する。 Search Consoleのパフォーマンスレポートを開き、トラフィックグラフに公開日を重ねます。公開時または直後に低下が始まっていれば手順2へ進みます。一致しなければ移行問題ではなく、アルゴリズム更新など別の原因を調べます。
-
実際にHTMLとして配信されているものを確認する。 View Sourceで（または影響の大きいURLをRender Gapで）最もトラフィックの多いページを調べます。タイトル、本文、リンクなどのSEOコンテンツが生HTMLにないなら、新フロントエンドはCSRをデフォルトにしています。何より先にSSR／SSGへ変更し、この手順を再確認します。
-
リダイレクトマップを監査する。 古いURL一覧を新サイトに対してクロールするか、トラフィックの多い旧URLをRedirect CheckerまたはRedirect Chain Mapperで1つずつ確認します。旧URLが404を返す、または着地までに複数ホップするなら、リダイレクトエントリを直します。カテゴリ、タグ、ページネーション付きアーカイブでURL棚卸しを忘れることが、移行後の低下の最も多い原因です。
-
メタデータとcanonicalが移行されたか確認する。 上位のランディングページでタイトル、説明、canonicalタグを移行前の状態と照合し、canonical部分にはCanonical Checkerを使います。メタデータがない、またはcanonicalが予期しない場所を指すなら、フロントエンドのフィールドマッピングを直します。
-
サイトマップを再送信したか確認する。 新しいサイトマップがGoogle Search ConsoleとBing Webmaster Toolsの両方へ送信され、新しいURL構造を反映していることを確認します。古い、または旧URLを指しているなら再送信します。
-
URL検査を真実のソースとして使う。 手順2〜5が正常なのにインデックス問題が残るURLは、URL検査のライブテストを実行し、「クロール済みページを表示」タブを読みます。これは想像したものではなく、Googlebotが実際に見たものです。
-
すべて確認できたら時間を置く。 正常な移行でも、Googleがサイトを再クロールして再処理する時間が必要です。技術的な問題を直した後、移行後の通常の落ち込みが回復するまで2〜4週間かかることがあります。その期間は追加変更をしないでください。何が効いたか判別できなくなります。
Contentfulフロントエンドを監査するプロンプト
Contentful SEOで繰り返す確認にそのまま使えるプロンプトです。サイトの実際の出力を貼り付けてください。入力した内容の質に応じて結果も変わります。
1. 生HTMLレスポンスに実際に何があるか確認する
ContentfulページのDevToolsでレンダリングされたDOMではなく、View Sourceの出力を貼り付けます。
Here is the raw HTML source (View Source, not the rendered DOM) of a page built on
Contentful:
[paste HTML here]
Check whether the following are present directly in this raw HTML, not injected
later by JavaScript: a <title> tag, a meta description, a self-referencing
canonical tag, and any JSON-LD structured data. List what's present and what's
missing.初回リクエストのHTMLにSEO要素が実際にあるか、ないかをプレーンな一覧で返してもらいます。ここにないものはGoogle、Bing、AIクローラーへ安定して届きません。
2. SEOコンテンツモデルの不足を見つける
Contentfulのコンテンツ型のフィールド一覧を貼り付けます。
Here are the fields on my Contentful content type(s):
[paste field names + types, e.g. "title (Short text), body (Rich text), slug
(Short text)..."]
Compare this against a standard SEO field set: seoTitle, seoDescription,
canonicalUrl, noindex (boolean), nofollow (boolean), ogImage, ogTitle,
ogDescription. Which are missing, and what Contentful field type/validation would
you use for each one?すでにあるフィールドに対応した不足一覧と、推奨するフィールド型を返してもらいます。コンテンツモデルを変更する出発点であり、レビューなしに公開するものではありません。
3. Contentful固有のミスがないかrobots.txtを確認する
Contentfulサイトのホスティング層で配信しているrobots.txtを貼り付けます。
Here is my robots.txt file, served at the hosting layer for a Contentful-powered
site:
[paste robots.txt contents]
Check specifically for two mistakes: (1) does any rule block .js or .css paths
that a rendering framework needs, and (2) does it correctly separate rules for a
preview/staging host from the production host? Flag anything that looks wrong.レンダリングをブロックする可能性のあるDisallowルールと、プレビュー／本番の分離が正しいように見えるかの短い一覧を返してもらいます。これは初回確認として扱い、最後にライブのrobots.txtテスターで確認します。
Contentful SEOを自分でテストする
ContentfulヘッドレスCMSでSEOを行うための短い5問です。各問の答えを選んでから確認してください。
変更履歴
2026年8月22日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。
2026年8月8日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。