技術SEO怎麼做：抓取、索引、Canonical 與渲染排查清單

技術SEO不是一堆神秘引數，也不是“只有程式設計師才看得懂”的最佳化工作。它本質上只回答一個問題：Google 能不能順暢地發現、抓取、渲染、理解並索引你的網站頁面。如果這條鏈路的任何一環出問題，內容再好，排名也很難穩定。

Google Search Central 在 Google Search technical requirements 和 Crawling and indexing 文件裡把底層邏輯寫得很清楚：頁面要能返回正常狀態碼、包含可索引內容，並且沒有被技術性地擋在 Google 之外。也就是說，技術SEO不是附屬項，而是所有內容最佳化和結構最佳化的前提。

什麼是技術SEO，它到底在解決什麼

對一個網站來說，技術SEO至少會影響這 4 件事：

• 頁面發現。 Google 能不能找到你的重要 URL。
• 頁面抓取。 Googlebot 能不能正常訪問這些頁面和關鍵資源。
• 頁面理解。 Google 能不能看懂頁面結構、規範版本和主要內容。
• 頁面索引。 頁面最終能不能進入索引並參與搜尋結果展示。

如果你在 Search Console 裡經常看到“已發現，尚未編入索引”“已抓取，尚未編入索引”“替代頁（具有適當的規範標記）”這類狀態，那問題多半已經不是“再多發幾篇文章”，而是技術鏈路需要排查。

第一步：先按 Google 的真實處理流程來看問題

技術SEO最容易混亂的地方，就是把很多問題混在一起。更穩的方式是按 Google 處理頁面的順序來判斷：

1. 發現 URL。
2. 抓取 HTML 和關鍵資源。
3. 渲染頁面內容。
4. 理解 canonical、後設資料和主要正文。
5. 決定是否進入索引。

Google 在 JavaScript SEO basics 裡明確提到，Google 處理 JavaScript 頁面時也遵循抓取、渲染、索引這條主線。也就是說，技術排查時不要一上來就談“收錄差”，而要先問：是沒發現、抓不到、渲染不出來，還是被 canonical / noindex / 質量判斷擋住了。

如果你需要一個更適合團隊協作的拆法，Ahrefs 對技術 SEO 的分層解釋很有參考價值。它把問題拆成 crawlability、indexability、renderability 三層，用來安排排查順序很實用，不容易把所有報錯堆進一張“大清單”。

第二步：先看狀態碼和可索引性，不要只看頁面能不能開啟

很多頁面在瀏覽器裡“看起來能開啟”，但對 Google 來說並不一定是合格頁面。Google 的技術要求文件首先強調的是：頁面要返回成功狀態碼，並且有可索引內容。

這一步最容易出問題的地方有：

• 錯誤狀態碼。 例如真實不存在頁面卻返回 200，形成 soft 404。
• 被 noindex 排除。 頁面能訪問，但被明確要求不進入索引。
• 登入牆或許可權限制。 使用者能看，Googlebot 未必能看。
• 正文太弱或主要內容不可見。 頁面有模板，但缺乏真正可索引的主體內容。

所以單頁診斷時，優先看 Google Search Console 實操清單 裡的 URL Inspection，而不是隻看瀏覽器或 `site:` 搜尋結果。

第三步：robots.txt 管的是抓取，不是索引

這是技術SEO裡最常見、也最容易被誤用的點。Google 在 Introduction to robots.txt 裡寫得非常直接：robots.txt 主要用來控制爬蟲訪問，不是用來讓頁面“從 Google 消失”的機制。

這意味著：

• 一個被 robots.txt 禁抓的 URL，仍然可能因為外部連結而出現在搜尋結果裡。
• 如果你真正不想讓頁面出現在 Google，應該優先用 noindex 或許可權控制。
• 如果重要的 CSS、JS、圖片資源被誤遮蔽，Google 可能就無法正確渲染頁面。

Google 還在 How Google interprets the robots.txt specification 文件裡說明了 `allow`、`disallow` 和 `sitemap` 的規則。實操裡更重要的結論不是背語法，而是：robots.txt 只該阻止你不希望浪費抓取預算的內容，而不該誤傷關鍵頁面和關鍵資源。

