# SEOエンジニアリングとは？AI・APIで改善ループを作る方法
**SEOエンジニアリングとは、検索データの取得、改善候補の選定、修正、検証、効果測定を、再現可能な仕組みとして設計することです。** AIに記事を量産させることではありません。
はじめに自動化するのは、**直すべきページを見つけ、1本ずつ改善し、結果を確かめること**です。難しいのは、どの記事を、なぜ直し、何をもって成功とするかを決めること。ここが曖昧なまま自動化すると、読まれない記事と確認作業ばかりが増えます。
この記事では、Search Console、Ahrefs、Herdrを使って、SEO改善を無理なく続ける仕組みを作ります。最初からすべてを自動化する必要はありません。まずは「改善候補を毎週3本出す」ところから始めましょう。
## SEOのループ設計とは？
**検索データを確認し、直すページを選び、修正し、公開後の変化を確かめる。ここまでを一つの仕事として繰り返せるようにすることです。**
流れは次の5段階です。
1. **見つける**：Search Consoleで、伸びそうなページを探す
2. **選ぶ**：事業への近さと改善余地を比べ、1本に絞る
3. **直す**：不足している説明、事例、図解、内部リンクを加える
4. **確かめる**：事実、文章、表示、リンク切れを確認する
5. **振り返る**：公開後の数字を見て、次に直す内容を決める
一度きりの指示を工夫するのがプロンプトの改善だとすれば、ループ設計は「毎週同じ品質で仕事を進めるための段取りづくり」です。SEOは公開後にもデータがたまるため、この方法とよく合います。
## SEOエンジニアリングとSEOエンジニアはどう違いますか？
**SEOエンジニアは主に技術的な改善を実装する職種、SEOエンジニアリングはSEO業務全体を繰り返せる仕組みにする考え方です。**
「SEOエンジニア」の一般的な説明では、クロール、レンダリング、構造化データ、速度、サイト構造などの実装を担います。この記事でいうSEOエンジニアリングは、その技術改善に加え、コンテンツ改善と計測までを一つのループとして扱います。
| 領域 | 主な目的 | 主な仕事 | 成果の確かめ方 |
| --- | --- | --- | --- |
| SEOマーケター | 検索から商談・売上を作る | キーワード、企画、記事、分析 | コンバージョン、クリック |
| SEOエンジニア | 検索エンジンが理解しやすい実装にする | クロール、レンダリング、構造化データ、速度 | インデックス、Core Web Vitals、エラー |
| テクニカルSEO | 技術的な妨げを取り除く | 監査、要件定義、実装確認 | クロール可否、速度、正規化 |
| SEOエンジニアリング | 改善を継続できる運用にする | データ取得、優先度付け、修正、検証、記録 | 変更前後の表示回数、順位、CTR、CV |
少人数チームでは、1人が複数の役割を兼ねても問題ありません。大切なのは、「誰の職種か」より、データ取得から効果測定までの担当と完了条件が決まっていることです。
## なぜ「記事作成」から自動化しないのですか？
**作る速さより、何を作らないかを決める方が大切だからです。**
検索需要がない。既存記事と内容が重なる。自社だから書ける経験がない。このようなテーマを速く書いても、成果にはつながりません。
Googleも、生成AIの利用そのものを問題にはしていません。一方で、読者への価値を加えずに大量のページを作る行為は、スパムポリシーに触れる可能性があると案内しています。
そこで、AIには候補集めや下調べを任せます。公開するかどうかは、読者への価値、事実、ブランドへの影響を人が見て決めます。
## どの道具を、何に使いますか？
道具は多いほどよいわけではありません。次の役割がそろえば始められます。
| 役割 | 道具の例 | ここで見るもの |
| --- | --- | --- |
| 自社の検索データ | Search Console API | 検索語、ページ、表示回数、クリック率、平均掲載順位 |
| 市場と競合の確認 | Ahrefs API v3 | 検索数、難易度、流入可能性、競合ページ |
| 複数の作業を管理 | Herdr | 担当ごとの進み具合、確認待ち、完了した作業 |
| 記事の修正 | Git、CMS | 本文、タイトル、図解、内部リンクの変更 |
| 公開前の確認 | ビルド、リンク検査、ブラウザ確認 | エラー、リンク切れ、パソコン・スマートフォンでの表示 |
| 結果の記録 | スプレッドシート、データベース | 仮説、変更日、変更内容、公開後の数字 |
Search Consoleの数字は、自社サイトで実際に起きたことです。Ahrefsの数字は、市場や競合を比べるための推定値です。同じものとして扱わないようにします。
## 改善するページはどう選びますか？
最初は、Search Consoleから次の条件に合うページを探します。
- 直近28日間で表示回数が100回以上ある
- 平均掲載順位が7位から15位にある
- 事業につながる検索語で表示されている
- すでに記事があり、内容を足せば検索意図に近づける
- 前の28日間と比べて、クリック率か順位が下がっている
この条件は絶対ではありません。サイトの規模が小さければ、表示回数は20回からでも構いません。大事なのは、毎回同じ基準で候補を並べることです。
候補が出たら、次の4項目を5点満点で採点します。
| 判断すること | 5点になる状態 |
| --- | --- |
| 事業への近さ | 問い合わせや購入の前に読まれるテーマ |
| 伸びしろ | 少しの改善で検索結果の上位を狙えそう |
| 独自性 | 自社の経験、数字、画像、具体例を加えられる |
| 手間 | 1週間以内に公開まで進められる |
合計点が高いものから、まず1本だけ選びます。同点なら、独自性の高い方を優先します。
## Search Console APIでは何を取得しますか？
**最初に必要なのは、ページ、検索語、クリック数、表示回数、クリック率、平均掲載順位です。**
直近28日と、その前の28日を取得して比べます。日々の小さな上下ではなく、ある程度まとまった期間で見るためです。
注意点もあります。Search Analytics APIは、すべての行が返ることを保証していません。クリック数の多い上位データが中心です。そのため、「APIに出てこない検索語には需要がない」とは判断できません。
また、取得した数字だけで記事を直さないようにします。実際の検索結果を開き、上位ページがどのような疑問に答えているかも確認してください。
### 最小の取得リクエスト
Search Analytics APIに次のJSONをPOSTすると、検索語×ページ単位のデータを取得できます。日付は実行時に差し替えます。
```json
{
"startDate": "2026-07-01",
"endDate": "2026-07-28",
"dimensions": ["query", "page"],
"type": "web",
"dataState": "final",
"rowLimit": 25000
}
```
返った `clicks`、`impressions`、`ctr`、`position` を保存し、同じ条件で取得した前期間と比べます。Google公式ドキュメントでは、1回の `rowLimit` は最大25,000行で、返却対象は主要行に限られ、全データを保証しないと明記されています。大きなサイトでは `startRow` で分割取得してください。
## 実際のSEO改善ループで数字はどう動きましたか？
**自社の採用系メディアでは、7週間で週間クリックが32から182、週間表示回数が5,554から72,795に増えました。** Search Consoleの実測値です。
| 時点 | 週間クリック | 週間表示回数 | 実行体制 |
| --- | ---: | ---: | --- |
| 2026年2月10日 | 32 | 5,554 | 運用開始時点 |
| 2026年3月29日 | 182 | 72,795 | 収集・下書きはAIとcron、計画と公開は人 |
ただし、これは1サイトの観察事例です。立ち上げ時期の自然なインデックス進行も含まれ、ループだけが成長の原因とは断定できません。加工していない推移、判定ルール、全自動化が空回りしたログは、[実データ付きのSEO改善ループ事例](/blog/seo-ai-loop-case-study/)で公開しています。
## Ahrefs APIはどこで使いますか？
**Search Consoleで見つけた候補に、本当に取り組む価値があるかを確かめるために使います。**
Ahrefs API v3のKeywords Explorerでは、検索数、キーワード難易度、流入可能性などを取得できます。たとえば、次のように使い分けます。
- **検索数**：その検索語がどれくらい調べられているか
- **難易度**：上位表示の難しさを比べる目安
- **流入可能性**：上位ページが関連する検索語全体から得ている推定流入
- **検索意図**：情報収集、比較、購入など、検索する目的
ここでも推定値をそのまま正解にはしません。自社のSearch Consoleで表示が発生しているなら、検索数が小さく見えても候補に残す価値があります。
Ahrefs APIは、取得する項目や行数に応じて利用枠を消費します。必要な項目だけを指定し、同じデータは一定期間保存して使い回すと無駄を減らせます。
## HerdrはSEOで何をしてくれますか？
**HerdrはSEOツールではなく、複数のAIエージェントやターミナル作業をまとめて見るための場所です。**
たとえば、次のように担当を分けます。
- **調査担当**：Search ConsoleとAhrefsから候補を3本出す
- **編集担当**：選ばれた1本の構成と本文を直す
- **確認担当**：出典、数字、日本語、リンク、表示を確認する
それぞれを別の画面で動かしても、Herdrなら「作業中」「確認待ち」「完了」を一覧で追えます。CLIやローカルのSocket APIから、画面の作成、指示、状態確認、完了待ちも行えます。
ただし、人数を増やせば品質が上がるわけではありません。編集担当と確認担当に同じ指示を渡すと、同じ思い込みを共有することがあります。確認担当には完成原稿だけでなく、出典と確認項目を別に渡してください。
## 1回分の仕事をどう決めますか？
自動化を始める前に、1回分の仕事を短い仕様書にします。次の内容があれば十分です。
### 目的
表示回数が多く、平均掲載順位が7位から15位の記事を1本改善する。
### 入力する情報
- 直近28日と、その前の28日のSearch Consoleデータ
- Ahrefsで確認した検索数、難易度、流入可能性
- 現在の記事
- 検索結果の上位5ページ
- 自社で追加できる経験、数字、画像
### 公開前に通す確認
- 見出しの直後に、質問への答えがある
- 出典と取得日が分かる
- 自社だから書ける具体例が一つ以上ある
- 内部リンクが切れていない
- ビルドに成功する
- パソコンとスマートフォンで読める
- 日本語を声に出して読んでも不自然ではない
### 途中で止める条件
- 独自の情報を追加できない
- 既存記事と検索意図が重なる
- 事実を確認できる出典がない
- 2回直しても公開前の確認を通らない
- APIの利用枠や確認時間が上限を超える
ここまで決めておけば、「もっとよくして」のような終わりのない指示を減らせます。
## 作る担当と確認する担当はどう分けますか？
**作る担当は記事を改善し、確認する担当は公開してよい証拠をそろえます。**
確認する担当には、次の順番で見てもらいます。
1. 数字と固有名詞は出典どおりか
2. 検索した人の疑問に答えているか
3. 自社の経験や具体例が入っているか
4. 日本語は自然か
5. リンクと表示に問題はないか
誤字やリンク切れのように、正解がはっきりしたものは自動で修正できます。一方で、検索意図、法務、ブランド表現は人が判断します。
## 公開後はいつ結果を見ますか？
**公開直後の順位を見て、すぐに書き直す必要はありません。まず評価する日を決めて待ちます。**
目安として、公開または更新から28日後に、変更前の28日間と比べます。
- クリック数は増えたか
- 表示回数は増えたか
- クリック率は上がったか
- 狙った検索語の平均掲載順位は動いたか
- 問い合わせや資料請求につながったか
数字が下がっても、すぐ元に戻すとは限りません。季節性、検索結果の変化、Googleの更新なども確認します。そして、一度に複数の場所を直しすぎないこと。何が効いたのか分からなくなるからです。
## 最初の4週間はどう進めますか？
いきなり大きな仕組みを作らず、次の順番で試します。
### 1週目：候補を出す
Search Consoleから改善候補を3本出します。まだ記事は自動で直しません。
### 2週目：1本だけ直す
人が1本を選び、AIに構成案を作らせます。編集と公開は人が行います。
### 3週目：確認を分ける
記事を作る担当とは別に、事実、日本語、表示を確認する担当を置きます。
### 4週目：記録を残す
「なぜ選んだか」「何を変えたか」「いつ結果を見るか」を1行ずつ残します。ここまで安定してから、HerdrやAPIで繰り返せる範囲を広げます。
最初の目標は、記事を10本作ることではありません。**改善候補を選び、1本を安全に公開し、あとから結果を比べられること**です。
## よくある疑問
### AIに記事の全文を書かせてはいけませんか？
下書きに使うこと自体は問題ありません。ただし、出典、経験、判断までAI任せにすると、どの会社でも書ける内容になります。構成の整理や言い換えには使い、自社の経験と最終判断は人が加えてください。
### Ahrefs APIがなくても始められますか？
始められます。最初はSearch Consoleと実際の検索結果だけでも十分です。候補が増え、競合や市場を同じ条件で比べたくなった段階でAhrefsを加えます。
### 毎日改善した方が早く成果が出ますか？
同じ記事を毎日直すのはおすすめしません。検索結果に反映される前に次の変更を重ねると、何が効いたのか分からなくなります。変更日と評価日を決め、その間は別の記事に取り組みます。
### どこまで自動化すればよいですか？
失敗してもすぐ戻せる作業からです。データ取得、候補の並べ替え、リンク検査は自動化しやすい領域です。公開、法務、ブランド表現は人の確認を残します。
### SEOエンジニアがいなくても始められますか？
始められます。最初はSearch ConsoleからCSVを取得し、スプレッドシートで候補を並べるだけでも十分です。対象選定と公開判断が安定してから、API取得、定期実行、ビルド検証を少しずつ加えます。技術的なクロールや表示速度の課題は、[SEO内部対策のチェックリスト](/blog/seo-naibu-taisaku/)に切り分けて確認してください。
## まずは「候補を3本出す」から始めよう
最初に作るのは、大がかりな自動執筆システムではありません。Search Consoleから改善候補を3本出し、その理由を添える小さな仕組みです。
その3本から人が1本を選び、直し、確認し、28日後に結果を見る。この一巡ができれば、次に自動化すべき場所が自然に見えてきます。
全体の道具選びは[マーケターのAI技術スタック](/blog/marketer-ai-tech-stack/)、SEO施策の優先順位は[ひとりマーケターのSEO完全ガイド](/blog/hitori-marketer-seo/)、実際の数字と失敗ログは[実データ付きの7週間レポート](/blog/seo-ai-loop-case-study/)で確認できます。
### 参照した一次資料
- [Herdr公式ドキュメント](https://herdr.dev/docs/)
- [Herdrのエージェント管理](https://herdr.dev/docs/agents/)
- [Herdrの自動操作](https://herdr.dev/docs/agent-automation/)
- [Herdr Socket API](https://herdr.dev/docs/socket-api/)
- [Search Console Search Analytics API](https://developers.google.com/webmaster-tools/v1/searchanalytics/query)
- [Googleのクローラー概要](https://developers.google.com/crawling/docs/crawlers-fetchers/overview-google-crawlers)
- [Ahrefs API v3公式ドキュメント](https://docs.ahrefs.com/en/api/docs/introduction)
- [Ahrefs Keywords Explorer API](https://docs.ahrefs.com/en/api/reference/keywords-explorer/get-overview)
- [Googleの生成AIコンテンツに関する指針](https://developers.google.com/search/docs/fundamentals/using-gen-ai-content)
SEOエンジニアリングとは、検索データの取得、改善候補の選定、修正、検証、効果測定を、再現可能な仕組みとして設計することです。 AIに記事を量産させることではありません。
はじめに自動化するのは、直すべきページを見つけ、1本ずつ改善し、結果を確かめることです。難しいのは、どの記事を、なぜ直し、何をもって成功とするかを決めること。ここが曖昧なまま自動化すると、読まれない記事と確認作業ばかりが増えます。
この記事では、Search Console、Ahrefs、Herdrを使って、SEO改善を無理なく続ける仕組みを作ります。最初からすべてを自動化する必要はありません。まずは「改善候補を毎週3本出す」ところから始めましょう。
SEOの検証ループ生成ではなく、観測から再検証までを1つの仕事にする。1観測GSC・順位・CV
→2選定価値×勝ち目
→3制作一次情報を追加
→4検証build・表示・事実
→5学習結果を記録
公開前のチェックに通らなければ修正します。公開後は28日間の変化を確認し、次に直す内容を決めます。
SEOのループ設計とは？
検索データを確認し、直すページを選び、修正し、公開後の変化を確かめる。ここまでを一つの仕事として繰り返せるようにすることです。
流れは次の5段階です。
- 見つける：Search Consoleで、伸びそうなページを探す
- 選ぶ：事業への近さと改善余地を比べ、1本に絞る
- 直す：不足している説明、事例、図解、内部リンクを加える
- 確かめる：事実、文章、表示、リンク切れを確認する
- 振り返る：公開後の数字を見て、次に直す内容を決める
一度きりの指示を工夫するのがプロンプトの改善だとすれば、ループ設計は「毎週同じ品質で仕事を進めるための段取りづくり」です。SEOは公開後にもデータがたまるため、この方法とよく合います。
SEOエンジニアリングとSEOエンジニアはどう違いますか？
SEOエンジニアは主に技術的な改善を実装する職種、SEOエンジニアリングはSEO業務全体を繰り返せる仕組みにする考え方です。
「SEOエンジニア」の一般的な説明では、クロール、レンダリング、構造化データ、速度、サイト構造などの実装を担います。この記事でいうSEOエンジニアリングは、その技術改善に加え、コンテンツ改善と計測までを一つのループとして扱います。
| 領域 | 主な目的 | 主な仕事 | 成果の確かめ方 |
|---|
| SEOマーケター | 検索から商談・売上を作る | キーワード、企画、記事、分析 | コンバージョン、クリック |
| SEOエンジニア | 検索エンジンが理解しやすい実装にする | クロール、レンダリング、構造化データ、速度 | インデックス、Core Web Vitals、エラー |
| テクニカルSEO | 技術的な妨げを取り除く | 監査、要件定義、実装確認 | クロール可否、速度、正規化 |
| SEOエンジニアリング | 改善を継続できる運用にする | データ取得、優先度付け、修正、検証、記録 | 変更前後の表示回数、順位、CTR、CV |
少人数チームでは、1人が複数の役割を兼ねても問題ありません。大切なのは、「誰の職種か」より、データ取得から効果測定までの担当と完了条件が決まっていることです。
なぜ「記事作成」から自動化しないのですか？
作る速さより、何を作らないかを決める方が大切だからです。
検索需要がない。既存記事と内容が重なる。自社だから書ける経験がない。このようなテーマを速く書いても、成果にはつながりません。
Googleも、生成AIの利用そのものを問題にはしていません。一方で、読者への価値を加えずに大量のページを作る行為は、スパムポリシーに触れる可能性があると案内しています。
そこで、AIには候補集めや下調べを任せます。公開するかどうかは、読者への価値、事実、ブランドへの影響を人が見て決めます。
どの道具を、何に使いますか？
道具は多いほどよいわけではありません。次の役割がそろえば始められます。
| 役割 | 道具の例 | ここで見るもの |
|---|
| 自社の検索データ | Search Console API | 検索語、ページ、表示回数、クリック率、平均掲載順位 |
| 市場と競合の確認 | Ahrefs API v3 | 検索数、難易度、流入可能性、競合ページ |
| 複数の作業を管理 | Herdr | 担当ごとの進み具合、確認待ち、完了した作業 |
| 記事の修正 | Git、CMS | 本文、タイトル、図解、内部リンクの変更 |
| 公開前の確認 | ビルド、リンク検査、ブラウザ確認 | エラー、リンク切れ、パソコン・スマートフォンでの表示 |
| 結果の記録 | スプレッドシート、データベース | 仮説、変更日、変更内容、公開後の数字 |
Search Consoleの数字は、自社サイトで実際に起きたことです。Ahrefsの数字は、市場や競合を比べるための推定値です。同じものとして扱わないようにします。
改善するページはどう選びますか？
最初は、Search Consoleから次の条件に合うページを探します。
- 直近28日間で表示回数が100回以上ある
- 平均掲載順位が7位から15位にある
- 事業につながる検索語で表示されている
- すでに記事があり、内容を足せば検索意図に近づける
- 前の28日間と比べて、クリック率か順位が下がっている
この条件は絶対ではありません。サイトの規模が小さければ、表示回数は20回からでも構いません。大事なのは、毎回同じ基準で候補を並べることです。
候補が出たら、次の4項目を5点満点で採点します。
| 判断すること | 5点になる状態 |
|---|
| 事業への近さ | 問い合わせや購入の前に読まれるテーマ |
| 伸びしろ | 少しの改善で検索結果の上位を狙えそう |
| 独自性 | 自社の経験、数字、画像、具体例を加えられる |
| 手間 | 1週間以内に公開まで進められる |
合計点が高いものから、まず1本だけ選びます。同点なら、独自性の高い方を優先します。
Search Console APIでは何を取得しますか？
最初に必要なのは、ページ、検索語、クリック数、表示回数、クリック率、平均掲載順位です。
直近28日と、その前の28日を取得して比べます。日々の小さな上下ではなく、ある程度まとまった期間で見るためです。
注意点もあります。Search Analytics APIは、すべての行が返ることを保証していません。クリック数の多い上位データが中心です。そのため、「APIに出てこない検索語には需要がない」とは判断できません。
また、取得した数字だけで記事を直さないようにします。実際の検索結果を開き、上位ページがどのような疑問に答えているかも確認してください。
最小の取得リクエスト
Search Analytics APIに次のJSONをPOSTすると、検索語×ページ単位のデータを取得できます。日付は実行時に差し替えます。
{
"startDate": "2026-07-01",
"endDate": "2026-07-28",
"dimensions": ["query", "page"],
"type": "web",
"dataState": "final",
"rowLimit": 25000
}
返った clicks、impressions、ctr、position を保存し、同じ条件で取得した前期間と比べます。Google公式ドキュメントでは、1回の rowLimit は最大25,000行で、返却対象は主要行に限られ、全データを保証しないと明記されています。大きなサイトでは startRow で分割取得してください。
実際のSEO改善ループで数字はどう動きましたか？
自社の採用系メディアでは、7週間で週間クリックが32から182、週間表示回数が5,554から72,795に増えました。 Search Consoleの実測値です。
| 時点 | 週間クリック | 週間表示回数 | 実行体制 |
|---|
| 2026年2月10日 | 32 | 5,554 | 運用開始時点 |
| 2026年3月29日 | 182 | 72,795 | 収集・下書きはAIとcron、計画と公開は人 |
ただし、これは1サイトの観察事例です。立ち上げ時期の自然なインデックス進行も含まれ、ループだけが成長の原因とは断定できません。加工していない推移、判定ルール、全自動化が空回りしたログは、実データ付きのSEO改善ループ事例で公開しています。
Ahrefs APIはどこで使いますか？
Search Consoleで見つけた候補に、本当に取り組む価値があるかを確かめるために使います。
Ahrefs API v3のKeywords Explorerでは、検索数、キーワード難易度、流入可能性などを取得できます。たとえば、次のように使い分けます。
- 検索数：その検索語がどれくらい調べられているか
- 難易度：上位表示の難しさを比べる目安
- 流入可能性：上位ページが関連する検索語全体から得ている推定流入
- 検索意図：情報収集、比較、購入など、検索する目的
ここでも推定値をそのまま正解にはしません。自社のSearch Consoleで表示が発生しているなら、検索数が小さく見えても候補に残す価値があります。
Ahrefs APIは、取得する項目や行数に応じて利用枠を消費します。必要な項目だけを指定し、同じデータは一定期間保存して使い回すと無駄を減らせます。
HerdrはSEOで何をしてくれますか？
HerdrはSEOツールではなく、複数のAIエージェントやターミナル作業をまとめて見るための場所です。
たとえば、次のように担当を分けます。
- 調査担当：Search ConsoleとAhrefsから候補を3本出す
- 編集担当：選ばれた1本の構成と本文を直す
- 確認担当：出典、数字、日本語、リンク、表示を確認する
それぞれを別の画面で動かしても、Herdrなら「作業中」「確認待ち」「完了」を一覧で追えます。CLIやローカルのSocket APIから、画面の作成、指示、状態確認、完了待ちも行えます。
ただし、人数を増やせば品質が上がるわけではありません。編集担当と確認担当に同じ指示を渡すと、同じ思い込みを共有することがあります。確認担当には完成原稿だけでなく、出典と確認項目を別に渡してください。
1回分の仕事をどう決めますか？
自動化を始める前に、1回分の仕事を短い仕様書にします。次の内容があれば十分です。
目的
表示回数が多く、平均掲載順位が7位から15位の記事を1本改善する。
入力する情報
- 直近28日と、その前の28日のSearch Consoleデータ
- Ahrefsで確認した検索数、難易度、流入可能性
- 現在の記事
- 検索結果の上位5ページ
- 自社で追加できる経験、数字、画像
公開前に通す確認
- 見出しの直後に、質問への答えがある
- 出典と取得日が分かる
- 自社だから書ける具体例が一つ以上ある
- 内部リンクが切れていない
- ビルドに成功する
- パソコンとスマートフォンで読める
- 日本語を声に出して読んでも不自然ではない
途中で止める条件
- 独自の情報を追加できない
- 既存記事と検索意図が重なる
- 事実を確認できる出典がない
- 2回直しても公開前の確認を通らない
- APIの利用枠や確認時間が上限を超える
ここまで決めておけば、「もっとよくして」のような終わりのない指示を減らせます。
作る担当と確認する担当はどう分けますか？
作る担当は記事を改善し、確認する担当は公開してよい証拠をそろえます。
確認する担当には、次の順番で見てもらいます。
- 数字と固有名詞は出典どおりか
- 検索した人の疑問に答えているか
- 自社の経験や具体例が入っているか
- 日本語は自然か
- リンクと表示に問題はないか
誤字やリンク切れのように、正解がはっきりしたものは自動で修正できます。一方で、検索意図、法務、ブランド表現は人が判断します。
公開後はいつ結果を見ますか？
公開直後の順位を見て、すぐに書き直す必要はありません。まず評価する日を決めて待ちます。
目安として、公開または更新から28日後に、変更前の28日間と比べます。
- クリック数は増えたか
- 表示回数は増えたか
- クリック率は上がったか
- 狙った検索語の平均掲載順位は動いたか
- 問い合わせや資料請求につながったか
数字が下がっても、すぐ元に戻すとは限りません。季節性、検索結果の変化、Googleの更新なども確認します。そして、一度に複数の場所を直しすぎないこと。何が効いたのか分からなくなるからです。
最初の4週間はどう進めますか？
いきなり大きな仕組みを作らず、次の順番で試します。
1週目：候補を出す
Search Consoleから改善候補を3本出します。まだ記事は自動で直しません。
2週目：1本だけ直す
人が1本を選び、AIに構成案を作らせます。編集と公開は人が行います。
3週目：確認を分ける
記事を作る担当とは別に、事実、日本語、表示を確認する担当を置きます。
4週目：記録を残す
「なぜ選んだか」「何を変えたか」「いつ結果を見るか」を1行ずつ残します。ここまで安定してから、HerdrやAPIで繰り返せる範囲を広げます。
最初の目標は、記事を10本作ることではありません。改善候補を選び、1本を安全に公開し、あとから結果を比べられることです。
よくある疑問
AIに記事の全文を書かせてはいけませんか？
下書きに使うこと自体は問題ありません。ただし、出典、経験、判断までAI任せにすると、どの会社でも書ける内容になります。構成の整理や言い換えには使い、自社の経験と最終判断は人が加えてください。
Ahrefs APIがなくても始められますか？
始められます。最初はSearch Consoleと実際の検索結果だけでも十分です。候補が増え、競合や市場を同じ条件で比べたくなった段階でAhrefsを加えます。
毎日改善した方が早く成果が出ますか？
同じ記事を毎日直すのはおすすめしません。検索結果に反映される前に次の変更を重ねると、何が効いたのか分からなくなります。変更日と評価日を決め、その間は別の記事に取り組みます。
どこまで自動化すればよいですか？
失敗してもすぐ戻せる作業からです。データ取得、候補の並べ替え、リンク検査は自動化しやすい領域です。公開、法務、ブランド表現は人の確認を残します。
SEOエンジニアがいなくても始められますか？
始められます。最初はSearch ConsoleからCSVを取得し、スプレッドシートで候補を並べるだけでも十分です。対象選定と公開判断が安定してから、API取得、定期実行、ビルド検証を少しずつ加えます。技術的なクロールや表示速度の課題は、SEO内部対策のチェックリストに切り分けて確認してください。
まずは「候補を3本出す」から始めよう
最初に作るのは、大がかりな自動執筆システムではありません。Search Consoleから改善候補を3本出し、その理由を添える小さな仕組みです。
その3本から人が1本を選び、直し、確認し、28日後に結果を見る。この一巡ができれば、次に自動化すべき場所が自然に見えてきます。
全体の道具選びはマーケターのAI技術スタック、SEO施策の優先順位はひとりマーケターのSEO完全ガイド、実際の数字と失敗ログは実データ付きの7週間レポートで確認できます。
参照した一次資料
