結論先講
SEO 的核心就三件事：讓 Google 找到你、讓 Google 看懂你、讓 Google 覺得你值得推薦。 大部分工程師只做了第一件的一半，其他兩件完全沒做。
我自己踩過最慘的坑：300 篇技術文章，Google 收錄的全是舊站已經 404 的頁面。新文章一篇都搜不到。原因？網站從 Hexo 搬到 Quartz 時，沒做 redirect。
Google 的三個階段：爬取、索引、排名
很多人以為 SEO 就是塞關鍵字。錯。Google 處理你的網頁分三個階段，每個階段都有可能出問題：
階段一：爬取（Crawling）
Googlebot 會來你的網站抓頁面。它怎麼知道你有哪些頁面？
- Sitemap — 你主動告訴 Google「我有這些頁面」
- 內部連結 — 從首頁點得到的頁面，Googlebot 會順著爬
- 外部連結 — 別的網站連到你，Google 就會發現你
工程師最常犯的錯：
- 沒有 sitemap，或 sitemap 過期沒更新
- SPA（單頁應用）沒做 SSR/SSG，Googlebot 看到空白頁
robots.txt不小心擋掉了重要頁面- 網站搬家沒做 redirect，Google 還在爬舊 URL
# robots.txt — 正確示範
User-agent: *
Allow: /
# 不要擋 CSS/JS，Googlebot 需要渲染頁面
# Disallow: /static/ ← 這行會害死你
Sitemap: https://your-site.com/sitemap.xml階段二：索引（Indexing）
Google 抓到你的頁面後，要決定「這頁在講什麼」。它看的東西：
<title>標籤 — 搜尋結果的藍色標題，最重要<meta name="description">— 搜尋結果的灰色描述<h1>~<h3>標題結構 — 幫 Google 理解內容層級- 內文關鍵字 — 自然出現，不是硬塞
<link rel="canonical">— 告訴 Google 哪個 URL 是正版
工程師最常犯的錯：
<title>每頁都一樣（「我的部落格」）- 沒寫
description，Google 自己截你內文（通常截得很醜） - 一頁有多個
<h1> - 重複內容沒用
canonical指定正版
<!-- 好的 title — 包含關鍵字 + 站名 -->
<title>RAG 實作指南：從切文件到 Vector DB | Terry's Blog</title>
<!-- 好的 description — 講清楚這頁在幹嘛，150 字以內 -->
<meta name="description" content="用 LangChain 實作 RAG：文件切割策略、
Embedding 選型、Pinecone vs Chroma 比較，附完整 Python code。">
<!-- canonical — 告訴 Google 這是正版 -->
<link rel="canonical" href="https://your-site.com/ai/02-rag-architecture">階段三：排名（Ranking）
Google 知道你的頁面在講什麼之後，要決定搜「RAG 教學」時，你排第幾。影響排名的因素超過 200 個，但工程師能控制的主要有：
| 因素 | 說明 | 你能做的 |
|---|---|---|
| 內容品質 | 原創、深入、解決問題 | 寫好文章，不要水 |
| 頁面體驗 | Core Web Vitals（LCP、CLS、INP） | 優化載入速度 |
| 行動裝置友善 | Responsive design | 測試手機版 |
| HTTPS | 加密連線 | 用 HTTPS（GitHub Pages 自帶） |
| 反向連結 | 別人引用你 | 寫值得被引用的內容 |
| 結構化資料 | Schema.org JSON-LD | 幫搜尋結果加 rich snippet |
技術 SEO 檢查清單
每個網站上線前，至少確認這些：
必做（沒做就是隱形）
-
sitemap.xml存在且有效 — 包含所有公開頁面 -
robots.txt沒擋到內容 —Allow: /且有Sitemap:指令 - 每頁有唯一的
<title>— 包含頁面主題 + 站名 - 每頁有
<meta description>— 150 字內描述內容 - 每頁有
<link rel="canonical">— 指向自己的正確 URL - HTTPS — 沒有 mixed content 警告
- 行動裝置友善 — 用 Mobile-Friendly Test 測
- 註冊 Google Search Console — 提交 sitemap、監控索引
應做（做了加分）
- Open Graph meta — 分享到社群時有正確的標題、描述、圖片
- 結構化資料 — Article、BreadcrumbList、FAQ 等 Schema.org
- 圖片有
alt屬性 — Google 圖片搜尋的來源 - 內部連結策略 — 相關文章互相連結
- 404 頁面 — 自訂 404，引導使用者回到有用的頁面
- 網站速度 — LCP < 2.5s, CLS < 0.1, INP < 200ms
千萬不要做
- 關鍵字堆砌 — Google 會懲罰
- 隱藏文字 — 白底白字那種，直接扣分
- 購買連結 — Google 能偵測，扣分
- 抄襲內容 — 重複內容不會被索引
- 頻繁改 URL 結構 — 每改一次就損失一次 SEO 積累
網站搬家的 SEO 災難
這是我親身經歷的教訓，值得單獨講。
我把部落格從 Hexo 搬到 Quartz，URL 結構從 /{category}/{date}/{hash}/ 變成 /{category}/{slug}。結果：
舊 URL（Google 索引中）：
/devOps/20240915/3152381087/ → 404 ❌
新 URL（實際存在）：
/git/08-release → 200 ✅
Google 的判斷：這個網站的頁面都壞了 → 降權
正確做法： 舊 URL 要做 redirect 到新 URL
<!-- 在舊路徑放 redirect HTML -->
<link rel="canonical" href="https://site.com/git/08-release">
<meta http-equiv="refresh" content="0; url=https://site.com/git/08-release">
<meta name="robots" content="noindex">關鍵三行：
canonical— 告訴 Google 正版在哪meta refresh— 立即跳轉noindex— 別索引這個舊頁面
詳細的搬家 SEO 流程，我會在 網站搬家 SEO 那篇展開講。
AEO：AI 時代的 SEO
2024 年之後，搜尋不只是 Google 了。使用者開始用 ChatGPT、Perplexity、Google SGE 來找答案。這些 AI 引擎找答案的方式跟傳統搜尋引擎不同：
| 傳統 SEO | AEO（Answer Engine Optimization） | |
|---|---|---|
| 目標 | Google 搜尋結果排名 | 被 AI 引用為答案來源 |
| 評估 | 點擊率（CTR） | 被引用次數 |
| 內容格式 | 長文章、關鍵字 | 結構化問答、清晰的段落 |
| 技術重點 | sitemap、meta tag | Schema.org、FAQ structured data |
| 連結價值 | 反向連結提升排名 | 權威性決定被引用機率 |
AEO 的核心原則：讓你的內容容易被 AI 擷取和引用。
這代表：
- 段落要短、結構要清楚（H2/H3 分層）
- 問題和答案要明確配對
- 提供具體的數據和範例
- 用列表和表格整理資訊
下一步
如果你只做一件事，先去 Google Search Console 看你的網站索引狀態。知道問題在哪，才知道要修什麼。