Google People Also Ask Scraper - Question Tree

Collect the People Also Ask questions Google shows for a keyword, then expand each of those questions to get the questions behind them.

No API key, no browser, no login.

One seed, four questions. Or seventeen.

A results page carries four or five People Also Ask entries. On its own that is a thin answer, and it is what every other tool in this category returns.

The value is in the tree. Ask one of those questions and Google shows four more, most of them new. Measured on best crm software, en/us:

depth	what happens	questions
0	read the seed's own results page	4
1	also ask each of those four	17

Same seed, one input change, four times the material. Depth 2 and 3 go further and each level costs roughly four times the previous one, which is exactly why depth is a visible number in the input form and not a hidden default.

Every row keeps parent_question and depth, so the flat dataset rebuilds into the tree it came from:

best crm software
├── What is no 1 CRM?
│   ├── What is the #1 CRM in the world?
│   ├── Which CRM is the most popular?
│   └── Who is the biggest CRM company?
├── Is AI going to replace CRM?
│   └── Will CRM be taken over by AI?
├── What is the #1 CRM platform?
└── Is CRM difficult to learn?

A branch that cannot be traced back to the question that produced it is just a keyword list. This one is a map of how Google thinks the topic breaks down.

What you get

One row per question:

field	example
question	Can web scraping be detected?
seed	web scraping
parent_question	Is web scraping illegal?
depth	1
language	en
market	us
position	9

Duplicates are removed across the whole run, not per page. A question that shows up under two different parents is kept once, under the first parent that surfaced it, so questionsReturned is a count of distinct questions rather than an inflated total.

Three things this gets right

The seed is not sold back to you as a question. Google writes the query itself into the same place on the page as the questions. Read that naively and your export says people also ask "cheap flights amsterdam" about "cheap flights amsterdam". Worse, an expanding run then asks the same thing again and loops. Both are handled, structurally and by name.

There is no answer column, because there are no answers. Google fetches a People Also Ask answer at the moment somebody clicks the question, so no answer exists on the page that was served. Tools that promise answers here are either doing a second round of work they charge you for anyway, or handing you empty strings. This one says answersAvailable: false in the run summary, once, and gives you the questions.

A silent change is reported as a number. If Google keeps the attribute but changes the tag around it, a naive extractor returns nothing and the run looks successful on a keyword you assume was just thin. The summary carries queriesWithChangedMarkup for exactly that case, separately from queriesWithNoQuestions, which is the normal and legitimate one.

Input

field	default	notes
keywords	—	One per line. Each becomes a search.
depth	1	0 reads the seed's page only. 1 also expands each question found. Max 3.
max_questions	200	Stop after this many distinct questions. Your cost ceiling.
language	en	Two letters. The questions come back written in it.
region	us	Two letters.
attempts	20	How often to retry a search before giving up on it.

Minimal run:

{ "keywords": ["best crm software"] }

Flat, cheapest, one request per seed:

{ "keywords": ["best crm software", "crm for small business"], "depth": 0 }

Dutch market:

{ "keywords": ["beste crm software"], "language": "nl", "region": "nl" }

Language and country both matter

People Also Ask is regional, and the two inputs do different jobs: language decides what the questions are written in, region decides which market's questions you get. beste crm software at nl/nl returned questions about ZZP'ers and small Dutch businesses that have no equivalent in the en/us set for the same topic. Running one keyword across several markets is a legitimate use of this Actor, and language and market are on every row so the results stay separable afterwards.

What it is for

Content briefs. The depth-1 tree for a target keyword is a section outline that came from Google rather than from a guess. Questions at depth 0 are the headings, their children are the subheadings.

FAQ blocks that match real queries. These are the questions Google has already decided are adjacent to the topic, phrased the way it phrases them.

Finding the gap. Run the tree for your keyword and for a competitor's. Questions in theirs and not in yours are pages you have not written.

Topic modelling at low cost. A depth-1 run on one seed is five searches. A depth-2 run is around twenty. That is a topical map for a few cents.

Pricing

Pay per event.

event	price
Run start	$0,002
Question returned	$0,003

One seed at depth 0 is four questions: $0,014. One seed at depth 1 returned seventeen: $0,053. max_questions is a hard ceiling, so a run cannot cost more than you decided in advance.

Limits, stated plainly

• No answers. Explained above. Questions only.
• Four or five per page. That is what Google publishes. A seed that returns four questions at depth 0 is not a failed run, and thin or very specific keywords sometimes return none at all. Those are counted in the summary as queriesWithNoQuestions.
• Depth costs. Each level multiplies the searches by roughly four. Depth 3 on several seeds is a big run; set max_questions before starting it.
• Not every search comes back on the first try. The Actor retries, and the summary reports requestsRetried so a slow run is explainable rather than mysterious. A query that never came back becomes an entry in the errors record instead of vanishing.
• Questions change. Google rewrites People Also Ask constantly. Two runs a week apart on the same keyword will not match exactly, and that is the source behaving normally.

Output

Rows go to the default dataset. The run summary and any errors go to the default key-value store as summary and errors. The summary carries the seed count, queries sent, questions per depth level, retries, and the two counters described above, so a run can be judged without reading the rows.