# Next.js SEO対策｜実装手順と確認方法

- 公開日: 2026-08-07
- 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星
- URL: https://www.geek-bridge.com/column/nextjs-seo-implementation-guide

Next.jsのSEO対策は、検索対象ページ、URL、初回HTML、メタデータ、クロール制御、表示性能を一つの仕様として設計し、公開前後に検証する取り組みです。外注時はページ種別ごとの要件と受入基準まで見積もりに含めると、実装漏れを防げます。

## Next.jsのSEO対策は要件定義から始める

Next.jsサイトのSEO対策で最初に行うべきことは、実装方法の選定ではなく「どのページを、どのURLで、どのように検索結果へ出すか」を決めることです。

テクニカルSEO（＝検索エンジンがページを取得・解釈しやすくする技術設計）は、公開後にも修正できます。しかし、URLやページ生成の仕組みを後から変更すると、リダイレクト、データ構造、CMS、計測設定まで修正範囲が広がります。新規開発やリニューアルでは、要件定義（＝作るものと条件を決める工程）の段階からSEOを扱う方が合理的です。

### ページ種別ごとに検索公開方針を決める

同じサイト内でも、すべてのページを検索結果へ出す必要はありません。まずはページ一覧を作り、ページ種別ごとに方針を整理します。

|ページ種別|基本的な方針|事前に決めること|
|---|---|---|
|サービス・商品詳細|原則として検索対象|固有のタイトル、本文、正規URL、構造化データ|
|記事・導入事例|原則として検索対象|公開日、更新日、著者、カテゴリ、公開条件|
|カテゴリ・一覧|検索需要と独自性で判断|ページ送り、絞り込み条件、内部リンク|
|サイト内検索結果|通常は検索対象外|noindex、クロール負荷への対応|
|会員・管理画面|検索対象外|認証、アクセス制限、noindex|
|下書き・プレビュー|検索対象外|本番URLとの分離、認証、公開事故の防止|
|広告計測パラメータ付きURL|元ページへ集約|canonical、パラメータの扱い|

インデックスとは、検索エンジンのデータベースへページが登録され、検索結果に表示できる状態になることです。検索対象外のページにはnoindexを設定できますが、機密情報を守る機能ではありません。会員画面や検証環境は、認証やIP制限などでアクセス自体を制御する必要があります。

### SEO要件表に含める項目

発注時は、ページ単位の細かい指示よりも、ページ種別ごとの生成規則を決めると管理しやすくなります。

- 検索流入を獲得したいページ種別
- ページごとの中心テーマと検索意図
- title、description、見出しの生成規則
- URLの命名規則と変更可否
- canonical（＝内容が同じ、または近いページの正規URLを示す設定）
- 公開、非公開、削除時のHTTPステータス
- XMLサイトマップへ掲載する条件
- 構造化データを設定するページと項目
- 多言語サイトの場合は言語・地域別URL
- 自然検索からの問い合わせ、登録、購入などの計測方法
- 公開前テストと受入基準

