robots.txt 檔案是一個小型純文字檔，位於網站來源的最上層，用來告知符合 RFC 9309 規範的爬蟲可以請求哪些路徑。它不是存取控制、加密機制或移除工具，而是一個禮貌性的公開請求，合作的爬蟲會予以遵守，但惡意用戶端可以忽略。建立這個檔案意味著選擇一種爬蟲政策、撰寫一個符合規則的 User-agent 群組，然後將結果以 /robots.txt 發布到其所管轄的確切通訊協定、主機和連接埠。標準檔案短到可以手動撰寫，但大多數團隊偏好使用產生器，以強制執行該通訊協定所規定的字元、將來源標準化，並防止意外產生註解或格式錯誤的路徑。Robots.txt 產生器完全在瀏覽器中執行，只需輸入網站 URL 和政策選擇，即可產生一份含有 Sitemap 行的 UTF-8 文字檔，讓您在上傳前先行檢視。
對於從未擁有 robots.txt 檔案的網站，預設行為是「所有內容皆可爬取」——爬蟲會將檔案不存在視為完全開放的邀請。新增檔案本身並不會封鎖任何內容;它只是記錄您實際想要的政策。對於已經擁有檔案的網站，每次變更都會取代先前的規則，這就是為什麼發布和驗證步驟與產生步驟同等重要。
Robots.txt 檔案實際的作用
robots.txt 檔案是 RFC 9309 所定義的標準化機制，供網站擁有者發布爬蟲偏好設定。目前的 Robots Exclusion Protocol 標準化了恰好兩種指令類型:User-agent，後接一或多條 Allow 或 Disallow 規則。根據 IETF 規範，檔案以一或多個群組開頭;每個群組列出適用的產品，以及應視為禁止或允許的路徑。
當合規的爬蟲造訪您的來源時，會讀取 /robots.txt，選擇最符合的特定群組，並對任何路徑使用最長匹配的規則。這就是為什麼一個小檔案能管轄整個網站:萬用字元符號 * 會匹配任何沒有更特定群組的產品，路徑內的特殊字元 * 會匹配任何字元序列，而結尾的 $ 則會將模式錨定到路徑的結尾。這個匹配模型直接衍生出兩個實際的結論:
- 路徑的比較區分大小寫，因此 /Private 和 /private 是不同的模式。
- 沒有結尾 $ 的規則會匹配所有以列出的前綴開頭的內容，因此 Disallow: /draft 會封鎖 /draft、/drafts 和 /draft/2024/01。
該檔案透過純 HTTP 或 HTTPS 請求，以 text/plain 提供，且必須放置在其管轄的來源。位於 https://www.example.com/blog/robots.txt 的 robots.txt 並不會管轄 https://www.example.com/,而位於不同通訊協定或連接埠的檔案也不適用於替代來源。Robots.txt 產生器遵循此規則，在輸出 Sitemap 行之前，會將每個輸入的 URL 標準化為其來源。
三種政策模式說明
大多數網站僅需要三種政策中的其中一種，而優秀的產生器會在產生任何文字之前讓您明確做出選擇。Robots.txt 產生器提供相同的這三種選項，下表將每種模式對應到其典型使用情境以及所輸出的規則。
| 政策模式 | 典型使用情境 | 輸出規則 |
|---|---|---|
| 全部允許 | 沒有路徑限制的公開網站 | Allow: / |
| 選擇性禁止 | 需要隱藏管理、搜尋、購物車或預備環境路徑的正式環境網站 | 每個提交路徑對應一行 Disallow |
| 全部封鎖 | 不得被建立索引的預覽、預備和開發環境 | Disallow: / |
每個選項都會產生一個 User-agent: * 群組、對應的規則，以及指向來源 /sitemap.xml 的 Sitemap 行。選擇全部允許並不等同於什麼都不做——如果沒有檔案，爬蟲仍會將網站視為完全開放，但您就失去了將其指向 sitemap 並記錄意圖的機會。選擇全部封鎖會將網站變成私人預覽;搭配 HTTP 驗證，這是防止預備環境出現在搜尋結果中最簡單的方式。選擇性禁止是最常見的正式環境選擇，因為它能讓公開網站保持可爬取，同時引導爬蟲避開 /admin、/search、/cart 或 /preview 等內部區域。
為網站建立 Robots.txt
使用 Robots.txt 產生器，透過三個簡短的步驟產生符合標準的 robots.txt:
- 在 URL 欄位中輸入網站來源的完整 HTTP 或 HTTPS URL。即使您貼上的是深層頁面連結，此工具會將 URL 縮減為其來源(通訊協定、主機和連接埠)，讓 Sitemap 行指向正確的位置。
- 選擇整體的爬蟲政策。可選擇全部允許、全部封鎖或選擇性禁止。在選擇性模式下，每行輸入一個禁止的路徑——每個路徑必須以斜線開頭，最多可提交 50 個不重複的項目，且完全重複的項目會依首次出現的順序予以移除。
- 產生並檢視文字，然後在與目前正式環境的檔案進行比對後，再將其發布為 /robots.txt。產生器絕不會擷取您的實際運作中的檔案，因此手動進行差異比對，才能保護您不會遺失刻意的爬蟲特定群組。
第二步值得更仔細檢視，因為大多數的錯誤都發生在選擇性模式下。萬用字元星號和結尾的錢號會予以保留，因為該通訊協定的特殊匹配字元就是如此定義的，因此 /private/* 和 /draft$ 都是有效的模式。井字號會遭到拒絕，以避免不小心將使用者輸入規則的一部分變成註解，因此像 /admin # block admin area 這樣的內容將無法通過驗證。規則清單的上限為 50 條，以保持檔案的可讀性，並避免將 robots.txt 當作隱私工具使用。所有輸入的路徑和產生的文字都會保留在目前的分頁中——不會上傳到任何伺服器。
如需更深入地逐步了解相同的工作流程並進行額外的檢查，請參閱建立 robots.txt 檔案的實用指南。
在發布前仔細閱讀產生的輸出內容
正確的 robots.txt 很短，因此請逐行閱讀。產生器一律會輸出一個 User-agent: * 群組，因為 RFC 9309 將萬用字元標準化為備援產品，且產生器刻意不會假裝能管理每個搜尋引擎的私有擴充功能。對於封鎖兩個路徑的典型正式環境網站，其輸出結構如下:
User-agent: * Disallow: /admin Disallow: /search Sitemap: https://www.example.com/sitemap.xmlSitemap 行是根據您標準化後的來源所建立，而不是您貼上的深層連結。含有頁面路徑、查詢或片段的 URL 會被縮減為其來源，讓預設的 sitemap 不會意外繼承不相關的路由。明確指定的連接埠會予以保留，因此 https://staging.example.com:8443 會保留其連接埠。如果您的 sitemap 位於來源 /sitemap.xml 以外的地方，請在發布前編輯產生的那一行。
常見的細節錯誤
- 大小寫:/Admin 和 /admin 在 RFC 9309 中是不同的模式，因此請依照您要封鎖的 URL 確切撰寫路徑。
- 前綴行為:Disallow: /draft 會封鎖 /draft、/drafts 和 /draft/anything，除非您使用 Disallow: /draft$ 加以錨定。
- 萬用字元:像 /private/* 這樣的路徑會匹配 /private 下方的每個子路徑，這通常是您在管理資料夾中想要的結果，但仍值得在發布前加以確認。
如果您要沿用現有的檔案，單一的萬用字元群組將會覆寫爬蟲特定的封鎖。請下載新檔案，與目前的 /robots.txt 進行比對，保留任何刻意的爬蟲特定群組，並保留一份舊檔案以供還原。如需針對性地檢查 32 個 AI 及 AI 相關產品權標如何匹配您的規則，請參閱如何驗證 AI 機器人 robots.txt 檢查的結果。
/robots.txt 的發布位置與方式
該檔案必須發布為 /robots.txt，位於其所管轄的確切通訊協定、主機和連接埠的最上層，以 text/plain 提供，檔名為小寫。位於子目錄、其他子網域或不同通訊協定的檔案，不會管轄預期的來源。Robots.txt 產生器會輸出 UTF-8 文字，可以使用任何檔名儲存，但只有 /robots.txt 才是正確的部署檔名。
對於 Apache 網站，請將檔案放在文件根目錄，並確認 MIME 類型為 text/plain。對於 Nginx 靜態區塊，請將其放在根路徑，並確認 types 指令包含 text/plain。對於 CMS，請使用內建的 robots 編輯器或檔案管理員——WordPress 和 Shopify 都有記錄在案的路由，而產生器的輸出與兩者皆相容。上傳後，請使用 curl 或瀏覽器直接從確切的來源 URL 擷取檔案，並確認回應內容與您產生的內容相符。
須避免的部署陷阱
- 新增 Crawl-delay，即使某些搜尋引擎的說明文件仍然提到它。由於 Crawl-delay 不屬於 RFC 9309 的一部分，且並非通用支援，因此產生器會省略 Crawl-delay。
- 混合來自多個來源的指令，但未了解每個爬蟲如何處理它們。請僅組合您能用淺顯語言說明的規則。
- 從 CDN 提供含有快取壓縮變體的檔案，導致爬蟲無法解析。檔案內容很短，因此快取很少造成影響，但仍請驗證實際運作中的回應。
驗證部署並測試關鍵 URL
產生器不會擷取現有的實際運作中檔案、不會驗證伺服器回應、不會將檔案提交給搜尋引擎，也不會確認爬蟲是否已重新整理其快取。這些動作需要存取已部署的網站和搜尋引擎工具。發布後，請執行四項檢查:
- 使用 curl -I 和 curl 擷取已部署的 /robots.txt，確認 HTTP 200、text/plain 內容類型，以及確切的內容。
- 在相關的搜尋引擎 URL 測試工具中測試一個公開 URL，確認在新檔案生效後，該頁面仍符合爬取資格。
- 在相同的測試工具中測試一個被封鎖的 URL，確認規則已套用，且該頁面已依預期從實際結果中排除。
- 如果平台支援，請透過搜尋引擎的控台提交 sitemap URL，並在下一次爬取週期中觀察是否成功讀取。
根據Google 的爬取說明文件，robots.txt 規則會在每次爬蟲下次擷取時生效，而搜尋引擎可能會保留透過連結所探索到 URL 的有限資訊，即使爬取已遭到封鎖。這就是為什麼驗證步驟至關重要:遺漏的 Allow 或過於寬鬆的 Disallow，只有在爬蟲重新造訪該檔案後才會顯現出來。
What Robots.txt Cannot Do
Robots.txt 是大型索引系統中的一項控制手段，而這項標準的極限值得明確指出：
- 它並非身分驗證或授權機制。遵守規範的爬蟲會遵循規則，但惡意用戶端可以忽略它，且所有列出的路徑都是公開可見的。絕對不要將敏感路徑列為登入檢查或伺服器端存取控制的替代方案。
- 它無法保證從搜尋結果中移除。搜尋引擎可能透過連結發現某個網址，並在未擷取被封鎖網頁的情況下保留有限的資訊。請使用網頁層級的索引控制、HTTP 標頭、移除工作流程或身分驗證來達成實際目標。
- 它不是隱私工具。該檔案本身會被任何人擷取，且其中的路徑並未加密。
- 它無法控制所有爬蟲。只有選擇遵循該協定的用戶端會遵守規則；私人爬蟲和擷取工具可以忽略它。
Robots.txt Generator 的範圍經過刻意設定。它只做一件事：在瀏覽器中為單一網站來源產生簡短、符合 RFC 9309 格式的檔案，並且不會假裝能管理爬蟲專屬的擴充功能、伺服器設定或移除工作流程。一旦你了解政策、產生器和發布步驟，你就能在幾分鐘內替換正式檔案 —— 而下次需要更新該檔案時，同樣的三步驟工作流程依然適用。