📍 WDQWDWQD987AAAAA:216.73.216.136
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /21a53283850b.html
📄

内链策略：日志中应该核对哪些字段

做内链策略时核对日志，重点不是看“有多少次访问”，而是看爬虫在站内沿着链接走到了哪里、停在了哪里。需要优先核对的字段包括：请求时间、请求方法、请求URL、状态码、响应大小、User-Agent、Referer、爬取耗时，以及服务器返回的Content-Type。它们分别回答“谁来了、访问了什么、结果如何、从哪个页面跳过来”这四个问题。缺少Referer时，内链路径就无法还原，这是第一次排查时最容易忽略的一点。

先分清日志类型，再决定字段优先级

服务器访问日志、CDN日志和搜索引擎后台的抓取统计不是一回事。服务器日志记录的是到达源站的请求，CDN日志可能包含边缘节点缓存命中，搜索引擎后台只展示该引擎愿意公开的抓取数据。做内链策略时，建议以服务器日志为主，因为它能反映爬虫实际请求的URL和状态码；CDN日志可用于判断缓存是否拦截了爬虫，搜索引擎后台数据用于交叉验证，不能单独作为内链是否被发现的依据。

如果站点使用反向代理或CDN，源站日志里的客户端IP可能变成代理IP，这时要确认日志中是否保留了X-Forwarded-For或类似字段。否则按IP识别爬虫会全部误判。

逐项核对：每个字段用来判断什么

• 请求时间：判断爬虫集中抓取的时间段，以及新内链上线后多久被首次抓取。时间字段要确认时区，避免和后台报表对不上。
• 请求方法：内链抓取以GET为主。如果大量内链目标只出现HEAD请求，说明爬虫在探测但未完整获取内容，需要结合状态码进一步判断。
• 请求URL：核对是否包含参数、大小写、末尾斜杠、URL编码差异。同一内容出现多个URL变体，会稀释内链指向，是内链策略里最常见的问题之一。
• 状态码：200表示正常返回；301/302表示跳转，要确认跳转链是否过长；404表示内链指向了不存在的页面；5xx表示服务器或应用出错。把404和5xx按来源页面分组，能直接定位哪些内链需要修复。
• 响应大小：同一URL的响应大小突然变小，可能返回了错误页或空模板；大小为0通常意味着请求被中断。
• User-Agent：用于区分不同爬虫和普通用户。注意UA可以被伪造，不能只凭UA就断定是某个搜索引擎的爬虫，必要时应结合反向DNS或搜索引擎提供的验证方式核对。
• Referer：还原内链来源页面的关键字段。如果为空，可能是从外部直接进入、从HTTPS跳到HTTP被浏览器省略、或者页面使用了rel="noreferrer"。它决定了你能否画出“从哪个页面链到哪个页面”的路径。
• 爬取耗时：耗时异常长的URL会拖慢整站抓取预算，内链再合理也可能因为响应慢而减少被抓。
• Content-Type：确认返回的是HTML而不是图片、PDF或JSON。内链指向的资源类型不对，爬虫不会按页面处理。

一个假设例子：新内链上线后怎么查

假设你在某篇文章正文中新增了一条指向产品页的内链，想确认爬虫是否沿着它走过去了。可按下面步骤操作：

1. 记录内链上线的时间点，以及来源页URL和目标页URL。
2. 在日志中先筛目标页URL，看上线后是否出现新的请求记录。
3. 如果有请求，查看对应状态码：200说明抓取成功；301/302要跟到最终URL；404说明链接写错或目标页已删除。
4. 查看这些请求的Referer，确认是否来自你新增内链的那个来源页，而不是导航、页脚或外部链接。
5. 如果目标页始终没有请求，再回到来源页URL，检查来源页本身是否被抓取、状态码是否正常、内链是否被JavaScript动态插入或加了nofollow。

常见错误有三种：一是只看目标页总访问量，不区分来源，导致无法判断内链是否生效；二是忽略URL变体，把带参数的请求和规范URL当成两个页面；三是把robots.txt的抓取限制当成索引移除手段。robots.txt只能阻止爬虫抓取，不能可靠地把已收录页面从索引中移除，这两件事要分开处理。

核对顺序与判断结果

建议按“状态码 → URL规范 → Referer → 抓取频率”的顺序排查。状态码异常先修链接和服务器；URL不唯一先统一内链指向；Referer缺失再检查跳转协议和页面代码；最后才看抓取频率是否偏低。这样能避免在链接本身有问题时，误以为是抓取预算不足。

还要注意，站点地图提交不保证收录，HTTPS也不保证安全无漏洞或排名提升，它们和日志字段核对是不同层面的工作。不同搜索引擎对同一字段的支持和展示方式需要分别核查，不能拿一个引擎的日志结论直接套到另一个引擎上。

下一步：从日志中导出最近一段时间的爬虫请求，按目标URL分组，统计每个URL的状态码分布和Referer来源，先找出404和5xx对应的来源页面，再决定修复哪些内链。