以下內容為基於該篇「IQ test …」文章及其前言 Front Matter（Jekyll 格式）所能萃取且可延伸為實戰教學的問題解決案例。說明：原文並未提供大量「完整問題—根因—解法—成效」的技術案例；因此以下案例以文中可觀察的實體設定（如 redirect_from、wordpress_postid、comments、外部圖片與連結等）、內容特徵（中英混寫、百分位敘述）為依據，設計為可實作的教學型案例。若原文無提供成效數據，將以「示範專案」的參考實測或可量化目標呈現，並明確註記。

Case #1: WordPress → Jekyll 遷移後的舊網址保留（redirect_from）

Problem Statement（問題陳述）

業務場景：網站從舊 CMS（如 WordPress）遷移至 Jekyll 靜態站，需保留歷史外部連結與 SEO 積累。該文的 Front Matter 顯示多條 redirect_from（多歷史路徑），反映真實遷移場景：同一文章曾有多個舊網址。若不處理，將導致大量 404、搜尋排名下滑、外部推薦失效。
技術挑戰：在靜態站中實作大量 301 轉址；維護映射表；避免循環重定向；在 CI/CD 中驗證轉址健康。
影響範圍：SEO 流量、使用者體驗、內容可得性、外部導流成效。
複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：
1. URL 結構改變：WP 與 Jekyll 的永久連結格式不同。
2. 多歷史路徑：文章歷史上多次更名與搬家（文中列出 6+ 條 redirect_from）。
3. 靜態站沒有動態路由：需在構建期間生成對應規則。
深層原因：
- 架構層面：無集中式路由層，不易動態處理所有歷史 URL。
- 技術層面：未使用 redirect 外掛或缺乏映射資料來源。
- 流程層面：缺少遷移前 URL 盤點與自動化驗證流程。

Solution Design（解決方案設計）

解決策略：使用 jekyll-redirect-from 在 Front Matter 寫入舊路徑映射，配合一份舊→新 URL 表自動生成映射與 301 測試，並在 CI 持續驗證。
實施步驟：
1. 舊網址盤點
  - 實作細節：從舊站資料庫/站台地圖/日誌匯出 URL；清洗重複與非 200 頁。
  - 所需資源：Screaming Frog、WP 匯出、log 分析。
  - 預估時間：4-8 小時。
2. 批次產生 redirect_from
  - 實作細節：撰寫腳本將舊→新對應寫入各 Markdown 的 Front Matter。
  - 所需資源：Python/Node 腳本。
  - 預估時間：4 小時。
3. 自動化驗證
  - 實作細節：CI 使用 curl/lychee 檢查 301/200 與避免 302/循環。
  - 所需資源：GitHub Actions。
  - 預估時間：2 小時。
關鍵程式碼/設定： ```yaml
_config.yml

plugins:
- jekyll-redirect-from

某篇文章 Front Matter（示意）

title: “IQ test …” redirect_from:

/2006/11/15/iq-test/
/post/IQ-test-.aspx/
/blogs/chicken/archive/2006/11/15/1947.aspx/

```
實際案例：本文 Front Matter 即出現多條 redirect_from，代表此解法已在該站採用。
實作環境：Jekyll 4.x、Ruby 3.x、GitHub Actions。
實測數據（示範專案）：改善前 404 率 12.3%；改善後 0.9%；改善幅度 92.7%。

Learning Points（學習要點）

核心知識點：
- jekyll-redirect-from 的使用與限制
- 301/302/307 差異與 SEO 影響
- 遷移專案的 URL 盤點方法
技能要求：
- 必備技能：YAML、Jekyll 基礎、HTTP 狀態碼
- 進階技能：CI 驗證、log 分析與自動測試
延伸思考：
- 如何集中管理全站 redirect 規則？
- 如何避免鏈式重定向（多跳）？
- 是否需要在 CDN/邊緣層實作更高效的重定向？
Practice Exercise：
- 基礎：為 5 篇文章加上 2 條舊路徑並手動測試 301（30 分鐘）
- 進階：寫腳本批次產生 redirect_from 並輸出測試報告（2 小時）
- 專案：完成 WordPress→Jekyll 遷移含全站 301 驗證（8 小時）
Assessment Criteria：
- 功能完整性（40%）：301 正確、無循環、舊 URL 覆蓋率
- 程式碼品質（30%）：腳本結構、可維護性、記錄完善
- 效能優化（20%）：驗證速度、並行測試
- 創新性（10%）：可視化報表、CI 報錯回饋機制

Case #2: WordPress 內容與 metadata 自動轉換為 Jekyll Front Matter

Problem Statement

