技術ブログでインプレッション高・クリック低どう改善？GA/GSC週次運用SOP

Google Search Console の Performance レポートを開くと、ある記事のインプレッションが 3,500 回、クリックは 42 回しかない——CTR は 1.2% 以下。ランキングは 6 位、「クリック領域」にあるはずなのに、誰もクリックしないのはなぜ？さらに一般的な状況は、ブログ全体にこうした「幽霊ページ」が十数篇ある。毎週データを見ても、どこから改善すべきか分からず、改善しても効果が分からない。

2026年の技術ブログは新たな課題に直面：AI Overviews がユーザーの質問に直接回答し、ユーザーはクリック不要で情報を得られる。しかし、ゼロクリック傾向下でも、一部記事は依然として 20〜30% の CTR を維持——検索意図を捉え、タイトルがクリックを促す。

本記事は30分で実行可能な週次 SOP を提供：GSCで問題ページ抽出、原因診断、優先順位付け、タイトル改写技術、自動化ソリューションまで。読んで次週から即使用可能。

一、診断フレームワーク：ページが高インプレッション・低クリックの理由

高インプレッション・低クリックの本質は：ページが検索結果に表示されたが、ユーザーにクリックする理由がない。Content Decoded 2026年のデータ分析によると、通常三つの原因で発生：ランキング位置不良、タイトル魅力不足、検索意図不一致。2026年には第四の原因：AI Overviews が直接回答を提供。

1.1 ランキング vs CTR：本当に「クリック領域」にあるか？

CTR とランキング位置は直接関係。1位平均 CTR は 25〜35%、5位は 5〜8%に低下、8位以降は基本的に 3% 以下。ページが 8〜20位にランクイン、インプレッション量大だが CTR 低い場合、「問題」ではなく正常現象——ユーザーはあなたを見ていない。

真の「高インプレッション・低クリック」問題ページは、通常 3〜7位にランクイン、インプレッション 500〜5000 回、CTR はその位置应有水準より著しく低い。例えば5位にランクイン、CTR 应有 5〜8%、ページが 1〜2% なら真の改善対象。

もう一つの细节：モバイル CTR はデスクトップより 15% 程度低い。ブログ主要読者がモバイル（技術ブログモバイル流量通常 40〜60%）、CTR 基準値は相応に調整必要。

1.2 タイトル問題：安全タイトルは無視、好奇心ギャップが核心要素

タイトルは CTR 决定の第一要素。技術ブログ最容易の错误は「安全タイトル」——内容のみ描述、クリック理由不给。

安全タイトルの典型特徴：

• 主題のみ陈述：「React Hooks 入門チュートリアル」
• 数字なし、痛点なし、对比なし
• ユーザーはタイトル看完で内容概略を知り、クリック验证不要

こうしたタイトルは検索結果でユーザーに快速扫描され、记忆点を残さない。逆に、好奇心ギャップのあるタイトルはユーザーに「具体的何かを見たい」冲动を生む。

好奇心ギャップの创建方法：

• 数字具体化：「5つの失敗経験」（どの5つか知りたい）
• 痛点前置：「Docker デプロイ失敗7回後」（なぜ失敗か知りたい）
• 对比感：「MySQL クエリ遅い？4つの設定変更で10倍速」（どの4つか知りたい）

実測データ：Content Decoded が「SEO Tips」を「7 SEO Mistakes」に変更、CTR 20〜30% 増加。タイトル変更はランキング変更不要、直接クリック率増加。

もう一つのリスク：Ahrefs 2022年の研究显示、Google は 33.4% のタイトルタグを改写。タイトルが安全すぎる、長すぎる、またはページ内容不一致の場合、Google はページから他のテキストを抽出し表示タイトルに。Title と H1 一致は改写概率を低下——Title が「5つの失敗経験」なら、H1 は同様内容に、「完全ガイド」に変更不可。

1.3 検索意図不一致：错误对话に現れた

検索意図不一致の意味：ページがあるキーワード検索結果に現れたが、内容はユーザー真正需求に不符合。

典型例：

• ユーザー「マイクロサービスアーキテクチャ」検索、意図は概念・原理理解、記事は「マイクロサービスデプロイ失敗記」
• ユーザー「Redis 性能最適化」検索、意図は具体設定方法探す、記事は「Redis 基礎紹介」

