數以千計的 robots.txt 404 錯誤來自試圖抓取舊的多站點的機器人
目前的情況是，由於域重定向，我們在我們網站的不同位置尋找 robots.txt 的機器人收到了成千上萬的 404 錯誤。
我們的舊網站是一個迷宮般的多站點，由具有多個域名的 dotnetnuke 提供支持。我們已經在 Wordpress 上改為使用一個域名的單個站點。剩下的域名現在只是重定向到網站上的類別。這意味著 googlebot、bingbot 和許多其他人反复嘗試索引曾經是成熟網站的域並被重定向。
www.EXAMPLE.co.uk 重定向到 www.EXAMPLE.co.uk/challenge/
所以 /challenge/robots.txt 有超過一千個 404
與最終在 /walktoschool/robots.txt 等的其他重定向相同
有沒有一種聰明的方法來重定向機器人？或者應該以不同的方式處理這個問題或讓機器人停止？我們的新網站甚至不使用 robots.txt，它使用 htaccess 和 Better WP Security。我已向 Google 和 Bing 提出重新抓取新網站的請求，但這就是結果。
我是一個非營利組織的業餘網站管理員，我真的不得不開始行動，任何幫助都將不勝感激！
在執行您正在執行的那種重定向時，只有一個適用的 HTTP 響應程式碼，即
301 Moved Permanently. RFC 2616是定義 HTTP 協議的標準，因此定義了 301 響應程式碼（我的重點）：請求的資源已被分配一個新的永久 URI，並且任何將來對該資源的引用都應該使用返回的 URI 之一。如果可能，具有連結編輯功能的客戶端應該自動將對 Request-URI 的引用重新連結到伺服器返回的一個或多個新引用。除非另有說明，否則此響應是可記憶體的。
新的永久 URI 應該由響應中的 Location 欄位給出。除非請求方法是 HEAD，否則響應的實體應該包含一個簡短的超文本註釋，其中包含指向新 URI 的超連結。
如果收到 301 狀態程式碼以響應 GET 或 HEAD 以外的請求，使用者代理不得自動重定向請求，除非使用者可以確認，因為這可能會改變發出請求的條件。
將此與 HTTP 重定向進行對比
302 Found，後者在簡單配置“重定向”時經常使用，其定義為（再次強調）：請求的資源臨時駐留在不同的 URI 下。由於重定向有時可能會改變，客戶端應該繼續使用 Request-URI 來處理未來的請求。此響應僅在由 Cache-Control 或 Expires 標頭欄位指示時才可記憶體。
臨時 URI 應該由響應中的 Location 欄位給出。除非請求方法是 HEAD，否則響應的實體應該包含一個簡短的超文本註釋，其中包含指向新 URI 的超連結。
如果收到 302 狀態碼以響應 GET 或 HEAD 以外的請求，除非使用者可以確認，否則使用者代理不得自動重定向請求，因為這可能會改變發出請求的條件。
因此，在您的場景中進行 HTTP 重定向的正確方法是將 Web 伺服器配置為返回指示新位置的301響應，而不是302響應。然後，有能力的客戶端將儲存新的 URL 並將其用於任何未來的請求。