Why one search query only ever finds 50 people: 900 live measurements

Every guide to finding people with a site:linkedin.com/in query teaches the same two moves. Write a better Boolean string. Then page through the results.

We measured both, across roughly 900 live searches on 4 and 5 August 2026. The first move matters less than the guides claim. The second one does almost nothing at all.

One query saturates at 30 to 50 people. Not because the best matches sit at the top and quality decays with depth, but because there is no depth. Twelve pages of a single query returned 37 people in total, and pages five through eleven added one person between them. Getting past that number has nothing to do with writing a better query. It has to do with asking a different question.

What we measured

Roughly 900 live calls to a commercial search API, over two days, against public profile pages. Every technique ran at least three times. Whether a result was on target was judged by a model against a written description of the buyer, using one prompt for every arm, so the comparisons are like for like.

Two honest framings before the numbers. This measures one commercial search API sitting in front of a general web index. A few findings below are properties of that intermediary rather than of the index, and we say which ones. It also measures public profile pages, the version published deliberately for search engines, and nothing behind a login.

One search query saturates at 30 to 50 people

Whatever you do to a single query, it tops out somewhere between 30 and 50 distinct people. Depth is not where the results are. Every arm that added pages returned less and less. Every arm that added queries returned close to a full page of new people, each time.

At equal spend, widening beat paging by 2.5 to 3.4 times on unique people who matched the role.

The commonly repeated figure in sourcing guides is that a single x-ray query yields somewhere in the low hundreds of profiles. We could not reproduce anything close to it, on any query, in any market, at any depth.

The likely mechanism is not a secret. Google has long documented that it filters out entries "very similar to the search results already displayed". Its own guidance describes offering a link to repeat the search with those entries put back (Google Search Appliance documentation, duplicate result filtering). A page of public profile pages is, structurally, a page of very similar entries. The filter that makes ordinary search readable is the same filter that caps this one.

Two lines showing cumulative distinct people found against searches spent. Paging one query flattens at 37 people, with pages five to eleven adding one person between them. Running one query per job title rises in a straight line to 80.

The page number is barely a cursor

You would expect page 3 of a query to be a different set of people from page 1. It mostly is not. Across 21 fetches of one query spanning pages 1 to 12, only 10 distinct result sets came back, and one of them came back seven times. Two fetches of the same page differed about as much as two fetches of different pages.

Google repeats itself openly too: 23% of the raw results on page 2 were byte-identical URLs from page 1.

So the page parameter is closer to a suggestion than a cursor, and the practical rule we now follow is to never page past 2. Everything after that is paid for and already in hand.

Slicing is the only way past it, and the slices barely overlap

The obvious worry about slicing is that a second way of cutting a market re-finds the first one's people. It does not. Six job titles across ten cities returned 532 people. The same six titles across ten first names returned 578. Only 38 people appeared in both lists.

Seven percent overlap, a union of 1,072 people from 120 queries, roughly twice what either axis reached on its own. Axes compound, and that is the whole reason this works.

Two barely overlapping circles. Slicing six job titles by ten cities found 532 people, the same titles by ten first names found 578, and only 38 appeared in both, for a union of 1,072.

Here is every axis we tested, three times each. The first column is the share of people it returned that a plain search had not. The second is what a model judged on target.

Two rows are worth a second look. A job title written in another language, searched in a country where that is not the local language, returned 100% new people at 100% precision. And a negative term is the weakest axis on the board: it removes rather than adds, which is what the 58% is telling you.

Compounding is also what makes a repeat search worth running, and it is the part most saved searches get wrong. Running the same search next week returns the same people. Running the next slice does not.

A saved search that re-runs rather than advances will report an empty market it never looked at.

How far the pool actually goes

Further than we expected. 300 queries returned 2,552 distinct people, at 8.5 people per call, with no sign of flattening at the end of the run. The last 30 queries were still finding 258 new people, against 280 for the first 30.

The useful shape of that result is where the ceiling sits: on the query, not on the market. The pool is bounded by how many such people exist. Give a plan enough axes and it keeps finding them, long after intuition says the market ran dry.

Geography: one control works and the other is a placebo

