JSON-LD JobPosting：如何在聚合网站索引之前找到职位

你曾经看过的几乎每个职位发布，在可见的HTML旁边都有一个隐藏版本——一个干净的、机器可读的职位描述，带有标题、地点、发布日期、薪资范围和雇主等结构化字段。它叫做JSON-LD JobPosting，它作为一个script标签嵌入在页面中，这就是为什么Google Jobs能给你显示一个带有薪资范围和"5小时前"时间戳的卡片，而LinkedIn仍然告诉你该职位是"2天前"发布的。

理解这种格式有两个实用价值。它告诉你为什么某些渠道在结构上比其他渠道更快（Google Jobs直接使用JSON-LD；LinkedIn不使用）。它给你一条干净的路线来监控企业招聘页面，而无需尝试解析不是为被解析而构建的HTML。

它到底是什么

JSON-LD（"用于关联数据的JSON"）是一种在网页中嵌入机器可读数据的方法。JobPosting模式定义在schema.org/JobPosting，是Google用来从网络中获取结构化信息的数十种类型之一。

为什么每家企业都输出它：Google要求的。如果一个职位没有有效的JobPosting JSON-LD块，它就不会出现在Google Jobs中——而Google Jobs越来越成为候选人开始搜索的地方。因此每个现代ATS（Workday、Greenhouse、Lever、Ashby、Phenom、iCIMS）都在其公开发布页面上输出这种结构化数据，无论雇主是否要求。

它长什么样

如果你查看一个典型的Greenhouse托管职位发布的源代码并搜索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天前发布的"，它们显示的是它们首次摄入的日期，而不是企业实际发布它的日期。企业自己页面上的JSON-LD给你真正的数字。我们对ATS到LinkedIn延迟的测量就是基于这种比较构建的。

2. 它解释了为什么Google Jobs比LinkedIn更快

Google Jobs直接通过JSON-LD获取数据。一旦Googlebot爬取了招聘页面（对大多数企业网站来说在数小时内发生），该职位就出现在Google Jobs搜索结果中。LinkedIn和Indeed必须进行自己的爬取、解析、去重和分类，这就是它们1到5天延迟的来源。聚合网站延迟的成本分析详细介绍了这一点。

3. 它给你一条干净的路线来自己监控企业

如果你在构建任何类型的监控，JSON-LD比解析原始HTML好得多。数据已经是结构化的。你不需要在企业重新设计招聘页面时会失效的CSS选择器。你只需要查找<script type="application/ld+json">块并将其解析为JSON。

如何自己检查

在任何浏览器中：

打开一个职位发布页面（试试一个Greenhouse或Lever的URL）。
右键点击选择"查看页面源代码"（或按Ctrl+U / Cmd+U）。
搜索application/ld+json。
你会找到一个或多个JSON块。带有"@type": "JobPosting"的就是职位数据。

你可以用Google的富媒体搜索结果测试工具来验证它，该工具既能确认JSON-LD格式正确，也能告诉你Google Jobs是否会索引它。

哪些ATS可靠地输出JSON-LD

Greenhouse：是的，在每个公开职位发布页面上。实现最干净。
Lever：是的，有一些小的模式问题。
Ashby：是的，结构良好。
Workday：部分。许多Workday托管的招聘网站输出它；一些不会，取决于雇主的配置。
Phenom：是的，通常比一般系统有更丰富的元数据。
iCIMS：是的，不过有时JSON-LD是异步加载的，在没有浏览器引擎的原始HTML获取中不会出现。
SmartRecruiters：是的。
SAP SuccessFactors：参差不齐，很大程度上取决于租户配置。
自定义内部系统：差异很大。大型企业（Google、Meta、Amazon、Apple）有格式良好的JSON-LD；较小的企业通常没有。

我们完整的ATS参考涵盖了如何识别企业使用的是哪个系统。

一个最简"做你自己的爬虫"教程

对于技术读者，这里是一个监控单个招聘页面上新JSON-LD JobPosting条目的Python脚本的大致框架：

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渲染的页面、处理速率限制、跨运行去重、将薪资解析为可查询的格式）是简单直接的但需要更多工作。我们关于监控招聘页面的完整指南将此方法与其他替代方案进行了比较。

这对你的求职意味着什么

如果你主要在聚合网站上搜索，你本质上是在企业已经发布的结构化数据的下游。为Google Jobs在职位上线当天提供数据的同一JSON-LD就在企业页面上等着被读取，而聚合网站的经过删减、分类、延迟一天的副本才是你在看的东西。

实际含义：如果你没有使用直接ATS监控，在当天投递很重要的职位上，Google Jobs在结构上比LinkedIn搜索更快。我们对三种方法的比较详细介绍了实际的权衡。

总结

JSON-LD JobPosting是隐藏在大多数现代求职搜索基础设施之下的安静基元。为Google Jobs在职位上线那一刻提供数据的同一数据就在企业页面上等着被读取。聚合网站在其之上增加了自己的摄入、解析、去重和分类层——这就是为什么它们比权威来源晚一两天。

对于大多数候选人来说，实际含义比技术故事更简单：如果你在求职渠道之间选择，Google Jobs在结构上比LinkedIn更新鲜，因为它直接读取JSON-LD。如果你自己在构建任何类型的监控，JSON-LD是你应该读取的东西——而不是渲染的HTML，更不是聚合网站的索引副本。

← 返回博客 · 免费开始 →