2026 年 WordPress robots.txt 設定指南（到底該寫什麼）

一份好的 WordPress robots.txt 大概只有五行。封鎖 /wp-admin/、放行 admin-ajax.php、把爬蟲指向你的 sitemap，然後就停手——你在論壇上看到那種動輒 40 行的封鎖清單，多半不是破壞渲染就是根本沒作用。整份檔案：

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

把網域換掉，如果你用的 SEO 外掛接管了 sitemap，就把 Sitemap 那行改指向該外掛的索引檔。就這樣。如果你的檔案比這還長，多出來的那些行大概正在讓你付出代價。

WordPress 本來就會生成一份——直到你建立實體檔案

WordPress 內建虛擬的 robots.txt。當 /robots.txt 的請求進來、而你的網站根目錄沒有實際檔案時，WordPress 會攔截請求並在記憶體中印出回應。磁碟上不寫入任何東西。預設輸出就是上面那段 wp-admin 封鎖規則，再加上一行指向 wp-sitemap.xml 的 Sitemap:，這是核心自 WordPress 5.5 起就會輸出的。

有兩件事會改變這份輸出。第一，如果設定 → 閱讀 → 阻擋搜尋引擎索引這個網站被勾選，WordPress 會把整份內容換成 Disallow: /，等於封鎖一切。那個勾選框是網站上線後從搜尋結果中消失最常見的單一原因。第二，外掛和佈景主題可以透過 robots_txt 過濾器修改虛擬輸出，SEO 外掛就是這樣插入自己的 sitemap 行和規則的。

接下來是害大家浪費整個下午的那一段。網站根目錄裡的實體 robots.txt 檔案會無聲地覆蓋以上全部。 你的網頁伺服器在磁碟上找到實際檔案就直接提供，WordPress 根本不會載入。虛擬生成器不會執行，robots_txt 過濾器不會觸發。你的 SEO 外掛的 robots.txt 編輯器可能還是顯示著漂亮的介面、裡面規則都對，但那些東西沒有一個到得了爬蟲手上。

規則存在哪裡	能否在 WordPress 後台編輯	實際請求時誰贏
虛擬（磁碟上無檔案）	可以，透過 robots_txt 過濾器或外掛	只有在沒有實體檔案時才生效
網站根目錄的實體檔案	只有在外掛會寫入磁碟時才行	永遠是它

所以在你除錯任何東西之前：先用瀏覽器打開 https://yoursite.com/robots.txt，然後透過 SFTP 或主機商的檔案管理員，檢查 wp-config.php 和 .htaccess 旁邊有沒有一個實體的 robots.txt。如果有，那個檔案就是你的 robots.txt。要嘛就在那裡編輯，要嘛把它刪掉讓 WordPress 接手——但只能選一種。兩邊同時跑，正是網站最後留著一個沒人找得到的過時 sitemap 網址的原因。

為什麼封鎖 /wp-admin/ 卻放行 admin-ajax.php

/wp-admin/ 放的是後台。那些網址出現在搜尋結果毫無用處，去爬它們只是把爬取預算燒在會導向登入畫面的頁面上。封鎖這個目錄沒有爭議。

admin-ajax.php 雖然住在那個目錄裡，但它不是後台頁面。它是外掛和佈景主題用來處理前台 AJAX 請求的端點——載入更多按鈕、篩選過的商品列表、計算機、表單。如果爬蟲抓不到它，就看不到那些功能載入的內容，而 Google 渲染出來的頁面，就等於一般訪客看到功能壞掉的樣子。

Google 是否真的需要在你這個網站抓取 admin-ajax.php，取決於你的前台有沒有在用它。老實說：在許多現代網站上這根本無所謂，因為佈景主題改用 /wp-json/ 的 REST API 了。那行 Allow 是針對一個真實故障模式的廉價保險，不是排名因素。留著它，因為它不花你任何東西。

不要封鎖 /wp-content/ 或 /wp-includes/

這是至今仍在流傳的 robots.txt 建議中最糟的一條，它出自 Google 還不會渲染頁面的年代。

