Rank Tracking API: The Hard Part Is Not the Fetch
Getting today's position is one cheap call. The product is yesterday's position, identical parameters, and knowing what moved. Here is the whole shape.
Copy this line to your agent to pull a ranked SERP with positions you can store.
set up https://monid.ai/SKILL.md and use api.strale.io /x402/google-search to get positions for a keyword list
Every article about rank tracking APIs compares vendors on how fast they return a SERP. That is the easy half and it has been solved for years. The product is the other half: a column of positions stored day after day, fetched with parameters that never drift, and read in a way that tells you whether you moved or the page under you did. This guide is about that half, and about the one endpoint field most people never store, running through Monid, the OpenRouter for agent tools.
What is a rank tracking API?
A rank tracking API returns where a given URL sits in the results for a given query, so a program can record it. That definition sounds identical to a search API and it is not, because the two are used at different frequencies for different reasons.
Search once, track forever
A search API answers a question now: what is on this page today. You call it when a user or an agent asks something, you use the answer, you throw it away. A rank tracking API answers a question about change: is this position different from last Tuesday. You call it on a schedule you set, and the answer is worthless unless you kept the previous ones.
That difference in disposal is what makes them different products. A search endpoint that never stores anything is complete. A rank tracker that never stores anything is a stopwatch with no memory.
What you are actually recording
Position is the obvious field and it is the least of it. A useful record for one keyword on one day holds the position, the URL that held it, the title and snippet Google rendered, whether the answer box or the knowledge panel fired, how many organic results there were at all, and the exact parameters the query ran under. Drop any of those and a future question becomes unanswerable.
The one people skip is the last. Which brings us to the reason this is harder than it looks.
Why is tracking a rank harder than fetching one?
Because a time series is only meaningful if every point was measured the same way, and search results are personalised, localised and restructured constantly.
The parameters have to be frozen, and provable
Country, language, device, and location all change the result set. If Monday ran with one country code and Thursday ran with another, the position moved and you learned nothing. Every serious tracker pins these, and the ones that survive an audit store what they pinned alongside the number.
This is why the response field to care about is the one echoing your query back. Running api.strale.io/x402/google-search live on 2026-08-26 returned search_parameters in the payload beside the results. Store that object with the row, and a year later you can prove Monday and Thursday were comparable. Store only the integer and you cannot.
The page changes shape, not just order
Position three means something different on a page with an answer box, four ads and a video carousel than on a plain ten-blue-links page. That same live run returned knowledge_graph, answer_box and people_also_ask as first-class fields, all empty on that particular query, alongside result_count.
Empty is data. A keyword whose answer box appears in March and disappears in June has changed enormously for you, and a table of positions alone shows a flat line across the event. This is the single most common blind spot in homegrown trackers.
Provenance drifts and nobody notices
Rank data comes from somewhere, and the somewhere can change under you. The same response carried a _meta block naming its upstream, google-serper, with a fetched_at timestamp and a latency reading of just over half a second. That is not decoration: if the provider swaps its upstream, your series has a discontinuity that looks exactly like a ranking change.
Store the provenance field. It costs nothing and it is the only way to tell a real movement from a supplier change.
Fetch vs track: what actually differs
| Aspect | A search API call | A rank tracking system |
|---|---|---|
| Frequency | On demand | On a schedule you own |
| Lifetime of the answer | Discarded | Kept forever |
| What must be identical | Nothing | Every parameter, every run |
| Cost driver | Calls made | Keywords times days |
| Hard part | Getting the page | Keeping the series comparable |
| Failure mode | An error you see | A silent discontinuity |
The last row is the whole argument. A fetch fails loudly; a series degrades quietly.
How do you track rankings on a schedule?
Three steps. The third is the one nobody writes about.
For agents
Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:
set up https://monid.ai/SKILL.md
It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main
Step 1. Find an endpoint that returns a position
What it does. Not every search endpoint gives you a rank. Retrieval-oriented ones return relevance, which is their own ordering rather than Google's, and that is useless for tracking.
The endpoints. api.strale.io/x402/google-search returns a numbered SERP; context.dev/web/search returns ranked results with a relevance band instead.
The call.
monid discover -q "google search results with positions"
monid inspect -p api.strale.io -e /x402/google-search
What comes back. The schema, the billing shape and the price, all free to read. Check specifically that a position integer exists, because a relevance label is not one.
What it costs. Nothing. Discovery and inspection never bill.
Step 2. Fetch with parameters you will repeat
What it does. Produces one row of the series.
The endpoints. api.strale.io/x402/google-search, billed per call regardless of how many results come back.
The call.
monid run -p api.strale.io -e /x402/google-search -w \
--query '{"query": "best web scraping api", "country": "us"}'
What comes back. From that exact run on 2026-08-26: a results array of ten entries each carrying position, title, url, snippet, date and a sitelinks array, plus result_count, the three SERP feature slots, search_parameters, and the _meta block described above.
What it costs. Cents per call, billed per call rather than per result, which is the shape that matters here: a rank check is one call whether the page had ten results or a hundred. Current figures at monid.ai/tools.
Step 3. Write the row, not the number
What it does. Makes the series survive a year.
The call. No endpoint. A schema decision:
row = {
"keyword": kw,
"checked_at": now_utc(),
"position": next((r["position"] for r in res["results"]
if domain(r["url"]) == MY_DOMAIN), None),
"result_count": res["result_count"],
"had_answer_box": res["answer_box"] is not None,
"had_knowledge_graph": res["knowledge_graph"] is not None,
"paa_count": len(res.get("people_also_ask") or []),
"params": res["search_parameters"],
"source": res["_meta"]["provenance"]["source"],
}
What comes back. A row that answers questions you have not thought of yet. Note position is None when you are not on the page at all, which is different from position 100, and conflating those is the second most common mistake in this category.
What it costs. Nothing, and it is the difference between a rank tracker and a number that goes up and down for reasons you cannot reconstruct.
📖 See also Automate SERP Tracking with a Structured Google Search API
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to check where monid.ai ranks for these 20 keywords in the US, store the position plus the search parameters and whether an answer box fired, and tell me which ones changed since the last run.How do you track Bing rankings now?
Bing is the largest term in this cluster and the awkward one, because the official route changed. Microsoft retired the Bing Search API, which removed the obvious way to check a Bing position programmatically, and we wrote up the replacement landscape in Bing Search API Retired: What Actually Replaces It.
For tracking specifically, three things follow.
The independent indexes are not Bing. Several search APIs that appeared after the retirement run their own crawl. They are good products and they are not a mirror of Bing's page, so a position from them is not a Bing rank. If the number has to be Bing's, an index of somebody else's is the wrong instrument no matter how good it is.
Bing Webmaster Tools remains free and first-party. For your own domain, it reports impressions, clicks and average position straight from Microsoft. That is better data than any third party can sell you for the sites you control, and it costs nothing. Use it, and reach for a tracker only for the sites you do not control.
Everything in this guide applies unchanged. Whichever source you land on, freeze the parameters, store the provenance, and record the page shape rather than just the integer. The retirement changed the supplier and changed nothing about the storage problem.
Which endpoint should I use for which job?
| Endpoint | What it does | Input | Output | Best for | Billing |
|---|---|---|---|---|---|
api.strale.io/x402/google-search | Numbered SERP with features | Query, country | position per result, feature slots, search_parameters, _meta | Recording a rank | Per call |
context.dev/web/search | Ranked results with a relevance band | Query, freshness, domain filters | URL, title, description, relevance | Retrieval, not ranking | Per result |
context.dev/web/scrape/markdown | Reads a competitor page that moved | A URL | Markdown, headings, JSON-LD | Investigating why a rank changed | Per call |
api.strale.io/x402/keyword-suggest | Autocomplete expansions | A seed keyword | Questions, comparisons, long tail | Finding what else to track | Per call |
Every row was verified with monid inspect on 2026-08-26. The table gives billing shape rather than figures; shape is what changes your design and current numbers are on monid.ai/tools.
The per-call versus per-result distinction is the budget in this category. Rank checks are per call, so a hundred keywords checked daily is a hundred calls a day regardless of page size, and the monthly figure is a multiplication you can do before you start. Two hundred keywords daily lands in low tens of dollars a month, which is well under most tracker subscriptions and well over zero, so it is worth trimming the keyword list before it is worth optimising anything else.
When should you just buy a rank tracker?
Three cases where building is the wrong call.
You want the interface more than the data. Ahrefs, Semrush and the dedicated trackers ship dashboards, share-of-voice charts, competitor overlays and client reporting. If somebody needs to look at this weekly and does not want to build a chart, buy the chart. The storage argument in this guide is about what the tool has to do, not about who should write it.
You need historical data you did not collect. This is the honest limit. A tracker you build starts today, and no amount of good schema design gives you last year. Established tools have archives, and if the question is "what did this look like before the March update", buying the archive is the only answer.
Your keyword count is very large. The per-call economics are pleasant at hundreds of keywords and stop being pleasant at tens of thousands checked daily. At that scale the platforms have negotiated rates you cannot match, and the arithmetic flips.
There is also a case for the specialists. Companies whose entire product is rank data handle the localisation matrix, device splits and the SERP feature taxonomy in more depth than a generic search endpoint exposes. If rank data is your product rather than your instrument, buy from someone whose product it also is.
And the disclosure: this is Monid's blog and we sell per-call access to tools, so the argument we make best is the one where you already have a pipeline and need a position in it. If what you need is a dashboard on Monday morning, buy a dashboard.
Conclusion
The comparison every article in this category runs, which API returns a SERP fastest, is a comparison of the part that does not fail. Fetching a ranked page is a solved, cheap, per-call operation available from several good providers. What fails is the series: parameters that drifted, a supplier that changed upstream, and a flat position line hiding the month an answer box appeared and took the clicks.
So the useful decision is not which vendor. It is what you write down. Store the parameters, the provenance and the page shape next to the integer, and treat a missing position as absent rather than as one hundred. That schema costs nothing on the day you design it and is impossible to add retroactively.
Free next step: run monid discover -q "google search results with positions" and monid inspect the top result. Both are free, and the schema will tell you in a minute whether the endpoint returns a real position or a relevance label. Start at monid.ai.
FAQ
Is there a Google rank tracker API?
There is no official one from Google. The Search Console API reports average position for your own properties, which is first-party and free but only covers sites you verify, and it is an average across impressions rather than a position on a specific page. For sites you do not own, the answer is a SERP endpoint that returns a numbered result list, and the field to check for in the schema is an integer position rather than a relevance label.
What is the best keyword rank checker API?
The ones that matter for a checker are the ones returning a real position plus the SERP feature slots, because a position without the page shape is not interpretable. Beyond that, pick on billing shape rather than on speed: per-call billing suits rank checks because the cost of a keyword-day is fixed regardless of how large the results page was, and that makes the monthly figure something you can calculate in advance instead of watching.
How do you build a Google rank tracking API into a workflow?
Schedule the fetch, write the full row rather than the integer, and diff against the previous run rather than recomputing everything. In a workflow tool the same three steps apply and the storage question is the same, which is the part the node library will not solve for you. The wider version of running data endpoints inside an orchestrator is in The Data Layer for n8n.
Does location change the rank you get back?
Yes, substantially, and for anything with local intent it is the dominant variable. This is why the parameter object in the response matters more than any single setting: pin the country and locale explicitly rather than accepting a default, and store what you pinned with every row. A tracker whose numbers move when a provider quietly changes a default is worse than no tracker, because it produces confident readings that are wrong.
Last updated August 2026.
