如何核對來自 Indeed 的僱主申請連結

設定與資料收集

開始時，請為針對性的人手核對設定資料抓取程式。Indeed Apply Link Audit Task 的預設輸入預設包含寬泛的預設詞項：

{
  "balanceKeywordCoverage": true,
  "country": "us",
  "followApplyRedirects": true,
  "jobType": "any",
  "maxItems": 100,
  "maxPagesPerSearch": 5, "postedWithinDays": "7",
  "remoteOnly": false,
  "requestDelayMillis": 2500,
  "saveOnlyUniqueItems": true,
  "scrapeCompanyDetails": false,
  "searchTerm": "software engineer\ndata analyst\nproduct manager",
  "sortBy": "date"
}

把 `searchTerm` 中的範例職位換成你單一的目標職位，設定確切的 `country` 和 `location`，並把 `maxItems` 設為 2、`maxPagesPerSearch` 設為 1，以限制範圍。確保 `saveOnlyUniqueItems` 設為 `true`，並把 `followApplyRedirects` 改為 `false`。Actor 搜尋輸入使用搜尋詞和地點，而不是直接的職位列表網址。如果你從已知的職位列表網址開始，請人手檢查，或把它對應到實際返回的搜尋列。

申請人系統是僱主用來管理職位申請的第三方軟件平台。租戶是申請人系統上託管的、屬於某一機構的專用工作區或子網域。

程式返回原生輸出欄位，包括 `jobId`、`title`、`companyName`、`locationRaw`、`jobUrl`、`applyUrl`、`finalApplyUrl`、`applyUrlRedirected`、`applyUrlResolveStatus`、`descriptionText`、`descriptionStatus` 和 `scrapedAt`。當 `followApplyRedirects` 設為 `false` 時，未經接納的自動重新導向欄位（例如 `finalApplyUrl` 和 `applyUrlResolveStatus`）仍為可選或未知。

收集運行完成後，檢查 `OUTPUT` 元資料欄位：`requestedMaxItems`、`candidateItemsSeen`、`jobsSaved`、`pagesParsed`、`blockedPages`、`failedRequests` 和 `stopReason`。在上限為 2 項的對照運行中，抓取程式儲存了 2 列包含完整職位描述的資料。一列返回 Workday 僱主路徑，另一列返回由 Indeed 託管的路徑。把一個有日期的公開職位、職位空缺編號和地點，與僱主官方招聘頁核對後，確認了該 Workday 租戶連結。這展示對某一職位列表的路徑核實，但並不證明來源覆蓋完整、能自動解析，或僱主路徑政策普遍適用。

核對申請連結的步驟

1. 選擇一個已知職位列表或一個小範圍搜尋。儲存來源職位 ID、職稱、公司、地點和收集時間。不要根據舊例子假定 Indeed 的路徑規則已經改變。
2. 運行一個小的 Task 輸入：maxItems 設為 2，maxPagesPerSearch 設為 1，saveOnlyUniqueItems 設為 true，followApplyRedirects 設為 false。檢查運行輸出。成功運行但沒有有用資料列時，需要人手檢查來源。
3. 為每個來源職位列表和候選申請網址建立一筆路徑紀錄。把原始申請網址和職位網址分開保存。儲存最初主機、路徑類型、核對時間和核對狀態。
4. 開啟返回的公開路徑。記錄最終目的地，並檢查它是否顯示同一職位、僱主、職位空缺編號和地點。此次核對期間不要提交申請。
5. 另行開啟僱主的官方公開招聘頁。跟隨其公開搜尋或申請人系統連結。檢查它是否到達同一機構租戶和職位。
6. 為紀錄使用明確狀態。選擇已核對的僱主路徑、已核對的申請人系統路徑、招聘網站路徑、缺失、無法使用，或身份未解。已核對的路徑是指公開目的地在所記錄的時間相符。
7. 把路徑紀錄加入你的職位追蹤表。在實際申請之前，立即重新核對公開目的地。一次舊觀察不能證明目前狀態。
8. 如果已核對的僱主路徑或申請人系統路徑符合目標職位列表，就選擇該路徑。否則使用來源招聘網站路徑，或把目的地標為未解。

路徑審計的實例演練

注意：以下 5 個案例和表格列是為教學而設的明確虛構內容。

在案例 J1 中，Indeed 有一則 Green Labs 在 Austin 的 Software Analyst 職位列表，職位空缺編號為 GL-42。`jobUrl` 是 `https://jobs-board.example/view/J1` ，`applyUrl` 是 `https://ats.example/green/jobs/GL-42`. 人手檢查確認公開目的地顯示 Green Labs、Software Analyst、Austin 和 GL-42。開啟 Green Labs 官方招聘頁，可見直接連到該確切租戶和職位的連結。把此項記為 `checked_applicant_system_route`。

在案例 J2 中，`applyUrl` 指向 `https://jobs-board.example/apply/J2` ，並停留在來源招聘網站。把此項記為 `board_route`。案例 J3 返回 null 的 `applyUrl`；把此項記為 `missing`。缺失路徑表示來源資料有空缺，需要人手檢查職位列表，而不是證明沒有該職位。

在案例 J4 中，`applyUrl` 導向僱主網站，但目的地顯示的是另一城市的職位空缺編號 GL-99，而不是預期的職位列表。因不相符，把此項記為 `unresolved_identity`。在案例 J5 中，申請連結返回頁面無法使用的錯誤；把此項記為 `unavailable`。

這 5 筆虛構紀錄得出 1 條已核對的申請人系統路徑、1 條招聘網站路徑，以及 3 項資料空缺。這個 1/5 分項是教學表格，不是一般可用性基準。某一特定時間的已核對目的地，不是該路徑沒有欺詐的證明，也不是正在招聘的保證，更不是申請成功的證明。提交實際申請前，務必做最後一次來源再核對。如果 J1 在下星期變為無法使用，請附加新的觀察時間，不要覆寫原來的已核對紀錄。