Google Search Console on kenji.blog

工程師為了增加技術部落格月流量應該做的事

Sat, 12 Sep 2026 12:00:00 +0900

前言：正因為是工程師才能做到的技術部落格成長駭客

許多軟體工程師都會開設技術部落格，但能聚集一定瀏覽量，並長期間維持與擴大流量的例子卻不多。寫出高品質的技術文章是大前提，但「只要寫出好文章自然就會有人看」的時代已經結束了。現在的搜尋引擎演算法變得非常複雜，而且社群網路上的資訊流動速度也比以往任何時候都要快。

然而，工程師擁有其他職位所沒有的優勢。那就是「理解系統架構、能組合工具進行自動化、能用程式分析數據」。本文將不只停留在單純的寫作技巧，而是將技術部落格視為一個「產品」，極度詳細且實踐性地解說如何利用工程能力來大幅提升月流量的策略。

1. 面向工程師的技術部落格SEO架構

作為部落格基礎的系統（如靜態網站生成器）和HTML結構，是搜尋引擎正確理解內容的最重要項目。

1.1 Core Web Vitals 的最佳化

Google 採用頁面體驗作為排名因素，特別是 Core Web Vitals (LCP, FID/INP, CLS) 在技術部落格中也無法忽視。技術部落格經常大量使用原始碼區塊、數學公式（MathJax / KaTeX）和圖解圖片。這些都會成為延遲頁面渲染的因素。

LCP (Largest Contentful Paint): 首屏主要內容的載入速度。主視覺圖片應使用 WebP 或 AVIF，並加上 fetchpriority="high" 屬性進行預載入。此外，用於語法標明的巨大 CSS 或 JS 應設計為非同步載入，或僅在需要的頁面載入。
CLS (Cumulative Layout Shift): 文章載入過程中的版面偏移。透過 CSS 的 aspect-ratio 等預先保留數學公式和圖片的顯示區域，可以防止後續 DOM 插入時造成的畫面跳動。
INP (Interaction to Next Paint): 對使用者操作的響應性。繁重的 JavaScript（例如客戶端的動態全文檢索或巨大的 Markdown 解析器執行等）不應在主執行緒上執行，必須轉移到 Web Worker，或者在建置時生成靜態 HTML (SSG)。

1.2 結構化資料（JSON-LD）的實作

為了明確地告訴搜尋引擎頁面是「文章」，作者是「誰」，需要實作 JSON-LD 格式的結構化資料。活用 TechArticle 或 SoftwareSourceCode 等 Schema，可以更容易顯示在 Google 的複合式搜尋結果中，從而提升 CTR（點閱率）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@type": "TechArticle",
 "headline": "工程師為了增加技術部落格月流量應該做的事",
 "image": [
 "https://example.com/img/eyecatch.jpg"
 ],
 "datePublished": "2026-09-14T10:00:00+09:00",
 "author": {
 "@type": "Person",
 "name": "Kenji",
 "url": "https://example.com/about/"
 },
 "publisher": {
 "@type": "Organization",
 "name": "Kenji's Tech Blog",
 "logo": {
 "@type": "ImageObject",
 "url": "https://example.com/img/logo.png"
 }
 }
}
</script>

1.3 語意化HTML與文件結構的最佳化

標題（h1〜h6）的適當嵌套是基本中的基本，但在技術部落格中會被要求正確使用 HTML5 的語意標籤，如 article, section, aside, nav。此外，透過適當區分表示原始碼的 <code> 和 <pre>、表示鍵盤輸入的 <kbd>、表示變數的 <var> 等，可以提供機器可讀 (machine-readable) 的 HTML。這對於 AI 的內容索引（LLM 的學習資料收集或 RAG 系統）也是非常有效的手段。

2. 搜尋意圖（Search Intent）的心理學與關鍵字策略

要最大化來自搜尋引擎的流量（自然流量），必須準確解讀使用者「為什麼用那個關鍵字搜尋」的搜尋意圖。技術相關的搜尋意圖大致可分為兩類。

2.1 「錯誤解決型」與「系統性學習・評論型」

