BotifyにSEOの修正を任せる？｜本番に自動で当てる前に

「タイトルを直したいのに、開発の順番待ちで3か月動かない」「AIに説明文を作らせて、そのまま本番に流し込めば一気に片づくのでは」——ページ数の多いサイトを持つマーケ部門で、担当者からも上長からも聞こえてくる声です。SEOの修正が遅いのは開発待ちのせいだから、AIに作らせて本番に直接当てれば速くなる、と考えるのは自然です。けれども、本当はそうではありません。速く当てられるようになるほど、差し戻す手段と、誰が承認したかの記録が要るのです。この記事では、開発を通さずに修正を当てる仕組みを持つ Botify を例に、入れるかどうかと、入れるならマーケが持つべき承認・差し戻し・記録の線を整理します。

Botifyは何をする製品か

Botify は、ページ数の多いサイトを対象にしたSEOの基盤です。2026年10月時点の公式サイトでは、自らを「AI検索の最適化の基盤」と説明し、製品を3つの領域に分けて並べています。1つ目はAIに見つけてもらうための備えで、AIのエージェントや検索のボットへの対応を担う SpeedWorkers などが入ります。2つ目は見え方の分析で、サイトの巡回、検索語、サーバーの記録の分析、優先して手を付けるべき作業の一覧などです。

3つ目が、この記事の主題にかかわる実行の領域です。公式サイトでは「自動化と反映」として PageWorkers、「AIが作るコンテンツ」としてスマートコンテンツ、内部リンクの機能、検索への登録を広げる機能などが並んでいます。分析して終わりではなく、見つけた課題の修正を作り、試し、公開中のページに当てるところまでを1つの基盤で扱うのが Botify の考え方です。

つまり Botify を検討するということは、分析の道具を1つ増やすことではありません。サイトの表示を書き換える権限の一部を、開発の手順の外に、マーケやSEOの担当の手元へ移すかどうかを決めることになります。この記事で扱うのは、この権限の移し方です。

作っている会社と、国内でまだ知られていない理由

Botify は2012年に創業した会社で、公式サイトの法的な表示では、パリに本店を置くフランスの会社が運営者になっています。のちに米国にも拠点を開き、公式サイトに掲げられた顧客の例は、海外の大手の小売・ECやファッション、宿泊の事業者が中心です。数万から数百万のページを持ち、商品の追加や入れ替えでページが毎日増減するようなサイトを主な相手にしている、と読むのが自然です。

日本語で Botify を紹介した記事は、2026年10月時点でほとんど見当たりません。確かめられる範囲で理由を挙げると、まず公式サイトとサポートの記事がすべて英語です。料金の金額も公式サイトには載っておらず、多くの場合は商談から始まる形です。次に、対象の規模です。数百ページ規模のサイトなら、開発の順番待ちはそれほど長くならず、ページを1枚ずつ直すほうが早い場面も多いため、開発を飛ばして当てる仕組みそのものが要らないことがほとんどです。

一方で、AIで修正案を作る機能は日本語にも対応しています。公式のサポート記事では、スマートコンテンツの出力はページの言語に合わせて作られ、対応する言語の一覧に日本語が含まれています。大規模なECやメディアを持つ国内の会社が検討の対象になる余地はあり、その時に何を決めておくべきかを先に押さえておく価値はあります。

PageWorkersはどうやって本番を書き換えるのか

PageWorkers の仕組みは、公式のサポートにある技術概要で説明されています。サイトの各ページに、非同期で読み込まれる小さなスクリプトを1つ置きます。このスクリプトが Botify から設定を受け取り、ページの要素を作る・変える・消す、といった書き換えを行います。元のページのコード自体は変えず、その上に修正を重ねる形です。

書き換えは、検索のボットにだけ見せるか、ボットと利用者の両方に見せるかを設定で選べると説明されています。ほかのスクリプトが同じ要素を上書きした場合は、決められた回数まで修正を当て直す仕組みも書かれています。設定は版の履歴が残る保管場所に置かれ、スクリプトは実行の成否と誤りを記録として送ります。

