エージェントは JavaScript SEO に役立ちますが、その前に、実際に何ができるのかを知る必要があります。Workbubby はローカルファイルを読めるのか。公開ページを閲覧できるのか。生の HTML やレンダリング済みブラウザを調べられるのか。コマンドを実行できるのか。接続済みのクロールエクスポートへアクセスできるのか。チケット作成、メッセージ送信、タスクの予約は可能なのか。その答えによって、安全なワークフローは変わります。
エージェント製品の名前だけでは権限は分かりません。似た製品でも、導入形態、ツール、承認ゲート、データアクセス、ログ記録は大きく異なります。小さな操作でも CMS、robots 指示、サイトマップ、デプロイ、公開ページを変える可能性がある SEO 作業では、とりわけ重要です。
この手順で完成するもの： 実際の Workbubby 環境に対応した機能カード、重要ページ一つに関する読み取り専用の証拠マトリクス、責任者が承認した引き継ぎ文書です。本記事は、Workbubby にターミナル、ブラウザ自動操作、Git チェックアウト、コネクター、スケジューラー、公開機能があるとは仮定しません。
第1部：決めつけずに理解するJavaScript SEO
ページが完成して見えてもSEO上の問いが残る理由
JavaScript サイトでは、サーバーの初期レスポンスの後に、スクリプト、データリクエスト、クライアント側ルーティング、UI 更新が続くことがあります。ブラウザはそれらを組み合わせ、完成したように見えるページを作ります。検索システムも URL を発見し、リクエストし、アクセス可能なリソースを処理し、リンクとコンテンツを理解し、何をインデックスするか判断する必要があります。
JavaScript 自体が問題なのではありません。ページの目的を決めるコンテンツ、安定した到達先、ページシグナルが、未確認の工程に依存することがリスクです。商品グリッドが、一部の状態で失敗するリクエストに依存するかもしれません。カードがイベントハンドラーだけで移動することもあります。無限リストの深い位置に安定 URL がない場合や、利用できない項目がクライアント側エラーを表示してもサーバーが成功ステータスを返す場合もあります。
仕事は技術を責めることではなく、実際の状態を特定することです。
四つの証拠レイヤー
レイヤー | 主な問い | 示せること | それだけでは示せないこと |
|---|---|---|---|
レスポンス | リクエストURLは何を返したか | ステータス、リダイレクト、初期HTML、ヘッダー | 最終レンダリング済みコンテンツやインデックス状態 |
ソース | アプリのコードが完了する前から何があったか | 初期title、canonical、robots、コンテンツ、リンク | ブラウザで完成したUI |
レンダリング済みページ | テストしたページ状態に何が現れたか | 表示コンテンツとレンダリング済みマークアップ | 本番履歴やGoogleによる選択 |
検索証拠 | 承認済みプラットフォームは何を報告したか | URL検査、クロール、ログ、パフォーマンス情報 | 根本原因となるコード機構 |
「不明」という言葉が重要です。Workbubby が添付スクリーンショットしか読めないなら、生の HTML は調査できません。公開ページを閲覧できてもレンダリング済みブラウザを使えないなら、動的コンテンツを確認できません。リポジトリファイルを読めても本番証拠がなければ、今日のライブ URL が返した内容を断言できません。
最初の確認に使う七つのJavaScript SEO項目
URLとレスポンスの挙動
URL は意図した最終ページへ到達するか。適切なステータスを返すか。リダイレクトは直接的で意味があるかを確認します。クライアント側リダイレクトは訪問者には動いても、レスポンス層の問題を隠すべきではありません。
主要コンテンツの利用可否
ページで最も重要な内容を特定します。商品カテゴリなら見出し、商品、価格、到達先。記事なら title と本文です。その内容が提供レスポンスにあるか、レンダリング後だけにあるか、操作後だけか、証拠に存在しないかを記録します。
クロール可能な到達先
重要な到達先は通常、安定 URL を持つ通常リンクとして表現します。クリックできるカードが、必ずしもクロール可能なリンクとは限りません。これはエージェントがマークアップを書き換えるべきという意味ではなく、責任者が現在の実装を確認すべきという意味です。
canonicalとrobotsの一貫性
canonical と robots のシグナルは、意図した URL と利用可否に一致する必要があります。canonical はヒントであり、重複または壊れたルートの万能薬ではありません。robots 指示と robots.txt の変更は影響が広いため、どちらも自動化しないでください。
フラグメントナビゲーションとクライアント側ルート
個別の発見が必要な到達先にとって、#details のようなフラグメントのみの経路はページ URL の代わりになりません。History API ルーティングは利用できますが、安定してルーティング可能な URL と直接リクエストに対する正しいサーバー処理が必要です。
遅延読み込みと無限スクロール
遅延読み込みは自動的に有害ではありません。重要なコンテンツが任意のスクロールやクリックなしに到達可能かが問題です。長い一覧では、スクロールイベントだけで十分と決めつけず、安定したページネーションまたは別のクロール可能な経路を用意する方が安全なことがあります。
メタデータと構造化データ
title、meta description、canonical、robots、構造化データは、表示ページを正確に表す必要があります。構造化データは補助的な文脈であり、Google がリッチリザルトを表示したり、そのページを上位表示したりする保証ではありません。
ページストーリーで境界を設定する
エージェントに調査を依頼する前に、ページが意図する仕事を短く記述します。
項目 | 例 |
|---|---|
ページ |
|
訪問者の仕事 | 靴を比較して各商品ページへ移動する |
必須要素 | カテゴリ見出し、商品名、価格、商品URL |
既知の証拠 | マスキング済みレンダリングDOMとレスポンスメモ |
不明な証拠 | Search Console、ログ、本番ウォーターフォール |
対象外 | 公開、デプロイ、robots変更、一括編集 |
初心者にとって「SEO を確認して」よりずっと良い依頼になります。また、エージェントに何をさせてはいけないかも伝えられます。
第2部：Workbubby機能カードから始める
製品名の正確な綴りで公開検索しても、あなたの環境で有効な Workbubby の機能を示す信頼できる公式資料は確認できませんでした。したがって安全な方法は、機能を先に確認することです。作業を渡す前に、実際に存在するツール、情報源、承認境界を Workbubby に尋ねます。
動作させずにカードだけを求める
この JavaScript SEO タスクについて、現在利用できる機能だけを報告してください。
各項目を Allowed（許可）、Not available（利用不可）、Needs my approval（要承認）
のいずれかで示してください。
- ローカルプロジェクトファイルを読む
- 公開 URL を閲覧する
- 生の HTML を調べる
- レンダリング済みページを調べる
- コマンドを実行する
- 接続済みツールまたはデータへアクセスする
- ファイルを作成または編集する
- チケットを作成またはメッセージを送信する
- 公開、デプロイ、URL送信、設定変更を行う
- 定期作業を予約する
Allowed の機能ごとに、情報源またはツールの境界を一文で記載してください。
一切の操作を行わず、製品名から機能を推測せず、認証情報を要求せず、
一覧にないコネクターを開かないでください。回答をケースと一緒に保存します。機能カードは官僚的な書類ではありません。添付ファイルしか扱えないアシスタントへターミナルエージェント用プロンプトを渡すことや、ブラウザ機能のあるエージェントが無断で書き込み操作へ進むことを防ぎます。
タスクを割り当てる前に、自分のWorkbubby環境で許可済み、利用不可、承認必須の機能を記録します。
カードに合った調査レーンを選ぶ
環境で確認した機能 | 安全な最初の作業 | 有用な出力 | 推測してはいけないこと |
|---|---|---|---|
ファイルのみ | 提供レスポンス、DOM抜粋、コードを読む | 証拠マトリクスとコード上の問い | ライブページの挙動 |
公開Webのみ | 公開ページのソースと表示ページを比較 | 限界を明記した観測ログ | インデックス状態やリポジトリ原因 |
ブラウザとファイル | 視覚症状を関連しそうな実装領域へ結び付ける | 読み取り専用調査ブリーフ | 編集権限 |
読み取り専用コネクター | 承認済みクロールまたはSearch Consoleエクスポートを要約 | 優先順位と不足データの報告 | アカウント全体へのアクセス |
書き込み可能ツール | 最初の確認では使わない | 別の承認依頼 | 書き込みが無害であること |
機能がなければ、回避させるのではなくワークフローを変えます。閲覧できないならレスポンス記録を添付し、コネクターがなければデータ責任者へエクスポートを依頼します。
タスク自体にアクセス境界を書く
機能カードは一時点の記録です。古いタスクや記憶でアクセスが広がらないよう、重要な境界を各プロンプトに繰り返します。
承認済み情報源：[一覧]
このタスクで許可された機能：[一覧]
利用できない機能：[一覧]
禁止操作：編集、送信、公開、予約、デプロイ、URL送信、設定変更、
または一覧にないコネクターへのアクセス。
回答が利用できない情報源に依存する場合は UNKNOWN と記載し、責任者が承認できる
最小の次回確認を示してください。境界を回避しないでください。第3部：読み取り専用のJavaScript SEO調査を実行する
一つのページ、一つの訪問者の仕事、一つの証拠一覧を使う
小さく始めます。代表的なカテゴリ、商品、記事、所在地ページ一つで、テンプレートの仕組みを確認できます。
承認済み情報源だけを使い、読み取り専用のJavaScript SEO調査を行ってください。
ページ：[URLまたはページファイル]
訪問者の仕事：[一文]
必須コンテンツと到達先：[一覧]
承認済み情報源：[一覧]
利用できない情報源：[一覧]
証拠がある場合、次を調べてください。
- 最終URL、ステータス、リダイレクト、canonical、robotsの一貫性
- 主要コンテンツとページtitle
- 重要な到達先への標準リンク
- フラグメントナビゲーションとクライアント側リダイレクト
- 遅延読み込みと無限スクロール
- メタデータと構造化データの一貫性
各項目について Evidence、Status（observed / plausible risk / unknown）、
訪問者の仕事に重要な理由、最小の次回確認を返してください。
編集、送信、公開、予約、デプロイ、URL送信、一覧にないコネクターへのアクセスを
行わず、インデックス、順位、クロール、パフォーマンスデータを捏造しないでください。期待する出力： 観測マトリクス。品質確認： 各行に情報源があり、利用できない確認項目を結論へ変えていないこと。復旧方法： 根拠のない行を削除し、許可されるなら不足情報を添付し、その確認項目だけ再実行します。
初心者としてマトリクスを読む
エージェントの説明は、フレームワークを知らなくても理解できる必要があります。
弱い報告 | より良い報告 |
|---|---|
「アプリはSEO向けではない」 | 「提供されたレンダリング済みマークアップに、商品到達先の標準リンクがありません。ソースHTMLとSearch Console証拠は未提供です」 |
「Googleはインデックスできない」 | 「提供された証拠からインデックス状態は判断できません。URL検査または承認済みクロールエクスポートを依頼してください」 |
「SSRを使う」 | 「提供レスポンスに主要コンテンツがありません。アーキテクチャ変更を選ぶ前に、データとルートの経路を調べてください」 |
良い報告は、判明したこと、不確かなこと、次に何を尋ねるかを責任者へ伝えます。
確認済み観測を責任者ブリーフに変換する
最初の確認で無人の変更を作らせないでください。重要な観測をエスカレーションする場合は、簡潔な引き継ぎを作ります。
項目 | 必要な詳細 |
|---|---|
観測内容 | 正確なURL、ファイル、取得日、証拠抜粋 |
重要な理由 | 失敗する可能性がある訪問者の仕事 |
証拠状態 | 観測済み、可能性のあるリスク、不明 |
最小の技術的な問い | 調べるルート、コンポーネント、仕組みを一つ |
受け入れ確認 | レスポンス、レンダリング出力、機能フロー、承認済み検索証拠 |
維持する挙動 | ナビゲーション、アクセシビリティ、分析、スタイル、データ要件 |
承認境界 | 編集、チケット、メッセージ、外部操作を誰が承認できるか |
「Workbubby はチケットを作れるかもしれない」という言葉は許可ではありません。作成するか、どこに置くか、何を含められるかを責任者が決めます。
第4部：自動化は修復ではなく通知から始める
Workbubby がタスクを予約できると確認できても、読み取り専用のリマインダーまたはレビューキューから始めます。robots 編集、デプロイ、サイトマップ変更、公開、URL 送信から始めてはいけません。
安全な週次タスクの設計
承認済みスケジュールで、提供された重要URL一覧と承認済み証拠エクスポートだけを
確認してください。各URLについて、実行日、情報源一覧、観測状態、責任者を記録します。
書き込み先に明示的な権限がある場合だけ、承認済みの場所にレビューキューを作成します。
コード編集、設定変更、公開、デプロイ、URL送信、外部メッセージ送信を行わず、
インデックス状態を推測しないでください。不足または古い証拠はUNKNOWNとします。望ましい出力は、修正ではなく問いです。
二つのカテゴリ URL について、提供レンダリング証拠に商品到達先が見えません。DOM 記録を確認し、フロントエンド責任者を割り当ててください。
最初の自動化は、無人のWebサイト変更ではなく、レビュー可能な問いを作るべきです。
エスカレーションゲートを追加する
次の状況では、エージェントタスクを停止し、具名承認を求めます。
- コード、CMSコンテンツ、robots、サイトマップ、設定の編集依頼
- 承認済みの場所を外れるチケット、メッセージ、共有操作
- 認証情報、顧客データ、新しいコネクター
- 元のページストーリーとは異なる仕組み
- サンプルページを超えてテンプレートに影響する発見
- テスト失敗、またはロールバック経路の欠落
エスカレーションには証拠と選択肢を含め、完了した操作を装った推奨にしないでください。
小さなレビューキューを維持する
項目 | 例 |
|---|---|
ケースID | JS-2026-07-01 |
ページテンプレート | カテゴリ一覧 |
証拠状態 | 可能性のあるリスク |
観測 | 提供DOM抜粋に標準到達先リンクなし |
不足証拠 | ソースレスポンスとURL検査 |
次の責任者 | フロントエンド責任者 |
操作境界 | 調査のみ |
レビュー日 | ページ責任者が予約 |
責任と不確実性が見えるため、順位付けされていない警告で埋まったダッシュボードより有用です。
第5部：人間が承認した変更を検証する
責任者がコードまたは設定変更を承認したら、実際の環境に合う別の実装ワークフローを使います。Workbubby が補助できるのは、機能カードで確認され、明示的に承認された範囲だけです。
順序に沿って検証する
- 必須の訪問者行動： ページストーリーの仕事を完了できるか。
- レスポンス挙動： 最終URL、ステータス、リダイレクト、canonical、robotsが承認目標と一致するか。
- レンダリング出力： 必須コンテンツと到達先が該当状態にあるか。
- 維持する挙動： キーボードナビゲーション、視覚状態、分析、エラー状態が引き続き動くか。
- 権限のある検索証拠： 後日、URL検査、クロール、ログ、Search Consoleは何を示すか。
一つのテストですべてを代替できません。ブラウザテストはインデックス登録の証明ではなく、きれいなソースレスポンスもレンダリング済みデータの成功を証明しません。
外部操作前にロールバックを定義する
承認済み変更には正確な取り消し条件を記載します。機能テストの失敗、分析イベントの破損、アクセスできないナビゲーション、誤ったステータス、予想外のテンプレート範囲などです。ロールバック方法と責任者を言えないなら、無人自動化の準備はできていません。
決定を記録する
証拠一覧、責任者判断、変更記録、テスト結果、日付、残る不明点を保存します。将来のエージェントは根拠のない診断を再生成せず、この記録から始めるべきです。
Workbubbyができると決めつけてはいけないこと
調査時点で正確な製品構成を示す信頼できる公式資料を確認できなかったため、Workbubby が次を実行できると仮定しないでください。
- ターミナルコマンドを実行する
- 公開サイトを閲覧またはレンダリングする
- Gitリポジトリを読む
- Search Console、分析、クロールへアクセスする
- タスク、チケット、メッセージを作成する
- 定期作業を予約する
- デプロイまたは公開する
- 特定の方法でデータを保護する
自分の環境で機能を質問してください。これは製品への批判ではなく、チームごとに異なる構成が可能なエージェントを安全に運用する方法です。
よくある間違い
ターミナルエージェントのプロンプトを未知の環境へコピーする
プロンプトが想定するツールがないかもしれず、意図しない書き込みツールを持っているかもしれません。機能カードから始めてください。
エージェントに自分の権限を決めさせる
エージェントは利用可能なツールを報告できますが、そのタスクでどのツールとデータを承認するかは人間の責任者が決めます。
ブラウザのスクリーンショットを完全な技術監査として扱う
有用な証拠ですが、レスポンスステータス、ソースHTML、コード原因、インデックス登録までは示しません。分かることと分からないことを明記します。
スケジュールを無言の修復システムにする
観測とレビューキューから始めます。書き込み操作は、アクセス範囲、承認動作、テスト、責任者、ロールバックをすべて明示してから追加します。
WorkbubbyをOpenClawと同じ製品と呼ぶ
自分の資料で関係が確認されない限り、別製品として扱います。パターンが似ていても、ツール、データ処理、権限が同一とは限りません。
よくある質問
WorkbubbyはOpenClawと同じですか？
導入資料に記載がない限り別製品として扱ってください。似たエージェントパターンは、機能やセキュリティ挙動が同一である証拠ではありません。
CodexやClaude CodeのskillをWorkbubbyで再利用できますか？
インストール前提ではなく、意思決定の考え方を再利用します。環境がアクセス・承認できる内容を確認した後、Workbubby の文書化された設定へ変換してください。
最も安全な最初のWorkbubbyタスクは何ですか？
機能カードを依頼し、次に提供済み情報源だけを使って、重要ページ一つの読み取り専用証拠マトリクスを作らせます。
WorkbubbyはGoogleがページをインデックスしたか分かりますか？
環境内の権限のある検索情報源がその情報を提供する場合に限ります。ブラウザ表示、HTMLファイル、リポジトリのチェックアウトだけでは判断できません。
最も安全な最初の自動化は何ですか？
承認済み入力から責任者レビュー用キューを作る、読み取り専用のリマインダーです。最初からデプロイ、公開、robots変更、URL送信を自動化しないでください。
著者：Martin Hayes。Auspia で 200 件を超える実行チェックリストを作成した GEO プレイブックビルダー。段階的なワークフロー、実践ガイド、運用チェックリストについて執筆しています。
