JSON-LD JobPosting：如何在聚合平台索引前发现职位
许多招聘页面会嵌入一份机器可读的职位描述。页面包含有效的 JSON-LD JobPosting 时，它往往比渲染后的 HTML 更适合监控，也能帮助你理解搜索产品如何发现和展示职位。
许多职位页面会在可见 HTML 旁放置机器可读的描述，其中可能包含职位名称、地点、发布日期、薪资和雇主等字段。常见格式是嵌在脚本标签里的 JSON-LD JobPosting。是否提供、字段是否完整都因页面而异，所以应把它当成值得检查的数据源，而不是所有招聘页面都具备的保证。
理解这一格式有两个用途：它解释了搜索引擎如何从公司页面读取结构化信息，也给技术读者提供了更干净的监控入口。缺失、无效或由 JavaScript 后加载的数据仍需要备用处理方式。
它到底是什么
JSON-LD 是在网页中嵌入机器可读数据的一种方式。schema.org/JobPosting 定义的 JobPosting，是 Google 用来读取网页结构化信息的多种类型之一。
Google 将 JobPosting 结构化数据列为进入职位搜索体验的一条资格路径，但符合条件并不保证展示。许多现代 ATS，包括 Workday、Greenhouse、Lever、Ashby、Phenom 和 iCIMS，会在部分公开职位页面提供结构化数据。实际情况仍取决于平台、模板和雇主配置。
它长什么样
查看一个典型职位页面的源代码并搜索 application/ld+json，你可能会看到类似内容：
{
"@context": "https://schema.org",
"@type": "JobPosting",
"title": "Senior Backend Engineer",
"description": "We're looking for...",
"datePosted": "2026-05-12",
"validThrough": "2026-08-12",
"employmentType": "FULL_TIME",
"hiringOrganization": {
"@type": "Organization",
"name": "Acme",
"sameAs": "https://acme.example"
},
"jobLocation": {
"@type": "Place",
"address": {
"@type": "PostalAddress",
"addressLocality": "London",
"addressCountry": "GB"
}
},
"baseSalary": {
"@type": "MonetaryAmount",
"currency": "GBP",
"value": {
"@type": "QuantitativeValue",
"minValue": 90000,
"maxValue": 130000,
"unitText": "YEAR"
}
}
}datePosted 记录结构化数据声明的发布日期，baseSalary 则可能包含雇主提供的薪资。字段可能缺失、过期或格式错误，使用前应与可见广告核对。
为什么对求职有用
主要有三个实用原因。
1. 它提供雇主页面声明的发布日期
datePosted 往往比“3天前发布”这类平台相对标签更有参考价值，但也不是绝对时钟。雇主可能更新、省略或复用日期，聚合平台也可能经不同路径接收职位。我们的源头与聚合平台对比把它视为需要核对的证据，而不是不容质疑的事实。
2. 它解释了搜索引擎如何读取职位页面
搜索引擎抓取页面时，结构化数据提供一份直接的职位描述。抓取时机、索引和展示都没有保证，其他平台也可能通过不同路径接收和处理职位。我们的聚合平台延迟分析讨论了晚于源头发现职位的实际影响。
3. 它为自建监控提供干净入口
有效的 JSON-LD 已经把字段结构化，适合作为监控的第一数据源，但不能取代备用方案。数据块可能缺失、损坏、嵌套异常或在初始 HTML 之后加载。先查找 <script type="application/ld+json">，验证结果，并准备好在它不存在时继续处理页面。
如何自己检查
在任意浏览器中都可以这样做：
- 打开职位页面，例如 Greenhouse 或 Lever 链接。
- 右键选择“查看网页源代码”，或按 Ctrl+U / Cmd+U。
- 搜索
application/ld+json。 - 在一个或多个 JSON 块中找到
"@type": "JobPosting"。
Google 的富媒体搜索结果测试可以发现结构化数据错误和资格问题。通过测试并不保证 Google 会索引或展示职位。
为什么只看 ATS 名称不够
- 托管的 ATS 页面：多个平台可能提供 JobPosting 数据，但支持程度因模板和雇主配置而异。
- JavaScript 渲染页面：结构化数据可能在页面运行后才出现，原始响应里看不到。
- 自建招聘网站：实现完全取决于雇主，公司规模或品牌不能替代检查。
- 任何平台：都应检查你实际要监控的职位页面，平台层面的预期不是单页证据。
ATS 完整指南说明了如何识别公司使用的系统。
最小版“自己做监控”示例
技术读者可以从下面的 Python 轮廓开始：监控单个招聘页面中的新 JSON-LD JobPosting 条目。
import json, re, requests, hashlib
from bs4 import BeautifulSoup
def fetch_postings(url):
html = requests.get(url, headers={"User-Agent": "Mozilla/5.0"}).text
soup = BeautifulSoup(html, "html.parser")
out = []
for tag in soup.find_all("script", type="application/ld+json"):
try:
data = json.loads(tag.string)
except (json.JSONDecodeError, TypeError):
continue
items = data if isinstance(data, list) else [data]
for item in items:
if item.get("@type") == "JobPosting":
out.append(item)
return out
# Run on a schedule; diff against previous run; email new entries.
正式监控还要处理 JavaScript 渲染、请求失败、频率限制、重复记录和结构变化，工作量远大于这个例子。招聘页面监控指南比较了这种方式和其他选择。
对求职的实际意义
如果雇主发布了有效结构化数据，它会在源头页面上与职位一起出现，可能早于之后出现在别处的副本。但这不能证明另一个平台何时收到或展示了职位。它真正给你的理由，是回到雇主页面核对，而不是把聚合平台的时间戳当作原始时钟。
不要只依赖一个发现渠道。申请前查看雇主的规范页面；如果自建监控，再利用结构化数据。提醒方式对比列出了各自取舍。
如何把它用起来
JSON-LD JobPosting 是现代职位发现中的一个有用层。公司正确发布时，搜索引擎和监控工具都能读取相同的声明字段，但这些数据不会告诉你另一平台何时接收或展示了职位。
对候选人而言，技术细节没有源头本身重要：在雇主页面确认职位，并在合适的职位仍新鲜时申请。如果在候选人队列或候选名单形成前就发现它，你会得到真实的时机和可见度优势。若自己搭建监控，应先检查有效的 JSON-LD；缺失或不完整时，再谨慎使用备用方式。