網站健檢的三個盲區：你的 SEO 檢查腳本可能在說謊

網站健檢的三個盲區：你的 SEO↗ 檢查腳本可能在說謊

太長不看版： 我們一天內用同一支驗收腳本量了自己手上的 24 個網站，結果最有價值的產出不是報告，是發現腳本本身有三個盲區。一、設定錯會造成整站假失敗——三個站初跑分別是 0/42、0/61、0/78 全紅，真因全是設定檔而不是內容。可帶走的判準：同一條 gate 命中超過 80% 的檔案，先當設定問題處理，內容真的爛不會爛得這麼整齊。二、腳本只數「引用了幾個不同網域」，不數那些網域是死是活——有一個站 92 篇文章引用的三組來源全壞，gate 卻是綠的。三、有一整類問題只有讀渲染後的 HTML 才看得見，我們為此把那部分抽出來開源了。

為什麼會有這篇：一天，24 個站，同一把尺

我們手上有二十幾個自己的網站與客戶站。2026 年 9 月 8 日，我們用同一支內容驗收腳本，在同一天把其中 24 個站全部跑過一遍——同一套門檻、同一份 gate 定義、同一個人判準。

這件事的價值不在單一站的分數。單站報告我們每週都在做。價值在橫斷面：同一把尺量 24 個結構完全不同的站（Markdown 的、MDX 的、把內容寫死在 TSX 元件裡的），腳本會在哪裡系統性地出錯，一天之內就會浮出來。

浮出來的是三個盲區。以下每一個都有具體數字，都是那天的實際輸出。

盲區一：設定造成的整站假失敗

三個站第一次跑出來的結果是這樣的：

站 B 的兩條特別值得看，因為它們是「設定檔存在、而且看起來很合理」的那種錯：

第一條：尾斜線制。 那個站的 canonical 是無尾斜線的（/tools/roi），設定檔沒有宣告 trailingSlash: false，而腳本預設是 true。結果 60 篇裡 60 篇都報「站內連結漏尾斜線」。如果照腳本的話去改，我們會親手替那個站製造 60 個 308 轉址。

第二條：moneyPaths 帶了前導斜線。 設定寫的是 ["/tools/", "/try", ...]，而腳本會把這幾個值組進一條 regex，變成 ^/(/tools/|/try…) ——永遠不會中。於是 61 篇全部報「沒有任何一條連到 money page」。改成 ["tools", "try", "pricing", "partners"] 之後，真正沒連到 money page 的只剩 5 篇。

所以可以帶走的判準是這一條：

同一條 gate 命中超過 80% 的檔案時，先假設它是設定問題，不是內容問題。

理由很簡單：內容爛是分散的。五十篇文章由不同的人在不同的月份寫出來，會用不同的方式爛掉——有的缺來源、有的太短、有的沒有內鏈。它們不會整整齊齊地在同一條 gate 上一起爛。 當你看到 60/60 或 61/61 這種數字，那不是內容的形狀，那是設定的形狀。

這條判準我們已經寫回腳本裡了：現在批次跑的時候，只要偵測到單一 gate 的命中率超過 80%，它會直接在報告最後印一行「這比較像設定問題」，並附上對應的提示。那天還有另外兩個站也是同一種病——一個是裸跑沒設定檔全紅，一個是內容寫在 React 元件的 prop 裡（<BlogArticle tldr={[...]}>），抽取器讀不到，於是 12 個 gate 全紅；修抽取器之後 0 gate。兩個都不該去改文章。

這也是這一節真正的重點：當一支自動化工具告訴你「你的內容全都不合格」時，第一個該被懷疑的是工具，不是內容。

盲區二：只數網域，不數死活

大部分內容驗收腳本（包括我們自己的）對「外部來源」的檢查是：數這篇引用了幾個不同的網域，少於三個就 gate。這條規則的假設是「引用了不同來源 = 有做功課」。

那天有一個站把這個假設打穿了。它 gate 全綠，然後我們手動點開來源：

全站 92 篇文章，引用的三組來源全壞，而腳本認為這站的引用品質沒問題。

這裡有一個比數字更重要的觀念：

引用一個 404，比完全沒有引用更糟。

沒有引用只是沒有證據。引用一個死連結，是宣稱你有證據，然後讀者一點就發現沒有。對讀者是失信，對 Google 是一個 outbound 死連結，對你自己是一個永遠不會有人告訴你的錯誤——因為沒有人會回報「你引用的那頁是空白的」，他們只會離開。

