Field note
When LinkedIn Job Wrapping quietly stops updating
This one is unusual because nothing reports an error. Jobs keep appearing on LinkedIn, the integration shows as healthy, and yet the listings drift further from what is actually open. Recruiters notice weeks later, normally because a closed role is still collecting applicants.
The cause is almost always the same: Job Wrapping works by scraping your careers site, and your careers site changed.
Why it fails silently
A scraper looks for specific elements in your page structure. When a careers site is redesigned — or a content management system is upgraded, or a template is tweaked by someone in marketing who had no idea anything depended on it — the selectors that used to find a job title, location or requisition ID stop matching.
A scraper that finds nothing does not usually crash. It returns an empty or partial result, and an empty result is indistinguishable from 'this employer has no open roles right now'. The pipeline treats that as valid and carries on.
This is why the failure presents as drift rather than an outage, and why it survives so long before anyone raises it.
Confirming it in about ten minutes
- Pick three roles you know are currently open and check whether all three appear on LinkedIn. Partial presence points at selector breakage rather than a feed-wide failure.
- Check the reverse: are roles that closed weeks ago still live? Stale-but-present is the signature of a feed that stopped being refreshed rather than one that broke outright.
- Find out when your careers site last changed. Compare that date against when the discrepancies started. In my experience these correlate more often than not.
- View the page source of a job listing — the raw source, not the rendered DOM. If the job detail is injected by JavaScript after load, a scraper may never see it at all.
- Check whether anything changed about how job pages are addressed. New URL patterns can leave a scraper crawling a structure that no longer exists.
The JavaScript-rendering trap
A specific case worth calling out: migrating a careers site to a modern JavaScript framework. The page looks identical to a human, every job is right there on screen, and nothing appears to have broken.
But if the job content is rendered client-side and the scraper reads the initial HTML response, that response now contains an empty container. The site is fine. The feed sees nothing.
This is the same class of problem that makes single-page applications hard to index in search, and it catches people out for the same reason — what you see in a browser is not what an automated fetch receives.
What fixing it actually involves
On the platform side, the repair is updating the scraper's selectors to match the new markup and verifying the revised script against the live site before it ships. When I did this at LinkedIn it meant editing the Python scraper, running the revised version locally in Docker against real careers pages, confirming the extracted fields were correct, and handing the verified fix to the development team through JIRA for review and deployment.
On your side, the useful work is preventative and costs almost nothing: tell whoever owns the careers site that a third-party integration reads its markup, and add a check to your release process. A one-line note in a deployment checklist prevents a month of silently wrong job listings.
If it is not the careers site
When the markup has genuinely not changed, the next places to look are authentication and permissions on the integration itself, and whether the feed is being processed but rejected downstream. Both present differently — an auth problem tends to fail completely rather than partially, and a rejection usually leaves a trace somewhere.
At that point a HAR capture of the failing flow is worth more than any amount of describing the symptom.
Feed drifting and nobody can say why?
I ran product health across the Jobs API, Automated Job Postings and Job Wrapping at LinkedIn for three years. If you have a discrepancy you cannot explain, that is a conversation worth having.
Get in touch →