公開ページから読み取るレンダリング、メタデータ、Web Vitals
Next.jsサイトが検索エンジンに配信する内容を監査する.
Next.jsのサイトを運営している方、あるいは引き継いだ方に向けた診断です。検索エンジンが実際にどんな情報を取得しているのかを確認できます。この無料診断では、トップページと最大8つのサンプルページを分析し、根拠を添えて100点満点のスコアを出します。ソースコードは読み取りません。ログインもしません。アナリティクスデータも確認しません。そのため、お渡しいただく情報もありません。
このページの内容 8つのセクション
Next.jsのSEO監査では、どのような点がチェックされるのでしょうか?
この診断では、サイトから抽出した各ルートがクローラーに返す内容を検証します。見るのは、レスポンスHTMLとheadタグ内の要素です。さらに、インデックス制御シグナルとスクリプトの容量も確認します。トップページで「ソースを表示」を開き、メインの見出しを検索してみてください。すぐ見つかるなら、サーバーからHTMLが出力されています。空のdiv要素とスクリプトのバンドルしか見当たらない場合（よくあることです）、そのページはJavaScriptが動くまで中身が表示されません。
この診断は、トップページと最大8つのサンプリングページから、レスポンスヘッダー、マークアップ、構造化データ、見出しを読み取ります。加えて、スクリプトと画像の転送量、robotsとcanonicalのシグナルも確認します。結果は8つの加重配分スコアに反映されます。内訳は、アーキテクチャ（15％）、パフォーマンス（15％）、検索（12％）、スキーマ（10％）などです。リポジトリにはアクセスしません。そのため各指標が示すのは、ソースコードのファイル構成ではなく、クローラーがサイトから実際に受け取ったデータです。検索エンジンもコードベースを直接読むわけではありません。だから、ここで出る数字はサイト管理者にとって実態に即しています。
レンダリングモードによって、Googleが受信する内容に変化はありますか?
はい。レンダリング方式によって、最初のレスポンスに本文が含まれるか、それともGoogleがあとからレンダリングしなければならない「シェル」しか返らないかが決まります。まず、記事のURLを1つ選び、HTMLに本文が含まれているか確認してください。「静的レンダリング」ではHTMLを事前生成してキャッシュし、「動的レンダリング」ではリクエストごとにサーバーで生成します。どちらでも構いません。いずれの方式でもマークアップをブラウザに返送できます（重要なのはこの点です）。
クライアントサイドのデータフェッチに過度に依存すると、問題が生じます。ページ全体を「use client」モードに強制したり、useEffect 内でコンテンツを読み込んだりすると、Googlebot には本文ではなく「読み込み中…」しか届きません。しかも Next.js は、ルート単位でレンダリング方式を決定します。見落としやすいのはここです。クッキーやヘッダーなどの動的APIを1回呼び出すだけで、そのルート全体の挙動が変わります。だから、意図せず混在した構成になることがあります。
GoogleはJavaScriptをレンダリングします。ただし、初回の200レスポンスを受け取った後に処理をキューへ回すため、待ち時間が数秒を超えることがあります。Googleのドキュメントでも、サーバーサイドレンダリングやプリレンダリングが今なお推奨されています。別の問題もあります。JavaScriptを実行しないボットも存在し、スクリプトの確実な動作は前提にできません。だから、ルートごとにレスポンス内容を精査するこの診断で、配信している各ルートの実態を確認できます。
メタデータAPIは、タイトル、カノニカルURL、およびOpen Graphタグをどのように決定するのでしょうか?
head タグの中身は、layout.js または page.js でエクスポートしたメタデータオブジェクト、もしくは generateMetadata 関数から生成されます。下層ページのソースを開き、head 内を確認してください。見るのは3つだけです。タイトルとカノニカルリンク、そして og:image です。そこに出力されている内容が、エクスポートした設定そのものです。そして、評価ツールがページ上で認識する内容とも、完全に一致します。
`generateMetadata` 関数ではデータを取得し、親セグメントのメタデータを読み取ることができるため、共有されている Open Graph 画像を上書きするのではなく、それを拡張することができます。`alternates.canonical` を設定すると、Next.js が正規リンクを記述します。また、`openGraph.images` を設定すると、og:image が記述されます。 画像のURLは絶対パスである必要がありますので、`metadataBase` に `new URL(...)` を設定してください。`title.template` は子セグメントにのみ適用されます。これを定義したセグメント内のページはスキップされるため、予想外の結果となることがあります。したがって、タイトルが正しく表示されない場合は、設定場所を確認してください。
静的メタデータでよく見られる問題は、複数ルートでのタイトルの重複です。そして、正規URLの欠落や、og:image の相対パス指定もよく見られます。診断レポートには、サンプリングしたページごとの問題点が挙がります。そのため、各不備をコード側のエクスポート定義と照合できます。あとは該当ルートのファイルを開き、エクスポート内容を確認してください。検出された不備はどれも、ご自身が書いた（あるいは書き忘れた）メタデータ定義に直接起因しています。
なぜNext.jsのサイトはCore Web Vitalsの基準を満たせないのでしょうか?
Next.js サイトでは、フィールドデータで LCP が 2.5 秒、INP が 200 ミリ秒、CLS が 0.1 のいずれかを超えると、Core Web Vitals の基準を満たせなくなります。Vercelによると、LCP要素が画像だったページのうち、35％で初回のHTMLからソースURLを特定できなかったそうです。自分のサイトではどうか、確かめてみてください。手順は簡単です。初回のHTMLソースを開き、画面上部（above-the-fold）で最も大きい画像のURLを探してみてください。
スクリプトのサイズとハイドレーションの処理負荷は、INPに影響します。INPは2024年3月にFIDに代わって導入された指標です。Vercelによると、主要なページブロックをSuspenseでラップすると、それぞれが個別にハイドレーションされ、INPが改善するそうです。CLSの原因は、もっと単純です。寸法を指定していない画像があります。後から挿入されるコンテンツもあります。そして、読み込み中のWebフォントも原因になります。テンプレート内で、この3点をすべて確認してください。
この評価が測定するのは、ページ上のスクリプトと画像の転送量です。実環境データを提供するものではありません。Googleが検索順位の判定に利用するのは、直近28日間の実環境データです。だから、Lighthouseの結果が良くても、それで安心はできません。ラボテストのスコアが高くても、その月の実環境データが悪ければ、問題が見落とされてしまうことがあります。そこで Core Web Vitals のテストを実行し、ご自身の実環境データを確認してください。
どのApp Routerの設定ミスが、ページを検索結果から非表示にしてしまうのでしょうか?
クライアント側だけでコンテンツをレンダリングしている。noindexを誤って設定している。noindexを付けたかった箇所でクロールをブロックしている。canonicalタグがなく、重複URLが残っている。どれか1つでもあると、ページは検索から外れてしまいます。まずrobots.txtを開いてください。JavaScriptやCSSのパスをブロックしていないか確認します。主要なページでは、head部分にrobotsメタタグが入っていないか見てください。余計な記述が1行あるだけで、これまでの努力が無駄になることがあります。しかも、気づく機会はほとんどありません。
App Router では、ページ単位の noindex をメタデータのエクスポート（robots: { index: false, follow: false }）で設定します。その URL をサイトマップに残すと、それは矛盾したシグナルになります。さらに robots.txt でも同じ URL をブロックすると、Google がそのページをクロールしなくなり、noindex が認識されないおそれがあります。この2つの設定は、互いに打ち消します。
ステージング環境がインデックス登録されていないか、先に確認してください。この評価では、ホームページとサンプリングしたページから、robotsファイルとカノニカルタグを読み取ります。レポートに出るのは、誤設定の「noindex」、カノニカルタグの欠落、クライアント専用シェルなどです。見られる範囲は限られます。サンプリング対象外のルートは確認できません。そちらはご自身でご確認ください。
Next.jsのサイトを外部から2分で確認するにはどうすればよいでしょうか?
ご自身のURLで無料診断を実行し、職場のメールアドレスを入力してください。約2分後に、100点満点のスコアと、各評価項目の根拠となるデータが表示されます。まずはホームページのURLを貼り付けます。そのうえで、レポートに書かれたレンダリングやヘッドタグの内容を、サイト内の深い階層にあるページの一つで「ソースを表示」した内容と見比べてください。ご登録のメールアドレス宛に、レポートへのリンクが1回だけ送られます。実行できるのは、1つの接続につき1時間に3回までです。
数字を見る前に、まずバンド値を確認してください。80～100は良好です。60～79は制限ありです。40～59はリスクありです。0～39は既存の課題とみなされます。次に、ピラーごとの分析結果を見てください。レンダリング、正規化、スクリプトの重み付けに関する指摘が、どの項目に出ているかを確認します。そこが、サイト全体に最も広く影響する改善点です。
次の項目は、この分析の範囲外です。この評価が対象にするのは公開ページだけなので、実際のパフォーマンスデータや情報源は確認できません。パフォーマンスの測定結果を知りたい場合は、「Core Web Vitals」テストを実行してください。AIシステムがページをどう認識しているかを知りたい場合は、「AI SEO監査」を実行してください。
よくある質問.
01Next.jsはSEOに悪影響を及ぼしますか？
いいえ。Next.js は完全にレンダリングした HTML を送信できますし、Google も JavaScript をキュー経由でレンダリングします。ただし、その処理に数秒以上かかることがあります。リスクがあるのは、クライアント側でコンテンツを取得し、シェルだけを送信するルートです。この評価では、サンプルとして抽出したページのレスポンスにコンテンツが含まれているかどうかを、ルートごとに確認します。
02この診断は、Next.jsのソースコードを読み取りますか？
いいえ。このツールが読むのは、公開ページに含まれる情報だけです。対象になるのは、レスポンスヘッダー、マークアップ、構造化データ、見出し、スクリプトや画像の容量、robotsやcanonicalのシグナルなどです。ログインはしません。分析データは読み取りません。フィールドのパフォーマンスデータも取得しません。誰かにインタビューすることもありません。「調査結果」は、クローラーが受け取った出力を記述したものにすぎず、それ以上のことは主張しません。
03SEOの観点から、静的エクスポートとサーバーサイドレンダリングのどちらを採用すべきでしょうか？
どちらの方法でも、検索には対応できます。Next.js 13.3以降で`output: 'export'`と設定する静的エクスポートは、ルートごとに1つのHTMLファイルを生成します。一方、サーバーサイドレンダリングでは、リクエストのたびにHTMLを生成します。大事なのは、レスポンスにコンテンツ、タイトル、カノニカルタグが含まれていることです。確認は簡単です。各ルートのページソースを見てください。
04このチェックは何度まで実行できますか？
1つの接続につき、1時間に3回までチェックを実行できます。1回のチェックは約2分で、無料です。職場のメールアドレスの入力が必要で、レポートへのリンクがそのアドレスに一度だけ送られます。読み込むのは、ホームページと最大8つのサンプルページです。修正をリリースしたら、もう一度チェックして比較してください。変更が反映されたかどうかを確かめるには、それがいちばん手っ取り早い方法です。
出典
このページの事実は以下の資料に基づいています。確認日： 2026-10-25。診断そのものに関する数値は、その仕組みを説明するものです。
無料の自動診断