業務場景：從 WP 匯出文章（含 wordpress_postid、分類、標籤、發佈狀態）並轉成 Jekyll Markdown。本文 Front Matter 中的 wordpress_postid、tags、categories 顯示該需求真實存在。
技術挑戰：從 WXR/XML/DB 準確抽取欄位、轉換為 YAML Front Matter、處理 slug/日期/編碼差異。
影響範圍：遷移效率、資料正確性、後續 SEO 與導覽。
複雜度評級：中

Root Cause Analysis

直接原因：
1. 系統資料格式差異（WP WXR vs Jekyll Markdown）
2. Metadata 分散且不一致
3. 圖片與內部連結需調整
深層原因：
- 架構：動態 CMS → 靜態站，資料存取模式不同
- 技術：缺少標準化轉換工具
- 流程：無自動驗證遷移結果的流程

Solution Design

解決策略：撰寫轉換器將 WXR 解析成 Markdown + Front Matter；內文連結正規化；輸出遷移報告。
實施步驟：
1. 解析 WXR
  - 細節：用 Python xmltodict 解析文章、分類、標籤
  - 資源：Python、xmltodict
  - 時間：4 小時
2. 產生 Markdown + Front Matter
  - 細節：映射 title/date/tags/categories/comments/published/wordpress_postid
  - 資源：Jinja2 模板
  - 時間：4 小時
3. 內文連結與圖片修補
  - 細節：相對路徑化/資產移轉
  - 資源：正則、測試集
  - 時間：4 小時
關鍵程式碼： ```python import xmltodict, yaml, re, os from datetime import datetime

def wp_to_jekyll(item): fm = { ‘title’: item[‘title’], ‘date’: datetime.strptime(item[‘wp:post_date’], ‘%Y-%m-%d %H:%M:%S’), ‘categories’: [c[‘#text’] for c in item.get(‘category’, []) if c.get(‘@domain’)==’category’], ‘tags’: [t[‘#text’] for t in item.get(‘category’, []) if t.get(‘@domain’)==’post_tag’], ‘comments’: True if item[‘wp:comment_status’]==’open’ else False, ‘published’: True if item[‘wp:status’]==’publish’ else False, ‘wordpress_postid’: int(item[‘wp:post_id’]) } content = item[‘content:encoded’] content = re.sub(r’http://oldsite.com’, ‘’, content) # 路徑標準化示例 return fm, content

- 實際案例：本文 Front Matter 顯示已保有 wordpress_postid。
- 實作環境：Python 3.10、Jekyll 4.x。
- 實測數據（示範專案）：人工遷移 100 篇需 20 小時；自動轉換降至 1.5 小時（含檢查），節省 92.5%。

Learning Points
- 核心知識點：WXR 結構、Front Matter 映射、路徑規則
- 必備技能：Python/XML、正則、Markdown
- 進階技能：資料驗證、自動化測試、報表輸出
- 延伸思考：如何處理自定義欄位與短代碼？如何追蹤遺漏或轉換失敗？
- Practice：基礎（轉換 10 篇）、進階（含圖片/連結修補）、專案（端到端遷移）
- Assessment：完整性、品質、效能、創新（可視化報告）

---

## Case #3: 靜態網站的留言系統整合（comments: true）

### Problem Statement
- 業務場景：Front Matter 設定 comments: true，但 Jekyll 不內建留言功能，需整合第三方（如 Disqus、Giscus）。
- 技術挑戰：條件式載入、隱私合規、腳本延遲載入避免阻塞渲染。
- 影響範圍：互動性、頁面速度、隱私法規。
- 複雜度：低

### Root Cause Analysis
- 直接原因：靜態站無伺服器端留言儲存機制；第三方服務策略差異。
- 深層原因：
  - 架構：前後端分離，需外部服務
  - 技術：沒有統一的 SDK 標準
  - 流程：缺乏隱私告知與同意流程

### Solution Design
- 解決策略：以 Liquid 條件式載入留言組件，支援多平台開關、GDPR 同意後載入。

- 實施步驟：
  1. 選型與開關
     - 細節：site.comments.provider 配置 giscus/disqus
     - 資源：Jekyll 設定
     - 時間：0.5 小時
  2. 模板整合
     - 細節：post.html 依 front matter 決定是否包含
     - 資源：Liquid
     - 時間：1 小時
  3. 延遲載入與同意
     - 細節：點擊同意後動態插入 script
     - 資源：JS
     - 時間：1 小時

- 關鍵程式碼：
```html
{% if page.comments and site.comments.provider == 'giscus' %}
<div id="comments"></div>
<script>
  // 使用者同意後再載入
  function loadComments() {
    const s = document.createElement('script');
    s.src = 'https://giscus.app/client.js';
    s.setAttribute('data-repo', 'user/repo');
    s.setAttribute('data-repo-id', '...');
    s.setAttribute('data-category', 'General');
    s.setAttribute('data-mapping', 'pathname');
    s.async = true;
    document.getElementById('comments').appendChild(s);
  }
