網站改版與上線必檢：robots.txt 錯誤如何讓流量整站消失與復原流程

robots.txt 錯誤會讓網站流量消失嗎？（案例重建）

是。錯誤的 robots.txt 可直接讓搜尋引擎停止抓取整站或重要資源，導致流量驟降並需數週至數月才能逐步恢復。

案例重建：一行設定引發的四個月空窗

情境概述（匿名）：某站在三月中旬完成改版並上線。最初幾週流量有小幅波動，四月比改版前下滑約兩成；到了五月下滑幅度擴大到約五成，團隊開始檢視內容與標題調整；六月流量掉到上線前流量的不到五成（原始案例描述為從每月約四千次掉到不到兩百次），外包與內部調整都未發現問題來源。

七月我們接手時，第一天就檢查了網站根目錄的 robots.txt，發現開發環境的封鎖規則被帶到正式站（檔案中一行阻止抓取的設定）。修正後第九天流量開始回升，第七週回到修正前水準的約八成，第四個月完全恢復。整個過程的主要教訓不是修復本身的時間，而是那段期間內失去的業務機會與詢問量（案例中以該客戶既有轉換率估算的機會成本被指出）。

重點回顧：短而易被忽視的文字檔（robots.txt）能造成長期影響；首次檢查應在改版或搬家當天執行。

robots.txt 六種常見錯誤與它們的後果

下面以匿名案例與實務觀察，重整六類常見錯誤與具體後果、偵測特徵與風險評估。

1) 全站被封鎖（最嚴重）

• 後果：搜尋引擎停止抓取整個網站，既有索引會在數週內逐步失效，流量在一段時間內持續下滑而非瞬間消失。
• 偵測：流量起落呈現自某時間點開始持續下滑，搜尋主控台（Search Console）抓取量下降。
• 風險緩解：改版上線當天立即檢查；發現封鎖立即修正並提交索引請求，但重新收錄通常需二到六週。

2) 重要資源（CSS/JS）被封鎖，導致渲染失敗

• 後果：搜尋引擎看到的頁面與使用者看到的不一致，可能產生版面空白、主內容缺失或行動友善性被判定為不佳，長期降低頁面評價。
• 偵測：頁面仍被收錄但排名與互動表現低；使用 URL 檢查工具或行動裝置模擬工具比對渲染結果。
• 注意：此類錯誤往往比整站封鎖更難察覺，因為頁面仍在索引名單中。

3) 未封鎖應排除的大量參數頁（爬蟲預算空轉）

• 後果：站內搜尋、篩選參數或分頁組合產生大量近似頁面，爬蟲大量抓取低價值頁面，重要頁面抓取頻率下降，搜尋表現受損。
• 偵測：伺服器日誌或搜尋主控台顯示抓取多集中在某類型網址（例如站內搜尋結果頁）；範例中曾觀察到抓取七成以上集中在搜尋結果頁上，商品頁平均數週才被抓一次。
• 做法：以 robots.txt 搭配 canonical 與 sitemap，或在 robots.txt 封鎖低價值參數，並允許關鍵頁面被抓取。

4) 用封鎖取代正確的移除流程（封鎖 ≠ 移除索引）

• 後果：以為封鎖就能讓網址從搜尋結果消失，但實務上如果該網址已有外部連結或早已被收錄，仍可能出現在結果頁，但顯示無描述（no snippet）。
• 正確做法：若目標是「不再出現在搜尋結果」，應允許抓取並在頁面中加入 noindex；若目標是節省爬蟲預算而接受可能仍被列出，則可以 robots.txt 封鎖。
• 禁忌：不要同時對同一網址既封鎖抓取又在頁面標示 noindex，否則 noindex 標示將無法被讀取。

5) 規則比對與萬用字元使用誤判

• 後果：因為 rules 的匹配邏輯以最明確（longest match）或最特定規則為準，允許與拒絕規則同時存在時，結果常與撰寫者預期不同；萬用字元、結尾符號誤用則可能意外封鎖整個目錄。
• 偵測與防範：使用測試工具驗證多種 URL，理解「最明確規則優先」的運作方式，避免只用簡單的字串比對。

6) sitemap 路徑錯誤或缺失

• 後果：robots.txt 中若宣告的 sitemap 指向錯誤路徑或舊網域，搜尋引擎會讀取不存在或過期的清單，影響新頁面被發現與收錄速度。
• 偵測：比對 robots.txt 中 Sitemap: 行與實際 sitemap 的路徑；搬家後常見忘記更新此行的疏漏。

可直接套用的檢查流程（步驟清單）

下面是一組可在上線當天或發現流量異常時立刻執行的步驟，按順序檢查並記錄結果：

