React SEO： SEOフレンドリーにするためのベストプラクティス

この記事はAhrefs公式ブログの日本語訳です。
原文：＜React SEO: Best Practices to Make It SEO-Friendly＞
（著者：＜Sam Underwood＞/ 原文の最終更新日：＜March 1, 2022＞）
※フルスピード註：この記事は2022年3月1日時点の記載をもとに翻訳しています。Ahrefs公式ブログの記事は今後追記・再公開されることがありますことをご了承ください。

現代の Web 開発におけるReactの普及は無視できません。

React および他の同様のライブラリ ( Vue.jsなど) は、より単純なアプローチ (WordPress テーマの使用など) では要件を満たせない複雑な開発を必要とする大企業にとって、事実上の選択肢になりつつあります。

それにもかかわらず、SEO は当初、 HTML ソース内で利用可能なコンテンツを優先し、検索エンジンが JavaScript を効果的にレンダリングするのに苦労していたため、React のようなライブラリを採用しませんでした。

ただし、Google と React が JavaScript をレンダリングする方法の開発により、これらの複雑さが簡素化され、その結果、SEO が React の使用を妨げるものではなくなりました。

それでも、いくつかの複雑な点が残っていますが、それについてはこのガイドで説明します。

これに関連して、以下の内容について説明します。

まず最初に、React とは何でしょうか?
React によるレンダリング、短い歴史
Google によるページの処理方法
React に関する一般的な SEO の問題
まとめ

まず最初に、React とは何でしょうか?

React は、Web およびモバイルアプリケーションを構築するために Meta (旧 Facebook) によって開発されたオープンソース JavaScript ライブラリです。React の主な特徴は、宣言型であること、コンポーネントベースであること、そしてDOM の操作が容易であることです。

コンポーネントを理解する最も簡単な方法は、WordPress の場合のようにコンポーネントをプラグインとして考えることです。これらにより、開発者は MUIやTailwind UIなどのコンポーネントライブラリを使用して、デザインを迅速に構築し、ページに機能を追加できます。

開発者が React を愛する理由を詳しく知りたい場合は、ここから始めてください。

React によるレンダリング、短い歴史

React はApp Shell モデルを実装しています。つまり、すべてではないにしても、コンテンツの大部分がデフォルトでクライアント側レンダリング (CSR) になります。

CSR とは、サーバーがサーバーからの最初の HTTP 応答 (HTML ソース) 内でページ全体のコンテンツを送信するのではなく、HTML に主に React JS ライブラリが含まれていることを意味します。

また、 JSON データを含むさまざまな JavaScript や、React コンポーネントを含む JS ファイルへのリンクも含まれます。HTML ソースをチェックすると、サイトがクライアント側でレンダリングされていることをすぐに知ることができます。これを行うには、右クリックして「ページソースの表示」(または CTRL + U/CMD + U) を選択します。

netlfix.com ホームページのソース HTML のスクリーンショット。

そこに HTML 行があまり表示されない場合、アプリケーションはクライアント側でレンダリングされている可能性があります。

ただし、右クリックして「要素の検査」(または F12/CMD + ⌥ + I) を選択して要素を検査すると、ブラウザーによって生成された DOM (ブラウザーが JavaScript をレンダリングした場所) が表示されます。

その結果、サイトには大量の HTML が含まれていることがわかります。

最初の <div> の appMountPoint ID に注目してください。このような要素はシングルページアプリケーション (SPA)でよく見られるため、React のようなライブラリは HTML を挿入する場所を認識しています。Wappalyzer などのテクノロジー検出ツールもライブラリの検出に優れています。

編集者注記
Ahrefs のSite Audit は、サーバーから送信された生の HTML とブラウザーにレンダリングされた HTML の両方を保存するため、サイトにクライアント側でレンダリングされたコンテンツがあるかどうかを簡単に特定できます。

さらに良いことに、Raw HTML とレンダリングされた HTML の両方を検索して、具体的にどのコンテンツがクライアント側でレンダリングされているかを知ることができます。以下の例では、このサイトがクライアント側で <h1> タグなどの主要なページコンテンツをレンダリングしていることがわかります。

Joshua Hardwick
コンテンツ責任者

React を使用して作成された Web サイトは、サーバーサイドレンダリング (SSR) と呼ばれる、PHP などの言語を使用してサーバー上でコンテンツをレンダリングするという重労働を残す従来のアプローチとは異なります。