修法是把「有引用」拆成三種狀態：

blocked 這一類必須單獨存在，否則你會把好來源砍掉。實際遇過的：一個博弈相關的資料站對機器人回 451、一個資料 API 回 503、還有一個大型社群平台的網域對「假裝成 Chrome」的 User-Agent 回 400，反而用最陽春的 curl 才通得過。這三個都是活的，只是不歡迎腳本。

但這裡要誠實標出極限：這套分類只驗「連得通」，不驗「內容對不對」。上面那三組壞來源裡，只有 404 那組是腳本抓得到的。空白頁與指錯詞條那兩組，回的都是 200——只有人打開來看才會發現。 一個宣稱能驗證引用品質的工具，如果不講這句話，它就是在賣一個你其實沒有買到的保障。

寫這篇的時候我們又踩到第四種。 這篇文章的來源清單跑驗證時，Google 官方的 Search Console 說明頁被判成死連結。手動 curl 是 200，腳本說 404。

真因是請求方法：驗證器為了省流量先發 HEAD，而 support.google.com 對 HEAD 回 404、對 GET 回 200（2026-09-09 實測）。驗證器原本只在收到 405 / 501 / 403 時才改用 GET 重試，收到 404 就直接判死。

所以判準要再加一條：HEAD 回的 404 不是權威答案。 收到 404 時要用 GET 再確認一次才算數。多打的那一次請求只發生在「看起來已經死掉」的 URL 上，成本可以忽略，而代價是把一篇引用了官方文件的好文章擋在門外——假陽性擋掉真內容，比假陰性放過爛內容更貴，因為前者你會照著它去改一個沒有壞的東西。

那天另外兩個站也修了同一類問題：一個把 30 個 3xx 的來源換成 200 的直連，一個換掉 5 個真的 404。這些都是腳本抓得到的部分。抓不到的那部分，就是上面那 92 篇。

盲區三：只有渲染後才看得見的

第三個盲區是結構性的，而且無解——除非你換一個地方看。

內容驗收腳本讀的是原始檔：Markdown、MDX、或元件的 props。以下四類問題在原始檔裡完全不存在，它們是在 build 與 serve 之間產生的：

一、首屏的 U+FFFD 亂碼。 一個站有 20 個替換字元散在 11 篇文章的首屏。真因是引用修補流程有一道「先遮罩、後還原」的字串處理，遮罩了但沒還原乾淨。而它們的落點是來源的錨文字——一篇文章最需要看起來可信的那個位置。原始 Markdown 完全正常。

二、公開可見的內部 QA 區塊。 一個頁面把內部品管的字串直接印在頁面上，內容是「Word count within target band (1800-2200)」。讀者看得到。

三、JSON-LD 與 canonical 的尾斜線不一致。 一個站的 breadcrumb 結構化資料↗有 12 處 item URL 少了尾斜線，而該站的 canonical 是有斜線的。對 Google 而言那是同一頁的兩個 URL。BreadcrumbList 的 schema 定義↗ 沒有規定尾斜線，但 Google 的 canonical 說明↗ 講得很清楚：同一份內容出現在兩個 URL，你就是在讓 Google 自己猜。

四、全站 soft-404。 這一個是四個裡面最嚴重的。某個站的 hosting 有一條 ** 的 rewrite 規則，結果任何不存在的路徑都回 200。

它的後果比「Google 收到一堆重複殼頁」更狠：在這種站上，任何爬蟲都永遠不會回報死連結——因為沒有死連結，一切都回 200。那個站有 20 條打錯字的站內連結，就是這樣一直沒有被抓到。你買再貴的爬蟲工具都一樣，它會告訴你這個站的內鏈健康度是滿分。

Google 的 HTTP 狀態碼說明↗ 與 Search Console 的頁面索引報告↗ 都把 soft 404 列為明確的問題類型，但它們是事後告訴你的。而這件事你可以在三十秒內自己驗：

curl -s -o /dev/null -w "%{http_code}\n" https://你的網域/這個路徑一定不存在-12345/

回 404 或 410 就對了。回 200 的話，先修這個，其他內鏈數據在修好之前都不必看。

我們開源了第三個盲區

第三類問題的檢查邏輯是通用的——它跟你的內容策略、你的產業、你的品質標準都無關，純粹是渲染層衛生。所以我們把那部分抽出來，用 MIT 授權開源：

rendered-seo-check↗ — 單一檔案、零依賴、Node 20 以上。

# 從 sitemap 抓 URL 檢查
npx rendered-seo-check https://example.com

