ECサイトのJavaScript SEO｜商品情報とリンクを正しく伝える方法
目次
商品ページをブラウザで開くと、商品名も価格も表示される。それでも、検索エンジンが同じ情報を取得できているとは限りません。ECサイトのJavaScript SEOでまず確認したいのは、商品情報が読み込まれる仕組みと、商品へ移動するリンクの書き方です。
JavaScript SEOとは、JavaScriptで動くページの内容を、検索エンジンにも適切に取得・理解してもらうための取り組みです。GoogleはJavaScriptを実行できますが、クリック後にしか表示されない情報や、取得に失敗する商品データまで自動的に補ってくれるわけではありません。この記事では、商品ページとカテゴリページを例に、確認方法と開発担当者への修正の伝え方を説明します。
GoogleがJavaScriptページを処理する流れ
GoogleはまずURLをクロールし、サーバーから返されたHTMLを取得します。その後、レンダリングの処理でJavaScriptを実行し、生成された内容とリンクを分析します。
初期HTMLに商品情報がないアプリでは、レンダリングが終わるまで主要内容が見えません。サーバーサイドレンダリングや事前生成は、利用者とクローラーへ早く内容を届ける方法として有効です。
「初期HTML」はサーバーが最初に返すHTML、「レンダリング後のHTML」はJavaScriptの処理を反映した状態です。たとえば、次のHTMLだけが返る商品ページでは、この時点では商品名や説明を読み取れません。以下は仕組みを説明するための簡略例で、実在する店舗の実装ではありません。
<main id="product"></main>
<script src="/assets/product.js"></script>JavaScriptが商品データを取得して、商品名や説明を追加できれば、Googleがレンダリング後の内容を扱える可能性はあります。初期HTMLに本文がないことだけを理由に「インデックスされない」と判断せず、実際の処理結果を確かめてください。URLが見つかる経路については、Googleのクロールの仕組みも参考になります。
各商品と画面に固有URLを持たせる
一つのURLで画面だけを切り替える構成では、商品やカテゴリを個別に共有・再訪・クロールできません。商品詳細、カテゴリ、ページ送りなど検索対象の画面には固有URLを用意します。
直接URLを開いたときも同じ商品と選択状態が表示され、適切なHTTP応答を返すことを確認します。アプリ内の移動でだけ表示できる画面は避けます。
クロール可能なリンクを使う
Googleは一般にa要素のhrefにあるURLをリンクとして発見します。divやbuttonのクリックイベントだけで商品ページへ移動させず、商品名や画像へ通常リンクを設定します。
JavaScriptでDOMへリンクを追加すること自体は可能ですが、レンダリング後に正しいhrefが存在するかを確認します。利用者のクリック、スクロール、入力後にしか作られないリンクは発見経路として不安定です。
たとえば、商品一覧で次のようにクリック時の処理だけを設定していると、HTMLのリンクから移動先を取り出せません。
<!-- 修正前：クリック処理だけで商品へ移動 -->
<div onclick="location.href='/products/cup-a/'">
陶器のマグカップ A
</div>商品詳細への移動は、次のように通常のリンクとして表現します。カートへの追加など、その場で実行する操作のボタンまで、すべてリンクに置き換える必要はありません。
<!-- 修正後：移動先をhrefに指定 -->
<a href="/products/cup-a/">陶器のマグカップ A</a>この違いは、検索エンジンだけでなく、リンクを別タブで開く利用者にとっても重要です。アプリ内で画面を切り替える場合も、直接URLを開いたときに同じ商品が表示されることまで確認します。
主要商品情報をレンダリング結果へ出す
商品名、価格、在庫、説明、画像、型番、購入可否がレンダリング後のDOMにあることを確認します。canvasやCSSのcontentだけで文字を表示すると、検索エンジンが本文として扱えない場合があります。
商品データの取得に失敗し、空のテンプレートだけを200で返し続けると、内容不足やsoft 404として扱われる可能性があります。存在しない商品IDは404などで伝え、一時的なサーバー障害と区別してください。在庫切れでも商品情報が残るページは、商品が存在しないページとは別に判断します。
titleとmeta description
JavaScriptでtitleやmeta descriptionを設定できますが、初期HTMLからページ固有の値を出せるならそのほうが安定します。商品遷移後に前商品のtitleが残らないか、直接アクセス時も正しいかをテストします。
検索結果ではGoogleがtitleやスニペットを書き換える場合があります。書き換えを避ける小技ではなく、画面内容と一致する固有情報を提供します。
canonicalとrobots meta
canonicalは可能なら初期HTMLへ出します。JavaScriptで変更する場合、初期HTMLのcanonicalと異なる値へ書き換えると手掛かりが矛盾します。
初期HTMLにnoindexを置き、JavaScriptでindexへ戻す方法は避けます。Googleがnoindexを見てレンダリングを省略する可能性があるため、検索対象ページには最初から正しいrobots設定を返します。
robots.txtでリソースを塞がない
JavaScript、CSS、APIなど、表示に必要なリソースをGooglebotが取得できる必要があります。robots.txt、WAF、認証、地域制限がレンダリングを妨げていないか確認します。
機密APIを公開する必要はありません。検索対象の公開商品情報を、認証なしで安全に取得できる配信方法を用意します。
遅延読み込みと無限スクロール
画像の遅延読み込みでは、スクロールなど利用者の操作がなくても必要な画像URLが発見できる実装にします。ファーストビューの主要画像は優先的に読み込むことも検討します。
商品一覧の追加読み込みは、ページ単位のURLと通常リンクを用意します。クローラーが「もっと見る」を押すことを前提にしません。カテゴリの2ページ目を直接開いても商品リンクが表示されるか確認してください。具体的な設計は、無限スクロールと「もっと見る」をクロール可能にする実装で解説しています。
構造化データ
JSON-LDをJavaScriptで生成することはできますが、価格や在庫の変化が速い商品では、初期HTMLへ正確なProduct情報を出す方法が安定します。画面表示と構造化データを同じ商品データから生成します。
バリエーション変更後に価格だけ変わり、構造化データが初期商品のまま残る事故を防ぎます。直接アクセスしたバリエーションURLでも正しい値を返します。
検証方法
最初から全商品を調べるより、通常の商品、在庫切れ商品、カテゴリの2ページ目など、テンプレートと状態の異なるURLを数本選ぶほうが原因を切り分けやすくなります。次の順番で、同じURLを確認してください。
1．初期HTMLに何があるかを見る
ブラウザの「ページのソースを表示」で、実際の商品名、型番、商品リンクのURLを検索します。ここで見つかる内容は初期HTMLの確認材料です。開発者ツールのElementsに表示される内容とは区別してください。ElementsにはJavaScript実行後の変更も含まれます。
2．URL検査で現在の公開ページをテストする
Search Consoleで対象プロパティを選び、URL検査に商品の完全なURLを入力します。最初に表示される登録状況や最終クロール日時は、Googleが保持する情報です。現在の状態を調べるには「公開URLをテスト」を実行します。
テスト後に「テスト済みのページを表示」などの詳細を開き、HTML、スクリーンショット、取得できなかったリソースを確認します。画面上の名称は変更される場合があります。HTML内で商品名・型番・リンク先を検索し、スクリーンショットではエラー画面や読み込み中の表示になっていないかを見ます。
3．「見えない場所」から修正先を決める
初期HTMLにはなく、テスト結果にはある場合は、JavaScriptによって情報が追加されています。それだけで障害とはいえません。一方、通常のブラウザでは見えるのにテスト結果にない場合は、商品API、必要なファイル、操作後に読み込む条件などを確認します。HTMLに商品名はあってもリンク先がない場合は、商品データではなく一覧のリンク実装を調べます。
公開URLのテストに成功しても、インデックス登録や検索表示が保証されるわけではありません。登録状況の確認は別に行います。インデックス状況の確認方法と合わせて、「取得できるか」と「登録されているか」を分けて判断してください。
4．状態を変えて再テストする
同じ商品でも、直接アクセスした場合と、カテゴリから画面遷移した場合で結果が異なることがあります。色違いの商品、在庫切れ、存在しないIDも確認し、URL、確認日時、期待する商品情報、実際の結果を記録します。商品構造化データはリッチリザルトテストでも検証しますが、その合格だけで本文やすべてのリンクが正しく取得できるとは判断しません。
よくある間違い
- ブラウザで見えるだけで問題ないと判断する
- 商品リンクをクリックイベントだけで実装する
- 初期HTMLのnoindexを後から解除する
- API失敗時も空ページに200を返す
- バリエーション変更後のメタ情報を確認しない
確認項目
- 検索対象の各画面に固有URLがあるか
- レンダリング後に商品情報とhrefリンクがあるか
- 必要リソースをGooglebotが取得できるか
- canonicalとrobots設定が初期HTMLから正しいか
- エラー時に適切なHTTP応答を返すか
- URL検査でGoogleが見る内容を確認したか
サーバーサイドレンダリングの判断
サーバーサイドレンダリングは、リクエスト時に主要なHTMLを生成して返します。事前生成は、公開時にHTMLを作って配信します。どちらも初期表示とクロールを安定させやすい一方、在庫や価格の更新方式を設計する必要があります。
すべてをサーバー側へ移すのではなく、商品名、説明、価格、在庫、リンク、メタ情報など検索と初期表示に重要な部分を優先します。カート操作やお気に入りなど対話機能はクライアント側で追加できます。
レンダリング障害を監視する
JavaScriptファイルの404、APIの5xx、CORS、タイムアウト、認証エラーを監視します。一般ユーザーのブラウザではキャッシュで動き、Googlebotの初回取得だけ失敗することもあります。
エラー監視にはページURL、リソースURL、発生時刻、端末、デプロイ版を残します。検索流入が減ってから調べるのではなく、公開直後に主要テンプレートのレンダリングを自動確認します。
キャッシュとファイル更新
GoogleのレンダリングではJavaScriptやCSSがキャッシュされることがあります。内容が変わったファイルは、ファイル名へ内容に基づくバージョンを含めるなど、更新を正しく取得できる仕組みにします。
同じURLのスクリプトを上書きし続けると、古いHTMLと新しいJavaScript、またはその逆が組み合わさる可能性があります。デプロイ時の互換性とキャッシュ無効化を設計します。
開発の受け入れ条件
機能が操作できることに加え、固有URLを直接開ける、初期またはレンダリング後に主要情報がある、hrefリンクがある、正しいステータスとcanonicalを返すことを受け入れ条件にします。
商品データが空、APIが遅い、JavaScriptが無効、botがリソースを取得できない場合も確認します。例外状態を含めてテストすることで、空の200ページや孤立URLを防げます。
開発担当者には「JavaScriptをSEO対応してください」だけでなく、「カテゴリ2ページ目を直接開いた際に、商品名と商品詳細へのhrefリンクがHTMLから確認できること」のように、対象URL・期待結果・確認方法をセットで渡します。修正前後のテスト結果を残せば、次の改修時にも同じ条件で確認できます。
まとめ
ECサイトのJavaScript SEOでは、商品やカテゴリに固有URLを持たせ、主要情報と通常リンクをレンダリング結果へ安定して出します。利用者の操作を待たなければ内容が見えない設計は避けます。
初期HTML、レンダリング後のHTML、HTTP応答を分けて確認してください。商品状態やバリエーションごとのテストを自動化すると、機能追加後の見落としを減らせます。
まずは代表的な商品ページ1本とカテゴリページ1本で、商品名・価格・リンク先がどの段階で現れるかを確認してみてください。問題のあるテンプレートが分かってから修正範囲を広げると、調査と開発の手戻りを抑えられます。
仕様の確認には、Google公式のJavaScript SEOの基本と、Search ConsoleのURL検査ツールの説明を参照しています。