上は、サーバーが React を使用して JavaScript を HTML にレンダリングする様子を示しています (これについては後ほど詳しく説明します)。この概念は、PHP で構築されたサイト (WordPress など) でも同じです。PHP が JavaScript ではなく HTML に変換されているだけです。

SSR が登場する前、開発者はそれをさらにシンプルにしていました。

彼らは、変更のない静的な HTML ドキュメントを作成し、サーバー上でホストして、すぐに送信していました。サーバーは何もレンダリングする必要がなく、ブラウザーがレンダリングするものはほとんどありませんでした。

SPA (React を使用している SPA を含む) は現在、この静的アプローチに一周回帰しつつあります。ブラウザが URL をリクエストする前に、JavaScript を HTML に事前レンダリングするようになりました。このアプローチは静的サイト生成 (SSG) と呼ばれ、静的レンダリングとも呼ばれます。

実際には、SSR と SSG は似ています。

主な違いは、ブラウザーが URL をリクエストしたときに SSR でレンダリングが行われるのに対し、フレームワークでは SSG によるビルド時 (開発者が新しいコードをデプロイするとき、または Web 管理者がサイトのコンテンツを変更するとき) にコンテンツを事前レンダリングすることです。

SSR はより動的になりますが、ユーザーのブラウザに送信する前にサーバーがコンテンツをレンダリングする間に追加の遅延が発生するため、速度が遅くなります。

SSG は、コンテンツがすでにレンダリングされているため高速です。つまり、コンテンツをユーザーにすぐに提供できます (つまり、TTFB が高速になります)。

Google によるページの処理方法

React のデフォルトのクライアント側レンダリングアプローチが SEO の問題を引き起こす理由を理解するには、まず Google がどのようにページをクロール、処理、インデックス付けするかを知る必要があります。

これがどのように機能するかの基本を以下の手順にまとめることができます。

クロール – Googlebot は、クロールキュー内の URL の GET リクエストをサーバーに送信し、応答の内容を保存します。Googlebot は、HTML、JS、CSS、画像ファイルなどに対してこれを行います。
処理 – これには、HTML 内の <a href> リンク内にあるクロールキューに URL を追加することが含まれます。これには、 <link>タグ内にあるキューイングリソース URL (CSS/JS) や<img src>タグ内の画像も含まれます。この段階で Googlebot が noindex タグを見つけた場合、プロセスは停止し、Googlebot はコンテンツをレンダリングせず、Caffeine (Google のインデクサー) はコンテンツのインデックスを作成しません。
レンダリング – Googlebot は、ヘッドレス Chromium ブラウザで JavaScript コードを実行し、DOM 内の追加コンテンツを検索しますが、HTML ソースは検索しません。これはすべての HTML URL に対して行われます。
インデックス作成 – Caffeine は Googlebot から情報を取得し、それを正規化し (壊れた HTML を修正)、すべてを理解しようとして、検索結果内で提供できるようにいくつかのランキングシグナルを事前計算します。

サイドノート。このプロセスについて詳しく知りたい場合は、Google に詳しい説明があります。Patrick Stox は、知っておくべき重要なJavaScript SEO の事実を説明した記事もあります。

これまで、React やその他の JS ライブラリの問題は、Google がレンダリングステップを適切に処理できなかったことが原因でした。

例としては次のようなものがあります。

JavaScript がレンダリングされない – これは古い問題ですが、Google が限定的な方法で JavaScript のレンダリングを開始したのは 2008 年になってからです。ただし、2009 年に作成された JavaScript サイトのクロールスキームに依然依存していました ( その後、Google はこのスキームを廃止しました )。
レンダリングエンジン (Chromium) が古いため、最新のブラウザーと JavaScript 機能がサポートされなくなりました。Googlebot がサポートしていない JavaScript 機能を使用した場合、ページが正しく表示されず、コンテンツのインデックス登録に悪影響を及ぼす可能性があります。
Google には非常に長い遅延が発生しました。場合によっては、最大数週間の遅延が発生し、コンテンツの変更がインデックス作成段階に達するまでの時間が遅くなる可能性があります。これにより、ほとんどのサイトのコンテンツのレンダリングを Google に依存することができなくなります。

ありがたいことに、Google はこれらの問題のほとんどを解決しました。Googlebot は現在エバーグリーンです。つまり、Chromium の最新機能を常にサポートしています。

さらに、2019 年 11 月の Chrome Developer Summit で Martin Splitt 氏が発表したように、レンダリング遅延は 5 秒になりました。