止まったときの動きも示されています。配信網に障害が起きればスクリプトが読み込まれず、元のページがそのまま表示されます。Botify の側の仕組みが応答しなければ、スクリプトは読み込まれても修正は実行されません。どちらの場合もページは表示され続けるが、当てていた修正は消えて元に戻るということです。この性質は、後で述べる止め方と棚卸しの考え方にそのまま効いてきます。

「開発待ちが原因だから直接当てれば速い」の落とし穴

開発を通さずに修正を当てられると、確かに速くなります。ただ、開発に頼んでいた頃の流れには、意図しない副作用がありました。依頼書を書く、開発が内容を読む、試験環境で確かめる、公開の日を決める。この1つ1つが、変えてよいかを誰かが確かめ、いつ何を変えたかが記録に残る工程を兼ねていたのです。

PageWorkers のような仕組みを入れると、この工程がまとめて外れます。担当者が管理画面で修正を作り、公開の状態にすれば、すぐに公開中のページに反映されます。そこにAIが作った修正案が何千件も流れ込むと、速さと引き換えに、誰も中身を見ないまま本番に出た修正が生まれやすくなります。速く当てられることと、安全に当てられることは別の話です。

だからこの道具の導入は、外れた確認の工程を、マーケの側に置き直す作業とセットで考える必要があります。以下の節では、任せる要素の決め方、確認の関所、小さく当てて比べる工程、元に戻す手順、開発との取り決め、棚卸しの順に、置き直す中身を見ていきます。

検索エンジンはスクリプトの書き換えをどう扱うか

スクリプトでページを書き換えたとき、検索エンジンがそれをどう読むかは、Google の公式文書で確かめられる範囲だけを押さえておきます。Google の「JavaScript SEO の基本」では、タイトルと説明文はスクリプトで設定・変更してよいと明記されています。一方で、正規のURLを示す指定は、元のHTMLにある値と違う値にスクリプトで変えてはいけないとされています。

検索に載せない指定についても注意書きがあります。スクリプトで追加・変更はできますが、元のHTMLに載せない指定があると、Google は描画やスクリプトの実行を飛ばすことがあり、スクリプトでその指定を外しても期待どおりに動かない場合があるとされています。また、ページの描画は待ち行列に入り、数秒で済むこともあれば、それより長くかかることもあると書かれています。さらに同じ文書は、すべてのボットがスクリプトを実行できるわけではない、とも述べています。

もう1つ確かめておきたいのが、ボットにだけ修正を見せる設定です。Google のスパムに関するポリシーは、順位を操作して利用者を欺く意図で、利用者と検索エンジンに違う内容を見せることをクローキングと呼んでいます。ボットにだけ見せる設定を使うなら、利用者に見える内容と食い違わない範囲に限るという社内の線を、導入の前に決めておくべきです。

AIに任せる要素と任せない要素を決める

最初に決めるのは、どの要素の修正をこの仕組みで当ててよいかです。何でも書き換えられるからといって、何でも任せてよいわけではありません。前の節の Google の公式文書の内容と、戻せるかどうか、間違えたときの影響の大きさで分けると、次のようになります。

要素	この仕組みで当ててよいか	理由
タイトル	承認を通せば可	スクリプトでの変更は公式に認められている。戻すのも容易
説明文	承認を通せば可	同上。検索結果で書き換えられることもあり、影響は限られる
見出しや本文の一部	対象を絞れば可	利用者にも見える。商品の情報と食い違うと問い合わせにつながる
内部リンクの追加	試験から始める	サイト全体の回遊が変わる。効果と副作用の両方を見る必要がある
正規URLの指定	当てない	元のHTMLと違う値にスクリプトで変えないよう公式文書が求めている
検索に載せない指定	当てない	スクリプトで外しても期待どおりに動かないことがあると公式文書にある

表の上の2行は、AIに修正案を大量に作らせる対象として向いています。下の2行は、間違えたときにページが検索から消えたり、評価が別のURLに移ったりするおそれがあるため、この仕組みでは当てず、元のHTMLを開発が直すと決めておくのが安全です。内部リンクの設計そのものは別の記事に譲り、ここでは当てる仕組みの線引きにとどめます。

この表は社内の取り決めとして文書にし、管理画面の操作権限を持つ全員が見られる場所に置きます。後から要素を追加するときは、表を更新してから当てる、という順番にしておくと、担当者が交代しても線が崩れません。

