How to Check an Employer Application Link From Indeed

Setup and Data Collection

To start, configure the data scraper for a targeted manual check. The default preset for the Indeed Apply Link Audit Task contains broad default terms:

{
  "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"
}

Replace the sample roles in `searchTerm` with your single intended role, set your exact `country` and `location`, and limit the scope by setting `maxItems` to 2 and `maxPagesPerSearch` to 1. Ensure `saveOnlyUniqueItems` is set to `true` and change `followApplyRedirects` to `false`. An Actor search input uses search terms and locations rather than direct listing URLs. If you start with a known listing URL, inspect it manually or reconcile it to an actual returned search row.

An applicant system is a third-party software platform used by employers to manage job applications. A tenant is a specific organization's dedicated workspace or sub-domain hosted on an applicant system.

The program returns native output fields including `jobId`, `title`, `companyName`, `locationRaw`, `jobUrl`, `applyUrl`, `finalApplyUrl`, `applyUrlRedirected`, `applyUrlResolveStatus`, `descriptionText`, `descriptionStatus`, and `scrapedAt`. Unaccepted automated redirect fields like `finalApplyUrl` and `applyUrlResolveStatus` remain optional or unknown when `followApplyRedirects` is set to `false`.

When the collection run finishes, inspect the `OUTPUT` metadata fields: `requestedMaxItems`, `candidateItemsSeen`, `jobsSaved`, `pagesParsed`, `blockedPages`, `failedRequests`, and `stopReason`. In a control run capped at two items, the scraper saved two rows containing full job descriptions. One returned a Workday employer route and the other returned an Indeed-hosted route. Checking a dated public role, requisition ID, and location against the employer's official careers page confirmed the Workday tenant link. This demonstrates route verification for a specific listing, but it does not prove complete source coverage, automatic resolution, or universal employer routing policy.

Steps to Check Your Application Link

1. Choose a known listing or a small search. Save the source job ID, title, company, location, and collection time. Do not assume Indeed routing rules have changed based on old examples.
2. Run a small Task input with maxItems set to two, maxPagesPerSearch set to one, saveOnlyUniqueItems set to true, and followApplyRedirects set to false. Inspect the run output. A successful run with no useful rows needs a manual source check.
3. Build one route record per source listing and candidate application URL. Keep raw application URLs and job URLs separate. Save the initial host, route type, checked time, and check state.
4. Open the returned public route. Record the final destination and check whether it displays the same role, employer, requisition, and location. Do not submit an application during this check.
5. Independently open the employer's official public careers page. Follow its public search or applicant-system link. Check whether it reaches the same organization tenant and role.
6. Use explicit states for your records. Choose checked employer route, checked applicant system route, board route, missing, unavailable, or unresolved identity. A checked route means the public destination matched at the recorded time.
7. Add the route record to your job tracking sheet. Recheck the public destination immediately before your actual application. One old observation cannot prove current status.
8. Choose the checked employer or applicant-system route if it fits the intended listing. Otherwise use the source board route or mark the destination unresolved.

Worked Route Audit Examples

Note: The following five cases and table rows are explicit fiction designed for teaching purposes.

In case J1, an Indeed listing for a Software Analyst at Green Labs in Austin lists requisition GL-42. The `jobUrl` is `https://jobs-board.example/view/J1` and `applyUrl` is `https://ats.example/green/jobs/GL-42`. Manual inspection confirms that the public destination displays Green Labs, Software Analyst, Austin, and GL-42. Opening the official Green Labs careers page shows a direct link to that exact tenant and role. Record this as `checked_applicant_system_route`.

In case J2, `applyUrl` points to `https://jobs-board.example/apply/J2` and stays on the source board. Record this as `board_route`. Case J3 returns a null `applyUrl`; record this as `missing`. A missing route indicates a source data gap requiring a manual listing check, not proof that no job exists.

In case J4, `applyUrl` leads to the employer's site, but the destination displays requisition GL-99 in a different city rather than the expected listing. Record this as `unresolved_identity` due to the mismatch. In case J5, the application link returns a page unavailable error; record this as `unavailable`.

These five fictional records yield one checked applicant-system route, one board route, and three data gaps. This 1/5 breakdown is a teaching table, not a general availability benchmark. A checked destination at a specific time is not a fraud certificate, an active hiring guarantee, or proof of application success. Always run a final source recheck before submitting an actual application. If J1 becomes unavailable next week, append the new observation time without overwriting the original checked record.