検索から来た人の入口を作る
英語学習アプリ Words Admin では、検索から来た人の入口として、英語が出てこないときの解説ページを書きました。今回の記録は、2026年10月12日から13日にかけて、その題材と見出しをどう選び、公開までに何を確かめたかをまとめたものです。
題材を決めるために使ったのは、実際に取得した Google の検索候補です。「英語 出てこない」や「英語 とっさに」などを入力し、どんな語が続くのかを確認しました。取得日は2026年10月13日、条件は hl=ja&gl=jp です。
確かめたかったのは、似た言葉で検索していても、求めている内容が違わないかという点でした。英語を話そうとして言葉が出てこない人に向けた説明と、日本語の英訳を探す人に向けた説明では、扱う内容が変わります。そこで、候補の数だけでなく、候補に現れた言葉を読んで記事の範囲を決めました。
検索順位や流入数は測っていません。今回示せるのは、取得した候補と、それをもとに行った編集上の判断です。
似た検索語でも、求める内容は違った
取得結果の一部を、そのまま示します。
| 入力した語 | 候補の数 | 読めたこと |
|---|---|---|
| 英語 言葉が出てこない | 6件 | 「スピーキング」「上手く話せない」「頭が回らない」 |
| 英語 とっさに出てこない | 2件 | 語を長くすると候補が減る |
| 英語 とっさに話せない | 1件 | 入力そのもの |
| 英語 とっさに出てこない 原因 | 0件 | |
| 英語 知ってるのに出てこない | 0件 |
「英語 出てこない」では、候補が10件ありました。候補内の2位は「なぜ」、3位は「練習」、4位は「時」。その後には「独り言」「スピーキング」「単語」「会話」が続き、場面によって分かれていました。9〜10位は文字の変換や訳語探しに関するもので、同じ入口にも別の用事が混ざっていました。ここでの順位は、取得した検索候補内の順番です。
違いがより明確だったのは、「英語 とっさに」です。10件のうち7件は末尾が「英語」で、「咄嗟に」という言葉の英訳を探す内容でした。英語が出てこなくて困っている側に当たる候補は、「とっさに出てこない」「とっさに話せない」の2件でした。
一方、「英会話 とっさ」では、10件のうち7件が「とっさのひとこと」系でした。辞典、アプリ、ハンドブック、フレーズ、放送局の講座など、言い方の一覧を求める内容です。
この違いから、「とっさに」という語を使うだけでは、記事が何に答えるのかが定まらないと判断しました。見出しには、英訳を探す話ではなく、英語が出てこない場面を扱うことが分かる言葉を置く必要があります。なお、候補10件中7件という内訳は、検索した人の割合を測った数字ではありません。
見出しを分け、作らない記事も決める
実測後は、候補に現れた語を使って記事の役割を分けました。1本目は独り言の練習、2本目は英語が出てこないときの切り分けです。題材の出どころとなった候補が別だったため、同じ内容の言い換えにならないようにしました。
2本目の節は、「単語」「会話」「スピーキング」「独り言」の4つに分けました。いずれも検索候補にあった語です。見出しを増やすために解釈を足すのではなく、実際に出てきた言葉を区分として使いました。
候補に現れなかった案もあります。「英語 言えなかった 表現 メモ」は、実測で候補に出なかったため、今回の題材には採用しませんでした。
また、「英語 出てこない 単語」「英語 出てこない 会話」という語の組は、候補が1件以下でした。加えて、既に書いたページの表と内容が重なっていました。このため、別の記事を作っても言い換えになると判断し、作成を見送りました。代わりに、候補が10件あった「英語 ネットスラング」を3本目の題材にしました。
候補が少ないことだけで決めたのではありません。既存ページで既に扱っているかを併せて確認し、新しく記事を分ける理由があるかを判断しました。
求められていても、未検証の原因は書かない
「英語 出てこない」の候補では、「なぜ」が2位にありました。原因を知りたいという方向は候補から読み取れます。しかし、英語が出てこない原因を自分たちで検証したわけではありません。そのため、「なぜ出てこないのか」の答えは書かないと決めました。
検索候補を取得すると、どんな説明が求められているかを考える手がかりになります。ただし、それだけで説明の正しさを確かめたことにはなりません。今回は、候補にある問いを見つける作業と、その問いに答える根拠を持っているかの確認を分けました。
同じ理由で、実数のない利用者数や利用者の評価、検証していない学習効果も掲載しませんでした。「〇秒で」という表現についても、計測と収録の回で食い違いがあったため、使わない判断をしました。こうした未検証の内容を扱わないことは、ページにも明記しました。
公開の確認では、次の更新で消える箇所も直した
ページごとの公開作業では、canonical、OGP、構造化データを確認しました。構造化データは Article と BreadcrumbList を使い、どちらも JSON として読めることを確かめました。
sitemap への追加では、件数が804から805になりました。IndexNow の通知では HTTP 200 を確認しています。また、公開前には390pxと1200pxの画面幅で表示を確認し、横スクロールがないことと、例外が0であることを確かめました。
この作業で見つかったのが、sitemap を作るスクリプトの問題でした。スクリプトは sitemap 全体を上書きする作りで、手で追加した解説ページは、次に作り直した時点で消える状態になっていました。
そこで、解説ページをスクリプト側に登録しました。公開時点で sitemap に載っているかに加え、再生成したときにも掲載されるよう、生成元を修正した形です。記事を公開する作業には、表示の確認だけでなく、更新を繰り返したときに登録が残るかという確認も含まれました。
業務に置き換えると
オウンドメディアや解説記事を作る業務では、今回の記録を次の点検に置き換えられます。
- 題材を決める前に検索候補を実際に取得し、取得日と条件を残しているか。
- 同じ検索語に、訳語探しや困りごとの解決など、異なる目的が混ざっていないか。見出しで扱う範囲が分かるか。
- 候補にない語を題材にしていないか。既存の記事や表と重なり、言い換えになっていないか。
- 効果や原因について、検証した内容と未検証の内容を分け、書かない範囲をページに明記しているか。
- 公開時の表示と登録に加え、sitemap を再生成した後にも記事が残るよう、生成元に登録しているか。
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。