Skip to content

Series · 7 parts Published July 30, 2026

Search rank reporter

A small system that reads your own search performance data, groups queries into the themes your business actually cares about, and reports movement that is large enough to mean something. It never guesses at rankings and it never claims a cause it cannot see. Seven posts on the same system — one diagram at a time — with a cost breakdown and an engineering reference at the end.

  1. 01

    A search rank reporter on AWS for a few dollars a month

    The whole system on one page — a fetcher, a grouper and a reporter — built around the fact that the raw data is far too granular to act on.

  2. 02

    How search data gets fetched

    The reporting delay, the row limits that quietly truncate a fetch, the long-tail queries that are withheld entirely, and why the raw response is stored first.

  3. 03

    How queries get grouped

    Why grouping rules are written rather than discovered, the order they apply in, the brand and competitor themes that need special handling, and why the unmatched bucket is the most useful output.

  4. 04

    How a ranking change is judged

    Why impressions gate every comparison, the seasonality that fools week-on-week reporting, and the crucial difference between a ranking change and a demand change.

  5. 05

    How the ranking report reads

    Why the same six themes appear every week in the same order, how pages are named, and the causal claims the report refuses to make.

  6. 06

    What the search rank reporter costs

    About $1 a month. One Bedrock read per weekly fetch is the only line that grows; the queue, the table, the mail and the storage are rounding errors. Plus the three ways the bill could surprise you.

  7. 07

    Engineering reference: the search rank reporter architecture

    Same system, drawn purely for engineers. Service names, region, Lambda inventory, IAM scopes, the schemas and the exact model id.

What is a search rank reporter?
A small serverless system that reads your own search performance data, groups thousands of query rows into a handful of themes, and reports movement large enough to be real. It works from your own measured data rather than from simulated searches.
Why not scrape search results?
Because scraped positions are personalised, localised, and against most search engines’ terms. Your own performance data is the average position real people saw, which is both more accurate and not a rule you are breaking.
Why group queries?
Because a report with nine hundred query rows is unreadable and mostly noise. Six themes that map to what the business sells are a report somebody reads, and the queries are still there underneath.
Does it say why something moved?
It says what correlates: a page that changed, a page that was added, a competitor appearing. It does not claim causation, because search movement has causes no data you hold can see.
What does it cost to run?
Around a dollar a month. It reads an API weekly. See part six.
All posts