This one reads Google's careers site itself - not an aggregator. Each row is a live vacancy with its full description, its minimum and preferred qualifications, its responsibilities and a direct application link. Submit a search term or paste a filtered careers URL.
This is the opposite trade from the jobs vertical: one company instead of the whole market, but far more of each posting.
The Google Search Jobs Scraper reads Google's aggregated jobs panel - many employers, a short row each. This service reads Alphabet's own careers site. You get one employer group, but each row carries the full job description, the minimum and preferred qualifications and the responsibilities as written, which is enough to analyse rather than merely count.
"One employer" is doing some work in that sentence. The company column is not always Google: across our 131 rows it also returned YouTube, Waymo, Verily Life Sciences, Wing and GFiber. The careers site covers the Alphabet group, so a sweep gets the subsidiaries too - usually a bonus, occasionally a surprise if you assumed otherwise.
Input is flexible in a way the reference does not mention. A plain term like job works, and so does a filtered careers URL pasted straight in - we ran https://careers.google.com/jobs/results/?location=Los Angeles, CA, USA and got its result set back as rows. That is observed behaviour from our own runs rather than a documented contract, so verify it on the free tier before you build a pipeline that depends on it.
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 is the xlsx header row, identical across all 11 runs, in sheet order. The fill rates below are counted over the 131 rows those runs returned - covering 68 distinct job titles and 52 distinct locations.
Software Engineer, Early Careers, PhD, Cloud AI. Present on all 131, with 68 distinct values.Google. See the note below. | - one row in our sample listed 17.https:// and always carrying a jobId= parameter. Present on 104 of 131.2026-06-08. Present on all 131, and matched YYYY-MM-DD in every single one.Minimum qualifications:, and most also carry a Preferred qualifications: block. Present on 104 of 131.Nine of the ten columns carried data; one never did. Six are present on every row - query, title, company, location, posted and description. Three are present on 104 of 131. job_id was empty throughout. The most useful thing in this table is not a fill rate but a pattern: those three partial columns are the same 104 rows every time, which the note below explains.
All four come from reading the 131 rows rather than the reference, which is why they are worth the space.
apply_url, qualifications and responsibilities are each present on 104 of 131 rows - and it is the same 104. Rows carrying only one or two of the three: zero. So treat them as a single optional block: either a row has the full detail or it has the summary fields only. A single presence check on one of them tells you about all three.
All 131 rows matched YYYY-MM-DD exactly - no "3 days ago", no locale-formatted strings, no mixture. You can parse it directly and sort on it without a normalisation step. Our sample spanned 2025-07-30 to 2026-07-13, so postings stay listed well beyond a few weeks.
A single role open in several offices puts every one of them in the same cell, joined by | . One row in our sample carried 17 locations that way. Split on the pipe before you group by city, or your counts will treat each combination as its own place - and a role open in 17 cities will read as one obscure location nobody hires in.
Across 131 rows we saw six employers: Google on 108, then GFiber, Verily Life Sciences, Wing, Waymo and YouTube. If you are counting "Google headcount signals" you probably want to filter; if you are mapping Alphabet's overall hiring, you already have what you need.
Where the depth of these rows matters more than their breadth.
The qualifications column is the part candidates guess at. Pull every posting for a role family and the minimum-versus-preferred split stops being folklore: you can see which requirements are genuinely fixed, which are aspirational, and how the wording shifts between levels.
With the full description on every row, titles stop being the only signal. Sweeping the whole board shows how responsibilities scale across levels for the same job family - a far better input to a levelling framework than a title ladder copied off a blog.
Because posted is a real date and the subsidiaries are included, repeat runs turn into a time series. A cluster of new roles at Waymo or Verily in one region is a strategic signal that shows up here weeks before it shows up in the news.
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. 500 rows goes a long way here - our 11 runs together produced 131.
Roughly $2 per 1,000 results. Rows on this service are unusually dense - a full description, qualifications and responsibilities each - so the cost per useful word is lower here than almost anywhere in the catalogue.
Volume pricing, SLAs, dedicated workers and bespoke onboarding for teams tracking a hiring board on a fixed cadence. Tell us your numbers and we'll quote.
LIVESCRAPER10 at checkout.This service gives you everything about one employer group. These two give you the context around it.
The aggregated jobs vertical - many employers, a shorter row each, with the board every posting came from. The breadth to put this depth in context.
A hiring cluster usually has a story behind it. Filter news to the last hour, day, week, month or year to find the announcement that explains the postings.
Short answer: yes. This reads a public careers site, and the thing being read is published in order to attract applicants.
A careers page is public. Anyone can browse Alphabet's openings without an account. Collecting publicly visible listings 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.
Job postings sit unusually comfortably here. A vacancy 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, apply_url, posted, qualifications, responsibilities, description and job_id. That is the header row of real Livescraper careers exports, identical across 11 runs. Six are populated on every row; apply_url, qualifications and responsibilities on 104 of our 131; and job_id was empty on all of them.company column held six values - Google on 108 of them, plus GFiber, Verily Life Sciences, Wing, Waymo and YouTube. Filter on that column if you only want one of them.2026-06-08. All 131 of our rows matched YYYY-MM-DD, with no relative strings like "3 days ago" mixed in, so you can parse and sort on it without normalising first.apply_url, and the 27 that did not were also missing qualifications and responsibilities - the three always appeared together, never partially. So a row is either a full record or a summary one. Check any one of the three and you know about the other two.Submit a search term or a filtered careers URL and get Alphabet's openings back as rows - full descriptions, qualifications and responsibilities included. Your first 500 rows are free.
Most job data is thin by design. An aggregator shows a title, a company and a location, because that is all a results row needs to be clickable. The trouble starts when you want to analyse rather than browse: to know what a role actually requires, how one employer describes seniority, or which of its bets are being staffed. The Google Search Careers Scraper reads Alphabet's own careers site and returns each opening as a row carrying the full posting - the description, the minimum and preferred qualifications, the responsibilities as written, the location, the date and a direct application link. Submit up to 1,000 queries in a run, set language and country, choose how deep to go per query, and export as CSV, JSON or Excel.
The ten columns on this page are measured rather than assumed. They are the header row of real Livescraper careers exports, identical across 11 runs, and every fill rate quoted comes from the 131 rows those runs returned - covering 68 distinct job titles and 52 distinct locations. That matters because the reference for this endpoint documents the request side in full and does not enumerate the response columns at all, so a page that simply repeated the docs could not have told you what arrives. Six columns were populated on every row: query, title, company, location, posted and description. Three more - apply_url, qualifications and responsibilities - appeared on 104 of the 131. The tenth, job_id, is named in the header but was empty on every row and does not appear in the JSON export at all; it is listed here with that stated plainly rather than quietly dropped, because a column that exists and never fills is exactly the kind of thing that wastes an afternoon.
Four measured behaviours are worth knowing before you write an importer. First, those three partial columns are not independently sparse - they are the same 104 rows every time, with not one row carrying a partial set, so they behave as a single optional block and one presence check covers all three. Second, posted is a genuine ISO date in all 131 rows, with no relative strings mixed in, so it parses and sorts without normalisation; our sample ran from July 2025 to July 2026, which shows postings persist well beyond a few weeks. Third, location is a list hiding in a string: a role open in several offices puts all of them in one cell joined by a pipe, and one row in our sample carried seventeen that way, so split before you group by city or your geography will be nonsense. Fourth, company is not a constant - the careers site covers the Alphabet group, and alongside Google we saw GFiber, Verily Life Sciences, Wing, Waymo and YouTube.
Typical uses follow from the depth. Careers advisers and candidates read the qualifications column to replace folklore about the hiring bar with the text of the bar itself, minimum and preferred separated as the employer separates them. People and rewards teams sweep the whole board and read how responsibilities scale across levels within one job family, which is a sounder input to a levelling framework than a title ladder borrowed from elsewhere. Strategy teams re-run on a cadence and treat the result as a time series, watching where headcount is being added across the group - a cluster of new roles at one subsidiary in one region is a signal that tends to precede the announcement. One further note on input: a plain search term works, and in our runs a filtered careers URL pasted directly also worked and returned its result set as rows. The published reference describes only text queries, so treat the URL route as observed rather than promised, and confirm it on the free tier. Your first 500 rows cost nothing and need no credit card.