AIの修正案はどう作られるか

Botify でタイトルと説明文の修正案を作るのは、スマートコンテンツという機能です。公式のサポート記事によると、Botify が持つサイトのデータと生成AIを使って、最適化したタイトルと説明文を大量に作ります。提供元が用意した基本の指示に、自社の事業や読者、反応のよい言葉などの情報を足して使う形です。

同じ記事には、同じ指示を繰り返しても結果は少しずつ変わるとも書かれています。つまり、一度うまくいった指示で作り直しても、前回と同じ文が出てくるとは限りません。データの扱いについては、データは自社の案件の中にとどまり、大規模言語モデルの学習には使わないと説明されています（2026年10月時点）。

作った修正案は、元のタイトル・説明文と新しい案を並べたCSVとして取り出せます。これを PageWorkers に取り込んで当てるか、CSVをもとに手作業で反映するかを選べます。公式の説明では、5千URL分の案を作るのに10分ほどかかるとされており、作るのにかかる時間は短い一方で、人が1件ずつ読む時間はその何十倍にもなることを前提に、確認の量を設計する必要があります。

確認の関所をどこに置くか

公式のサポート記事を読む限り、スマートコンテンツと PageWorkers には、作った人とは別の人が承認しないと公開できない、という形の正式な承認の工程は書かれていません。説明されているのは、対象の範囲を確かめること、CSVを編集できること、修正が下書きの状態で作られることです。管理画面に承認の機能があるかどうかは、契約の前に提供元に確かめる項目です。

承認の機能がない、または足りない場合でも、関所は置けます。おすすめは、CSVの段階で人が読み、承認した版だけを取り込むという形です。全件を読めない量なら、ページの種類ごとに抜き取って読み、1件でも基準に外れたらその種類はまとめて差し戻す、と決めておきます。

差し戻す基準は、次のような案です。どれもAIが作った文に起こりやすく、検索の数字より先にブランドや問い合わせに響くものです。

• 商品の価格・在庫・送料など、ページの本文や商品の情報と食い違う内容を含む
• 「最安」「日本一」など、根拠を示せない比べる表現や言い切りを含む
• 同じ型の文が大量に並び、ページごとの違いが読み取れない
• 自社のブランドの表記（社名・商品名の書き方）が揺れている
• 対象の範囲に、当てるつもりのなかったページが混ざっている

誰の資格で本番に出せるか

関所を人の手順だけで支えるのは心もとないので、管理画面の権限の分け方も確かめておきます。Botify の公式サポートの権限の説明（2026年10月時点）では、権限は利用者1人ずつではなく、チームごとに割り当てた役割で決まります。役割は最上位の管理者・管理者・編集者・閲覧者の4つで、チームの権限を変えられるのは組織の所有者です。1人の利用者が複数のチームに入ることもできます。

同じ説明の表では、修正（最適化）を作れるのは編集者以上ですが、設定や修正を本番に出す操作ができるのは最上位の管理者だけとされています。PageWorkers の操作の説明でも、修正はまず下書きとして保存し、本番に出すボタンを押して初めて動き出す、という順番です。つまり、作る人と本番に出す人を、役割で分けておけるということです。

これを使えば、承認の機能が別にない場合でも関所を形にできます。AIの修正案を取り込んで下書きを作るのはマーケの担当者が入るチーム（編集者）、本番に出す操作はマーケの上長かSEOの責任者が入るチーム（最上位の管理者）、と分けておけば、担当者1人の判断で本番が書き換わることはなくなります。ただし権限はチーム単位なので、同じ人を両方のチームに入れると分けた意味が薄れます。誰をどのチームに入れたかも、承認の記録と同じ場所に残しておきます。

なお、公式の権限の説明には、誰がいつ本番に出したかを追える操作の記録については書かれていません。その機能の有無は契約の前に提供元に確かめ、無ければ次の節で述べる社内の記録で補います。

承認の記録に何を残すか

修正の設定には版の履歴が残ると公式は説明していますが、それは何をどう変えたかの記録です。誰がなぜ承認したかまでは、社内で残す必要があります。数か月後に順位や問い合わせが変わったとき、どの修正が効いたのか、どの修正が悪さをしたのかを追えなければ、速く当てられる道具はかえって原因の分からない変化を生みます。