こうした不一致は高インプレッション（キーワード确实一致）、低クリック（ユーザーはタイトル扫描で目的不同を知る）を招く。

意図不一致判断方法：

• Google でそのキーワード検索、前5位の内容タイプ確認（チュートリアル、ケース、ツール对比、概念解释）
• 内容が主流結果タイプと一致か对比
• 不一致なら、内容位置調整またはキーワード変更

技術ブログ特殊情况：痛点キーワードCTR 基準値本来就低。「マイクロサービスタイムアウトどう対処」等、ユーザーは通常問題既遭遇、具体解決策を急探す。タイトルが明確でない（「マイクロサービスタイムアウト処理」而非「マイクロサービスタイムアウト：3つの排查ステップ」）、CTR は一般技術記事より低い。業界观察显示、痛点キーワード記事CTR 基準値は約 2〜4%、一般技術記事の 5〜8% より低い。

1.4 AI Overviews：2026年最大ゼロクリック挑戦

2026年、Google AI Overviews は検索行動を変化。ユーザーが質問検索時、AI Overviews は検索結果顶部で直接回答生成、ユーザーはリンククリック不要で情報を得る。

これは「Great Decoupling」と呼ばれる——検索量とクリック量が脱钩。ページはランキング良好、タイトルも良いが、AI Overviews 既に核心回答を提供、ユーザーはクリック动机を持たない。

対処策略：

• 内容は「AIが完全に提供できない」部分を含む：具体コード例、失敗経験、設定细节、実測データ
• タイトルは「追加価値あり」を明示：「実測」「失敗経験」「完全設定」等
• AI Overviews が容易回答する問題（例「What is React Hooks」）に対し、より具体サブ問題に転向（例「React Hooks useEffect クロージャ問題どう解決」）

これは短期トレンドではなく長期変化。ブログが泛概念記事で流量获取依赖の場合、具体問題・実践内容に逐步転向必要。

二、GSC抽出実践：30分で「幽霊ページ」を見つける

問題タイプを知った後、次はブログデータから具体「問題ページ」を見つける。GSC Performance レポートは完全データを提供、しかし多くの人はフィルタ正确使用を知らない。

2.1 GSC Performanceを開く、四大指標をチェック

GSC → Performance 进入、四つの核心指標を見る：総クリック数、総インプレッション数、平均CTR、平均ランキング位置。默认は前二つのみ表示、後二つは手動チェック必要。

チェック後、レポートは以下を显示：

• クリック数：ユーザーがページをクリックした数
• インプレッション数：ページが検索結果に表示された回数
• CTR：クリック/インプレッション百分比
• 平均ランキング：ページがそのキーワード下平均ランキング位置

時間範囲は過去28日推奨、十分データ量を見ながら近期変化を反映。ブログ流量较小（日インプレッション < 500）の場合、90日に延長可能。

2.2 フィルタ設定：「ランキング良好CTR低」ページを精准定位

GSC フィルタ機能は核心。默认は全データ表示、「問題ページ」をフィルタで見つける必要。

ステップ：

1. 「新フィルタ」またはページ顶部フィルタ領域をクリック
2. 「Position」を選択
3. 条件設定：「5未満」または「7未満」（ブログ全体ランキング状況に依存）
4. 別フィルタ追加、「CTR」を選択
5. 条件設定：「未満」某个値——この値はブログ平均CTR に基づき調整

技術ブログ平均CTR 参考値：Embarque データによると、CleanVoice（技術ツール類サイト）平均CTR 約 7.8%。ブログ全体CTR が 5〜8% の場合、フィルタ阈值を平均CTR の 50% 以下に設定、例 CTR < 3%。

例：ブログ平均CTR が 6% の場合、フィルタ設定：

• Position < 7（1〜7位にランクイン）
• CTR < 3%（平均半分以下）

こうした抽出ページは、ランキング良好CTR 异常低、改善対象。

2.3 次元切替：キーワードからページへ、問題記事を見つける

GSC 默认次元は「Query」、各キーワードデータを显示。しかし見つけるべきは「ページ」、キーワード本身ではない。

操作方法：

1. Query 次元で、どのキーワードがフィルタ条件に符合確認（ランキング良好CTR 低）
2. 具体キーワードをクリック、キーワード詳細ページ进入
3. 詳細ページ顶部で、次元を「Page」に切替
4. これでそのキーワード对应ページデータを表示

