Long Tail Keyword Generator: Google Autocomplete A-Z

Type a topic, get hundreds of long tail keywords and questions. The Actor expands each topic with A-Z, 0-9 and question prefixes, asks Google Autocomplete once per prefix and returns every unique suggestion once, for Web, YouTube, Shopping or News, in your country and language.

One topic with A-Z and questions: 48 checks, $0.048, about 700 keywords (US English Web, staging run of 2026-10-30): about $0.07 per 1,000 keywords. You pay $0.001 per verified prefix check on the Apify Free plan and less on paid plans (from $0.00065 on Gold), platform usage included. Failed checks are free. No start fee, Google login, API key or proxy is needed; an Apify account is.

Already have keywords to watch? Monitor mode tracks new, lost and re-ranked suggestions for exact prefixes across runs.

Long tail keywords in one run

Open the form, keep air fryer or type your own topic, and press Start. The same run through the API:

{ "mode": "longTail", "seeds": ["air fryer"] }

Each Dataset row is one keyword. Excerpt from the 2026-10-30 staging run:

seed	suggestion	expansion	prefix	rank	seen_in_prefixes	is_question
air fryer	air fryer asparagus	alphabet	air fryer a	1	1	false
air fryer	air fryer chicken	alphabet	air fryer c	1	2	false
air fryer	how air fryer works	questions	how air fryer	1	1	true
air fryer	when air fryer invented	questions	when air fryer	1	2	true

prefix is the exact query sent to Google, rank the keyword's 1-based place in that prefix's list, and seen_in_prefixes how many of the seed's prefixes returned it (case and spacing ignored). Rows also carry word_count, depth, country, language, vertical and a stable source_id per seed and keyword. The Long tail keywords Dataset view shows these columns.

Input	Default	What it does
seeds	air fryer in the form	1-50 topics, one per line
country, language, vertical	us, en, web	Locale and suggestion box for every seed: web, youtube, shopping or news
expand	alphabet, questions	Prefixes per seed: alphabet (36: seed a ... seed z, seed 0 ... seed 9), questions (12: how, what, why ... + seed), prepositions (8: seed + for, with, without ...), comparisons (4: seed + vs, or, and, alternative)
depth	1	2 also expands the top depth2Seeds (5) suggestions of each seed with the alphabet
maxQueriesPerSeed	60	Hard cap on paid checks per seed. The most a run can cost is seeds x cap x your check price ($0.001 on Free)

Question, preposition and comparison words exist for English, German, French, Spanish, Portuguese and Italian. Seeds in other languages use the alphabet only, and RUN_SUMMARY.inputNotes says so. A prefix reached twice ("vs" is both a preposition and a comparison) is checked and charged once.

Measured on staging, 2026-10-30, priced at the Free-plan rate:

Run	Checks	Unique keywords	Price
1 topic, A-Z + questions, US Web	48	702	$0.048
1 topic, A-Z + questions, US YouTube	48	543	$0.048
1 topic, A-Z + questions, German Shopping	48	94	$0.048
3 topics, A-Z + questions + prepositions, depth 2, cap 120	360	3,806	$0.36

Shopping suggestions are sparse, and question prefixes returned nothing there: use expand: ["alphabet"] for Shopping (36 checks, $0.036 per topic). Counts vary by topic, market and day.

Statuses and the run summary

A seed with keywords and no failed prefix has only KEYWORD rows. Any other seed gets one SEED_STATUS row after its keywords:

status	Meaning
PARTIAL	Some prefixes delivered keywords; others failed or were not sent because of the charge limit, the run timeout or a Google outage. The keyword list is incomplete
NO_RESULTS	Every prefix was verified and Google suggested nothing
FAILED	Every checked prefix failed verification, or Google stopped answering the run (12 checks in a row failed, so the rest was not sent). This is never "no keywords". Not charged
SKIPPED	The charge limit (CHARGE_LIMIT_REACHED) or the run timeout (RUN_DEADLINE) came first. Not requested, not charged
INVALID_INPUT	The seed was rejected before any request, for example country zz in a target

RUN_SUMMARY reports seeds, prefixes checked, failed and skipped, unique keywords, merged duplicates, charged checks, cost_per_unique_keyword_usd, inputNotes and nextAction. If every prefix of the run fails, the run fails with SOURCE_FAILED and nothing is charged.

