網站效能、搜尋與資安的免費檢測工具

為什麼想查這個

kiwi-walk 做完一輪 SEO 健檢之後，要驗收改動有沒有生效。原本只打算跑 Google 的 Rich Results Test 和 PageSpeed Insights，但看著這些結果，覺得蠻有趣的，想要深入了解看看這些。

因此就想說不要只停在我的檢查紀錄，而是同步介紹給想了解自己網站效能與資安的人，所以就請 claude 協助擴展工具，最後有七個免費工具可以測試驗證。下面結果是在 10/15 測試。

查到什麼

總覽

三個面向的分數落差很大：效能和搜尋大多過了，安全標頭是最弱的一塊。下面一個一個看。

效能：PageSpeed Insights

PageSpeed Insights 用 Google 的 Lighthouse 把頁面載入一次，量速度、做一連串檢查。貼上網址就能跑，報告分手機和桌機兩頁，手機版的條件比較嚴。

先看報告底下的測試條件。這次測的是一篇文章的中階手機/4G 網路/第一次造訪網站：

Emulated Moto G Power with Lighthouse 13.5.0
Slow 4G throttling
Initial page load

分成兩種數據；

• 實驗室數據：中階手機用限速的 4G 第一次造訪網站。這是模擬出來的，每次測都會浮動，也比多數真實訪客慢。
• 實地數據：Chrome 使用者回報的真實體驗，網站流量足夠才會出現，Search Console 的「網站體驗核心指標」報表也看得到同一份。

報告最上面那塊「Discover what your real users are experiencing」就是實地數據，kiwi-walk 顯示 No Data：流量還不夠，只有實驗室數據可看。

五個分數（0–49 紅、50–89 黃、90–100 綠），每一類展開到底都會列出通過的檢查：

SEO 100 分只代表基本項目沒漏（有 title、能被收錄、連結有文字），不代表排名好。

效能分數由五個指標算出：

LCP 和 CLS 是 Google 的「網站體驗核心指標」。第三個核心指標 INP 量的是點擊後多久有反應，實驗室裡沒有人點，所以用 TBT 代替。

最有用的是指標下面的診斷，每一項都能展開看是哪個元素、可以省多少：

• LCP breakdown：這篇的 LCP 元素是開頭第一段文字，不是封面圖。伺服器回應 0 毫秒，「元素轉譯延遲」2,380 毫秒，也就是文字早就下載完了，卻遲遲畫不出來，通常是在等 CSS 或 JavaScript。健檢時把文章封面改成優先載入，前提是「封面就是 LCP」，在這篇文章上這個前提不成立。
• Improve image delivery（估計省 238 KiB）：頁首 logo 原圖 659×659、98 KiB，畫面上只顯示 96×96；文章裡的圖 1800 寬只顯示 672；分類 logo 326 只顯示 49。
• Use efficient cache lifetimes（估計省 181 KiB）：CDN 上的圖片沒有設快取時間。
• Render-blocking requests（估計 150 毫秒）、Reduce unused JavaScript（估計 72 KiB）、Image elements do not have explicit width and height。

讀這份報告的方法是看「Est savings」大的項目，挑影響範圍大、改動小的先改。

搜尋：Rich Results Test

Rich Results Test 用 Googlebot 抓頁面、執行完 JavaScript 後拿最終的 HTML，找出裡面的結構化資料（例如 JSON-LD），再對照 Google 支援的「複合式搜尋結果」規格。它回答的是：這一頁有沒有資格在搜尋結果裡用比較豐富的樣子出現，例如顯示圖片、日期、麵包屑路徑。

結果頁的幾塊：

每個項目有三種狀態：有效、非重大問題（缺了建議欄位，仍然有資格）、無效（缺必填欄位或格式錯）。結果頁的網址可以直接分享。

我測了兩篇文章、三次：

失敗的那次不是結構化資料寫錯，是工具沒抓到頁面。同一時間用一般瀏覽器和 Googlebot 的身分去抓都正常，一分鐘前另一篇也剛測成功，重測就過了。如果重測還是失敗，就要展開 Crawl 看「Crawl allowed?」，再去 CDN 或防火牆的紀錄裡找有沒有擋到 Google 的測試爬蟲。

點進 Articles 可以看到 Google 解析出的每個欄位：類型是 BlogPosting，作者和發布者都是同一個人（連到 About 頁，列出四個社群帳號），語言 zh-TW，沒有封面的文章用的是預設分享圖，字數是數字 3439。這篇沒寫最後修改時間，所以發布日和修改日相同。

讀結果時要記得三件事：

• 它只列 Google 有對應豐富結果的類型。 首頁的 WebSite 標記不會出現在這裡。
• 有效不等於一定會顯示。 只是「有資格」，Google 仍會自己決定；麵包屑在手機版搜尋結果裡早就不顯示了。
• 結構化資料不影響排名。 它影響的是搜尋結果長什麼樣子。

搜尋：Schema Markup Validator

Schema Markup Validator 由 schema.org 提供，檢查任何 schema.org 類型的語法，不管 Google 有沒有支援。它和 Rich Results Test 互補，PageSpeed 的 SEO 類別裡那項「Structured data is valid」要人工確認，指的也是這種工具。