The country subdomain in the site restriction is the only geography control that works, and it works completely. Searching site:fr.linkedin.com/in/ put 135 of 135 hits inside the target country. With no control at all the in-country rate was zero. Not low, zero: 0 of 19.

A country parameter on the search call and a location word in the query text are both real, and both redundant once the subdomain is present. Prefer the subdomain. It is the shortest form that works, and shortness turns out to matter.

One practical trap: the namespaces disagree with each other. Public profiles use uk for the United Kingdom and put the United States on www, while Google's country parameter wants gb. A converter at each boundary is not optional.

Google's interface-language parameter (hl) is the interesting one, because it looks contradictory until you separate two questions. It does nothing for geography: 80.0% of results were in-country with it unset against 81.9% with it set, a difference well inside noise at z = -0.39. It is a real slice: on an identical query string, 79% of what one language setting returned was absent from the other.

Interface language moves the result set without moving the country. Treat it as a free extra axis, and never as a geography filter.

Recency cannot be requested at all

The date filter is accepted, returns a success code, and is ignored. We asked for four different windows on the same searches and got back the same ageing results every time.

Note that "past month" returned older results than no filter at all. That is not a finding, it is noise on 14 results per condition, which is exactly the point: the parameter is doing nothing.

The consequence is bigger than the inconvenience. A public post index is not a fresh signal. The median indexed post we saw was 338 days old and four in ten were over a year, so any recency requirement has to be applied after fetching, not requested before it. We cut at 180 days on our side. Job postings are the only public source that is dated by nature, which is a large part of why hiring is such a reliable trigger.

What the operators are actually worth

Most of the Boolean advice in circulation is either neutral or actively costly. We paired every operator against a plain quoted phrase on the same target and the same country, and only two of them earned their place.

The industry row is the expensive mistake, and the reason is obvious once measured: almost nobody writes their industry taxonomy label in their headline. You are ANDing on a word your target does not use.

One more rule, and it comes from the failure modes rather than from precision. Longer queries are riskier, because a longer query is likelier to trip the silently dropped site restriction described below. When two forms score the same, ship the shorter one.

A public profile page does not carry a job title

The title a public profile page publishes is the person's name and their employer. It is not their headline. That surprised us more than anything else here, and it explains a bug people report as "why does this lead show a brand name where a role should be".

Across 50 live public profiles, the fetched title equalled the company name in 45 of them and rendered a location string in the other 5. Not one of them was the person's headline. We also saw a page return a former role outright, "Angel Investor", for somebody whose real headline names a current VP Sales job.

The fix is free and it was already on the page you searched. The search result title carries a real role in 84% of cases and is present on essentially every hit. Ranking happens on that title, before anything is fetched, which is what makes working with a pool of several hundred people affordable in the first place.

Comment threads are the exception. A public comment carries no headline at all, so there is no search result title to read. One targeted lookup of that person's own profile URL fixes it, and it lands at rank 1: measured 34 times out of 34. The About section is not a substitute. It is absent on 38% of profiles and hard truncated at a median of 84 characters. The mechanics of working from comment threads are in how to export LinkedIn post commenters.

The failures are silent, and one of them is common

Two failure modes, and both of them return a success code. Neither is visible without a deliberate check, which means every one of them reaches a person as a wrong answer rather than as an error.

An empty result set with a success code. 9.8% of calls, against 1.0% for outright HTTP errors. They arrive in clusters rather than at random: one page came back empty on three consecutive attempts inside about six seconds, then returned ten results. An earlier retry schedule that gave up after 1.6 seconds was reporting queries that had results as having none. Three retries with the last wait at five seconds cost 1.09 calls per search on average, and took the per-search failure rate from 9.4% to zero.

The site restriction is silently dropped. Roughly one call in five. It is nondeterministic rather than a property of the query: the same scoped query returned ten profiles on one attempt and, two seconds later, a French glossary of car registration codes.

The obvious detector for that second one is not good enough. Asking whether any result merely mentions the host lets a quarter of the failures through, because a junk page can carry a single link to the host that is not a profile. What works is asking whether the page contained any of the thing you came for, plus one blunt signal: page shortness. Every page that came back with fewer than ten result rows carried zero profiles, across two independent samples, while full pages essentially always did. After adding that check, 0 of 18 searches returned zero profiles.