去年、トム・グリーナウェイと私はこのステージに立って、「そうですね、最長一週間かかることもあります。このようなことになって大変申し訳ありません」と言いました。これは忘れてください、いいですか？新しい数字のほうがずっと良く見えるからです。そこで実際に数値を調べてみたところ、クロールしてから実際にこれらの結果が表示されるまでに費やした時間は、中央値で 5 秒であることがわかりました。」

これはすべてポジティブに聞こえます。しかし、クライアント側でレンダリングを行い、Googlebot にコンテンツのレンダリングを任せることは正しい戦略なのでしょうか?

答えはおそらくまだ「ノー」です。

React に関する一般的な SEO の問題

過去 5 年間、Google は JavaScript コンテンツの処理を革新してきましたが、完全にクライアント側でレンダリングされたサイトでは、考慮する必要がある別の問題が生じます。

React と SEO を使用すればすべての問題を克服できることに注意することが重要です。

React JS は開発ツールです。React は、WordPress プラグインであろうと、選択した CDN であろうと、開発スタック内の他のツールと何ら変わりません。SEO をどのように設定するかによって、SEO が損なわれるか強化されるかが決まります。

結局のところ、React はユーザーエクスペリエンスを向上させるため、SEO に適しています。次の一般的な問題を必ず考慮する必要があります。

1. 適切なレンダリング戦略を選択する

React で取り組む必要がある最も重要な問題は、コンテンツをどのようにレンダリングするかです。

前述したように、現在、Google は JavaScript のレンダリングに優れています。しかし、残念ながら、他の検索エンジンではそうではありません。Bing は JavaScript レンダリングをある程度サポートしていますが、その効率は不明です。Baidu、Yandex などの他の検索エンジンは限定的なサポートを提供します。

サイドノート。この制限は検索エンジンにだけ影響するわけではありません。サイト監査者は別として、Web をクロールしてサイトのバックリンクなどの要素に関する重要なデータを提供する SEO ツールはJavaScript をレンダリングしません。これは、提供されるデータの品質に重大な影響を与える可能性があります。唯一の例外は Ahrefs です。Ahrefs は2017 年から Web 全体で JavaScript をレンダリングしており、現在1 日あたり 2 億ページ以上をレンダリングしています。

この未知の導入により、すべてのクローラーがサイトのコンテンツを確実に参照できるように、サーバー側でレンダリングされるソリューションを選択する良いケースが構築されます。

さらに、サーバー上でコンテンツをレンダリングすることには、 読み込み時間という別の重要な利点があります。

ロード時間

JavaScript のレンダリングは CPU に負荷をかけます。これにより、React のような大きなライブラリの読み込みが遅くなり、ユーザーにとってインタラクティブになります。一般に、インタラクティブ時間 (TTI) などの Core Web Vitals は、特にユーザーが Web コンテンツを消費する主な方法であるモバイルにおいて、SPA の方がはるかに高いことがわかります。

クライアント側レンダリングを利用する React アプリケーションの例。

ただし、ブラウザによる最初のレンダリングの後は、次の理由により、その後の読み込み時間が速くなる傾向があります。

クライアント側のレンダリングではページ全体が更新されません。つまり、ライブラリは 1 回読み込むだけで済みます。
React の「diffing 」アルゴリズムは、状態が変更された DOM 内の HTML のみを変更します。その結果、ブラウザーは変更されたコンテンツのみを再レンダリングします。

訪問ごとに表示されるページ数に応じて、フィールドデータが全体的にプラスになる可能性があります。

ただし、サイトの訪問ごとに表示されるページ数が少ない場合、すべての Core Web Vitals について肯定的なフィールドデータを取得するのは困難になります。

解決

最善の選択肢は、主に次の理由から SSR または SSG を選択することです。

初期レンダリングの高速化。
コンテンツをレンダリングするために検索エンジンクローラーに依存する必要がありません。
インタラクティブになる前にブラウザーが解析およびレンダリングする JavaScript コードが減少したことによる TTI の改善。

React 内での SSR の実装は、ReactDOMServerを介して可能です。ただし、 Next.jsという React フレームワークを使用し、その SSG およびSSR オプションを使用することをお勧めします。Next.js を使用して CSR を実装することもできますが、このフレームワークは速度の点でユーザーを SSR/SSG に誘導します。

Next.js は、「自動静的最適化」と呼ばれるものをサポートしています。実際には、これは、サイト上に SSR を使用するいくつかのページ (アカウントページなど) と、SSG を使用する他のページ (ブログなど) を配置できることを意味します。

