説明文： 個人ブログが月3万PVから10万PVを狙うとき、何が足りない？ 自動公開、サイトマップ、検索登録、バズ頼みの流入、広告の実効RPMを分解し、30日で検証できる改善順を整理する。
記事をぽんぽん作って、自動公開までつながった。「あとはGoogleさん、よろしくお願いします！」。ところがアクセス画面を開くと、伸びた日だけ派手で、普段はおとなしい。収益も、たまに数千円が見えても、毎月その金額で固定されるわけではない。
答えは、記事の製造能力と、記事を毎月読んでもらう能力が別物だから。 工場は動いている。でも商品が倉庫で迷子になったり、店の入口がたまに閉まったり、客が来た日にだけ店主が勝利宣言したりする。月10万PVへの道は、もっと記事を積む前に、この一連の動線を分解するところから始まる。
1. 月3万PVは多い？ 「3万人」とは別物
月3万PVなら30日換算で1日約1,000PV。個人の読み物サイトとして十分に意味がある水準だ。ただし「3万PV」はページが表示された回数であって、3万人の人間が来た証拠ではない。1人が3ページ読めば3PV。広告管理画面の表示回数も、Webサーバーへの通信回数も、PVとは別だ。
さらに「月3万」は同じ計測条件の直近30日で確認して初めて現在値になる。1週間の大ヒットを30日へ引き伸ばした数字なら、それは勢いの指標であって、安定した月商でも月間読者でもない。自分の確認操作や機械アクセス、アプリ画面まで混ぜると、なぜ伸びたかも見えなくなる。
月10万PVには1日平均約3,333PV。月3万を確かな基準と仮定した場合、必要なのは約3.33倍、つまり月間であと7万PVだ。
2. 公開ボタンの先に、七つの関門がある
記事ができたら、次の順番で進む。原稿完成 → 本番公開 → 正しいURLから表示できる → 検索エンジンが発見・取得する → インデックスに採用される → 検索結果に出る・クリックされる → 読者がページを開く。
これは同じ「公開済み」に見えて、まったく違う状態だ。ソースを保存しただけで本番の本文が古いなら第二関門。サイトマップにはあるのに404なら第三関門。取得されたが検索に採用されないなら第五関門。検索結果に出るのにクリックされないなら、タイトルと検索した人の疑問の問題かもしれない。
ここを区別しない改善は、店に客が来ない原因を全部「料理の味」で片づけるようなものだ。玄関の鍵が閉まっているのに新メニューを百品追加しても、店内は静かなままである。
3. サイトマップは出席簿。全員を合格にする装置ではない
大量自動公開なら、通常ページ用と新着記事用などにサイトマップを分け、索引で束ねる設計は合理的だ。robots.txt から案内し、検索に出したい記事だけを載せる。各URLについて本番でHTTP 200、検索除外指示なし、正しい代表URL指定、必要な言語間リンクを確認する。
ただしGoogleの公式説明では、サイトマップ送信は発見のヒントで、取得も登録も保証しない。最終更新日も、デプロイした時刻ではなくページに重要な変更があった日を使う。自動公開の仕組みがあることと、いま配信されるXMLに最新記事が載っていることも別々に確かめる。
サイトマップに名前が書いてあるだけで、Googleの入学式に全員参加できるわけではない。 出席簿の次は、教室のドアが開くかどうかだ。
4. 一番損なのは「たまに404になる優秀な記事工場」
無料枠や動的処理へ強く依存したサイトでは、アクセスや巡回が集中すると記事の配信が失敗することがある。通常は読めるのに、枠を使い切った時間だけ古い配信元へ切り替わり、記事が404になる――という構成なら厄介だ。サイト運営者が寝ている間に、読者にも検索ロボットにも閉店札を見せる。
対処の優先順は、既存記事を安定して配信できること、正常な記事URLとサイトマップの整合性、失敗時の記録、そして再試行。本文は可能なら静的配信で守り、動的処理を必要な仕事へ絞る。新記事1本を公開するたび、全記事を重い処理で作り直すような設計も見直す余地がある。
ただし404件数を見ただけで原因を決めつけない。意図した削除、旧URL、実際の配信障害を分け、同じURLの応答と時刻で検証する。
5. バズ記事は花火。毎月のアクセスは街灯
ある記事だけが突然当たると、アクセス画面はお祭りになる。素晴らしい。ただし収益も流入もその記事1本に依存しているなら、翌月に花火が終わった時点で暗くなる。
そこで月間PVを「上位1本」「上位5本」「それ以外」に分け、7日・28日・90日で比較する。過去に検索された問い、クリックされた言葉、継続して閲覧された記事を特定し、類似記事を増やす前にその記事の説明・見出し・内部リンク・更新状況を改善する。検索需要の無い記事でも面白さの価値はあるが、継続流入の主力とは別評価にする。
不足する7万PVを、仮に毎月1,000PVを生む記事70本、または500PVを生む記事140本で補うという計算はできる。これは記事を書くノルマでも達成予測でもない。どの種類の記事が実際に継続して読まれるかを検証するための配分モデルだ。自動制作を止めず、当たり方を学んで次に戻す。
6. 12言語なら入口は12個。コピーしただけで12倍にはならない
多言語記事が公開されれば、確かに世界へ入口は増える。しかし翻訳の数と、現地の検索者が抱える疑問の数は一致しない。検索の言い方、作品名、困りごとの切り口、競合は言語・地域によって違う。
各言語でタイトル・説明文・冒頭が同じ読者の問いに答え、本文もその言語だけで読めることが重要。言語版の関係を示す仕組みが正常でも、読者の探している答えが無ければ伸びにくい。逆に言語別の表示・クリックがほとんどない場合も、未登録、需要、品質、配信失敗を分けなければ原因は見えない。
7. 月3,000円は10万PVで実効RPM30円。問題は「毎月」だ
収益の計算は意外と地味。サイト全体の実効RPMを 収益 ÷ 対象PV × 1,000 と置くと、月10万PVで3,000円に必要なのは30円。月3万PVのままなら100円、月5万PVなら60円だ。いずれも「仮にそのPVが正しく計測され、同じ期間の収益と対応する」場合の算数で、広告市場の平均単価ではない。
一度2,000円に届いた月があっても、それが少数記事のヒットなら翌月の再現性は分からない。広告の表示数、広告対象になったページ、推定収益と確定収益、紹介リンクのクリックと承認済み成果を分ける。異なる日付・サイト・通貨・集計方式の数字を強引に割らない。
収益画面はアクセス画面の表彰状ではなく、レジの締め作業。 目標は月3,000円の単発達成より、3か月続けて3,000円以上を出せる構造だ。
8. 30日で見る順番は「配信 → 発見 → 定着 → 収益」
最初の週は、本番URLのHTTP 200、代表URL、検索除外設定、サイトマップ掲載、公開後の本文一致を点検する。2週目はSearch Consoleで発見・取得・登録・表示・クリックを切り分ける。3週目は上位1本を除いたPVと、30日後にも検索される記事の数を追う。4週目は、同じ期間の有効PVと実収益から実効RPMを出し、改善した記事群と未改善群を比べる。
技術故障は早く直す。検索で育つまでの時間は、短期バズと混同せずに見る。改善の効果が実測できない部分は「仮説」のまま残す。Googleは読み手に役立つ独自の情報や分析を重視している。大量生成だけの勝負にせず、会話や観察から生まれた「なんでそうなるんだよ」という切り口を、検索してきた人への回答へつなげよう。
工場ができたのは大きな進歩。でも、工場長が毎日「今日も100記事できました！」と喜ぶ一方、入口に404の貼り紙があったら悲しい。
次の仕事は増産ではなく、開店確認。月10万PVは、製造ラインの速度ではなく、毎日ちゃんとお客さんが入れる店で目指す。
参考資料： Google サイトマップ／サイトマップの作成・送信／役立つコンテンツ／AdSense ページRPM／Cloudflare Web Analyticsの指標