</script>
<button onclick="loadComments()">同意並載入留言</button>
{% endif %}

實際案例：本文設有 comments: true。
實作環境：Jekyll、Giscus/Disqus。
實測數據（示範專案）：首屏 TTI 減少 18%，互動率提升 12%。

Learning Points：第三方整合、延遲載入、隱私提示技能：HTML/Liquid/JS；進階：同意管理（CMP）延伸：離線快取留言？自建後端？ Practice：基礎（加入 Giscus）、進階（GDPR 同意控管）、專案（多供應商開關） Assessment：功能（可用性）、品質（無阻塞）、效能（載入策略）、創新（體驗）

Case #4: 外部圖片熱鏈風險與鏡像備援

Problem Statement

業務場景：本文多張圖片來自外部域名（i.emode.com），長期有斷圖風險。
技術挑戰：批量下載、路徑更新、權限與版權、CDN 加速。
影響範圍：內容可視性、SEO、體驗。
複雜度：中

Root Cause Analysis

直接原因：外部圖源不受控，HTTP 非加密。
深層原因：
- 架構：靜態站缺乏資產管線
- 技術：無自動化鏡像腳本
- 流程：發佈前未做連結/資產健康檢查

Solution Design

解決策略：編寫腳本鏡像外部圖片至本地或物件儲存，統一以相對路徑引用並走 CDN。
實施步驟：
1. 掃描與下載
  - 細節：抓取 Markdown 中的外鏈圖片；failover 重試
  - 資源：Python requests、asyncio
  - 時間：2 小時
2. 路徑替換
  - 細節：更新文內 URL → /assets/img/…
  - 資源：正則
  - 時間：1 小時
3. 發佈與 CDN
  - 細節：上傳至 S3/Cloudflare R2，設 CDN
  - 資源：CLI/SDK
  - 時間：2 小時
關鍵程式碼： ```python import re, os, requests from pathlib import Path

def mirror_images(md_path): text = Path(md_path).read_text(encoding=’utf-8’) urls = re.findall(r’![[^]]*]((http[s]?://[^\s)]+))’, text) out_dir = Path(‘assets/img’) out_dir.mkdir(parents=True, exist_ok=True) for u in urls: fname = u.split(‘/’)[-1].split(‘?’)[0] p = out_dir/fname try: r = requests.get(u, timeout=10) r.raise_for_status() p.write_bytes(r.content) text = text.replace(u, f’/{p.as_posix()}’) except Exception as e: print(‘download fail’, u, e) Path(md_path).write_text(text, encoding=’utf-8’)

- 實際案例：本文圖片為外部連結，適合鏡像。
- 實作環境：Python 3.10、S3/CDN。
- 實測數據（示範）：斷圖率從 6%→<0.5%，LCP 改善 15%。

Learning Points：資產鏡像、相對路徑、CDN
技能：Python/HTTP；進階：CDN 快取策略
延伸：權限管理與授權標示？版本化資產？
Practice：基礎（鏡像單篇）、進階（全站批次）、專案（接入 CDN）
Assessment：完整性（鏡像成功率）、品質（路徑準確）、效能（載入）、創新（回滾機制）

---

## Case #5: 外部連結腐朽（Link Rot）檢測與存檔

### Problem Statement
- 業務場景：文中連到 http://web.tickle.com/...，多年後可能失效或改址。
- 技術挑戰：批量檢測、分類 4xx/5xx/timeout、提供 Wayback 或快照備援。
- 影響範圍：參考價值、用戶信任、SEO。
- 複雜度：中

### Root Cause Analysis
- 直接原因：外部站點改版、服務關閉、協定升級。
- 深層原因：
  - 架構：內容與外部資源耦合
  - 技術：無自動連結健康檢查
  - 流程：發佈後無持續監測

### Solution Design
- 解決策略：CI 週期性檢測外鏈，失效時自動加註存檔連結。

- 實施步驟：
  1. 連結掃描
     - 細節：使用 lychee/awesome_bot
     - 資源：GitHub Actions
     - 時間：1 小時
  2. 存檔查找
     - 細節：Wayback API 查快照
     - 資源：Wayback CDX API
     - 時間：1 小時
  3. 標記與替換
     - 細節：Markdown 後處理，加註「存檔連結」
     - 資源：Node/remark
     - 時間：2 小時

- 關鍵程式碼：
```yaml
# .github/workflows/link-check.yml
name: Link Check
on:
  schedule: [{cron: '0 3 * * 0'}]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: lycheeverse/lychee-action@v1
        with:
          args: --verbose --no-progress --max-concurrency 10 ./**/*.md

實際案例：本文含外鏈，具備實施價值。
實作環境：GitHub Actions、Node。
實測數據（示範）：失效外鏈覆蓋率 100%，附存檔成功率 85%，用戶回退可用性提升顯著。

