如何核对来自 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 的搜索输入使用检索词和地点，而不是直接的职位 URL。如果你从一条已知的职位 URL 开始，请手动检查它，或将它与实际返回的某一搜索行对应起来。

应聘系统是雇主用来管理职位申请的第三方软件平台。租户是某一组织在应聘系统上托管的专用工作区或子域名。

该程序返回的原生输出字段包括 `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. 为每一对来源职位信息与候选申请 URL 建立一条路径记录。将原始申请 URL 与职位 URL 分开保存。保存初始主机、路径类型、核对时间和核对状态。
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 返回的 `applyUrl` 为 null；将其记录为 `missing`。路径缺失表示来源数据有缺口，需要手动检查职位信息，并不能证明该职位不存在。

在案例 J4 中，`applyUrl` 指向雇主网站，但目的地显示的是另一城市中的需求编号 GL-99，而不是预期的职位信息。因不一致，将其记录为 `unresolved_identity`。在案例 J5 中，申请链接返回页面不可用错误；将其记录为 `unavailable`。

这 5 条虚构记录得到 1 条已核对的应聘系统路径、1 条招聘平台路径，以及 3 处数据缺口。这个 1/5 的分布是教学用表，不是普遍可用性的基准。在某一特定时间核对过的目的地，并不能证明其无欺诈，也不是正在招聘的保证，或申请成功的证明。在提交实际申请之前，务必再做一次最终的来源复核。如果 J1 在下周变为不可用，请追加新的观察时间，不要覆盖原来的已核对记录。