為 WordPress 網站產生 robots.txt 意味著在您的配置、網域主機與連接埠的「完全根目錄」上,產生一個以 UTF-8 編碼的純文字檔,該檔案會使用 RFC 9309 標準化的「群組與規則」結構來列出爬蟲請求。像 Robots.txt Generator 這種瀏覽器型的產生器,會將您設定檔中的每一個位元組保留在當前的分頁中——不會上傳到後端、不會從上線中的網站擷取、也不會傳送給任何搜尋引擎。該檔案本身包含一個以萬用字元 (wildcard) 表示的 User-agent 群組、一個您選擇的 Allow 或 Disallow 政策,以及一行根據您所輸入的網站來源 (origin) 自動產生的 sitemap 行。由於這個通訊協定是區分大小寫 (case-sensitive)、採用最長匹配 (longest-match)、並從 URL 路徑的第一個八位元組 (octet) 開始比對,因此每一條規則都必須以斜線開頭、完全重複的條目會依「先出現」順序合併,而 `/Private` 與 `/private` 兩者不可互換。這些限制條件,加上刻意設定的 50 條規則上限,以及拒絕輸出 Crawl-delay 的設計,正是讓輸出結果誠實(而非紙面上好看)的原因;本文接下來會說明如何在不使用外掛的情況下,將這個產生器整合進 WordPress 的工作流程中。
為什麼 WordPress 網站需要一份符合標準的 robots.txt
WordPress 長期以來會在使用者沒有上傳檔案時,自動提供一份「虛擬的」robots.txt,這代表許多 WordPress 安裝在站長自行建立檔案之前,根本不會在磁碟上看到一個實體檔案。那些會輸出 sitemap、內部搜尋範本、摘要 (feed) URL,以及預覽連結的外掛,都會擴大爬蟲可發現的 URL 表面。在缺乏一份刻意設定的檔案時,這些 URL 預設會被爬取;而一組少量但可預測的管理後台、登入頁與佈景主題路徑,對於任何遵守協定的爬蟲來說都僅有一鍵之遙。
一份符合標準的 robots.txt 提供了一個單一、可版本控管的場所,讓您表達合規的爬蟲應當避開哪些內容。它本身不做任何身分驗證、不隱藏任何東西、也不加密任何東西——這些責任仍屬於應用程式——但它劃定了主流搜尋引擎會優先讀取的禮貌邊界。Robots.txt Generator 恰好會產生這樣一份檔案:一份 UTF-8 純文字文件,包含一個以萬用字元表示的 User-agent 群組、一個由您選擇的 Allow 或 Disallow 政策,以及一行指向您所輸入來源的 sitemap。
對 WordPress 來說,產生器「應該」與「不應該」做什麼
一個值得信賴的瀏覽器端產生器,應當在不模仿各家爬蟲私有擴充的前提下,遵守 RFC 9309 的限制。對 WordPress 工作流程而言,這代表:
- 將您貼上的 URL 正規化為一個不帶認證資訊的來源 (origin),避免 sitemap 行不小心繼承到來自瀏覽器分頁的路徑、查詢字串或片段。
- 輸出一個萬用字元群組,在沒有更具體的匹配時套用,而不是堆疊自行發明的指令。
- 只接受以斜線開頭的規則格式,保留 `*` 與結尾 `$` 等通訊協定所定義的特殊字元,並拒絕 `#`,以避免一個多餘的字元悄悄地把某段規則變成註解。
- 依「先出現」的順序移除完全重複的條目,並將規則總數控制在 50 條以內,讓結果可以在單一畫面內完成稽核。
- 拒絕加入 Crawl-delay,因為 RFC 9309 標準規則並未納入這個指令,而且各家爬蟲對它的支援也不一致。
同一個工具也應該誠實說明它「做不到」什麼。它不會擷取現有的上線檔案、不會把產生的檔案提交給搜尋引擎、不會驗證伺服器的回應,也不會確認爬蟲已重新整理其快取。這些動作都需要存取已部署的 WordPress 網站與搜尋引擎本身工具的權限;若假裝能夠做到,反而會讓設定檔因為背景擷取而被悄悄損毀。
為 WordPress 產生一份 Robots.txt 檔案
- 開啟產生器並貼上您的網站來源。輸入您希望這份檔案管轄的 WordPress 網站之完整 HTTP 或 HTTPS URL。貼上前請先移除任何路徑、查詢字串或片段,讓工具把這個值化簡為一個乾淨的來源;明確指定的連接埠會予以保留。
- 選擇整體的爬蟲政策。選 Allow all 會寫出 `Allow: /`;選 Block all 會寫出 `Disallow: /`;或選 Selective 來保留預設的 allow 行為,並額外加入明確的 disallow 行。
- 在選擇性模式下,每行輸入一個要禁止的路徑。每一條非空白的規則都必須以斜線開頭;完全重複的條目會依「先出現」順序合併;整份清單上限為 50 條。萬用字元星號與結尾的 `$` 會依通訊協定定義,作為特殊比對字元予以保留;井字號則會被拒絕。
- 產生並檢視文字內容。請檢查輸出中是否包含一個以萬用字元表示的 User-agent 群組、您所選擇的 Allow 或 Disallow 規則,以及一行 `Sitemap:`,指向經過正規化的來源再加上 `/sitemap.xml`。
- 與目前線上的正式檔案進行比對。在上線之前,先下載產生的文字、開啟上線中的 robots.txt,並將兩者並排 diff。請保留產生器並未寫入、但您刻意設定的爬蟲專屬群組,並留存一份舊檔以便日後回復。
- 把檔案發布到其管轄範圍的「完全根目錄」。以全小寫將該文字檔以 `/robots.txt` 這個名稱上傳到相同的配置、網域主機與連接埠,並以 `text/plain` 形式提供。放在子目錄、不同子網域或不同協定下的檔案,將不會管轄您的 WordPress 來源。
- 測試公開與被封鎖的 URL。使用相關搜尋引擎的測試工具,確認幾個具代表性的路徑仍如您預期般運作;在每次更新會影響到 sitemap 或 rewrite 規則的 WordPress 外掛後,也應重新檢查。
檢視 WordPress 網站產生的輸出內容
當文字攤在您面前時,有四項檢查可以幫助您避開最常見的 WordPress 錯誤。第一,大小寫:RFC 9309 明確規定爬蟲應以區分大小寫的方式比對路徑,因此 `/Private` 與 `/private` 是兩條不同的規則,只有其中一條會與 CMS 實際提供的 URL 匹配。第二,錨點:`Disallow: /draft` 與 `Disallow: /draft$` 表達的意圖並不相同——後者會停在段落 (segment) 的邊界,而前者是前綴匹配。第三,最長匹配:當多個群組都可能套用時,最明確的那一個會勝出,因此您排列規則的順序,重要性反而不及規則本身的明確度。第四,sitemap 行:它是由您經過正規化的來源加上 `/sitemap.xml` 構成;若您真正的 sitemap 實際位於別處——例如在會輸出 `/sitemap_index.xml` 的外掛後方,或在另一個 `/news-sitemap.xml` 中——請在上線前編輯這一行。
| 政策模式 | 產生器寫入的內容 | 在 WordPress 網站上的實際用途 |
|---|---|---|
| Allow all | User-agent: *Allow: /Sitemap: …/sitemap.xml | 希望所有 URL 都能被發現的公開部落格與內容網站。 |
| Block all | User-agent: *Disallow: /Sitemap: …/sitemap.xml | 預備上線環境、上線前的網域,或私人版本。 |
| Selective | User-agent: *Disallow: /first-pathDisallow: /second-pathSitemap: …/sitemap.xml | 正式上線的 WordPress:必須讓管理後台、搜尋或內部面向 (facet) 保持不可爬取,但其餘部分仍可被索引。 |
在 WordPress 中替換或新增檔案
WordPress 只會接受位於您所設定來源「根目錄」的 robots.txt。若您將檔案上傳到像 `/wp-content/` 這樣的子目錄,或上傳到 `www.` 子網域,而您的標準來源卻是頂級網域 (apex),那麼合規的爬蟲仍會繼續讀取 WordPress 所產生的虛擬檔案。實際上有兩條可行路徑,可讓您把產生的文字放上線:透過 SFTP、SSH 或主機商提供的檔案管理員來編輯或上傳實體檔案;或者,在主機商封鎖根目錄寫入時,使用一款會「依需求」寫入檔案的 robots.txt 外掛,並驗證最終結果可在「裸來源」(bare origin) 上正確解析。
在覆寫任何檔案之前,請依逐步操作章節所描述的方式,將新的文字與目前線上的正式檔案進行比對。外掛有時會加入它們自己的指令(例如 WooCommerce 的購物車 disallow,或 multilingual 切換器的排除),而一個刻意只輸出一組通用群組的產生器並不會重現這些內容。請留存一份舊檔備份;若您真正的 sitemap 位於不同的 URL,請編輯產生的 `Sitemap:` 行;並確認伺服器送出的 Content-Type 是 `text/plain`,且檔名為小寫。這種小型檔案也正是當您將 WordPress 遷移到新網域、從 HTTP 切換到 HTTPS,或從 `www` 改用頂級網域時,應該重新檢視的地方,因為它的作用範圍僅限於特定的單一配置、主機與連接埠。
常見的 WordPress robots.txt 模式及其意義
WordPress 網站通常只會考慮一小組可預測的路徑。下表列出人們最常貼進產生器的模式,以及它們在 RFC 9309 下的實際意義;它不會為您代勞運算出一份清單,因為每個網站的爬取預算 (crawl budget) 與內容策略各不相同。
| 模式 | 它會匹配到什麼 | 為何 WordPress 網站會考慮它 |
|---|---|---|
| /wp-admin/ | 所有以 /wp-admin/ 開頭的 URL | 管理後台本就不是設計給爬蟲的,結尾的斜線可避免與外掛目錄產生部分匹配。 |
| /wp-includes/ | 所有以 /wp-includes/ 開頭的 URL | 核心 PHP 與 JavaScript 檔案,幾乎不會變動;爬取它只是浪費預算。 |
| /?s= | 透過 s 參數進行的內部搜尋查詢 | 搜尋結果頁通常內容薄弱,而且會產生大量近似重複的內容。 |
| /search/ | 經過美化 (pretty permalink) 的搜尋結果 | 在改寫過搜尋 URL 的網站上,目的與上一項相同。 |
| /author/ | 作者彙整頁 | 在多人共筆的部落格中相當實用,可讓彙整面向 (archive facet) 不會進入索引。 |
| /feed/ | RSS 與 Atom 的 feed URL | 選用性質;有些發布者會讓 feed 保留在索引中,有些則會加以封鎖。 |
上線後請記住:封鎖爬取並不保證從搜尋結果中移除。搜尋引擎仍可能透過反向連結發現某個 URL,並在不下載被封鎖頁面的情況下,保留一段有限的摘要。當您的目標實際上是「不讓某個頁面出現在結果中」時,請使用適當的索引或移除控制機制——例如頁面層級的 noindex meta 標籤、HTTP 標頭,或身分驗證的存取控管。RFC 9309 規格明確指出,這些規則並非存取授權機制,而 Google 爬蟲基礎架構說明文件則描述了它的爬蟲實際上如何讀取這份檔案。若想獲得更廣泛、與環境無關的逐步解說,說明這份檔案如何運作,以及如何稽核一份既有的檔案,請參考 如何在 WordPress 中建立 robots.txt 檔案的實用指南,該文與前文以產生器為核心的流程相輔相成。
若想進一步深入了解,請參考 Generate llms.txt From a Storybook Docs Site。