The Duplicate Job Posting Trace, Seven Copies Matched to One Requisition

This is the trace I run when one role turns up on the employer's careers page, two job boards, an aggregator, and a couple of staffing agency listings. It is for job seekers who need to know which copy is real and live, and which one to apply through without being double-submitted. It gives you a seven-step procedure of about 20 minutes per role, carried through one worked example, and it ends with a logged record of the channel you chose.

What counts as the real copy of a job posting?

The real copy is the posting hosted in the employer's own applicant tracking system, because that is where the requisition ID lives and where every application ends up. Every other copy comes from it and is one of three types: a wrap, a scrape, or an agency mirror.

Two terms first. An applicant tracking system (ATS) is the software an employer uses to publish jobs and store applications. Workday and Greenhouse are the two whose URL formats this guide reads. A requisition ID is the employer's internal number for one approved opening, and it is the only field that can prove two copies are the same job.

The labels matter because each type fails in a different way. A wrap is usually safe to apply through. A scrape is safe only if its apply link still lands on a live source page. An agency mirror changes who can claim a fee if you are hired, which is why it gets its own section below.

The worked example: one role, seven copies

The case is a senior forward deployed engineer role at a software employer that runs a Workday-style careers site. It is a composite. The URL shapes and ID formats come from public Workday and Greenhouse documentation and published scraper notes, and the requisition number R172762 is the format example from those notes, not a live opening. Keep your own posting open in another tab and follow along.

The first sighting was a job board listing. Over the next twenty minutes the trace found seven copies:

1. The employer careers page, URL ending Sr-Forward-Deployed-Engineer_R172762, labelled "Posted 30+ Days Ago".
2. A LinkedIn listing created by job wrapping. Job wrapping means the board imports postings from the employer's ATS and sends the apply click back to it.
3. An Indeed listing with a link to apply on the company's site.
4. An aggregator copy with the same description text and no visible ID.
5. Agency A's ad: "our client, a leading software company", a reworded title, and a pay presentation that did not match the careers page.
6. Agency B's ad: the same distinctive sentence from the description, location narrowed to one city, no client name.
7. A second aggregator copy whose apply link returned a 404 (page not found).

That gives seven copies with different dates, different pay presentation, and two hidden employers. The question at the start is the one you have now: which of these is real, which is live, and which one should I click?

Where to find the job requisition ID on a careers page

The requisition ID is in two places on the source page: the URL, and the structured data in the page source. Workday puts it at the end of the URL slug, Greenhouse puts it in a gh_jid parameter, and both can expose it as identifier in the page's JSON-LD.

Workday formats vary by employer, so don't expect an R prefix every time. If a Workday link carries a suffix like ?source=BeameryInvite, that suffix is a channel tag, not part of the ID. Greenhouse's gh_src does the same job. It is a short string of numbers and letters that tells the employer which channel sent you.

Reading the page source

JSON-LD is a block of structured data that employers embed so search engines can read the posting. To find it, open the source page, view the page source, and search for JobPosting. Read these fields:

• identifier holds the employer's job ID. It proves the match.
• datePosted is the real posting date. It is more precise than any "30+ days" label.
• validThrough is the expiry. Google tells employers that to pull a posting they should make sure validThrough is populated and in the past, so a past date here is a strong sign the role is closed.
• directApply is the employer saying you can apply on that page. Treat it as a claim, not a guarantee.

Only title, description, datePosted and hiringOrganization are required. identifier and validThrough are only recommended, so a missing field proves nothing.

In the worked example, the careers page slug ended _R172762, the JSON-LD identifier matched it, datePosted was present, and validThrough was missing. That row, with the ID recorded, is the anchor I compared every other copy against.

The trace, step by step

The trace has seven steps: capture the sighting, find the source, extract the ID and dates, find every copy, classify them, handle the agency copies, and pick and log one channel. No single source publishes the whole sequence. I put it together from ATS documentation, Google's structured-data rules and published agency terms. Each step has a done state, so you know when to move on.

How each fork went in the worked example

Steps 1 and 2. The board listing gave me the title, city and a posted label. Its apply button did not go to the employer, so I followed the usual advice: look for a link to apply on the company's site. The Indeed copy had one, and it led to the Workday slug. If none of the copies had offered a link, the next move would have been the company's main website and its careers page.

Step 3. The slug gave ID R172762, and the JSON-LD confirmed it. The "Posted 30+ Days Ago" label only gives a minimum age, not the real one, so I logged datePosted instead.

Step 4. I ran two searches, in this order:

• "Sr Forward Deployed Engineer" "<one distinctive sentence from the description>" finds copies that kept the text, including agency rewrites that only changed the title.
• "R172762" finds copies that kept the ID.

