有一個開發者發現，他網站上的 404 頁面長得完全正常。大大的「Page not found」擺在那裡，使用者一看就知道自己走錯了。但他打開 Chrome 的開發者工具一看，這個頁面回傳的 HTTP 狀態碼是 200。
200 的意思是「一切正常」。Google 看到這個回應，會把一個「不存在」的頁面當成真的存在。這種狀況叫 soft 404（軟性 404，頁面看起來像找不到，伺服器卻回報成功）。這不是虛構的情節，是 Ahrefs 資深 SEO 專員 Despina Gavoyannis 在 2026 年 10 月 1 日刊出的文章裡，引用開發者 Josh Deltener 實際遇到的情況。Deltener 用的是 Nuxt 靜態網站，部署在 Vercel 上。
問題出在一支產生的 200.html 檔案，被當成所有未知網址的回退頁面。看起來像 404，機器讀起來是 200。
Gavoyannis 這篇文章標題是《SEO for Static Sites: 8 Problems to Watch For》，由 Ryan Law 審稿，找來 Suganthan Mohanadasan 和 Pedro Dias 分享實務經驗。她開頭就講了一件事：vibe coding（用自然語言叫 AI 生成程式碼的開發方式）讓架靜態網站比以前容易太多，你可以用 Astro、Jekyll、Gatsby、Hugo 這些框架把站生出來，完全不用碰傳統 CMS。但容易架，不代表容易優化。
靜態網站把 SEO 從外掛移到了你身上
傳統的 WordPress 之類的 CMS，有很多 SEO 基礎是外掛在默默處理的：canonical 標籤（告訴 Google 哪個網址才是正版）、sitemap（網站地圖，列給搜尋引擎抓的頁面清單）、301 重新導向、meta 標籤、schema 結構化資料、404 處理。這些東西你平常根本不用想到，外掛都做好了。
Gavoyannis 寫，換成靜態網站，這些工作「變成你的責任」。她引用了 Suganthan Mohanadasan 的一句話。Mohanadasan 是 Keyword Insights 共同創辦人，他說：「在我看來，走靜態不代表拿掉 SEO 工作，是把它搬走了。WordPress 把一堆預設值藏在外掛後面，靜態把每一件都變成你自己要做的活。」
沒有後台外掛代管，canonical、noindex 與 sitemap 的對應關係得自己管
這在她的第二個問題裡講得最具體。靜態網站的 XML sitemap 通常是用程式碼產生的。問題是，這支產 sitemap 的程式不一定知道你把哪些頁面標了 noindex（告訴 Google 不要把這個頁面放進搜尋結果）。
結果就是：草稿頁、感謝頁、確認頁，這些你不想被 Google 收錄的頁面，還是會出現在 sitemap 裡，因為沒有外掛幫你把兩邊的狀態同步起來。她寫，這個問題在網站長大之後會更麻煩。一開始一個扁平 sitemap 很好管，但當你需要按頁面類型拆分、排除某些區段、對不同模板套不同規則，事情就開始複雜。
她的修法建議是：建立一條統一的規則。把不要被搜尋的頁面標上 noindex: true，然後告訴 sitemap 和 RSS feed 跳過所有帶這個標記的頁面。同時檢查 robots.txt（放在網站根目錄、跟搜尋引擎講哪些可以抓哪些不要抓的檔案）存在、有指向正確的 sitemap、沒有誤擋想被收錄的段落。
頁面產生很快，SEO 設定不會自動跟上
使用 Astro、Hugo、Jekyll 或 vibe coding 架站，頁面的產生速度是真的快。尤其 vibe coding，AI 可以把整頁連同樣式生出來。但 Gavoyannis 點出一個容易忽略的地方：AI 生成的模板會吐出看起來合理的 metadata 和基本 schema，卻不一定符合你那個頁面類型真正需要的結構。
模板層級的錯誤會整站擴散
她的第四個問題講的是 template-driven metadata and schema errors，模板驅動的 metadata 與 schema 錯誤。靜態網站的標題、meta description、canonical、schema 常常是從共用模板產生出來的。很有效率，但一個壞預設值會一次影響幾百頁。她舉的例子是：把品牌名自動加進每個標題，可能讓一整批頁面標題超過你要的長度。schema 更糟，模板用錯類型、漏掉必要屬性，錯誤會被複製到每一個用到那個模板的頁面。她的看法是，vibe coding 讓這件事更難抓。AI 產生的模板看起來合理，不代表它對。
圖片優化不是預設就會發生
Jekyll 預設只是把圖片檔照原樣複製過去。不會自動縮圖、不會壓縮、不會轉格式。要最佳化，你得自己接外掛、接圖片 CDN（內容傳遞網路），或在上線前多做一道圖片處理。Next.js 有 next/image 元件會自動處理響應式尺寸、壓縮、懶載入，但前提是你用那個元件。寫一般的 HTML img 標籤，這些東西一概不會發生。她特別提到，vibe coding 的頁面在預覽裡看起來完全正常，可能還是載了一張大到離譜的原始圖檔。因為網站照樣 build 得過，沒人會在發布前攔下這件事。
效能靠靜態產生不保證
第七個問題把「靜態網站很快」這個印象拆掉一半。靜態產生（HTML 先產好放著，使用者來直接給）不代表效能一定好。她的意思是：站還是可能塞太多 JavaScript、每個頁面載入用不到的 CSS、掛了很重的第三方 script、字型載入方式差、bundle 沒切好。她寫，vibe coding 的站特別值得查，因為 AI 會一直加 script、套件、動畫，不會去算這些東西累積起來的效能成本。一頁一頁看都很漂亮，每改一輪就重一點。
遷移不是換框架，是整組 SEO 設定重來
最後一個問題是遷移。從 CMS 換到靜態網站，最危險的不是新頁面長得不一樣，是舊的 redirect、sitemap 規則、metadata 邏輯、schema、內部連結行為，這些以前被默默處理掉的東西，搬過去就沒了。她寫，最大的風險是 URL 改動。舊網址如果沒有 301 重新導向（永久轉址，告訴 Google 這個頁面搬去哪裡了）接到新網址，指向它的連結和排名訊號可能就沒了。她的建議是：把遷移當成完整的 SEO 遷移，不是重設計。上線前把每個舊網址對到新位置、URL 有變就加 301、比對新舊 canonical 和 sitemap 規則、上線後測實際的站，不只看 staging。
這篇值不值得看
如果你是用 Astro、Hugo、Next.js、Jekyll 自己架站的人，或者是用 vibe coding 生出整站的開發者，這篇值得看。它不跟你談內容策略，它談的是那些你以為有、其實根本沒人幫你做的事。尤其 sitemap 和 noindex 不同步、404 回 200 這兩件，不是你把頁面打開來檢查就會看到的。
我個人記住的是文章開頭那句話：走靜態沒有拿掉 SEO 工作，是把工作搬到你身上。這不討厭。搬到自己身上，至少你知道它在哪裡。
原文：Ahrefs〈SEO for Static Sites: 8 Problems to Watch For〉
本文由 Claire 撰寫。Claire 是文案大叔開發的自動化寫作系統，從素材選題、撰稿到推上草稿全程自動執行，發布前由本人過目。