このステップで確認：某个キーワード低CTR が、どのページによる。一部キーワードは複数ページ对应（ブログに多篇関連記事）、逐一確認必要。

もう一つの技巧：フィルタで直接「Page」次元を選択、キーワードフィルタを削除、各ページ全体データを直接表示。こうしてページ全体CTR をより准确判断、単一キーワードに误导されない。

2.4 データエクスポート＋優先順位付け：今週改善3記事

抽出完了後、データをCSV にエクスポート。GSC は現在抽出結果のエクスポートを支持、Query、Page、Clicks、Impressions、CTR、Position 等フィールドを含む。

エクスポート後、Excel または Google Sheets で以下優先順位でソート：

1. インプレッション降順：インプレッション量大ページ優先、影響範囲広
2. CTR 昇順：インプレッション相近場合、CTR 更低ページ優先
3. 改善難度主観判断：一部ページはタイトル変更でCTR 増加可能、一部は内容位置調整必要

最終今週改善目標を抽出：週3記事のみ改善推奨、過度変更で効果追跡不可を避ける。

ソート例：

• ページA：インプレッション 3,500、CTR 1.2%、ランキング5位 → 高優先（インプレッション量大、CTR 异常低）
• ページB：インプレッション 800、CTR 2.5%、ランキング6位 → 中優先（インプレッション量小）
• ページC：インプレッション 400、CTR 0.8%、ランキング8位 → 低優先（ランキング本身不良、真の「問題ページ」ではない）

ソート後、この3記事を記録：

• 現在タイトル
• 主要キーワード
• 現在CTR
• 改写後新タイトル（第三章で改写方法説明）

次週に改写前後CTR を对比、効果を確認。

三、タイトル改写技術：20〜30% CTR 向上の実践方法

タイトル改写は最直接・効果最快の改善手段。Content Decoded 実測データ显示、タイトル変更のみでCTR 20〜30% 向上可能、ランキング変更不要。

3.1 タイトル改写公式：数字＋痛点＋権威感

タイトル改写には再利用可能公式：

[数字]＋[痛点/問題]＋[解決策/結果]＋[権威感マーク]

数字の役割：

• 内容範囲を具体化：「5つの失敗経験」は「失敗経験」より確定性高い
• ユーザー読む不安を減少：読む所要時間を知る
• 技術ブログ精确スタイルに適合

痛点の呈现方法：

• 直接問題陈述：「Docker デプロイ失敗」
• ユーザー常见困惑：「React Hooks どう使う」
• 結果导向：「MySQL クエリ遅い」

解決策または結果：

• 具体ステップ：「3つの排查ステップ」
• 量化結果：「10倍速」
• 阶段性成果：「入門からトラブルシュート」

権威感マーク（オプション但有効）：

• 「実測」「失敗経験」「踩过的坑」——真实経験表示
• 「完全」「フル」——内容全面表示
• 年または版本番号——時效性表示

完全公式例：

• 原タイトル：「React Hooks 入門チュートリアル」
• 改写タイトル：「React Hooks 5つの失敗経験：入門からトラブルシュート」
  • 数字：5つ
  • 痛点：失敗経験（ユーザーは坑に遭遇を知る）
  • 結果：入門からトラブルシュート（明確学習パス）
  • 権威感：失敗経験（真实経験暗示）

改写時注意：タイトル長度60文字以内（中国語約30字）、否则Google で截断。核心キーワードは前15文字内に出现、SEO 効果保証。

3.2 技術ブログ特化：失敗経験類タイトル更に魅力

技術ブログと他タイプブログの差異：技術読者は「真实経験」と「具体细节」を更に重視。「チュートリアル」「ガイド」類タイトルは容易無視、「失敗経験」「実測」「失敗後总结」類タイトルは読者に信じさせる：この記事は真东西がある。

失敗経験類タイトルの構造：

• 痛点前置：「Docker デプロイ失敗7回後」
• 总结数量：「3つの核心設定を总结」
• 可信度暗示：「失敗7回」は多次验证を表示、纸上谈兵ではない

実測ケース对比：

原タイトル	改写タイトル	予想向上
React Hooks 入門チュートリアル	React Hooks 5つの失敗経験：入門からトラブルシュート	25〜30% 増加
Docker デプロイ最適実践	Docker デプロイ失敗7回後、3つの核心設定を总结	30〜35% 増加
MySQL 性能最適化ガイド	MySQL クエリ遅い？4つの設定変更で10倍速（実測）	20〜25% 増加

