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；資料缺失或不完整時，再小心使用備用方式。