第四步：sitemap 是提示重要 URL，不是收錄保證

sitemap 的作用經常被高估。Google 在 Build and submit a sitemap 裡強調，sitemap 是告訴搜尋引擎你希望展示在搜尋結果裡的 canonical URL，但它並不保證這些 URL 一定會被抓取或收錄。

真正容易翻車的是下面幾點：

• 只把你真正希望被搜尋結果使用的 canonical URL 放進 sitemap。
• 不要把 noindex、重定向頁、錯誤頁和重複頁塞進去。
• 大站點要注意 sitemap 的體積和拆分方式。
• 如果站內內鏈本來就很完整，sitemap 是加強發現效率，不是替代結構。

所以別指望提交個 sitemap 就萬事大吉。它就是塊引路牌，路牌再清楚，房子是危房，Google 照樣不進去——質量不夠、規範訊號打架、渲染失敗這些深層問題，sitemap 一個都管不了。

第五步：canonical 決定 Google 該認哪一個版本

技術SEO裡另一個高頻問題，是重複 URL 和規範頁判斷混亂。Google 在 What is canonicalization 文件裡說明，canonicalization 本質上是在重複版本里選擇代表 URL。

常見場景包括：

• 帶引數和不帶引數的 URL。
• HTTP / HTTPS 或帶不帶 www 的歷史版本。
• 分頁、篩選、排序產生的大量近重複頁。
• 同一內容被多個路徑承接。

技術上真正危險的不是“存在重複頁”本身，而是訊號衝突。例如：

• sitemap 提交的是 A，但 canonical 指向 B。
• 內鏈大量指向引數版，但你想讓 Google 認無引數版。
• 頁面自稱 canonical，但又被重定向到別處。

一旦這些訊號不一致，Google 就會自己選版本，而不是聽你的。結果往往就是索引異常、頁面分權和抓取浪費。

Moz 對 canonicalization 的解釋很適合拿來做團隊溝通，因為它講清楚了一件常被忽略的事：canonical 只有在站內其他訊號不打架時才最穩定。你一邊 canonical 指向 A，一邊 sitemap 推 B，一邊內鏈又集中指向 C，這種情況本來就容易失控。

第六步：JavaScript 頁面要重點檢查“Google 最終看到什麼”

如果網站用了大量 JS、前端元件或 SPA 架構，技術SEO的風險會更高。Google 在 JavaScript SEO 文件裡已經明確說明：Google 會先抓取，再排隊渲染，再基於渲染後的 HTML 做進一步理解和索引。

這裡有個很多人想當然搞錯的細節：渲染不是即時的，而是排隊的。Google 官方 2019 年說渲染中位數是 5 秒，聽起來很快；但 MERJ 和 Vercel 在 2024 年對 10 萬多次真實 Googlebot 抓取做的實測給出了完全不同的分佈——中位數其實是 10 秒，但長尾遠比想象誇張：

來源：MERJ × Vercel 對 10 萬+ 次 Googlebot 抓取的實測（2024）、Google 官方 5 秒中位數口徑（2019）

這組資料能直接解釋一個常見現象：「JS 頁面有時收錄得快、有時拖好幾天」不是玄學，而是渲染佇列的真實分佈。你重要的頁面如果落在那條長尾裡，等渲染排到它可能已經是幾小時後——這段時間裡 Google 看到的就是沒渲染的空殼。所以越是依賴客戶端渲染的關鍵頁，越值得把主內容放進初始 HTML，別賭它能快速排到隊。

在實操層面，Search Engine Journal 對 JavaScript SEO 的排查思路也有參考價值。它的重點不是多講概念，而是提醒你把渲染後的連結、標題、後設資料和主內容當成真實檢查物件，而不是隻盯開發環境裡那份原始碼。

這帶來幾個實操重點：

• 重要正文最好能在初始 HTML 或穩定渲染結果中被看到。
• 重要連結必須是可抓取的標準 <a href>，而不是隻靠點選事件。
• 不要讓 canonical、title、robots 等關鍵標籤在渲染後產生衝突。
• 如果頁面嚴重依賴客戶端渲染，優先考慮 SSR、預渲染或更穩定的服務端輸出。

