Collecting search results without distorting them

If you have ever pulled a page of search results, put it in a spreadsheet, and treated it as the truth, this post is a small warning.

A search result is not a stable object sitting on a shelf. It is an answer to a question, and the answer depends heavily on who is asking and from where. Two people can search the same term at the same second and see different pages in a different order. Neither of them is looking at a bug. That variation is the product working as designed. The problem is that when you collect results, you have to decide which of those many possible pages you actually wanted, and then hold that decision steady across every request.

What actually moves a result

There are three forces that reorder a page, and it helps to name them separately.

The first is location. Where the request appears to come from changes what is considered local, which listings surface, which language is assumed, and sometimes which competitors even appear. A query for a service, a store, or a product often produces a substantially different page from one city to the next, let alone one country to the next.

The second is personalization. Prior activity, an account, a history of clicks — these nudge results toward what the searcher seems to like. This is the force you almost always want to switch off when collecting data, because it makes every sample a little bit about the collector and a little less about the market.

The third is time and load. Results drift over a day, tests get run, pages get recomputed. You can’t remove this one, but you can stop pretending it isn’t there by timestamping everything and sampling more than once.

The question to ask before every collection run is simple: whose search am I trying to reproduce, and have I removed everything that is about me rather than about them?

Collect the un-personalized view

For most rank and visibility work, the goal is the neutral local page — what a fresh searcher in a given place would see, with no personal history attached. That means no logged-in account, a clean session, and a request that carries no baggage from earlier runs. If you skip this, you get a page shaped partly by your own collector’s behavior, and that distortion is invisible in the output. It looks like data.

The practical version of this is boring but important. Keep sessions clean. Don’t let one query’s context bleed into the next when you are trying to measure a place rather than a person. Treat every sampled page as one observation of a moving thing, not a fact.

Match the geography you actually care about

Once personalization is off, location becomes the dominant variable — and the one you can turn into a deliberate choice instead of an accident.

If you care about how a term ranks for people in a specific city, you need requests that genuinely originate near that city. Country-level is often not enough. A national view averages over places that don’t actually see the same page, and the average describes nobody. When the work is local, coarse geography quietly lies to you.

This is where precise targeting earns its place. Platinum is built for exactly this kind of collection: it lets you target down to a city, and even to a specific network by ASN, and it bills per gigabyte, which suits the bursty, sampled nature of rank checks. You are usually pulling a modest amount of data across many carefully chosen vantage points, not moving volume, so paying for what you use fits the shape of the job.

When you want to be granular, a good pattern is to enumerate the geographies you care about, hold everything else constant, and vary only the location. Then any difference in the page is attributable to place, which is the whole point.

When you want the same vantage every time

There is a second, quieter requirement that comes up constantly in longitudinal tracking: you want the vantage point itself to stop moving.

If you are checking a term every day for months to watch a trend, a rotating address introduces noise you can’t separate from real movement. Yesterday’s sample came from one part of a metro, today’s from another, and now a small shift in rank might be the market or might just be that you stood somewhere slightly different. For trend work, that ambiguity is expensive.

A fixed local vantage removes it. Static ISP gives you a dedicated address that stays put, so every sample in the series comes from the same consistent origin. When the vantage is constant, a change in the results is far more likely to be a change in the world. That is the difference between a chart you can trust and a chart you have to caveat.

The two products pair naturally. Use per-city, per-network targeting when you are mapping how a term looks across places, and a fixed local origin when you are tracking one place over time and need the ground to stay still under you.

A short checklist

Before a run, it is worth confirming four things. That personalization is off and the session is clean. That the location genuinely matches the audience you are studying, at the right granularity. That you are timestamping and sampling more than once, so drift is visible rather than assumed away. And that, for anything you plan to compare over time, the vantage point is held constant.

None of this is exotic. It is mostly the discipline of deciding what you are measuring before you measure it, and then not letting your tools quietly change the question.

Keep the collection focused on public results, respect the terms and rate limits of the sites you touch, and treat each page as one honest observation of a moving system. Do that, and the data you keep will describe the market rather than the way you happened to look at it.