Long tail mode reads and writes no monitor state. monitorKey, baselineMode, confirmationChecks, minRankDelta, minRelevance and includeMetadata apply to monitor mode only; a non-default value is ignored and noted in inputNotes. An input with seeds and no targets always runs long tail; an API call without mode and with targets runs monitor mode as before.

Compare the best keywords in Google Trends

The five keywords per seed returned by the most prefixes carry trends_compare_url, a link to Google Trends Monitor. Autocomplete shows what people type, not how many search. To see which of the five has more interest, pass them as one comparison group so Google scales them together:

{
  "queries": [
    {
      "keywords": [
        "air fryer chicken",
        "air fryer chicken breast",
        "air fryer chicken thighs",
        "when air fryer invented",
        "which air fryer is good for health"
      ],
      "geo": "US",
      "property": "web"
    }
  ]
}

Use property: "youtube", "shopping" or "news" for the matching vertical. That is a separate run with its own pricing; nothing here calls it.

Related tools for keyword research

• Compare interest over time: Google Trends checks selected suggestions together, by country and search property. Its scores are normalized relative interest, not absolute search volumes.
• Check the pages you publish: Website SEO Audit checks your chosen website for technical SEO issues and later regressions. Pass website URLs, not the suggestion list; neither Actor measures your search-result position.

These are separate runs with separate pricing. Choose the suggestions and target website yourself, or map them in your own automation.

Monitor mode: track new and lost suggestions

Track the Google search suggestions shown for your brand, competitors and topic prefixes. Get typed alerts when a suggestion appears, disappears or changes rank, with a saved baseline and configurable confirmation across consecutive checks.

Monitor Web, YouTube, Shopping and News suggestions by country and language. Useful for SEO topic research, brand monitoring, ecommerce keyword discovery and recurring n8n, Make or API workflows. This is autocomplete position monitoring; it does not measure website rankings in search results or keyword search volume.

Set mode to changesOnly or snapshotAndChanges and list exact prefixes in targets. $0.001 per verified prefix check on the Free plan, less on paid plans, including platform usage. The three-prefix example costs $0.003.

The first run returns confirmed suggestions and saves a baseline. Later runs return typed changes and compact status rows for unchanged, duplicate or unsuccessful entries. Use the changes Dataset view for the alert feed.

One content brief, then confirmed changes

The default three prefixes now address the same job: air-fryer content questions in US English on Google Web. Replace them together for your topic. Keep country, language, vertical and monitorKey stable for comparable observations.

Run with confirmationChecks: 2	What it means
First run	Takes two successful samples per prefix to establish the confirmed baseline; returns suggestions with emitSnapshot
First later appearance or disappearance	Candidate change awaits confirmation; it is not yet a new/lost alert
Next successful confirming run	Emits the confirmed addition/removal when the same condition persists
Failed check	Retains the previous good state; it is not an empty suggestion list

Rank moves follow minRankDelta; confirmation mainly governs suggestion presence/absence. The SEO research Task uses confirmationChecks: 1 for an immediate snapshot; use 2 for a recurring alert watchlist.

To validate an idea, pick a few relevant suggestions yourself and submit them to Google Trends. Match country and search property, and compare keywords together when you need a common scale. Autocomplete position/relevance is not search volume. Monitor mode checks only the prefixes you list; long tail mode expands a topic, and neither starts a Trends run.

Monitor quickstart

Use the saved SEO content-planning example as a starting point, replacing its sample question prefixes. Check Current suggestions after the first run; an empty Changes view on a new baseline is expected. A three-prefix daily watchlist costs $0.09 over 30 successful days at the Free-plan $0.001/check rate, including platform usage.

{
  "targets": [
    { "query": "how to use air fryer", "externalId": "how-to", "country": "us", "language": "en", "vertical": "web" },
    { "query": "can air fryer", "externalId": "can-it", "country": "us", "language": "en", "vertical": "web" },
    { "query": "why air fryer", "externalId": "why-it", "country": "us", "language": "en", "vertical": "web" }
  ],
  "monitorKey": "example-autocomplete-content-questions",
  "mode": "snapshotAndChanges",
  "baselineMode": "emitSnapshot",
  "confirmationChecks": 1
}