很多“頁面可訪問但遲遲不穩定”的案例，問題根本不在正文寫得不好，而在於 Google 渲染後的頁面和你在瀏覽器裡看到的版本並不完全一致。

第七步：結構化資料和頁面後設資料是“幫助理解”，不是補救一切

結構化資料、title、description、robots meta 等訊號都屬於頁面理解層。Google 在 Introduction to structured data markup 裡明確說，結構化資料可以給 Google 提供更明確的語義線索，並可能幫助頁面獲得更豐富的搜尋展現。

但要注意兩個邊界：

• 結構化資料不能替代真實可見內容。
• 錯誤、空洞或和頁面正文不一致的 structured data，價值很低，甚至會製造額外問題。

對於企業站來說，更務實的做法通常是：

• 先保證 title、description、canonical、robots 等基礎後設資料一致。
• 再補充合適的 JSON-LD，而不是亂上各種 schema 型別。
• 釋出後用 Rich Results Test 和 URL Inspection 驗證，而不是隻看前端原始碼。

第八步：技術SEO排查時，優先抓這 6 個高頻問題

1. 重要頁面沒有被正常發現或內鏈支援太弱。
2. robots.txt、noindex、canonical 訊號互相打架。
3. 返回碼異常或 soft 404 太多。
4. JavaScript 渲染後正文、連結或後設資料不完整。
5. sitemap 包含了不該提交的 URL，或漏掉重點 URL。
6. 結構化資料、title、description 與頁面任務不一致。

這 6 類問題解決得差不多，很多站點的索引穩定性和內容承接關係就會明顯改善。它們比“再研究幾個新技巧”更值得優先處理。

技術SEO最常見的 7 個錯誤

• 把 robots.txt 當成去索引工具來用。
• 認為提交 sitemap 之後收錄問題就自動解決。
• canonical、重定向、內鏈和 sitemap 指向不一致。
• 前端頁面看起來正常，但 Google 渲染結果並不完整。
• 把結構化資料當作內容和索引問題的補救藥。
• 只看原始碼，不看 URL Inspection 的 live 結果。
• 技術排查不分層，把抓取、渲染、索引和質量問題混成一團。

一份可直接執行的技術SEO檢查清單

1. 先確認關鍵頁面返回正常狀態碼，並且沒有被 noindex。
2. 檢查 robots.txt 是否誤遮蔽頁面或關鍵資源。
3. 核對 sitemap 裡提交的是否都是 canonical URL。
4. 檢查 canonical、重定向、內鏈和實際可訪問 URL 是否一致。
5. 對 JS 頁面用 URL Inspection 看渲染後 HTML 是否完整。
6. 驗證 title、description、robots 和 structured data 是否與頁面任務匹配。
7. 最後再回到 GSC，看索引狀態是否開始穩定改善。

如果你想把上面的排查順序繼續往下落，可以順著這些主題繼續看：

• Google Search Console 實操清單
• 內鏈最佳化指南
• 頁面速度最佳化指南
• Schema Markup 指南
• 谷歌SEO內容最佳化指南

常見問題 FAQ

技術SEO是不是隻適合大網站？

不是。小網站同樣會遇到抓取、規範化、渲染和索引問題。規模越小，問題通常越少，但並不代表不需要檢查。

robots.txt 能不能阻止頁面出現在 Google？

不能完全保證。Google 官方已經明確說明，被 robots.txt 禁抓的 URL 仍可能因為外部連結而出現在結果裡。真正要防索引，優先用 noindex 或許可權控制。

提交 sitemap 之後，頁面就一定會被收錄嗎？

不一定。sitemap 是發現和提示機制，不是收錄承諾。頁面質量、規範訊號和可索引性仍然決定結果。

技術SEO和頁面速度是不是一回事？

不是。頁面速度只是技術SEO的一部分。技術SEO更大的範圍是抓取、渲染、索引、規範化和頁面可理解性。

網站問題如果表現為“頁面已經寫了很多，但 Google 仍然看不清、抓不穩、收不齊”，那優先順序往往不是繼續加內容，而是先把技術鏈路理順。技術SEO不一定最顯眼，但它通常是讓內容真正開始發揮作用的前提。