Learning Points：連結健康、Wayback API、CI 定期任務技能：CI 基礎；進階：AST/remark 處理 Markdown 延伸：如何自建快照（自家存證）？如何分級警示？ Practice：基礎（掃描單 repo）、進階（自動 PR 標註存檔）、專案（可視化儀表板） Assessment：偵測準確、修復覆蓋、效能、創新（自動修復）

Case #6: 中英混排與多語 SEO（i18n/hreflang）

Problem Statement

業務場景：本文同時含中文敘述與英文測驗報告段落。需改善可讀性與多語搜尋可見度。
技術挑戰：語言屬性標註、雙語切換、hreflang、分語言路徑規劃。
影響範圍：讀者體驗、SEO、可維護性。
複雜度：中

Root Cause Analysis

直接原因：混排無語言屬性與結構化路徑。
深層原因：
- 架構：缺少 i18n 模組
- 技術：模板未考量 lang 屬性
- 流程：無多語發佈規範

Solution Design

解決策略：模板層提供 lang 屬性、支持 /zh/ /en/ 路徑與 hreflang，對內文英文區塊加 lang=”en”。
實施步驟：
1. 模板語言標註
  - 細節：html lang 由 site.lang 或 page.lang 控制
  - 資源：Liquid
  - 時間：1 小時
2. hreflang 與路徑規劃
  - 細節：建立對應語言版本與互連
  - 資源：配置規則
  - 時間：2 小時
3. 內文標註
  - 細節：英文段落 …
  - 資源：Markdown/HTML
  - 時間：1 小時
關鍵程式碼： ```html <!doctype html>

{% if page.alternate %} {% for alt in page.alternate %} {% endfor %} {% endif %}

中文段落

Your IQ score is 124

- 實際案例：本文中英混排，適用此法。
- 實作環境：Jekyll。
- 實測數據（示範）：英文關鍵字曝光+8%，跳出率 -6%。

Learning Points：lang/hreflang、路徑國際化
技能：HTML/Liquid；進階：多語內容治理
延伸：自動語言偵測？翻譯工作流？
Practice：基礎（lang 標註）、進階（hreflang 配置）、專案（雙語版面）
Assessment：語言標註正確、連結互通、SEO 指標、創新

---

## Case #7: 從 Markdown 文本抽取結構化百分位與分數

### Problem Statement
- 業務場景：本文描述數據（IQ=124、四個智能百分位），但以自然語言呈現。希望抽取為 JSON 以利分析/可視化。
- 技術挑戰：正則或 NLP 抽取、魯棒性、單位與範圍解析。
- 影響範圍：數據可用性、報表自動化。
- 複雜度：中

### Root Cause Analysis
- 直接原因：數據散落於段落文字與圖片替代文字。
- 深層原因：
  - 架構：無結構化資料層（如 front matter data）
  - 技術：缺少抽取規則
  - 流程：未規劃數據化輸出

### Solution Design
- 解決策略：撰寫抽取器，針對模式化句式與 alt 文案抽取百分位與得分。

- 實施步驟：
  1. 模式設計
     - 細節：定義 regex（e.g., "You scored in the (\d+)(?:th)? percentile on the (.+?) intelligence"）
     - 資源：測試集
     - 時間：1 小時
  2. 實作抽取
     - 細節：解析 Markdown，抽 alt 與正文
     - 資源：Python/remark
     - 時間：2 小時
  3. 匯出 JSON
     - 細節：標準 schema（score、category、percentile）
     - 資源：JSON Schema
     - 時間：1 小時

- 關鍵程式碼：
```python
import re, json, pathlib

text = pathlib.Path('post.md').read_text(encoding='utf-8')
iq = re.search(r'Your IQ score is (\d+)', text)
cats = re.findall(r'You scored in the (\d+)(?:th)? percentile on the ([A-Za-z\-]+) intelligence', text)

data = {'iq': int(iq.group(1)) if iq else None, 'categories': []}
for p, c in cats:
    data['categories'].append({'name': c, 'percentile': int(p)})

print(json.dumps(data, ensure_ascii=False, indent=2))

實際案例：本文提供完整句式與 alt 文案。
實作環境：Python 3.10。
實測數據（示範）：抽取精確率 100%（針對此文）；一般化語料需額外規則。

Learning Points：正則抽取、Markdown 解析、Schema 設計技能：Python/Regex；進階：NLP 正規化延伸：多語支援？圖片 OCR？ Practice：基礎（抽取 IQ 與 4 類百分位）、進階（多文批次抽取）、專案（抽取→可視化流水線） Assessment：抽取正確率、可維護性、效能、創新（自動校驗）

Case #8: 將抽取數據可視化（雷達圖/長條圖）

Problem Statement

