Checking search positions: regional results, official limits and honest sizing

Why a single-address measurement shows nothing

Google states plainly what results depend on: location, language, device type, search history and the time of the query. It notes separately that updates roll out across data centres unevenly — so two requests sent in the same minute can hit different versions of the index.

Which leads to a conclusion worth accepting before choosing any tool: there is no single true position. Measuring from one address with no explicit region measures one arbitrary combination and reports it as the site's ranking.

• Region is detected automatically, and with mobile carriers an address need not match the city.
• Mobile and desktop results are counted separately — Yandex Webmaster offers a device-type filter.
• History-based personalisation shapes what an individual user sees.
• Staggered data-centre rollout makes the result dependent on when you asked.

The trap: lr means different things to Yandex and Google

This is the most common bug in home-grown tools, and it yields silently wrong data rather than an error. In Yandex, lr sets the region. In Google, lr sets the document language. Same parameter, entirely different meaning.

# Yandex: lr is the REGION. 213 = Moscow.
# The parameter is absent from the user-facing help but appears in Webmaster
# documentation examples — so it cannot be treated as a stable contract.
https://yandex.ru/search/?text=QUERY&lr=213

# Google: lr is the LANGUAGE, not the region. A direct collision with Yandex.
lr=lang_en        # restrict document language
gl=us             # BOOSTS that country's results, does not restrict to them
cr=countryUS      # this one actually restricts
hl=en             # interface language

# googlehost is marked deprecated; use gl instead.
# uule has no official documentation at all.

One more thing about lr on Yandex's public results: it is absent from the user-facing help. It appears in Webmaster documentation examples, but it is not declared as a public contract and may change without notice. Setting the region manually through settings is stored in a cookie, so it needs session support rather than just an address.

What the rules say about automated queries

The honest answer here is inconvenient, but you need it before building any collection system. Google classes automated queries against its results as a policy violation and names scraping for rank-checking purposes explicitly. The robots.txt on google.com closes the search path to crawling.

Yandex's terms of use reserve the right to cap the number of requests over a period and to prohibit automated access to its services. Under a stream of uniform requests the service presents a check that distinguishes a person from a program.

What is permitted, and what to use

For your own site's rankings the right tool is the engines' own consoles. Yandex Webmaster shows positions filtered by region and device type; Search Console reports query data with the caveat that results depend on the searcher's time, place, device and recent history.

For programmatic access Yandex offers a Search API with published quotas. It runs on Yandex's search base, so the data is comparable to ordinary results.

Yandex Search API — published limits

  synchronous requests   10,000 per hour, 10 per second
  deferred requests      35,000 per hour, 10 per second
  results per request    up to 250
  deferred mode          from 5 minutes, results kept for 12 hours

Google's programmatic access works differently, with two caveats that matter. First, the Custom Search JSON API is closed to new customers and existing ones face a migration deadline in early 2027. Second and more important: it is not the same corpus. The documentation states that results exclude some ordinary web-search features, personalisation among them, and that the index may be a subset when more than ten sites are configured. Presenting it as a substitute for rank checking would be wrong.

Where several addresses genuinely help here

Not for staying unnoticed. The honest list is shorter and more specific.

• Checking how your own site responds and what it shows a visitor from another country.
• Confirming regional page variants and hreflang reach the audiences they target.
• Verifying that advertising displays correctly by region.
• Working in parallel with external sources that enforce a per-address rate limit.

In every one of these, addresses serve geographic correctness and parallelism — so a request leaves from where it should, and so jobs do not queue up behind each other. That is a measurable engineering need, unlike promises of undetectability.

Sizing the volume

Load is a multiplication, and it is worth doing before choosing a tool — often the volume fits inside API quotas and no collection system is needed at all.

requests/day = keywords × regions × engines × devices × runs per day

500 keywords × 3 regions × 2 engines × 2 devices × once daily
  = 6,000 requests per day

Plus a pagination multiplier: depth ÷ results per request.
  Top-100 at 10 results per page -> ×10 = 60,000 calls per day
  Top-100 at 250 results per call -> ×1  = no pagination at all

Here the honesty boundary begins. You cannot divide that load by an allowed number of requests per address: no such officially published number exists for either Yandex or Google, and any figure here would be invented. What can be computed exactly is the ratio to published API quotas: six thousand requests a day fit inside one hour of Yandex's synchronous quota and use under a tenth of its per-second ceiling.