The text search found the two aggregator copies and Agency B. The ID search mostly found copies that link back to the source. That gap is why you run both. Nobody has publicly established how reliably the ID survives into board and aggregator copies, so one search alone will miss some.

Step 5. The fork worth slowing down for was copy 7. It carried the same requisition ID, but the posting part of its URL differed from the live page and returned a 404. Workday keeps requisition IDs when a role is reposted, so copy 7 was a scrape of the earlier posting window, left up after that page closed. The role itself was still live under the same ID on the careers page. If I had read the 404 as "job closed", I would have dropped a live role.

Step 6. Agency A named the employer and the role when asked, and they matched R172762. Agency B never named a client.

Step 7. I applied once, on the careers page, and logged it. The section on channels below covers why, along with the wrong turn that came before it.

How to tell if a job listing is scraped or expired

A copy is live only if its apply link lands on a source page that is still open. How long scraped copies stay up after the source returns a 404 has not been established publicly, so check the source every time. What is known is how fast sources close and how often some copies refresh.

How fast sources close depends heavily on which ATS hosts them. A public cohort table from JobsPipe tracked how many ATS postings were still open after they were first seen:

Ashby's survival at 30 days is 2.6x Greenhouse's. In practice, a three-week-old copy of a Greenhouse role is much more likely to be dead than a copy of the same age from an Ashby employer.

Three refresh mechanisms explain why copies drift away from the source:

• Scheduled pulls. Talent.com pulls Greenhouse boards every four hours. A copy fed that way should follow the source closely. A copy from an unknown feed might not.
• Board post lifetimes. Free Indeed posts stay up for up to 30 days in the US and up to 120 days in some other markets. A board copy can expire while the requisition is still open, or outlive it.
• Combined statuses. Indeed's "job closed or expired" is a single status. It does not mean the role was filled.

When the source page is gone and you need to know what it said or when it went up, Google no longer offers its search cache. The free route is a Wayback Machine snapshot of the source URL, where you can read datePosted and the description as they were captured.

Staffing agency posted the same job as the company: ownership windows

When a staffing agency posts the same job as the company, the agency either has the client's permission to recruit for that role or is advertising speculatively, and the ad alone won't tell you which. The difference matters to you because a CV the agency submits can give it a claim to a fee if you are hired, and that claim runs for a set period.

A candidate-ownership window is the period, set in the agency's terms of business, during which the agency is owed a fee if the employer hires a candidate the agency introduced. RTR (right to represent) is your written consent for an agency to submit you. It should always name one employer and one role.

The table shows three patterns:

• Six months is the most common published figure. One glossary cites 30, 60 or 90 days from first submission. That claim is unverified, so don't plan around it.
• Scope varies a lot. Fieldfisher ties ownership to the specific role the agent had permission for. BountyJobs and Norland reach any job at the employer.
• First in time wins, with conditions. Between agencies, Fieldfisher's terms favour the submission made first. Against a direct application, Lithe's terms require the client to tell the agency in writing within 48 hours of the agency's submission. Only then are no fees payable.

The wrong turn: an agency resubmission meets a direct application

In the worked example, the mistake happened before the trace began. The candidate saw Agency A's ad first, replied with a CV, and wrote something like "happy for you to put me forward for suitable roles." The next day they found the careers page and applied directly. Agency A then submitted them to the same employer for the same role.

Here is what the ATS does with that. Greenhouse's duplicate tag matches on email address, phone number and LinkedIn profile URL. It flags duplicates but does not block them. Candidates bulk-imported with an agency source are never auto-merged, and auto-merge does not work backwards. The collision therefore lands in front of a person as a manual alert. If the employer misses the 48-hour notice, a fee dispute can follow, and you are now part of a disagreement that has nothing to do with whether you can do the job.

The fix was quick. The candidate emailed Agency A, withdrew consent for that employer, gave the time of the direct application, and forwarded the confirmation email. One public-sector clause actually requires suppliers to check whether candidates have already applied through the official jobs board. Most agencies won't ask, so tell them.

Hi [name],

Thanks for getting in touch about the [title] role. Before I share a CV or agree to representation, could you confirm in writing:

1. The client's name and the exact role title.
2. The client's requisition or job ID, if you have it.
3. That you have the client's permission to recruit for this specific role.

I have already applied directly to [employers from my log], so I do not consent to being submitted to them for any role. Any consent I give will cover one named employer and one named role only.

Thanks,
[name]

Finding the recruiter behind a mirror

To check an agency mirror, look up the recruiter who posted it, and use the job title that recruiters in that country actually carry. In Refolk's index of professional profiles, agency recruiter titles split sharply between the US and the UK.