業務場景：本文以圖片展示百分位；希望以前端圖表動態呈現（例如雷達圖）。
技術挑戰：前端圖表庫整合、響應式、資料從 JSON 注入。
影響範圍：可讀性、分享傳播。
複雜度：低-中

Root Cause Analysis

直接原因：原圖靜態且外部托管，難以統一風格。
深層原因：
- 架構：缺少可視化組件
- 技術：無資料接口
- 流程：發佈不產出圖表資產

Solution Design

解決策略：使用 Chart.js 以 JSON（Case #7 輸出）繪製雷達/柱狀圖，部署靜態頁即可。
實施步驟：
1. 引入圖表庫
  - 細節：CDN/本地打包
  - 資源：Chart.js
  - 時間：0.5 小時
2. 數據注入
  - 細節：fetch JSON 或在 script 中內嵌
  - 資源：JS
  - 時間：1 小時
3. 風格與導出
  - 細節：主題顏色、社群分享圖
  - 資源：CSS/Canvas
  - 時間：1 小時
關鍵程式碼： ```html

- 實際案例：本文四項百分位可直接用於圖表。
- 實作環境：前端靜態頁。
- 實測數據（示範）：平均停留時間 +22%，分享率 +10%。

Learning Points：圖表庫應用、資料綁定
技能：HTML/CSS/JS；進階：可視化設計與可用性
延伸：SSR 預渲染？擷取為 Open Graph 圖片？
Practice：基礎（靜態雷達圖）、進階（動態取 JSON）、專案（生成分享圖）
Assessment：視覺清晰、代碼整潔、效能、創意呈現

---

## Case #9: 301 轉址自動化測試（CI 驗證）

### Problem Statement
- 業務場景：redirect_from 眾多，需持續驗證 301 是否正確、是否有鏈式/循環。
- 技術挑戰：CI 併發測試、結果報表、自動失敗告警。
- 影響範圍：SEO、可用性、維護成本。
- 複雜度：中

### Root Cause Analysis
- 直接原因：手測不可靠、條目多且易變。
- 深層原因：
  - 架構：無集中式規則驗證
  - 技術：缺測試腳本
  - 流程：缺自動化把關

### Solution Design
- 解決策略：建立 URL 清單，CI 以 curl/自製腳本驗證狀態碼、Location 目標與跳數。

- 實施步驟：
  1. 生成清單
     - 細節：從 Front Matter 聚合 redirect_from
     - 資源：Parser
     - 時間：1 小時
  2. 腳本驗證
     - 細節：檢查 301、最大 1 跳
     - 資源：bash/python
     - 時間：1 小時
  3. CI 集成
     - 細節：PR 時自動跑、失敗阻擋
     - 資源：GitHub Actions
     - 時間：1 小時

- 關鍵程式碼：
```bash
# verify_redirects.sh
set -e
while read -r url; do
  code=$(curl -sIL -o /dev/null -w "%{http_code}" "$url")
  hops=$(curl -sIL "$url" | grep -i '^Location:' | wc -l)
  if [ "$code" != "200" ] && [ "$code" != "301" ]; then
    echo "BAD: $url -> $code"
    exit 1
  fi
  if [ "$hops" -gt 1 ]; then
    echo "CHAIN: $url -> $hops hops"
    exit 1
  fi
done < urls.txt

實際案例：本文有多條 redirect_from。
實作環境：Linux/curl/Actions。
實測數據（示範）：錯誤率提前發現 100%，回歸測試時間 -90%。

Learning Points：HTTP/CI、質量門禁技能：Shell/CI；進階：自動生成測試集延伸：如何可視化跳轉圖？如何在 CDN 層驗證？ Practice：基礎（手動清單驗證）、進階（自動生成 + CI）、專案（可視化報表） Assessment：覆蓋率、準確性、速度、創新

Case #10: 強制 HTTPS 與混合內容檢查

Problem Statement

業務場景：本文外部資源多為 http://，在 https 網站上會造成混合內容警告與阻擋。
技術挑戰：靜態內容掃描、替換策略、降級容錯。
影響範圍：安全、SEO、瀏覽器相容性。
複雜度：中

Root Cause Analysis

直接原因：外部資源未提供 HTTPS 或未切換。
深層原因：
- 架構：缺少資產治理
- 技術：沒有檢測/替換工具
- 流程：未在 PR 檢查此項

Solution Design

解決策略：建置混合內容 linter，嘗試自動升級至 https，失敗則鏡像或阻擋。
實施步驟：
1. 掃描
  - 細節：正則尋找 http:// 資源
  - 資源：Node/remark
  - 時間：1 小時
2. 升級/鏡像
  - 細節：HEAD 測試 https 可用性
  - 資源：Node fetch
  - 時間：2 小時
3. CI Gate
  - 細節：Fail PR 若仍含 http
  - 資源：Actions
  - 時間：1 小時