錯誤解決型（Troubleshooting Intent）
- 搜尋關鍵字範例: Docker "no space left on device" 解決方案, Python IndexError list index out of range 原因
- 心理: 因為開發中的錯誤而卡住，現在立刻需要能作為特效藥的指令或程式碼片段。
- 策略: 在文章開頭（首屏）提示「結論（解決用的程式碼或指令）」。背景和詳細機制的解說放在後面，首先滿足使用者「想立刻修好」的渴望。這樣可以降低跳出率（Bounce Rate）。
系統性學習・評論型（Learning & Review Intent）
- 搜尋關鍵字範例: React vs Vue 2026 比較, Rust 非同步處理入門, GCP 網路架構設計
- 心理: 想選擇新的技術堆疊，或想從基礎加深理解，已經準備好花時間閱讀。
- 策略: 充實目錄（TOC），大量使用圖解或架構圖（如 Mermaid 等）。客觀比較優缺點，並包含在實際業務中如何使用的案例，可以延長停留時間。

2.2 流量的指數衰減模型與長尾策略

技術文章的瀏覽量，通常在公開後會因為在 SNS 等被瘋傳而形成高峰（Spike），隨後呈現指數型減少的趨勢。這個流量 $V(t)$ 可以用以下數學模型來近似：

$$ V(t) = V_0 e^{-\lambda t} + C $$

這裡的：

$V(t)$: 時間 $t$ 的流量
$V_0$: 公開後因 SNS 瘋傳等造成的初期流量高峰值
$\lambda$: 伴隨內容過時或 SNS 上被遺忘的衰減常數（取決於技術趨勢變化的速度）
$C$: 來自搜尋引擎的穩定自然搜尋流量（基準線流量）

要長期提升流量的關鍵，與其瞄準短暫的爆紅（$V_0$），不如將重點放在如何將常數項 $C$（來自搜尋引擎的持續流量）最大化。涵蓋大量像特定的小眾錯誤、或是特定工具之間的串接方法等，即使搜尋量少但沒有競爭對手的「長尾關鍵字」，來將 $C$ 的總和培育成巨大的流量。

3. 使用 Google Search Console API 的數據驅動內容分析

為了建構穩定的流量基礎 $C$，必須活用 Google Search Console (GSC) 的數據，客觀地分析「被 Google 給予了什麼樣的評價」。然而，在 GSC 的 Web UI 上點擊操作是有極限的。如果是工程師，就用 GSC API 和 Python 將分析自動化吧。

3.1 GSC API 與 Python 的自動化方法

建立一個腳本，自動偵測特定文章的搜尋排名是如何隨時間下降的（Decaying Content），或者顯示次數（曝光）很多但點閱率（CTR）卻異常低「很可惜的文章」。這會使用到 google-api-python-client 和 pandas。

3.2 Python 實作程式碼：自動萃取 CTR 下降的內容

以下腳本範例是從 API 取得過去 30 天的搜尋成效數據，並萃取出顯示次數 1000 次以上且 CTR 在 2% 以下的「標題或描述有很大改善空間的關鍵字與文章 URL」。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


import pandas as pd
from google.oauth2 import service_account
from googleapiclient.discovery import build
import datetime

# 1. 認證與建立 API 服務
KEY_FILE_LOCATION = 'path/to/your-service-account-key.json'
SCOPES = ['https://www.googleapis.com/auth/webmasters.readonly']
SITE_URL = 'https://your-tech-blog.com/'

credentials = service_account.Credentials.from_service_account_file(
 KEY_FILE_LOCATION, scopes=SCOPES)
webmasters_service = build('searchconsole', 'v1', credentials=credentials)

# 2. 計算請求期間（過去 30 天）
today = datetime.date.today()
end_date = (today - datetime.timedelta(days=2)).strftime('%Y-%m-%d')
start_date = (today - datetime.timedelta(days=32)).strftime('%Y-%m-%d')

# 3. 執行 API 請求
request = {
 'startDate': start_date,
 'endDate': end_date,
 'dimensions': ['query', 'page'],
 'rowLimit': 5000
}

response = webmasters_service.searchanalytics().query(
 siteUrl=SITE_URL, body=request).execute()

