先免费检查外链,然后有目的地花费 $100
四个操作无需成本。启动余额为 1,000,000 个信用额度。这些预算展示了这些额度在典型开发者项目中能走多远。

价格表汇总
预付费,无订阅,无月度最低消费。1 个信用额度等于 $0.0001。
三个预算,均为假设
这些是规划示例,并非来自真实账户的报告。更改数量后算术关系仍然成立,因此可以替换为您自己的数据。
预算 A,公共小部件
博客上的免费 DR 检查器使用 domain,成本为 0 个信用额度。每月一万次查询在 API 中是免费的,您面临的唯一账单是托管费用,这与 SEOMasters.dev 无关。博客上的免费检查外链工具是相同的调用,从访客可见的页面发起。
像 Next.js 指南那样缓存免费调用一天。一个小部件从一篇热门帖子获取一千次查询,然后每天对每个域名进行一次上游调用,这使算术计算更简洁,页面加载更快。
小部件的关键账单是其托管和流量处理,因此先对这些进行定价,并将 API 视为其实际的小额项目。
预算 B,机构报告
每月 300 个客户域名,每个域名一次 refdomains 调用,每次 2 个信用额度。每月 600 个信用额度,每年 7,200 个,即 $0.72。金额很小。以该速率计算,$100 余额可覆盖约 139 年,因此存储和您自己的时间占主导地位,而非 API。
时间表是关键杠杆。如果每周运行相同的 300 个域名而不是每月运行,意味着运行次数大约增加四倍,但由于索引大约每月刷新一次,大多数每周答案会重复上一次的结果。
预算 C,完整导出
一个域名,50 次 1,000 行的调用以达到 50,000 上限,每次 2 个信用额度:100 个信用额度,即一美分。对 1,000 个域名重复此操作,您将花费 100,000 个信用额度,即 $10,占 $100 余额的十分之一。
信用额度成本很小,但存储的行并非如此。像规划信用额度一样规划磁盘空间,并仅保留您的报告读取的列。
如果导出必须每月重复,则月度数字是应放入预算的数字,而非一次性总数。
预算中未包含的内容
注意缺失的内容:月度计划。没有需要续订的订阅,您为调用付费,而非席位。便宜。每个预算都基于同一个事实。批量脚本 和 分页说明 展示了这些调用计数背后的代码。
忽略时间的预算是不完整的,因此下一部分将添加价格表之外的成本。
每个预算中还应有一行:重新运行失败作业的成本。如果运行停止并从顶部重新开始,已付费的调用将重复,因此恢复逻辑也是预算项目。
相同的资金,另一家供应商
| SEOMasters.dev API | Ahrefs API(报价) | |
|---|---|---|
| 入口点 | $0,然后是预付费信用额度 | 每月 $129 起 |
| 配额 | 注册时免费获得 1,000,000 个信用额度 | 每月 200,000 个单位 |
| 每次请求的最低限制 | 无;免费操作成本为 0 | 至少 50 个单位 |
| 在该最低限制下每月的大多数请求 | 不适用 | 4,000 |
| 关键词、排名跟踪、每日爬取 | 未提供 | 是,Semrush 也提供 |

预算未包含的内容
API 行是大多数项目中最小的项目。其他三个成本通常更重要,预算页面应指出它们。
托管和存储
您的服务器、数据库和 cron 主机分别计费,加在一起的成本可能超过调用本身的成本。想象一下小型 VPS 上的夜间作业:VPS 是需要注意的行,而非调用。
存储响应的原始表也占用磁盘空间。根据保存的一批数据估算其增长,乘以您计划的运行次数。
在选择主机之前对作业进行定价。每月运行一次的 cron 作业所需资源远少于全天运行的工作进程,这种差异往往决定预算。
日志也是一项成本。每次调用一行,保留一年,在繁忙的作业中会累积,因此应有目的地决定保留期,而非默认设置。
两年后迁移
为退出预算,而不仅是为开始预算。如果两年后出现重新设计或新供应商,工作是获取层和字段映射,批量脚本 保留了使该映射更容易的原始主体。
只要历史记录对您有意义,就尽可能长时间保留旧响应,因为它们是您的报告所用数字的唯一记录。
现在写下退出计划需要一小时。两年后发现从未保留原始主体,则需要重建历史记录。
在原始主体所在的同一文件夹中存储您读取的每个字段的简短描述。该描述使未来的团队无需猜测即可映射历史记录。
您在获取层上的时间
获取层、重试和允许列表需要一下午编写,更长时间测试。在决定免费工具是否免费之前,计算这段时间。
这是大多数预算忽略的行,通常是托管之后最大的项目。无论如何都要写下来,以便比较诚实。
一个好的测试是新开发人员从头开始进行一次调用所需的时间。如果这需要一天,获取层是项目的真实成本,而非信用额度。
在该时间旁边放置一个粗略的每小时数字,即使是猜测。写下来的猜测比从未出现在表格中的成本更容易受到质疑。
在信任之前检查算术
预算的质量取决于其乘法。两个检查可以在计划运行之前捕获大多数错误。
从每个信用的价格开始
1 个信用额度等于 $0.0001。这使得 10,000 个信用额度等于 $1,完整的 1,000,000 启动信用额度等于 $100,这是规划表需要的唯一转换。
将转换写入一次,在单元格或常量中,并重复使用。在三个地方重新输入它是导致表格出现三个不同价格的原因。
在最后一行之前保持表格以信用额度为单位。提前转换然后再次乘法是因子十无声滑入的常见位置。
带有货币列的规划表会引发舍入。在美元列旁边保留信用额度列,让美元成为派生数字。
用余额测试一次调用
进行一次付费调用,读取调用前后的 _credits,并检查下降量是否等于操作的价格。refdomains 调用应使余额移动 2 个信用额度,search 调用移动 3 个。
如果下降量不同,请在计划运行将不匹配放大之前停止。测试调用成本为几分之一美分,这是整个预算中最便宜的检查。
将测试记录在与运行相同的日志中。一个月后,测试行显示在编写表格时每个操作的成本,如果价格表发生变化,这将很有用。
在您的账户页面上也检查一次余额。两个数字应一致,如果不一致,值得在运行手册中做简短说明。
在代码中设置月度预算
- 1
计算付费调用
计算每次运行的付费调用次数,乘以一个月内的运行次数。将总数写入代码旁边的配置文件。
- 2
将调用转换为信用额度
乘以价格表中的信用额度成本:
bulk_dr为 1,refdomains为 2,search为 3。结果是每月的信用额度消耗。 - 3
设置警报级别
选择一个应发送消息给充值人员的余额。将其与上次响应中的
_credits值进行比较。 - 4
一个月后审查
将实际消耗与估计值进行比较。差距通常意味着循环、重试或您未预期运行的操作。

我们会将其放在哪里
每月深度拉取花费,其余免费
由于索引大约每月刷新一次,比每月更频繁的调用会重复昨天的答案。每月安排付费拉取,让四个无需密钥的操作处理日常查询。
- 缓存免费调用一天
- 在代码中允许付费操作
- 每次调用后记录
_credits - 仅当余额值得时以 USDT (TRC-20) 充值
资金问题
- $100 会过期吗?
- 我们为此网站持有的材料未给出过期时间,因此我们不声明。在计划长期作业之前,请检查账户页面,该页面显示您的余额和活动。
- 开始需要卡片吗?
- 不需要。使用 Google 账户登录,$100 信用额度将自动添加,无需卡片。稍后的充值通过账户页面以 TRC-20 网络上的 USDT 进行。