關鍵程式碼：

// check-mixed.js
const fs = require('fs');
const md = fs.readFileSync('post.md','utf8');
const urls = [...md.matchAll(/http:\/\/[^\s)"]+/g)].map(m=>m[0]);
console.log('HTTP assets:', urls);
process.exit(urls.length ? 1 : 0);

實際案例：本文多個 http:// 圖片/連結。
實作環境：Node/Actions。
實測數據（示範）：混合內容告警從 7 → 0，合規性 100%。

Learning Points：HTTPS、混合內容技能：Node/正則；進階：自動鏡像策略延伸：CSP 政策？升級不成功時 UI 提示？ Practice：基礎（掃描一篇）、進階（全站自動升級）、專案（鏡像 + CSP） Assessment：檢測準確、修復成功率、合規、創新

Case #11: SEO 與社群分享的 Open Graph/Meta 生成

Problem Statement

業務場景：文章標題為 “IQ test …” 且含圖片與英文段落；需優化分享預覽與搜尋摘要。
技術挑戰：OG 標籤生成、預設圖、描述截斷、國際化。
影響範圍：點擊率、曝光度。
複雜度：低

Root Cause Analysis

直接原因：靜態站未必內建完整 meta。
深層原因：
- 架構：模板缺預設 fallbacks
- 技術：未處理多語與圖片缺省
- 流程：未驗測分享預覽

Solution Design

解決策略：在 layout 注入 og:title/og:description/og:image、twitter:card，無圖時生成功能圖。
實施步驟：
1. 模板化 meta
  - 細節：page 取值，否則 fallback site
  - 資源：Liquid
  - 時間：1 小時
2. 預設圖
  - 細節：以標題生成 SVG → PNG
  - 資源：node-canvas
  - 時間：2 小時
3. 驗證
  - 細節：FB/Twitter Debugger
  - 資源：線上工具
  - 時間：0.5 小時
關鍵程式碼： ```html

- 實際案例：本文具標題與圖像，可受益於 OG。
- 實作環境：Jekyll/Node。
- 實測數據（示範）：社群 CTR +12%，自然流量 +5%。

Learning Points：OG/Twitter Cards、fallback 策略
技能：HTML/Liquid；進階：動態生成分享圖
延伸：多語描述？A/B 測試標題？
Practice：基礎（加入 OG）、進階（自動生成圖）、專案（分享預覽 CI 檢查）
Assessment：完整性、正確性、效能、創新

---

## Case #12: 以 tags/categories 建立導覽與聚合頁

### Problem Statement
- 業務場景：本文前言含 tags 與 categories；需建立分類與標籤聚合頁、提升可探索性。
- 技術挑戰：自動產生索引頁、分頁、SEO。
- 影響範圍：用戶探索深度、停留時間。
- 複雜度：低

### Root Cause Analysis
- 直接原因：預設主題未必提供完整聚合。
- 深層原因：
  - 架構：導覽結構缺失
  - 技術：分頁/靜態生成需客製
  - 流程：標籤不一致命名

### Solution Design
- 解決策略：建立 tags/categories 索引模板，於構建時生成聚合頁與分頁。

- 實施步驟：
  1. 模板
     - 細節：迭代 site.tags/site.categories
     - 資源：Liquid
     - 時間：1 小時
  2. 分頁
     - 細節：jekyll-paginate-v2
     - 資源：插件
     - 時間：1 小時
  3. SEO
     - 細節：canonical、描述
     - 資源：模板
     - 時間：0.5 小時

- 關鍵程式碼：
```html
{% for tag in site.tags %}
  <h2 id="tag-{{ tag[0] }}">{{ tag[0] }}</h2>
  <ul>
    {% for post in tag[1] %}
      <li><a href="{{ post.url }}">{{ post.title }}</a></li>
    {% endfor %}
  </ul>
{% endfor %}

實際案例：本文含 tags/categories。
實作環境：Jekyll。
實測數據（示範）：每訪頁數 +0.6，內部導流 +9%。

Learning Points：聚合頁、分頁技能：Jekyll 基礎；進階：SEO 最佳化延伸：標籤治理（同義詞合併）？熱門內容卡位？ Practice：基礎（標籤頁）、進階（分頁/排序）、專案（完整導覽系統） Assessment：功能、整潔、效能、創新

Case #13: 內容可近用性（alt 文字、語意結構）檢測

Problem Statement

業務場景：本文圖片 alt 含「90th percentile」等說明，但需全站一致檢查 alt/標題階層等。
技術挑戰：自動化 linter、報表、PR 合規。
影響範圍：可近用、SEO、法規要求。
複雜度：中

Root Cause Analysis

直接原因：人工作業易遺漏。
深層原因：
- 架構：缺少可近用檢查
- 技術：Markdown AST 分析未建立
- 流程：PR 缺檢查項

Solution Design

解決策略：使用 remark-lint/markdownlint 檢查 alt；自定規則校驗標題階層、對比度（靜態 CSS 掃描）。
實施步驟：
1. 工具配置
  - 細節：remark-lint 規則集
  - 資源：Node
  - 時間：1 小時
2. 自定規則
  - 細節：必須存在 alt，且長度>3
  - 資源：Plugin
  - 時間：2 小時
3. CI 整合
  - 細節：不合規 fail PR
  - 資源：Actions
  - 時間：0.5 小時

關鍵程式碼：

// .remarkrc
{
"plugins": [
  "remark-preset-lint-recommended",
  ["remark-lint-image-alt-text", true]
]
}

實際案例：本文圖片有 alt，可作為標竿。
實作環境：Node/remark。
實測數據（示範）：alt 缺失率 <1%，可近用分數 +15。

Learning Points：可近用標準、lint 流程技能：Node/工具配置；進階：自定 lint 規則延伸：自動建議 alt？圖像 AI caption？ Practice：基礎（套用規則）、進階（自定規範）、專案（CI 合規體系） Assessment：覆蓋率、規範性、穩定性、創新

Case #14: 轉址與 404 的營運分析（日志解析）

Problem Statement

業務場景：多條 redirect_from 實施後，需量化效果（404 趨勢、301 命中、來源）。
技術挑戰：蒐集 CDN/伺服器日誌、解析、可視化。
影響範圍：SEO、用戶體驗、決策。
複雜度：中-高

Root Cause Analysis

直接原因：缺少觀測指標。
深層原因：
- 架構：靜態站常託管於 CDN，日誌分散
- 技術：解析格式/時區
- 流程：未建立 KPI

Solution Design

解決策略：收集日誌至 Storage，定期用 Python 解析並出報表（301 命中、404 Top N、來源）。
實施步驟：
1. 日誌匯入
  - 細節：Cloudflare Logpush/S3
  - 資源：CDN/雲儲存
  - 時間：1 小時
2. 解析聚合
  - 細節：pandas groupby
  - 資源：Python
  - 時間：2 小時
3. 儀表板
  - 細節：Metabase/Grafana
  - 資源：BI
  - 時間：2 小時

關鍵程式碼：

import pandas as pd
df = pd.read_csv('logs.csv')
report = df.groupby('status').size().sort_values(ascending=False)
print(report)

實際案例：本文多條 redirect_from，適合分析成效。
實作環境：Cloudflare/S3、Python。
實測數據（示範）：404 降 93%，301 覆蓋率 96%，Top 10 來源占 70%。

Learning Points：營運指標、日誌工程技能：Python/pandas；進階：BI 可視化延伸：自動生成修復工單？與 SEO 排名關聯分析？ Practice：基礎（讀取/聚合）、進階（週報自動化）、專案（儀表板） Assessment：指標正確、可讀性、效能、創新

Case #15: Front Matter 資質檢查與發佈防呆（published/comments）

Problem Statement

業務場景：本文有 published: true、comments: true；需防止誤發佈、欄位缺失、格式錯誤。
技術挑戰：YAML 驗證 Schema、PR Gate、防呆回饋。
影響範圍：內容品質、運營風險。
複雜度：低-中

Root Cause Analysis

直接原因：人為失誤。
深層原因：
- 架構：無 Schema 校驗
- 技術：缺少 Lint
- 流程：未設發佈門檻

Solution Design

解決策略：以 JSON Schema 表達 Front Matter 欄位要求，CI 驗證，不符則阻擋發佈。
實施步驟：
1. 定義 Schema
  - 細節：title 必填、published bool、tags array
  - 資源：JSON Schema
  - 時間：1 小時
2. 驗證工具
  - 細節：提取 YAML → JSON → ajv 驗證
  - 資源：Node/ajv
  - 時間：2 小時
3. CI 集成
  - 細節：PR 自動跑，輸出可讀錯誤
  - 資源：Actions
  - 時間：1 小時
關鍵程式碼： ```js // validate-frontmatter.js const matter = require(‘gray-matter’); const Ajv = require(‘ajv’); const schema = { type:’object’, required:[‘title’], properties:{ title:{type:’string’, minLength:3}, published:{type:’boolean’}, comments:{type:’boolean’}, tags:{type:’array’, items:{type:’string’}} }}; const ajv = new Ajv(); const validate = ajv.compile(schema); const fs = require(‘fs’);

fs.readdirSync(‘_posts’).forEach(f=>{ const {data} = matter.read(_posts/${f}); if(!validate(data)){ console.error(f, validate.errors); process.exit(1);} }); ```

實際案例：本文 Front Matter 欄位齊全，適合作為對照。
實作環境：Node、Actions。
實測數據（示範）：Front Matter 錯誤率降至 <1%，誤發佈趨近 0。

Learning Points：Schema 驗證、CI 質量門檻技能：Node/JSON Schema；進階：自動修復建議延伸：與 CMS 編輯器整合即時提示？ Practice：基礎（單檔驗證）、進階（全站/PR Gate）、專案（可修復報告） Assessment：規範性、易用性、效能、創新

案例分類

1) 按難度分類

入門級：
- Case #3（留言整合）
- Case #8（簡單可視化）
- Case #11（OG/Meta 生成）
- Case #12（標籤/分類聚合頁）
中級：
- Case #1（轉址）
- Case #2（WP 轉換）
- Case #4（圖片鏡像）
- Case #5（Link Rot）
- Case #6（多語 SEO）
- Case #7（文本抽取）
- Case #9（301 CI 驗證）
- Case #10（HTTPS 檢查）
- Case #13（可近用性檢測）
- Case #15（Front Matter 驗證）
高級：
- Case #14（營運分析/日誌）

2) 按技術領域分類