# 4. 使用 Pandas DataFrame 進行資料處理與過濾
if 'rows' in response:
 rows = response['rows']
 data = []
 for row in rows:
 data.append({
 'Query': row['keys'][0],
 'URL': row['keys'][1],
 'Clicks': row['clicks'],
 'Impressions': row['impressions'],
 'CTR': row['ctr'],
 'Position': row['position']
 })

 df = pd.DataFrame(data)

 # 過濾條件: 曝光次數 1000 以上 且 CTR 低於 2%
 target_df = df[(df['Impressions'] >= 1000) & (df['CTR'] < 0.02)]

 # 依照排名升冪排序（優先處理排名高卻沒有被點擊的項目）
 target_df = target_df.sort_values(by='Position', ascending=True)

 print("【建議修改標題/Meta Description 的清單】")
 print(target_df.head(10))

 # 根據需求輸出 CSV 等
 # target_df.to_csv('improve_candidates.csv', index=False)
else:
 print("找不到數據。")

透過 cron 或 GitHub Actions 的定期任務來執行這個腳本，就能持續以數據驅動來決定「應該重寫哪篇文章的標題」。不依賴直覺，而是基於數據的持續改善（不是 CI/CD 而是 Continuous Content Improvement）是非常重要的。

4. 文章的生命週期管理與重寫策略

技術文章不是發布了就結束了。隨著技術的演進（框架的版號升級、API 的棄用等），內容很快就會過時。持續提供舊資訊不僅會損害部落格的信譽，在 SEO 上也會獲得負面評價。

4.1 內容・生命週期管理（甘特圖）

用 Mermaid 甘特圖來展示理想的內容營運生命週期。

gantt
title 數據驅動型內容・生命週期管理
dateFormat YYYY-MM-DD
axisFormat %m/%d
section "階段1: 企劃・寫作"
"搜尋關鍵字・趨勢分析" :a1, 2026-09-01, 3d
"草稿・程式碼驗證" :a2, after a1, 5d
"推敲・校對" :a3, after a2, 2d
section "階段2: 發布・推廣"
"透過 CI/CD 管道進行部署" :p1, 2026-09-11, 1d
"自動 SNS 發布 (X, LinkedIn, RSS)" :p2, 2026-09-11, 1d
"擴散至社群書籤等" :p3, after p2, 3d
section "階段3: 觀測・分析"
"GSC 數據累積期間" :m1, 2026-09-14, 28d
"透過 Python API 進行成效評估":m2, after m1, 2d
section "階段4: 改善 (重寫)"
"修改 CTR 下降文章的標題" :r1, after m2, 3d
"程式碼更新至最新版本":r2, after r1, 4d

像這樣，將文章撰寫視為一個軟體開發專案來對待，並將發布後的營運・維護（重寫）階段納入計畫，是維持與提升流量的秘訣。

4.2 內容創作的 ROI（投資回報率）數學模型

既然工程師要花費寶貴的時間寫文章，就應該意識到其投資回報率 (ROI)。部落格的 ROI 可以公式化如下：

$$ ROI = \frac{\sum_{t=1}^{T} \left( Rev_{ad}(t) + Val_{brand}(t) + Val_{skill}(t) \right) - Cost_{time}}{\text{Cost}_{time}} \times 100 \ (\%) $$

$T$: 文章的有效壽命（直到過時的期間）
$Rev_{ad}(t)$: 廣告收益、聯盟行銷收益、贊助等直接收益
$Val_{brand}(t)$: 技術能力展示對職涯產生正面影響（轉職時錄取薪資增加、演講邀約等）的金錢換算值
$Val_{skill}(t)$: 為了撰寫文章，自身進行學習與調查所帶來的自我技能提升價值
$Cost_{time}$: 撰寫文章、製作圖解、驗證程式碼所花費的時間（換算成自己的時薪）

技術部落格最棒的一點是，即使 $Rev_{ad}$ 很少，$Val_{brand}$ 和 $Val_{skill}$ 也有變得極大的傾向。特別是高品質的技術解說會直接成為作品集，在轉職活動或獲取副業時發揮極大的威力。

5. 結合 GitHub Actions 與外部自動化工具的發布機制

建立內容後，如何有效率地傳遞給目標受眾（發布與分發）就成了一個課題。每次都手動將連結貼到各個 SNS 是沒有效率的，也不像工程師的作風。

5.1 社群媒體分享的自動化架構

建構一個架構，從將 Markdown 檔案合併到 GitHub 儲存庫的 main 分支那一刻起，到建置、部署、以及跨平台發布通知，都能完全自動化。

