JavaScript SEO: リンクがレンダリング後も機能していることを確認する
Googleは最新バージョンのChromiumを使用してJavaScriptをレンダリングします。問題となるのはレンダリング自体よりも、アンカーにならないリンクや、クローラーが保持していない状態に依存するページです。
ArchiLinksリサーチチーム ·
クローラーの視点
Googlebotは2019年5月以来、最新バージョンのChromiumを使用しています。これにより、モダンなJavaScriptを実行できるかどうかという疑問は解決しました。
実務上のリスクは古くからのものです：レンダリングはクロールの後に行われ、遅延する可能性があります。クリックやログインが必要なコンテンツは表示されず、div要素のonclickハンドラーで構築されたリンクはリンクとして機能しません。Reactフロントエンドに移行したウェブサイトのページでバックリンクを確認する前に、それらのページが生のレスポンスまたはレンダリング後のHTMLでコンテンツを表示していることを確認してください。
SSR、SSG、CSR：リンクへの影響
| アプローチ | 最初のレスポンスでのコンテンツ | アンカーとしての内部リンク | 適しているもの |
|---|---|---|---|
| SSR（Next.js、Nuxt） | はい | はい、実際のアンカーを使用する場合 | データが変化する公開ページ |
| SSGまたはプリレンダリング | はい | はい | ドキュメント、ブログ、マーケティングページ |
| CSRシングルページアプリ | いいえ、空のシェル | レンダリング後だけ | ログインが必要なダッシュボード |
| ハイブリッド（SSRホーム、CSRアプリ） | ルートごと | ルートごと | 公開側を持つ製品の大半 |
テスト1：生のHTMLとレンダリング後のHTML
主要なリンクが最初のレスポンスに表示される場合、この問題は解決です。表示されない場合は、ヘッドレスレンダリングと比較してください。
# raw response: are the links there?
curl -s https://new-shop.com/guides/ | grep -o '<a [^>]*href="[^"]*"' | head -20
# rendered DOM with headless Chrome
chrome --headless --dump-dom https://new-shop.com/guides/ | grep -c '<a '
外部リンクの役割
レンダリングのバグはコンテンツを隠しますが、他のサイトがすでに付与したリンクを消去するわけではありません。
Next.js、Vite、またはヘッドレスCMSへの移行後、ホストに対してtoppagesを実行し、最もリンクされている20個のURLのステータス、canonical、表示コンテンツをテストしてください。まずこれを行ってください。40個のドメインからリンクされているページが空のシェルまたはクライアントサイドの404を返す場合、他のことよりも先に修正してください。そこがあなたの権威が到達する場所だからです。内部と外部の格差ページでは、そのリストを内部リンクと比較する方法を示し、移行チェックリストでは、テストをローンチプランに組み込む方法を説明しています。
フレームワークよりも重要なのは規律です。テンプレートエンジン付きのExpress、WordPressテーマ、Next.jsアプリルーターはすべて、クロール可能なリンクを提供できます。クリック後にのみ存在するアンカーをチームが公開した場合、どれでも失敗する可能性があります。
リンクとレンダリングのチェックリスト
- ナビゲーションとページネーションは、他の要素へのクリックハンドラーではなく、
<a href>を使用します。 - すべてのルートは実際のステータスコードを返します。ソフト404画面は404を返す必要があります。
- JavaScriptによって注入される
noindexまたはcanonicalは、サーバーレスポンスのものと一致します。 - 最初のレスポンスでのフォールバックコンテンツは、Googleがインデックス化する可能性のあるスピナーではなく、実際のページです。
- 認証コードは公開ルートのクローラーをリダイレクトしません。
- レンダリングに必要なCSSおよびJSファイルは、robots.txtでブロックされていません。
- 遅延読み込みは、スクロールイベントではなく、IntersectionObserverまたはネイティブの読み込み属性を使用します。
サーチコンソールの証拠を読む
適切なレポートを尋ねれば、Search Consoleはレンダリングに関するほとんどの疑問に答えます。URL検査を使用し、次に「クロールされたページを表示」を選択します。
3つのものを比較してください：GoogleがフェッチしたHTML、スクリーンショット、読み込みに失敗したページリソース。ブラウザでは完全に見えるが、スクリーンショットでは空のページは、通常、スクリプトエラーまたは許可されていないリソースによってブロックされています。修正はコンテンツではなくビルドにあります。
遅延を覚えておいてください。今日公開した変更は、GoogleがURLを再クロールするまで検査ツールに表示されません。それには数日かかることがあります。
SSRが価値があるとき
ランキングする必要がある公開ページ：はい。ダッシュボード：いいえ。
ルートがオーガニックトラフィックを集めるべき場合、最初のレスポンスでコンテンツを提供してください。ログインの背後にある場合は、複雑さを避けてください。プロジェクト全体ではなくルートごとに選択し、次の開発者がその決定を元に戻さないように決定を文書化してください。
- レンダリング後の出力を比較するために、リッチリザルトテストとURL検査を使用します。
- 各フレームワークのアップグレード後にSearch Consoleのライブテストでテストします。
サーバーレンダリングが必要か、それともプリレンダリングで十分か？
サーバーレンダリングはオプションです。それは、最初のレスポンスにクローラーが必要とするものを含める方法です。多くの公開サイトは、プリレンダリング、静的ビルド、または重要なページのサーバーレンダリングでそれを実現し、ログインが必要な部分はそのままにします。
製品ページとドキュメントは公開されているが、ダッシュボードはログインの背後にあると想像してください。最初のグループをプリレンダリングします。ダッシュボードはクライアントサイドのままにします。公開ページは最初のレスポンスにリンクを含め、ダッシュボードは必要に応じて複雑なままにできます。
ホームページのみをプリレンダリングする
ホームページをプリレンダリングすることは最初のクロールを解決しますが、他のすべてのルートをブラウザの待機状態に置きます。ホームページがクライアントレンダリングされたカテゴリページにリンクする場合、それらのページのリンクは依然としてレンダリングに依存します。フロントドアだけでなく、所有するすべてのテンプレートを確認してください。
レンダリング方法付きの公開ルートの短いリストを維持してください。このリストは、クロールレポートよりも早くギャップを示します。
サーバーレンダリングはローカルの可視性を変化させるか
サーバーレンダリングは最初のコンテンツが表示される速度を変化させる可能性があり、読者はそれを感じ取ります。それ自体でページをローカルクエリに関連付けるわけではありません。それらのシグナルはページコンテンツ、ビジネス詳細、およびそれへのリンクから来ます。
レンダリングを、それらのシグナルがクローラーに読み取られる方法として扱い、リンクはAPIで個別に測定します。
1つのシェルを提供するViteおよびReactアプリ
すべてのパスに1つのHTMLシェルを提供するViteビルドは、すべての作業をクライアントに任せます。そのようなアプリは一部のクエリでランキングできるかもしれませんが、各公開ルートには計画が必要です：プリレンダリングするか、サーバーでレンダリングするか、損失を受け入れ、それを文書化します。
再ビルド後にウェブサイトのルートでバックリンクを確認する前に、各公開ルートがどのようにコンテンツを取得するかを決定してください。そうしないと、リンクデータは、中身のないページに外部リンクが到達していることを示します。
ルートがリンクを表示しているかどうかのテスト
2つのテストがほとんどの疑問に答えます。生のレスポンスは、スクリプトが実行される前にクローラーが取得するものを示します。レンダリング後のDOMは、ブラウザがその後構築するものを示します。2番目のものでのみ表示されるリンクは依然としてリンクですが、レンダリングが正常に行われることに依存しています。
Search Consoleのライブテストを読む
URL検査からライブテストを1つのルートずつ実行します。レンダリング後のHTMLを確認し、次に読み込みに失敗したリソースのリストを確認します。ブロックされたスクリプトはナビゲーションブロック全体を削除でき、ページは目に見えるエラーを表示せずに薄っぺらく見えます。
フレームワークのアップグレード後にテストを繰り返してください。新しいデフォルトにより、スクリプトの実行前後にリンクがレンダリングされるかどうかが変わる可能性があるためです。インデックス化されていないページガイドでは、レンダリング後のページが依然としてインデックス化されない場合の対処法をカバーしています。
ルートはレンダリングされるがコンテンツがスピナーの場合
最初のレスポンスでのフォールバックは、多くのチームが期待するよりも重要です。スピナーまたは空のコンテナは、その瞬間にページがクローラーにテキストを保持していないことを意味します。詳細なリストが後で読み込まれる場合でも、タイトル、イントロ、主要なリンクを最初のレスポンスに含めてください。
実際のページであるフォールバックはシンプルに保つことができます。その唯一の役割は、他のコンテンツが到着するまでコンテンツを保持することです。
リンクを失うことなくクライアントサイドサイトを移動する
外部リンクを持つルートをリスト化する
ホストに対してtoppagesを実行し、上位50個のURLをメモします。コードの変更前にこれらのルートを最初にテストし、再ビルドが保持すべきものを把握してください。
生の出力とレンダリング後の出力を比較する
各ルートについて、古いビルドと新しいビルドの生のHTMLとレンダリング後のDOMを確認します。片方に存在し、もう片方に存在しないリンクをメモします。
クリックハンドラーをアンカーに置き換える
ナビゲーションを適切なアドレスを持つ実際のアンカーに変えます。速度の作業はスプリントに待たせることができますが、欠落したアンカーはルートがサイトへの経路を失う原因になります。
リリース後にテストを繰り返す
リリースの1週間後、同じルートでライブテストを実行し、結果を以前の結果と比較します。差異は、再ビルドが出力を変えた場所を示します。
クライアントサイドアプリのステータスコードとリダイレクト
シングルページアプリは、サーバーがステータス200を返す間、よく見つからない画面を表示します。Googleはこのようなページをソフト404として扱う可能性があり、欠落したURLへの外部リンクはほとんど機能しません。修正はサーバー側に行う必要があります。
200を返す未知のルート
存在しないルートにはサーバーから実際の404を返し、クライアントサイドのルートで到着した訪問者のためにアプリ内見つからない画面を維持します。置換が存在する場合は、代わりに301を送信します。
各リリース後にライブホストでいくつかの架空のアドレスを確認します。読むべきものはページブラウザで見るものではなく、レスポンスコードです。
ブラウザで実行されるリダイレクト
ページロード後に発火するリダイレクト（例：コンポーネント内でURLパラメータを読み取る）は、サーバーリダイレクトとは異なります。クローラーは、リダイレクトが実行される前に最初のレスポンスをインデックス化する可能性があります。ルートが恒久的に移動した場合は、サーバーから301を返し、コンテンツを変更するパラメータを維持します。リダイレクトマップレシピは、それらのルールをテストする方法を示しています。
