SEO 完全指南

目錄

• 什麼是 SEO？
• 搜尋引擎運作原理
• 技術 SEO
• 站內 SEO（On-Page SEO）
• URL 與內部連結策略
• 內容優化
• 站外 SEO（Off-Page SEO）
• Core Web Vitals
• 結構化資料
• SEO 工具
• 最佳實踐
• 常見問題
• 總結

什麼是 SEO？

SEO（Search Engine Optimization） 是透過優化網站內容和技術架構，提升網站在搜尋引擎自然搜尋結果中排名的過程。

SEO 三大支柱

┌─────────────────────────────────────────────────────────┐
│                      SEO 三大支柱                        │
├─────────────────┬─────────────────┬─────────────────────┤
│   技術 SEO       │   內容 SEO      │    站外 SEO          │
│                 │                 │                     │
│ • 網站架構       │ • 關鍵字研究      │ • 反向連結           │
│ • 速度優化       │ • 內容品質        │ • 品牌提及           │
│ • 行動優先       │ • 使用者意圖      │ • 社群訊號           │
│ • 爬蟲優化       │ • 標題優化        │ • 本地 SEO          │
└─────────────────┴─────────────────┴─────────────────────┘

為什麼 SEO 重要？

搜尋引擎運作原理

三個核心階段

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   爬取       │ ──> │   索引      │ ──> │   排名       │
│  Crawling   │     │  Indexing   │     │  Ranking    │
└─────────────┘     └─────────────┘     └─────────────┘
     │                    │                    │
     v                    v                    v
 搜尋引擎派出        分析頁面內容         根據演算法
 爬蟲抓取網頁        建立搜尋索引         決定排名順序

1. 爬取（Crawling）

搜尋引擎爬蟲（Googlebot）透過連結發現和抓取網頁。

影響爬取的因素：

• robots.txt - 告訴爬蟲可以/不可以抓取的頁面
• sitemap.xml - 提供網站所有頁面清單
• 內部連結結構 - 決定爬蟲能否發現所有頁面
• 爬取預算（Crawl Budget）- 大型網站需特別注意

2. 索引（Indexing）

搜尋引擎分析頁面內容，決定是否加入索引資料庫。

影響索引的因素：

• 內容品質和獨特性
• noindex 標籤
• Canonical URL
• 重複內容問題

3. 排名（Ranking）

根據數百個排名因素，決定搜尋結果的順序。

主要排名因素：

• 內容相關性
• 頁面權重（PageRank）
• 使用者體驗（Core Web Vitals）
• 行動裝置友善度
• HTTPS 安全性

技術 SEO

robots.txt 設定

# /robots.txt

# 允許所有爬蟲
User-agent: *

