SEO

Sitemap 为爬虫提供一份明确的候选网址清单，适合帮助发现新内容或普通导航中较深的文档。这份列表不会绕过登录、授予抓取权限、保证搜索收录，也不能承诺某天一定重新访问。应把它视为计划公开文档的发布清单，并让清单与规范网址及实际发布状态保持一致。文件成功上传，只能说明某一步交付发生了，不能替代后续抓取和收录证据。 从发布清单生成 使用与公开页面相同的权威内容筛选规则，排除草稿、私有文档和多余的跟踪参数变体。源码目录里存在一个文件，不代表它已经对应公开 URL；反过来，分页、翻译文档或生成路由，也未必与源文件逐一对应。因此需要查看生成器实际输出，而不是仅凭目录列表猜测发布范围。内容筛选与 sitemap 生成相互独立维护，容易出现遗漏或提前暴露未发布入口。 XML sitemap 使用声明的命名空间，以及包含网址条目的 urlset，每个 loc 提供完整网址。XML 转义与 URL 编码解决不同问题：分隔查询参数的与号，需要在 XML 文本里转义，而网址本身的字符也必须符合相应 URI 表示方式。生成后应重新解析文件，确认经过两层处理，仍然得到原本希望发布的网址，不能因为 XML 看起来能打开就省略这一检查。 还要遵守格式的范围与大小条件。通常应列出相应主机及允许位置范围内的网址，受支持的跨站提交安排有额外规则。每份 sitemap 最多五万个网址，未压缩内容不得超过 52,428,800 字节。gzip 可以减少传输量，却不能取消解压后的上限。更大的清单应拆分并使用适当索引，不能为了让文件通过检查而悄悄截断后面的页面。 坏掉的样子 XML 合法的文件，仍可能列出跳转、缺失页面或不应进入索引的内容。应同时验证目标与语法，并让目标上的 canonical 声明符合预期清单。某个地址返回二百，却只有登录界面或通用错误页，不能证明列出的文档真正可用。Sitemap 自身成功交付，与其描述的页面是否有用，需要分别检查，不能在一个状态码上完成所有判断。 修改时间也可能失真。提供 lastmod 时，应依据页面有意义的变化，而不是每次构建都刷新所有条目的时间。Google 明确说明，它会使用持续准确的 lastmod，并忽略 priority 和 changefreq。这些字段不是调度接口，把所有页面都标成最高优先级，也不能命令爬虫增加访问。没有可信历史依据时，省略可选字段比编造精确时间更诚实。 ...

同一文档可能由多个地址提供：跟踪参数、别名主机或末尾斜杠变化，都可能不改变有意义的内容。canonical 链接用于指出合适重复表示中的首选版本，帮助接收方理解它们的关系，但不会自动重定向 HTTP 请求，也不能强制搜索引擎采用声明的网址。只有目标与周围信号符合真实内容关系，这份声明才有价值；标签存在本身并不等于规范化已经完成。 先确定身份，再写标签 先决定哪个公开网址代表这份文档，再让站内链接和相关 sitemap 条目与这个选择一致。不能机械删除所有查询参数：跟踪参数可能多余，语言、页码或商品选择却可能实质改变表示。如果没有比较含义就把它们全部折叠到一个地址，会把不同文档指向错误的首选页面。规范化应当反映资源关系，而不是只让网址看起来更短。 HTML 中应把带有 rel="canonical" 的 link 元素放入有效 head，并提供清晰目标。对于 PDF 等其他表示，也可以用 HTTP Link 响应头表达这一关系。优先采用完整公开网址，减少 base 地址或部署前缀造成的歧义。生成时应依据站点预期的公开配置，而不是意外把代理内部主机名写进页面。实际发布结果需要再次检查，不能仅查看模板参数。 canonical 链接关系本身不要求目标必须位于同一个源站。跨域声明需要仔细审查内容与控制关系，声明一个值并不能证明拥有目标。对翻译页面，如果同语言的合适规范页面存在，通常应选择该语言目标。语言替代与内容重复是不同关系，把所有中文页面都指向英文首页，会抹掉有意义的文档区别，不能称为准确的去重处理。 坏掉的样子 声明目标可能报错、继续重定向，或者又指向另一个 canonical。模板、插件和响应头各自生成声明，也可能产生相互冲突的值。应检查完整响应，而不是只搜索有没有一个标签。首选目标需要能够使用，声明也要与实际表示一致。多个位置各自维护相同事实时，更应明确权威来源，避免一次修改只更新了其中一处。 普通链接关系不会改变原始地址的可访问性，除非路由另外配置了行为。如果旧路径需要对所有客户端迁移，就应设置合适的 HTTP 重定向，并验证它对方法的影响；如果变体仍有用途，也可以继续成功响应并提供 canonical。不能把元数据提示等同于跳转、访问授权，或者爬虫必须执行的命令。用户与搜索系统可能观察到不同层面的结果。 搜索引擎会综合多种信号，也可能选择另一份规范网址。因此，标签正确不等于收录已经收敛。应区分源站实际提供的声明与搜索服务报告的选择，排查站内链接、sitemap、跳转或语言元数据是否互相矛盾。发生分歧时，不应只是在更多位置重复添加同一个标签，而应先确认它表达的内容关系是否真实且一致。 快速验证 保存为 canonical.py 并执行 python3 canonical.py。脚本创建临时回环 HTTP 源站，用 Python HTML 解析器读取实际响应，提供英文文档、跟踪参数变体、中文文档和两个故意不一致的元数据案例。本地网址只是演示身份，并不会提交给搜索引擎，也没有检查任何真实搜索账号或收录记录。 ...