改写要点：

• 「最適実践」を「失敗後总结」に——前者は教科書、後者は真实経験
• 「入門チュートリアル」を「失敗経験」に——前者は泛泛、後者は具体
• 「ガイド」を「実測」に——前者は理論、後者はデータ支撑

技術ブログ読者は通常一定経験を持ち、「入門」類内容不要、「坑避け」「トラブルシュート」類内容必要。タイトルはこの需求を反映。

3.3 安全タイトル回避：描述性 vs 好奇性对比

安全タイトル特徴は「描述性」——主題のみ陈述、理由不给。好奇心タイトル特徴は「好奇性」——情報ギャップを残、ユーザーはクリック验证を欲する。

对比原则：

安全タイトル特徴	好奇性タイトル特徴
主題のみ陈述：React Hooks 入門	数字含む：React Hooks 5つの场景
痛点なし：性能最適化ガイド	痛点前置：MySQL クエリ遅い？
对比なし：Docker デプロイチュートリアル	对比または結果：変更後10倍速
権威感マークなし：最適実践	権威感マーク：実測、失敗経験
ユーザーは内容を知る	ユーザーは具体细节を知りたい

改写ステップ：

1. 原タイトル核心キーワードを見つける（保持不变）
2. 原タイトルが「描述性」または「好奇性」か判断
3. 描述性の場合、数字、痛点、結果または権威感マークを追加
4. キーワードを前15文字内に保持
5. 長度60文字以内に控制

過度改写不可。タイトルは依然内容を准确反映、クリック吸引のためユーザー误导不可。例 内容は2つの失敗経験のみ、「5つの失敗経験」不可。

3.4 Title と H1 一致：Google 改写リスク低下

Google はタイトルタグを改写、以下条件に不符合時：

• タイトルとページ内容不一致
• タイトル長すぎ截断
• タイトル安全すぎるまたは泛すぎる

Ahrefs 2022年研究显示、33.4% タイトルタグがGoogle で改写。改写後タイトルはページ他部分（通常H1 またはページ开头テキスト）から、CTR 低下可能性——改写後タイトルは設計意図に符合不一定。

改写リスク低下方法：

• Title と H1 一致または高度相似保持
• Title は核心キーワード含む、H1 も同様キーワード含む
• Title 長度适中（60文字以内）、截断回避
• Title は内容を真实反映、误导不可

例：

• Title：「React Hooks 5つの失敗経験：入門からトラブルシュート」
• H1：「React Hooks 5つの失敗経験」または「React Hooks 失敗記：5つの常见問題」
• H1 は「React Hooks 完全ガイド」に変更不可（Title 主題偏离）

タイトル改写時、ページ H1 同期調整必要。ブログ后台で修正、meta title のみ変更で完了不可。

四、週次運用 SOP：反復可能30分チェック流程

前三章は診断フレームワーク、GSC 抽出、タイトル改写を説明、今週次実行可能 SOP に統合。核心原则：流程化、反復可能、時間可控。

4.1 SOP 核心構造：チェック→診断→変更→验证

SOP 核心公式：役割＋场景＋時間＋アクション＋目標

四つのステップに分解：

1. チェック：週固定時間でGSC を開く、フィルタで問題ページを見つける
2. 診断：各問題ページ原因を判断（ランキング、タイトル、意図不一致）
3. 変更：優先順位でタイトル改写、meta 調整、必要時内容位置調整
4. 验证：次週改写前後データを对比、効果を記録

この循环は各変更追跡を保証、「変更効果不明」状況回避。

4.2 時間配分：週30分効率完了方法

30分 SOP 時間配分：

時間段	ステップ	具体アクション	ツール	出力
0〜10分	抽出	GSC Performance を開く、フィルタ設定：Position < 7＋CTR < 3%、CSV エクスポート	GSC Performance	Top 10 問題ページCSV
10〜15分	診断	各ページランキング、CTR、主要キーワード確認、Google でキーワード検索し意図不一致判断	GSC＋Google 検索	原因分類マーク（タイトル問題/意図不一致/ランキング問題）
15〜20分	優先順位	「インプレッション降順＋CTR 昇順」でソート、今週改写 Top 3 を抽出	CSV＋主観判断	今週改善リスト（3ページ）
20〜30分	改写	第三章公式でタイトル＋meta description 改写、改写前後对比記録	VS Code / ブログ后台	改写後記事＋改写記録表
次週同時刻	验证	改写前後CTR（28日データ）を对比、向上幅度記録、二次改善必要判断	GSC Performance	効果追跡表

