CareerBuilder Scraper for Public Job Posting Data

What a CareerBuilder Job Posting Exposes

CareerBuilder renders result and job-details pages from a structured payload, so these fields are read, not guessed from formatted text.

• Job title as the employer wrote it, plus the normalized title the site uses for its landing pages.
• Employer name, with a caveat: some postings render as Company Confidential and carry no employer. We flag them.
• Location as city and state, with the coordinates the page publishes.
• Dates. The payload carries a posted date, a created date, a modified date and a recency bucket, and they do not agree. We deliver all of them, because freshness analysis breaks if you pick the wrong one.
• Salary, paired with a flag saying whether the employer stated the figure or the platform generated it.
• Employment type, often returned as OTHER rather than a usable value, so we pass the raw value through.
• Full description, markup stripped and list structure kept for text processing.
• Apply route as a type, for example offsite, not a destination link. The payload often carries an empty apply URL, so the route type is the dependable field.
• Posting identifier. Each vacancy has a UUID, and the URL is a title, city and state slug, a double hyphen, then that UUID. The UUID is the stable key; the slug changes if the title is edited.
• Source system, the applicant tracking system or feed a posting arrived through.

Excluded by default, not on request. Output is limited to posting and employer data. We do not extract named recruiter emails, phone numbers or personal messaging links, and we do not build person-level records about recruiters or candidates. An earlier version of this page offered recruiter contact fields; that was wrong and is withdrawn. Under the GDPR a named person's work email and direct phone number are personal data. Resumes and candidate profiles sit behind a recruiter login. We do not collect them and we do not access anything behind a login.

What CareerBuilder Scraping Has To Resolve

CareerBuilder shows two kinds of pay figure and labels them differently. Some are stated by the employer. Others are generated by the platform under a Monster Estimated Salary heading, with a note saying the range is an estimate based on averages for the role and location and was not supplied by the employer. Merge them into one column and you are averaging model output with real employer numbers, and every wage benchmark built on it is wrong. We keep the provenance flag as a first-class field. Many postings carry a currency with no amount, so an empty salary is a real absence, not a parsing failure.

Other fields are derived by the platform rather than entered by the employer, and we label them derived:

• Remote and onsite status arrives as a policy decision with a written explanation, not an employer checkbox.
• Skill tags are machine-extracted from the description and tied to opaque internal codes.
• Descriptions carry a platform-generated summary alongside the employer's original text.
• Each posting carries an occupational classification code from the platform's own taxonomy.
• Paid placement is exposed as a promotion flag and an ad pricing type, so organic and sponsored rows separate.

None of these derived fields describe a person. The exclusion above holds across the pipeline: no recruiter contact details, no candidate data, nothing from behind a login. If a field would identify an individual rather than a vacancy or an employer, it does not enter the dataset.