結果: 非動的ページには SSG と高速 TTFB、動的コンテンツにはバックアップレンダリング戦略として SSR が使用されます。

サイドノート。ReactDOM.quantity()を使用した React Hydrationについて聞いたことがあるかもしれません。ここでは、コンテンツが SSG/SSR 経由で配信され、最初のレンダリング中にクライアント側でレンダリングされるアプリケーションに変わります。将来の動的アプリケーションでは、SSR よりもこれが当然の選択となる可能性があります。ただし、ハイドレーションは現在、React ライブラリ全体をロードし、変更されるイベントハンドラーを HTML にアタッチすることで機能します。React はブラウザとサーバーの間で HTML の同期を保ちます。現時点では、このアプローチはお勧めできません。初期レンダリングの TTI などの Web 重要な要素に依然としてマイナスの影響があるためです。部分的なハイドレーションは、ページ全体ではなく、ページの重要な部分 (ブラウザーのビューポート内の部分など) のみをハイドレーションすることで、将来的にこの問題を解決する可能性があります。それまでは、SSR/SSG がより良い選択肢となります。

速度について話しているので、他の方法については言及しないと不利益を被ることになります。 Next.js は、次のような機能を使用して React アプリケーションの重要なレンダリングパスを最適化します。

画像の最適化 – これにより、幅と高さの <img> 属性と srcset、遅延読み込み、画像のサイズ変更が追加されます。
フォントの最適化 – これにより、重要なフォント CSS がインライン化され、font-displayのコントロールが追加されます。
スクリプトの最適化 – これにより、スクリプトをいつロードするかを選択できます。ページがインタラクティブになる前または後です。
動的インポート – コード分割のベストプラクティスを実装している場合、この機能により、必要なときに JS コードを初期レンダリングで読み込んだままにして速度を低下させるのではなく、簡単にインポートできるようになります。

速度と肯定的な Core Web Vitals は、マイナーではありますが、ランキング要素です。Next.js の機能を使用すると、競争上の優位性をもたらす優れた Web エクスペリエンスを簡単に作成できます。

ヒント
多くの開発者は、サーバーのグローバルエッジネットワークを持つ Vercel (Next.js の作成者) を使用して Next.js Web アプリケーションをデプロイしています。これにより、ロード時間が短縮されます。

Vercel は、プラットフォーム上にデプロイされているすべてのサイトの Core Web Vitals に関するデータを提供しますが、Ahrefs のSite Auditを使用して、各 URL の詳細な Web Vitals データを取得することもできます。

プロジェクトのクロール設定内に API キーを追加するだけです。

監査を実行した後、パフォーマンス領域を確認してください。そこでは、Ahrefs のサイト監査により、Chrome ユーザーエクスペリエンスレポート (CrUX) と Lighthouse からのデータを表示するグラフが表示されます。

2. ステータスコードを正しく使用する

ほとんどの SPA に共通する問題は、ステータスコードを正しく報告しないことです。これは、サーバーがページを読み込んでいるのではなく、ブラウザがページを読み込んでいるからです。一般的に次の問題が発生します。

3xx リダイレクトはなく、代わりに JavaScript リダイレクトが使用されます。
4xx ステータスコードが「見つからない」URL を報告しない。

以下では、 httpstatus.ioを使用して React サイトでテストを実行しました。このページは明らかに 404 であるはずですが、代わりに 200 ステータスコードを返します。これをソフト 404 と呼びます。

ここでのリスクは、Google がそのページを (コンテンツによっては) インデックスに登録することを決定する可能性があることです。Google はこれをユーザーに提供したり、サイトを評価するときに使用したりできます。

さらに、404 を報告すると、SEO がサイトを監査するのに役立ちます。誤って 404 ページに内部リンクし、ステータスコード 200 が返された場合、監査ツールを使用してその領域を迅速に特定することがはるかに困難になる可能性があります。

この問題を解決するには、いくつかの方法があります。クライアント側でレンダリングを行っている場合:

React Router フレームワークを使用します。
ルートが認識されない場合に表示する404 コンポーネントを作成します。
「見つからない」ページには noindex タグを追加します。
「404: ページが見つかりません」のようなメッセージを含む <h1> を追加します。404 ステータスコードは報告されないため、これは理想的ではありません。ただし、Google がページをインデックスに登録するのを防ぎ、ページをソフト 404 として認識できるようになります。
URL を変更する必要がある場合は、JavaScript リダイレクトを使用します。これも理想的ではありませんが、Google は JavaScript リダイレクトに従い、ランキングシグナルを渡します。