# 禁止爬取的路徑
Disallow: /admin/
Disallow: /api/
Disallow: /private/
Disallow: /*?*sort=
Disallow: /*?*filter=

# 允許爬取的路徑（覆蓋上層禁止規則）
Allow: /api/public/

# Sitemap 位置
Sitemap: https://example.com/sitemap.xml

sitemap.xml 範例

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2025-12-17</lastmod>
    <changefreq>daily</changefreq>
    <priority>1.0</priority>
  </url>
  <url>
    <loc>https://example.com/about</loc>
    <lastmod>2025-12-15</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
  </url>
  <url>
    <loc>https://example.com/blog/seo-guide</loc>
    <lastmod>2025-12-17</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.9</priority>
  </url>
</urlset>

Sitemap Index（大型網站）

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-pages.xml</loc>
    <lastmod>2025-12-17</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-posts.xml</loc>
    <lastmod>2025-12-17</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2025-12-16</lastmod>
  </sitemap>
</sitemapindex>

單一 sitemap 限制：5 萬 URL 或 50MB（壓縮後），超過必須切分用 sitemap index。

Sitemap 維護策略（lastModified）

錯誤做法 1：每次部署都 bump 全站 lastmod

// ❌ 大量教學會這樣寫
{ url: ..., lastModified: new Date() }  // 每個 URL 都用「現在」

問題：每次部署 Google 都看到「全站同時更新」 → 訊號被忽略，甚至被視為操弄。

錯誤做法 2：用 git timestamp 自動產生

// ❌ 看似聰明但有坑
const lastMod = execSync(`git log -1 --format=%ai -- ${file}`);

問題：

• 多數 CI / 雲端建置環境用 shallow clone（--depth=1），git log 拿不到真實提交日期
• 純樣式 refactor 也會 bump → 假訊號
• build 速度被拖慢

✅ 推薦做法：手動維護

把 lastMod 當成內容的 metadata，跟著內容寫進 registry / frontmatter：

// registry / config
export const POSTS = [
  {
    slug: "seo-guide",
    title: "SEO 完全指南",
    lastMod: "2026-04-10",  // 內容上次實質更新
  },
  // ...
];

維護準則：

邏輯：lastMod 是「訊號」，過度使用會貶值。手動維護累一點，但 Google 更信任。

Hub 頁面的 lastModified 推播

問題：首頁、分類頁這種「列表頁」自己沒內容，但子項目更新時要不要 bump？

做法：取所有子項目的 max(lastMod) 當 hub 的 lastMod。

// 範例：首頁是所有工具的 hub
const allTools = [...];
const homeLastMod = allTools.reduce(
  (max, t) => (t.lastMod > max ? t.lastMod : max),
  "1970-01-01"
);

return [
  {
    url: "https://example.com",
    lastModified: new Date(homeLastMod),
    changeFrequency: "weekly",
    priority: 1.0,
  },
  // ... 各工具自己的 URL
];

這樣 hub 頁的「新鮮度」會跟著子項目自動更新，但不會像「每次部署 bump」那樣造成全站假訊號。

priority 與 changeFrequency 怎麼設

注意：Google 自 2023 起公開表示忽略 priority 與 changeFrequency，但 Bing / Yandex / 其他爬蟲仍會參考。仍建議設定（沒成本）。

URL 結構最佳化

✅ 推薦的 URL 結構
https://example.com/blog/seo-complete-guide
https://example.com/products/iphone-15-pro

❌ 不推薦的 URL 結構
https://example.com/blog?id=12345
https://example.com/p/a/b/c/d/e/page
https://example.com/產品/手機  （避免中文 URL）

URL 最佳化原則：

Canonical URL

處理重複內容，告訴搜尋引擎哪個是「正版」頁面。

<!-- 在 <head> 中設定 -->
<link rel="canonical" href="https://example.com/products/phone" />

<!-- 常見需要 canonical 的情況 -->
<!-- 1. HTTP/HTTPS 版本 -->
<!-- 2. www/non-www 版本 -->
<!-- 3. 帶參數的 URL（排序、篩選）-->
<!-- 4. 分頁內容 -->

行動裝置優先

Google 使用 Mobile-First Indexing，以行動版內容為主要索引依據。

<!-- 響應式設計的 viewport 設定 -->
<meta name="viewport" content="width=device-width, initial-scale=1.0" />

<!-- 避免使用 Flash -->
<!-- 確保點擊目標足夠大（至少 48x48px）-->
<!-- 文字大小至少 16px -->

HTTPS 安全性

✅ HTTPS 優點
- Google 排名因素之一
- 使用者信任感
- 保護資料傳輸
- 可使用 HTTP/2 提升效能

🔧 實作重點
- 設定 301 重導向（HTTP → HTTPS）
- 更新內部連結為 HTTPS
- 更新 sitemap 和 canonical URL
- 檢查混合內容（Mixed Content）

站內 SEO（On-Page SEO）

HTML 標籤優化

Title 標籤

<!-- 最重要的 SEO 標籤 -->
<title>SEO 完全指南：2025 年最新技術與策略 | 網站名稱</title>

<!-- Title 最佳化原則 -->
<!-- 1. 長度：50-60 字元（約 25-30 中文字）-->
<!-- 2. 關鍵字放前面 -->
<!-- 3. 每頁獨特標題 -->
<!-- 4. 包含品牌名稱（放後面）-->

Title 公式：

主要關鍵字 + 次要關鍵字 + 品牌名稱
─────────────────────────────────
SEO 教學：完整入門指南 | Example

Meta Description

<meta name="description" content="學習 SEO 搜尋引擎優化的完整指南，
涵蓋技術 SEO、內容優化、站內站外 SEO 策略。從基礎到進階，
幫助你的網站在 Google 搜尋結果中獲得更好的排名。" />

<!-- Meta Description 最佳化原則 -->
<!-- 1. 長度：120-160 字元（約 60-80 中文字）-->
<!-- 2. 包含目標關鍵字 -->
<!-- 3. 吸引點擊的文案 -->
<!-- 4. 每頁獨特描述 -->
<!-- 5. 包含行動呼籲（CTA）-->

標題階層（H1-H6）

<!-- 正確的標題結構 -->
<h1>SEO 完全指南</h1>                    <!-- 每頁只有一個 H1 -->
  <h2>什麼是 SEO？</h2>                  <!-- 主要章節 -->
    <h3>SEO 的定義</h3>                  <!-- 子章節 -->
    <h3>為什麼 SEO 重要</h3>
  <h2>技術 SEO</h2>
    <h3>網站速度優化</h3>
      <h4>圖片優化</h4>                  <!-- 更細的分類 -->
      <h4>程式碼優化</h4>

<!-- ❌ 錯誤示範 -->
<h1>標題一</h1>
<h1>標題二</h1>                          <!-- 不應有多個 H1 -->
<h3>跳過 H2 直接用 H3</h3>               <!-- 不應跳級 -->

圖片 SEO

<!-- 完整的圖片 SEO 優化 -->
<img
  src="seo-guide-infographic.webp"
  alt="SEO 優化流程圖：包含技術、內容、站外三大步驟"
  title="SEO 完整流程圖"
  width="800"
  height="600"
  loading="lazy"
/>

<!-- 圖片優化檢查清單 -->
<!-- ✅ 描述性檔名：seo-guide.webp 而非 img001.jpg -->
<!-- ✅ Alt 文字：描述圖片內容，自然包含關鍵字 -->
<!-- ✅ 壓縮圖片：使用 WebP 格式 -->
<!-- ✅ 指定尺寸：避免 CLS（版面位移）-->
<!-- ✅ Lazy Loading：延遲載入非首屏圖片 -->

內部連結策略

內部連結結構示意圖

         ┌─────────┐
         │  首頁    │
         └────┬────┘
              │
    ┌─────────┼─────────┐
    │         │         │
┌───┴───┐ ┌───┴───┐ ┌───┴───┐
│分類頁A │ │分類頁B │ │分類頁C │
└───┬───┘ └───┬───┘ └───┬───┘
    │         │         │
  ┌─┴─┐     ┌─┴─┐     ┌─┴─┐
  │文章│←───→│文章│←──→│文章│  ← 相關文章互相連結
  └───┘     └───┘     └───┘

內部連結最佳實踐：

URL 與內部連結策略

Canonical URL 維護細節

Canonical 看似簡單，但實務上有多個面向要決定：

1. 相對 vs 絕對路徑

<!-- ❌ 寫死絕對 URL — 預覽部署 / 多環境會出錯 -->
<link rel="canonical" href="https://example.com/about" />

<!-- ✅ 用相對路徑或框架的 base URL 機制 -->
<link rel="canonical" href="/about" />

為什麼：

• 預覽環境（如 PR preview）URL 不同，硬寫會把 canonical 指到正式站
• 多環境部署（dev / staging / prod）共用同一份程式碼
• 多數現代框架都支援設一個 base URL，子頁用相對路徑會自動展開

2. Trailing slash 處理

https://example.com/about
https://example.com/about/

這是兩個不同的 URL。Google 會視為重複內容（除非 canonical 指向同一個）。

選一邊堅持：

• 多數現代靜態站省略 trailing slash（/about）
• 老 CMS / WordPress 預設帶 trailing slash（/about/）

伺服器層強制統一（在 reverse proxy 或 web server 設 301）：

# 概念：把帶 slash 的 URL 301 redirect 到不帶 slash 的版本
GET /about/   →   301 → /about
GET /about    →   200

各家 web server（Nginx / Apache / Caddy）或框架都有對應寫法，重點是整站只接受一種形式。

3. Query Params 與 Tracking Params

/products?sort=price       ← 真實的排序頁
/products?utm_source=fb    ← 追蹤參數
/products?session=xxx      ← 不該被索引

處理原則：

<!-- /products?utm_source=fb 頁面 -->
<link rel="canonical" href="/products" />

4. 子網域 / 主域選擇

www.example.com vs example.com
m.example.com（行動版）vs 響應式單一網址

• www vs naked：選一邊堅持，另一邊 301 過去
• m.* 行動子網域：已過時，現代用響應式即可

內部連結結構：Hub-and-Spoke

把網站想像成樞紐（hub）+ 輻條（spoke）：

                    首頁（hub）
                   /    |    \
              分類頁  分類頁  分類頁
              /  |  \   |     \
           文章1 文章2 文章3 文章4
              \  |  /   |     /
               相關文章彼此互鏈

設計原則：

1. 首頁是最大 hub：傳遞權重給所有分類
2. 分類頁是中型 hub：列出該主題所有文章
3. 內容頁彼此互鏈：用「相關文章」「延伸閱讀」做 spoke-to-spoke
4. 層級不超過 3 層：首頁 → 分類 → 內容，深於 3 層的爬蟲很少抓

自動產生「相關文章」區塊

實用模式：每篇文章底部自動列同分類 / 同 tag 的其他文章。

選文邏輯（虛擬碼）：

取得所有文章
排除：當前這篇
篩選：有共同 tag 或同分類
排序：交集 tag 數量多的優先 / 最近更新優先
取前 N 篇（通常 3-5 篇）

呈現範例：

<section>
  <h2>相關文章</h2>
  <ul>
    <li><a href="/posts/seo-checklist">SEO 上線前檢查清單</a></li>
    <li><a href="/posts/structured-data-tips">結構化資料常見錯誤</a></li>
    <li><a href="/posts/canonical-deep-dive">Canonical 深入解析</a></li>
  </ul>
</section>

SEO 訊號：

• 增加每頁的內部連結數（提升網狀結構強度）
• 用主題 tag 連結 → Google 看出語意關聯
• 降低跳出率（使用者有後續閱讀去處）

Tag 頁面與分類頁

好的 tag 頁：

/tags/seo  → 列出所有 #seo 文章 + 標題 + 摘要

每個 tag 頁本身可以是排名目標（鎖定該 tag 的長尾關鍵字）。

陷阱：tag 過多 / 重複 / 重疊會產生薄內容頁（每頁只有 1-2 篇文章）。建議：

• 控制 tag 總數（< 50 個）
• 至少有 3 篇文章才產生 tag 頁
• 同義 tag 合併（seo 與 搜尋引擎優化）

URL Migration 與 301 Redirect

改 URL 結構（如把 /blog/xxx 改成 /articles/xxx）會踩到 SEO 雷區。

為什麼有影響：

• 舊 URL 累積的反向連結會斷
• Google 索引的舊 URL 變 404 → 排名掉
• 使用者書籤失效

正確做法：

對所有舊 URL 設 301 Permanent Redirect 指向對應新 URL。

舊 URL                          新 URL
GET /blog/seo-guide      →      301 → /articles/seo-guide
GET /blog/react-hooks    →      301 → /articles/react-hooks

實作層級可選：

何時用 302（暫時）vs 301（永久）：

Google 對 301 會傳遞「絕大部分」反向連結權重，對 302 則不傳遞。確定永久就用 301。

何時可以接受 404（不設 redirect）

不是所有 URL 改動都要 redirect。接受 404 的情境：

• 該 URL 流量極低（Search Console 看月曝光 < 50）
• 該 URL 未被 Google 索引 或反向連結 = 0
• 該舊 URL 內容已下架（不該存在於新站）

優點：少維護一條 redirect 規則。缺點：短期該 URL 排名掉、可能丟掉 0.x% 流量。

判斷流程：

舊 URL 流量 / 索引狀態？
├─ 流量明顯 / 有反向連結 → 必須 301
├─ 流量低 + 內容仍在新位址 → 建議 301（成本低）
└─ 流量幾乎 0 + 內容下架 → 可接受 404

內部連結錨文字策略

❌ 不夠描述性
<a href="/seo-guide">點此</a>查看完整教學
<a href="/seo-guide">這篇文章</a>

✅ 含關鍵字 + 描述性
查看完整的 <a href="/seo-guide">SEO 教學指南</a>
深入了解 <a href="/seo-guide">技術 SEO 與內容優化策略</a>

⚠️ 完全相同錨文字過度使用會被視為操弄
（同一目標 URL 的內鏈不要全部用 "SEO 教學" 當錨文字）

自然多樣化：同一個目標 URL 用 3-5 種不同錨文字，模擬真實寫作。

內容優化

關鍵字研究

關鍵字類型

┌─────────────────────────────────────────────────────────┐
│                    關鍵字類型金字塔                        │
├─────────────────────────────────────────────────────────┤
│                                                         │
│                    ┌───────────┐                        │
│                    │ 短尾關鍵字  │  流量高、競爭大          │
│                    │   "SEO"   │  轉換率低               │
│                    └─────┬─────┘                        │
│                 ┌────────┴────────┐                     │
│                 │   中尾關鍵字      │  流量中等            │
│                 │  "SEO 教學"      │  競爭中等            │
│                 └────────┬────────┘                     │
│         ┌────────────────┴────────────────┐             │
│         │         長尾關鍵字                │  流量低      │
│         │  "2025 SEO 入門教學 新手指南"      │  競爭小      │
│         │                                 │  轉換率高     │
│         └─────────────────────────────────┘             │
└─────────────────────────────────────────────────────────┘

搜尋意圖類型

內容品質標準（E-E-A-T）

Google 評估內容品質的標準：

E-E-A-T 框架

┌─────────────────────────────────────────┐
│  E - Experience（經驗）                  │
│  作者是否有實際經驗？                      │
├─────────────────────────────────────────┤
│  E - Expertise（專業）                   │
│  作者是否具備專業知識？                     │
├─────────────────────────────────────────┤
│  A - Authoritativeness（權威性）          │
│  網站和作者是否被認可？                     │
├─────────────────────────────────────────┤
│  T - Trustworthiness（可信度）            │
│  內容是否準確可信？                        │
└─────────────────────────────────────────┘

提升 E-E-A-T 的方法：

• 作者簡介頁面
• 引用權威來源
• 定期更新內容
• 使用者評價和社會證明
• HTTPS 和隱私政策

內容結構優化

# 完整的內容結構範本

## 引言（Hook）
- 吸引讀者注意
- 說明文章價值
- 預告主要內容

## 目錄（Table of Contents）
- 方便快速導航
- 提升使用者體驗
- 可能出現在搜尋結果

## 正文內容
- 使用標題階層（H2、H3）
- 短段落（2-4 行）
- 條列式清單
- 圖表輔助說明
- 內部連結至相關文章

## 結論（Summary）
- 總結重點
- 行動呼籲（CTA）
- 相關推薦

## FAQ（常見問題）
- 針對長尾關鍵字
- 有機會出現在精選摘要

站外 SEO（Off-Page SEO）

反向連結（Backlinks）

反向連結是其他網站連結到你的網站，是重要的排名因素。

連結品質評估

高品質連結特徵：
┌────────────────────────────────────────┐
│ ✅ 來自高權重網站（DA/DR 高）             │
│ ✅ 與你的內容主題相關                     │
│ ✅ Dofollow 連結                        │
│ ✅ 自然的錨文字                          │
│ ✅ 來自內容區域（非頁尾、側邊欄）           │
│ ✅ 來自獨立 IP 的不同網站                 │
└────────────────────────────────────────┘

低品質/有害連結特徵：
┌────────────────────────────────────────┐
│ ❌ 來自垃圾網站或連結農場                  │
│ ❌ 購買的連結                            │
│ ❌ 過度優化的錨文字                       │
│ ❌ 與主題完全無關的連結                    │
│ ❌ 全站連結（Sitewide Links）            │
└────────────────────────────────────────┘

建立連結策略

品牌提及

即使沒有連結，品牌提及也是排名信號之一。

品牌提及監控：
- Google Alerts 設定品牌關鍵字提醒
- 使用社群監聽工具
- 定期搜尋品牌名稱
- 將無連結提及轉換為連結

社群訊號

雖然社群訊號不是直接排名因素，但間接影響 SEO：

社群對 SEO 的間接影響：
┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│ 社群分享     │ ──> │ 更多曝光      │ ──> │ 自然連結     │
└─────────────┘     └─────────────┘     └─────────────┘
                           │
                           v
                    ┌─────────────┐
                    │ 品牌知名度  │
                    └─────────────┘

Core Web Vitals

Google 的使用者體驗指標，是排名因素之一。

三大核心指標

┌─────────────────────────────────────────────────────────┐
│                  Core Web Vitals                        │
├─────────────────┬─────────────────┬─────────────────────┤
│      LCP        │      INP        │       CLS           │
│ Largest         │ Interaction to  │ Cumulative Layout   │
│ Contentful      │ Next Paint      │ Shift               │
│ Paint           │                 │                     │
├─────────────────┼─────────────────┼─────────────────────┤
│ 最大內容繪製      │ 互動延遲         │ 累積版面位移          │
│ 載入效能         │ 互動效能         │ 視覺穩定性            │
├─────────────────┼─────────────────┼─────────────────────┤
│ 良好: ≤2.5s     │ 良好: ≤200ms     │ 良好: ≤0.1           │
│ 需改善: ≤4s      │ 需改善: ≤500ms   │ 需改善: ≤0.25        │
│ 差: >4s         │ 差: >500ms       │ 差: >0.25           │
└─────────────────┴─────────────────┴─────────────────────┘

優化建議

LCP 優化

<!-- 預載入關鍵資源 -->
<link rel="preload" as="image" href="hero-image.webp" />
<link rel="preload" as="font" href="font.woff2" crossorigin />

<!-- 優化伺服器回應時間 -->
<!-- 使用 CDN -->
<!-- 圖片壓縮和 WebP 格式 -->
<!-- 延遲載入非關鍵 CSS/JS -->

INP 優化

// 分割長任務
function processData(items) {
  // ❌ 不好：長時間阻塞
  items.forEach(item => heavyOperation(item));

  // ✅ 好：使用 requestIdleCallback 分批處理
  function processChunk(startIndex) {
    requestIdleCallback((deadline) => {
      while (deadline.timeRemaining() > 0 && startIndex < items.length) {
        heavyOperation(items[startIndex]);
        startIndex++;
      }
      if (startIndex < items.length) {
        processChunk(startIndex);
      }
    });
  }
  processChunk(0);
}

CLS 優化

<!-- 為圖片指定尺寸 -->
<img src="image.jpg" width="800" height="600" alt="..." />

<!-- 為廣告/嵌入內容預留空間 -->
<div style="min-height: 250px;">
  <!-- 廣告內容 -->
</div>

<!-- 避免在現有內容上方插入內容 -->
<!-- 使用 transform 動畫而非改變 top/left -->

結構化資料

使用 Schema.org 標記幫助搜尋引擎理解內容。

JSON-LD 格式範例

文章標記

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "SEO 完全指南：2025 年最新技術與策略",
  "description": "學習 SEO 搜尋引擎優化的完整指南",
  "image": "https://example.com/images/seo-guide.jpg",
  "author": {
    "@type": "Person",
    "name": "作者名稱",
    "url": "https://example.com/author"
  },
  "publisher": {
    "@type": "Organization",
    "name": "網站名稱",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2025-12-17",
  "dateModified": "2025-12-17"
}
</script>

FAQ 標記

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "什麼是 SEO？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "SEO（Search Engine Optimization）是搜尋引擎優化的縮寫，透過優化網站內容和技術架構，提升網站在搜尋結果中的排名。"
      }
    },
    {
      "@type": "Question",
      "name": "SEO 需要多久才能看到效果？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "一般來說，SEO 需要 3-6 個月才能看到明顯效果。這取決於網站現況、競爭程度和執行的策略。"
      }
    }
  ]
}
</script>

產品標記

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "SEO 工具 Pro",
  "description": "專業的 SEO 分析工具",
  "image": "https://example.com/product.jpg",
  "brand": {
    "@type": "Brand",
    "name": "Example"
  },
  "offers": {
    "@type": "Offer",
    "price": "99.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "100"
  }
}
</script>

常用結構化資料類型

Multi-Schema 並用策略

實務上一個頁面通常會放多種 schema，分別代表不同實體：

範例：一個技術文章頁的完整 schema 套組

<head>
  <!-- 1. WebSite + SearchAction（繼承自 root layout） -->
  <script type="application/ld+json">{...WebSiteSchema}</script>

  <!-- 2. TechArticle 主體 -->
  <script type="application/ld+json">{...TechArticleSchema}</script>

  <!-- 3. BreadcrumbList 麵包屑 -->
  <script type="application/ld+json">{...BreadcrumbSchema}</script>

  <!-- 4. FAQPage 若內文有 FAQ 區塊 -->
  <script type="application/ld+json">{...FAQSchema}</script>
</head>

多個 schema 並存無衝突，Google / Bing 會各自挑用所需。

WebSite 與站內搜尋框（SearchAction）

讓 Google 搜尋結果直接顯示「站內搜尋框」，輸入後可直接搜該站。

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "url": "https://example.com",
  "name": "我的工具站",
  "potentialAction": {
    "@type": "SearchAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://example.com/search?q={search_term_string}"
    },
    "query-input": "required name=search_term_string"
  }
}

呈現效果：搜尋結果第一條會帶一個輸入框，鍵入後跳到站內搜尋頁。

前提：

• 站內必須真的有 /search?q=... 這條路由
• 通常用在站台首頁，搜尋結果頁會出現 Sitelinks Searchbox

WebApplication（給線上工具）

如果你的網站是「線上工具」性質（如 QR Code 產生器、JSON 格式化），用 WebApplication：

{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "QR Code 產生器",
  "description": "免費線上產生 QR Code 圖片",
  "url": "https://example.com/qrcode",
  "applicationCategory": "UtilitiesApplication",
  "operatingSystem": "Any",
  "browserRequirements": "Requires JavaScript. Requires HTML5.",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  }
}

applicationCategory 常見值：UtilitiesApplication（工具）、GameApplication（遊戲）、BusinessApplication、MultimediaApplication、SecurityApplication。

BreadcrumbList 雙寫模式

重要原則：麵包屑要同時寫兩份 — 一份是給爬蟲的 schema，一份是給使用者看的 HTML。

// ❌ 只寫 schema 不寫 HTML — 失去使用者導航價值
<script type="application/ld+json">{breadcrumbSchema}</script>

// ❌ 只寫 HTML 不寫 schema — Google 不會用麵包屑取代 URL
<nav aria-label="麵包屑">
  <a href="/notes">筆記</a> &gt;
  <a href="/notes/web">Web</a> &gt;
  SEO 完全指南
</nav>

// ✅ 雙寫：兩者都要
<nav aria-label="麵包屑">
  <ol>
    <li><a href="/notes">筆記</a></li>
    <li><a href="/notes/web">Web</a></li>
    <li>SEO 完全指南</li>
  </ol>
</nav>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "筆記", "item": "https://example.com/notes" },
    { "@type": "ListItem", "position": 2, "name": "Web", "item": "https://example.com/notes/web" },
    { "@type": "ListItem", "position": 3, "name": "SEO 完全指南" }
  ]
}
</script>

好處：

• HTML 麵包屑 → 使用者體驗 + 內部連結（往上回到分類頁的內鏈訊號）
• Schema 麵包屑 → Google 搜尋結果用麵包屑取代 URL 顯示（更易讀）

結構化資料的常見錯誤

驗證工具

• 官方 Rich Results 測試：https://search.google.com/test/rich-results
• Schema Markup Validator：https://validator.schema.org/
• Google Search Console → 強化項目：上線後監看實際被識別與錯誤

SEO 工具

免費工具

付費工具

Google Search Console 重點功能

Google Search Console 必看報告：

1. 成效報告（Performance）
   - 曝光次數、點擊次數
   - 平均排名、點擊率（CTR）
   - 依查詢、頁面、國家等維度分析

2. 涵蓋範圍（Coverage / Indexing）
   - 有效頁面數
   - 錯誤和警告
   - 排除原因

3. 體驗（Experience）
   - Core Web Vitals
   - 行動裝置可用性
   - HTTPS

4. 連結（Links）
   - 外部連結來源
   - 內部連結結構
   - 最常見的錨文字

最佳實踐

SEO 檢查清單

技術面

• robots.txt 設定正確
• sitemap.xml 已提交
• HTTPS 已啟用
• 行動裝置友善
• 頁面載入速度 < 3 秒
• 無重複內容問題
• Canonical URL 設定
• 404 頁面處理

內容面

• Title 標籤優化（50-60 字元）
• Meta Description 優化（120-160 字元）
• H1 標籤每頁一個
• 標題階層正確（H1 > H2 > H3）
• 圖片有 Alt 文字
• 內部連結策略
• 內容定期更新

站外面

• Google Search Console 已設定
• Google Analytics 已設定
• 社群媒體頁面
• 品牌一致性

常見錯誤避免

❌ 常見 SEO 錯誤

1. 關鍵字堆砌（Keyword Stuffing）
   錯誤：「SEO SEO 教學 SEO 入門 SEO 指南 SEO 課程」
   正確：自然地將關鍵字融入內容

2. 隱藏文字
   錯誤：白色背景配白色文字塞關鍵字
   正確：所有內容對使用者可見

3. 購買連結
   錯誤：付費購買大量低品質連結
   正確：透過優質內容自然獲得連結

4. 重複內容
   錯誤：複製貼上其他網站內容
   正確：創造原創、有價值的內容

5. 忽略行動裝置
   錯誤：只優化桌面版網站
   正確：行動裝置優先設計

6. 過度優化錨文字
   錯誤：所有連結都用「SEO 教學」
   正確：錨文字多樣化、自然

常見問題

SEO 需要多久才能看到效果？

答案：通常需要 3-6 個月。影響因素包括：

• 網站年齡和現有權重
• 競爭程度
• 內容品質和更新頻率
• 技術問題修復速度

SEO 和 SEM 有什麼不同？

要如何選擇關鍵字？

關鍵字選擇考量：

1. 搜尋量（Search Volume）
   - 有足夠的搜尋需求

2. 關鍵字難度（Keyword Difficulty）
   - 符合網站現有權重

3. 搜尋意圖（Search Intent）
   - 與你的內容/產品匹配

4. 商業價值
   - 能帶來轉換的關鍵字

建議策略：
新網站 → 先攻長尾關鍵字（低競爭）
成熟網站 → 可挑戰中短尾關鍵字

內容長度對 SEO 有影響嗎？

答案：內容長度本身不是排名因素，但長內容通常：

• 涵蓋更完整的資訊
• 獲得更多反向連結
• 停留時間較長

建議：依主題需求決定長度，確保內容完整且有價值。

總結

核心要點

SEO 成功關鍵：

1. 技術基礎
   - 確保網站可被爬取和索引
   - 優化網站速度
   - 行動裝置友善

2. 優質內容
   - 滿足使用者搜尋意圖
   - E-E-A-T 原則
   - 定期更新

3. 使用者體驗
   - Core Web Vitals
   - 清晰的網站架構
   - 直覺的導航

4. 權威建立
   - 高品質反向連結
   - 品牌知名度
   - 社群經營

SEO 優先順序

SEO 執行優先順序：

第一優先（基礎）
├─ 技術 SEO 健檢
├─ Google Search Console 設定
└─ 修復爬取和索引問題

第二優先（內容）
├─ 關鍵字研究
├─ 內容優化
└─ Title 和 Meta Description

第三優先（體驗）
├─ 網站速度優化
├─ Core Web Vitals
└─ 行動裝置優化

第四優先（權威）
├─ 內部連結優化
├─ 反向連結建立
└─ 品牌經營

快速參考

建立日期：2025-12-17 最後更新：2025-12-17