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

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

• Next.jsのSEO対策は要件定義から始める
  • ページ種別ごとに検索公開方針を決める
  • SEO要件表に含める項目
• 実装手順：HTML生成からクロール制御まで
  • 1. ページに合うレンダリング方式を選ぶ
  • 2. URLと重複ページを整理する
  • 3. メタデータをページ単位で生成する
  • 4. クロール制御と構造化データを実装する
  • 5. Core Web Vitalsを確認する
• 費用相場・期間と外注先の選び方
• 公開前後の確認方法とよくある失敗
  • 公開前の受入チェックリスト
  • 公開後の検証手順
  • よくある失敗と回避策
• まとめ
• よくある質問
  • Next.jsを使えば自動的にSEOに強くなりますか？
  • SSRとSSGはどちらがSEOに有利ですか？
  • Next.jsのSEO対応にはいくらかかりますか？
  • XMLサイトマップには全URLを載せるべきですか？
  • SEO施策の効果はいつ判断できますか？

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

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

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

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

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

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

SEO要件表に含める項目

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

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

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

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

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

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

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

検索流入を狙うページでは、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パーセンタイルで次のとおりです。

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

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

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

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

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

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

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

相見積もりでは総額だけでなく、前提条件と対象範囲をそろえて比較します。比較方法はシステム開発の相見積もり｜取り方と比較方法もご覧ください。

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

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

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

Next.jsサイトの新規開発やSEO改修について、要件整理から相談したい場合は開発のご相談はこちらをご利用ください。

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

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

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

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

公開後の検証手順

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

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

よくある失敗と回避策

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の表示回数やクリックだけでなく、自然検索経由の問い合わせ、登録、購入も継続して比較してください。