• 文章頁：BreadcrumbList 1 個、BlogPosting 1 個，沒有任何錯誤、沒有任何警告。
• 首頁：WebSite 1 個（裡面包著作者、社群帳號、語言），沒有任何錯誤、沒有任何警告。這個在 Rich Results Test 裡看不到。

搜尋：Search Console

Search Console 要先登入、驗證你擁有這個網站（kiwi-walk 早就用 DNS 記錄驗證過）。前兩個工具測的是「一頁」，Search Console 看的是「Google 對整個網站實際做了什麼」。

這次做了兩件事：

• 重新提交 sitemap（線上有 142 個網址）。
• 收到一封通知：有網頁因為「Excluded by ’noindex’ tag」沒有被收錄，建議修正。信裡說這是一個「新的原因」。它其實是健檢時刻意讓標籤、分類、搜尋頁不被收錄的結果，不是出錯。要確認的是被排除的只有那些頁：把 sitemap 裡 142 個網址逐一抓回來，全部都是 index, follow。這種情況報表裡的「驗證修正」不要按。

值得定期看的報表：

資安：Mozilla HTTP Observatory

HTTP Observatory 是 MDN 提供的工具，檢查網站回應裡的 HTTP 安全標頭，給分數和等第（A+ 是 100 分以上，D 是 30 分，F 是 0 分）。

kiwi-walk 拿到 D，30/100，12 項過 8 項：

這幾個標頭在做什麼：

• HSTS（Strict-Transport-Security）：讓瀏覽器強制使用 HTTPS 連這個網站。
• CSP（Content-Security-Policy）：列出允許載入內容的來源，瀏覽器就不會載入其他來源的惡意資源，用來防範 XSS。
• X-Frame-Options：告訴瀏覽器是否允許這個網站被嵌進框架（frame），防範點擊劫持（clickjacking）。
• SRI（Subresource Integrity）：在 script 標籤上附檔案的雜湊值，瀏覽器確認檔案沒被竄改才使用（MDN 說明）。

報告最後有一張各等第的網站數統計：D 有 42 萬個網站，D− 有 53 萬個，F 有 108 萬個，是數量最多的三個等第。

資安：securityheaders.com

securityheaders.com 是 Snyk 的專案，檢查的東西和 Observatory 類似，評分方式不同。勾「Hide results」結果就不會公開在網站上。

kiwi-walk 一樣是 D：

• 有的：X-Content-Type-Options、Referrer-Policy
• 缺的：Strict-Transport-Security（建議值 max-age=31536000; includeSubDomains）、Content-Security-Policy、X-Frame-Options（建議值 SAMEORIGIN）、Permissions-Policy（控制頁面在瀏覽器裡能用哪些功能與 API）

它還多提醒了一件事：回應帶著 access-control-allow-origin: *，是很寬的跨來源設定，它認為只適合用在公開的 CDN。兩個工具的結論一致：缺 HSTS、CSP、X-Frame-Options。

資安：Qualys SSL Labs

SSL Labs 檢查的是 HTTPS 那一層：憑證、支援哪些 TLS 版本、加密套件、有沒有已知漏洞。勾「Do not show the results on the boards」就不會公開。網域有多個伺服器位址時會逐一測，每個約一分半，要等一下。

kiwi-walk.com 有四個位址（兩個 IPv6、兩個 IPv4），四個都是 A：

• 憑證：一張 RSA、一張 EC，Google Trust Services 簽發，有效期約三個月，主要作業系統和瀏覽器都信任，憑證鏈沒有問題。
• 協定：支援 TLS 1.3 和 1.2；1.1、1.0、SSL 3、SSL 2 都不支援。另外支援後量子（PQC）的金鑰交換。
• 漏洞：Heartbleed、POODLE、ROBOT 等已知漏洞都沒有。
• 可以加強的：沒有 HSTS、不在瀏覽器的 HSTS 預載名單；沒有 DNS CAA 記錄；TLS 1.2 還列著幾個被標成 WEAK 的舊加密套件。

拿 A 而不是 A+，差的就是 HSTS，和前兩個資安工具指出的是同一個缺口。

cloudflare 幫我的

因為我的 kiwi-walk 跑在 Cloudflare Pages 上，HTTPS 那一層由 Cloudflare 處理，所以 SSL Labs 拿 A。但安全標頭需要自己加，所以才會在兩個標頭檢測都拿 D。資安工具測的是不同層，所以才會有落差。

這次也先依結果改了效能的兩項：頁首 logo 換成小圖（每頁約 100 KB 降到不到 20 KB），CDN 圖片加上快取規則。設快取規則的過程，記在 SEO 健檢之後的 Cloudflare 收尾。

還沒解的問題

• 安全標頭還沒加：HSTS、X-Frame-Options（或 CSP 的 frame-ancestors）、Permissions-Policy、CSP。CSP 要先盤點網站用到的 Google Analytics、CDN 和頁面裡的 inline script，不能直接套嚴格的版本。
• PageSpeed 剩下的項目：LCP 的文字轉譯延遲、文章圖片原尺寸輸出、圖片缺寬高、顏色對比、用不到的 JavaScript。

來源

• PageSpeed Insights
• Rich Results Test
• Schema Markup Validator
• Google Search Console
• MDN HTTP Observatory
• securityheaders.com
• Qualys SSL Labs SSL Server Test