带筛选参数的列表页要不要放行抓取,排除路径怎么写

📅 2026-10-12 👁️ 0

带筛选参数的列表页要不要放行抓取,不能一刀切。判断要看两点:这类页面会不会带来大量重复内容,以及它有没有独立价值值得被收录。排除路径怎么写,则受制于抓取协议的一条硬限制——它只按路径前缀匹配,表达不了「排除所有带某个参数的地址」。

先分清三类会重复出现的列表页

第一类是站内搜索结果页。每个关键词都生成一个结果页,内容高度重叠且没有稳定价值,通常希望挡掉。第二类是自定义字段筛选出来的列表页——按颜色、地区、规格等字段组合出的地址,字段一多,组合爆炸,容易出现近乎相同的页面。第三类是伪静态之后变成规整路径的分面地址,比如某分类下按属性翻页后的目录。

三类里,前两类地址通常带查询参数,第三类是规整路径,可控性完全不同。这决定了它们能不能用「前缀排除」表达。

按前缀排除能表达什么、不能表达什么

抓取排除协议只认 User-agent 与 Disallow,且匹配按请求路径前缀进行,通配和正则都不被支持。所以能精确表达的只有「以某段路径开头的都排除」:写成 /list/ 就能挡掉所有以它开头的目录,规则清晰。不能表达的恰恰是筛选页最常见的需求——「带 ?filter=color 的挡、不带 ?filter=page 的放行」,因为参数出现在路径之后的问号段,前缀规则够不着它。

这就是诊断结论:参数型地址的精细排除,靠这份文件本身做不到。想挡参数页,得换思路,而不是硬写正则(写了也只会被当成字面量前缀)。

哪些页面挡了反而伤收录

不是所有重复都该挡。分面导航里,「某分类 + 排序」这种组合是内容组织方式,全挡可能把正常的分类入口一起关在外面。真正该优先处理的是站内搜索页这类明确无独立价值的地址,以及会无限增长的参数组合。判断标准是:这个页面是不是用户会主动访问的稳定入口——是就放行,纯粹是参数排列组合出来的就考虑挡。

站内两处配置怎么分工

站内靠两处配合解决。「一处是 Robots.txt 配置」把能用前缀表达的路径规则写清楚,比如把站内搜索结果页统一放在一个可识别的目录前缀下再整段排除。另一处是伪静态规则:把自定义字段筛选生成的地址从「长串查询参数」伪静态成「规整路径 + 层级」,筛选页从「前缀够不着」变成「前缀能表达」。内容模型的自定义字段决定了筛选页有多少种组合,字段设计时给常用筛选项定下稳定的路径形态,抓取排除才写得准。两处一起动,比只在 robots 里堆规则更有效。

需要提醒的是,挡抓取不等于不产生重复内容——页面还在、还能被站内链接指向、还可能被用户分享。真正的重复内容治理要看规范化的地址与站内链接结构,robots 只是其中一环。

常见问题

问:能只挡带某个筛选参数的地址吗? 答:靠抓取排除文件不行,它只按路径前缀匹配,参数在问号之后够不着。要么把该筛选伪静态成规整路径再按前缀处理,要么在服务端用别的机制。

问:站内搜索页要不要挡? 答:通常建议挡,它重复度高、独立价值低。做法是让搜索结果统一走一个可识别的路径前缀,再整段排除。

问:伪静态之后一定好排除吗? 答:可控性更好,前提是路径形态稳定、层级清晰。若伪静态规则本身让同类页面散落在多种前缀下,排除反而更难写,先统一路径形态再排除。

相关文章

抓取排除文件按路径前缀匹配,写成通配或正则为什么不生效

抓取排除文件里的规则按请求路径前缀匹配,写成通配符或正则不生效,是因为这套协议只识别 User-agent 与 Disallow 两项、且明确不支持通配与正则。本文按协议原文说明规则为什么只按前缀走、通配和正则写法会发生什么,以及站内该按什么顺序写目录路径与斜杠来匹配真实需求。

2026-10-12

内容管理系统一个月内接连出安全版本,说明运维该改什么

内容管理系统在一个月内接连发布安全维护版本,说明运维的判断标准要从版本号转向修复内容。本文以近期***息为例:WordPress 在九月与十月接连发布三个安全维护版本,Joomla 同期面向 5.x 与 6.x 两支发布安全修复,从中提炼三条运维调整——按修复内容决策、升级留回滚点、升级后轮换密钥与口令。

2026-10-12

自建内容系统和按量计费的云服务,花费差在哪几项

自建内容系统与按量计费的 Headless 云服务,花费差异主要落在服务器、请求量、集成扩展与运维人力四项。小规模自建通常更省,规模上升后维护与人力成为主要支出;Headless 把前端部署到边缘、按接口取内容,省掉每次请求的服务端渲染,但引入接口调用计费。本文按四项拆开对比,并给出自托管的对照。

2026-10-12

未登录用户能读到什么,内容系统的权限边界容易漏在哪

未登录用户能读到什么,取决于权限边界划在哪一层。多数越权读取不在主文章本身,而在附属数据、接口列表和预览入口:评论、附件、草稿预览各有各的可见性。本文说明这三处最容易漏的位置,以及站内用用户组权限、文档状态与高危接口默认关闭来收口的做法。

2026-10-12

导出文件里也会藏注入,二阶 SQL 注入防在哪一步

二阶注入的特征是延迟执行:恶意内容第一次被写入时看起来无害,等到导出、导入或重建索引把它再当成语句消费时才触发。本文以 WordPress 7.1.3 修复的 WXR 导出中的二阶 SQL 注入为例,说明一阶与二阶的差别、导出为什么成了投递渠道,以及防护该放在写入、存储、消费哪几步和备份恢复流程要补的检查。

2026-10-12

评论在后台被打开时才触发的 XSS,内容系统该防在哪一层

有些跨站脚本不在前台触发,而是等管理员在后台打开待审评论时才被执行,这类缺陷的防护位置和前台完全不同。本文以近期 WordPress 7.1.3 修复的评论管理页存储型 XSS 为例,说明二次上下文为什么是独立攻击面、入库过滤为什么不够,以及后台侧要做的三层防护:输出转义、权限边界与内容审核。

2026-10-12

智能体用请求头要纯文本版本时,站点的转换该由哪一层做

智能体用 Accept 请求头要纯文本版本时,转换通常由边缘层代做,而不是源站自己出。本文讲清协商机制:客户端带头表达偏好,边缘从源站取原始网页再动态转换成 Markdown,返回的类型头与清理范围由转换方决定;源站原有的安全头透传,但长度、实体标识与修改时间头会被去掉。并说明站内该确认的三件事与模型说明文件的分工。

2026-10-12

边缘节点代做文本转换和程序自己出纯文本版本,建站时怎么选

给智能体提供纯文本版本有两条实现路径:边缘节点代做转换,源站不改代码但受托管档位与体积上限约束、控制粒度在响应头里;程序自己输出纯文本,内容与结构可控但多一份模板与缓存成本。本文摊开两条路径的控制面、体积与一致性差异,并给出四类建站场景的选择建议和该问的四个问题。

2026-10-12