Google keeps a separate results vertical for jobs - the panel you get for a query like "react developer jobs in Berlin". It gathers postings from job boards and company career pages into one ranked list. This service reads that vertical for a list of queries and returns the results as rows.
Worth being precise about what this reads, because "jobs" invites a bigger assumption than the service makes.
Google's jobs vertical is a search surface. It does not host vacancies of its own - it indexes postings that already exist on job boards and company career pages, then ranks them for a query. This service submits your queries to that surface and hands back what it returns. The via column exists precisely because a result belongs to some other board first.
What it is not is an applicant-tracking integration or a licensed jobs feed. It reads a public results page. Nothing is applied to, no candidate is contacted, and no employer or board account is involved.
One more thing, stated plainly rather than buried: the published reference for this endpoint documents the request side in full but does not publish a column list for the results. The nine columns in what you get back come from real Livescraper exports instead - and those exports carry the header row without example values, so that section says which columns arrive and stops there.
The same shape as the other search verticals - a list of queries, a locale, and how deep to go.
Pages per query defaults to one page, so a run stays modest unless you deliberately go deeper.
This list is the actual header row of Livescraper job exports, in sheet order. It is not copied from the API reference - that document covers the request side and leaves the result columns unspecified - and it is not borrowed from any other service on this site.
Column names are confirmed; values are not. Both exports behind this list came back with the header row and no data rows, so we can tell you exactly which columns arrive but not what a populated cell looks like - not the date format in posted, not whether salary carries a currency, not how long description runs. Run one query against the one-time 500 free rows to see real values in each column before you build against them.
Three settings shape a run. On this vertical they are not equally important.
Breadth - up to 1,000 queries in one run. Hiring research is naturally many-queried, because the unit of interest is usually a role, a city or a company, and you rarely want just one. A single run can hold a whole market map. Depth - pages per query, defaulting to one. The first page is what a candidate actually sees, so it's usually the honest sample; go deeper when you're building an exhaustive list rather than a visibility read. Locale - language and country as separate settings, the same pair used on the Google Search Scraper. Every vertical is somewhat localised. This one is about locality: a vacancy is a job in a place, so the country you search from shapes the result set more here than almost anywhere else in the catalogue. Leaving it at the default and reading the output as global is the mistake to avoid.
A practical consequence: put the place in the query as well as in the settings. "Data engineer Lisbon" and "data engineer" searched from Portugal are different questions, and the first is almost always the one you meant. The same goes for seniority and contract type - the vertical ranks against the words you give it, so a vague query returns a vague market.
Where a jobs export earns its keep.
Before you write a job ad, read the competition. Pulling a role across a city shows how others title it, where they place it and how they describe it - which is a far better brief than an internal template that was last revised two reorganisations ago.
Hiring is one of the least ambiguous signals a company emits. A fixed set of company-name queries, re-run on a schedule, turns that into a series you can read: a team being built, a market being entered, a function being rebuilt after departures.
The via column names the source Google credits each result to. Sweep a sector and the distribution shows you which boards own which niches - useful whether you are deciding where to advertise or where your own listings are being outranked.
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 - and on this service in particular, the free rows are how you see real values in each column before committing to anything.
Roughly $2 per 1,000 results. With depth defaulting to a single page, a role-by-role sweep across a region costs less than most people assume - the estimator prices the run before it starts.
Volume pricing, SLAs, dedicated workers and bespoke onboarding for teams tracking hiring across many roles and markets. Tell us your numbers and we'll quote.
LIVESCRAPER10 at checkout.Expansions get announced, employers have reputations, and the company behind a posting has a website. Teams reading hiring signals rarely watch only one surface.
A hiring push is usually announced before it is advertised. The news vertical filters to the last hour, day, week, month or year - and its columns come back populated, so you can see real values before you build.
The organic vertical for the same queries - listings, ads, shopping results and related questions. Where the employer and board websites themselves show up, with a documented field set.
Short answer: yes. This reads a public results page, and the thing being read is information published to attract applicants.
A jobs results page is public. Google shows anyone what's advertised for a role, signed in or not. Collecting publicly visible results for research is long-established practice, and as long as the data is publicly available and the process doesn't disrupt the site there are no federal laws prohibiting it.
Vacancies sit unusually comfortably here. A job posting exists in order to be found - the employer published it precisely so people would see it. There is no login, no paywall, and nothing is applied to on your behalf. The subject of a posting is a role at a company, not a named individual, so this is company data rather than personal data.
Google'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, via, posted, salary, link and description. That is the header row of real Livescraper job exports, identical across both runs - not a list from the API reference, which leaves the result columns unspecified. One caveat worth knowing: both exports came back with the header row and no data rows, so the column names are confirmed but example values aren't. Run one query on the free 500 rows to see populated cells.via is the column naming the source a given result is credited to. What we can't yet tell you is how those values are written, because both of our sample exports arrived without data rows.Submit your role, city or company queries and get Google's jobs results back as rows. Your first 500 rows are free - and they're the right way to see real values in each column before you plan anything around them.
Google maintains a dedicated jobs vertical: ask for a role in a city and you get a ranked list of vacancies gathered from job boards and company career pages rather than ordinary web pages. For anyone whose work depends on knowing who is hiring for what - recruiters sizing a market, talent teams benchmarking a job ad before they write it, analysts reading hiring as a growth signal - that vertical is the most convenient single view of the labour market in existence. Reading it one query at a time in a browser is the bottleneck. The Google Search Jobs Scraper removes it: submit up to 1,000 queries in a run, set language and country, choose how deep to go per query, and take the results away as CSV, JSON or Excel with each query's results kept distinct.
One thing is worth saying directly on this page, because pipelines get built on assumptions. The published reference for this endpoint documents the request side in full but does not specify the result columns, so the nine-column list on this page does not come from there - it is the header row of real Livescraper job exports, identical across both runs held locally. Nothing on this page is a guess at what a jobs row "should" contain. The limit of that evidence is worth stating too: those exports arrived with the header row and no data rows, so we can name every column and cannot show you a populated one. We do not know the date format in posted, whether salary carries a currency or a range, or how much of a posting description holds. The recommendation that follows is concrete rather than hand-waving: run a single query against the one-time 500 free rows and open the file. A minute's work and no money shows you real values in each of the nine columns, which is a better foundation than a confident-sounding table on a marketing page.
What the run does control is well defined. Breadth is up to 1,000 queries, which suits hiring research particularly well, since the natural unit is a role, a city or a company and you almost never want only one. Depth is pages per query and defaults to a single page - usually the honest sample, because one page is what a candidate actually sees. Locale is language and country as separate settings, and on this vertical it matters more than most: a vacancy is a job in a place, so where you search from shapes the results more than it would for a general text query. The practical advice that follows is to name the place in the query as well, since "data engineer Lisbon" and a bare "data engineer" run from Portugal are not the same question. Seniority and contract type behave the same way - the vertical ranks against the words you give it, so a vague query returns a vague market.
Typical workflows fall into three shapes. Talent teams pull a role across a city and read how competitors title, place and describe it, which is a better brief for a job ad than an internal template nobody has revised in years. Strategy and research teams fix a set of company-name queries and re-run them on a cadence, treating hiring as one of the least ambiguous signals a company emits - a team being built, a market being entered, a function being rebuilt. Recruitment and marketing teams sweep a sector and read the via column as a coverage map of which boards own which niches. All three are pointer work - you learn what exists and where to look next, which is exactly what a results page is for. Nothing is applied to, nobody is contacted, nothing behind a login is touched, and exports auto-delete after 30 days. Start free: your first 500 rows cost nothing and need no credit card.