The percentages come from samples of 25 profiles, so treat them as a direction, not a precise share. The US count for RCM Healthcare Services includes one profile spelled "RCM Health Care Services". Coast Personnel Services was next with 4. The practical point holds anyway: if you search "Recruiter" in the UK, you miss most of the people who post agency ads there.

How this goes wrong: failure modes and false positives

Most trace errors come from trusting one field too much: an ID taken to prove the job is open, a label taken as a date, or a status taken as an outcome. Each failure below lists what it looks like and the check that catches it.

The ID tells you it is the same job. It does not tell you the job is still open.

1. Same req ID read as the same posting window. Workday IDs survive reposts, so a fresh date on a copy can mean a repost, not a scrape. Check: compare the posting suffix in the URL, the part shaped like _3164651-2, against the live page.
2. No req ID read as a different job. Some Workday tenants leave out the requisition ID on postings mirrored across several career sites. Check: match on a distinctive description sentence and the location instead.
3. A board application that loses its source token. Greenhouse says some advanced board integrations can remove the source parameter, so the application gets filed under the wrong channel. Check: look for gh_src= in the final application URL before you submit.
4. "Closed or expired" read as filled. Indeed's combined status does not mean someone was hired. Check: the employer's careers page, then a search on the req ID for a repost.
5. A copy dated by its listing label. "Posted 30+ Days Ago" is only a minimum, and a missing validThrough hides the real age. Check: datePosted in the page source or a Wayback Machine snapshot.
6. Agency collision. You apply directly, an agency submits later, and the employer misses the 48-hour notice. Check: refuse RTR for any employer in your log, and keep the timestamp.
7. Multi-location postings read as separate jobs. Workday's job list can show "5 Locations" without naming them. Check: open the job detail page before counting copies.
8. Country-blind agency search. Searching "Recruiter" in the UK misses about 72% of the sample, who are titled Recruitment Consultant ([OURS] sample of 25).

What the evidence does not settle

Two questions come up all the time and have no solid answer. First, nobody has published a validated list of signs that an agency ad is fishing for CVs rather than filling a real role. Ask a Manager describes agencies that post boilerplate ads for jobs that don't exist, but that is practitioner testimony. Second, the widely shared ghost-job figure comes from a Resume Builder survey of 650 hiring managers, in which 40% of companies said they had posted a fake listing that year. CV-writing services produced those figures, and one critique notes the source would benefit from candidates being more anxious. My local test is simpler: an agency mirror that won't name the client after one written request stays unverified, and it gets no CV.

Apply on the company website or the job board?

Apply once, through the employer's source page or a wrap that lands on it. Consider an agency route only when the agency has named the client and role in writing, you have not applied already, and you are willing to give consent for that one role.

Here the sources genuinely disagree. Jobscoutly calls applying on both channels reasonable. LoopCV warns that duplicates can create confusing duplicate records. I side with LoopCV, because the ATS documentation supports it. Greenhouse flags duplicates rather than blocking them, and auto-merge does not reach back to existing records. A second application doesn't raise your chances. It leaves two records of you for one requisition, filed under two sources.

Source tracking is weaker than most applicants assume:

• Integrated boards send applications into the same job record with a source label attached. Greenhouse, for example, receives Talent.com applicants that way.
• The source token can be lost. Greenhouse says advanced integrations may strip it.
• LinkedIn job wrapping is not tracked by Greenhouse unless the employer enables source tracking.
• Batching and separate inboxes. No vendor documentation covers boards that collect applications and send them in batches, or very small firms that set up separate email addresses per source. Practitioner write-ups describe both.

Because the ATS's record of your channel can be wrong, your own log is the record that counts. Whichever channel you pick, tailor against the source page's description, not an agency's rewrite or a scraped copy that may be an older version. Refolk tailors your resume and cover letter to the posting you give it and scores how well you fit, so give it the source text you just verified.

Role:
Employer:
Req ID:
Source URL:
datePosted / validThrough:
Copies found (URL | class | ID match | date shown | pay shown):
1.
2.
3.
Agency contacts (agency | recruiter | client named in writing? | consent given?):
Channel chosen:
Applied at (date, time, timezone):
Final application URL, including source tag:
Confirmation email subject and time received:

Keeping the trace log current

A trace log stays useful for as long as an ownership window could still reach you, which under published terms can be 12 months. Board saved-job lists don't last that long: Indeed removes saved jobs older than six months, so the log you keep yourself is the only lasting record.

Re-check in three situations:

• Before any follow-up message. Reopen the source URL and read validThrough in the page source.
• When a "new" copy appears. Search its req ID against the log. For a reposted replacement, compare the requisition number, responsibilities and location before treating it as the same job. If the responsibilities changed, run your fit score again in Refolk against the new text before deciding whether to reapply.
• When an agency calls about an employer already in the log. Read them the date from the log and decline consent.