残す項目は多くなくて構いません。修正の名前、対象のページの範囲、AIに渡した指示の版、取り込んだCSVの版、承認した人と日付、当て始めた日、見直す予定の日、の7つがあれば十分です。大事なのは、管理画面の中の修正の名前と、社内の記録の行が1対1で突き合わせられることです。名前の付け方を最初に決めておくと、後の棚卸しが楽になります。

記録の置き場所は、マーケの部内で閉じず、開発とサイト管理の担当も読める場所にします。障害の調査で開発がページを見たとき、元のコードにない文言が出ている理由をすぐに確かめられるようにするためです。

小さく当てて比べる

PageWorkers には、修正を当てるページと当てないページに分けて比べる、分割の試験の仕組みがあります。公式のサポートでは、対象のページを修正を当てる群と比べる群に分け、既定では半々に分けると説明されています。同じページに2つの版を出すA/Bテストとは違い、1つのページには常に1つの版だけが出る形です。

比べる報告では、クリックの上位5%のページを比較から外すとされています。ただし公式の別の記事は、報告が示すのは「対象の範囲に入っているか」であって、「実際に書き換わったか」ではないと注意しています。試験の期間の目安も公式には書かれていないため、何週間で判定するかは自分たちで決める必要があります。

この仕組みで決めておきたいのは、効果の測り方の細部より、全体に広げる前に必ず一部で試すという順番です。タイトルの変更の効果を測る工程そのものは別の記事に譲りますが、AIが作った案を最初から全ページに当てることだけは避けます。試す範囲、判定の日、広げるか戻すかを決める人を、試験を始める前に記録に書いておきます。

元に戻す手順を先に書く

公式の技術概要によると、PageWorkers の修正はいつでも外す・止める・変えることができ、外せばページは元の状態に戻ります。管理画面では、修正を公開中・一時停止・下書きといった状態で絞り込んで見られます。戻す操作そのものは簡単です。難しいのは、誰が、どの条件で、どの順番で戻すかが決まっていないことです。

戻す・直すの操作には、1つ注意があります。公式の編集の説明によると、公開中の修正を編集しても、本番に出す操作をし直すまでは反映されず、一覧に保留中の印が付きます。一時停止した修正を再開しても、保留中の変更は含まれないとされています。つまり、直したつもりの修正が、前の版のまま動いていることがあるのです。直した後や再開した後は、保留中の印が残っていないかを確かめる手順も加えておきます。一時停止をどの役割が行えるかは公式の権限の表に書かれていないため、止める担当を決めるときに提供元に確かめておきます。

戻し方が文書になっていれば、上長も「速く当てる」ことに安心して承認を出せます。逆に、戻し方が決まっていない状態で当て始めると、問題が起きた日に誰も止められないことになります。

開発・サイト管理部門との取り決め

開発を通さずに当てる仕組みでも、開発やサイト管理の部門と無関係にはなりません。まずスクリプトを各ページに置くのは開発の仕事です。公式の説明では、スクリプトの読み込みはページの表示を妨げない非同期の形で、表示の速さへの影響は小さいとされていますが、どのページの型に置くかは開発と決める必要があります。

次に、ほかの仕組みとの重なりです。公式は、A/Bテストの道具と併用しても、同じ要素を両方で触らなければ問題はないとしています。逆に言えば、同じ要素を2つの仕組みが書き換えると、どちらの修正が出ているのか分からなくなります。サイトのテンプレートを開発が改修したときに、PageWorkers の修正が当たらなくなる、あるいは想定外の場所に当たる、ということも起こりえます。

取り決めておきたいのは、PageWorkers で触る要素の一覧を開発と共有すること、テンプレートの改修の前に一覧を見てもらうこと、障害の連絡の窓口を1つにすること、の3つです。開発から見れば、元のコードにない修正が本番に乗っている状態は、知らなければ障害の原因調査を難しくします。共有すること自体が、開発の協力を得るための条件だと考えてください。

当てたまま忘れられた修正を数える

この仕組みの見落としやすい点は、修正が元のコードに入らず、スクリプトの上に重なり続けることです。当てた修正が増えるほど、本当のページの姿は元のコードを見ても分からなくなります。そして前に見たとおり、Botify の側が止まれば修正は消えて元に戻ります。契約をやめたときも同じです。