flowchart TD
A["開發者 (Git Push)"] --> B["GitHub 儲存庫"]
B -->|Webhook| C["GitHub Actions (CI/CD)"]
C -->|Build| D["靜態網站生成器 (Hugo/Gatsby)"]
D -->|Deploy| E["主機代管 (Vercel / Cloudflare Pages)"]
D -->|Generate| F["RSS Feed (index.xml)"]
F -->|Polled by| G["Zapier / IFTTT / Make"]
G -->|API Call| H["X (Twitter) 自動發文"]
G -->|API Call| I["LinkedIn 文章發文"]
G -->|API Call| J["Discord / Slack 社群 Webhook"]
C -->|Actions Script| K["Qiita / Zenn 跨平台發布 API"]

5.2 自動化管道的建置重點

透過 GitHub Actions 進行建置與部署 如果使用靜態網站生成器，可利用 GitHub Actions 將 HTML 的生成與部署到主機服務（Vercel, Netlify, Cloudflare Pages 等）自動化。這時，作為前述 Core Web Vitals 的對策，將圖片最佳化流程（例如自動轉換為 WebP）納入建置管道也是非常有效的。
利用 Zapier/IFTTT 搭配 RSS 觸發的 SNS 串接 網站生成器在建置時會產生最新的 RSS feed (XML)。讓 Zapier 或 Make (前 Integromat) 等 iPaaS 讀取這個 feed，並建立「當 RSS 有新增項目時，就將標題和 URL 發布到 X (Twitter) 和 LinkedIn」的工作流程。這樣一來，文章發布的瞬間就能自動通知追蹤者。
交叉發布 (Cross-Post) 到 Qiita/Zenn（Canonical 標籤的活用） 當自家部落格或個人部落格的網域權威（Domain Power）還很弱時，借用 Qiita 或 Zenn 等技術平台的集客力也是一種方法。但是，單純的複製貼上會有被當作重複內容而受到 SEO 懲罰的風險。這個問題可以透過在 Qiita 或 Zenn 文章的 Meta Data 中設定 Canonical 標籤，並指定自家部落格的原創文章 URL 來解決。透過 GitHub Actions 呼叫各種平台的 API，編寫從 Markdown 自動生成文章的腳本，就能完全自動化多管道的發布。

結語：轉動持續改善的循環

為了讓技術部落格的月流量出現戲劇性的成長，除了「寫作」這個行為之外，本次介紹的工程化方法也是不可或缺的。

建立有意識到 SEO 的穩固 HTML 與網站架構
規劃能理解使用者搜尋意圖（錯誤解決 vs 系統性學習）的文章
充分運用 Google Search Console API 與 Python 進行數據分析
意識到 ROI 的內容生命週期管理與重寫
透過 CI/CD 與 Zapier 串接，實現發布的完全自動化

如果能將這些組合成一個系統，技術部落格將會成為強力推動你個人職涯的最強資產（Asset）。如果工程師正為了流量停滯而煩惱，請務必從今天開始嘗試「部落格的成長駭客」。在開發業務中培養出的程式設計技能與架構設計能力，在經營部落格時也一定會成為最強大的武器。

運用 Google Search Console 重新撰寫過往技術文章的策略

Sat, 12 Sep 2026 12:00:00 +0900

1. 前言：技術部落格中重新撰寫的重要性與數據驅動方法

在經營技術部落格或針對開發者的自有媒體時，與持續撰寫新文章同等重要、甚至更重要的，就是「重新撰寫過往文章」。特別是 IT 與技術相關的主題，資訊過時得很快，幾年前寫的程式碼片段或 API 規格在現在已不建議使用 (Deprecated) 的情況也屢見不鮮。然而，如果只是盲目地更新舊文章，是無法將來自搜尋引擎的流量 (流入) 最大化的。

因此，本文將解說如何活用 Google Search Console (以下簡稱 GSC) 與 Google Analytics 4 (GA4) 的數據，採用數據驅動且數學化的方法，來鎖定應該重新撰寫的技術文章，並大幅提升搜尋排名與點擊率 (CTR) 的進階策略。

具體而言，我們將網羅各種方法，從運用 Python 和 BigQuery 整合 GSC 與 GA4 數據，找出相對於曝光次數但 CTR 卻很低的「錯失機會文章」，到使用 NLP (自然語言處理) 的 TF-IDF 分析，來找出 H2 或 H3 標題中缺乏的關鍵字，有效率地填補內容差距的手法。

