Snagajob Scraper for Hourly Job and Pay Data

What a Snagajob scraper can extract per posting

Posting pages carry JobPosting structured data, and the pay range sits inside it. On a posting from a February 2025 archived capture, the baseSalary block was a MonetaryAmount whose QuantitativeValue held minValue, maxValue and unitText set to HOUR. That matters: the rate is machine readable and already per hour, so there is no annual figure to divide down.

A standard delivery includes:

• Identity - numeric posting id, the canonical URL built as snagajob.com/jobs/ plus that id, and the page title.
• Employer - company name, a normalized brand name, and the location name exactly as entered, which is frequently the individual operator rather than the corporate brand.
• Location - street address where present, city, state, state code, postal code, latitude, longitude and the internal location id.
• Pay - the employer-stated hourly minimum, median and maximum, kept separate from the site's own estimated wage band with tenth, twenty-fifth, seventy-fifth and ninetieth percentile values.
• Employment type - part time, full time, seasonal part time or gig, taken from both the posting category list and the schema employmentType array.
• Dates - created date, last update date and validThrough, all ISO 8601.
• Apply route - the directApply flag from the schema plus the internal one-click and easy-apply flags and the outbound application URL, which together tell you whether the application completes on Snagajob or leaves for the employer.
• Classification - industry, an O*NET-SOC occupation code and skill tags.
• Age gate - a minimum age value and tags such as 16plus and 17plus that hourly employers rely on.
• Description - the full HTML body, including benefits text where supplied.

We do not collect job seeker profiles. Those sit behind a login and are personal data. Output is limited to posting and employer data, and any personal contact detail an employer typed into a description can be excluded on request.

What Snagajob scraping has to handle

Keyword search runs at snagajob.com/search/q- followed by the term with plus signs for spaces. Browse pages sit under snagajob.com/find-jobs/ with short facet prefixes: w- for a city and state, i- for an industry, x- for an employment type, plus t- and c- segments that combine with commas. Paging is driven by an opaque continuation token rather than a page number, and the search response reports both the current page size and a separate full match count. Deep paging is a sequence you walk, not a page number you can jump to, and crawl planning has to respect that.

The robots.txt file disallows /api/, the apply and registration paths, member and profile paths, and every paginated or query-string search form, including /search?q= and the combined find-jobs facet patterns. We read it and follow it, so coverage is assembled from posting pages and permitted entry points rather than from disallowed search URLs.

Postings expire but stay addressable. The record keeps an expiry flag alongside a validThrough date, so a closed listing can still be fetched and dated. That is exactly what makes a historical series possible, and we keep the flag in the output instead of quietly dropping the row.

The site sits behind Cloudflare. A plain HTTP request to snagajob.com returns a managed challenge page instead of content. We render pages properly and run at a measured rate. We do not defeat challenges, solve CAPTCHAs or disguise our traffic, and we will say where that limits coverage rather than promise around it.