【PR】この記事には広告リンクが含まれています。
ブログ記事を公開した直後にアクセスがないと、タイトルや本文をすぐ直したくなります。しかし、Search Consoleのクリック、表示回数、CTR、平均掲載順位、WordPress側のPV、広告管理画面のクリックは、同じ出来事を数えているわけではありません。指標の定義と期間を混ぜると、記事が読まれていないのか、検索結果に出ていないのか、広告が押されていないのかを判断できなくなります。
運営者は、WordPress側のPVと広告・計測画面のクリックが一致しない事例を確認し、指標の定義、計測タイミング、自己クリックを切り分ける必要を感じました。また、自動公開は全記事のURL、公開状態、時刻、サムネイルを個別確認し、1本でも未公開なら完了と報告しない運用へ変更しています。この考え方を公開後評価にも適用し、30日・60日・90日で見るものを分けます。
結論：日数ごとに結論を変え、指標ごとの役割を固定する
30日は計測と検索表示の有無を確認する期間、60日はクエリとCTRから改善仮説を作る期間、90日は記事の役割とリライト優先度を判断する期間として使います。これはGoogleが定めた順位確定日ではなく、本サイトの運用上の評価周期です。記事のテーマやサイトの状態で検索反映の速度は異なります。
- GSCはGoogle検索結果での表示とクリックを確認する
- WordPressのPVはサイト内でページが表示された状況を確認する
- 広告クリックは広告リンクの操作を確認する
- 各指標の期間、ページ、集計単位を揃えて比較する
- 公開直後の少数データで成果を断定しない
- 変更前の数値と本文を保存してからリライトする
まず理解する4つのSearch Console指標
クリック数
Google公式では、クリック数はユーザーがGoogle検索結果からサイトをクリックした回数です。WordPress内の関連記事クリックや、ブックマークからの訪問、SNSからの訪問を含むPVとは範囲が違います。
検索結果から一度記事へ入り、同じページを再読み込みした場合、サイト側の表示回数が増えてもGSCのクリックが同じように増えるとは限りません。数が違うこと自体を計測不良と決めつけません。
表示回数
表示回数は、サイトがGoogle検索結果に表示された回数です。記事ページがブラウザで開かれた回数ではありません。表示回数がありクリックが少ないなら、検索結果には出ているが選ばれていない可能性を検討できます。
ただし、クエリ、国、デバイス、検索での見え方などで集計が変わります。グラフの合計と表の合計が一致しない場合があることもGoogle公式が案内しています。
CTR
CTRはクリック数を表示回数で割った値です。表示回数が少ない記事では、一回のクリックで率が大きく動きます。CTRだけを見てタイトルが良い、悪いと判断せず、表示回数とクエリを一緒に確認します。
平均CTRが低くても、対象外に近い広いクエリで表示が増えた結果かもしれません。ページ単位のCTRと、主要クエリ単位のCTRを分けて確認します。
平均掲載順位
平均掲載順位は、検索結果におけるサイトの最上位の平均位置です。固定された順位表ではなく、検索時刻、場所、端末、検索履歴、クエリなどで結果が変わる前提があります。単日の上下だけで本文を書き換えません。
ページ全体の平均順位が変わったときは、表示されたクエリの構成が変わっていないかを見ます。新しい周辺クエリで表示が増えると、平均値が下がって見える場合もあります。
WordPressのPVと広告クリックは別の問いに答える
WordPress側のPVは、使用している解析機能やプラグインによって定義が異なります。検索流入だけでなく、内部リンク、直接訪問、管理者の確認などを含む可能性があります。設定や除外条件を確認せず、GSCクリックと一対一で照合しません。
広告管理画面のクリックは、広告コードやASP側の計測条件に基づく数です。記事が一回表示されても広告が押されなければ増えません。広告を押した後の戻る操作、自己クリック、計測タイミング、無効トラフィックの扱いもサイトPVと異なります。
運営者が確認したのは、WordPress側のPVと広告・計測画面のクリック等が一致しない事例です。どちらかが必ず誤りという結論ではなく、数えている行動が違うことを前提に調べる必要があると判断しました。
評価前に公開状態を確認する
アクセス評価の前に、その記事が本当に公開され、読者が見られる状態かを確認します。運営者の現行ルールでは、WordPressのstatus、slug、公開URL、本文、featured_mediaを再取得し、公開URLの表示も確認します。
公開処理の実行ログが成功でも、記事が未公開なら評価対象にできません。公開日もスプレッドシートの予定日ではなく、WordPressの公開状態とURLを基準にします。
30日評価：計測できているかを見る
30日時点では、成果の良し悪しより、計測と検索表示の入口を確認します。URLがSearch Consoleの対象プロパティ内にあり、ページ別データを抽出できるか、表示回数が発生しているか、想定した主要キーワードに近いクエリが出ているかを見ます。
- 公開URLがHTTP 200で表示される
- canonicalやnoindexの意図しない設定がない
- GSCでページフィルタを設定できる
- クリック、表示、CTR、平均順位の期間が同じ
- WordPress PVの管理者除外条件を確認した
- 広告リンクの飛び先とrel属性、計測要素を再確認した
表示が0でも、すぐに本文を全面変更するとは限りません。インデックス状況、サイトマップ、内部リンク、公開日、対象クエリの需要を切り分けます。逆に表示が出ているなら、初期のクエリを保存し、60日評価の比較基準にします。
30日で変えてよいもの
リンク切れ、誤字、古い公式URL、PR表記不足、広告属性不足、画像欠け、個人情報、事実誤認など、重大な不備は期間を待たずに直します。公開後評価を理由に誤りを放置しません。
30日で急いで変えないもの
少数の表示だけを根拠にタイトルを何度も変更したり、主要キーワードを別テーマへ入れ替えたりすると、比較基準が失われます。改善仮説と変更日を記録できない変更は保留します。
60日評価：クエリと検索意図のずれを見る
60日時点では、ページがどのクエリで表示され、どのクエリでクリックされたかを確認します。主要キーワードと同じ語だけでなく、読者が実際に使った疑問の形を見ます。タイトルにない具体語で表示されているなら、本文中の実体験や見出しが役立っている可能性があります。
表示があるのにクリックが少ない場合は、タイトルと説明文が検索意図を十分に表しているかを点検します。ただし、平均順位が低い状態では、CTRだけを改善対象にしません。掲載位置の違いを含めて判断します。
60日で作る改善仮説
- 主要クエリは記事の結論と一致しているか
- 想定外のクエリに答えられる一次情報や実体験があるか
- タイトルが大げさでなく内容を正確に要約しているか
- 導入で読者が得られる答えを示しているか
- 公開済み関連記事から自然にリンクできるか
- 公式情報の更新日や名称が変わっていないか
仮説は一度に一つか二つへ絞ります。タイトル、導入、見出し、CTAを同時にすべて変えると、どの変更が読者行動へ影響したか分かりません。
90日評価：維持・部分改善・リライトを決める
90日時点では、記事を維持するか、タイトルや導入を部分改善するか、本文をリライトするかを判断します。これは削除期限ではありません。検索表示が少ないテーマでも、内部リンクの受け皿、既存顧客への説明、問い合わせ対応など別の役割がある場合があります。
リライト候補にする場合は、公開中の同じ記事を更新します。新しい記事IDやslugを作ると、重複記事になり、履歴や内部リンクが分散します。更新前のタイトル、抜粋、本文HTML、投稿ID、slug、URLを保存し、失敗時に公開記事を壊さないようにします。
維持に向く状態
主要クエリと本文が一致し、重大な古い情報がなく、クリックや表示が安定している場合は、無理に変更しません。改善点がなくても再判定日を設定し、公式仕様の更新だけ定期確認します。
部分改善に向く状態
表示はあるがタイトルと検索意図に小さなずれがある、導入で答えが遅い、内部リンクが不足している場合は、必要な範囲だけ直します。実体験や広告リンクを壊さないよう、変更箇所を記録します。
本文リライトに向く状態
公式仕様が変わった、検索クエリが当初の想定と大きく違う、実体験が追加されて読者の判断を改善できる、重複箇所を統合できる場合に検討します。順位が下がったという一点だけで全面改稿しません。
期間比較の作り方
直近28日と前28日を比較するなら、ページ、検索タイプ、国、端末などの条件を揃えます。公開から28日に満たない記事は、前期間との比較が成立しません。数値が0のときも、データがないのか、実際に0なのかを確認します。
比較表にはクリック、表示、CTR、平均順位だけでなく、公開日、前回変更日、変更内容、主要クエリ、次回再判定日を入れます。数値だけでは、変化が記事編集によるものか、季節や検索需要によるものか説明できません。
自己クリックと確認アクセスを分ける
公開後の本人確認では、記事を何度も開き、広告リンクの飛び先を確認することがあります。WordPress側のPVや広告側の計測に影響する可能性があるため、確認作業の日時と方法を記録します。広告についてはASPの規約を守り、不適切な自己クリックを行いません。
テスト環境やプレビューで済む確認は本番アクセスと分けます。本番URLを開く必要がある場合も、確認回数を成果として扱いません。
変更履歴を残す
リライト後の評価には、何をいつ変えたかが必要です。記事ID、版、変更日、変更箇所、根拠、更新前後のslugとURL、次回再判定日を残します。slugと公開URLは原則維持し、同じWordPress投稿を更新します。
タイトル変更だけでも履歴を残します。変更直後の数値だけを見ず、次の評価周期まで待つ項目と、すぐに検査する項目を分けます。リンク切れや表示崩れは即時、検索パフォーマンスは一定期間で確認します。
評価シートの最小構成
- 記事ID、投稿ID、slug、公開URL
- 公開日、最終更新日、次回再判定日
- 主要キーワードと検索意図
- 直近期間と比較期間のクリック、表示、CTR、平均順位
- WordPress PVの定義と期間
- 広告クリックの媒体・期間・計測条件
- 判定、理由、次の処理
- 変更前バックアップの保存先
同じ行へすべての詳細を詰め込まず、記事マスター、GSC日次、リライト判定、履歴を記事IDでつなぎます。正本を一つに決めれば、古い数字や別記事のURLを参照しにくくなります。
評価で避けたい判断
- PVが少ないから広告クリックも少ないはずだと断定する
- GSCクリックとPVが一致しないため計測失敗と決める
- 30日で順位が確定したと考える
- 平均順位だけを見て主要クエリを確認しない
- 一度にタイトル・本文・CTAを全面変更する
- リライトを新規記事として公開する
- 公開予定日だけを見て評価期間を数える
よくある質問
Q. 30日でアクセスが0なら削除しますか？
削除を自動判断しません。公開状態、インデックス、検索需要、内部リンク、記事の役割を確認し、必要なら観察を続けます。
Q. CTRが低ければタイトル変更ですか？
表示回数、平均順位、主要クエリを一緒に見ます。少数データや低い掲載位置ではCTRだけで決めません。
Q. PVとGSCクリックのどちらが正しいですか？
どちらも別の範囲を測るため、目的に応じて使います。定義と集計条件を確認します。
Q. 90日で必ずリライトしますか？
いいえ。維持、観察、部分改善、本文リライトから、根拠のある次の処理を選びます。
関連記事
公開後確認を含む運用全体はひとり社長ブログを週4本運用する自動化設計、公開前の品質基準はWordPress自動投稿の品質ゲート設計、複数記事の処理履歴はGASでWordPressを4記事連続公開する設計で解説しています。
実務補足：評価会議を一人でも再現できる形にする
評価日時を先に決める
記事を気になった日に毎回見ると、好調な日だけ、あるいは不調な日だけを切り取って判断しやすくなります。公開時に次回再判定日を登録し、その日までは重大な誤り以外の全面変更を待ちます。評価日は休日や作業予定を考慮し、実際に確認できる日に設定します。
期限管理では、法律上の締切と社内の確認日を分ける考え方が役立ちます。公開後評価にも、データ集計日、確認日、変更実施日を分けて記録します。
ページフィルタを保存する
Search Consoleでは、サイト全体の合計ではなく対象URLへページフィルタをかけます。URL末尾の違い、httpとhttps、末尾スラッシュ、パラメータの扱いを確認し、意図したページだけが対象になっているか見ます。
同じ条件を次回も再現できるよう、期間、検索タイプ、国、デバイス、ページ条件を記録します。条件を変えた比較を同じ表へ混ぜません。
クエリを役割別に分ける
クエリは、主要キーワードと一致するもの、補助見出しに対応するもの、意図から外れるものへ分けます。外れるクエリが表示されても、すぐ本文へ追加しません。読者が記事に求める中心課題を壊さない範囲かを確認します。
補助クエリへ答える実体験や公式情報があるなら、FAQや注意点へ追加できます。根拠がなければ、新しい企画候補として実体験DBとの対応を探します。
タイトル変更の条件を決める
タイトルは、内容を正確に要約していない、主要クエリとずれている、古い名称が残っている、誇張表現がある場合に見直します。単にCTRが低いという理由だけでは変更しません。表示位置やデータ量を確認します。
変更時は、旧タイトル、新タイトル、理由、変更日、想定する検索意図を履歴へ残します。slugは変更せず、既存URLを維持します。
導入改善の条件を決める
記事へ入った読者が結論までたどり着きにくい場合、導入で対象条件、答え、注意点を先に示します。本文で扱わない内容を導入へ追加しません。実体験の範囲と公式情報の確認日を明確にします。
導入の変更は検索結果の数字だけでなく、記事内容の理解を助けるかで判断します。変更後は本文の結論や見出しと矛盾していないか確認します。
内部リンク改善の条件を決める
読者が次に必要とする詳細記事が公開されたら、関連箇所へ内部リンクを追加します。記事末尾へ機械的に大量追加するのではなく、疑問が生まれる直後へ置きます。
リンク先のstatus、slug、公開URL、HTTP応答を確認し、アンカーテキストが内容を説明しているか見ます。リダイレクト先や404を放置しません。
広告導線を評価する
広告クリックが少ない場合、記事の目的が申込み前の比較なのか、トラブル解決なのかを確認します。情報探索の初期段階の記事で、クリックが少ないことだけを失敗としません。読者の次の行動に広告が自然かを見ます。
広告リンクの位置を変える前に、飛び先、提携状態、PR表記、rel属性、計測要素を確認します。自己クリックで成果を確認しません。
PVが増えた理由を断定しない
内部リンク追加、検索表示、直接訪問、SNSなど、PV増加の原因は複数あります。接続されていない計測を使ったように書かず、確認できる流入元だけを扱います。現在GA4が未接続なら、GA4セッションを評価済みとして記録しません。
原因が特定できない変化は、相関として記録し、成果断定を避けます。次回に同じ条件で再確認できるよう、期間と変更履歴を残します。
少数データを言葉で補わない
表示やクリックが少ないと、都合のよい解釈を足したくなります。しかし、読者に支持された、需要がない、順位が安定したといった結論は、根拠が十分かを確認します。データ不足なら判定を観察中にします。
0という表示も、同期エラーや期間条件が原因でないかを確認します。GSC日次の同期結果と対象URLを照合し、取得できていない数字を実績として使いません。
リライト候補を自動選定するとき
自動判定は、公開日、経過日数、クリック、表示、CTR、平均順位、前期間との差を使えます。ただし、閾値だけで本文を自動上書きしません。候補を抽出し、検索意図、実体験、公式情報、既存記事との差を再確認します。
品質ゲートに合格した原稿だけを同じWordPress投稿へ反映し、更新前バックアップを残します。失敗時は公開中の記事を維持し、原因を直した対象記事だけを再処理します。
次回再判定日を決める
リライト後は、すぐに同じ指標で成否を決めません。原則の再判定日を設定し、その間に重大な不備だけを直します。季節性が強い記事は、前年同時期や需要期も別に確認します。
維持判定の記事にも次回日を持たせます。公式仕様、料金、サービス名の変更は検索数値と関係なく起こるためです。
週次と月次の確認を分ける
週次では、公開エラー、404、画像欠け、広告リンク切れ、GSC同期エラーなど、すぐ直すべき異常を確認します。月次では、クリックや表示の傾向、主要クエリ、内部リンクの機会を確認します。毎回同じ深さで全記事を見ません。
確認頻度を分けると、短期の変動で記事を触り過ぎず、重大な不備は早く見つけられます。
評価結果を次の公開計画へ戻す
検索クエリから新しい疑問が見つかっても、すぐ新規記事を作りません。既存記事の補足か、独立した検索意図か、実体験と一次情報があるかを確認します。公開計画へ追加する場合は、既存記事とのカニバリ説明も記録します。
評価は過去の記事を採点する作業ではなく、次に何を維持し、何を改善し、何を新しく作るかを決める材料です。
判定理由を人が読める文にする
『CTR低』だけでは次の担当者が判断できません。どの期間、どのページ、どの主要クエリで、表示と順位がどうだったため何を確認するのかを書きます。データ不足なら、その事実と再判定日を記録します。
判定値は集計しやすい短い語、理由は根拠を含む文章に分けると、自動抽出と人の確認を両立できます。
ブログ運用の土台を整える
記事企画や評価を仕組みにしても、公開先のWordPressが安定して動かなければ運用は止まります。運営者が実際に利用しているエックスサーバーの現行プランや仕様は、申込み前に公式ページで確認してください。
確認した公式情報
仕様や画面は変わる可能性があるため、2026年9月26日に次の現行ページを確認しました。
- Google Search Console：検索パフォーマンス レポート
- Google Search Console：表示回数、掲載順位、クリック数とは
- Google Search Central：有用で信頼性の高いユーザー第一のコンテンツ作成
まとめ
ブログ公開後の評価では、30日、60日、90日で問いを変えます。最初は公開・計測・検索表示、次にクエリとCTR、最後に記事の役割とリライト優先度を確認します。
GSC、WordPressのPV、広告クリックは定義が違います。期間と集計単位を揃え、同じ記事IDで履歴を残し、数値の違いをすぐエラー扱いしないことが重要です。公開中の記事を改善するときは、同じslug・URL・投稿を維持し、更新前バックアップと次回再判定日まで管理します。
