怎麼看網頁原始碼？SEO 人必會的網頁開發者工具（F12） | 白話文商學院
在瀏覽器按一個鍵就能看見瀏覽器真正渲染後的 HTML，判斷 title、meta description、H1、canonical、og 標籤有沒有正確輸出，連動態渲染的 SPA…
F12 開發者工具是什麼？為什麼 SEO 一定要會
在瀏覽器按一個鍵就能看見瀏覽器真正渲染後的 HTML，判斷 title、meta description、H1、canonical、og 標籤有沒有正確輸出，連動態渲染的 SPA 網站也能檢查，不必等工程師開票。Chrome、Edge、Firefox 都內建這個面板，Windows 按 F12、Mac 按 Cmd+Option+I 就能開啟 [來源：Chrome for Developers〈Chrome DevTools〉 https://developer.chrome.com/docs/devtools 2024]。F12 開發者工具是 SEO 人最快的自助驗證工具，三十秒內可以做完一次標籤健檢。
重點先看：檢查 SEO 標籤要用 F12 的 Elements 面板，因為它顯示的是 JavaScript 執行後瀏覽器真正渲染出來的最終 DOM，而伺服器回傳的初始 HTML 看不到動態產生的標籤，這點在 Chrome DevTools 的 Elements 面板官方說明裡有明確記載 [來源：Chrome for Developers〈Inspect and Edit Pages and Styles〉 https://developer.chrome.com/docs/devtools/dom 2024]。按 F12 → Elements → Ctrl+F 搜尋 title、H1、canonical、og:type，三十秒做完一次自助健檢。
很多人第一次按到 F12 是一場意外。原本想按 F11 把瀏覽器切到全螢幕，結果手指多跨了一格，畫面突然冒出一大排夾著角括號的程式碼，還以為把網站弄壞了。這個反應很正常，我也不例外。但說到底，那個被嚇到的畫面就是 F12 開發者工具，是現代瀏覽器內建的檢查面板，SEO 人拿它來驗證標籤有沒有輸出，而不是去改程式。
會看、會搜尋就夠，不需要會寫程式。先把一個觀念弄清楚：F12 預設打開的 Elements（元素）面板顯示的是瀏覽器渲染後的 DOM，也就是使用者與搜尋引擎最終看到的結構，而伺服器回傳的原始碼只是渲染前的起點，根據 Chrome DevTools 官方文件，Elements 面板呈現的就是執行階段後的 live DOM [來源：Chrome for Developers〈Inspect and Edit Pages and Styles〉 https://developer.chrome.com/docs/devtools/dom 2024]。這個差異在動態渲染網站上會決定你看到的是真象還是假象，後面會專門拆開講。
SEO 人的核心需求是「驗證標籤有沒有輸出」，所以聚焦在 Elements 面板就好。其他像 Console、Sources、Network 這些面板，對入門者來說可以先放著。基礎觀念還不夠熟的話，建議先把 SEO 是什麼的入門基礎觀念 走一遍，工具操作起來會更有感。用 WordPress 架站的人，這套檢查邏輯也可以直接對接 WordPress SEO 必做的幾項設定，遇到 依登入狀態切換的會員選單 也能用同樣方式檢查結構。
為什麼 SEO 特別需要這套工具，背後有兩個現實原因。第一個現實是分工邊界。SEO 人負責設定標籤內容，但標籤會不會真的輸出到 HTML、會不會被佈景主題或外掛覆蓋，往往落在工程與前端的職責範圍。如果每遇到一個疑問就開票等工程師回覆，排程動輒拉長好幾天，問題還可能在傳話過程中變調。F12 讓 SEO 人自己把「設定值」和「實際輸出值」對齊，發現落差時再帶著明確證據溝通，省下來的不只是時間，還有來回誤解的成本。第二個現實是動態渲染普及。React、Vue、Next.js 構成的單頁應用（SPA）越來越常見，這類網站的標籤大量由 JavaScript 在載入後才產生，傳統檢視原始碼的方法會整段漏掉，只有渲染後的 DOM 才看得到全貌。把這兩個現實放在一起，就會理解為什麼「會用 F12」已經從加分技能變成 SEO 入門的基本動作。
Elements、Console、Network、Sources 各自能幫 SEO 做什麼
開發者工具不只有 Elements 一個面板，但 SEO 用得到的範圍很明確。把四個常用面板各自能解決的問題拆開，操作時就不會迷失在介面裡。
| 面板 | 主要用途 | SEO 常見應用 | 入門難度 |
|---|---|---|---|
| Elements | 檢視與暫時編輯渲染後的 DOM | 搜尋並比對 title、H1、canonical、og 標籤實際輸出 | 低，第一個該學 |
| Console | 顯示 JavaScript 錯誤與警告訊息 | 排查代碼載入失敗、結構化資料格式錯誤 | 中 |
| Network | 記錄頁面發出的所有請求與回應 | 確認 GA、GTM 資料真的送出，檢查回應狀態碼 | 中高 |
| Sources | 瀏覽頁面載入的全部檔案與原始碼 | 找代碼片段實際寫在哪個檔案、檢查 JS 內容 | 中高 |
SEO 日常八九成的工作落在 Elements，其餘三個面板視情況搭配。Console 出現紅字代表 JavaScript 出錯，這往往連帶讓仰賴 JS 的標籤或代碼跟著失效；Network 用來驗證「代碼裝了，但資料到底有沒有送出去」這種最難抓的問題；Sources 則適合在你需要回報「這段標籤是哪個檔案輸出的」時派上用場。先顧好 Elements，再隨問題往其他面板延伸，是比較穩的學習路徑。
各瀏覽器怎麼開啟開發者工具：快捷鍵總整理
不同瀏覽器、不同系統要按的鍵不一樣。Chrome 與 Edge 在 Windows 按 F12 或 Ctrl+Shift+I，Mac 按 Cmd+Option+I；Firefox 按 Ctrl+Shift+I（Windows）或 Cmd+Option+I（Mac）；Safari 要先在設定裡開啟開發選單，再按 Cmd+Option+I，各瀏覽器的快捷鍵整理可見 MDN Web Docs 與 Apple Safari 開發者工具說明 [來源：MDN Web Docs〈Firefox Developer Tools〉 https://developer.mozilla.org/docs/Tools 2024]。Mac 鍵盤沒有直覺的 F12，記 Cmd+Option+I 比較省事。
這裡最常被卡住的是 Safari。Safari 預設把開發選單藏起來，你得先到「設定 → 進階」，勾選「在選單列顯示開發選單」，這個選項才會出現，Apple 開發者文件對 Safari 開發者工具的啟用流程有完整記載 [來源：Apple Developer〈Safari Developer Tools〉 https://developer.apple.com/safari/tools/ 2024]。Mac 使用者如果照著 Chrome 的習慣按 F12 卻沒反應，多半就是這個原因，並不是鍵盤壞了。
| 瀏覽器 | Windows 快捷鍵 | Mac 快捷鍵 | 前置設定 |
|---|---|---|---|
| Chrome | F12 或 Ctrl+Shift+I | Cmd+Option+I | 無，內建 |
| Edge | F12 或 Ctrl+Shift+I | Cmd+Option+I | 無，內建 |
| Firefox | Ctrl+Shift+I | Cmd+Option+I | 無，內建 |
| Safari | 不適用 | Cmd+Option+I | 需先勾選顯示開發選單 |
把這張表存起來，第一次操作時對著按就好。我在接手別人交接過來的網站時，第一個動作一定是開 F12 確認標籤現況，連 HTTPS 與網站安全、網址與 SEO 的關係 這種基礎項目也順手看一眼，這比看文件快得多。想檢查 canonical 標準網址的作用與寫法 有沒有正確帶上，也是同一個流程。
從選單開啟與重新停靠面板的兩個小訣竅
除了快捷鍵，每個瀏覽器也能從選單開啟開發者工具。Chrome 與 Edge 在右上角的三點選單裡找「更多工具 → 開發人員工具」；Firefox 從選單的「更多工具 → 網頁開發者工具」進入；Safari 開啟開發選單後，從選單列的「開發」裡點「顯示網頁檢閱器」。快捷鍵記不起來的時候，走選單永遠是備案。
面板預設停靠在瀏覽器視窗下方，但有時候你會希望它獨立成視窗，方便對照。在面板右上角的三點選單裡可以切換停靠位置：靠下、靠右、靠左，或獨立成浮動視窗。習慣雙螢幕的人把面板拉成獨立視窗放到第二個螢幕，主螢幕保留給網頁本身，檢查與瀏覽可以同時進行。另外，按 Ctrl+Shift+M（Mac 為 Cmd+Shift+M）能切換裝置模式，這個功能後面講行動版檢查時會用到。
用 Elements 面板搜尋標籤
打開 Elements 面板後，按 Ctrl+F（Mac 為 Cmd+F）輸入標籤名稱，例如 title、description、canonical、og:type，就能直接跳到該標籤在 HTML 中的位置，確認內容是否與你設定的相符。這個 Ctrl+F 搜尋動作是 SEO 標籤健檢裡出現頻率最高的一個操作。
搜尋的關鍵在於你輸入的是標籤名稱，而內容只是次要。想看 title 就搜「title」，想看 meta description 就搜「description」，想看標準網址就搜「canonical」。Elements 會把符合的位置全部列出來，你點過去就能看到實際輸出的值。比對「你設定的內容」與「頁面實際輸出的內容」是否一致，不一致就是 SEO 隱患。舉個例子，你在 CMS 裡把 title 改成了新版本，但快取沒清，F12 裡搜尋出來的還是舊 title，這時你就知道問題出在哪，無需再猜測。
title 標籤漏掉的情況比想像中常見。一份針對 953,276 個排名前十頁面的研究發現，有 7.4% 的排名頁面根本沒有 title 標籤 [來源：Ahrefs〈Title Tag Study: 7.4% of Top-Ranking Pages Don't Have a Title Tag〉 https://ahrefs.com/blog/title-tags-study/ 2021-10-21]。換句話說，就算你以為標題一定會輸出，實際上仍有一小群頁面在這一步就漏了。用 F12 搜「title」花十秒就能確認這件事，比事後在搜尋結果看到空白標題才補救省事得多。
常用檢查清單
- title：頁面標題，搜尋結果與瀏覽器分頁顯示的主標，title 標籤要怎麼寫才正確 有完整寫法。
- meta description：搜尋結果下的描述文字，搜「description」即可。
- h1 到 h4：標題層級，建議一個頁面只有一個 H1。
- canonical：標準網址，避免重複內容被當成不同頁面，搜「canonical」。
- og:type、og:title、og:image：Open Graph 標籤，控制分享到社群時的預覽，Open Graph 標籤如何設定 有細節。
- 結構化資料：schema.org 標記，搜「application/ld+json」可以找到，結構化資料的意義與檢查方式 是延伸閱讀，想深入標記寫法可參考 結構化資料 Schema 標記完整教學。
順手檢查重複標籤。一個頁面出現兩個 H1 或兩個 canonical 就要處理，這種問題用肉眼讀 HTML 很難抓，但在 Elements 裡搜尋一次就無所遁形。重複的 canonical 會讓搜尋引擎搞不清哪一個才是你要的標準網址，連帶影響 重複內容問題與解法 的判定。如果你懷疑頁面被下了 noindex 標籤的 SEO 效果，也是搜「noindex」一秒見真章。
確認 title 與 H1 是否如實輸出，不只是基本功，還會直接影響搜尋結果上顯示的標題。Google 其實會改寫 title 標籤，比例高達 33.4%，而當它決定不用 title 標籤時，有 50.76% 的情況會直接從 H1 抓取做為搜尋結果標題 [來源：Ahrefs〈Title Tag Study: 7.4% of Top-Ranking Pages Don't Have a Title Tag〉 https://ahrefs.com/blog/title-tags-study/ 2021-10-21]。這就是為什麼用 F12 同時確認 title 與 H1 這麼重要，一旦 title 缺漏或與 H1 不一致，搜尋結果上的標題可能完全不是你設定的版本。
title 的長度也值得在這個步驟順手留意。研究顯示，長度落在 40 到 60 個字元的 title 標籤有較高的點擊率，比落在這個範圍之外的 title 高出約三成三 [來源：Backlinko〈Google CTR Stats: We Analyzed 4 Million Google Search Results〉 https://backlinko.com/google-ctr-stats 2025-04-16]。字數過長的 title 還會提高被改寫的機率，前面提到的同一份 Ahrefs 研究指出，超過 600px 寬度的 title 被 Google 改寫的比率明顯上升 [來源：Ahrefs〈Title Tag Study〉 https://ahrefs.com/blog/title-tags-study/ 2021-10-21]。在 Elements 搜到 title 之後，順手數一下字數，太長就回去精簡，這個動作幾乎不用花額外時間。
講了這麼多標籤，其實節奏很固定：開 F12、開 Elements、按 Ctrl+F、打標籤名、看結果。這個動作我一天可能做十幾次，比開任何 SEO 軟體都快。檢查 內部連結與網站架構優化 用到的連結結構、或是 各類連結的區分與作用，也都能用同一套搜尋邏輯驗證。
搜尋不到標籤時的四種排查方向
Ctrl+F 搜不到 title 或 H1，是最常讓 SEO 人慌起來的瞬間。先別急著認定網站出問題，按下面四個方向依序排除，多半能在五分鐘內定位原因。
- 搜尋範圍設錯：Elements 的 Ctrl+F 預設只搜尋 DOM 樹，如果你切到 Console 或 Network，搜尋行為會跟著變。確認游標焦點回到 Elements 面板再按一次。
- 頁面還沒渲染完：SPA 網站的標籤要等 JavaScript 跑完才出現，頁面剛載入就搜會撲空。等畫面完全顯示，或在 Network 面板確認主要請求都回傳後再搜。
- 標籤真的漏了：搜不到就是搜不到，這時要回 CMS 或佈景主題確認該標籤的輸出邏輯，而不是懷疑工具壞掉。前述 7.4% 排名頁面缺 title 的數據，就證明漏掉是真實存在的狀況。
- 快取擋在中間：瀏覽器快取、CDN 快取、頁面快取外掛都可能讓你看到舊版本。開無痕視窗或強制重新整理（Ctrl+Shift+R）再搜一次，能排除快取干擾。
這四個方向涵蓋了搜尋失敗的絕大多數原因。把它們當成制式的排查流程，遇到搜不到時照著走一遍，會比直覺式亂點有效率得多。真正屬於「標籤漏掉」的情況，往往要走到第三步才會確認，前面兩步先排除掉，能避免把正常的渲染延遲誤判成 SEO 事故。
檢查箭頭與右鍵檢查：從畫面反查背後的程式碼
看到網頁上某段文字，想知道它是用哪個標籤包起來的，有兩種做法。一是點開發者工具左上角的「檢查箭頭」，再把游標移到想檢查的元素上，Elements 會自動跳到對應程式碼；二是直接在網頁上把元素框起來、按右鍵選「檢查」，效果一樣。
檢查箭頭的位置在開發者工具面板左上角，圖示是一個游標指向方框的樣子。點下去之後它會變成啟用狀態，這時你把游標移到網頁上，每停在一個元素，那個元素就會被色塊框起來，同時 Elements 面板裡對應的那一行程式碼會自動反白。這招很適合拿來驗證「這段標題到底是不是 H1」「這段文字是不是用 H2 而非單純的粗體」。我遇過不少案例，視覺上看起來是大標題，實際上卻是用 div 加 font-size 撐出來的，搜尋引擎根本讀不到層級，這時只有檢查箭頭會戳破這個假象。
右鍵檢查則更直覺，新手更常用。把游標移到目標元素上直接按右鍵，選單裡點「檢查」，Elements 就會跳到那段程式碼。用來驗證圖片 alt 屬性有沒有寫、連結的 rel 設定對不對、按鈕結構是否符合預期，都靠這個動作。兩種方法的差別只是入口不同，結果完全相同，挑你順手的就好。
不過話說回來，檢查箭頭在版面複雜的頁面上更好用，因為你可以連續移動游標逐層切換元素，無需每次都重新框選。確認 反向連結與網域權重 的連結屬性、或是排查 SEO 友善的網站架構 裡的層級問題，這個小工具能省下不少時間。如果你想更系統化檢查整站，Screaming Frog 爬蟲工具教學 會是下一步，但單頁除錯時 F12 仍是首選。要擴大檢查範圍到全站結構時，Ahrefs 完整教學 與 Ubersuggest 深度評測 都能補上批量分析的視角。
用檢查箭頭抓出五種常見的標題假象
視覺上的大標題和 HTML 裡的標題層級，經常是兩回事。版面設計師追求的是畫面好看，搜尋引擎讀的卻是標籤結構，兩者目標不同就會產生落差。有幾種常見的「看起來是標題、其實不是」狀況，只有用檢查箭頭實際點過去才會現形。
- 粗體放大當標題：設計師用 div 包文字，再套 font-weight 與 font-size 把字撐大，畫面上像是 H1，DOM 裡卻只是一個普通區塊，搜尋引擎讀不到任何標題層級訊號。
- H1 連續堆疊：同一頁塞了多個 H1，每個都用來強調不同的版塊主題。視覺上無害，結構上卻讓搜尋引擎搞不清哪一個才是頁面主軸。
- H2 直接跳到 H4：跳過 H3 直接用 H4，層級斷裂會削弱標題結構傳遞的資訊，等於自動放棄了一個結構訊號。
- 整段標題用圖片呈現：把標題做成圖片檔，外層連 alt 都沒寫，搜尋引擎看到的是一個沒有文字意義的 img 標籤。
- 標題藏在按鈕或連結裡：把主標包進 a 或 button 元素，雖然字很大，但語意上被歸類為互動元件，未必等同於獨立的標題層級。
這幾種狀況在改版後的網站特別常見。設計稿定案、版面切好之後，SEO 人若沒有在最後階段用檢查箭頭逐一驗證標題層級，等搜尋結果表現下滑才回頭找原因，往往要花更大力氣。把「畫面上的大字是不是真的標題」列進上線前的檢查項目，是低成本高回報的習慣。
動態渲染網站為什麼只能靠 F12
View Source 跟 F12 看到的程式碼並不一樣。View Source 看到的是伺服器最初回傳的 HTML，不包含 JavaScript 執行後的內容；F12 的 Elements 看到的是瀏覽器渲染完成後的最終 DOM，這也是 Chrome DevTools 官方文件強調 Elements 面板與 View Source 本質不同的原因 [來源：Chrome for Developers〈Inspect and Edit Pages and Styles〉 https://developer.chrome.com/docs/devtools/dom 2024]。React、Vue 等 SPA 網站的許多標籤是 JS 執行後才動態產生，用 View Source 會看漏，只有 F12 看得到。
用包裹來比喻會比較好懂。View Source 像是看到包裹還沒拆開前的外箱標籤，上面只有出貨時貼的資訊；Elements 面板則是你拆開包裹、把東西擺出來之後看到的實際成品。對 SEO 來說，搜尋引擎和使用者最後看到的是拆開後的成品，不是外箱標籤，所以你該驗證的也是 Elements 面板裡的內容。
| 比較項目 | 檢視原始碼 View Source | Elements 面板 F12 |
|---|---|---|
| 顯示內容 | 伺服器回傳的初始 HTML | 瀏覽器渲染後的最終 DOM |
| 是否含 JS 執行結果 | 否 | 是 |
| 適用網站類型 | 傳統伺服器渲染頁面 | 所有頁面，含 SPA 動態渲染 |
| SEO 驗證可靠度 | 動態網站上不可靠 | 最接近使用者實際看到的結構 |
React、Vue、Next.js 這類前端框架，標籤常常是 JavaScript 跑完才產生的。你在這種網站上按 View Source，可能整個 body 裡只有一個掛載點 div，什麼 title、H1 都看不到，但頁面實際顯示出來明明有內容。這就是動態渲染造成的落差，也是 JavaScript SEO 與動態渲染的關係 之所以需要專門處理的原因。若你懷疑 Google 爬蟲到底抓不抓得到這些標籤，可以進一步對照爬蟲模擬工具與 Google 搜尋引擎運作原理 裡提到的渲染機制。
退一步看，這個機制差異會直接左右你判斷對錯。同一段標籤，View Source 看得到不代表搜尋引擎看得到，反之亦然。搭配爬蟲工具與 爬取與爬取預算概念、網頁索引怎麼確認 的觀念一起看，會更清楚動態渲染對 檢索環節在搜尋流程中的位置 的影響。想知道搜尋引擎到底收錄了哪些頁面，可以再對照 GSC 網頁索引報表解讀。動態網站的收錄往往要靠一份完整的 網站 Sitemap 入門指南 來輔助。
渲染佇列與雙階段爬蟲：為什麼 SPA 容易掉標籤
搜尋引擎處理動態網站時採用兩段式流程。第一階段是「檢索」，爬蟲拿到伺服器回傳的初始 HTML，這份 HTML 在 SPA 網站上通常只有一個空的掛載點。第二階段是「渲染」，爬蟲把頁面丟進一個類似瀏覽器的環境執行 JavaScript，等標籤產生後再重新讀取。因為渲染比單純檢索消耗更多資源，搜尋引擎會把需要渲染的頁面排進佇列，等資源有空檔才處理。
這個佇列機制帶來一個直接後果：剛上線的 SPA 頁面，初始 HTML 裡沒有標籤，爬蟲第一階段抓到的就是空殼，要等到第二階段渲染完成，標籤才會被看見。在這段空窗期裡，標籤等同不存在。如果你用 View Source 驗證，看到的跟爬蟲第一階段拿到的一樣是空殼，會誤以為「標籤有輸出」；用 F12 的 Elements 驗證，看到的才是渲染後的最終 DOM，也就是爬蟲第二階段才會讀到的內容。這也是為什麼在動態網站上，SEO 人堅持用 Elements 而不用 View Source，差別就在於你驗證的是哪一個階段的結果。
實務上有兩個訊號代表你的 SPA 頁面卡在這個空窗期。第一個訊號是 GSC 網址檢查工具顯示「已檢索但未建立索引」，這代表爬蟲抓到了空殼，還沒排到渲染。第二個訊號是搜尋結果顯示的標題與你設定的 title 完全無關，常常是抓到了掛載點的預設文字或瀏覽器快取。遇到這兩種訊號，先回 F12 確認標籤在 Elements 裡看得到，再檢查初始 HTML（View Source）是不是真的空殼，就能判斷問題屬於「還沒渲染」還是「永遠渲染不出來」這兩種不同性質的狀況。
行動版與桌面版：用裝置工具列檢查兩種視角
Google 已經全面採用行動優先索引，所有能在行動裝置上運作的網站，主要都由行動爬蟲來檢索 [來源：Google Search Central Blog〈Mobile-first indexing is here〉 https://developers.google.com/search/blog/2023/10/mobile-first-is-here 2023-10-31]。這代表搜尋引擎收錄與排名時參考的，是網站的行動版本。如果桌面版標籤齊全、行動版卻漏了一兩個，受傷的會是排名而不是畫面。
F12 的裝置工具列（Device Toolbar）就是用來補這個視角的。按 Ctrl+Shift+M（Mac 為 Cmd+Shift+M）或點面板左上角的手機圖示，頁面會切換成行動版模擬，你可以選擇不同的預設裝置尺寸，也能自訂寬度。切換之後，Elements 裡搜尋出來的 DOM 會是行動版渲染後的結構，這才是行動爬蟲會看到的內容。
同一段標籤在桌面版與行動版輸出不一致的情況比想像中多。響應式設計可能在不同斷點載入不同元件，導致行動版的 H1 與桌面版不同；AMP 或獨立行動版網域更是兩套結構並存，標籤落差更明顯。把桌面版與行動版各用 F12 搜一次相同的標籤，比對兩邊輸出是否一致，是行動優先索引時代的基本檢查動作。這個步驟花不到一分鐘，卻能避免「桌面看起來沒問題、排名卻莫名下滑」這類難以察覺的狀況。
| 檢查項目 | 桌面版注意點 | 行動版注意點 |
|---|---|---|
| title 與 H1 | 確認兩者都輸出且語意一致 | 確認與桌面版相同，避免響應式切換時漏掉 |
| canonical | 指向自身或對應網址 | 行動版與桌面版 canonical 指向要一致或正確對應 |
| 結構化資料 | JSON-LD 完整輸出 | 行動版結構化資料不應缺席 |
| meta viewport | 通常已內建 | 必須存在，否則行動版渲染會失準 |
| 可點擊元素間距 | 影響體驗較小 | 太近會觸發行動可用性問題 |
檢查行動版標籤時要特別留意 viewport 中繼標籤。少了這個標籤，行動裝置會用桌面寬度渲染再縮放，畫面變小、字變糊，連帶讓 Google 判定頁面對行動裝置不友善。在 Elements 搜「viewport」，確認有一行 meta name="viewport" 開頭的標籤，是行動版健檢的基本動作。搭配 網站體驗核心指標 CWV、網頁速度優化方法 一起看，才能把行動版體驗顧到位。
F12 還能檢查什麼：GTM、GA 代碼與 SEO 健檢延伸應用
除了 SEO 標籤，開發者工具還能幫 SEO 做不少檢查。F12 能用來確認 GTM、GA4 等追蹤代碼是否真的被載入到頁面上，在 Elements 搜尋 gtag、GTM 或容器 ID 即可；進一步還能用 Network 面板看代碼是否成功發送請求，是 SEO 與數據追蹤交接時的基本功。還沒把容器建起來的人，先照著 GTM Google 代碼管理工具新手攻略 走一遍。
GTM 的容器 ID 命名格式是 GTM-XXXX，GA4 的量測 ID 格式是 G-XXXX，這兩個都是官方定義的格式，可以直接拿來當搜尋關鍵字，根據 Google 代碼管理工具與 Analytics 說明文件的命名規範。在 Elements 裡搜「GTM-」如果你的容器 ID 有掛上去，就會出現在 script 標籤裡；搜「G-」則能確認 GA4 量測代碼在線。沒搜到，代表代碼根本沒裝或裝錯頁面，這時再回去看 GTM Google 代碼管理器教學、GA4 Google Analytics 教學 的安裝步驟。
- 搜尋 GTM 容器 ID（GTM-XXXX）：確認代碼管理器已掛載到頁面。
- 搜尋 GA4 量測 ID（G-XXXX）：確認分析代碼在線，GA4 專有名詞對照 可對照名詞。
- Network 面板篩選 collect：看 GA4 的資料收集請求是否真的發出，判斷事件追蹤有沒有作用。
- 檢查 UTM 參數是否正確帶在連結上，UTM 參數與追蹤設定 有完整說明。
Network 面板對 SEO 人來說進階了一點，但它能回答一個關鍵問題：代碼到底有沒有把資料送出去。在 Network 面板的篩選框打「collect」，重新整理頁面，如果有看到 Google Analytics 的 collect 請求，代表事件追蹤真的在跑；沒看到，就算你在 Elements 裡搜得到代碼，也可能是裝了但沒觸發。想系統化檢查整站標籤與代碼，可搭配 SEO 工具軟體推薦、Ahrefs 功能與用法 做批量處理，GSC 日期快速設定器 則是報表層面的小幫手。要一次備齊分析與追蹤用得到的工具，50 款行銷人必備工具推薦 是現成的清單。
追蹤代碼的普及程度也讓這項檢查更顯必要。Google Analytics 出現在約 46.6% 的所有網站上，在已知流量分析工具的網站中更佔了 81.8% [來源：W3Techs〈Usage Statistics and Market Share of Google Analytics〉 https://w3techs.com/technologies/details/ta-googleanalytics 2026-06-29]。多數網站都裝了 GA，但裝了不等於裝對、裝對不等於資料有送出，這中間的落差正好是 Network 面板能幫你抓出來的。SEO 與數據分析共用同一套代碼基礎，把這個檢查動作練熟，等於一次照顧到兩個領域。
老實說，SEO 跟數據追蹤的邊界愈來愈模糊，很多排錯情境最後都會繞回代碼有沒有正確觸發這件事。把 Google Search Console 功能介紹、GSC 常用功能總覽、GSC 安裝與設定教學 串起來看，你會發現 F12 是把這些工具串起來的那條線。搭配 GSC 網址檢查工具用法，可以進一步確認單一網址的檢索與索引狀態，Bing Webmaster Tools 安裝 則補上另一個搜尋引擎的視角。
用 Network 面板確認事件追蹤的三步驟
Elements 能告訴你代碼有沒有掛上去，Network 才能告訴你代碼有沒有真的把資料送出去。三個步驟的流程是 SEO 人排查事件追蹤時最常用的方法。
- 開 Network 面板並保留記錄：勾選「Preserve log」，這樣頁面跳轉或重新整理時記錄不會被清空，跨頁面的事件才追得到。
- 在篩選框輸入 collect：GA4 的資料收集請求網址裡會帶有 collect 這個字串，輸入後清單只留下相關請求，雜訊瞬間歸零。
- 觸發你想測試的動作：點按鈕、送出表單、滾動到特定區塊，觸發後回 Network 看 collect 請求有沒有新增一筆，有就代表事件真的送出去了。
這個流程的最大價值，在於它能把「代碼裝了」與「資料收到」這兩件常被混為一談的事拆開。很多網站看起來裝了 GA、報表卻一片空白，追根究柢就是代碼裝了但事件沒觸發，或觸發了卻被廣告阻擋外掛攔截。Network 面板讓你直接看到請求層的真相，這比看報表數字猜原因可靠得多。
看不懂的標籤直接丟給 AI
遇到看不懂的程式碼片段，SEO 人不必自己硬啃 HTML。把 Elements 裡看不懂的程式碼片段反白複製（右鍵 → Copy → Copy element），貼給 ChatGPT、Claude 等 AI 工具並附上「這段標籤對 SEO 有什麼影響」的提問，AI 會用白話解釋結構與潛在影響。這是入門者縮短學習曲線最快的捷徑。若想用 AI 一次處理更多站務，用 Perplexity AI 管理 WordPress 的流程值得參考。
複製的重點是連屬性一起帶走。在 Elements 裡對著某個標籤按右鍵，選 Copy 再選 Copy element，就能把整段標籤連同它的屬性、內容完整複製下來，而不是只拿到可見文字。提問時附上情境效果最好，例如「這是一個產品頁的標題區塊，幫我看 SEO 是否有問題」「這段 schema 標記有沒有寫錯」，AI 才能給出貼合你需求的判斷。如果你還不熟 AI 工具的操作，ChatGPT 中文使用教學、Claude 使用技巧懶人包、AI 提示詞寫法入門 都是很好的起點。要一次檢查多組 SEO 標籤建議，ChatGPT Atlas × SEO 實戰指南 也幫得上忙。
AI 特別擅長解讀結構化資料、複雜巢狀 div、JS 框架語法這幾類讓人頭痛的東西。schema.org 標記常常一層包一層，光看 JSON-LD 就眼花，丟給 AI 它能幫你拆解每個欄位對應的意義；React 或 Vue 的元件結構有時會出現語法上的 SEO 隱患，AI 也能指出來。不過要提醒一句，AI 的判斷仍需回到 F12 實際渲染結果交叉驗證，不要全盤相信，因為 AI 幻覺 會讓它把不存在的標籤講得煞有其事。搜尋引擎對 AI 生成內容的態度可以參考 Google 對 AI 內容的看法，而 AI 時代 SEO 趨勢建議 則把工具運用放進更大的脈絡裡。
說實在的，把 AI 當成一個隨時可問的資深工程師來用，比硬啃文件有效率。我自己的習慣是，F12 搜到的可疑標籤先複製一份，丟進 AI 問一次，再拿著 AI 的解釋回去對照實際渲染結果，這個循環讓我在不懂程式的情況下也能獨立排除七八成的標籤問題。想進一步用 AI 直接調整前端程式，Vibe Coding 與 Claude Code 完整教學 都是入門的捷徑。
餵給 AI 之前要脫敏的三類資訊
把標籤丟給 AI 雖然方便，但 SEO 人手上的程式碼片段常常夾帶不該外流的資訊。貼上去之前花十秒脫敏，能避免把敏感資料送進第三方服務。
- 個人資料與會員資訊：標籤裡可能內嵌使用者名稱、Email、會員 ID，這些貼上去等於把會員資料外洩。先手動遮罩或用假值替換。
- 內部網址與測試環境：預覽網址、後台路徑、內部 API 端點，外洩後可能成為攻擊線索。改成示意用的 example.com 再送出。
- 金鑰與 token：某些標籤會把 API key 或 access token 寫在屬性裡，這類字串外洩的後果最嚴重。務必整段刪除再提問。
脫敏的動作雖然瑣碎，卻是使用外部 AI 工具時應有的基本紀律。養成「貼之前先掃一眼」的習慣，比事後補救資料外洩來得輕鬆。如果你的網站處理大量敏感資料，改用本地部署或企業版的 AI 服務會是更穩妥的選擇。
F12 標籤健檢診斷矩陣：把症狀對應到原因
把前面零散的檢查動作整理成一張診斷矩陣，遇到問題時可以直接對照症狀找出最可能的原因與下一步。這張矩陣把 SEO 人在 F12 裡最常碰到的症狀分成五類，每一類都對應一組主要原因與建議的排查動作。
| 症狀 | 最可能原因 | F12 中的排查動作 | 優先順位 |
|---|---|---|---|
| 搜不到 title | 佈景主題未輸出、外掛覆蓋、SPA 未渲染 | Elements 搜「title」；切桌面/行動版各搜一次 | 高 |
| 搜到多個 H1 | 佈景主題重複輸出、外掛插入 | Elements 搜「h1」逐一點看內容 | 高 |
| canonical 指向他頁 | 外掛預設、多語系或分頁設定 | 搜「canonical」核對 href 值 | 高 |
| noindex 出現 | 開發環境設定未移除、特定外掛勾選 | 搜「noindex」找來源標籤 | 高 |
| 結構化資料錯誤 | JSON-LD 格式錯誤、欄位缺漏 | 搜「ld+json」複製內容丟結構化資料測試工具 | 中 |
| GA collect 沒送出 | 代碼未觸發、被廣告阻擋外掛攔截 | Network 篩「collect」觸發動作觀察 | 中 |
這張矩陣的用法是「由症狀往回推原因」。當你在搜尋結果或 GSC 看到異常，先對照症狀欄找到對應列，再到 F12 執行該列的排查動作，最後依優先順位決定處理順序。標記為高優先的症狀（缺 title、重複 H1、錯誤 canonical、意外 noindex）會直接影響收錄與排名，通常要在發現當下立刻處理；中優先的症狀（結構化資料錯誤、代碼未送出）影響的是豐富結果與數據品質，可以排進當週的維護排程。
什麼情況不該只靠 F12
F12 雖然是 SEO 驗證的主力工具，但它有明確的邊界，超過這個邊界的問題需要換工具。把這幾個「不該只靠 F12」的情境記下來，可以避免在錯誤的地方耗費時間。
- 全站批量檢查：F12 是單頁工具，檢查一個頁面就要開一次。要一次掃完整站的 title、canonical、H1，應改用爬蟲類工具如 Screaming Frog。
- 驗證搜尋引擎實際視角：F12 顯示的是瀏覽器渲染結果，不等同爬蟲抓到的內容。要確認 Google 真正看到什麼，應搭配 GSC 網址檢查工具。
- 歷史變化追蹤：F12 只看當下這一刻的輸出，無法回溯昨天或上週的標籤狀態。需要歷史比對時，應建立定期快照或使用監控服務。
- 伺服器端標籤注入：標籤若是由伺服器或 CDN 層動態注入，F12 看到的是最終結果，未必能定位注入邏輯所在。這類問題要回到伺服器設定或 CDN 規則。
知道工具的邊界，與知道工具的用法一樣重要。F12 負責的是「單一頁面、當下、瀏覽器視角」的快速驗證，超出這個範圍就換成對應的工具，整體效率才會高。把 F12、爬蟲工具、GSC 三者當成互相搭配的視角，而非互相取代的競爭者，是 SEO 技術檢查走向成熟的指標。
SEO 標籤健檢清單：三十秒做完一次自助檢查
拿到一個頁面，完整的 SEO 標籤自助檢查流程是這樣的：按 F12 → Elements → Ctrl+F 依序搜尋 title、description、h1、canonical、og:type，逐項比對內容是否與設定一致，再用檢查箭頭確認主標題真的是 H1，整個流程三十秒內可完成，是上線前與排錯時的標準動作。
五項必檢標籤
- title：頁面主標，搜尋結果最顯眼的一行。
- meta description：結果頁下方的描述。
- H1：每頁建議只一個，是頁面主題的宣告。
- canonical：標準網址，防止重複內容問題。
- og:type：Open Graph 類型，影響社群分享預覽。
加分檢查項目
- og:title、og:image：分享到社群時的標題與圖片。
- 結構化資料 schema.org：用 application/ld+json 搜尋。
- noindex、robots 設定：確認頁面沒被意外封鎖，可對照 robots.txt 對 SEO 的影響 與 robots.txt 與 noindex 的差異。
- XML Sitemap：網址有沒有被收錄，XML Sitemap 與爬取優化 是基礎。
- 網址結構與查詢參數：SEO 網址命名與結構、網址組成結構拆解、網址路徑的意義、網址查詢參數解析 一併看。
重點永遠是比對「設定的內容」與「實際輸出」之間的落差，落差就是問題。SPA 網站一定要用 F12 而非 View Source，否則會漏看動態標籤，這條規則沒有例外。把這份清單跑熟之後，你可以再往策略層走，搭配 搜尋意圖與排名的關係、關鍵字對 SEO 的意義、關鍵字研究工具指南、長尾關鍵字策略 來檢視標籤內容是不是真的貼合使用者要找的東西。想把它推進到實際搶排名，關鍵字排名優化全攻略 與 Google 關鍵字排名衝刺 提供從選詞到提升的系統化做法。
競品分析也是同樣道理。F12 可以檢查競爭對手網頁的標籤寫法，把對手的 title、H1、canonical 拆開來看，你會很快抓到對方的 SEO 思路。再對照 搜尋結果頁元素介紹、獲得網站連結的技巧、網站連結 Sitelinks 怎麼拿到，你會更清楚為什麼某些頁面能佔到版面。想了解搜尋引擎收錄的相關觀念，網域與子網域觀念、網域跟網址的區分、中文網址與英文網址比較 也值得一看。現在搜尋版面多了 AI 摘要，建議再補上 AI 搜尋時代的 SEO 策略 與 AEO 優化完全指南。
講了這麼多工具操作，技術檢查本身不會讓排名往上爬。標籤全對、結構沒問題，只是把基本功做齊；真正決定頁面能不能排上去的是內容本身。所以 E-E-A-T 內容品質原則 有沒有落實、Entity SEO 核心概念 建得夠不夠、資訊增益與內容差異化 是否到位，這些才是接下來要花力氣的地方。網站體驗也得一起看，網站體驗核心指標 CWV、網頁速度優化方法、INP 與 FID 的差別 都會被搜尋引擎算進評價，想做更全面的調校可看 網站速度優化全攻略。內容上線後照著 年度內容更新建議 定期回頭檢視，舊文才不會失準。版面規劃也影響停留與轉換，給品牌網站的設計建議 提供了務實的方向。順帶一提，黑帽白帽 SEO 差異 的界線要分清楚，F12 是用來查問題的，而鑽漏洞不是它的用途；想把重複性檢查交給自動化流程，AI Agent 從運作原理到自動化代理 是值得認識的下一步。
把健檢變成例行：上線前、改版後、季盤點三個時機
三十秒健檢的價值，要靠固定的執行時機才能兌現。把這套流程嵌進日常工作流的三個關鍵時機，技術問題才會在釀成排名傷害之前被攔下來。
- 頁面上線前：每一篇新內容發布前，作者或 SEO 人都用 F12 跑一次五項必檢。這個動作能在標籤進入搜尋引擎視野之前就把問題擋住，成本最低。
- 網站改版後：改版動到佈景主題、外掛或前端框架之後，全站的標籤輸出邏輯可能跟著變。抽幾個代表性頁面（首頁、分類頁、文章頁、產品頁）各檢查一次，能及早發現系統性問題。
- 季度盤點：每隔一段時間，把流量最高的十幾個頁面拿出來重新健檢。外掛更新、快取規則調整都可能讓原本正常的標籤悄悄走樣，定期複查才能維持。
三個時機對應的是三種不同的風險來源。上線前防的是「新內容自帶問題」，改版後防的是「系統變動牽連舊內容」，季盤點防的是「時間累積造成的悄悄漂移」。把這三個時機排進工作曆，健檢就不會淪為「想到才做」的隨機動作，而是穩定的品質防線。
常見問題 FAQ
F12 開發者工具是什麼？
瀏覽器內建的檢視面板，不用安裝任何外掛。SEO 人靠它確認 title、H1、meta description 這類標籤究竟有沒有實際渲染到頁面上。
Chrome 開發者工具的快捷鍵是什麼？
Windows 環境按 F12 或 Ctrl+Shift+I，Mac 按 Cmd+Option+I。Edge、Firefox 的 Mac 組合同為 Cmd+Option+I；Safari 比較特別，得先到設定裡把開發選單打開才能用。
檢視原始碼跟 F12 有什麼不一樣？
前者只給你伺服器送出的初始 HTML，JavaScript 跑完才產生的標籤看不到；後者顯示瀏覽器渲染後的最終 DOM。SPA 網站的標籤大多屬於動態產生，只有 F12 看得到全貌。
動態渲染的網站怎麼檢查 SEO 標籤？
同樣開 F12 的 Elements，靠 Ctrl+F 搜尋標籤名。React、Vue 這類框架的標籤多半要等 JavaScript 執行完才出現，檢視原始碼會整個漏掉。
怎麼用檢查箭頭找到某個元素背後的程式碼？
點面板左上角的箭頭圖示，游標停在哪個元素，Elements 就反白哪一行。或者直接在該元素上按右鍵選檢查，走的是另一個入口，結果一樣。
F12 可以檢查 GTM 跟 GA 嗎？
可以。Elements 搜「GTM-」看代碼管理器掛上去沒，搜「G-」確認 GA4 在線；進一步開 Network 篩「collect」，則能確認資料請求確實送出。
看不懂的程式碼可以用 AI 幫忙解釋嗎？
可以。把 Elements 裡的標籤整段複製下來（右鍵 Copy element），連同情境一起丟給 AI 問。不過 AI 的判斷要再回到 F12 的實際渲染結果對照，別直接採信。
canonical 跟 og:type 在 Elements 哪裡找？
開 Elements 後按 Ctrl+F，把 canonical 和 og:type 各搜一次，面板會列出所有命中位置，點進去就能看到實際值，再跟你設定的內容比對。
SEO 一定要會用開發者工具嗎？
建議要會。它是少數不必麻煩工程師、自己就能驗證標籤的工具，半分鐘能跑完一次健檢，上線前和排錯時都派得上用場，上手門檻其實不高。
行動版標籤也要用 F12 檢查嗎？
要。Google 採行動優先索引，行動爬蟲看到的內容才是排名依據。按 Ctrl+Shift+M（Mac 為 Cmd+Shift+M）切換裝置工具列，就能在 F12 裡看到行動版渲染後的 DOM，再把桌面版與行動版的標籤各搜一次比對是否一致。
為什麼我在 F12 搜不到 title 標籤？
常見有四個方向：搜尋範圍跑到別的面板、SPA 頁面還沒渲染完、標籤真的漏了、被快取擋住看到舊版本。先確認焦點在 Elements、等頁面渲染完再搜、開無痕視窗排除快取，多數情況能定位原因。
F12 能取代爬蟲工具做全站檢查嗎？
不能。F12 是單頁工具，檢查一個頁面要開一次，全站批量掃描應改用 Screaming Frog 這類爬蟲工具。F12 適合單頁除錯與深入檢查，兩者搭配而非互相取代。