重复页面排查的目标不是把所有相似URL都删掉,而是找出会被搜索引擎当作同一内容多个地址的页面,决定保留哪个、合并哪个、屏蔽哪个。多人协作时最容易返工的地方是:有人只交了一份URL清单,没人说明判断依据、处理动作和验收标准。建议从交付结果倒推:最终要交出一张可执行的重复页面处置表,每行包含URL、重复类型、判断证据、处理动作、负责人、验收方式。
排查开始前,先约定交付格式。清单只回答“有哪些页面”,处置表才回答“每个页面怎么办”。一张可验收的处置表至少需要这些列:
这张表就是协作接口。没有它,前端、编辑、SEO各改各的,最后没人能说清哪个URL是应该被收录的版本。
第一步是取样。用站点地图、站内搜索、日志或爬虫工具导出URL样本,不要只凭栏目页手工点。样本要覆盖带参数地址、http与https、带www与不带www、末尾带斜杠与不带斜杠、大写与小写这几类变体。
第二步是归一化对比。把URL去掉参数、统一协议和主机名、统一大小写和末尾斜杠后分组,同一组内如果页面主体内容基本相同,就进入候选重复列表。注意:URL相似只是线索,是否重复要看页面内容,不能只看地址长得像。
第三步是确认规范版本。对每组候选,判断哪个URL应该被保留。可核对的依据包括:站内链接主要指向哪个地址、sitemap里登记的是哪个、页面内容是否最完整、是否有独立搜索需求。判断结果写进处置表的“判断证据”列。
第四步是分派动作。模板层问题交给开发,例如协议跳转、尾部斜杠规则、参数处理;内容层问题交给编辑,例如两篇高度相似的文章合并。每项动作都要有负责人和完成标准。
下面按现象列出可能原因和处理方向。同一现象可能有多个解释,先确认再动手。
/page与/page/都返回200。可能是服务器或CMS未归一化。处理方向是统一规则并跳转。责任划分按改动位置定,不按头衔定。模板和服务器规则由开发负责,内容合并由编辑负责,处置表维护由SEO或项目负责人负责。每项动作完成后,验收要回到同一张表逐行核对:
验收时还要注意比较条件。改动前后流量或收录变化会受季节、搜索需求和数据采集差异影响,不能把一次波动直接归因于某次改动。判断是否有效,应看处置表里的动作是否全部按预期生效,而不是承诺固定见效时间。
下一步:把现有URL样本按上面的处置表格式填出前20行,先确认判断证据列是否每行都有依据,再分派负责人。证据列空着的行不要进入执行阶段。