Keyword Rank Tracker — Google SERP Positions avatar

Keyword Rank Tracker — Google SERP Positions

Pricing

from $50.00 / 1,000 keyword rank checks

Go to Apify Store
Keyword Rank Tracker — Google SERP Positions

Keyword Rank Tracker — Google SERP Positions

Track a domain's Google organic keyword positions by location and device. Returns one timestamped row per keyword with target rank, ranking URL, top results, check URL, and provider task provenance. This measures observed SERP positions; it does not guarantee rankings or future traffic.

Pricing

from $50.00 / 1,000 keyword rank checks

Rating

0.0

(0)

Developer

Khadin Akbar

Khadin Akbar

Maintained by Community

Actor stats

0

Bookmarked

1

Total users

0

Monthly active users

2 days ago

Last modified

Share

Keyword Rank Tracker checks where a domain appears in Google organic results for a bounded list of keywords. It returns one timestamped dataset row per successfully processed keyword with the observed target rank, target URL, compact top results, Google check URL, location/device settings, and the provider task ID used for provenance.

This is a conventional search-engine rank tracker for observed Google SERP snapshots. AI answer visibility, first-party Search Console performance, and future-rank forecasting belong to their own measurement workflows.

Best fit

Use this Actor for SEO agencies, content teams, publishers, and product marketers who need a repeatable position snapshot across a target location and device. It supports:

  • checking a domain against a prioritized keyword list;
  • comparing desktop and mobile visibility;
  • recording localized Google positions for a client report;
  • identifying the target URL and compact competitors for a keyword;
  • scheduled runs whose datasets can be joined by keyword, targetDomain, locationCode, and checkedAt.

For the next workflow step, route AI-answer visibility questions to AI Rank Tracker, citation-source questions to AI Citations Tracker, and first-party impressions/clicks analysis to the verified property's Search Console export. This keeps each measurement surface clear and makes the resulting reports easier to interpret.

How the workflow works

  1. The Actor removes blank and duplicate keywords and applies maxKeywords.
  2. It submits one Google organic SERP request per selected keyword to the configured rank provider.
  3. It matches the normalized target domain against organic result domains and result URL hostnames. Subdomains count as matches.
  4. It writes one validated row for each successful provider response. A target absent within depth is a valid row with found: false and null rank fields.
  5. It saves compact OUTPUT and detailed RUN_SUMMARY records in the run's default key-value store.

Inputs

FieldPurpose
targetDomainDomain to track, such as example.com; URLs are normalized to their hostname.
keywordsOne search phrase per line; duplicates are removed case-insensitively.
locationCodeGoogle location code; defaults to United States (2840).
languageCodeGoogle language code such as en.
device / osDesktop/mobile SERP profile and its matching operating system.
depthRequested result depth from 10 to 20. The bounded maximum keeps provider cost predictable.
maxKeywordsPer-run safety cap after duplicate removal; defaults to 25.
Rank-provider credentialsOptional managed rank-provider login and password (or matching Actor environment secrets). Used only for the request Authorization header and never written to output.

The credentials can instead be provided as Actor environment secrets. Keep credentials in private input or environment configuration rather than a public task or shared saved input.

Example input

{
"targetDomain": "apify.com",
"keywords": [
"web scraping platform",
"best data extraction tools"
],
"locationCode": 2840,
"languageCode": "en",
"device": "desktop",
"os": "windows",
"depth": 20,
"maxKeywords": 10
}

Output

The overview view is designed for rank reporting. The serp_evidence view retains the selected target result, compact top results, provider task ID, and check URL for review.

Important fields include:

  • keyword, targetDomain, locationCode, languageCode, device, os, and depth — the exact tracking context;
  • found, targetRank, and targetRankAbsolute — group and absolute positions, or null when the target is absent;
  • rankingUrl, rankingTitle, and rankingSnippet — the matching target result when present;
  • topResults — up to ten compact organic results for context;
  • checkUrl, checkedAt, and providerTaskId — reproducibility and provenance fields.

Example row

{
"runId": "abc123XYZ",
"keyword": "web scraping platform",
"targetDomain": "apify.com",
"found": true,
"targetRank": 3,
"targetRankAbsolute": 4,
"rankingUrl": "https://apify.com/",
"rankingTitle": "Apify: Full-stack web scraping and data extraction",
"rankingSnippet": "Extract data from websites with APIs and tools.",
"resultsChecked": 20,
"topResults": [
{ "rank": 1, "rankAbsolute": 1, "domain": "example.org", "title": "Example", "url": "https://example.org", "snippet": "..." }
],
"searchEngine": "google.com",
"locationCode": 2840,
"languageCode": "en",
"device": "desktop",
"os": "windows",
"depth": 20,
"checkUrl": "https://www.google.com/search?q=web+scraping+platform",
"checkedAt": "2026-08-09T10:00:00.000Z",
"providerTaskId": "01234567-89ab-cdef-0123-456789abcdef"
}

Terminal outcomes