Run once and export Current suggestions. Group the phrases into how-to, capability and troubleshooting questions, discard irrelevant suggestions, then select a small set for a content brief. Validate demand with a jointly normalized Google Trends comparison before prioritizing articles. This is a research input, not an automatically generated content plan.

The example uses one source sample for immediate research. For recurring alerts, set confirmationChecks: 2 and keep that setting and monitorKey stable. Review confirmed changes on later runs; country, language, vertical, source filtering and observation time affect coverage. Monitor mode does not reproduce every personalized Google UI list or expand the alphabet (long tail mode does), and neither mode guarantees an exhaustive keyword universe.

For n8n or Google Sheets, run the saved Task, wait for completion and retrieve its default Dataset. Keep external_id, query, country, language, vertical and the observation timestamp alongside each suggestion. Route confirmed change records to editorial review; retain failed checks without treating them as lost phrases. Scheduling and writing to Sheets are configured in your integration.

A target is a plain string or an object. Defaults are country: "us", language: "en", vertical: "web".

Choose a monitor workflow

Workflow	Starting prefixes / scope	Result and repeat use
Compare countries	insurance in US, UK (gb) and India; English Web	Current lists for side-by-side review. One sample per check; keep the same prefix to compare markets.
Plan SEO content	how to use air fryer, can air fryer, why air fryer; US Web	Current question suggestions for editorial review, with changes on later checks. This does not generate answers or expand every keyword.
Monitor brand comparisons	notion vs, notion alternatives; US Web	First-run baseline, then confirmed new/lost phrases and rank changes. The Changes view is empty until an actual change is confirmed.
Plan fitness videos	home workout, running shoes, yoga for beginners; US YouTube	Confirmed suggestion lists and changes for a recurring video-topic review.
Research German Shopping terms	beste laufschuhe, wanderschuhe, kaffeemaschine; Germany, German Shopping	Confirmed product-query suggestions and changes for German shops; no product prices or search volumes.

Replace the sample prefixes and use a separate monitorKey for each watchlist. Keep that key stable between checks. With confirmationChecks: 2, a new or lost phrase needs two consecutive successful checks; a daily watch can therefore take another daily run to confirm it. First-run lists are in Current suggestions. Use snapshotAndChanges if you need the list again on every successful run, or changesOnly for a compact recurring feed. Monitor Tasks do not create schedules or send notifications automatically.

The prepared Task examples use 2–3 scopes ($0.002–$0.003 per successful run on the Free plan) and a $0.02 run cap, allowing up to twenty distinct checked scopes at the Free-plan price. If you add more targets, increase the cap deliberately or expect uncharged SKIPPED rows. A single checked prefix can produce multiple Dataset rows.

The following output examples are illustrative excerpts, not live market findings.

Sample NEW_SUGGESTION

{
  "record_type": "CHANGE",
  "status": "SUCCESS",
  "change_type": "NEW_SUGGESTION",
  "query": "notion vs",
  "external_id": "notion-competitors",
  "country": "us",
  "vertical": "web",
  "suggestion": "notion vs obsidian 2026",
  "position": 3,
  "previous_position": null,
  "relevance": 600,
  "observed_at": "2026-09-11T06:00:00Z"
}

Sample LOST_SUGGESTION

{
  "record_type": "CHANGE",
  "status": "SUCCESS",
  "change_type": "LOST_SUGGESTION",
  "query": "notion vs",
  "suggestion": "notion vs goodnotes",
  "position": null,
  "previous_position": 10,
  "previous_relevance": 554,
  "observed_at": "2026-09-11T06:00:00Z"
}

Sample RANK_CHANGED

{
  "record_type": "CHANGE",
  "status": "SUCCESS",
  "change_type": "RANK_CHANGED",
  "query": "notion vs",
  "suggestion": "notion vs google docs",
  "previous_position": 6,
  "position": 1,
  "delta": -5,
  "previous_relevance": 602,
  "relevance": 602,
  "observed_at": "2026-09-11T06:00:00Z"
}

delta is negative when a suggestion moves up. It is measured among the suggestions confirmed in both checks, so a volatile neighbour arriving or leaving does not count as a move. That is why it can differ from position - previous_position.