/wp-content/ 放的是你的佈景主題、外掛、上傳檔案——那些讓你的頁面看起來像頁面的樣式表、指令碼和圖片。/wp-includes/ 放的是外掛依賴的核心 JavaScript。Google 在評斷你的頁面之前，會用無頭瀏覽器渲染它。封鎖那些目錄，渲染器拿到的就是一個沒有 CSS、沒有圖片的頁面。Google 評估到的會是一堵沒有樣式、版面全壞的文字牆，這會影響它如何理解你的內容，以及它怎麼評分你的行動裝置可用性。

如果你接手的檔案裡有這幾行，把它們刪掉：

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

你可以在 Google Search Console 的網址審查工具裡自己確認損害。對任何頁面執行即時測試，看渲染後的螢幕截圖，並檢查頁面資源清單裡有沒有被封鎖的項目。如果你的 CSS 顯示為被封鎖，原因就在這裡。

Sitemap 指令

一行，絕對網址，而且可以放在檔案的任何位置——它不隸屬於任何 User-agent 群組。

Sitemap: https://example.com/wp-sitemap.xml

用真的打得開的網址。WordPress 核心提供的是 wp-sitemap.xml。多數 SEO 外掛會停用核心 sitemap，改在不同路徑提供自己的索引檔，通常是 sitemap_index.xml。在你把網址寫死之前，先用瀏覽器載入它——一行指向 404 的 Sitemap 比沒有這行更糟，因為它在稽核時看起來是對的。

列出多個 sitemap 沒問題，一行一個。在 Search Console 另外提交 sitemap 仍然值得做；robots.txt 的這個指令，是給那些永遠看不到你 Search Console 帳號的爬蟲用來找到它們的。

robots.txt 不是 noindex，也不是安全機制

這兩個誤解造成了 robots.txt 大部分的災情。

封鎖一個網址不會把它從 Google 移除。 robots.txt 管的是爬取。如果別的網站連到某個被封鎖的網址，Google 還是可以索引那個網址本身——你會得到一筆只有網址、並註明沒有可用資訊的結果。還有一個更麻煩的陷阱：如果某個頁面已經有 noindex meta 標籤，而你接著在 robots.txt 封鎖它，Google 就爬不到它、看不到那個 noindex，於是這個頁面可能無限期留在索引裡。要移除頁面，請放行爬取，並在頁面 head 中提供 noindex 的 meta robots 標籤，或送出 X-Robots-Tag HTTP 標頭。Google 已於 2019 年停止支援 robots.txt 內的 noindex 指令。

封鎖一個路徑不會保護它。 你的 robots.txt 依定義就是公開的。把 /private-client-files/ 列上去，等於告訴每個訪客和每支掃描程式該往哪裡看，而且遵守與否是自願的——Google 會遵守，敵意機器人不會。任何需要保護的東西，需要的是身分驗證、IP 限制，或 .htaccess 裡的伺服器層級規則，而不是一份把目標昭告天下的純文字檔案裡的一行字。

值得加的規則，和值得跳過的規則

有兩項新增在許多網站上確實有用。封鎖站內搜尋結果的路徑，可以避免爬蟲從你的內部搜尋生成無止盡的低價值網址。在 WooCommerce 上封鎖購物車或結帳路徑，則能讓帶有 session 參數的網址不進入爬取。

Disallow: /?s=
Disallow: /search/

以下這些跳過：

• Crawl-delay —— Google 完全不理會。如果你真的有伺服器負載問題，請用 Search Console 的爬取頻率控制。
• 封鎖 /feed/ 或 /trackback/ —— 這些網址無害，而且訂閱來源是有用的。
• 一長串個別機器人名稱 —— 大家想擋的那些機器人，多半本來就不會誠實表明身分。
• 封鎖 /wp-json/ —— 你的佈景主題可能正是靠它來渲染內容。

用 WordPress robots.txt 產生器來建立檔案，它會產出最精簡的正確版本，並讓你在不必手動編輯語法的情況下加上搜尋與電商規則。

改完之後

直接載入 https://yoursite.com/robots.txt，確認實際送出的內容就是你預期的——而不是你外掛編輯器顯示給你看的。接著在 Search Console 對一個一般頁面執行即時網址審查，檢查沒有任何 CSS 或 JavaScript 資源回報為被封鎖。Google 會把 robots.txt 快取大約一天，所以修正不會立刻生效，錯誤也不會立刻反映。正是這個延遲，讓你更應該仔細驗證，而不是在正式環境上試了再等。