2. 預期 CTR 與實際 CTR 的差距分析 (導入數學模型)

SEO 中最基本的指標之一就是「相對於搜尋排名的點擊率 (CTR)」。一般來說，當搜尋排名第 1 時的 CTR 大約是 25〜30%，第 2 名約 15%，之後便會呈現急遽下降的特性。這個排名與 CTR 的關係，可以被模型化為服從冪法則 (Power Law) 的分佈。

已知相對於排名 $r$ 的預期點擊率 $CTR(r)$ 可以用以下數學公式來近似：

$$ CTR(r) = a \cdot r^{-b} $$

在此，$a$ 代表第 1 名時的預期 CTR (例如：30% 的情況為 $0.30$)，$b$ 代表衰減參數 (通常介於 $1.0$ 到 $1.5$ 之間)。

在選定要重新撰寫的文章時，最有效的方法是找出「實際 CTR」遠低於「預期 CTR」的文章 (關鍵字)。舉例來說，儘管搜尋排名第 3 名 (預期 CTR 約為 10%)，但實際 CTR 卻只有 2% 的話，就可以判斷很有可能是搜尋意圖與標題、描述 (Description) 產生了落差，又或者是受到複合式摘要 (Rich Snippets) 等競爭因素的影響而被搶走了點擊。

下方的圖表展示了某技術部落格中預期 CTR 與實際 CTR 之間落差的示意圖。

xychart-beta
title 各排名的預期 CTR 與實際 CTR
x-axis ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"]
y-axis "CTR (%)" 0 --> 35
line [30.5, 15.2, 10.1, 7.5, 5.2, 4.1, 3.2, 2.5, 2.0, 1.5]
bar [32.1, 14.0, 8.5, 4.0, 5.0, 2.1, 1.5, 1.0, 1.2, 0.5]

(※ 折線代表預期 CTR，長條圖代表實際 CTR。可以確認在第 4 名與第 8 名時出現了大幅低於預期的情況。)

3. 使用 GSC API 自動擷取搜尋成效數據 (Python)

雖然從 GSC 的網頁介面下載 CSV 進行分析也是可行的，但為了應付大規模的部落格或進行持續性的分析，最好的方式還是建構一套使用 GSC API 搭配 Python 來自動擷取數據的機制。

以下展示了一個 Python 程式碼片段，使用 google-api-python-client 來取得特定期間內依頁面、依查詢 (Query) 的成效數據 (點擊次數、曝光次數、CTR、平均排名)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


import pandas as pd
from google.oauth2 import service_account
from googleapiclient.discovery import build

def get_gsc_data(key_path, site_url, start_date, end_date):
 # 讀取認證資訊並建構 API 客戶端
 credentials = service_account.Credentials.from_service_account_file(
 key_path, scopes=['https://www.googleapis.com/auth/webmasters.readonly']
 )
 service = build('searchconsole', 'v1', credentials=credentials)

 # API 請求的 Payload 設定 (指定頁面與查詢為維度)
 request = {
 'startDate': start_date,
 'endDate': end_date,
 'dimensions': ['page', 'query'],
 'rowLimit': 25000
 }

 # 執行 API
 response = service.searchanalytics().query(
 siteUrl=site_url, body=request
 ).execute()

 # 從回應中擷取數據並轉換為 Pandas DataFrame
 rows = response.get('rows', [])
 data = []
 for row in rows:
 keys = row['keys']
 data.append({
 'page': keys[0],
 'query': keys[1],
 'clicks': row['clicks'],
 'impressions': row['impressions'],
 'ctr': row['ctr'],
 'position': row['position']
 })

 return pd.DataFrame(data)

# 執行範例
# df_gsc = get_gsc_data('credentials.json', 'https://kenji.blog/', '2026-08-01', '2026-08-31')
# print(df_gsc.head())

透過這支腳本，可以將頁面 URL 與搜尋查詢關聯起來，以 DataFrame 的形式取得詳細數據。這使得我們能夠全面掌握特定文章是透過哪些關鍵字顯示出來的。

4. 使用正規表示式 (Regex) 過濾技術關鍵字

在技術部落格的分析中，GSC 的正規表示式 (Regex) 過濾器是一項非常強大的功能。舉例來說，當撰寫的文章橫跨前端、後端到基礎設施等多種領域時，我們有時會希望只萃取出「與 Python 或 Pandas 相關的錯誤或教學文章」，藉此決定重新撰寫的優先順序。