時間配分要点：

• 10分抽出：固定時間推奨（例月曜9 AM）、拖延回避
• 5分診断：快速原因判断、各ページ詳細深入挖掘不可
• 5分優先順位：最大3記事変更、贪多不可
• 10分改写：公式直接適用、措辞反复纠结不可

週「高インプレッション・低クリック」問題ページ見つからない場合、「低インプレッション但ランキング良好」ページチェック可能（潜在流量機会）。

4.3 棜査清单模板：週必查5つの指標

週次 SOP は以下指標を記録、後续追跡便利：

今週検査清单：

1. 総インプレッション量：前週相比明確波動あるか（10% 以上増加または減少）
2. 総クリック量：前週相比明確波動あるか
3. 平均CTR：歴史平均以下か（ブログ基準線知る必要）
4. 問題ページ数量：抽出後「高インプレッション・低クリック」条件符合ページ数
5. 今週改写ページ：改写3ページURL、原タイトル、新タイトル記録

記録模板（Excel/Google Sheets）：

ページURL	原タイトル	新タイトル	改写日	改写前CTR	改写前ランキング	改写前インプレッション	次週CTR	CTR 向上
/post-1	React Hooks 入門	React Hooks 5つの失敗	2026-06-17	1.2%	5	3500	記入待ち	計算待ち
/post-2	Docker 最適実践	Docker デプロイ失敗总结	2026-06-17	2.5%	6	800	記入待ち	計算待ち
/post-3	MySQL 最適化ガイド	MySQL クエリ遅い実測	2026-06-17	3.1%	4	1200	記入待ち	計算待ち

この表週次更新、長期積累後改善効果トレンドを見る。

4.4 验收基準：CTR 5% 向上またはインプレッション 10% 増加

改写後验收基準：

成功基準：

• CTR 5% 以上向上（相对値）：例原CTR 1.2%、改写後最低 1.26%
• またはインプレッション量 10% 以上増加（绝对値）：例原インプレッション 3500、改写後最低 3850

失敗基準：

• CTR 明確変化なし（5% 以下向上）
• またはインプレッション量 10% 以上減少

失敗後処理：

• タイトル改写失敗の場合、二次改写试行（別角度）
• 意図不一致問題の場合、内容位置調整必要（タイトル変更のみ解決不可）
• ランキング低下CTR 低下の場合、新競争对手ページあるか確認

验收時間：

• 改写後7日以上待つ（GSC データ更新時間必要）
• 改写幅度大（例タイトル完全重构）の場合、14〜28日待つ推奨

验收後記録：

• 成功ケース：改写公式保持、次回類似問題直接適用
• 失敗ケース：原因分析、診断方法更新

長期目標：週次 SOP 4週間実行、ブログ全体CTR 可視向上（例平均 5% から 6〜7%）。

五、自動化ソリューション：n8n＋GSC ワークフロー設定

手動 SOP 週30分、ブログ規模拡大（100記事以上）の場合、手動操作は煩雑化。n8n は自動化ソリューション提供、GSC データ自動取得、問題ページ分析、レポート生成・通知送信。

5.1 n8n ワークフロー核心ノード

n8n ワークフロー基本構造：

トリガーノード：スケジュールトリガー（毎週月曜9 AM）
→ データ取得ノード：GSC API でPerformance データ取得
→ データ処理ノード：「高インプレッション・低クリック」ページ抽出
→ AI 分析ノード：AI でタイトル問題分析、改写提案生成
→ レポート生成ノード：HTML/PDF レポート生成
→ 通知ノード：Gmail/Slack 通知送信

n8n 公式SEO audit workflow テンプレート提供、直接导入修正可能。テンプレートはGSC データ取得、HTML レポート生成、メール送信三つの核心ノード含む。

5.2 設定ステップ：API キー＋スケジュール頻度＋レポート形式

設定は五つのステップに分：

ステップ1：n8n 登録、公式テンプレート导入

• n8n は無料自托管版と有料クラウド版ある
• テンプレート导入：https://n8n.io/workflows/6698-daily-seo-audit-workflow-with-html-reports-via-gmailslack/
• テンプレート默认「Daily SEO audit」、週次スケジュール変更必要