客户端跟随重定向时，需要先读取 Location，解析目标地址，再发出后续请求，才能取得需要的表示。几个单独看来合理的规则经常组合成长链：规范主机名、切换到 HTTPS、补齐末尾斜线、迁移旧文章。检查时应从用户实际访问的旧地址出发，沿完整路径观察，因为每一个中间环节都会增加依赖。 请求次数不等于连接次数 实际从网络读取的新重定向通常增加一次顺序发生的请求与响应交换。客户端要等前一个响应给出目标，才能继续访问，所以它会推迟最终内容的获取。但“再发请求”不等于“必须重新建立 TCP 连接”。同源 HTTP/1.1 可以复用持久连接，HTTP/2 和 HTTP/3 则有各自的连接与流机制。切换主机可能额外触发域名解析或建连，是否真的发生还取决于已有连接和缓存。 浏览器内部升级和缓存重定向也会改变网络轨迹。HSTS 可能直接把 HTTP 地址升级为 HTTPS，不必先请求明文入口；永久重定向也可能已经存储在缓存。因此，不能为每一跳规定固定耗时，更不能直接断言三个重定向就让整页加载慢三倍。图片、脚本及渲染都可能占据更多时间，必须结合真实瀑布图判断关键路径。 状态码首先表达语义。301 和 302 的历史处理允许把 POST 改为 GET，307 与 308 要求保留方法，303 则指向另一个资源的检索。永久性与可缓存性同样需要考虑。为了把请求列表变短而统一改成永久跳转，可能让客户端长期记住一次错误配置，即使服务器随后修复也不能立即消除影响。 Location 可以使用相对引用，必须结合当前请求地址解析后，再判断目标源和路径是否符合预期。只记录原始响应头可能掩盖问题：相同的相对值从不同目录返回，最终会指向不同位置。故障记录应同时保留原始值和解析结果。 坏掉的样子 两个规则可能互相反向，例如一个规则添加斜线，另一个又删除斜线。分别检查两个端点都能收到响应，并不能证明访问最终会结束。客户端通常有跳转次数上限，但触及上限依然意味着用户任务失败。修改共享规则后，需要记录访问过的目标，并覆盖具有代表性的旧地址、带参数地址及不同入口。 中间地址失效时，最终页面即使健康也无法保证整条路径可达。可以把内部链接更新为最终规范地址，并在语义允许时让历史地址直接跳过去。修改过程中仍要保留有业务意义的查询参数和编码，不能因为少一跳就丢失筛选条件。也不要接受完全不受约束的用户目标地址，或把身份凭据无条件转发到另一个源。 抓取程序同样需要处理额外请求，但重定向链并不能换算成固定的搜索排名损失。搜索引擎有独立的处理规则和上限，本地实验没有测量这些行为。可报告的是跳转数量、是否循环、最终状态及目标是否一致；这些证据比对排名作没有依据的保证更适合指导修复。 快速验证 将下面程序保存为 redirect-chain.py，运行 python3 redirect-chain.py。程序使用 Python 3 创建 HTTP/1.1 回环服务器，并始终使用同一个 HTTPConnection。每个响应都有明确长度，客户端完整读完后可以继续复用连接。响应设置 no-store，使实验观察实际网络交换，而不是依赖缓存里的跳转记录。 ...