SSR を使用している場合、 Next.js は応答ヘルパーを使用してこれを簡単にします。これにより、3xx リダイレクトや 4xx ステータスコードなど、必要なステータスコードを設定できます。React Router を使用して説明したアプローチは、Next.js を使用しながらも実践できます。ただし、Next.js を使用している場合は、SSR/SSG も実装している可能性があります。

3. ハッシュ化された URL を避ける

この問題は React ではそれほど一般的ではありませんが、次のようなハッシュ URL を避けることが重要です。

https://reactspa.com/#/shop
https://reactspa.com/#/about
https://reactspa.com/#/contact

通常、Google はハッシュの後に何も表示しません。これらのページはすべて https://reactspa.com/ として表示されます。

解決

クライアント側ルーティングを備えた SPA は、ページを変更するために History API を実装する必要があります。

React Router とNext.js の両方を使用すると、これを比較的簡単に行うことができます。

4. 関連する場合は <a href> リンクを使用します

SPA でよくある間違いは、<div> または <button> を使用して URL を変更することです。これは React 自体の問題ではなく、ライブラリの使用方法に問題があります。

これを行うと、検索エンジンに問題が発生します。前述したように、Google は URL を処理するときに、<a href> 要素内でクロールする追加の URL を探します。

<a href> 要素が欠落している場合、Google は URL をクロールせず、PageRank を渡しません。

解決

解決策は、Google に検出させたい URL への <a href> リンクを含めることです。

URL に正しくリンクしているかどうかを確認するのは簡単です。内部リンクしている要素を検査し、HTML をチェックして、<a href> リンクが含まれていることを確認します。

上の例のように、そうでない場合は問題がある可能性があります。

ただし、<a href> リンクの欠落が必ずしも問題になるわけではないことを理解することが重要です。CSR の利点の 1 つは、コンテンツがユーザーには役立つが検索エンジンには役に立たない場合に、クライアント側でコンテンツを変更し、<a href> リンクを含めないようにすることができることです。

上記の例では、サイトはファセットナビゲーションを使用しており、検索エンジンがクロールしたりインデックスを作成したりするのに役に立たないフィルターの数百万の組み合わせにリンクする可能性があります。

Google がクロールする <a href> リンクを追加しないことでサイトがクロールバジェットを節約できるため、これらのフィルターをクライアント側で読み込むことはここでは理にかなっています。

Next.js では、クライアント側のナビゲーションを許可するように構成できるリンクコンポーネントを使用してこれを簡単にします。

完全な CSR アプリケーションを実装することに決めた場合は、onClick とHistory API を使用してReact Router で URL を変更できます。

5. 重要な HTML の遅延読み込みを避ける

React で開発されたサイトでは、ユーザーが要素をクリックするか要素の上にマウスを移動すると、コンテンツが DOM に挿入されるのが一般的です。これは単に、ライブラリによってそれが簡単に実行できるためです。

これは本質的に悪いことではありませんが、この方法で DOM に追加されたコンテンツは検索エンジンには表示されません。挿入されたコンテンツに重要なテキストコンテンツまたは内部リンクが含まれている場合、次のような悪影響を及ぼす可能性があります。

ページのパフォーマンス (Google はコンテンツを認識しないため)。
他の URL の発見可能性 (Google は内部リンクを見つけられないため)。

これは、私が最近監査した React JS サイトの例です。ここでは、ファセットナビゲーション内に重要な内部リンクがある有名な e コマースブランドを紹介します。

ただし、「フィルター」ボタンをクリックすると、モバイル上のナビゲーションを示すモーダルが DOM に挿入されました。実際にこれを確認するには、以下の HTML 内の 2 番目の <!—-> を見てください。

解決

これらの問題を見つけるのは簡単ではありません。そして、私の知る限り、それらについて直接教えてくれるツールはありません。

代わりに、次のような共通の要素を確認する必要があります。

アコーディオン
モーダル
タブ
メガメニュー
ハンバーガーメニュー

次に、それらの要素を検査し、クリックまたはホバーして要素を開いたり閉じたりするときに HTML で何が起こるかを観察する必要があります (上の GIF で行ったように)。

JavaScript がページに HTML を追加していることに気付いたとします。その場合は、開発者と協力する必要があります。これは、コンテンツを DOM に挿入するのではなく、デフォルトで HTML 内に含まれ、visibility: hidden;などのプロパティを使用して CSS 経由で非表示および表示されるようにするためです。または表示: なし。