開発会社へ相談する際は、画面デザインだけでなく、URL一覧やページ種別、CMSから取得するデータ、旧サイトからの移転有無を共有してください。要件を整理して複数社へ依頼する場合は、[RFPの作り方｜システム開発の依頼準備](https://www.geek-bridge.com/column/system-development-rfp-creation-guide)も参考になります。RFPとは、開発会社へ要件や提案条件を伝える提案依頼書です。

## 実装手順：HTML生成からクロール制御まで

Next.jsのSEO実装は、レンダリング、URL、メタデータ、クロール制御、構造化データ、表示性能の順に確認します。個々の設定が正しくても、相互に矛盾すると意図したページが検索対象にならないため、一連の仕様として扱うことが重要です。

### 1. ページに合うレンダリング方式を選ぶ

レンダリングとは、ブラウザへ返すHTMLを生成する方法です。Next.jsを採用しただけで、自動的に検索エンジン向けのHTMLが完成するわけではありません。

|方式|概要|向いているページ|発注時の確認点|
|---|---|---|---|
|静的生成・SSG|ビルド時などにHTMLを生成|会社情報、サービス、更新頻度の低い記事|更新時の再生成方法|
|ISR|一定条件で静的ページを再生成|商品一覧、記事一覧、更新のある詳細ページ|反映まで許容できる時間|
|SSR|アクセスごとにサーバーでHTMLを生成|在庫、料金、検索条件など内容が変わるページ|応答速度、障害時の挙動、キャッシュ|
|CSR|ブラウザ上のJavaScriptで内容を取得・表示|ログイン後の操作画面|SEO対象本文をCSRだけに依存しないこと|

検索流入を狙うページでは、URLへ直接アクセスした時点のHTMLに、固有のタイトル、主要見出し、本文、内部リンクが含まれている状態を基本とします。GoogleはJavaScriptを処理できますが、APIの失敗、処理の遅延、アクセス制限などで内容を取得できない可能性があるためです。

ただし、全ページをSSRにすればよいわけではありません。更新頻度の低いページにアクセスごとの生成処理を使うと、サーバー負荷や応答時間が増える場合があります。反対に、頻繁に変わる情報を静的生成すると、古い内容が表示される可能性があります。

Next.jsにはApp RouterとPages Routerという異なるルーティング構成があり、バージョンやデータ取得方法によって実装が変わります。見積もり時には、利用中または採用予定のNext.jsのバージョン、ルーター、CMS、ホスティング環境を明記してください。

### 2. URLと重複ページを整理する

URLは公開後に変更しなくて済むよう、短く、意味が分かり、継続利用できる形にします。大文字と小文字、末尾スラッシュ、wwwの有無、HTTPとHTTPSなどは、サイト全体で一つに統一します。

同じ内容へ複数のURLからアクセスできる場合は、次の優先順位で整理します。

1. 不要なURLを発生させない
2. 廃止するURLから正規URLへ301または308で転送する
3. 存続が必要な類似ページにはcanonicalを設定する
4. サイト内リンクとXMLサイトマップを正規URLへ統一する

canonicalは重複整理の手掛かりであり、リダイレクトの代わりではありません。また、内容が異なるページを一律に代表ページへ集約すると、本来検索対象にしたいページがインデックスされないことがあります。

広告計測パラメータが付いただけのURLは元ページへ集約できますが、色、地域、カテゴリなどの条件によって本文や検索意図が大きく変わる場合は個別判断が必要です。ページ送りされた一覧も、各ページに異なる掲載内容があるなら、通常はそれぞれ自身を正規URLとして扱います。

サイトリニューアルでは、旧URLと新URLを一対一で対応させたリダイレクト表を作ります。旧ページをすべてトップページへ転送すると、利用者が目的の情報へ到達できず、検索エンジンからも適切な移転として扱われない可能性があります。

### 3. メタデータをページ単位で生成する

メタデータとは、ページのタイトルや説明、正規URLなどを検索エンジンやSNSへ伝える情報です。App RouterではMetadata API、動的ページではgenerateMetadataを利用して生成できます。Pages Routerを利用している場合は、対応する仕組みが異なるため、ルーターに合った実装が必要です。

最低限、次の項目を確認します。

- ページ固有のtitleがある
- descriptionがページ内容と一致している
- canonicalが本番環境の絶対URLになっている
- OGP（＝SNSで共有した際のタイトルや画像）が設定されている
- 非公開ページや存在しないデータへ誤ったメタデータを出さない
- 記事、商品、地域などの動的ページで重複タイトルが量産されない

タイトルは主要テーマを分かりやすい位置に置き、サイト名や定型文を長く付けすぎないようにします。descriptionは検索順位を直接上げるための文ではなく、検索結果でページ内容を判断してもらうための要約として作成します。Googleが検索語に応じて表示文を変更することもあります。

動的生成では、データが空の場合、非公開の場合、削除済みの場合、CMSとの通信に失敗した場合もテストしてください。テンプレートの不備は数百、数千ページへ一度に展開されるため、固定ページ以上に境界条件の確認が重要です。

### 4. クロール制御と構造化データを実装する

クロールとは、検索エンジンがリンクをたどってページを取得することです。robots.txtはクロール可能な範囲を示し、noindexは検索結果へ登録しない意思を示します。robots.txtで取得を禁止すると、検索エンジンがページ内のnoindexを確認できない場合があるため、両者を混同しないようにします。

XMLサイトマップには、次の条件を満たすURLだけを掲載します。

- ステータス200で正常表示される
- 検索結果へ出したい
- canonical先となる正規URLである
- 公開中で、認証を必要としない
- 実際の重要な更新日時を設定できる

リダイレクト、404、noindex、管理画面、パラメータ違いの重複URLは原則として除外します。1ファイル当たり5万URLまたは非圧縮で50MBを超える大規模サイトでは、複数のサイトマップへ分割してインデックスファイルから参照します。

構造化データとは、記事、商品、企業、パンくずリストなどの意味を検索エンジンへ機械的に伝える記述です。画面上で利用者が確認できる情報と一致させ、架空のレビュー、非表示のFAQ、実際と異なる価格や在庫を含めてはいけません。正しく設定しても、リッチリザルトの表示が保証されるものではありません。

### 5. Core Web Vitalsを確認する

Core Web Vitalsとは、実際の利用者が感じる表示速度、操作への反応、レイアウトの安定性を測る指標です。一般的な「良好」の目安は、実ユーザーデータの75パーセンタイルで次のとおりです。

|指標|意味|良好の目安|主な改善対象|
|---|---|---|---|
|LCP|主要な大きい要素が表示される速さ|2.5秒以内|画像、サーバー応答、キャッシュ|
|INP|クリックなどへの反応時間|200ミリ秒以内|JavaScript、重い処理、外部タグ|
|CLS|表示中のレイアウトのずれ|0.1以下|画像サイズ、広告枠、フォント|

Next.jsでは画像最適化やサーバー側のキャッシュを利用できますが、設定するだけで改善するとは限りません。大きなメイン画像、Webフォント、広告・計測タグ、チャットツール、CMS応答時間など、実際の遅延要因を計測して優先順位を付けます。

表示性能はSEOだけでなく、問い合わせや購入のしやすさにも関係します。一方で、数値改善のために必要な機能や計測を無条件に削るべきではありません。事業KPIと技術指標を合わせて判断してください。

## 費用相場・期間と外注先の選び方

Next.jsのSEO対応費用は、ページ数よりもテンプレート数、動的データ、既存実装の状態、URL移転、テスト範囲によって変わります。以下は一般的な目安であり、サイト制作費、記事制作費、SEO戦略全体の費用は含みません。

|依頼範囲|費用の目安|期間の目安|
|---|---:|---:|
|現状調査・SEO要件整理|20万〜80万円|1〜3週間|
|小〜中規模サイトの基本実装|40万〜150万円|2〜6週間|
|CMS連携を含む動的ページ対応|100万〜400万円|1〜3か月|
|大規模メディア・EC・URL移転|300万〜1,000万円以上|2〜6か月以上|
|公開後の監視・改善支援|月額5万〜30万円程度|継続|

基本実装には、メタデータ、canonical、robots.txt、XMLサイトマップ、主要な構造化データ、基本的なエラー処理が含まれる想定です。ただし、既存コードの改修難易度、ページ速度改善、データ移行、多言語対応、分析環境の整備によって金額は増減します。

発注のご相談を受ける開発会社の立場では、「SEO対応一式」という一行だけの見積もりはおすすめできません。発注者と開発会社で完成条件が異なりやすいためです。少なくとも、次の内訳を確認してください。

- 対象となるページ種別とテンプレート数
- 現状調査、要件定義、設計、実装、テストの工数
- titleやdescriptionの原稿を誰が用意するか
- リダイレクト表やURL一覧を誰が作成するか
- 構造化データの対象と種類
- 表示速度改善の対象ページと目標
- Google Search Consoleなどの設定範囲
- 本番公開作業、障害時の切り戻し方法
- 公開後の保証期間と修正条件
- コンテンツ制作や順位改善施策などの対象外項目

相見積もりでは総額だけでなく、前提条件と対象範囲をそろえて比較します。比較方法は[システム開発の相見積もり｜取り方と比較方法](https://www.geek-bridge.com/column/system-development-quote-comparison-guide)もご覧ください。

開発会社を選ぶ際は、次の点を確認すると判断しやすくなります。

- Next.jsのバージョンとルーターに対応できる
- SEO会社の指示を実装するだけでなく、矛盾や実現性を確認できる
- URL、HTTPステータス、レンダリング結果までテストできる
- 動的ページやCMS連携の例外処理を説明できる
- 公開後にSearch Consoleやログを使って原因を調査できる
- SEO担当、デザイナー、開発者の責任分界を明確にできる
- 検索順位を保証するのではなく、実装範囲と検証方法を説明できる

仕様が固まっている部分は請負契約（＝決めた成果物の完成を目的とする契約）、調査しながら改善する部分は準委任契約（＝一定の業務遂行を依頼する契約）が適する場合があります。既存サイトの状態が不明なときは、最初から総額固定にせず、調査・要件整理と実装を分ける方法も有効です。

Next.jsサイトの新規開発やSEO改修について、要件整理から相談したい場合は[開発のご相談はこちら](https://www.geek-bridge.com/#contact)をご利用ください。

## 公開前後の確認方法とよくある失敗

SEO実装は、コードが完成した時点ではなく、本番環境で検索エンジンが正しく取得できる状態まで確認して完了です。受入基準（＝発注者が完成と判断する条件）を事前に定め、検証環境と本番環境の両方で確認します。

### 公開前の受入チェックリスト

|確認領域|確認内容|
|---|---|
|HTML|主要な見出しと本文が初回HTMLに含まれる|
|メタデータ|title、description、canonicalがページごとに正しい|
|URL|大文字・小文字、末尾スラッシュなどの規則が統一されている|
|ステータス|正常ページは200、移転は301・308、削除ページは404・410を返す|
|クロール|robots.txtが公開ページを誤って遮断していない|
|インデックス|検索対象外だけにnoindexが設定されている|
|サイトマップ|公開中の正規URLだけが掲載されている|
|構造化データ|画面上の情報と一致し、検証エラーがない|
|内部リンク|主要ページへ通常のリンクで移動できる|
|モバイル|文字、画像、メニュー、フォームを無理なく操作できる|
|性能|主要テンプレートで表示速度と操作性を計測している|
|計測|自然検索の流入とコンバージョンを確認できる|

とくに注意したいのは、検証環境のnoindexやrobots.txtを本番へ残す事故です。本番用のドメイン、canonical、サイトマップURL、計測IDが環境変数で正しく切り替わることを、公開手順へ含めてください。

### 公開後の検証手順

1. 本番URLへ直接アクセスし、表示、ステータス、HTML、canonicalを確認する
2. Google Search Console（＝Google検索上の登録状況や流入を確認する無料ツール）へサイトマップを送信する
3. URL検査で代表ページのクロール可否とレンダリング結果を確認する
4. リッチリザルトテストで構造化データを確認する
5. 404、リダイレクトループ、サーバーエラーを監視する
6. 主要ページの表示回数、クリック、自然検索経由の成果を継続確認する

大規模サイトでは、全URLを一件ずつ登録リクエストするのではなく、内部リンク、XMLサイトマップ、適切なステータスを整えてクロールを促します。公開直後に検索結果へ反映されるとは限らないため、実装確認と流入評価を分けることも大切です。

### よくある失敗と回避策

|失敗|起こり得る問題|回避策|
|---|---|---|
|SEO対象本文をブラウザ側のAPI取得だけで表示|本文を安定して取得できない|初回HTMLと実際の取得結果を確認する|
|全ページへ同じtitleを設定|ページの違いが伝わりにくい|ページ種別ごとの生成規則を作る|
|canonicalが検証用ドメインを向く|本番URLが正規と認識されない|公開時の自動テストへ含める|
|削除ページが200を返す|ソフト404として扱われる可能性|実態に合う404・410を返す|
|旧URLをすべてトップへ転送|関連性のない移転になる|旧新URLを一対一で対応させる|
|サイトマップへ非公開URLも掲載|クロールと管理が不安定になる|公開中の正規URLだけを抽出する|
|表示速度を検証環境だけで判断|実利用時の問題を見落とす|本番の実ユーザーデータも監視する|
|順位だけを成果指標にする|事業成果との関係が分からない|問い合わせ、登録、売上も確認する|

SEOの成果は、技術要件を満たしただけで保証されるものではありません。検索意図に合うコンテンツ、競合状況、サイトの信頼性、認知度なども影響します。開発会社には検索順位の保証ではなく、技術的な完成条件、検証結果、改善可能な範囲を求める方が適切です。

## まとめ

- Next.jsのSEO対策は、検索対象ページとURLを決める要件定義から始めます
- 検索流入を狙う主要本文は、初回HTMLで安定して取得できる状態にします
- 静的生成、ISR、SSR、CSRは、更新頻度と個別性に応じて使い分けます
- メタデータ、canonical、サイトマップ、構造化データの内容を一致させます
- 見積もりでは「SEO対応一式」ではなく、対象ページ、成果物、テスト範囲を確認します
- 公開前の受入テストに加え、本番公開後もSearch Consoleや実ユーザーデータで検証します
- 技術指標だけでなく、自然検索経由の問い合わせや購入などの事業成果も確認します

## よくある質問

### Next.jsを使えば自動的にSEOに強くなりますか？

いいえ。Next.jsはサーバー側や静的なHTMLを生成しやすいフレームワークですが、コンテンツ品質、URL設計、メタデータ、内部リンク、クロール制御、表示性能を適切に設計する必要があります。

### SSRとSSGはどちらがSEOに有利ですか？

一律の優劣はありません。更新頻度が低いページにはSSG、アクセスごとに内容が変わるページにはSSRが向いています。どちらも主要内容を完全なHTMLとして速く安定して返せることが重要です。

### Next.jsのSEO対応にはいくらかかりますか？

一般的な目安では、現状調査と要件整理が20万〜80万円、基本実装が40万〜150万円程度です。動的ページ、CMS連携、大規模なURL移転を含む場合は100万〜1,000万円以上になることもあります。

### XMLサイトマップには全URLを載せるべきですか？

いいえ。ステータス200で応答し、インデックスさせたい正規URLだけを掲載します。リダイレクト、404、noindex、管理画面、重複URLは原則として除外します。

### SEO施策の効果はいつ判断できますか？

クロールやインデックスへの反映には数日から数週間、流入傾向の評価には数週間から数か月かかる場合があります。Search Consoleの表示回数やクリックだけでなく、自然検索経由の問い合わせ、登録、購入も継続して比較してください。