站內 SEO 與站外 SEO 差在哪？工程師改得動的是哪一半
「SEO 做一下」是很常見的需求，但它涵蓋的東西差異極大，有的是改十行標記，有的是三個月的內容規劃。
先把界線畫清楚，才知道每一件事該找誰。
三個範圍
| 範圍 | 處理什麼 | 判斷標準 |
|---|---|---|
| 技術 SEO | 能不能被爬到、渲染出、理解、收錄 | 寫在程式碼或伺服器設定裡 |
| 站內 SEO | 頁面上的內容與標記品質 | 在自己的頁面上 |
| 站外 SEO | 其他網站對您的推薦 | 不在自己的控制範圍內 |
判斷歸屬的一句話
這件事寫在程式碼裡嗎？
- 是 → 技術 SEO，工程師的責任。
- 不是，但在自己的頁面上 → 站內 SEO，通常是協作。
- 不在自己的頁面上 → 站外 SEO，不是工程師的事。
逐項對照表
技術 SEO：工程師主責
| 項目 | 章節 |
|---|---|
robots.txt 與環境切換 | 爬蟲規則 |
sitemap.xml 的產生與提交 | 網站地圖 |
canonical 與重複內容 | 網址正規化 |
| 轉址與狀態碼 | HTTP 狀態碼 |
| 網址結構與尾斜線 | 網址結構 |
| 渲染模式的選擇 | 渲染模式 |
| 檔頭標籤的輸出機制 | meta 標籤 |
| 結構化資料的實作 | 結構化資料 |
| 語意化標籤的選用 | 語意化 HTML |
| Core Web Vitals | 核心指標 |
| 圖片與字型最佳化 | 圖片 、字型 |
| 多語系標記 | hreflang |
這個系列的文章幾乎全部落在這一格。
站內 SEO：協作
| 項目 | 內容端決定 | 工程師負責 |
|---|---|---|
<title> | 文字 | 輸出機制、長度與唯一性檢查 |
description | 文字 | 同上 |
| 內文品質與深度 | 全部 | — |
| 關鍵字涵蓋 | 全部 | — |
| 標題階層 | 章節怎麼分 | 標籤層級正確、不跳級 |
| 錨點文字 | 用什麼說法 | 是 <a href> 而非 <div> |
圖片 alt | 描述文字 | 欄位存在、有自動檢查 |
| 內部連結佈局 | 哪些主題該互連 | 沒有孤兒頁面 |
最有效的分工模式
工程師把它做成欄位加上自動檢查，內容端只需要填欄位。
---
title: 頁面標題
description: 這一頁的重點摘要。
---再加上建置時的檢查：缺漏就擋住建置、重複就擋住建置、過長就給警告。
這樣內容端不必記規則，工程師也不必每次審稿。
站外 SEO：不是工程師的事
| 項目 | 誰負責 |
|---|---|
| 反向連結的取得 | 行銷、公關、內容 |
| 品牌提及 | 行銷、公關 |
| 社群擴散 | 行銷 |
| 媒體報導 | 公關 |
| 業界名錄與目錄收錄 | 行銷 |
| 評價與口碑 | 客服、產品 |
工程師在站外 SEO 幫得上的三件事
雖然不主責，但有三個關鍵支援
1. 網址穩定
被引用的網址如果隨改版消失，那條連結就變成 404，累積的價值全部歸零。
| 做法 | 見 |
|---|---|
| 改版時建立完整的轉址對照表 | 轉址對照表 |
| 轉址至少保留一年 | 同上 |
| 從 Search Console 匯出實際被收錄的網址 | Search Console |
這是工程師對站外 SEO 最大的貢獻，不是取得連結，而是不要把既有的連結弄壞。
2. 內容容易被分享
社群卡片空白的連結沒人想轉。
| 做法 | 見 |
|---|---|
| Open Graph 標籤寫在 HTML 裡（非程式碼注入） | Open Graph |
| og 圖用 PNG 或 JPEG | 圖片格式 |
| og 圖由建置流程自動產生 | 同上 |
3. 頁面值得被引用
載入八秒、版面亂跳的頁面，即使內容好也不太有人想引用。
| 做法 | 見 |
|---|---|
| Core Web Vitals 落在良好範圍 | 核心指標 |
| 行動裝置可讀 | viewport |
跨部門協作最常卡在哪
責任界線不清造成的互相等待
典型的情境：
- 行銷回報「某個關鍵字排名掉了」。
- 工程師檢查發現技術面沒問題。
- 內容端不知道要改什麼。
- 三方互相等待，什麼都沒發生。
解法是先排除工程面的可能
遇到流量或排名問題時，先跑一次技術檢查清單，那是最快能得到明確答案的一段：
| # | 檢查 | 見 |
|---|---|---|
| 1 | 頁面還在被收錄嗎？ | Search Console 的網址檢查 |
| 2 | 狀態碼正常嗎？ | HTTP 狀態碼 |
| 3 | 有意外的 noindex 嗎？ | meta robots |
| 4 | canonical 指對了嗎？ | 網址正規化 |
| 5 | 檢視原始碼看得到內容嗎？ | 純 CSR 的問題 |
| 6 | 核心指標有退步嗎？ | 指標量測 |
| 7 | 改版有漏掉的轉址嗎？ | 轉址對照表 |
跑完這七項通常能得到明確結論：
- 有問題 → 工程師修。
- 沒問題 → 問題在內容或競爭對手，交給對應的人。
關鍵是 這一段能在一小時內得到答案，而不是讓問題懸著。完整清單見 技術 SEO 的 30 項檢查 。
工程師需要懂多少關鍵字研究
不必自己做，但知道結果很有用
| 為什麼有用 | 說明 |
|---|---|
| 寫 錨點文字 | 用讀者真的會搜的說法，而不是內部術語 |
| 命名檔案與網址 | 網址結構 用有意義的字 |
寫 alt | 自然涵蓋主題 |
| 判斷需求合不合理 | 「把這五個關鍵字都塞進標題」→ 那是 關鍵字堆疊 |
最後一項尤其重要，看得懂 SEO 才能擋掉會反效果的需求。
各角色的責任摘要
| 角色 | 主責 | 協作 |
|---|---|---|
| 前端工程師 | 技術 SEO 全部 | 標記的輸出機制與自動檢查 |
| 後端工程師 | 狀態碼、轉址、TTFB、API 效能 | sitemap 的動態產生 |
| 內容編輯 | 內文、標題與描述的文字 | 提供 alt 描述 |
| SEO 或行銷 | 關鍵字研究、成效追蹤 | 提出優化方向 |
| 公關 | 反向連結、媒體報導 | — |
| 設計師 | 版面不造成 版面偏移 、圖片規格 | og 圖的視覺 |
設計師那一格常被忽略
「主視覺要滿版全螢幕」與「LCP 要在 2.5 秒內」是有張力的需求。在設計階段就把效能限制講清楚，比事後來優化容易得多。
一樣的道理：og 圖的視覺規格（1200 × 630、關鍵資訊不要貼邊）也該在設計系統裡定好。
這個系列的定位
這個系列談的是「技術 SEO」加上「站內 SEO 的標記部分」
| 涵蓋 | 不涵蓋 |
|---|---|
| 檔頭標籤的實作 | 標題與描述的文案技巧 |
| 索引控制 | 關鍵字研究 |
| 語意化結構 | 內容寫作 |
| 結構化資料 | 反向連結取得 |
| Core Web Vitals | 競爭對手分析 |
| 圖片與字型最佳化 | 廣告投放 |
| 渲染模式 | 品牌經營 |
| 檢測工具 | 成效歸因分析 |
這是刻意的界線，前端工程文件該談的是寫在程式碼裡的那一半。右邊那些屬於內容與行銷的專業，值得另外一整套資料。
常見問題
三種 SEO 怎麼區分？
技術 SEO 處理搜尋引擎能不能爬到、渲染出、理解與收錄這一頁，全部寫在程式碼裡；站內 SEO 是頁面上的內容與標記品質；站外 SEO 是其他網站對您的推薦，也就是反向連結與品牌提及。
標題與描述算誰的責任？
文字內容由內容端決定，輸出機制由工程師負責。實務上最有效的分工是工程師把它做成頁面資料的欄位並加上長度與唯一性的自動檢查，內容端只需要填欄位。
工程師需要懂關鍵字研究嗎？
不必自己做，但知道結果很有用。看得懂關鍵字清單才知道該用哪個說法寫 錨點文字 與檔案命名，也才能判斷內容端提的需求合不合理。
跨部門協作最常卡在哪？
責任界線不清。行銷回報排名掉了、工程師檢查發現技術面沒問題、內容端不知道要改什麼，於是互相等待。解法是先跑一次 技術檢查清單 排除工程面的可能，再把問題交給對應的人。
延伸閱讀
參考資料：Google 搜尋中心：SEO 入門指南