ZipRecruiter Proxies for Job and Salary Data

ZipRecruiter publishes two kinds of public data that interest labor-market analysts: job postings, distributed to it by employers and job boards, and salary pages that summarize estimated pay for a title in a location. The second kind is less common on job sites and can be sampled with a very small number of requests, which makes ZipRecruiter a good fit for careful, low-volume research. This page explains how its pages are organized, how location is resolved, how to pace sessions, and how a dedicated WeProx US mobile line fits in.

Two datasets, two collection plans

Salary pages are organized by job title and location in the URL path, and each shows an estimated average, a range and comparisons to nearby cities. They change slowly, so a monthly or quarterly sample by title and metro captures the trend. Job postings change daily and are where volume lives. Treat these as separate jobs with separate schedules. Mixing them into one crawler usually means the slow data is refetched far too often, which costs the site capacity and costs you nothing useful.

Before building either job, check whether a public labor data source already answers the question. Government occupation and wage statistics are free and methodologically documented; ZipRecruiter's pages add timeliness and posting-level detail. Using both, with the public statistics as a baseline, makes your findings easier to defend and keeps your request volume on ZipRecruiter to the part only it can supply.

How location is resolved

ZipRecruiter search takes a keyword and a location and returns jobs within a radius. When no location is supplied, the site uses an approximate location from the visitor's IP, which is a common source of silent errors: a collector that loses its location parameter keeps running and quietly returns jobs near the proxy. Always send the location explicitly, and log the location the page echoes back. When your aim is to see what a local job seeker sees by default, place the WeProx line in that metro deliberately. Carrier IPs geolocate at roughly the metro or state level, which matches how the site uses them.

Salary pages have location in the URL and are not affected by your IP, which makes them easy to sample from any line.

Session pacing and structure

Walk each search slice as one sticky session: the results page, a couple more pages, a few postings, pauses that vary, then rotate the line and start the next slice with fresh cookies. Keep concurrency per line low. A WeProx line is a single US carrier device dedicated to you, and its address is shared through carrier-grade NAT with ordinary phone users, so the site cannot treat the IP as a bot range and has to judge your behavior. Behavior is what the pacing plan is for. Unlimited data lets you use a real browser engine for postings that render client-side without counting gigabytes.

Many ZipRecruiter postings link out to the employer's own application page. Record that the posting exists and where it leads, but do not follow every outbound link at crawler speed; those are other sites with their own terms.

• Salary pages: sample by title and metro monthly.
• Postings: daily per slice, deduplicated on the posting ID.
• Never submit applications or contact employers through automation.

Deduplication and meaning

The same role often appears several times because employers syndicate it through multiple channels, and multi-location employers post near-identical jobs in many cities. Deduplicate on the posting ID for counts of postings; group by employer, normalized title and city for counts of distinct openings. Keep both numbers, and say which one a chart shows.

When it breaks

Results from the wrong city mean a missing location parameter. A drop in postings on one line but not others points to that line being challenged; slow it and rotate less often. Failures right after rotation are the re-attach window. Salary pages that return a generic national figure usually mean the title and location combination has too little data, not a block.

One more check worth automating: compare the number of postings per slice with the previous day. Real markets move gradually, so a sudden halving on one slice almost always means a collection issue.

Setting up a ZipRecruiter proxy on WeProx

1. Split the work into a salary sample job and a posting job.
2. Order a WeProx line and copy host, port, credentials and rotation URL.
3. Send an explicit location on every search and log the echoed location.
4. Run one sticky session per search slice, rotating between slices.
5. Deduplicate postings and group them into distinct openings.
6. Sample salary pages monthly by title and metro.

ZipRecruiter proxy questions