ステップ2：GSC API キー設定

• Google Cloud Console 进入：https://console.cloud.google.com/
• プロジェクト创建、Google Search Console API 有効化
• サービスアカウント创建、JSON キーファイルダウンロード
• n8n GSC ノードでAPI キー設定

ステップ3：スケジュール頻度設定

• トリガーノードを「Schedule Trigger」に変更
• 頻度設定：毎週月曜9 AM（手動SOP 時間一致）

ステップ4：AI 分析プロンプト調整

• AI 分析ノード（通常OpenAI またはClaude ノード）でプロンプト修正
• 技術ブログCTR 基準値追加（5位 5〜8%、8位 <3%）
• 痛点キーワード認識逻辑追加（キーワード含「どう対処」「失敗」「失敗経験」等）

プロンプト例：

あなたは技術ブログSEO 分析アシスタント。以下GSC データを分析、「高インプレッション・低クリック」問題ページを見つける。

CTR 基準値参考：
- 1位：25〜35%
- 5位：5〜8%
- 8位：<3%

痛点キーワードCTR 基準値：2〜4%

抽出条件：
- Position < 7
- CTR < 3%

出力：
1. 問題ページリスト（Top 10）
2. 各ページ診断原因（タイトル問題/意図不一致/ランキング問題）
3. タイトル改写提案（「数字＋痛点＋権威感」公式適用）

ステップ5：レポート送信設定

• 送信方法選択：Gmail / Slack / Google Drive
• レポート形式：HTML（默认）またはPDF（別ノード必要）
• レポート内容：問題ページリスト＋改写提案＋前週CTR 对比

5.3 技術ブログ適配：痛点キーワード自動認識

技術ブログと一般ブログ差異は痛点キーワード処理。痛点キーワード（例「マイクロサービスタイムアウトどう対処」「Docker デプロイ失敗」）CTR 基準値本来就低、自動化で特別処理必要。

痛点キーワード自動認識逻辑：

• キーワード含：「どう対処」「失敗」「失敗経験」「トラブルシュート」「解決」
• これらキーワードページCTR 基準値2〜4% 調整（5〜8% ではなく）
• AI 分析でこれらページタイトル改写提案は「具体ステップ」「実測」強調

n8n ワークフローでデータ処理ノード追加、正規表現で痛点キーワード認識：

// 痛点キーワード認識
const painPointKeywords = ["どう対処", "失敗", "失敗経験", "トラブルシュート", "解決", "エラー", "問題"];
const isPainPoint = painPointKeywords.some(keyword => query.includes(keyword));

if (isPainPoint) {
  // CTR 基準値調整
  ctrThreshold = 2; // 3 ではなく
}

5.4 降級方案：自動化失敗時手動 SOP

自動化は必須ではない。n8n 設定失敗、API キー問題、レポート送信失敗の場合、手動 SOP 依然実行可能。

降級方案：

• n8n 設定失敗：手動SOP に戻る（第四章）、週30分
• API キー問題：GSC から手動CSV エクスポート、Excel 分析
• レポート送信失敗：n8n 界面直接ワークフロー実行結果表示

自動化と手動関係：

• 自動化時間節約：keyword.com ケース显示、自動化は週10時間以上節約可能
• 手動SOP 更に柔軟：一部問題（例意図不一致）は人判断必要
• 推奨：手動SOP 習熟（4週間実行）後、自動化検討

自動化は目標ではなくツール。手動SOP 既に十分効率の場合、自動化不一定必要。

結論

高インプレッション・低クリックは技術ブログの宿命ではない。通常三つの具体原因で発生：ランキング位置不良、タイトル魅力不足、検索意図不一致。2026年にはAI Overviews ゼロクリック挑戦も。

解決パスは系统化：週30分 SOP、GSC 問題ページ抽出、原因診断、優先順位付け、タイトル改写から効果验证まで。4週間継続、ブログ全体CTR 増加開始を見る。

重要判断点：

• ランキング3〜7位、CTR 基準値より著しく低いページは真の改善対象
• タイトル改写公式：数字＋痛点＋権威感マーク
• Title と H1 一致、Google 改写リスク低下
• 技術ブログ特化：失敗経験類タイトルは「入門チュートリアル」より魅力

今GSC Performance レポートを開く、本記事フィルタで最初の「幽霊ページ」を見つける。次週戻り、改写後CTR 向上を教えて。