使用 GSC 的自訂正規表示式過濾器，就可以透過複雜的條件來篩選查詢。

技術關鍵字過濾的實際範例:

Python 相關的錯誤調查: ^(python|pandas|numpy|matplotlib).* (error|exception|bug|錯誤|無法執行)
AWS 相關的基礎設施建置: (aws|amazon web services|ec2|s3|lambda).* (建置|設定|教學|tutorial|how to)
特定函式庫的版本升級: (react|vue|angular) (v17|v18|v3) (migration|遷移|轉移)

若要將此整合到 GSC API 的請求中，可以活用 dimensionFilterGroups 來加上正規表示式的條件。充分利用這種過濾方式，就能精準地萃取出開發者「正因為遇到困難而進行搜尋」的高價值、解決問題型關鍵字。

5. 透過 BigQuery/Pandas 整合 GA4 與 GSC 數據

只靠 GSC 的數據，我們只能知道「搜尋排名與點擊率」。若要了解「來到該文章的使用者，實際停留了多久，以及是否達成轉換 (例如：前往 GitHub 儲存庫或訂閱電子報等)」，就必須整合 (JOIN) Google Analytics 4 (GA4) 的數據。

如果已將 GA4 的匯出數據與 GSC 的批次匯出數據儲存在 BigQuery 中，可以透過以下 SQL 查詢將兩者結合，進而萃取出「曝光次數多、搜尋排名也還不錯，但跳出率高或參與時間短的文章」。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


