JavaScript SEO は開発者だけの専門分野に見えます。しかし、最初に確認すべきことは意外と身近です。このページは訪問者に何をしてもらうためのものか。どの本文とリンクが必ず使えるべきか。サーバーは何を返したか。ページの実行後に何が現れたか。そして、まだ分かっていない事実は何か、という問いです。
Hermes Agent は、混ぜるべきではない複数の作業を分けて進められる点で、JavaScript SEO の調査と相性がよいツールです。ある役割は初期レスポンスを記録し、別の役割は提供されたレンダリング証拠を確認し、三つ目の役割は両方の報告を意思決定カードにまとめます。ただし、コードを変更するかどうかを決めるのは常に人間の責任者です。
この手順で完成するもの： 重要な URL 1 件について、出典を明記した証拠、未確認事項、次に行う範囲の限られた対応を 1 ページにまとめたケースファイルです。このワークフローは、Google にインデックスされたことや順位を保証するものではなく、エージェントに本番環境の編集権限を与えるものでもありません。
第1部：JavaScriptを書かない人のためのJavaScript SEO入門
ページは段階的に届けられる
従来型の HTML ページを開くと、役立つコンテンツの大部分がすでにサーバーレスポンスに含まれていることがあります。一方、JavaScript への依存が大きいサイトでは、最初のレスポンスは開始点にすぎません。ブラウザがスクリプトを読み込み、追加データを取得し、商品カードやナビゲーションを組み立て、初期 HTML の到着後にメタデータを更新する場合があります。
それだけで SEO に悪いページだと判断することはできません。Google は JavaScript を処理でき、多くの現代的なサイトが問題なく利用しています。実務上のリスクは「状態の不一致」です。訪問者には最終的に完成したページが見えていても、重要な本文、URL、ページシグナルが初期レスポンスにない、操作するまで読み込まれない、失敗したリクエストの先にある、または発見しにくい形式で表現されている可能性があります。
ページを、観測できる四つの層として考えてみましょう。
層 | 初心者が尋ねること | 役立つ証拠 |
|---|---|---|
URL とレスポンス | リクエストした URL は意図したページを返したか | ステータス、リダイレクト、レスポンスヘッダー |
ソース HTML | ブラウザがアプリを実行する前から存在したものは何か | 保存したレスポンス、または「ページのソースを表示」 |
レンダリング後のページ | スクリプトとデータ取得の完了後に何が表示されたか | レンダリング済み DOM、スクリーンショット、ブラウザ記録 |
検索に関する証拠 | 権限のある検索ツールが実際に何を報告したか | URL 検査、クロール結果、ログ、Search Console |
各層が答える問いは異なります。スクリーンショットが示すのは一つのブラウザでの表示であり、サーバーが返した内容ではありません。200 レスポンスは配信成功を示しますが、インデックス登録を示しません。レンダリング済み DOM に通常のリンクがあっても、検索エンジンがその URL をインデックスに採用した証明にはなりません。
最初に見るべき六つのシグナル
初心者がページを確認するために、フレームワーク全体を学ぶ必要はありません。発見性と理解しやすさに直結する六つのシグナルから始めます。
- ステータスとリダイレクト。 有効なページは、その用途に合ったステータスを返す必要があります。存在しない商品が成功した空ページを装ってはいけません。リダイレクトは、分かりにくい連鎖を作らず正しい到達先で終わるべきです。
- 主要コンテンツ。 ページタイトル、主要な説明、商品や記事の情報など、そのページの目的を決める内容が必要な状態で利用できることを確認します。クリックや不安定なリクエストの後でしか現れないなら、その依存関係を記録します。
- クロール可能なリンク。 重要な到達先には通常、
hrefを持つa要素のような、安定した URL の実リンクを使います。イベントハンドラーだけで動くカードは訪問者にはクリックできても、発見経路としては弱くなることがあります。 - canonical と robots の指示。 canonical URL、robots メタ指示、レスポンスステータス、サイトマップ、内部リンクが同じ説明をしているか確認します。canonical は命令ではなくヒントです。サイト側で防げる URL 重複を隠すために使うものではありません。
- 段階的な読み込み。 遅延読み込み画像、無限スクロール、クライアント側ページネーションによって、価値ある項目がスクロールやクリック、安定 URL のないブラウザ状態だけに依存しないようにします。
- メタデータと構造化データ。 JavaScript で作る title、description、canonical、構造化データは、画面に見えるページを正確に表す必要があります。構造化データは解釈を助けますが、リッチリザルトを保証しません。
レンダリングとインデックス登録は同じではない
この区別を理解すると、誤ったチケットを大幅に減らせます。レンダリングとは、システムがページを処理して意図したコンテンツを取得できるかという問いです。インデックス登録とは、検索エンジンが URL を保存し、検索結果に出せる候補として選んだかという問いです。ランキングは、どの検索語で、いつ、何位に表示されたかを扱います。
一度のブラウザ操作だけで三つすべてを証明することはできません。証拠がスクリーンショットだけなら、正直な結論は「このブラウザ状態ではコンテンツが表示された。サーバーレスポンス、検索エンジンによるレンダリング、インデックス採用は未確認」となります。「Google にはページが見えない」と断言するより、この表現の方が、次に必要な証拠を明確にします。
チェック前にページストーリーを書く
エージェントは長いチェックリストを作れても、そのページの事業目的を見落とすことがあります。最初に短いページストーリーを書きます。
項目 | 例 |
|---|---|
ページ |
|
訪問者の目的 | 商品を比較して商品詳細ページへ移動する |
必ず表示する内容 | カテゴリ名、商品名、価格、商品リンク |
一致すべきシグナル | 200 レスポンス、canonical URL、indexable な robots 指示、title |
利用できる証拠 | レスポンス記録とレンダリング済み DOM |
利用できない証拠 | Search Console とサーバーログ |
対象外 | 基盤移行、公開作業、robots.txt 変更、一括編集 |
このページストーリーを Hermes の各役割が共有する調査票にします。人間の責任者も「その指摘は訪問者の目的やページシグナルに影響するか」で、ケースに含めるべきか判断できます。
第2部：調査をHermes Agentチームのランブックにする
Hermes Agent の公開情報では、agents、tools、skills、memory、automation、subagents などの概念が説明されています。ただし、実際に使えるツールと権限は導入環境によって異なります。そこでこのランブックでは、すべての Hermes 環境が URL を閲覧し、コマンドを実行し、リポジトリを読み、チケットを作れるとは仮定せず、必要な出力と境界を定義します。
三つの役割に異なる証拠作業を割り当てる
「JavaScript SEO を修正する」という一つの大きなタスクを作らないでください。証拠収集、解釈、実行を分けます。
役割 | 読むもの | 作るもの | 禁止すること |
|---|---|---|---|
レスポンス調査役 | 提供されたレスポンス、ヘッダー、ソース、リダイレクト | レスポンスの事実とシグナルの矛盾 | Google のインデックス状況を推測する |
レンダリング調査役 | レンダリング済み DOM、ブラウザ記録、承認済みページ証拠 | コンテンツ、リンク、読み込みの観察結果 | コンポーネントやルーティングを変更する |
トリアージ編集役 | 二つの報告と利用権限のあるエクスポート | ケースファイル、優先度、責任者への質問 | 仮定を事実として書き換える |
三つの subagent、順番に実行する三つのタスク、または一つのエージェントによる明確に分けた三段階でも構いません。目的はエージェント数を増やすことではなく、受け渡しを検査可能にすることです。
ケースファイルを使うと、技術判断の前に、証拠の出所と不確実な状態を分けたまま確認できます。
共通の証拠契約を決める
調査役が動き始める前に、利用してよい情報源を指定します。入力がなければ、もっともらしい答えで補わず「利用不可」と記録させます。
一つの JavaScript SEO ケースを調査します。
対象ページ：[URL または提供されたページ証拠]
訪問者の目的：[1文]
必須ページ要素：[一覧]
利用を許可された証拠：[レスポンス HTML、レンダリング済み DOM、HAR、
スクリーンショット、クロール結果、またはリポジトリファイル]
利用できない証拠：[一覧]
読み取り専用で作業してください。ファイル編集、公開、URL 送信、CMS 変更、
メッセージ送信、チケット作成、明示的に許可されていないアカウントへの
アクセスは禁止します。
すべての観察結果に証拠の出所を記載し、次の状態を一つ使います：
CONFIRMED、PLAUSIBLE RISK、UNKNOWN、OWNER DECISION。
権限のある情報源から具体的な証拠が提供されない限り、検索エンジンが
ページをインデックス、レンダリング、またはランク付けしたと主張しないでください。期待する出力： 短い証拠台帳。品質チェック： すべての観察結果に出所があること。復旧方法： 出所のない結論があればその行を削除し、許可された証拠リストだけで役割を再実行します。
レスポンス調査役を実行する
レスポンス調査役は、ページアプリケーションが動く前に届いた内容を記述します。承認されたツールに応じて、保存レスポンス、クロール結果、公開 URL のいずれかを確認できます。記録する事実には次が含まれます。
- 既知のリダイレクト後の最終 URL
- 確認できる場合の HTTP ステータス
- レスポンス内の title、canonical、robots 指示、言語シグナル
- ページ目的を決めるコンテンツの有無
- 必須の到達先への通常リンク
- 提供ソースから確認できるスクリプトとデータ依存
- indexable なページが別 URL を canonical に指定する、といった矛盾
簡単な表で出力させます。
観察結果 | 証拠 | 状態 | 重要な理由 | 次の確認 |
|---|---|---|---|---|
提供レスポンスにカテゴリ見出しがない | レスポンス記録と行番号 | Confirmed | 初期レスポンスにページ目的を示す文がない | レンダリング済み DOM と比較 |
canonical がリクエスト URL を指す | レスポンス記録 | Confirmed | シグナルが内部で一致する | レンダリング後にも確認 |
Google が選択した canonical | 権限のある情報源なし | Unknown | マークアップだけでは推測できない | 必要なら URL 検査を依頼 |
コンテンツがレスポンスにないという理由だけで、SSR を推奨してはいけません。見つけたのは一つの状態であり、原因や必要な修正はまだ確定していません。
レンダリング調査役を実行する
レンダリング調査役は、チームが実際に提供できる完成状態を調べ、ページストーリーとレスポンス調査役の台帳を比較します。
次を確認させます。
- 主要コンテンツが不自然なユーザー操作なしで表示されるか
- 重要な到達先が安定したリンクとして表現されるか
- レンダリング後にメタデータや canonical が変化するか
- 遅延読み込み項目がスクロールや操作を必要とするか
- 無限スクロールが安定して到達できるページパスを公開しているか
- エラー、空、利用不可の各状態にも意味があるか
- 必須データリクエストが失敗したときコンテンツがどう変わるか
スクリーンショットしかなければ、リンクのマークアップやメタデータは確認できません。レンダリング済み DOM はあってもネットワーク記録がなければ、リクエスト失敗の理由を説明できません。出力には必ずこうした制限を書きます。
トリアージ編集役に不確実性を残させる
トリアージ編集役は二つの報告を統合します。断定的に聞こえる文章に直すのではなく、観察事実、考えられる仕組み、不足している情報源の違いを保つことが役目です。
状態 | 意味 | 例 |
|---|---|---|
Confirmed | 提供された証拠が状態を直接示す | 商品リンクがレンダリング済み DOM 記録にない |
Plausible risk | 証拠は失敗経路を示唆するが影響は未確定 | リンクがクリックハンドラーに依存している可能性 |
Unknown | 必要な証拠が提供されていない | 検索エンジンが選択した canonical |
Owner decision | 複数の実装が妥当になりうる | カード全体または主要操作にリンクを追加する |
優先度は、技術的に聞こえるかではなく、ページへの影響と証拠の強さで決めます。収益に関わるテンプレートから主要商品リンクが欠けていれば、すぐ責任者が確認すべきかもしれません。根拠のないフレームワークの好みは優先事項ではありません。
一つの指摘を承認カードに変える
トリアージ後、確認済みまたは十分に裏づけられた指摘を一つ選びます。監査全体を実装作業へ渡してはいけません。
指摘 ID：JS-01
ページと訪問者の目的：[URL と1文]
証拠：[具体的なレスポンス、DOM、またはコードの観察]
状態：[CONFIRMED / PLAUSIBLE RISK]
訪問者への影響：[到達または理解が難しくなるもの]
提案する最小限の対応：[範囲を限定した変更または調査を一つ]
影響するテンプレート／システム：[KNOWN / UNKNOWN]
合格条件：[ローカル動作、レスポンス、レンダリング済み DOM、機能リンク]
ロールバック：[以前の動作へ戻す方法]
意思決定者：[氏名または役割]
実装状態：WAITING FOR APPROVAL
範囲を限定した承認カードなら、エージェントの指摘を、担当者が確認できる意思決定に変えられます。
Hermes はカードを準備できますが、事業上または技術上の判断の所有者にはなれません。memory や automation があっても、それだけで重大な変更が安全になるわけではありません。
承認後は別の実装タスクを作る
責任者が対応を承認し、Hermes 環境に適切なツールがある場合は、承認範囲だけを持つ新しいタスクを作ります。監査タスクを黙って書き込みタスクへ変えないでください。
ケース JS-01 で承認された対応だけを実装してください。
変更前に、次の4点を言い直してください。
1. 影響するファイルまたはシステム
2. 合格条件
3. 引き続き禁止される操作
4. ロールバック条件
変更後は正確な diff または変更記録を示し、承認されたテストだけを実行します。
デプロイ、公開、URL 送信、無関係なファイル変更、範囲拡大は禁止します。
想定ファイルや仕組みが承認文書と異なる場合は停止し、新しい証拠を責任者へ返してください。期待する出力： 一つのレビュー可能な変更記録。品質チェック： 無関係なファイルや操作がないこと。復旧方法： テストが失敗した、または仕組みが承認内容と違った場合は、承認済みの方法で元に戻してケースを再開します。
結果を層ごとに検証する
エージェントが成功を報告しただけでは実装完了ではありません。ページが届けられる順番で検証します。
- ローカル動作： ページやコンポーネントがビルドでき、意図した訪問者フローが動き、アクセシビリティや計測が壊れていない。
- レスポンス層： ステータス、リダイレクト、title、canonical、robots 指示、重要なソース本文が承認目標と一致する。
- レンダリング層： 必須コンテンツとリンクが、隠れた操作依存なしで必要なページ状態に現れる。
- 検索に関する証拠： 権限のあるデータが利用可能になった時点で、URL 検査、クロール、ログ、Search Console が実際に報告した内容を記録する。ローカルレンダリングを代用しない。
- 意思決定記録： 日付、証拠、承認対応、テスト結果、責任者、ロールバック参照を保存する。
一つの層が失敗しても、自信のある要約で埋め合わせてはいけません。失敗したチェックと次の最小調査を責任者へ返します。
無理なく続けられるHermesの週間ルーチン
サイト全体へ大量のエージェントを放つのではなく、毎週一つ、価値の高い代表テンプレートを選びます。
日または段階 | 活動 | 出力 |
|---|---|---|
受付 | URL を一つ選び、ページストーリーを書く | 共有調査票 |
証拠 | レスポンスとレンダリングの調査役を実行 | 二つの台帳 |
トリアージ | 事実、リスク、未知を統合 | 一つのケースファイル |
レビュー | 範囲を限定した対応を一つ選ぶ | 承認済みカード |
検証 | 承認された変更または調査をテスト | 層別の結果記録 |
複数ページで同じ仕組みが確認できたら、影響テンプレートを対象に新しいケースを開きます。一つの URL だけでサイト全体の欠陥だと決めないでください。
よくある失敗と立て直し方
エージェントが重複した報告を作る
担当範囲が重なっています。役割ごとに異なる情報源リストと出力契約を与えます。レスポンス調査役はレンダリング動作を解釈せず、レンダリング調査役はレスポンスの事実を書き直しません。
データがないのにトリアージ報告が断定的になる
四つの状態ラベルを必須にし、証拠の出所がない行を却下します。Unknown は失敗ではなく、次に責任者が要求すべきものを示す有用な結果です。
バグを特定する前にSSRの議論になる
ページストーリーと確認済み症状へ戻ります。SSR、prerendering、hydration の変更、client-only rendering は設計上の選択肢であり、万能な答えではありません。
定期タスクがノイズを増やす
対象を一つのテンプレートまたは提供 URL リストに絞ります。スケジュールが作るべきものは、日付、失敗、担当者を含む確認待ちキューです。別途承認されていない変更や外部メッセージを作ってはいけません。
レスポンス報告とレンダリング報告が食い違う
その違いこそ調査対象であることがよくあります。都合のよい方を選ばず、両方の観察を残します。たとえばソースに商品詳細がなく、レンダリング済み DOM には存在する場合、次の問いは、そのレンダリング経路がページに対して信頼できるか、結果に安定した到達先があるかです。矛盾を失敗の証明にせず、既知のレスポンス記録や承認済みクロール結果など、最小の追加情報源を求めます。
一つのページからサイト全体の結論を求められる
一つの URL からテンプレート仮説は作れますが、その適用範囲は証明できません。最初のケースで共有されそうな仕組みを特定した後にだけ、二つ目の代表ページを追加します。二つ目が異なるならケースを分けます。万能な欠陥だと宣言するより遅く見えますが、一つの例外を理由に高額なプロジェクトを始めるリスクを避けられます。
初回ケースの実践例
オーガニック訪問があるカテゴリページで、SEO 担当者が商品カードを監査しにくいと気づいたとします。ページストーリーでは、訪問者が商品を比較し、詳細ページを開けることが目的です。レスポンス調査役は、提供された記録から 200 レスポンスと自己参照 canonical を確認しましたが、初期ソースには商品名がありません。レンダリング調査役はレンダリング後の名称と価格を確認したものの、記録が不完全なため、カードの主要操作が通常リンクかどうかを確認できません。
トリアージ編集役は「Google が商品をインデックスできない」と書くべきではありません。根拠のあるケースファイルは、もっと小さくなります。
項目 | 状態 | 次の対応 |
|---|---|---|
リクエスト URL は正常応答する | Confirmed | 基準値として維持 |
商品コンテンツはレンダリング後に現れる | Confirmed | レンダリング依存を記録 |
商品の到達先に通常リンクを使う | Unknown | レンダリング済みマークアップまたはコード責任者の確認を依頼 |
検索エンジンによるインデックス採用 | Unknown | 必要なら権限のある URL 検査を依頼 |
最初の意思決定は、リポジトリ確認を許可するだけでも構いません。後にコード責任者が、カードが安定した主要リンクを持たずクリックハンドラーを使っていると確認したら、二つ目の意思決定で、小さくテスト可能なコンポーネント変更を承認できます。順位データが変わる前でも、心配をあおる主張から、検証可能な仕組みへ進めたなら、Hermes ワークフローは成功です。
よくある質問
複数のHermesエージェントは一つのページを並行して調べられますか？
はい。読み取り専用の異なる役割、重ならない証拠ソース、共通ケースファイル形式がある場合に有効です。複数エージェントに同じ実装領域を編集させないでください。
HermesだけでGoogleがJavaScriptページをインデックスしたか分かりますか？
ソースコードやブラウザ表示だけでは分かりません。権限のある URL 検査、クロール、ログ、Search Console の証拠を提供してください。なければインデックスの問いは Unknown のままにします。
レスポンス調査役は常に本番URLを閲覧すべきですか？
いいえ。利用可能で承認されたツールと情報源だけを使います。制限された環境では、保存レスポンスやクロール結果が適切な入力になることがあります。
ソースにない要素はすべてSSRが必要ですか？
いいえ。実際の解決策は、安定リンク、正しいステータス、利用可能なデータ経路、一貫したメタデータ、または小さなテンプレート変更かもしれません。先に仕組みを診断します。
初心者に最適な最初のHermesタスクは何ですか？
重要な URL 一つに対してレスポンス調査役を一つ実行します。出所付きの事実表を必須にし、その後でレンダリング証拠が必要か判断してください。
著者：Julian Mercer。Auspia で 14 年の経験を持つテクニカル SEO 実務家。クロール可能性、レンダリング、サイト構造、AI が読み取りやすいコンテンツの技術基盤について執筆しています。