Every run writes OUTPUT and RUN_SUMMARY before it terminates.

  • COMPLETE: every selected keyword produced a persisted row.
  • PARTIAL: at least one row was persisted, while another keyword returned an upstream issue or the Apify spending limit stopped the run.
  • VALID_EMPTY: all requests succeeded, but the target was absent from the requested result depth.
  • INVALID_INPUT: the request can be fixed by changing the target, keywords, location, device, OS, language, depth, or a paid search operator.
  • CONFIG_ERROR: rank-provider credentials or account access are missing or invalid.
  • UPSTREAM_FAILED: every valid provider request ended with an upstream issue and no row could be persisted.

Pricing and provider usage

The Actor uses Apify Pay per event. A keyword-rank event costs $0.05 for each persisted keyword row, including a valid absent-target row. Actor start is $0.00005. Apify platform usage is passed through to the user according to the live Pricing tab.

The pricing envelope is designed for at least 70% gross margin before platform usage: Apify retains 20% of the event price, while the documented Live Google SERP base cost is $0.002 per request. Depth is bounded at 20 (a maximum baseline provider cost of about $0.004), and paid search operators that incur a surcharge are rejected. That leaves about $0.036 per $0.05 event before any provider-account charges, while platform usage is passed through to the user.

Rank-provider usage is separate: the user supplies the managed provider account and pays that provider directly. RUN_SUMMARY.providerCostUsd records the provider-reported cost when returned; it is informational and separate from Apify charges.

API and MCP example

curl -X POST "https://api.apify.com/v2/acts/khadinakbar~keyword-rank-tracker/runs?token=$APIFY_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"targetDomain": "apify.com",
"keywords": ["web scraping platform"],
"locationCode": 2840,
"languageCode": "en",
"device": "desktop",
"os": "windows",
"depth": 10,
"rankProviderLogin": "YOUR_PRIVATE_LOGIN",
"rankProviderPassword": "YOUR_PRIVATE_PASSWORD"
}'

For an Apify MCP workflow, use this prompt card:

Run khadinakbar/keyword-rank-tracker for example.com on these five keywords in US English desktop results at depth 10. Read the overview dataset view, report found/rank/rankingUrl for every keyword, and include checkedAt, locationCode, device, providerTaskId, and the OUTPUT outcome. Keep the private rank-provider credentials in the approved secret path.

Then read the dataset's overview view and use checkUrl for human review. The output is bounded by maxKeywords and depth; providerTaskId and checkedAt provide provenance, while the keyword-rank event and provider cost make the two cost surfaces explicit.

Best results and outcome guidance

  • Keep the target as a bare domain when possible; a URL is accepted while path-specific tracking sits outside the advertised scope.
  • Use the same locationCode, languageCode, device, os, and depth across scheduled runs when comparing movement.
  • Use depth: 10 for first-page monitoring and depth: 20 when a bounded second-page check matters.
  • Treat found: false as “absent within the returned SERP”; it is evidence for the selected depth and context, while broader rank history comes from additional scheduled checks.
  • Use providerTaskId, checkUrl, and checkedAt when a stakeholder needs to audit a surprising position.
  • Keep Google locations and device profiles consistent within each trend line.

Scope and responsible use

Results are provider snapshots whose context is captured in each row. Interpret them alongside location, device, language, data freshness, and Google SERP layout. Use Search Console or analytics for traffic and conversion decisions. Respect the terms and privacy requirements of the search provider and the rank-data provider; keep credentials in private input or environment configuration.

Continue the workflow

FAQ

Which data source does this use?

It checks observed Google organic results through a managed rank provider (Google organic live). Search Console remains the right source for first-party performance data from a verified property.

How should I read found: false?

It means the target was absent from the returned organic results up to the selected depth. The Actor stores a row so scheduled datasets keep missing keywords visible.

Do subdomains count?

Yes. A result on docs.example.com matches example.com. A lookalike such as example.com.evil.test is outside the target-domain match.

Why did the provider cost change?

Provider pricing depends on the request and depth. This Actor rejects paid search operators and caps depth at 20 so its advertised event price maintains the margin target. Check RUN_SUMMARY.providerCostUsd and your provider account for the authoritative provider charge.

Why are search operators such as site: rejected?

The rank provider applies a surcharge to supported search operators. The Actor rejects those phrases rather than silently breaking its minimum-margin billing envelope.

Which search surfaces are supported?

This Actor advertises Google organic tracking. For AI-answer visibility, route to the linked AI Rank Tracker; a future Bing-specific Actor can use the same bounded row-and-provenance pattern.

Source documentation

Design note

I found in the first local implementation pass that the most useful contract decision was to persist one row per successfully processed keyword, including a valid no-match. That keeps absent rankings visible in scheduled reports, couples PPE to data users can read, and makes a no-match distinct from a provider outage. I also chose to preserve checkUrl and providerTaskId; those fields let an analyst audit an unexpected position without treating the stored rank as an unexplained number.