SERP History: Track the Page's Shape, Not Just Your Rank

Copy this line to your agent to record what a results page looked like, not just where you sat on it.

set up https://monid.ai/SKILL.md and use api.strale.io /x402/google-search, then store the feature slots alongside the position

We hold forty-five non-brand keywords on page one of Google and they produced one click in twenty-eight days. Every rank report we could build from position data alone would describe that as a good month. This guide is about the fields that explain the gap, why almost nobody stores them, and what a SERP history is actually for, running through Monid, the OpenRouter for agent tools.

What is SERP history?

Two different things go by the name and only one of them is commonly built.

Position history, which everyone has

A number per keyword per day. Where you sat. Every rank tracker produces this and it is the thing people mean when they say they track rankings.

It is a measurement of you.

Page-shape history, which almost nobody has

What the results page looked like on that day. How many organic results there were at all. Whether an AI Overview fired. Whether an answer box, a knowledge panel or a People Also Ask block was present. Which competitors occupied the slots above you.

It is a measurement of the environment, and it is the half that explains the other half.

Why the second one is the useful one

Because your position can be unchanged while everything that determines your traffic changes. A keyword where you held position four all year, and where an AI Overview appeared in March, is a keyword you lost without moving. Position history records that as stability.

The reverse happens too. A drop from three to six looks bad and may be irrelevant if the page grew two new blocks above the fold, in which case position three had already stopped being valuable.

📖 See also Rank Tracking API: The Hard Part Is Not the Fetch

Why does a flat position line hide a real change?

Here is the argument with our own numbers rather than a hypothetical, because we are a clean example of it.

Forty-five keywords, page one, one click

Measured on 2026-08-30 across the twenty-eight days to 2026-08-25, our blog held forty-five non-brand keywords at a position better than ten. Those produced 259 impressions and one click.

At positions three to nine, a click-through rate of two to five percent is the ordinary expectation. That would be five to thirteen clicks. We got one.

What position data alone would tell you

That we rank on page one for forty-five terms, which sounds like progress and is the number a dashboard would show. It is true and it is useless, because it does not contain the fact that determines whether any of it matters.

The two explanations, and why you cannot separate them without shape data

The searcher never needed to click. An AI Overview or an answer box resolved the question at the top of the page. Our result was shown, read as a citation at best, and skipped.

Our result did not look like the answer. The title and description on the page did not match what the searcher was looking for, so they clicked something else.

Those have opposite fixes. The second is worth rewriting a title for; the first is not, and effort spent there is wasted. Without a record of whether an AI Overview was firing on those queries, we cannot tell which one we have, and we cannot go back and collect it.

That is the whole argument for storing shape. We are currently running a controlled title experiment on one page to distinguish the two, which is a slow and expensive way to answer a question a stored boolean would have answered for free.

Position history vs shape history: what actually differs

The two rows that matter are the last three. Shape costs nothing extra to collect because it arrives in the same response, it costs almost nothing to store, and it cannot be added retroactively.

How do you record a SERP's shape over time?

Three steps, and the whole thing is a schema decision rather than a tooling one.

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. Use an endpoint that returns the feature slots

What it does. Most search endpoints return results. Fewer return what else was on the page, and that is the part you are here for.

The endpoints. api.strale.io/x402/google-search returns the feature slots as first-class fields.

The call.

monid inspect -p api.strale.io -e /x402/google-search

What comes back. The schema, free to read. Check for knowledge_graph, answer_box and people_also_ask as named fields rather than something you would have to detect from the HTML.

What it costs. Nothing.

Step 2. Fetch, and read the empty fields too

What it does. Produces one row of the shape series.

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-27: ten results each with position, title, url, snippet, date and sitelinks, plus result_count, then knowledge_graph as null, answer_box as null, and people_also_ask as an empty array, plus search_parameters and a _meta block.

Read that again, because it is the point. All three feature fields came back empty, and empty is the data. A keyword whose answer_box is null in August and populated in November has changed enormously for you, and the only way to know is to have recorded the null.

What it costs. Cents per call, billed per call. Current figures at monid.ai/tools.

Step 3. Write six fields, not one

What it does. Makes the series answer questions you have not thought of yet.

The call. No endpoint. This is the whole intervention:

row = {
    "keyword": kw,
    "checked_at": now_utc(),
    "position": my_position_or_none(res),
    "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 []),
    "top_three": [r["url"] for r in res["results"][:3]],
    "params": res["search_parameters"],
}

A worked, scheduled version of this collection loop is in Automate SERP Tracking with a Structured Google Search API.

What comes back. The ability to answer, a year from now, why a keyword stopped converting. top_three is the one people leave out and it is the cheapest competitive intelligence available: a keyword whose top three changed completely between two runs is telling you something no position number will.

What it costs. Nothing on the day you write it, and it is impossible to add later.

📖 See also Google Search URL Parameters: What Still Works in 2026

What is PAA in SEO, and is it worth tracking?

People Also Ask is the expandable block of related questions Google inserts into results pages. It is worth tracking, and for a reason that is not the obvious one.

The obvious use, which is fine

The questions in the block are real queries with real demand, phrased the way people phrase them. Harvesting them is a decent source of subheadings and FAQ items, and most SEO writing about PAA stops here.

We use a different source for that ourselves, Google Autocomplete, because it returns the long tail rather than the eight questions Google chose to surface. Both work, and the three kinds of product that can supply either are separated in What Is a SERP API, and Which Kind Do You Need?.

The better use, which almost nobody does

Track whether the block is there at all, and how big it is.

A PAA block occupies a large amount of vertical space and answers questions inline. Its appearance on a keyword pushes every organic result down without changing anybody's position number, and it satisfies a share of searchers before they scroll. If it appears on a keyword you rank fourth for, your fourth is worth materially less than it was and nothing in a rank report will say so.

That is the same argument as the AI Overview one and it is easier to measure, because the count is right there in the response as an array length. If the questions themselves are what you are after, the build-versus-buy version of collecting them is in Buy vs Build: Structured Google Search Results API.

What to record

Not the questions. The count, per keyword, per run. Three numbers over three months tell you whether Google is progressively answering that query itself, which is the single most useful early warning in this whole category.

Which endpoint should I use for which job?

Every row was verified with monid inspect on 2026-08-30. The table gives billing shape rather than figures; shape drives design and current numbers live on monid.ai/tools.

Note that shape costs nothing extra. The feature slots arrive in the same response as the positions, on the same billed call. The only decision is whether you write them down, and the difference between a tracker that answers questions in a year and one that does not is entirely in that decision.

When is position history enough?

Three cases, and they are legitimate.

You are watching one keyword you already understand. If you know the page has no features and never has, the integer is the whole story and the extra fields are ceremony.

You need the number for a report somebody else reads. Client reporting, an internal dashboard, a board slide. The shape fields do not display well and the position does. Collect both, show one.

You are tracking Bing rather than Google. The source question comes first there, because the official API retired and the replacements are not equivalent; that is covered in Bing SERP Tracker: What to Use After the API Retired.

Your traffic is not from search. If organic is a small share of the business, this is real recurring work against a number that will not change a decision. Track quarterly by hand.

There is also a case for buying rather than building this. Ahrefs, Semrush and the dedicated trackers record SERP features already, they have historical archives you cannot reconstruct, and they ship the charts. If the question is "what did this look like before the March update", the archive is the product and no schema decision made today can substitute for it. That is the honest limit of everything on this page.

And the disclosure: this is Monid's blog, we sell per-call access to tools, so the argument we make best is the one where you already run a pipeline and are deciding what to write into it. If you need an archive and a dashboard, buy an archive and a dashboard.

Conclusion

SERP history means two different things and the industry built the less useful one. Position history measures you; page-shape history measures the environment that decides whether your position is worth anything. Our own data is the clean illustration: forty-five keywords on page one, one click, and no stored record of whether an AI Overview was firing on any of them.

The intervention is small and it does not scale with effort. The feature fields arrive in the response you are already paying for, they cost nothing to store, and they cannot be added retroactively. Write six fields instead of one and the series will answer a question in a year that it otherwise cannot answer at all.

Free next step: run monid inspect -p api.strale.io -e /x402/google-search and look at the response schema. It is free, and seeing answer_box and people_also_ask sitting there as named fields is the fastest way to understand that you have been throwing them away. Start at monid.ai.

FAQ

Last updated August 2026.