Complete examples, including a baseline run and a run summary, are in examples/.

What it detects

Change	Meaning
NEW_SUGGESTION	A phrase has become consistently present.
LOST_SUGGESTION	A previously confirmed phrase has become consistently absent.
RANK_CHANGED	A phrase moved among suggestions confirmed in both checks.
METADATA_CHANGED	The suggestion type changed, such as QUERY to NAVIGATION.

With the default confirmationChecks: 2, a new or lost phrase must be observed on two consecutive successful checks. The baseline takes two samples in its first run; later runs normally take one per prefix. This delays an alert until the second confirming run. Set confirmationChecks: 1 for immediate changes.

Google rotates suggestions between identical requests. In one local capture of 12 prefixes sampled 12 times within about a minute, confirmation plus comparison among confirmed suggestions produced 92% fewer change events than a naive diff. This is a reduction in observed short-interval churn on that sample, not a measured accuracy rate or a guarantee that real changes will all be preserved. The first comparison after a baseline can still be noisier than later checks.

minRelevance: 0 includes all suggestions. Raising it excludes lower-scoring phrases and can remove useful long-tail terms. Google's relevance is an ordering score, not search volume. Score changes alone never generate an alert.

Countries, languages and verticals

{
  "targets": [
    { "query": "insurance", "country": "us" },
    { "query": "insurance", "country": "gb" },
    { "query": "insurance", "country": "in" },
    { "query": "beste laufschuhe", "country": "de", "language": "de" },
    { "query": "running shoes", "vertical": "youtube" },
    { "query": "running shoes", "vertical": "shopping" }
  ]
}

The same prefix in a different country, language or vertical is a different target: monitored separately, compared separately, charged separately. country and language are validated against ISO 3166-1 alpha-2 and ISO 639-1, because Google accepts an invalid code silently and answers with global suggestions - country: "uk" would otherwise be monitored for the wrong market indefinitely.

One local comparison of 11 prefixes found the following mean overlap with Web. These sample observations are not guarantees for your market:

Vertical	Overlap with Web	Use it for
web	-	the default search dropdown
youtube	14%	video demand language; strongly distinct
shopping	18%	product and commercial modifiers; strongly distinct
news	81%	mostly mirrors Web; distinct for some prefixes only

Google Images is not supported. Its endpoint behavior was not independently verified during source investigation.

Note that language is a weak signal at the source: country does most of the work, and Google frequently ignores a language that does not match the prefix.

Scheduling and webhooks

1. Save your watchlist as a task.
2. Schedule it daily or weekly (Apify Console, Schedules).
3. Add a webhook on Run succeeded pointing at your endpoint, Slack relay or n8n/Make/Zapier scenario.

For a daily check at 06:00 UTC, use 0 6 * * *. The source repository includes examples/schedule.json and examples/webhook.json, matching the schedule and webhook APIs. These are templates; running the Actor does not create a schedule or send notifications by itself.

Example schedule body for one prefix (one check, $0.001 on the Free plan; the $0.002 cap covers every plan):

{
  "name": "autocomplete-brand-watch-daily",
  "isEnabled": true,
  "isExclusive": true,
  "cronExpression": "0 6 * * *",
  "timezone": "UTC",
  "actions": [{
    "type": "RUN_ACTOR",
    "actorId": "07uQmK4SMPp5OCXjH",
    "runInput": {
      "body": "{\"targets\":[{\"query\":\"notion vs\"}],\"monitorKey\":\"brand-watch-daily\"}",
      "contentType": "application/json; charset=utf-8"
    },
    "runOptions": {"memoryMbytes": 256, "timeoutSecs": 600, "maxTotalChargeUsd": 0.002}
  }]
}

Example webhook body, after replacing the URL with an endpoint you control:

{
  "eventTypes": ["ACTOR.RUN.SUCCEEDED", "ACTOR.RUN.FAILED", "ACTOR.RUN.TIMED_OUT", "ACTOR.RUN.ABORTED"],
  "condition": {"actorId": "07uQmK4SMPp5OCXjH"},
  "requestUrl": "https://YOUR-OWN-ENDPOINT.example/apify/autocomplete"
}