1. 在瀏覽器中直接開啟 https://你的網域/robots.txt，確認內容是否與預期一致，並將截圖存檔。
2. 在搜尋主控台的 URL 檢查工具中，隨機測試至少五個重要頁面（首頁、三個商品或文章頁、以及一個篩選或搜尋結果頁），確認可被抓取與渲染。
3. 檢查是否有封鎖 CSS、JS 或圖片目錄（例如 /assets/、/static/、/wp-includes/ 等），以免影響渲染。
4. 確認 robots.txt 中的 Sitemap 宣告是否為目前正確的網域與路徑。
5. 若用到參數化網址或大量篩選頁，檢視伺服器日誌抓取分布，判斷是否存在爬蟲預算被浪費的情形。
6. 若要讓頁面從搜尋結果消失，先移除 robots.txt 的封鎖（允許抓取），在頁面加入 noindex，再確認搜尋引擎已抓到該標示。
7. 做完以上步驟後，將 robots.txt 的最終版本加入上線檢查單第一項並存檔紀錄。

何時強烈建議重新檢視 robots.txt（時機與例外）

• 每次網站改版或系統搬家後的第一天必檢。
• 更換主機、網域或安裝會改寫網址結構的外掛或套件後必檢。
• 當流量在短期內出現異常下滑（非短暫波動）應列為優先調查項目。
• 建議在沒有異常時，每季檢視一次；此檔案通常很短，讀完不超過三分鐘，但錯誤代價高。

例外情況：如果你的網站使用第三方托管或平台（如某些 SaaS 電商或 CMS），請同時檢查平台層級的設定，有時平台會生成或代為管理 robots 規則。

沒有工程人員時的最低可行做法

如果團隊缺乏工程資源，至少應做到：

• 每次改動或上線後，用瀏覽器開啟 robots.txt 並截圖存檔，和上一次版本做比對；這不需要技術背景，只需比對文字是否變動。
• 若流量異常，先檢查 robots.txt 是否被意外修改；必要時把截圖提供給外部顧問或供應商，比對變動紀錄。

這兩步能捕捉多數因為人為上傳或部署錯誤導致的問題。

把檢查變成制度：三項建議

人為記得去檢查通常不可靠，特別在上線當天通常最忙。把檢查制度化建議採取三項措施：

1. 將 robots.txt 檢查列為上線檢查清單的第一項，並要求截圖存證與簽核。
2. 設定自動化腳本（或外部監控）每週抓取 robots.txt 並比對內容，若有變動自動發郵件通知相關負責人。
3. 在搜尋主控台或其他監控平台設定收錄或覆蓋範圍的異常通知，當收錄頁數或抓取量異常下滑時能及早發現。

常見問題（FAQ）

Q1：封鎖之後多久會開始影響排名？
A1：搜尋引擎通常會在數天內停止對被封鎖頁面的抓取，既有索引則會在二到六週內逐步失效；越早發現越容易加速恢復。

Q2：被 robots.txt 封鎖的頁面還會出現在搜尋結果嗎？
A2：有可能。如果該網址已有外部連結或先前已被收錄，搜尋結果可能仍會列出該網址，但不會顯示內容描述（no snippet）。要完全使網址不再出現在結果中，需允許抓取並在頁面上加入 noindex。

Q3：需要特別封鎖後台或登入頁面嗎？
A3：多數情況不需要，因為需要登入的頁面本就不會被索引；過度封鎖反而容易誤傷公開頁面。

Q4：發現 robots.txt 有誤，修正後多久會回復流量？
A4：修正後搜尋引擎會重新抓取，開始回升的時間可能在數天內出現（案例中第九天開始回升），但完整恢復可需數週到數月（案例中第七週達到約八成，第四個月完全恢復）。實際時間視索引失效程度與網站權重而定。

Q5：site map 放在 robots.txt 裡面有風險嗎？
A5：把 sitemap 宣告在 robots.txt 本身沒問題，但要確保路徑與網域正確；錯指向舊網域會讓新頁面收錄變慢。

下一步（站內資源與求助管道）

若要把檢查納入流程、或需要進一步的技術協助，可以參考站內相關頁面與服務：我們建議先檢視技術與服務資訊，或提交需求以安排診斷：

• 技術服務與顧問（服務項目說明）：/services/
• 過往案例（匿名或經同意展示的個案）：/cases/
• 常見問題總覽（技術檢查、上線流程）：/faq/
• 若需聯絡或預約諮詢，請使用聯絡表單：/contact/

（上述為內部入口提示，實際採取行動請先以自己網站環境與日誌為依據。）

---

本文資料邊界：本文基於既有匿名案例與實務觀察整理六種常見錯誤與可執行的檢查流程；文中使用的數字（例如流量從每月約四千次降到不到兩百次、以及案例中的恢復時間點）來自案例描述或站方提供的後台資料，具體細節與計算需以原始日誌與轉換率資料為準。