架構設計類：
- Case #1、#2、#6、#11、#12、#15
效能優化類：
- Case #4（資產/載入）、#10（混合內容間接優化）
整合開發類：
- Case #3（留言）、#8（圖表）、#11（OG 生成）
除錯診斷類：
- Case #5（Link Rot）、#7（抽取與驗證）、#9（轉址測試）、#13（可近用 lint）、#14（日志分析）
安全防護類：
- Case #10（HTTPS）、部分 #5（降低釣魚/風險）

3) 按學習目標分類

概念理解型：
- Case #1（301/SEO）、#10（HTTPS/混合內容）、#11（OG）
技能練習型：
- Case #2（轉換腳本）、#4（鏡像）、#7（抽取）、#8（可視化）、#9（CI 腳本）、#13（lint）
問題解決型：
- Case #5（外鏈腐朽）、#6（多語 SEO）、#12（導覽架構）、#15（發佈防呆）
創新應用型：
- Case #14（數據化營運分析與決策）

案例關聯圖（學習路徑建議）

建議先學：
- 基礎建設：#11（OG/Meta）、#12（tags/categories）、#3（留言）
- 安全與合規基礎：#10（HTTPS）、#13（可近用）
依賴關係：
- #1（轉址）依賴 #2（內容已轉換且路徑穩定）
- #9（301 CI 驗證）依賴 #1（已有轉址規則）
- #14（營運分析）依賴 #1/#9（有穩定轉址與可收集指標）
- #4（圖片鏡像）與 #10（HTTPS）相輔相成
- #7（抽取）→ #8（可視化）
- #15（Front Matter 驗證）可橫向支撐所有案例
完整學習路徑： 1) 內容呈現與基礎 SEO：#11 → #12 → #3 2) 安全與可近用：#10 → #13 3) 遷移與轉址：#2 → #1 → #9 4) 外部資源治理：#4 → #5 5) 多語與國際化：#6 6) 數據化內容：#7 → #8 7) 營運分析與持續優化：#14 8) 流程強化與防呆：#15

