はじめに
前回の記事では、Google Search Console APIから検索クエリ、表示ページ、クリック数、表示回数、CTR、平均掲載順位などを取得する仕組みについて書いた。
Search Consoleのデータを取得できると、ブログがどの検索語句で表示されているかが分かる。
しかし、ここで一つ問題がある。
検索語句が分かっただけでは、次に何をすればよいかまでは決まらないのである。
たとえば、Search Consoleに次のような検索語句が出ていたとする。
teams 添付ファイル 開けない
outlook 文字化け utf-8
sharepoint 404 復旧
windows.old 削除していい
これらは記事テーマになりそうである。
しかし、それぞれを新規記事にすべきか、既存記事に追記すべきか、既存記事をリライトすべきかは別問題である。
そこで筆者は、Search Consoleの検索語句をWordPress既存記事と照合し、次のように分類する仕組みを作った。
新規記事候補
既存記事のリライト候補
既存記事への追記候補
低優先度候補
本記事では、この「検索語句を次の行動に変換する仕組み」について紹介する。
Search Consoleのクエリは、そのままでは行動にしにくい
Search Consoleには、ブログ運営に役立つ情報が多く含まれている。
特に重要なのは以下である。
- 検索クエリ
- 表示回数
- クリック数
- CTR
- 平均掲載順位
- 表示されたページ
ただし、Search Consoleの画面を見ただけでは、次の行動を決めにくい。
たとえば、ある検索語句の表示回数が多かったとしても、その検索語句に対して次のどれを行うべきかは判断が必要である。
新しい記事を書く
既存記事に見出しを追加する
既存記事のタイトルを変える
メタディスクリプションを見直す
今は何もしない
この判断を毎回手動で行うのは手間である。
そこで、Search Consoleのクエリを既存記事と照合し、ある程度自動で分類することにした。
まずWordPress既存記事を取得する
検索語句を分類するには、既存記事の情報が必要である。
そこで筆者は、WordPress REST APIから既存記事一覧を取得する処理を作った。
取得する主な情報は以下である。
- 記事ID
- タイトル
- URL
- スラッグ
- 公開日
- 更新日
- 抜粋
- 本文の一部
- カテゴリ
- タグ
これらをCSVに保存し、検索用のインデックスを作る。
具体的には、記事タイトル、抜粋、本文の一部を結合し、検索クエリとの関連度を見られるようにした。
記事タイトル
+
抜粋
+
本文の一部
↓
既存記事インデックス
これにより、Search Consoleの検索語句に近い既存記事があるかどうかを判定できる。
query単位とquery×page単位を使い分ける
前回の記事でも触れたように、Search Console APIでは query 単位と query × page 単位のデータを取得するようにした。
この2つは役割が違う。
query単位
query単位では、検索語句そのものの状況を見る。
どんな検索語句で表示されているか
表示回数はどのくらいか
CTRは低くないか
平均掲載順位はどのくらいか
これは、記事テーマ候補を探す入口として使う。
query×page単位
query×page単位では、その検索語句でどの記事が表示されているかを見る。
この検索語句で、どの記事が表示されているか
既存記事がすでに反応しているか
関係の薄い記事が表示されていないか
複数の記事が同じ検索語句で表示されていないか
これは、新規記事にするか、既存記事を改善するかを判断する材料になる。
queryだけでは「何が検索されているか」しか分からない。
query×pageを見ることで、「どの記事をどう直すか」に近づけられる。
分類は4種類にした
今回の仕組みでは、検索語句を大きく4種類に分類した。
create_new_article
rewrite_existing
add_section_to_existing
ignore_low_priority
それぞれの意味は以下である。
| action | 意味 |
|---|---|
| create_new_article | 新規記事候補 |
| rewrite_existing | 既存記事のリライト候補 |
| add_section_to_existing | 既存記事への追記候補 |
| ignore_low_priority | 優先度が低い候補 |
この分類があると、Search Consoleのデータが単なる一覧ではなく、次の作業指示に近くなる。
新規記事候補にする条件
新規記事候補にするのは、既存記事で十分に扱えていない検索語句である。
たとえば、次のような条件に当てはまる場合である。
表示回数がある
平均掲載順位が8〜50位くらい
既存記事との類似度が低い
該当テーマを扱う記事がまだない
ブログの読者に合っている
例として、次の検索語句があったとする。
sharepoint 404 復旧
既存記事にSharePoint関連の記事がほとんどなければ、新規記事候補になる。
この場合、記事タイトルは以下のように考えられる。
SharePointサイトが404になる原因と復旧時に確認するポイント
新規記事候補は、ブログの領域を広げるために重要である。
ただし、表示回数だけで判断すると危険である。
サイトの方向性に合っているか、筆者が内容を確認できるかも見る必要がある。
リライト候補にする条件
リライト候補にするのは、既存記事が検索結果に表示されているが、改善余地がありそうな場合である。
たとえば、次のような条件である。
query×pageで既存記事が表示されている
表示回数がある
平均掲載順位が4〜20位くらい
CTRが低い
既存記事と検索語句の関連度が高い
この場合、新規記事を作るよりも、既存記事を改善した方がよい可能性がある。
たとえば、既存記事が「Outlookの文字化け対策」について書いており、Search Consoleに次の検索語句が出ていたとする。
outlook 文字化け utf-8
この場合、既存記事にUTF-8の見出しがないなら、リライト候補になる。
改善内容としては、以下が考えられる。
- タイトルに検索語句を自然に含める
- 見出しを追加する
- 確認手順を具体化する
- よくある原因を整理する
- メタディスクリプションを見直す
リライト候補は、すでに検索結果に表示されている記事を伸ばすための候補である。
追記候補にする条件
追記候補は、既存記事と関連はあるが、検索語句に対する説明が不足している場合である。
リライトほど大きく直す必要はないが、見出しや本文を追加するとよさそうなケースである。
たとえば、Teamsのトラブル記事がすでにあり、Search Consoleに次の検索語句が出ていたとする。
teams 添付ファイル 開けない
既存記事がTeams全般のトラブルを扱っているものの、添付ファイルの確認手順が薄い場合は、追記候補にできる。
追記する見出し案は、たとえば以下である。
Teamsで添付ファイルが開けない時に確認すること
追記候補は、既存記事を育てるために使いやすい。
新規記事を増やし続けるだけでは、サイト全体が散らかることがある。
既存記事に適切な追記を行うことで、記事の網羅性を高められる。
低優先度にする条件
すべての検索語句を記事化する必要はない。
中には、表示回数が少ないもの、ブログのテーマと関係が薄いもの、今すぐ扱う必要がないものもある。
低優先度にする条件は、たとえば以下である。
表示回数が少ない
平均掲載順位がかなり低い
自サイトのテーマと関係が薄い
既存記事とも関連が薄い
読者像に合っていない
こうしたクエリまで記事化すると、ブログの軸がぶれやすい。
特に、外部テーマ収集も組み合わせるようになると、候補は一気に増える。
そのため、書かない判断も必要である。
ブログ運営では、記事を増やすことだけでなく、書かないテーマを決めることも重要である。
優先度スコアを付ける
分類だけでなく、優先度スコアも付けるようにした。
候補が増えると、どれから着手すべきか分からなくなるからである。
スコアの考え方は、以下のようなものにした。
表示回数が多いか
平均掲載順位に改善余地があるか
CTRが低く改善余地があるか
既存記事との差分があるか
社内SEブログとの相性が高いか
記事化しやすいか
単純に表示回数が多いものを優先するわけではない。
たとえば、表示回数が多くても、ブログの読者と合わないテーマなら優先度は下げる。
逆に、表示回数がそこそこでも、社内SE向けの記事として実用性が高ければ優先度を上げる。
このように、SEOだけでなく、サイトとの相性も見てスコアを付けるようにした。
出力はCSVとMarkdownレポートにした
分析結果は、CSVとMarkdownレポートに出力するようにした。
主な出力は以下である。
outputs/topic_opportunities.csv
outputs/new_article_candidates.csv
outputs/rewrite_candidates.csv
outputs/add_section_candidates.csv
outputs/weekly_topic_opportunity_report.md
CSVは後続処理に使う。
Markdownレポートは人間が確認するために使う。
レポートには、以下のような内容を入れる。
- 新規記事候補トップ10
- リライト候補トップ10
- 追記候補トップ10
- カテゴリ別候補数
- 優先的に取り組むべき記事案
- 注意事項
このようにしておくと、毎週の確認作業が楽になる。
ただCSVを出すだけでは、人間が見るには少し分かりづらい。
Markdownレポートに要約することで、編集会議の資料のように使える。
Codexには何を作らせたか
この機能もCodexに段階的に作らせた。
最初から「Search Consoleデータを分析して良い記事テーマを出して」と頼んだわけではない。
Codexには、処理を分解して依頼した。
WordPress既存記事を取得する
既存記事インデックスを作る
Search Consoleクエリを読み込む
既存記事との類似度を判定する
新規記事・リライト・追記候補に分類する
優先度スコアを付ける
CSVとMarkdownレポートを出力する
このように分けたことで、どこで何をしているか確認しやすくなった。
AIに記事テーマを考えさせるだけなら一瞬である。
しかし、それでは再現性が弱い。
一方で、データ取得、照合、分類、出力を分けて作れば、毎回同じ手順で候補を出せる。
Codexを使う場合も、抽象的なお願いより、処理単位に分けて依頼した方が安定しやすい。
実装して感じたこと
この仕組みを作って感じたのは、Search Consoleのデータは「答え」ではなくあくまで「材料」だということである。
Search Consoleに出ているクエリをそのまま記事化すればよいわけではない。
たとえば、表示回数が多くても、記事にしにくいテーマもある。
逆に、表示回数が少なくても、社内SE向けの記事として価値があるテーマもある。
また、既存記事がある場合は、新規記事を作るよりも追記やリライトの方がよいこともある。
つまり、Search Consoleのクエリを見て大事なのは、次の判断である。
これは新規記事にするべきか
既存記事を直すべきか
見出しを追記するだけでよいか
今は保留すべきか
今回の仕組みは、この判断を支援するためのものである。
自動判定は過信しない
ただし、自動判定を過信してはいけない。
類似度判定やスコアリングは便利だが、完璧ではない。
たとえば、検索語句の意味が短すぎる場合、既存記事との関連度をうまく判定できないことがある。
また、同じ単語を含んでいても、読者の意図が違う場合もある。
そのため、最終判断は人間が行う。
今回の仕組みでも、分析結果は承認キューに出し、人間が approved に yes を入れたものだけを次工程に進めるようにしている。
候補を出す
↓
人間が確認する
↓
承認したものだけ記事化する
この流れにすることで、自動化しつつも、ブログの方向性を守りやすくなる。
次の工程につながる
この分類処理ができると、次の工程に進める。
具体的には、承認済みテーマから記事構成案を作る工程である。
Search Consoleデータ取得
↓
既存記事との照合
↓
新規記事・リライト・追記候補に分類
↓
人間が承認
↓
記事構成案を生成
次回以降は、この承認済みテーマから記事構成案を作る仕組みについて紹介したい。
AIで本文を書く前に、まず検索意図、想定読者、見出し構成、内部リンク候補などを整理する。
この工程を挟むことで、AI生成記事の品質を上げやすくなる。
まとめ
Search Consoleの検索語句は、ブログ記事テーマを考えるうえで非常に役に立つ。
しかし、検索語句を取得しただけでは、次に何をすればよいかは決まらない。
そこで筆者は、Search ConsoleのクエリをWordPress既存記事と照合し、新規記事候補、リライト候補、追記候補、低優先度候補に分類する仕組みを作った。
この仕組みにより、Search Consoleのデータを「見るだけ」ではなく、「次の作業」に変換できる。
特に重要なのは、query単位だけでなく、query×page単位のデータを見ることである。
どの検索語句でどの記事が表示されているかを見ることで、新規記事にするべきか、既存記事を直すべきか判断しやすくなる。
AIにブログテーマを考えさせるだけでは、実際の検索需要や既存記事との関係が見えにくい。
Search Consoleと既存記事データを組み合わせることで、より実用的な記事候補を作れる。
ただし、自動判定はあくまで補助である。
最終的には人間が確認し、承認したテーマだけを記事化する。
このバランスが、ブログ運営の自動化では重要である。
コメント