Why one trial said the opposite of the truth

The most consequential thing we learned was not about search at all. On a single trial each, six slice techniques that work scored 0% on target and looked useless. They were fine. The search API had dropped the site restriction on those particular calls. Repeated three times each with the detector in place, the same six scored between 83 and 100%.

A single trial against a 20% nondeterministic failure rate does not measure your technique. It measures the vendor. That is as true in a browser tab as it is in a test harness. So treat any confident claim about which Boolean operator wins as unproven until you know how many times it was run. Every row in the table above was run three times.

Four rules came out of it, and they are cheap:

1. Repeat every measurement at least three times.
2. Pair comparisons on the same cells. An unpaired comparison across a 20% failure rate measures the failure rate.
3. Count degraded pages separately and say so, rather than folding them into a rate.
4. Say plainly when a result is within noise. Two of the numbers on this page are, and we have said so.

What this changes if you are the one searching

1. Stop at page two. In our runs, pages 5 to 11 of a query added one person between them, and every one of those calls cost the same as a fresh query.
2. Add an axis instead of a page. A city, a first name, a synonym, a sector word, a school, a piece of software the person would use, the same job title written in another language. Each one returns roughly 90 to 100% people the plain search did not.
3. Keep a cursor, not a query. Re-running a search returns the same people. Advancing to the next slice returned 96 to 98% new ones, three weeks running.
4. Let a model name the target and let code write the query. Query construction is mechanical and models are bad at it. Raw model-authored query text returned zero profiles in our runs. A model-derived list of job titles, turned into queries by code, returned 99% on target.
5. Never build a query out of the sentence somebody typed. Asked who the ideal customer was for their own website, one such query went looking for the asker's own company name. It found 35 people and none of them in the right role. A question is not a description of anybody.
6. Read the site before you guess from the domain. Handed a domain with the page unread, a model took the name apart and invented a business. It read our own domain, bereach.ai, as bereavement and proposed Grief Counselor and Funeral Director. Handed 2,000 characters of the actual homepage, the same model answered Head of Sales and Account Executive.

To see this working without building anything, the free people search runs on the same public layer with nothing connected. The free company search does the account-first version. Neither needs a login, because both read the same public pages measured here. The wider case for running the whole research phase this way is in let an agent do the searching for you. For the comparison against LinkedIn's own free search, see free LinkedIn people search for prospecting.

Inside BeReach the same measurements are what the search planner is built on. It plans slices, not a query. Asking for more advances a cursor rather than re-running the one you already paid for, and ranking happens on the search result title before anything is fetched. An outage never reaches you as a verdict on your market.

Method and limits

Stated plainly, because a study that hides its method is a marketing asset rather than research.

• Sample. Roughly 900 live calls to a commercial search API on 4 and 5 August 2026, against public profile pages and public post pages.
• Repeats. Every technique ran at least three times. Comparisons are paired on the same cells wherever the design allowed it.
• On-target judgement. A model scored each returned person against a written description of the buyer, using one prompt across every arm. That is a consistent judge, not ground truth, and it will share the blind spots of the model that produced it.
• Market bias. Most slice measurements ran against one country, France. The geography arms used two countries and three targets.
• Small arms. Some numbers rest on small samples and should be read that way. The recency arm is 14 results per condition, the profile-title arm 50 profiles, the country arm 135 hits, and the post-detector check 18 searches.
• Vendor dependency. The empty-success responses and the dropped site restriction are properties of the commercial search API we buy, not of the underlying index. The saturation ceiling, the page-to-page repetition and the ignored date filter behave like properties of the index.
• What is not published. No personal data. Every figure here is a count of distinct profile URLs, an age in days, or a rate. We do not publish or sell the underlying results.

Cite this study. BeReach, "Why one search query only ever finds 50 people", roughly 900 live public-search calls, 4 and 5 August 2026. The sample definition and the limits are under method and limits on this page, so the arithmetic can be checked from the totals.

Frequently asked questions