備註：本文本為一則個人 IQ 測驗貼文與 Jekyll 前言；實戰案例多以其顯示的前言結構與內容特徵延伸設計，以供教學、練習與評估使用。若需更貼近原站實測數據，建議接入實際站點日誌與分析系統進行校準。

IQ test ...

Case #1: WordPress → Jekyll 遷移後的舊網址保留（redirect_from）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

_config.yml

某篇文章 Front Matter（示意）

/blogs/chicken/archive/2006/11/15/1947.aspx/

Case #2: WordPress 內容與 metadata 自動轉換為 Jekyll Front Matter

Problem Statement

Root Cause Analysis

Solution Design

Case #4: 外部圖片熱鏈風險與鏡像備援

Problem Statement

Root Cause Analysis

Solution Design

Case #6: 中英混排與多語 SEO（i18n/hreflang）

Problem Statement

Root Cause Analysis

Solution Design

Case #8: 將抽取數據可視化（雷達圖/長條圖）

Problem Statement

Root Cause Analysis

Solution Design

Case #10: 強制 HTTPS 與混合內容檢查

Problem Statement

Root Cause Analysis

Solution Design

Case #11: SEO 與社群分享的 Open Graph/Meta 生成

Problem Statement

Root Cause Analysis

Solution Design

Case #13: 內容可近用性（alt 文字、語意結構）檢測

Problem Statement

Root Cause Analysis

Solution Design

Case #14: 轉址與 404 的營運分析（日志解析）

Problem Statement

Root Cause Analysis

Solution Design

Case #15: Front Matter 資質檢查與發佈防呆（published/comments）

Problem Statement

Root Cause Analysis

Solution Design

Facebook Pages

AI Synthesis Contents

Edit Post (Pull Request)

Post Directory