WITH gsc_data AS (
 SELECT
 url AS page_path,
 SUM(impressions) AS total_impressions,
 SUM(clicks) AS total_clicks,
 AVG(sum_top_position) AS avg_position
 FROM
 `project.searchconsole.searchdata_url_impression`
 WHERE
 data_date BETWEEN '2026-08-01' AND '2026-08-31'
 GROUP BY
 url
),
ga4_data AS (
 SELECT
 REGEXP_REPLACE(
 (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location'),
 r'^https?://[^/]+', ''
 ) AS page_path,
 COUNT(DISTINCT user_pseudo_id) AS users,
 AVG((SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'engagement_time_msec')) / 1000 AS avg_engagement_sec
 FROM
 `project.analytics_123456789.events_*`
 WHERE
 event_name = 'page_view'
 GROUP BY
 page_path
)

SELECT
 g.page_path,
 g.total_impressions,
 g.total_clicks,
 SAFE_DIVIDE(g.total_clicks, g.total_impressions) AS ctr,
 g.avg_position,
 a.users,
 a.avg_engagement_sec
FROM
 gsc_data g
JOIN
 ga4_data a ON g.page_path = a.page_path
WHERE
 g.total_impressions > 1000
 AND g.avg_position BETWEEN 3 AND 15
ORDER BY
 g.total_impressions DESC

利用這個結果，我們可以依照以下矩陣將要重新撰寫的對象進行分類：

High Impression, Low CTR, High Engagement: 只要在搜尋結果中被點擊，讀者就會感到滿意的文章。應將修改標題與 Meta Description 列為最優先事項。
High CTR, Low Engagement: 雖然會被點擊，但內容不如預期而導致讀者離開的文章。需要進行大規模的內文重新撰寫，例如改善前言、更新至最新的程式碼，以及提升資訊的完整度 (新增 H2/H3)。

6. 使用 NLP 與 TF-IDF 進行內容差距分析

鎖定應該重新撰寫的文章後，接下來要做的就是分析「具體來說應該新增什麼樣的標題 (H2/H3) 或關鍵字」。在這裡我們同樣不依靠直覺，而是活用自然語言處理 (NLP) 中的 TF-IDF (Term Frequency-Inverse Document Frequency)。

TF-IDF 是一種用來評估某個單字在該文件中重要程度的統計量。

$$ TF\text{-}IDF(t, d) = tf(t, d) \times \log\left(\frac{N}{df(t)}\right) $$

在此，

$tf(t, d)$ 為單字 $t$ 在文件 $d$ 中的出現頻率
$N$ 為所有文件的總數
$df(t)$ 為出現單字 $t$ 的文件數量

方法:

透過網路爬蟲等方式，取得目標關鍵字排名前 10 名的文章 (競爭對手網站) 的文字數據。
準備好自己網站中目標文章的文字數據。
使用 Python scikit-learn 的 TfidfVectorizer，萃取出在競爭對手前幾名文章中普遍獲得高分，但在自己網站的文章中卻不存在，或是分數明顯偏低的關鍵字 (特徵詞)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


from sklearn.feature_extraction.text import TfidfVectorizer
import pandas as pd
import numpy as np

# documents = [自己網站的文字, 競爭對手文章1的文字, 競爭對手文章2的文字, ...]
# 這裡假設已經備妥使用中文斷詞系統 (如 Jieba 等) 切分好的文字列表

def extract_missing_keywords(documents):
 vectorizer = TfidfVectorizer(max_df=0.9, min_df=2)
 tfidf_matrix = vectorizer.fit_transform(documents)

 feature_names = vectorizer.get_feature_names_out()

 # 計算競爭對手文章 (索引 1 之後) 的平均 TF-IDF 分數
 competitor_mean_tfidf = np.mean(tfidf_matrix[1:].toarray(), axis=0)

 # 取得自己網站文章 (索引 0) 的 TF-IDF 分數
 my_article_tfidf = tfidf_matrix[0].toarray()[0]

 # 計算競爭對手覺得重要，但自己網站中缺乏 (或較少) 的單字差距
 gap_scores = competitor_mean_tfidf - my_article_tfidf

 # 萃取出差距最大的前幾名單字
 df_gap = pd.DataFrame({'keyword': feature_names, 'gap_score': gap_scores})
 df_gap = df_gap.sort_values(by='gap_score', ascending=False)

 return df_gap.head(20)

# 範例: missing_keywords = extract_missing_keywords(processed_docs)
# print(missing_keywords)

透過這項分析，可以量化地發現主題的遺漏 (內容差距)，例如：「原來排名前面的文章也提到了『部署至 Docker 容器的方法』與『建置 CI/CD 流程』，但我的文章卻沒有觸及」。

發現的重要關鍵字群不能只是隨便散佈在內文中，而是必須將它們作為有意義的段落，以 H2 或 H3 標題 (Heading 標籤) 的形式加入，並針對標題撰寫詳細的技術解說與程式碼片段，如此一來便能大幅提升 Google 的評價。

7. 數據管道與持續改善循環

上述解說的流程並不是做一次就結束了，將其管道化 (Pipeline) 並持續執行，才是 SEO 成功的關鍵。以下使用 Mermaid 的流程圖來展示整體的架構與營運流程。

flowchart TD
A["GSC API 數據 (曝光次數, 點擊次數, 排名)"] --> C["BigQuery / 數據倉儲"]
B["GA4 匯出數據 (頁面瀏覽量, 參與時間)"] --> C
C --> D["Python / Pandas 數據整合與分析"]
D --> E["鎖定高曝光 / 低 CTR 的文章"]
E --> F["NLP 競爭對手爬蟲與 TF-IDF 關鍵字萃取"]
F --> G["最佳化 H2/H3 標籤與重新撰寫內容"]
G --> H["發布更新後的文章"]
H --> I["監控 CTR 變化 (預期與實際比較)"]
I --> |"回饋循環"| A

像這樣，將從 GSC 與 GA4 收集數據、透過分析選定目標、利用 NLP 最佳化內容，一直到監控結果的一連串流程系統化，就能讓部落格媒體成為持續自動成長的資產。

8. 總結與未來展望

活用 Google Search Console 來重新撰寫技術文章，並不僅僅是修改文字而已。這是一項針對搜尋引擎演算法這個黑盒子，透過運用數據與數學模型來提出最佳解答的高階工程。

總結本文解說的手法：

計算預期 CTR 與實際 CTR 的落差，鎖定修改後成效最顯著的文章。
使用 GSC API 與 Python 自動擷取成效數據。
在 BigQuery 上結合 GA4 的參與度數據，修改跳出率較高文章的內文。
透過使用 TF-IDF 的 NLP 分析，發現與競爭對手之間的內容差距，並最佳化標題 (H2/H3)。

技術趨勢會不斷改變。為了能精準回應讀者目前面臨的錯誤或課題，請務必將這種數據為輔的戰略性重新撰寫，融入到日常的營運當中。