JSON-LD JobPosting：如何在聚合網站索引之前找到職缺

你看過的幾乎每一個職缺發布頁面，都有一個隱藏版本伴隨著可見的 HTML——一個乾淨的、機器可讀的職缺描述，包含標題、地點、發布日期、薪資範圍和雇主的結構化欄位。它叫做 JSON-LD JobPosting，嵌入在頁面的 script 標籤中，這就是為什麼 Google Jobs 能顯示帶有薪資範圍和「5 小時前」時間戳記的卡片，而 LinkedIn 還在告訴你該職缺是「2 天前」發布的。

了解這種格式有兩個實用的作用。它告訴你為什麼某些管道在結構上比其他管道快（Google Jobs 直接使用 JSON-LD；LinkedIn 不是）。它也給你一條乾淨的路線來監控公司的職涯頁面，而不用嘗試解析那些不是為了被解析而設計的 HTML。

它實際上是什麼

JSON-LD（「JSON for Linked Data」，連結資料的 JSON）是一種在網頁中嵌入機器可讀資料的方式。在 schema.org/JobPosting 定義的 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 的 Rich Results Test 工具驗證它，這既確認 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 渲染的頁面、處理速率限制、跨運行去重、將薪資解析為可查詢的格式）很直接但更複雜。我們的職涯頁面監控完整指南將這種方法與替代方案進行了比較。

這對你的求職意味著什麼

如果你主要在聚合網站上搜尋，你本質上是公司已經發布的結構化資料的下游。同樣的 JSON-LD 在職缺上線的那天就已經傳送給 Google Jobs 了，而聚合網站的經過編輯、分類、遲到一天的副本才是你在看的。

實際的含義是：因為管線的運作方式，Google Jobs 在結構上比 LinkedIn 或 Indeed 更快。對於需要當天投遞的職缺，如果你沒有使用直接 ATS 監控，請優先選擇 Google Jobs 而非 LinkedIn 搜尋。我們對三種方法的比較介紹了實際的權衡。

重點總結

JSON-LD JobPosting 是現代求職基礎設施底下安靜的基本元素。同樣的資料在職缺上線的那一刻就傳送給了 Google Jobs，它就坐在公司的頁面上等待被讀取。聚合網站在此之上加了自己的接收、解析、去重和分類層——這就是為什麼它們比權威來源慢一兩天。

對大多數候選人來說，實際的含義比技術故事更簡單：如果你在求職管道之間做選擇，Google Jobs 在結構上比 LinkedIn 更新鮮，因為它直接讀取 JSON-LD。如果你自己在建造任何類型的監控，JSON-LD 才是要讀的東西——不是渲染後的 HTML，絕對不是聚合網站的索引副本。

← 返回部落格 · 免費開始 →