资讯动态

每天 1.4 万个新职位如何被搜索引擎收录:freehire 用 Google Indexing API + IndexNow 的账本式配额设计

发布时间:2026/10/22 2:22:41 来源:尧图企业网站定制
【免费下载链接】freehirefreehire — the open-source search engine for job seekers项目地址https://gitcode.com/GitHub_Trending/fr/freehire点击查看免费下载freehire 是一个开源的职位搜索引擎open-source search engine for job seekers。它的站点每天新增约 1.4 万个技术类职位页面而 Google 的爬虫一天只主动抓取 65 个——如果只靠等爬虫来绝大多数新职位在上架很久之前就过期了。freehire 的解法是一套围绕Google Indexing API IndexNow的账本式配额设计不是把 URL 塞进队列排队而是记下已经告诉过谁每次运行重新挑选最值得报的新页面。本文带你拆解这套设计的来龙去脉。为什么等爬虫在 69 万页规模下失效设计这套系统的起点是一组生产环境的实测数据2026-09-14指标数值Googlebot 当天抓取的职位页65 个sitemap 声明的职位页~690,000每天新增技术类职位~14,000从 sitemap 抽样做 URL Inspection 的结果URL is unknown to GoogleURL is unknown to Google不是被拒绝或质量低而是从未被抓过。而职位页面是易腐的——雇主一撤下原链接页面就该关闭几个月后才被首次抓取的页面在可达之前就已经过期了。于是 freehire 把策略反转过来不等人来爬主动告诉搜索引擎这里有个新页面。相关背景还记录在 docs/seo-baseline.md 里。核心设计账本Ledger不是队列Outbox这是整个方案最有意思的一点。schema 里其他队列search_outbox、recent_feed_outbox等都满足排空速度 填充速度唯独这个不能Google Indexing API 的默认配额是每天 200 次 publish而每天新增上万职位如果用常规 outboxingest 写入、worker 消费队列会无限增长最老的一行永远轮不到所以 migrations/0162_job_search_pings.sql 里记录的从来不是待办而是**已发送的事实**。job_search_pings (job_id, engine, kind, pinged_at)每次cmd/search-ping运行时通过反连接anti-join找出该引擎还没被告知过的最新合格职位挑完即发。选择逻辑可以随时改变不存在需要消化的积压。最新优先是唯一的选择策略在配额远小于目录的情况下按created_at DESC取最新一举两得职位页只在招聘中才值得公告公告越早价值越高它顺带替代了一个过滤器——sitemap 会排除likely-evergreen长期常开职位这个类别只存在于搜索索引里无法在这里 join但它是靠长期不关闭赚来的所以最新行天然不可能是它。技术职位优先其他类别兜底目录并不只有 IT。合格门槛是搜索索引愿意收录开放、canonical、公开、有正文、类别可解析。在此之上分两层tier层级内容配额待遇TierTechis_tech为真技术类职位Google 的 200/天先给它TierBeyondTech其余有类别的职位医疗、零售、物流…只能用剩下的注意这是优先级不是资格规则——医疗或物流职位同样是站点主张的页面、同样带JobPosting标记。而 IndexNow 没有配额每一层每次都能领到一整批。选择查询写在 internal/platform/db/queries/job_search_pings.sql两层是一次查询跑两遍而不是ORDER BY is_tech DESC——后者无法走created_at索引会为挑 200 条而排序全部开放职位。两个事件创建与关闭都是 URL_UPDATED一个职位页会被公告两次出现时created、关闭后closed但两次都发URL_UPDATED见 migrations/0163_job_search_pings_kind.sql 的设计说明关闭后的页面仍是 HTTP 200保留JobPosting标记只是validThrough移到了过去——这是 Google 文档认可的下架职位方式之一所以需要的是重新抓取对仍在线的页面发URL_DELETED属于误用 API惩罚就是配额本身。kind列因此把同一职位拆成两条独立事实否则反连接会因为创建那行而永久跳过关闭公告。另外新职位先花预算新职位带来访客关闭公告只是整理一个不属于自己的索引。在 200/天 对 1.4 万/天的量级下第一遍就把配额吃完是正确行为配额一旦提升关闭公告无需改代码自动开始流动。两个引擎的分工Google Indexing API vs IndexNowGoogle Indexing APIIndexNow覆盖引擎只有 GoogleBing、Yandex、Seznam、Naver预算200 次/天可申请上调无公开配额凭证服务账号且必须是 Search Consoleowner站点公开提供的一个 key 文件批量一次调用只报 1 个 URL批量省的是 HTTP不是配额一次最多 10,000 个部分失败正常现象不可能——整批同答两个适配器分别实现在 internal/job/searchping/google.go 和 internal/job/searchping/indexnow.go统一实现Engine接口Name/DailyBudget/Accepts/Announce。Announce返回的是引擎接受的 URL 子集——账本只记引擎拿走的从不记递出的否则部分失败的批次会被整批入账没发出去的部分就再也不会被选中。公司页只能走 IndexNow 的资产通过 Bing Webmaster API 实测2026-09-15Bing 索引里的 25.5 万个页面中曝光最高的正是/companies/slug背后的查询形态全是公司名 careersBingbot 两天里抓了 6,275 个公司页 vs 3,679 个职位页。公司页是 freehire 自己装配的某雇主全部在招岗位雇主自己往往根本不发布——这是真正值钱的页面。但 Google Indexing API 只接受JobPosting和BroadcastEvent两类页面把公司页发过去就是违反条款惩罚是配额。所以拒绝逻辑写在引擎自己身上Engine.AcceptsGoogle 拒收KindCompanyIndexNow 全收。公司页另有独立账本 migrations/0164_company_search_pings.sql且没有 kind 列——公司页只有一个事件存在职位全部关闭它也仍是 200 页面。藏在细节里的四个陷阱1. 配额日在太平洋时间午夜重置。预算日既不是 UTC 也不是主机时区。代码里直接time.LoadLocation(America/Los_Angeles)并导入time/tzdata内嵌时区库——因为固定-8会在夏令时期间让边界晚一小时那小时的发送看起来没花钱实际 Google 在记账运行就会超支。剩余配额不是问 API 问来的API 只会在用完时回429不会自报余量而是从账本读回来的PingsSince数出该引擎今天已发的条数。2. 发送是至少一次at-least-once方向是刻意选的。HTTP 调用无法加入记录它的数据库事务两种顺序必有一个吃亏先发后记失败代价是一次重复公告有界、可见、无害先记后发失败则这个职位永久且静默地失去公告机会已入账的行永远不会再被选中。loud and bounded 的失败才是该保留的那个。3.siteFullUser不是siteOwner。用Full权限把服务账号加进 Search Console 可以读所有报告但 Indexing API 会回403 ... Failed to verify the URL ownership——报错里根本不会提示你去改角色。4. IndexNow 的 key 天生是公开的。它放在站点静态目录web/static/key.txt里供引擎回验是所有权证明而非机密。key 同时存在于站点文件和 worker 环境变量INDEXNOW_KEY两处一旦漂移IndexNow 会对每次提交回403看起来像集成坏掉了。所以启动时VerifyKey会抓取文件比对一次不一致就拒绝运行。一小时一次的运行与无感回滚入口 cmd/search-ping/main.go 每次运行给每个引擎 × 事件发一批后退出建议按小时调度SEARCH_PING_BATCH默认 200限制单批规模./search-ping # 正式公告 ./search-ping -dry-run # 只打印将要发送的 URL不发送事件竞争引擎一天的固定顺序就是策略本身新建·技术→新建·其他→公司页→关闭。有配额的引擎按顺序消耗剩余量无配额引擎IndexNow每遍各领一整批429 一到就停止该引擎的剩余批次继续发只会烧掉明天的配额——除了 429 以外的失败都耗配额。回滚同样优雅清掉GOOGLE_INDEXING_KEY_FILE和INDEXNOW_KEY两个环境变量即可。没有凭证的引擎视为未配置静默跳过两个都没有时运行是一次连数据库都不打开的空操作定时器可以原样保留。小结这套设计给大规模内容站做了 SEO 收录的团队留下了几条通用经验配额是设计约束不是管道参数——先确认一天能花多少再决定数据结构账本优于 outbox当消费速度永远追不上生产速度时记录已做比排队待做更可靠把平台规则写进引擎适配器Accepts、DailyBudget让策略顺序和具体引擎解耦接受 at-least-once选那个失败响亮且有界的写入顺序。核心实现都在 internal/job/searchping/ 目录下配合 docs/seo-baseline.md 中收录的实测数据可以完整复现这套决策的过程。赞分享【免费下载链接】freehirefreehire — the open-source search engine for job seekers项目地址https://gitcode.com/GitHub_Trending/fr/freehire点击查看免费下载相关推荐Linux桌面快捷启动3分钟让Umi-OCR离线OCR识别触手可及Linux桌面快捷启动3分钟让Umi OCR离线OCR识别触手可及 作为一款功能强大的免费开源OCR工具Umi OCR提供了截图识别、批量处理、二维码识别等桌面应用OCR计算机视觉Rendr.js与SEO如何让你的单页应用被搜索引擎完美收录Rendr.js与SEO如何让你的单页应用被搜索引擎完美收录 想要让你的单页应用在Google搜索中获得好排名吗 传统的客户端渲染应用面临着一个巨大的挑后端软件架构WebSlides SEO优化如何让你的演示文稿被搜索引擎收录WebSlides SEO优化如何让你的演示文稿被搜索引擎收录 WebSlides是一款强大的HTML演示文稿制作工具让你的演示内容不仅美观还能被搜索引擎前端UI组件上一篇17种Java代码坏味道大清单CoDiver代码嗅探器帮你根除技术债务下一篇官宣 Opus 4.8 级性能这只自己出题自己练的开源AI还能塞进 iPhone 17创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