The webhook carries run metadata, not individual change rows. Its receiver should read RUN_SUMMARY, then fetch that run's Dataset with view=changes&clean=true to exclude empty baseline/status projections. Notify only for relevant changes or operational failures; a succeeded run may contain invalid or failed inputs.

Every change row is usable as an alert payload as it stands: it carries the prefix, your external_id, the suggestion, both positions, and a source_url that a human can open to verify the claim.

Start with daily checks. More frequent checks can make short-lived rotation more prominent in your alert feed.

Run only one job at a time for each monitorKey. Its state is one KVS record; overlapping jobs can overwrite each other's comparisons. Wait for the previous run to finish before starting another run with the same key.

Changing confirmationChecks or minRelevance starts a fresh confirmed baseline for the affected targets. The old baseline remains intact until the new check succeeds and is delivered. State saved before these settings were recorded also re-baselines once. A relevance drop below the floor silently excludes the phrase; it does not emit LOST_SUGGESTION while Google still returns it.

Pricing

One event, a verified prefix check, where a prefix means one exact scope - query plus country, language and vertical. The price depends on your Apify plan:

Plan	Per check	Per 1,000 checks
Free	$0.001	$1.00
Bronze	$0.0009	$0.90
Silver	$0.0008	$0.80
Gold	$0.00065	$0.65
Platinum, Diamond	$0.00065	$0.65

The amounts below use the Free-plan price; paid plans pay less. There is no start fee.

In long tail mode every generated prefix is one check: one topic with A-Z and questions is 48 checks, $0.048, and returned 702 keywords for air fryer on US Web (2026-10-30). The bill depends on seeds and expansions, never on how many keywords come back, and is bounded by seeds x maxQueriesPerSeed x the check price (50 seeds at the default cap of 60: at most $3.00). Failed prefixes, retries and prefixes held back by the charge limit or the run timeout are never charged. The charge for a seed's checks follows the saved rows of that seed.

Monitor mode:

Watchlist	Per run	Daily for a month
20 prefixes	$0.02	~$0.60
100 prefixes	$0.10	~$3
500 prefixes	$0.50	~$15

Predictable from the watchlist alone. It does not matter whether a prefix returns 15 suggestions or none, whether it changed or not, or how many changes it produced. Never charged: retries, failed checks, responses that could not be trusted, prefixes held back by your charge limit, rejected entries, and the same scope listed twice.

Platform compute, storage operations and source requests during the run are included in the event price. Baselines, unchanged checks and valid empty results are each one verified check; confirmation samples are not extra paid events. The minimum allowed run charge cap is $0.001; it is a spending ceiling, not a minimum fee.

Set Maximum cost per run explicitly. One, 20, 100 and 500 unique scopes have maximum event bills of $0.001, $0.02, $0.10 and $0.50 on the Free plan. The default API cap is $1; use $0.003 for the three-prefix example. A lower cap preserves completed output and emits SKIPPED for entries it cannot deliver. The summary reconciles charges with delivered checks. Failed runs can contain earlier completed, paid checks.

Results are saved to the Dataset before a check is charged. If the platform declines that charge, the saved result remains available free of charge and remaining undelivered checks are skipped. uncharged_delivered_targets in RUN_SUMMARY counts these free delivered checks; their comparison state advances normally because the result was delivered. A failed or unconfirmed Dataset write is not charged.

Cloud measurements on 2026-09-09 at 256 MB: the default three-prefix baseline took 3.4 seconds; 100-prefix baseline and repeat checks took 16.1 and 9.7 seconds. These are single-run observations, including platform startup, not latency SLAs.

Failure semantics

A check that failed is never reported as a suggestion that disappeared. That is the guarantee this Actor is built around.

Charging, Dataset delivery and state saving are separate operations. An interruption during delivery can leave completed, paid rows without a saved comparison state. Resurrection fails closed instead of repeating side effects; a fresh run may report the same changes again if state was not saved. Inspect the Dataset and RUN_SUMMARY when available after a failed run.

status	Meaning
SUCCESS	Google answered with suggestions
NO_RESULTS	Google answered, validly, with none. A real observation, not a failure
FAILED	the answer could not be trusted. Nothing was reported as lost, the stored baseline is untouched, and you were not charged
INVALID_INPUT	the entry was rejected before any request was made
SKIPPED	the budget prevented delivery, either before checking or after charging stopped; already delivered results retain their verified status

