当返回的行看起来不正确时，如何通过 API 检查反向链接

首先检查这三项

大多数异常提取可归结为三个原因之一。每个原因均可在不到一分钟的时间内进行检查，因此在花费一小时排查行数据之前，先排除这些原因是明智之举。检查这三项：密钥、信用余额或快照日期。

每个经过身份验证的响应都包含 ok 字段和一个包含成本和剩余余额的 _credits 对象，因此第一步始终是打印这两个字段。始终从那里开始。如果 ok 为 false，那么行数据本身尚不重要。

然后检查月份。我们的索引大约每月刷新一次，上周添加的链接可能 simply 不在其中，这并非错误。

另一个习惯。每次调用时记录一行日志，包含操作、页码和来自 _credits 的剩余余额；这使得追踪缺失的 7 个信用额度变得容易，而不是等到月底才变成谜团。

正确解读短结果

小型域名可能确实只有少量锚文本。最近注册的域名，或者拥有较少外部链接页面的域名，可能会产生因完全正常原因导致的短列表。短列表并非故障。并非所有短列表都是失败。

将行数与同一域名的免费 overview 数据进行比较：如果 overview 报告有数千个反向链接和锚文本，而 anchors 在第一页只返回四十行，你可能需要第二页，而不是提交支持工单。如果 overview 本身只报告少量，则该域名较新或较小，提取是正确的。先计数，再抱怨。

情况也可能相反。大型域名会触及 50,000 行的分页上限，因此按你关心的列排序并获取顶部切片，或先调用 anchor_cloud 查看哪些术语占主导地位，然后再分页查看所有内容。

排序和分页设置会改变你看到的内容

两次提取可能因与网络无关的原因而不同。排序、顺序和页面大小共同作用，因此更改其中一项可能会重新排列整个结果，即使域名和密钥完全相同。排序、顺序和页面大小决定了哪些行排在前面以及每次调用返回多少行。首先检查这些设置。

相同域名，不同的领先项

第一行遵循你要求的排序，因此以不同方式排序的文件看起来不会一样。排序会改变领先项。如果一个文件以最大的引用站点为领先，而下一个文件以最新的行为领先，两者都可能是正确的。在文件名中注明排序方式。

快速测试会有帮助。首先在一个小型域名上运行，这样测试成本几乎为零，并能对请求给出明确答案。使用相同的参数两次调用相同的操作。如果行匹配，则差异在于请求，而非数据。

第二页不是第一页的副本

每一页都是独立的调用，有独立的计费行，且一页的行不应在下一页重复。页面是独立的调用。如果重复，循环可能保持了相同的页码值。打印每页的第一个域名以确认数字是否发生变化。

在日志中将页码与余额一起保存。当循环在第二页停滞时，如果你能看到停止的确切调用，修复起来会容易得多。日志可以节省数小时。

首先测试两页。前两页之后的简短测试就足够了。如果第二页重复了第一页，在余额为重复的行付费之前停止循环。

与上月文件解决争议

当两个文件不一致时，问题通常不在于谁对谁错。大多数不一致是由无人记录的设置更改引起的，这就是为什么日志比记忆更重要。问题在于请求的哪一部分在两者之间发生了变化。首先查看请求。按顺序进行三项检查，大多数争议会在第一次检查时结束。

从索引日期开始

索引大约每月刷新一次，该刷新是首先要排除的因素。在上次刷新后上线的链接不会出现在任何文件中，当天重新提取也无法解决此问题。刷新日期解释了差距。

标记每个文件。以提取日期和刷新周期命名的文件可以在任何人开会提问之前回答最常见的问题。在每个文件名旁边写下刷新周期。这样，差距会被读作时间上的差距，而非网络上的差距。

将刷新日期集中在一列中，不要分散在笔记中。在总数旁边看到日期的读者很少需要问第二个问题。这能节省一个问题。

同类比较

只有当操作、域名、排序和 per 值匹配时，两个文件才可比较。如果排序不同，即使每个总数都匹配，领先行也会不同，这看起来像是配置文件中的真实变化。将 anchors 文件与 backlinks 文件混合是制造从未发生过的下降的常见方式。匹配设置优先。

如果参数匹配但总数仍然不同，则这种差异值得更仔细的检查，日志会告诉你从哪里开始。然后阅读日志。

也为 per 值设置一列，因为它会改变每次调用返回的行数，从而影响提取的成本。保持其可见。

当行移动而非消失时

域名更改或重新设计后，链接可能仍然存在并指向新地址。旧主机保留链接。在调用链接丢失之前，比较旧主机和新主机的顶级页面。迁移检查清单 将引导你完成该配对。

记录双方。在一行中记录两个地址，以便在表格中保持移动可见。

令人惊讶的成本

账单增长速度快于计划通常有一个原因。许多团队仅在月底才注意到账单更高，因此每周查看运行总数可以更早发现偏差。这是操作。许多读者询问如何在不超支的情况下检查反向链接，答案始于操作名称。在每个响应中读取余额，并在表格旁边保持运行总数。

余额比计划消耗得更快

操作名称很重要。常见的罪魁祸首是操作名称。anchors 花费 2 个信用额度，而 keyword 和 search 各花费 3 个，因此切换操作的脚本悄悄提高了账单。在第一次大型运行之前，检查请求中的 action 值。

追踪偏差。在表格中保持 _credits 的运行总数。每天的微小偏差在那里很容易看到，远在月底之前。

循环中途出现 402

402 意味着余额已耗尽。停止循环。已服务的调用已计费，而下一个调用失败。停止循环，从账户页面使用 USDT (TRC-20) 充值，并从停止的页面恢复。

恢复点只有在记录时才有用。在日志中保留页码，以便重启不是猜测。写下页码。

解读过大的结果

突然增长的计数值得在成为故事之前查看来源。单个模板链接可以增加数千行，而仅凭总数行无法告诉你这是一个站点还是多个站点。行可能是正确的，原因可能位于一个域名中，而非整个配置文件。首先检查来源。

大计数背后的全站页脚

出现在单个站点数千页上的单个模板链接可以解释大量行。按链接域名对提取进行分组，看看一个站点占总量的多少。先分组，再判断。

如果一个域名占主导地位，则总数是该站点的事实，分析应以这种方式呈现。以这种方式呈现。

来自你从未链接的域名的行

异常的锚文本需要检查。它们的存在并不能证明有什么错误，但这意味着该行值得像分析中的任何其他行一样进行解读。不熟悉的链接域名带有不相关的锚文本可能来自爬虫或受感染的页面。在假设行属于你的配置文件之前，像访客一样打开其中一个链接页面。

在表格中记录域名、日期和锚文本，并保留原始响应，以便后续审查有据可查。证据胜过记忆。