Browser API: マーケティング Agents 向けのレンダリングされた Web 読み取り

UnifAPI が Browser の Markdown・HTML・スクリーンショット・リンクを追加した理由: fetch では JavaScript 中心のページを取りこぼすからです。
要点: Browser API は、実際の Web ページを読む必要がある Agents のための補助的な能力です。JavaScript をレンダリングし、Markdown・HTML・スクリーンショット・リンクを返すので、アシスタントはページが実際に表示している内容を引用できます。
多くのアシスタントは、すでに基本的な fetch ツールを備えています。それは便利ですし、UnifAPI はプレーンな URL 取得を目玉製品として再販しようとはしません。
しかしマーケティングリサーチは、単純な fetch ではうまく読めないページにしばしばぶつかります。クライアントレンダリングのページ、ドキュメントサイト、料金表、動的な比較ページ、ログイン隣接の公開ページ、遅延読み込みのコンテンツ、そして表示されるレイアウトが重要なページです。
Browser API はそのギャップを埋めます。
4 つの Browser 操作
| 操作 | 使うべきとき |
|---|---|
| Browser Markdown | Agent がレンダリングされたページからきれいなテキストを必要とするとき |
| Browser HTML | Agent が完全にレンダリングされた DOM や技術的検査を必要とするとき |
| Browser Screenshot | Agent が視覚的な証拠やレイアウトの根拠を必要とするとき |
| Browser Links | Agent がクロールやナビゲーション分析のためにレンダリングされたリンクグラフを必要とするとき |
これはクロール製品ではありません。より大きなワークフローの中でページの根拠を必要とする Agents のための、単一ページのレンダリングされた読み取りプリミティブです。
なぜレンダリングされた読み取りが重要なのか
SEO Agent が料金ページを監査していると想像してください。プレーンな fetch は、バンドルされた JavaScript を含むシェルを返します。アシスタントは、そのページには料金表も、FAQ も、内部リンクもない、と結論づけるかもしれません。
レンダリングされた Browser Markdown は、実際のコンテンツを示せます。
| レンダリングなし | Browser API あり |
|---|---|
| 欠落したクライアントサイドのセクション | 見える見出し、表のテキスト、CTA のコピー |
| 不完全なリンクセット | レンダリングされた内部・外部リンク |
| 視覚的な証拠なし | レイアウトとファーストビューを確認するスクリーンショット |
| 弱い引用 | Agent が引用または要約できるページコンテンツ |
それが推奨の質を変えます。Agent は、どのセクションが欠けているか、どの競合ページがそれを持っているか、どのレンダリングされたリンクが欠けているかを言えます。
コピー可能な実行プロンプト
SEO Agent または Competitive Intelligence Agent で使ってください。
UnifAPI Browser Markdown と Links で、これら 3 つの競合ページを読んで: [URLs]。各ページについて、見えるポジショニング、見出し、根拠ポイント、CTAs、内部リンク、そして料金や FAQ のコンテンツを抽出して。それから、[URL] にある私たちのページと比較して。差分の表を返し、レンダリングされた根拠を引用し、変更を推奨して。プライベートな分析データを推測したり、ページが変更されたと主張したりしないで。
このプロンプトは Browser API を実際のビジネスタスクの中に保ちます。アシスタントに延々とブラウジングするよう求めているのではありません。レンダリングされた根拠と意思決定を求めているのです。
Browser と SEO
Browser のレコードは、SEO のレコードと組み合わせると特に役立ちます。
- SEO SERP を使って、あるクエリで勝っているページを見つける。
- Browser Markdown を使って、それらのページが実際に何と言っているかを検査する。
- Browser Links を使って、それらが読者をどう誘導しているかを見る。
- ファーストビュー、レイアウト、信頼要素が重要なときは Browser Screenshot を使う。
- 順位の根拠とページの根拠の両方に基づいた修正プランを返す。
その結果は、どちらか一方のレイヤーだけよりも鋭くなります。SERP のレコードは誰が勝つかを言います。Browser のレコードは、なぜそのページが勝つのかを説明する助けになります。
Browser と GEO
GEO レポートにもレンダリングされたページの根拠が必要です。AI の回答が競合を引用しているなら、Agent はその引用されたページを読み、主張を抽出し、ターゲットサイトのページと比較できます。
それは実務的な問いに答える助けになります。競合が引用されているのは、回答エンジンが彼らのブランドを好むからなのか、それとも彼らのページにより明確な定義・比較・統計・出典リストが含まれているからなのか?
Browser API は回答エンジンの内部的な推論を知ることはできません。引用されたページが実際に何を含んでいるかを示すことはできます。
スコープ外に保つべきもの
Browser API は、デフォルトで際限のないクローラーになるべきではありません。Skill が複数ページのクロールを必要とするなら、まず計画し、見積もり、スコープを尋ねるべきです。
公開データの境界も尊重すべきです。Browser API は公開ページを読みます。ユーザーのプライベートアカウントを操作したり、ペイウォールを回避したり、フォームを送信したり、サイトに変更を加えたりする手段ではありません。
Browser 実行からの良い出力
| フィールド | 含めるべきもの |
|---|---|
| URL | 読んだページ |
| レンダリングモード | Markdown、HTML、スクリーンショット、リンク |
| 抽出した主要な根拠 | 見出し、セクション、主張、CTAs、リンク |
| 確信度 | レンダリング後にページが完全に見えたかどうか |
| ギャップ | 欠落したセクション、弱い根拠、壊れたフロー |
| 次のステップ | 推奨、またはより絞ったフォローアップの読み取り |
アシスタントが一般的なページ要約だけを返すなら、レンダリングされた根拠の表を含めるよう求めてください。Browser の呼び出しは、出力が監査可能なままであるときに最も価値があります。
主要な参考資料
検索と AI のワークフローは依然としてアクセス可能なページコンテンツに依存しているため、レンダリングされた読み取りは重要です。プレーンな fetch で十分かどうかを判断するときは Google の JavaScript SEO の基礎 を、クロール可能なコンテンツの基本には Google の SEO スターターガイド を、レンダリングされた HTML にエンティティマークアップのレビューが必要なときは Google の 構造化データの紹介 を使ってください。
次に読むべきもの
SEO Agent によるライブ順位監査 - SEO ワークフローの一部としての Browser を示します。
Competitive Intelligence Agent と公開シグナル - ローンチとポジショニングの分析に Browser のレコードを使います。
Browser API カタログ - ライブの Browser 操作を一覧します。