Treated as failure, never as an empty result: rate limits and server errors after the retry budget, timeouts, an HTTP 200 carrying an HTML challenge or consent page, invalid JSON, an unexpected response shape, and a metadata array that does not line up with the suggestion list.

Monitor rows have deliberately no PARTIAL. One check of one prefix either produces a trustworthy observation or it does not. Long tail SEED_STATUS rows use PARTIAL for a seed whose many prefixes only partly succeeded.

Mass-outage protection. Among at least ten checked prefixes with previously confirmed suggestions, if at least half now return none, that is treated as a suspected source event: the empty prefixes keep their previous state, are reported as FAILED, and are not charged. A Google outage cannot generate a wave of false "lost" alerts.

One prefix failing does not stop the remaining checks. If every attempted target fails verification, the Apify run fails after writing diagnostic rows and RUN_SUMMARY. Mixed successful and failed targets retain their individual outcomes. An all-invalid batch fails without source requests or charges.

Each submitted entry has at least one row, joined by zero-based input_index. Duplicate scopes share one check and one charge. Their status rows preserve each entry's external_id and identify the first occurrence through duplicate_of. In changesOnly, an unchanged verified target receives TARGET_STATUS with SUCCESS or NO_RESULTS; baselineMode: "storeOnly" likewise returns status without the suggestion list. Filter record_type: "CHANGE" for alerts.

status describes the latest source sample. suggestion_count describes the confirmed set: a first empty sample can be NO_RESULTS while old suggestions remain pending confirmation. A positive relevance floor requires a valid score for every returned suggestion; missing scores produce FAILED, never losses.

How this differs from Google Trends

They measure different things and complement each other.

Google Trends - interest over time, regional interest, related and rising queries, breakout signals. Is this topic growing?

This Actor - what Google suggests right now for an exact prefix, which suggestions are in the list, where they sit, and how that changes across scheduled checks. What language is Google putting in front of people who start typing this?

For interest curves, use a Google Trends Actor.

Limitations

• The endpoint is undocumented. It is a public, unauthenticated, browser-facing endpoint, not a supported Google API. It can change shape or disappear without notice. When it does, the Actor reports failures and preserves your state rather than inventing changes.
• Suggestion membership can be unstable at the tail. The confirmation model manages this; it does not abolish it. Expect the head of the list to be solid and the last few slots to move.
• Relevance is not search volume, and relevance moves are not reported as changes. relevance is Google's own ordering score. Measured, it is largely derived from position - the tail is a literal 550 + k counter - and where it does move independently, the movement is not separable from noise: across short-interval samples, 1.9% of suggestions that held their exact position still had their score move, by as much as 150 points. This does not establish a dependable demand signal, so score changes do not generate a RELEVANCE_CHANGED event. Do not read relevance as demand, and do not read a rank move as a revenue forecast.
• suggest_subtypes are undocumented opaque integers. Passed through as returned; never used for change detection.
• Query prefixes are capped at 100 characters, because Google answers 101 with HTTP 400.
• Anonymous suggestions. No Google account, no cookies, no session. No cookies are sent, including cookies set by earlier responses. You get anonymous endpoint suggestions; they can still vary with Google's server selection, IP location and other source behavior.
• Maximum 500 prefixes per monitor run; 50 seeds and 400 checks per seed in long tail mode. A run that would outlast its timeout stops starting seeds and reports them as SKIPPED with RUN_DEADLINE instead of timing out.
• Long tail is breadth from autocomplete, not a keyword database. No search volume, CPC or difficulty. Question keywords are autocomplete suggestions that start with a question word, not Google's People Also Ask box.

API and MCP

Long tail through the API: save {"mode": "longTail", "seeds": ["air fryer"]} as input.json and start it with a cap of $0.05 (48 checks x $0.001 = $0.048 on the Free plan); use seeds x maxQueriesPerSeed x $0.001 as the cap for a bigger list. For the monitor, save the monitor quickstart JSON as input.json instead. The following Bash example starts a monitor run with a $0.006 cap (enough on every plan). Supply your Apify token through your secret manager or environment; keep it out of shared commands, URLs and source control.

