注册即送 $100 免费额度，无需绑卡。链接数据低至 $0.0001/次调用。
分步配置指南
无需记忆的工作流优于那些大家总想去做却未执行的工作流。通过六个步骤，你可以从空白电子表格开始，建立一个每月自动运行并记录自身成本的定时任务。
使用 /auth/google.php 进行 Google 登录。/account.php 仪表板包含你的密钥（以 sk_ 开头），并附带 $100 的信用额度。
针对你自己的域名运行概览操作，无需提供密钥。如果返回的 JSON 中 ok 设置为 true，则说明网络路径正常。
电子表格中仅保留一列，每行一个域名，不包含 https 和路径。单次 bulk_dr 请求最多可处理 2,000 行。
将列表作为逗号分隔的 GET 值或 POST 主体发送。将回复存储到带有日期列的第二个标签页中。
在每月第一天后的几天运行任务，待月度索引刷新完成后执行。只需一行 cron 命令即可。通过手动检查前几个已知域名的输出结果来验证第一个月的输出。
每次经过身份验证的回复都包含 _credits 字段，显示成本和剩余余额。将两者写入日志行，并在低于你设定的阈值时通过电子邮件通知自己。
替换为你自己的密钥和文件名。
# crontab: 06:00 on the 4th of each month
0 6 4 * * /usr/bin/curl -s -X POST \
-H "Authorization: Bearer sk_live_..." \
-d "domains=$(paste -sd, domains.txt)" \
"https://aseotools.com/api.php?action=bulk_dr" >> dr_log.jsonl将密钥存储在 Apps Script 属性、环境变量或自动化工具的凭据存储中。任何拥有电子表格编辑权限的人都可以读取单元格中输入的密钥，而泄露的密钥会消耗你的信用额度。
静默是常见的失败形式。出错的定时任务看起来与成功运行的任务无异。
检查 HTTP 状态码。401 表示密钥缺失或错误，402 表示信用额度耗尽，因此应对这两种情况发出警报，并在下个月报告到期前修复问题。
请记住，分页上限为 50,000 行，且每次 bulk_dr 调用最多处理 2,000 个域名。更长的列表需要分块处理，这需要额外的循环，并且每个分块消耗一个信用额度。
先手动测试。在终端中运行 cron 命令，读取日志文件，并检查余额是否恰好下降了预期的成本。然后查看 与套件计划的成本对比，决定运行频率。
对域名列表进行版本控制。将文件保存在具有历史记录功能的存储库或共享驱动器中，以便当三月份某个数字发生变化时，你可以查看列表是否也随之更改。为有意添加的域名（如新竞争对手或当月签约的客户）添加备注列。将列表视为有所有者的数据，因为最便宜的错误是在差异对比中发现的。
长列表是整洁配置的极限所在。单次批量调用最多处理 2,000 个域名，因此 5,000 个域名的列表需要三次请求，且拆分必须在首次调用之前完成。
按稳定规则拆分，例如按域名列的排序顺序。这样，相同的域名每个月都会落入同一个分块中，从而保证对比的有效性。
将每个分块作为独立块写入电子表格，并在第一列标注分块编号。这样便于查找失败的分块。
每个分块消耗一个信用额度，因此 5,000 行的列表每次运行消耗 3 个信用额度，即 $0.0003。域名评分工具的实用性取决于其读取的列表，因此请保持列表整洁。
如果列表超过 5,000 行，请重新考虑电子表格的布局。为每个月设置一个标签页，以便在行数堆积时保持每次运行的可读性。
如果第二个分块返回错误，仅重新运行第二个分块。重新运行整个列表会对已经返回的行重复消耗信用额度。
在日志中记录分块编号和状态码，以便重新运行只需在日志中添加一行，而无需在电子表格中查找。
如果域名列表的顺序发生变化，分块也会随之移动，导致月度对比失效。每次拆分前都对列表进行排序。
将分块映射存储在列表旁边。
一个简单的测试：选择任意分块，并根据列表重新计算其行数。如果存在不匹配，说明映射已漂移，在电子表格中发现比在报告中发现成本更低。
| 列表规模 | 每月调用次数 | 信用额度 | 美元 |
|---|---|---|---|
| 200 个域名 | 1 | 1 | $0.0001 |
| 5,000 个域名 | 3 | 3 | $0.0003 |
| 5,000 个域名加上 20 次完整的 backlink 拉取 | 23 | 43 | $0.0043 |
仅显示 ok 的日志算不上真正的日志。每次运行应写入一行，让疲惫的人在十秒内即可读懂：日期、分块、状态、消耗的信用额度以及调用后的余额。
假设情况：一行显示第四个分块、状态 200、消耗一个信用额度以及调用后的剩余余额，这可以在一个月后回答大多数问题，而无需打开回复内容。
记录日期、列表名称、分块编号、状态码、扣除的信用额度和调用后的余额。这六个字段可以覆盖一个月后的大多数问题。
仅在人手工更改内容时添加自由文本备注。
一旦出现 401 或 402 错误，立即发出警报，因为这两种情况都意味着任务无法执行。低余额警告应使用你设定的阈值，以便仅触发一次并说明下一步该做什么。
每次运行发送一条警报，而不是每行发送一条，以免收件箱被噪音淹没。
可以。API 是标准的 REST 架构，支持开放 CORS 和 JSON 回复，因此 Apps Script 或 IMPORTDATA 风格的调用均可访问。请将密钥存储在脚本属性中，而不是存储在协作者可以读取的单元格中。
可以，通过标准的 HTTP 请求节点。将密钥作为 Authorization Bearer 头传递，解析 JSON 回复，并将 _credits 字段写入日志，以便查看每次运行的消耗情况。
计算调用次数，而不仅仅是列表大小。每次运行、重试或测试调用都会增加其成本，且每次回复中的 _credits 字段提供了该次调用的确切数字。
这样更简单，但任何可以读取 crontab 的人都可以看到密钥。应从具有受限权限的文件或为该任务设置的环境变量中加载密钥，并将其从共享日志中移除。
月度任务在无人监视的情况下运行。这正是自动化的目的，但也意味着失败可能在数周内未被发现。
指定负责读取日志的人和负责修复任务的人。两个名字比一个好。假期是可能发生的。运行手册 解释了如何首先选择列表。
首次运行需要花费大部分时间，因为密钥、电子表格和测试调用都需要关注。此后，该流程每月只需瞥一眼即可，无需重建。
如果维护工作量增加，通常是因为列表问题。每周变化的列表需要所有者、版本和添加规则。
输出中缺失的行比静默错误更容易被发现。每次运行时将行数与列表长度进行对比，并在两者不一致时写入警告。
将该警告保留在同一个日志文件中，以便读取日志的人首先看到它。
索引大约每月刷新一次，因此在每月第一天运行可能会读取到上一个构建周期的数据。如上述步骤建议，在几天后运行，以便让刷新有时间完成。
每月选择同一天运行，以保持系列数据的可比性，并将该日期写入 cron 命令的注释中。
每季度运行一次的任务可能不值得配置 cron 命令。电子表格和日历提醒可能就足够了，半自动化的流程可能不如清晰的流程化手动操作。
当相同的步骤连续几次干净地运行后，再进行自动化。
