robots.txt 是搜尋蜘蛛抓取前的第一道判断。它不决定頁面是否被索引，却會直接决定這條 URL 能不能進入抓取路径。不少站点把低频路径、參數頁、後台目錄一股脑寫進 Disallow，几個月後才發現，本该被發現的頁面也没被抓到。問题通常不出在“屏蔽”這個動作，而在規則寫法和复核方式上。

匹配逻辑：不是從上往下逐行讀

主流搜尋引擎在處理 robots.txt 时，多采用“最長匹配優先”的思路，而不是简單按出現顺序取第一條命中的規則。也就是说，命中的規則字符串越長、越具体，優先級越高；長度相同时，Allow 一般優于 Disallow。這條規則决定了同一段配置在不同书寫方式下會得到完全不同的结果。

• “Disallow: /”配合“Allow: /public/”是可行的，前提是放行路径寫得足够具体。
• 通配符“*”代表任意字符序列，“$”代表结尾，两者叠加时容易命中预期外的 URL。
• 路径区分大小寫，“/News/”和“/news/”是两條不同規則。

Allow 與 Disallow 冲突时的核對顺序

当两條規則同时命中一個 URL，處理方式可以归纳為三步：先比長度，再比具体程度，最後看其中一方是否為 Allow。實操中容易踩的坑，是把例外寫在通配符規則之前，以為顺序能起作用，结果通配符規則更長，仍然把例外覆盖掉了。

比較稳妥的做法是把需要放行的目錄單獨列出，並保證它的路径長度大于被屏蔽的父目錄。例如屏蔽整個參數泛滥的篩選目錄，同时放行其中少數确實有内容價值的路径。

三類常见誤伤

通配符一刀切

用一條規則屏蔽全部带問号的 URL，是最省事也最容易出問题的寫法。排序、篩選、分頁參數里往往混着有效入口，一刀切之後這些頁面既不會被抓取，也不會進入後續的抓取排期。

屏蔽目錄後忘记放行子路径

目錄調整、内容迁移之後，舊的屏蔽規則常被保留下来。新内容恰好落在被屏蔽目錄下，表現就是“明明加了内鏈，却迟迟没有抓取记錄”。

sitemap 與 robots 互相矛盾

把被屏蔽的 URL 寫進 sitemap，等于一邊邀請一邊關门。蜘蛛讀到 sitemap 里的條目，抓取时又被規則拦下，除了浪費一次請求，也會削弱 sitemap 本身的可信度。

被屏蔽不等于不會被發現

URL 的發現和抓取是两件事。外鏈、sitemap、内鏈都可能让蜘蛛知道某個 URL 存在，但規則判断發生在請求之前。日誌里如果出現“規則中已屏蔽、却仍有請求”的情况，通常要從這几個方向排查：

• 規則文件返回了非 200 狀態碼，或被 CDN、WAF 改寫；
• 請求来自其他爬虫或未声明身份的工具；
• 規則寫法存在语法错誤，整行被忽略。

复核清單

1. 拉取 robots.txt，逐條列出規則，标出通配符與结尾符的位置。
2. 挑 10 到 20 個有代表性的 URL，包括重要栏目頁、深层内容頁、參數頁，手動推演會命中哪條規則。
3. 對照 sitemap 與内鏈，確認没有重要 URL 落在屏蔽范围内。
4. 查看日誌中目标目錄的實际請求量，規則收紧前後各取一段時間做對比。
5. 規則變更後留出观察期，不要在同一天同时改動内鏈结构和 sitemap。

什么时候该動，什么时候不该動

抓取预算有限时，屏蔽确實是一種收敛手段，但它只适合處理确定没有價值的路径，比如後台、站内搜尋结果頁、無意义的會话參數。對于仍在观察期的目錄，用 noindex 或頁面内的規范連結處理，往往比直接屏蔽更可控——屏蔽會让蜘蛛彻底看不到内容，连纠错的机會都没有。

把 robots.txt 当成一次性的配置文件，是抓取問题反复出現的常见原因。它更像一份需要随站点结构同步更新的约定，改版、迁移、目錄調整之後都應该重新核對一遍。

規則本身並不复杂，难点在于它影响的是整條抓取路径的第一环。寫完之後用少量代表性 URL 推演一遍，比事後從日誌里倒查要省事得多。