curl --request POST \
  --header "Authorization: Bearer $APIFY_TOKEN" \
  --header "Content-Type: application/json" \
  --data-binary @input.json \
  'https://api.apify.com/v2/acts/automa-flow~google-autocomplete-rank-change-monitor/runs?maxTotalChargeUsd=0.006&memory=256&timeout=600'

Poll GET /v2/actor-runs/{runId}. When it finishes, use its defaultKeyValueStoreId to read GET /v2/key-value-stores/{storeId}/records/RUN_SUMMARY, and its defaultDatasetId to read GET /v2/datasets/{datasetId}/items. Keep the Authorization header on each request. Prefer these run-specific IDs over the last-run endpoint when you have several watchlists.

The first Dataset view, Long tail keywords, is for long tail runs. For a monitor run open Current suggestions (current), Changes (changes) or Target status / failures (status). Add ?view=changes&clean=true for the alert feed. The changes view projects and unwraps the optional change object; keep clean=true to omit empty projected rows. Raw Dataset records keep their flat fields, so record_type == "CHANGE" is the equivalent client-side filter. The other views select columns; inspect record_type and status to distinguish snapshots, successful checks, failures and skipped work. RUN_SUMMARY.operational reports batch health; a succeeded platform run may still contain invalid or failed entries.

The authenticated hosted MCP tool exposes this Actor's inputs and structured run output at:

https://mcp.apify.com?tools=automa-flow/google-autocomplete-rank-change-monitor

Example agent requests: "Generate long tail keywords for standing desk in Germany in German with mode longTail. Return the question keywords and the five rows with trends_compare_url." Or: "Check my brand prefixes under monitorKey brand-watch. Read RUN_SUMMARY and report failed or skipped checks separately. Return only NEW_SUGGESTION and LOST_SUGGESTION rows as alerts."

The direct MCP tool currently exposes waitSecs but not a per-call maxTotalChargeUsd option. For a strict per-call spending ceiling, use the Apify run API above. API execution and an authenticated hosted MCP execution were verified; public MCP search visibility must be checked after Store publication. Execution requires the customer's OAuth session or Apify token. See the Apify MCP documentation.

source_id aliases the stable target_key, and scraped_at aliases the UTC observed_at batch timestamp. Keep schema_version and fingerprint when exporting rows so observations can be joined to earlier runs.

---

Independent community Actor. Not affiliated with, sponsored by, or endorsed by Google. "Google" and "YouTube" are trademarks of Google LLC, used here only to describe what this Actor reads.

Technical source details

• Endpoint: https://www.google.com/complete/search with client=chrome, over HTTPS. No browser, no Playwright, no proxy, no CAPTCHA solving, no session bootstrap.
• Machine-readable instructions. https://www.google.com/robots.txt was checked on 2026-09-09 by expanding every rule in the User-agent: * group. The recorded source investigation found no rule matching /complete/search. Google's Terms of Service also cover protective measures, privacy and intellectual property. Absence of a matching robots.txt rule is not a commercial reuse license. Source risk is MODERATE: public, unauthenticated access with no supported API or explicit commercial automation license. Use only for lawful monitoring, respect source restrictions, and review the terms before redistributing collected suggestions. The Actor does not bypass blocks.
• Request volume. Long tail: one request per planned prefix, never more than maxQueriesPerSeed per seed, a prefix shared by two seeds requested once. Monitor: one request per prefix per run, plus one extra per prefix on a default first run to fill the confirmation window (up to three samples with confirmationChecks: 3). At most four requests in flight. Retries are bounded; the Actor does not bypass access restrictions.
• State. The Apify key-value store only, one compact record per monitorKey, holding the last confirmed suggestion set per prefix. No database. If that record cannot be written, the run fails rather than claiming a baseline was saved.
• Data collected. Public autocomplete suggestions and the prefixes you supply. These can contain personal names or other personal information; avoid supplying sensitive personal queries. No account data, credentials or cookie values are exported. Your prefixes and monitorKey are kept out of run logs. Run datasets and the comparison baseline remain in your Apify storage until you delete them or apply your account's retention policy.

Release notes

See the changelog for changes and notes about existing inputs.