# 指定頁面
npx rendered-seo-check https://example.com/a/ https://example.com/b/

# 加自己的外洩樣式、輸出 JSON
npx rendered-seo-check https://example.com --leak='internal-only' --json

它會抓上面那四類，加上幾個 warn 等級的：沒有 canonical、實際送出的 meta description 長度不對（不是你 frontmatter 裡那一份）、JSON-LD 解析失敗、以及這頁其實是 noindex。有任何一頁 gate 或站台 soft-404 沒過就 exit 1，可以直接丟進 CI。

它不做的事情，README 裡寫得比做的事情還清楚：不判斷內容好壞、不驗證你引用的來源說的是不是你講的那件事、不爬站、不執行 JavaScript。這幾件事沒有一件是這種工具做得到的，講不清楚就是在賣一個你沒有買到的保障——跟上一節同一個道理。

我們沒有開源的是內容品質檢查器。 理由不是它多聰明，是它裡面每一個門檻都是我們先犯錯才校準出來的數字：AI 套語表、段落節奏的變異係數門檻、中英文各自的長度門檻、第一手證據的偵測式。把程式碼丟出來而不附那兩年的校準，你拿到的會是一支看起來像我們的、但評分不一樣的工具，那對你比沒有更糟。

渲染層衛生是 commodity，內容品質校準不是。線就畫在這裡，而且我們認為講明白比裝作沒有這回事好。

三層要怎麼組合

把三個盲區倒過來看，就是一套完整的檢查該有的三層。這三層的順序不能換，因為每一層都會讓下一層的結果變得可信：

第三層必須在部署之後跑，這是它最違反直覺的地方——大部分團隊的 CI 在部署前就結束了，於是這一層永遠沒有人跑。

而第一層要先確認設定是對的，否則你會拿到 0/61 然後去改 60 篇不需要改的文章。順序是：先信任工具之前先驗證工具。

延伸閱讀：這次橫斷面的另一個產出是我們對 2026 年 8 月 Google 演算法更新 的實測資料；索引控制與 sitemap 的基礎在 robots.txt 與索引控制指南 和 sitemap 完整指南；結構化資料的部分在 結構化資料指南。如果你要的是有人把這三層直接幫你建起來並每週跑，那是我們的 SEO 建站與代營運服務。

常見問題

為什麼腳本會全站報錯，內容卻沒問題？

因為欄位映射或站台慣例的設定跟腳本的預設不一樣。最常見的兩個是尾斜線制（站台無斜線但腳本預設有）與 money page 路徑的寫法（帶前導斜線讓 regex 永遠不中）。判準是命中率：同一條 gate 中超過 80% 的檔案，先查設定。

「命中率超過 80% 就是設定問題」這條可靠嗎？

它是啟發式，不是定律。理由是內容缺陷是分散的——不同時間不同人寫的文章不會整齊地在同一條規則上一起失敗。真的有整站同型缺陷的情況存在（例如全站教學文一條外部來源都沒有，那天就有一個站是這樣，44 篇全紅且是真的），所以它的作用是「先查設定再改內容」，不是「自動忽略」。

引用的來源被擋（403）算死連結嗎？

不算。要分成 alive、blocked、dead 三類。401/403/405/429/451/503 是對方擋機器人，來源本身是活的，把它們當死連結砍掉會讓你損失好來源。正確做法是標記出來讓人用瀏覽器確認一次。

腳本可以驗證我引用的內容正確嗎？

不行，而且任何宣稱可以的工具都值得懷疑。腳本能驗的是「這個 URL 回什麼狀態碼」。回 200 的空白頁、回 200 但指到不相干條目的頁面，只有人打開來看才會發現——我們那天遇到的三組壞來源裡，有兩組是這種。

soft 404 為什麼那麼嚴重？

因為它讓所有內鏈檢查失效。不存在的路徑回 200 的站，爬蟲永遠找不到死連結，於是打錯字的內鏈可以存在好幾年沒人發現。修它之前，這個站的任何內鏈健康度數字都不必看。

這支開源工具跟 Screaming Frog 之類的爬蟲有什麼不同？

範圍完全不同。爬蟲做的是發現與規模化（找出所有頁、追所有連結）。這支做的是四個具體的渲染層檢查，單檔零依賴、可以直接進 CI，並且它預設從你的 sitemap 讀 URL 而不是爬。兩者是互補的：用爬蟲找頁，用這支驗頁。

---

了解我們的廣告策略與投放服務 →