だから、定期的に棚卸しをして、効果が確かめられた修正は元のコードに移し、スクリプトから外す流れを作っておきます。スクリプトは試す場所、元のコードは定着させる場所、と役割を分けるイメージです。

• 公開中の修正の数と、社内の記録の行の数が一致しているか
• 当て始めてから決めた期間を過ぎ、判定されないまま残っている修正はないか
• 効果が確かめられたのに、元のコードに移されていない修正はないか
• 同じページの同じ要素に、複数の修正が重なっていないか
• テンプレートの改修の後、当たらなくなった修正や想定外の場所に当たった修正はないか

棚卸しの間隔は、四半期に1回を目安にし、当てる修正が多い時期は月に1回に縮めます。数を数えるだけでも、当てっぱなしの修正が積み上がっていないかが見えるようになります。

費用の増え方と、やめるときの影響

費用は金額ではなく増え方で押さえます。公式のサポートでは、スマートコンテンツで反映できる数に契約ごとの年間の上限があり、残りの数が管理画面に表示されると説明されています。つまり、AIで作って当てる修正を増やすほど、上位の契約に上げる判断が早く来ます。どのページの種類にどれだけ使うかを、年の初めに見積もっておくと、途中で上限に当たって止まる事態を避けられます。

やめるときの影響は、ほかのSEOの道具と大きく違います。分析の道具なら、やめても見られなくなるのは画面だけです。PageWorkers の場合は、契約を終えるとスクリプト経由で当てていた修正がすべて元に戻ると考えておく必要があります。前の節の棚卸しで元のコードに移しておかなかった修正は、やめた日に消えます。

このため、導入の稟議には、やめるときに元のコードへ移す作業の量の見積もりも入れておくと、上長の判断がしやすくなります。数年使ったあとで乗り換える場合も、移す作業がどれだけ残っているかは棚卸しの記録を見れば分かる状態にしておきます。

よくある質問

AIが作ったタイトルを、確認なしで全ページに当ててもよいですか

おすすめしません。公式の説明でも、同じ指示で作り直すと結果が変わるとされています。全ページに当てる前に、ページの種類ごとに一部で試し、人が読んで承認した案だけを広げる形にしてください。

ページ数が少ないサイトでも導入する意味はありますか

数百ページ程度で、開発に頼めば数日で直せるなら、開発を通さずに当てる仕組みの利点は小さくなります。むしろ確認の関所と棚卸しの手間が増えるだけになりかねません。開発の順番待ちが実際にどれだけ長いかを先に測ってから判断してください。

スクリプトで書き換えた内容は、Google に必ず読まれますか

Google の公式文書は、タイトルと説明文の変更は可能としつつ、描画には時間がかかる場合があり、すべてのボットがスクリプトを実行できるわけではないとしています。読まれるまでの時間や、ほかの検索エンジンやAIのボットの扱いは保証されないものとして計画してください。

承認は誰が持つべきですか

修正の中身の承認はマーケの上長、当てる仕組みと要素の範囲の承認は開発またはサイト管理の責任者、と分けるのが現実的です。1人に両方を持たせると、速さを優先したときに確認が抜けやすくなります。

まとめ

Botify の PageWorkers は、ページに置いたスクリプトを通じて、開発を待たずにタイトルや説明文などの修正を公開中のページへ当てる仕組みです。AIで修正案を大量に作る機能と組み合わせると、確かに修正は速くなります。ただし、開発の手順が担っていた確認と記録の役目も同時に外れます。修正案の生成はAIに任せ、どのページにいつ当てるか、当てた修正を戻すかは人が承認する。当てない要素を決め、一部で試し、戻し方を書き、定期に棚卸しをして元のコードへ移す。この線を引いてから、速さを手に入れてください。

• 製品の機能・データの扱い・仕組みは、Botify の公式サイトと公式サポートを2026年10月15日に確かめた範囲に基づきます。機能や条件は更新されることがあるため、利用前に最新の原文と契約の条件を確かめてください
• 検索エンジンの扱いは Google の公式文書の記述に基づきます。順位や表示への効果を保証するものではありません

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。