Indeed is the largest job board in the world, and its search page is where most vacancies surface first. This service turns a search into a table - one row per listing, carrying the title, the employer, the location, the advertised pay, the contract type, how long it has been up, a snippet of the description and Indeed's own job key.
Almost everything that shapes a run is decided before you get here, in the filters you set on Indeed itself.
An Indeed search URL carries its own filters as parameters: q for the keywords, l for the location - a postcode or a "city, state" pair - radius for how far around it to look, jt for the contract type, fromage for how recently a job was posted, and sort for relevance or date order. Set those on Indeed, copy the URL, and the run inherits every one of them.
That matters more than it sounds, because it is how you keep a run small and pointed. A national search for a common title returns an enormous, mostly irrelevant set; the same search with a radius, a contract type and a recency filter returns the jobs you would actually read. The filtering is free - you only pay for rows.
One thing to know about what comes back: Indeed's results interleave sponsored placements with organic ones. Sponsored listings are ads an employer paid to surface, and they appear because of that spend rather than because they best match your query. The export gives you the listings as the results page presents them, so if that distinction matters to your analysis, treat the ordering with care.
The work happens on Indeed. Here you just hand over the URL.
The filters live in the URL, so the export matches exactly what you were looking at on Indeed.
These are the columns this scraper's export declares, in order. Each description explains what the column is for and what Indeed shows in that position on a results page.
Remote or a hybrid note instead of a place.jk value that appears in a listing URL like indeed.com/viewjob?jk=…. It is the natural key for matching a listing across runs.Two of these are worth planning around. job_key is Indeed's own listing identifier, which makes it the right column to deduplicate on when you re-run a search rather than matching on title and company. And posted is a relative age rather than a date - it describes the listing at the moment of the run, so record your run date if you need real timestamps later.
None of these are quirks of the scraper. They are properties of how Indeed presents jobs, and they shape what you can do with the export.
Every Indeed posting has a jk value, the string you see in a viewjob?jk=… link, and the export carries it as job_key. Match on that rather than on title plus company: the same role is frequently advertised more than once, sometimes by an agency and the employer both, and a text match will merge or split those wrongly. The id will not.
Indeed shows pay two ways: a range the employer entered, or a range Indeed models when the employer gave none. The card labels which it is, and that label travels in the salary string. Keep it. A benchmark built on employer-stated pay is a different - and far more defensible - number than one blended with estimates, and once you have discarded the label you cannot separate them again.
Indeed writes posting age relatively on the results card - freshly listed, a number of days, or an open-ended bucket once a posting is old. That is what lands in posted. It cannot be parsed as a date and it is not comparable between two runs made a week apart. If you need real dates, store the date you ran the job and derive them from it.
Indeed mixes paid placements into the result set. They rank there because an employer bid for the position, not because they are the closest match, so ordering on Indeed is not a pure relevance signal the way an organic search result is. For counting who is hiring it makes no difference; for anything that reads rank as importance, it does.
Where a filtered Indeed search is more useful as a spreadsheet than as a web page.
Before you write a job ad, read the market. One filtered search returns every competing vacancy for that title in your radius, with the advertised pay next to each. It is the fastest honest answer to whether your salary band is competitive, and it takes minutes rather than an afternoon of tabs.
Hiring is one of the least ambiguous things a company broadcasts. Fix a search, re-run it on a schedule and deduplicate on job_key, and what you accumulate is a record of who is growing, in which function and where - visible well before it reaches a press release.
Indeed's interface is built for browsing one listing at a time. Exported, a search becomes something you can sort by pay, filter by contract type and work through methodically - and re-running it later shows only what is new, which is the difference between a job hunt and an endless scroll.
No subscription, no minimum, no per-seat licence. Your first 500 rows are on us - after that, pay-as-you-go.
Every new account, one-time. No credit card required. All scrapers unlocked. A tightly filtered search is usually well under 500 results, so a real first run often costs nothing at all.
Roughly $2 per 1,000 listings. Because the filters live in the search URL, the cheapest way to run this is to narrow the search on Indeed first - radius, contract type and recency will often cut a result set by an order of magnitude before you pay for a single row.
Volume pricing, SLAs, dedicated workers and bespoke onboarding for teams tracking hiring across many searches, titles and regions. Tell us your numbers and we'll quote.
LIVESCRAPER10 at checkout.The same role is often advertised in several places, and rarely worded the same way twice. These two cover the ground Indeed does not.
Google's jobs panel aggregates across boards and names the source of each posting - useful for seeing what Indeed alone would miss.
The same shape of export from Glassdoor, where listings sit alongside employee reviews of the companies posting them.
Short answer: yes. A job advert is published to be found by as many people as possible.
Indeed's search results are public. Anyone can browse them without an account, and collecting publicly visible listings for research is long-established practice. As long as the data is publicly available and the process doesn't disrupt the site there are no federal laws prohibiting it.
Job adverts also sit at the comfortable end of the range. The subject of a listing is a role at a company, not a named individual - nothing in these eleven columns describes a person. There is no login, no paywall, and nothing is applied to on your behalf.
Indeed's terms restrict automated access, so this remains a terms question. We touch nothing behind a login, run no third-party trackers on the data layer, and your exports auto-delete after 30 days.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
query, title, company, location, salary, job_type, posted, snippet, url, job_key and status. One row per search result. job_key is Indeed's own listing identifier and status is a per-row flag from our export layer rather than something Indeed publishes.q, the location as l, and your filters as radius, jt, fromage and sort. Everything you set there shapes the export.snippet holds the short extract Indeed shows beneath each result, which is a teaser rather than the whole posting. Each row carries url and job_key, so the full description is one click away for the listings that warrant it.salary value, so keep it rather than parsing out the numbers alone. Employer-stated pay and modelled pay should not be averaged together.job_key. It is Indeed's own identifier for the posting - the jk value in a viewjob link - so it stays stable between runs in a way that a title-and-company match does not, particularly when a role is advertised by both an agency and the employer.Filter the search on Indeed, paste the URL, and take the listings away as rows - title, employer, pay, contract type and Indeed's own job key. Your first 500 rows are free.
Indeed is the largest job board in the world, and for most roles in most markets it is where a vacancy appears first. Its search is built for browsing: you type a title and a place, apply a filter or two, and scroll. That works when you are looking for one job. It works badly when the question is a market-wide one - what is the going rate for this role in this city, which employers are hiring for it right now, how has that changed since last month. The Indeed Job Scraper answers those by turning a search into a table: one row per listing, carrying the title, the employer, the location, the advertised pay, the contract type, the posting age, a snippet of the description, the listing URL and Indeed's own job key.
The design of this service puts the filtering where it belongs - on Indeed. An Indeed search URL encodes its own parameters: the keywords as q, the location as l (a postcode or a city and state), a radius around that location, a job-type filter covering full-time, part-time, contract, internship and temporary, a posted-within filter, and a choice between relevance and date ordering. Build the search you want on Indeed, copy the URL, and the run inherits all of it. That is not only convenient, it is the cheapest way to work: narrowing a search costs nothing, while exporting a broad one costs rows.
Two properties of Indeed's data are worth planning for before you build anything on the export. The first is the job key. Every posting on Indeed carries a jk identifier - the value you see in a viewjob link - and it comes through as job_key. That is the column to deduplicate on. Matching on title and company looks equivalent but is not, because the same role is often advertised more than once, sometimes by a recruitment agency and the employer simultaneously, and a text match will either merge two genuine vacancies or split one. The identifier will not. The second is posting age: Indeed writes it relatively on the results card rather than as a date, so it describes the listing at the moment of the run and cannot be compared across runs made at different times. Record your run date and derive real dates from it.
Two further caveats keep the analysis honest. Salary on Indeed is sometimes a figure the employer entered and sometimes a range Indeed models when the employer left it out; the card labels which, and that label travels in the salary string, so it should survive into your data rather than being parsed away - employer-stated pay and estimated pay answer different questions and should not be averaged together. And Indeed interleaves sponsored placements with organic results, meaning position in the list reflects advertising spend as well as relevance. Neither is a flaw to work around; both are simply how the board works, and knowing them is the difference between a defensible salary benchmark and a misleading one. Start free: your first 500 rows cost nothing and need no credit card.