用 F12 找 SEO 問題：開發者工具的實戰檢查法
SEO 人必學的 F12 開發者工具教學：打開 Elements 面板按 Ctrl+F 搜尋 title、H1、canonical、og:type，三十秒完成標籤健檢。動態渲染網站的標籤只有 F12 看得到，檢視原始碼會漏。
作者：褚崇名（Sliven）
本頁目錄
- 「檢視原始碼」跟「檢查元素」其實是兩件事
- 怎麼打開 DevTools：跨瀏覽器、跨系統的快捷鍵總表
- 為什麼 SEO 人一定要會：你看到的畫面不等於搜尋引擎讀到的
- Elements 面板實戰：把 title、canonical、schema 全部挖出來
- Console 面板：用一行指令把全頁的標題結構抓出來
- Network 與 Coverage 面板：速度、封鎖、冗餘資源一次看清
- Lighthouse 與 Disable JavaScript：模擬搜尋引擎的第一眼
- Application 面板：Service Worker 與 Cookie 帶來的 SEO 副作用
- 三個實務上最常撞見的「視覺騙局」
- 騙局一：用 div 假裝的標題
- 騙局二：靠 JavaScript 才出現的關鍵內容
- 騙局三：被 CSS 藏起來的文字與連結
- 新手最容易踩的 F12 地雷：一份 DO 與 DON'T 對照
- 行動優先索引下的檢查節奏：先切手機，再下結論
- 把 F12 拿來做競品拆解：看懂為什麼它排在你前面
- 把 F12 變成你的 SEO 第六感
頁面排在你前面，差距有時藏在畫面背後的程式碼裡。瀏覽器內建的開發者工具，多數人習慣叫它 F12，能幫你查看 HTML、資源載入與前端渲染；它可以找出技術差異，卻不能單憑一個頁面證明排名因果。
對前端工程師來說，F12 是除錯與調整樣式的工具；對 SEO 人來說，它能顯示目前瀏覽器的 DOM、載入資源與 JavaScript 執行結果。這不是 Googlebot 的實際視角，還要搭配 Search Console 網址檢查工具查看 Google 抓到與渲染的版本。
這個觀念在 AI 搜尋崛起的當下僅會越來越重要。不管是傳統的 Google 排名，還是 AI Overviews、生成式搜尋，背後都有一支爬蟲在讀你的 HTML。當 AI 引擎要決定要不要引用你的內容時，它讀的也是這份程式碼，不是你精心設計的視覺版面。換句話說，看懂原始碼，等於看懂所有搜尋與 AI 系統跟你的網站對話的語言。也因此，它可說是 SEO 人最該優先學會的「非 SEO」技能，CP 值比任何付費工具都高。
「檢視原始碼」跟「檢查元素」其實是兩件事
很多人把這兩個動作混在一起，但若你搞懂差別，SEO 功力會直接跨過一個檔次。一句話總結：「檢視原始碼」看到的是伺服器送出來的那份生 HTML，「檢查元素」看到的是瀏覽器渲染完、JavaScript 跑完之後的即時 DOM。
差別在哪？舉個極端的例子。一個用 React 或 Vue 打造的單頁應用（SPA），它的「原始碼」可能瘦到僅剩一個 <div id="root"></div>，因為所有標題、內文、連結都是 JavaScript 在瀏覽器裡動態生成。你按 Ctrl + U（檢視原始碼）會看到一片空曠；但你按 F12 打開 Elements 面板，卻能看到完整的、有層級的標題結構。這中間的落差，就是 JavaScript SEO 的核心戰場，也是這個領域反覆強調「渲染後 DOM」重要性的原因（延伸閱讀：JavaScript SEO）。
Google 會抓取原始 HTML，也能用 Web Rendering Service 執行 JavaScript。渲染可能排隊，所需時間沒有固定的「幾小時到幾天」承諾；資源遭 robots.txt 阻擋、需要登入或執行失敗，都可能讓 Google 看到不同結果。F12 可先確認內容如何進入本機 DOM，再用網址檢查工具核對 Google 實際抓取與渲染的版本。
| 動作 | 快捷鍵（Windows） | 快捷鍵（Mac） | 看到的是什麼 | SEO 判讀重點 |
|---|---|---|---|---|
| 檢視原始碼 | Ctrl + U | Cmd + Option + U | 伺服器送出的原始 HTML（未渲染） | 關鍵 SEO 標籤是否在第一份 HTML 裡，還是被 JS 注入 |
| 檢查元素（Inspect） | F12 或右鍵→檢查 | Cmd + Option + I 或右鍵→檢查元素 | 渲染後的即時 DOM，可即時修改 | 實際的標題層級、隱藏內容、結構化資料落地狀態 |
怎麼打開 DevTools：跨瀏覽器、跨系統的快捷鍵總表
F12 這個名字來自 Windows 鍵盤上那顆功能鍵，在 Chrome、Edge、Firefox 上按下去就會直接開啟開發者工具。但 Mac 鍵盤沒有獨立的 F12（要按 Fn + F12），所以 Mac 使用者請改用 Cmd + Option + I，這組快捷鍵在三大瀏覽器上幾乎通用。有個常見的小混淆要提醒你：F11 是全螢幕，F12 才是開發者工具，別按錯了。
各瀏覽器的開發者工具能力差不多，但入口與名稱略有不同。Safari 比較特別，它預設把開發者功能藏起來，你得先到「Safari → 設定 → 進階」勾選「顯示網頁開發者功能」，這組選單才會出現（這也是為什麼很多剛接觸 SEO 的 Mac 使用者在 Safari 上找不到 F12 的原因，可對照 Apple Developer 的 Safari Developer Tools 說明）。
| 瀏覽器 | Windows / Linux | Mac | 備註 |
|---|---|---|---|
| Chrome | F12、Ctrl + Shift + I、右鍵→檢查 | Cmd + Option + I、右鍵→檢查 | 業界主流，Chrome DevTools 官方文件最完整 |
| Edge | F12、Ctrl + Shift + I | Cmd + Option + I | Chromium 核心，操作邏輯與 Chrome 一致 |
| Firefox | F12、Ctrl + Shift + I | Cmd + Option + I | 內建 CSS 與無障礙檢查器（見 MDN 的 Firefox Developer Tools 文件） |
| Safari | 不適用 | 先啟用開發選單，再 Cmd + Option + I | 預設關閉，需手動開啟 |
養成一個習慣：檢查頁面時，按 F12 或右鍵選「檢查」。打開之後你會看到一整排分頁，初次接觸可能覺得眼花撩亂，但不需要全部學會；先掌握與頁面結構、資源載入和錯誤排查最相關的幾個面板，就能處理不少日常檢查。接下來會依序帶你走過這幾個關鍵面板。
為什麼 SEO 人一定要會：你看到的畫面不等於搜尋引擎讀到的
搜尋引擎會解析 HTML，也會渲染 CSS 與 JavaScript；可見性、行動版版面與互動體驗並非毫無意義。語意標籤能更清楚表達內容層級，也改善無障礙。一個用 <div class="big-title"> 做出的視覺標題仍有文字內容，但 <h1> 能更明確描述它是主標題。
title 缺漏、重複或與頁面內容不符，都能從原始碼與 Elements 面板開始排查。Google 會依 <title>、頁面主標題、醒目文字與其他訊號產生搜尋結果中的標題連結，因此瀏覽器分頁有文字，不代表搜尋結果一定照原樣顯示（見 Google 對標題連結的說明）。點擊率還會受排名、查詢與搜尋結果版型影響，不能把標題視為單一決定因素（見 Search Console 成效報表）。想深入了解標題怎麼寫，可以回頭看我們對〈title 標籤〉的完整拆解。
另一個關鍵是行動優先索引。Google 在 2023 年宣布遷移工作完成，意思是主要以行動版內容建立索引；這不是「行動版額外加分」的排名規則（見 Google 的公告〈Mobile-first indexing is here〉）。收合區塊若仍存在行動版 DOM、使用者可以操作展開，不會僅因收合就被折扣。真正要查的是行動版是否缺少主要內容、連結、圖片替代文字或結構化資料。
換句話說，SEO 的工作有很大一部分，是在翻譯兩種語言：把設計師視覺語言裡的「這裡是重點」，翻譯成搜尋引擎聽得懂的 HTML 語意。而 F12，就是你做這層翻譯時的對照字典。
把這個觀念再往前推一步：讀懂原始碼不僅是「找錯」，還能反過來提升你寫內容的判斷力。當你長期用 F12 觀察那些排名穩定的頁面，你會內化出一種感覺，知道什麼樣的標題層級、什麼樣的內部連結布局、什麼樣的結構化資料，會被搜尋引擎讀成「這是一份結構清楚、值得信任的內容」。這種來自第一手觀察的判斷，是 AI 量產文永遠學不來的經驗，也正是 E-E-A-T 裡那個 Experience 最值錢的地方（誠信與權威的完整框架，可參考〈E-E-A-T〉）。所以別把 F12 僅當除錯工具，它是你累積內容直覺的視窗。
Elements 面板實戰：把 title、canonical、schema 全部挖出來
Elements 面板（Firefox 叫 Inspector）是你最常待的地方。它用一棵可展開的樹狀結構呈現整份 DOM，你可以點開任何一個節點，右側還會顯示這個元素套用了哪些 CSS 規則。對 SEO 來說，這裡是驗證「關鍵標籤到底有沒有落地」的主戰場（操作說明見 Chrome DevTools 的 Inspect and Edit Pages and Styles 文件）。
建議你把 Elements 面板當成一個 SEO 健檢清單，逐項點開 <head> 確認下列標籤。多數瀏覽器還支援 Ctrl + F 在 DOM 樹裡搜尋關鍵字，例如直接搜 canonical、hreflang、application/ld+json，比肉眼翻快得多。
| SEO 元素 | 在 Elements 裡找什麼 | 判讀重點 |
|---|---|---|
| title 標籤 | <title> | 是否存在、長度、是否被 JS 動態改寫（見〈title 標籤〉） |
| meta description | <meta name="description"> | 是否空值或被截斷 |
| canonical | <link rel="canonical"> | 指向是否正確、有無衝突的多組 canonical（〈canonical 標籤〉） |
| hreflang | <link rel="alternate" hreflang> | 多語系站必查，雙向對應是否完整 |
| robots meta | <meta name="robots"> | 是否被 noindex 或 nofollow 封鎖（〈noindex〉、〈robots.txt〉） |
| 結構化資料 | <script type="application/ld+json"> | JSON-LD 是否存在、語法是否正確（〈結構化資料〉） |
| Open Graph | <meta property="og:"> | 社群分享時的標題與圖（〈Open Graph 標籤〉） |
| 標題層級 | <h1> ~ <h6> | 全頁應僅有一個 h1，層級不可跳級 |
在 Elements 面板裡，你也可以暫時修改任何元素的文字或屬性，即時看到畫面變化。這對「假設性調整」很好用：例如你想看某個標題換成更精準的關鍵字後畫面會不會跑版，雙擊文字就能改，重新整理後就還原。這個動作僅動你的瀏覽器，不會影響真實網站，是很安全的實驗方式。
Console 面板：用一行指令把全頁的標題結構抓出來
Elements 面板適合逐個元素翻，但如果要快速盤點整個頁面的標題結構、內部連結數量或重複標籤，Console 面板快多了。Console 讓你直接對目前這份 DOM 下 JavaScript 指令，回傳結果。接著這幾行是第一線最常用的查詢：
- 數標題數量：
document.querySelectorAll('h1').length、document.querySelectorAll('h2').length。一個頁面 h1 應該僅有一個，h2 數量則反映內容骨架的厚度。 - 列出所有標題文字：
[...document.querySelectorAll('h1,h2,h3')].map(e => e.tagName + ': ' + e.textContent.trim())。這行會把整頁的標題層級與文字一次吐出來，等於一份現成的文章大綱，拿來看資訊架構超方便。 - 查 canonical：
document.querySelector('link[rel="canonical"]')?.href。秒確認這一頁自我聲明的標準網址是什麼。 - 算內部連結：
document.querySelectorAll('a[href^="/"]').length。快速掌握頁面對站內的連結密度（搭配〈內部連結〉一起看）。 - 找隱藏內容：
[...document.querySelectorAll('*')].filter(e => getComputedStyle(e).display === 'none').length。這行僅回傳目前被隱藏的元素數量；選單、分頁與響應式元件都可能正常使用display:none，必須逐項判讀，不能用數量定罪。
一個更省事的寫法：Chrome 與 Edge 的 Console 內建 $$ 這個 document.querySelectorAll 的縮寫，所以 $$('h2').length 就能數 h2 數量；$0 則會指向你剛在 Elements 面板點選的元素，兩邊來回對照非常順手。這些不是花俏的技巧，是把十分鐘的肉眼翻找壓縮成三秒的效率工具。當你手上同時要檢查數十個頁面時，差別就出來了。
若某篇重要文章一直進不了索引，可先用 F12 確認主內容是否進入 DOM，再查 document.querySelector('meta[name="robots"]')?.content 與 document.querySelector('link[rel="canonical"]')?.href。H1 不必硬性僅有一個，段落數也沒有「合理值」門檻；這些僅能協助定位前端輸出，索引原因仍要用網址檢查與網頁索引報表核對。
Console 還有一個低調但好用的功能：它會印出頁面載入時的 JavaScript 錯誤。如果一進 DevTools 就看到 Console 滿是紅字，代表這個頁面有 script 執行失敗，而失敗的 script 很可能正是負責注入 SEO 標籤的那一段。把錯誤訊息點開，往往能直接指向問題檔案與行號，再轉交給工程師處理。對 SEO 人來說，你不一定要會修 JS，但你要會「讀」Console 的紅字，因為它就是頁面健康狀態的體檢報告。
Network 與 Coverage 面板：速度、封鎖、冗餘資源一次看清
SEO 不僅看內容，也看這個頁面能不能被順利抓取與快速載入。Network 面板（Firefox 同名）會列出頁面載入過程中發出的每一個請求：HTML 文件、CSS、JavaScript、圖片、字型、XHR/API 呼叫，連狀態碼與載入時間都一目了然。這裡有幾個 SEO 一定會用到的判讀：
狀態碼。主文件通常應回傳 200；大量轉址鏈會增加延遲，大型網站也可能浪費抓取資源。請求失敗。Network 顯示的是目前瀏覽器的請求，不會替 Googlebot 套用 robots.txt 規則；Google 是否能抓到所需 CSS／JS，要另用網址檢查與 robots.txt 測試確認。回應大小與時間。瀑布圖可找出拖慢渲染的資源。Core Web Vitals 是整體頁面體驗的一部分，屬於小幅排名訊號，不應凌駕內容相關性（延伸閱讀：〈Core Web Vitals〉、〈從 FID 到 INP〉）。
跟 Network 相輔相成的是 Coverage 面板。它會估算本次操作中未使用的 CSS／JS，但未執行不代表可以直接刪除，其他路徑或互動可能仍會用到。它適合拿來找候選項，再透過拆分、延後載入與實測確認是否改善 LCP 或 INP。
順帶一提，Network 面板也是你確認追蹤碼有沒有正常運作的好地方。在篩選器輸入 google 或 analytics，就能看到 GA、GTM、Ads 的請求有沒有真的發出去。畢竟網站分析工具的普及率極高，W3Techs 的統計（2026 年 6 月）顯示 Google Analytics 是全球市占最高的網站分析服務。但普及不代表你裝對了，太多站體是「畫面上看得到碼、Network 裡卻沒有請求」，這種情況僅有 F12 查得出來（追蹤碼安裝可搭配〈GTM 設定〉、〈Google Analytics〉）。
Lighthouse 與 Disable JavaScript：模擬搜尋引擎的第一眼
DevTools 的 Disable JavaScript 與 Lighthouse 能檢查無 JavaScript 備援與常見技術問題，但不能還原 Googlebot 的實際抓取環境。官方視角仍以網址檢查工具為準。
Disable JavaScript 適合快速查看伺服器送出的內容是否足以使用。執行後消失的標題、選單、內文與連結，代表它們依賴 JavaScript；但畫面不是 Googlebot 的「第一次抓取」，因為瀏覽器仍可能使用快取與不同請求條件。要確認原始回應，應搭配檢視原始碼或 Network 的主文件 Response。
如果重新整理後你的主要內容（h1、文章本體、內部連結）還在，代表你的網站對搜尋引擎相對友善；如果整頁變成空白、或僅剩一個空殼框架，就代表你幾乎所有 SEO 訊號都賭在「Google 願意花資源幫你渲染」這件事上。這在靜態輸出的內容站、WordPress 部落格上很少出問題，但在採用 React、Vue、Next.js 這類現代前端框架的網站上非常常見。這個測試不用三分鐘，卻能瞬間告訴你一個網站的 SEO 體質是強健還是脆弱，CP 值高得驚人。
Lighthouse 則是 DevTools 內建的自動化稽核工具（在分頁列找到 Lighthouse，或一樣用指令選單搜尋）。它會從效能、無障礙、最佳實踐、SEO 四個維度產出一份評分報告。對 SEO 人來說，要看的是它列出的 SEO 類別建議：缺 title、缺 meta description、canonical 無效、按鈕字級太小、圖片缺 alt 文字這些問題都會被一條條點名。Lighthouse 的價值不在分數本身，而在它給你一份現成、可逐條勾銷的待辦清單。要提醒一點：Lighthouse 跑的是模擬環境的分數，跟實際使用者在真實網路下的 Core Web Vitals（來自〈網頁速度〉的實測資料）會有落差，兩者要分開看，前者用來抓結構性問題，後者用來看真實體驗。
| 檢查方式 | 回答的問題 | 適合的場景 |
|---|---|---|
| Disable JavaScript 後重整 | 沒有 JS 時，SEO 關鍵內容還在嗎？ | 懷疑 JS 渲染風險、新框架網站健檢 |
| 檢視原始碼（Ctrl + U） | 伺服器送出的第一份 HTML 長什麼樣？ | 確認關鍵標籤是否 server-side render |
| Lighthouse SEO 稽核 | 有哪些結構性的 SEO 缺失？ | 新接手一個站、做全面盤點 |
| Elements 面板搭配 Console | 渲染後的 DOM 裡實際是什麼？ | 逐項驗證標籤、計算標題層級 |
Application 面板：Service Worker 與 Cookie 帶來的 SEO 副作用
很多人停在 Network 就走了，其實 Application 面板藏著另一層跟 SEO 間接相關的情報。這裡看的是瀏覽器端的儲存：Service Worker、Cache Storage、Cookies、IndexedDB、Local Storage。它們不直接決定排名，卻會在你看不到的地方影響「Google 抓到的是不是最新版本」。
Service Worker 可能讓本機瀏覽器收到舊快取或被改寫的回應，因此適合用 Application 面板排查「本機看得到的版本跟新訪客不同」這類問題。它不代表 Googlebot 一定會收到同一份 Service Worker 快取；搜尋端仍要用網址檢查與伺服器記錄驗證。
Cookie 與同意牆是另一個 SEO 副作用來源。歐盟與越來越多地區要求網站裝設 Cookie 同意橫幅，而有些實作方式會在使用者按下「同意」之前，把整個頁面內容用一層覆蓋物擋住，或甚至延後載入追蹤與部分內容。對真人沒問題，但對 Googlebot 這種「不會按同意鈕」的訪客，如果實作不當，它可能抓到的是被遮蔽的版本。在 Application 面板的 Cookies 分頁，你能看到目前設定了哪些 Cookie；搭配 Network 看 DOM 載入時序，就能判斷同意牆有沒有誤傷搜尋引擎。
這些都不是 F12 的主流用法，但正因為冷門，懂的人特別少。當你把 Elements、Console、Network、Lighthouse、Application 這幾個面板串起來看，你對一個頁面的掌握程度，會逼近一個真正的搜尋引擎渲染器。這種全景式的檢查能力，是任何付費工具都無法完全取代的（網站技術體質的長期經營，可延伸到〈網站設計〉與〈WordPress SEO〉）。
三個實務上最常撞見的「視覺騙局」
講了這麼多操作，換個角度，談談 F12 真正能幫你避開的地雷。接下來這三種狀況，畫面上完全看不出問題，但一打開 Elements 就現形。這類狀況稱為「視覺騙局」，因為它們專門欺騙設計稿與肉眼，卻騙不過程式碼。
騙局一：用 div 假裝的標題
若首頁最顯眼的標題僅是加大字級的 div，搜尋引擎仍讀得到文字，但語意層級不如正確標題元素清楚，螢幕閱讀器使用者也較難導覽。可在 Elements 面板確認主題標題是否使用合適的 <h1> 到 <h6>，並依內容結構安排層級。
還有一個快速驗證的訣竅：把整頁的標題層級用前面教的 Console 指令一次印出來，再對照你在畫面上「以為」的標題結構。如果印出來的清單裡，那些你視為主標的大字根本不在 h1 到 h3 的清單上，就代表這個頁面的語意骨架跟視覺骨架完全脫鉤。這種脫鉤在首頁、登入頁、活動頁這類「設計主導」的頁面最常見，偏偏它們往往又是網站權重最高的入口頁，值得你優先把標題層級校正回來。
騙局二：靠 JavaScript 才出現的關鍵內容
頁面的 title、canonical 或結構化資料也可能由 JavaScript 注入。Google 支援處理 JavaScript 產生的 JSON-LD，但內容必須與可見頁面一致；canonical 與 hreflang 若能在伺服器回應中保持穩定，較容易避免前端狀態或渲染失敗造成不一致。可同時比對原始碼、DOM 與網址檢查結果。
騙局三：被 CSS 藏起來的文字與連結
第三種是 display:none 或被定位到螢幕外的內容。響應式設計裡，把手機版不需要的桌機元素隱藏起來是正常做法，Google 也理解這點。但如果被藏起來的是塞滿關鍵字的段落、或一大排你看不到的內部連結，這就踩到黑帽的邊了。Google 對隱藏文字與隱藏連結有明確政策，輕則折扣該內容的權重，重則手動處分。用前面 Console 那行隱藏元素查詢，或在 Elements 面板勾選「顯示被隱藏的元素」，就能把這些幽靈內容抓出來（黑帽手法的全貌可參考〈黑帽 SEO〉）。任何「僅想給搜尋引擎看、不想給真人看」的內容，都是高風險動作。
新手最容易踩的 F12 地雷：一份 DO 與 DON'T 對照
工具學會了，觀念也講完了，但新手在實際操作時還是會踩到一些共同的坑。以下把常見的錯誤整理成一份對照表，你可以當成自我檢查的清單。這些地雷的共同特徵是：它們讓你「誤以為自己看對了」，卻在不知不覺中得出錯誤的 SEO 結論。
| 地雷 | 別這樣做（DON'T） | 該這樣做（DO） |
|---|---|---|
| 僅看 Elements、不看原始碼 | 以為 Elements 面板就是真相，沒發現關鍵標籤是 JS 注入的 | 用 Ctrl + U 對照原始碼，確認 SEO 標籤在第一份 HTML 裡 |
| 僅在桌機視角檢查 | 全程桌機檢查，漏掉手機版被精簡的內容 | 先切手機視角再檢查，因為 Google 主要看手機版 |
| 把暫存修改當成正式修復 | 在 Elements 改完就以為網站修好了，重整後卻還原 | 記得 F12 的修改僅動瀏覽器，正式修改要回到 CMS 或程式碼 |
| 忽略懶載入內容 | 滾動前就計算標題數，漏掉滾動後才載入的區塊 | 先完整捲動頁面、觸發所有載入，再下 Console 指令 |
| 把 Lighthouse 分數當唯一指標 | 僅追分數，忽略真實使用者的 Core Web Vitals | 分數抓結構問題，體驗看實測資料，兩者分開解讀 |
| 用 F12 判讀他人 GA 帳密 | 看到 Network 裡的追蹤 ID 就拿來濫用 | 僅用來確認對方裝了什麼追蹤，尊重資料邊界 |
這份清單裡最容易被忘記的是「懶載入」那一項。很多現代網站會把圖片、留言、推薦區塊設定成使用者滾動到定位才載入，如果你一打開 F12 就立刻數標題或連結，可能僅算到前半段。養成「先完整捲動一次、再下判斷」的習慣，你的檢查才會貼近真實。另一個觀念要釐清：F12 看到的是這個當下、這個瀏覽器、這個視角的 DOM，它不代表所有使用者的體驗，更不等於 Google 一定看到的一模一樣。它是一個強力但有限的取樣工具，跟 Search Console 的官方視角搭配著看，結論才會穩。
行動優先索引下的檢查節奏：先切手機，再下結論
把前面學的東西串成一個工作流程。既然 Google 主要看手機版，你的檢查順序就應該跟著調整。打開 F12 的第一件事，是先切到手機視角，別急著看桌機 DOM。在 Elements 面板左上角有一個「切換裝置工具列」的按鈕（快捷鍵 Ctrl + Shift + M／Cmd + Shift + M），點下去後就能選擇 iPhone、Pixel 等裝置，並調整視窗寬度。
切到手機視角後，重新做一次 Elements 健檢。確認主要內容與結構化資料沒有被移除，重要連結在收合選單中仍可操作且存在 DOM。連結不會僅因合理收合就被折扣，問題在於行動版是否真的缺少或無法操作。
舉一個常見的情境：一個電商網站的桌機版產品頁，下方有一大塊「相關推薦商品」的內部連結網格；手機版則改成預設闔上的收合元件。合理收合的內容不會因此被折扣，但仍要確認連結存在於行動版 DOM、能正常展開，而且沒有因延遲載入或 JavaScript 錯誤而缺漏。如果僅看桌機版，就可能忽略這類實作差異。行動優先索引指的是 Google 主要使用行動版內容進行索引，不代表行動版另有一套排名加分。
所以在工作流程上，建議你養成「兩次檢查」的習慣：一次桌機、一次手機，把兩邊看到的 DOM 差異都記下來。差異越大，越要思考那些僅出現在桌機版的內容，是不是該想辦法讓手機版也吃得到。這不是要你對抗設計，而是要你在設計與 SEO 之間找到平衡，讓兩個版本都對搜尋引擎友善。
- 開 DevTools 並切到手機視角，選一個代表性裝置（例如 iPhone 13）。
- 跑一次標題層級盤點：確認有清楚的主標題，標題層級能反映內容結構；HTML 並未禁止多個 h1，也沒有因單純跳級就觸發排名處罰的規則。
- 逐項查 head 標籤：title、meta description、canonical、hreflang、robots、JSON-LD，全部確認存在且值正確。
- 用 Ctrl + U 對照原始碼：確認上述標籤不是純靠 JS 注入。
- 開 Network 看狀態碼與被封鎖資源：主文件回 200、關鍵 JS／CSS 沒被擋。
- 查隱藏元素與追蹤碼：沒有異常的 display:none，GA／GTM 請求有正常發出。
- 記下問題、排優先順序：標題層級與 noindex 誤封是 P0，速度優化是 P1。
這份流程能讓你掌握目前瀏覽器的頁面結構，但不能代表搜尋引擎一定看到相同 DOM。Google Search Console 的〈網址檢查工具〉可提供官方抓取與渲染資訊，和 F12、伺服器記錄交叉比對，才是較完整的診斷。
把 F12 拿來做競品拆解：看懂為什麼它排在你前面
F12 不僅能檢查自己的網站，更是拆解競品的利器。當一個競品頁面排在你前面，與其憑感覺猜它「內容比較好」或「權重比較高」，不如直接打開它的原始碼，把它的 SEO 做法攤開來比對。你會經常發現，差距往往藏在那些畫面上完全看不出來的技術細節裡，跟內容長度的關係其實不大。
拆解流程通常是固定的五步：先用 Ctrl + U 看它的原始碼，確認 title、meta description、canonical、JSON-LD 是否齊全；再用 Console 跑一次標題層級盤點（$$('h1,h2,h3')），看它的內容骨架是怎麼組織的；接著切到手機視角，看它手機版的內容有沒有被精簡掉；然後開 Network，看它載入了哪些資源、有沒有用到你沒有的技術（例如 Service Worker 快取、圖片預先載入）；完成後比對它跟你的內部連結數量與錨點文字分布。這五步做完，你通常能具體說出「它贏在哪、自己輸在哪」，不會再停留在「它就是比較強」這種沒有行動指引的結論。
這個練習做多了，你會逐漸建立一套檢查頁面結構的直覺：title 是否準確、主標題是否清楚、標題層級能否反映內容、適用的結構化資料是否有效、內部連結是否自然。HTML 沒有限制每頁僅能有一個 h1，結構化資料完整也不保證排名；F12 的用途是發現可驗證的實作問題，不是從幾個標籤倒推出排名原因（搜尋意圖的完整觀念可參考〈搜尋意圖〉，內容與網站的組織方式可參考〈網站結構〉）。
把 F12 變成你的 SEO 第六感
工具本身不難，難的是養成「看到頁面就想翻它底牌」的直覺。當你按 F12 變得跟呼吸一樣自然，你會開始發現一堆過去看不到的問題：那個排名卡在第二頁的產品頁，原來 h1 是空的；那個怎麼樣都不被收錄的分類頁，原來被塞了 noindex；那個自稱速度很快的官網，原來載了一堆用不到的 JS。每一個發現，都是一個能往上爬的階梯。
說到底，這套檢查方法背後只有一個核心信念：SEO 從來不是玄學，而是一連串可以被看見、被驗證、被修改的技術事實。差別僅在於，你願不願意花三分鐘按下那顆 F12，把畫面背後的真相搬到眼前。多數人輸給競品，不是輸在內容才華，而是輸在「從來沒認真看過自己網站的原始碼」。你不需要變成工程師，你僅需要變成一個願意把網站拆開來看的人。這個小小的動作，長期累積下來，就是你跟其他僅會用第三方工具的人拉開差距的地方。
給你一個立刻能做的行動方案。今晚就挑出你自己網站上流量最高的三個頁面，按下 F12，照著上面的七步流程走一遍。把發現的問題列成清單，標上優先順序，下週找工程師或自己動手改。如果你是委外經營的站，這份清單就是你跟開發團隊溝通的最佳共通語言，因為你講的不再是「感覺 SEO 不太對勁」，而是具體的「這個 h1 缺失、那個 canonical 指錯、那段內容被 display:none 藏起來」。把感覺翻譯成事實，是讓跨部門協作真正動起來的關鍵。
F12 之所以是 SEO 人的基本功，是因為它把你從「猜測」拉到「看見」。而在一個演算法每個月都在變、AI 搜尋逐漸崛起的時代裡，能親眼看見搜尋引擎視角的人，永遠比僅看畫面的人多一分勝算（AI 搜尋時代的整體策略，可以參考〈AI SEO〉與〈AEO 優化〉）。現在，輪到你打開它，親自看一眼你網站程式碼背後的真面目了。這個動作，會是你 SEO 功力開始拉開差距的起點。
常見問題
F12 開發者工具是什麼？
檢視原始碼跟 F12 有什麼不一樣？
動態渲染的網站怎麼檢查 SEO 標籤？
為什麼我在 F12 搜不到 title 標籤？
F12 看到的 DOM，等於 Googlebot 看到的嗎？
操作步驟
- 開啟 F12 開發者工具：Windows 按 F12 或 Ctrl+Shift+I，Mac 按 Cmd+Option+I。
- 切到 Elements 面板，按 Ctrl+F（Mac 為 Cmd+F）叫出搜尋框。
- 依序搜尋 title、meta description、H1、canonical、og:type，逐項比對「你設定的內容」與「頁面實際輸出的內容」是否一致。
- 用左上角的元素選擇器（檢查模式的小箭頭）點過主標題，確認畫面上最大的字在 DOM 裡真的是 H1，而不是 div 套 font-size 撐出來的假象。
- 按 Ctrl+Shift+M（Mac 為 Cmd+Shift+M）切換行動版裝置工具列，再搜一次同樣的標籤，比對桌面版與行動版輸出是否一致。