The Ultimate Guide to LinkedIn X-Ray Searches (2026 Update)

If you are looking for the best linkedin xray search tool, the short answer is still Google plus a clean query builder. Start with site:linkedin.com/in/, then add exact titles, locations, and exclusion terms. That is still the fastest open-web method for finding public profiles outside LinkedIn’s own interface. But there’s a catch: this is a precision tool, not a whole sourcing system. One recruiter on Reddit said it better than most blog posts do.

That is the right frame. LinkedIn X-ray search is not magic. It is your sharp tool for awkward searches.

The rest of this article is the original guide, cleaned up, updated for LinkedIn, and trimmed where the old product references got stale.

We already built a working demo

The old article linked to a Proxycurl demo. I replaced it with the compact generator above.

You can use it to generate a LinkedIn X-ray search based on:

• Job title
• Location
• One or two skills
• One exclusion term

For example, find CTOs based in Atlanta with React or Django, but exclude PHP. It is that easy.

Now, back to business.

An overview of some search methods

The first method uses Boolean operators such as NOT, AND, and OR within LinkedIn’s search engine to improve search results.

For example, let’s say you wanted to find and hire a content marketer or content strategist, but you wanted to make sure they were also writers themselves, as well as familiar with SEO standards.

Rather than sifting through thousands of profiles on LinkedIn to find the right prospect, you could use the following search query to instantly find them, "content marketer" OR "content strategist" AND "writer" AND "SEO".

The second method for performing LinkedIn X-ray searches is Googling, but using operators to refine your results. The main difference is that we’re using Google’s search engine to find indexed LinkedIn pages instead of LinkedIn’s search engine.

We also don’t need to be logged into a LinkedIn account to do the second method, hence the name LinkedIn X-ray search, so there’s no need to burn your own account sessions just to test queries. Most people prefer this method because it scales better.

To give you an example, let’s take our earlier example and take a look at the Google search results for LinkedIn content writer and SEO.

Wow, that’s a lot. Let’s use a bit of magic and confine our search results to only LinkedIn:

site:linkedin.com/in/

Better. Now let’s refine that search query further with operators:

site:linkedin.com/in/ ("content marketer" OR "content strategist") "writer" "SEO"

Much better.

That said, in this article, I’ll be explaining how to use both methods to your advantage.

First, though, we need to talk a bit more about Boolean operators.

What are Boolean operators?

A Boolean operator is a word or symbol used in logic and search queries to combine or exclude keywords, resulting in more focused and specific search results. It’s basically like searching on steroids.

Both LinkedIn and Google support the following core Boolean operators:

Quick heads up

We’re about to get into examples of using search operators on LinkedIn and performing LinkedIn X-ray searches on Google. For the examples throughout this article, I’ll assume we’re working in some type of HR role and need to find a given individual to fill a job role.

If that’s not you, don’t overthink it. If you’re in sales or marketing, you can still use these same methods to find prospects for your use case. You just modify the query.

Okay, now let’s put this into practice.

How to use search operators on LinkedIn

On top of Boolean operators, LinkedIn also supports a few other search patterns:

These can further help refine our search results.

First up, the AND operator.

AND operators

So, let’s say we need to find a software engineer who lives in Los Angeles and has experience with both Javascript and Linux.

Here’s how we could use Boolean operators to help us here:

"software engineer" AND "los angeles" AND "javascript" AND "linux"

That gives us profiles that match all of our search criteria.

NOT operators

Let’s say for whatever reason, the company we’re recruiting for doesn’t hire programmers that use Kotlin.

We can refine our search accordingly:

"software engineer" AND "los angeles" AND "javascript" AND "linux" NOT "kotlin"

You’ll see the search narrow slightly. The Kotlin-heavy profiles should disappear.

Filtering with location and putting everything together

We can take this one step further and assume everything above is true, but the company we’re recruiting for has offices in both Los Angeles and New York City.

We can expand our original search by alternating it slightly:

"software engineer" AND ("los angeles" OR "new york city") AND "javascript" AND "linux" NOT "kotlin"

This is where Boolean logic stops being theory and starts saving time.

Searching on LinkedIn vs. Google

It may sound silly, but the main con of searching inside LinkedIn is that you need your own LinkedIn account and you need to be actively logged in.

You’ll also inevitably run into interface limits. This is old news for anyone who has tried to source at volume.

It’s simply not a very scalable method, and you can’t automate it cleanly for the most part.

This is why LinkedIn operators, while useful, are not quite as powerful as using Google to perform a true LinkedIn X-ray search without the same UI friction.

That said, let me show you how to do this in a better way using Google.

Google search operators

On top of AND, OR, and NOT, Google also supports additional search operators:

We can use these operators to our advantage.

How to do LinkedIn X-ray searches

site:linkedin.com/in/ is our starting point. It lets us search Google exclusively for LinkedIn profile results.

Note: if you want companies or jobs instead of people, the URL structure changes. Companies use /company/, for example https://www.linkedin.com/company/microsoft/, and jobs live under LinkedIn’s jobs URLs.

LinkedIn X-ray searches by job role

So, let’s say we want to find a full-stack developer. Here’s how we could do that by using a LinkedIn X-ray search:

site:linkedin.com/in/ intitle:"full-stack developer"

All consisting of LinkedIn profiles having full-stack developer in their title.

LinkedIn X-ray searches by job role and skill

Now, let’s narrow that search down a bit and say we need them to be familiar with both Django and React:

site:linkedin.com/in/ intitle:"full-stack developer" (django OR react)

Excluding skills, roles, or anything from your LinkedIn X-ray search

Next, let’s say we want the same as above, but we want to exclude PHP programmers.

Here’s how we could do that:

site:linkedin.com/in/ intitle:"full-stack developer" (intext:django OR intext:react) -php

That is much closer to what an actual sourcing query should look like.

Location-based filtering with LinkedIn X-ray searches

One way to do this is by simply adding the location into the search:

site:linkedin.com/in/ intitle:"full-stack developer" "new york city" (django OR react) -php

You can get more specific too:

site:de.linkedin.com/in/ intitle:"full-stack developer" "frankfurt" (django OR react) -php

Not bad.

Extracting your LinkedIn X-ray search results

Ideally, we want to automate and systemize as much as possible. Especially if you’re doing this at scale for recruiting.

To help accomplish this, we can use a tool like ValueSERP, which is a search engine result page API. Its job is to scrape search result pages at scale and return the data.

At the time of writing, public pricing pages still reference plans starting around $2.50 per 1,000 requests. Cheap enough for experimentation, assuming your workflow downstream is worth something.

This helps avoid future issues like CAPTCHAs or getting blocked if you try to brute-force Google the dumb way.

You can then export these results to a .CSV and process them downstream.

This is where LinkedIn X-ray searches truly shine: the programmatic nature of it, compared with traditional LinkedIn prospecting methods.

How to enrich LinkedIn profiles

You now have a way to search for qualified prospects that meet specified criteria. You know how to search for LinkedIn profile URLs at scale and export the results without UI limitations.

But a LinkedIn profile URL alone doesn’t do us much good.

Sure, you could click that URL and then manually send them a connection request and try to message them. However, I would usually want their email and phone number for better touchpoints. All 3 if possible.

So, what’s an easy way to do that?

There are now two ways to think about this section:

1. The legacy Proxycurl way, if you are maintaining old workflows or old code.
2. The NinjaPear way, if you want the current product path.

The NinjaPear path

If I were doing this today, I would not build the workflow around LinkedIn scraping infrastructure from scratch unless I absolutely had to.

I would use NinjaPear where it fits, especially for the enrichment layer and for workflows that begin from company, customer, or competitor data instead of profile URLs.

This part matters, so let me say it plainly: NinjaPear does not scrape LinkedIn, and it does not enrich LinkedIn profiles from a LinkedIn URL. That is a feature decision, not an omission.

Instead, NinjaPear gives you person and company enrichment from public web sources using cleaner inputs:

• for a person profile, bring a work email, or a role + company, or a name + company
• for a company profile, bring the company website or domain

That means if your workflow begins with https://www.linkedin.com/in/..., NinjaPear is not a drop-in LinkedIn URL enricher. If your workflow begins with a real business identity signal, which in my experience is usually the smarter starting point anyway, NinjaPear is much more useful.

The first relevant product here is Prospector. It is basically a spreadsheet with superpowers. You can start from a company domain, pull competitors, pull customer lists, search employees, and enrich work emails without having to juggle a CSV circus.

That matters because a lot of teams do not actually need “LinkedIn X-ray search” as an end in itself. They need a list of target accounts, the right people at those accounts, and a way to contact them. Different problem. Better solved upstream.

The second relevant product is NinjaPear’s Employee API and Company API stack, which can enrich person and company data from public web sources without forcing your whole workflow to depend on LinkedIn page URLs.

And this is the part most people miss: NinjaPear’s Employee API does a big chunk of the practical work people use a linkedin xray search tool for in the first place. If your real question is not “how do I search Google better?” but “how do I find the right employees at target companies?”, Employee API is usually the more direct route.

In practice, that means you can:

• start with a company website
• search employees by role or seniority
• pull a person profile from work email, role + company, or name + company
• enrich the company itself from the website
• add work email lookup

That is a lot closer to an actual recruiting or sales workflow than open-web query tinkering.

If your actual goal is:

• build prospect lists,
• identify decision-makers,
• enrich profiles,
• get work emails,
• monitor account activity,

then NinjaPear is the modern route.

If your actual goal is specifically “I need a Google query that finds public LinkedIn profiles,” then keep reading. X-ray search still has its place.

That comment is blunt, but correct. Most people do not want a clever query. They want a list that is ready to use.

The legacy Proxycurl path

I’m keeping this section because the original article had useful implementation detail, and some readers still maintain old Proxycurl-based flows.

But to be explicit: Proxycurl has been sunset.

Proxycurl’s Person Profile Endpoint

One of the key endpoints of Proxycurl was the Person Profile Endpoint, which allowed you to extract data from public LinkedIn profiles such as education, employment, skills, and everything you would find on a LinkedIn profile.

The broader lesson still holds: once you have profile URLs, you can enrich them and turn search results into structured data.

Using Proxycurl’s API for enrichment

In the original version of this article, I showed a Python example that took a LinkedIn profile URL and enriched it through Proxycurl’s API.

That workflow looked roughly like this:

import requests

api_key = 'Your_API_Key_Here'
headers = {'Authorization': 'Bearer ' + api_key}
api_endpoint = 'https://nubela.co/proxycurl/api/v2/linkedin'
params = {
    'linkedin_profile_url': 'https://www.linkedin.com/in/russellbrunson/',
    'extra': 'include',
    'github_profile_id': 'include',
    'facebook_profile_id': 'include',
    'twitter_profile_id': 'include',
    'personal_contact_number': 'include',
    'personal_email': 'include',
    'inferred_salary': 'include',
    'skills': 'include',
    'use_cache': 'if-present',
    'fallback_to_cache': 'on-error',
}

response = requests.get(api_endpoint, params=params, headers=headers)
print(response.text)

I’ve compacted this on purpose. The original article had several long code listings, but the core point was never the boilerplate. The point was that once you have the LinkedIn URL, you can enrich it programmatically.

How to easily enrich LinkedIn profiles at scale

The same applied in bulk. You could read profile URLs from a .CSV, hit the enrichment endpoint, and write the results to a new .CSV.

That old workflow still describes the shape of the problem correctly:

• find URLs,
• enrich them,
• export them,
• route them into outreach or CRM.

It is just no longer the product path I would recommend starting fresh with.

Search inside a dataset instead

The original article also covered Proxycurl’s Person Search Endpoint, which let you search a structured profile dataset directly instead of first discovering profile URLs through Google.

That idea is still important. If you already have a person dataset, searching the dataset is almost always cleaner than scraping the open web and then enriching after the fact.

This is also where NinjaPear is more interesting in 2026.

With NinjaPear, I would increasingly start from the company side, then move to people:

• start with a domain or target account list,
• pull competitors or customers,
• search employees,
• enrich work emails,
• optionally monitor the company for changes.

That is a more commercially useful pipeline than “Google query first, figure out the rest later.”

Comparison: three ways to do it

If you are deciding between LinkedIn search, Google X-ray, and a structured data platform, here is the blunt version.

I’m biased here, obviously. But the bias comes from spending years watching teams confuse a sourcing trick with a sourcing system.

LinkedIn X-ray search is a trick. A useful one. NinjaPear is closer to a system.

If you are entirely uninterested in coding

The original article had a no-code section because, frankly, most people reading this do not want to maintain Python scripts forever.

That point remains true.

If you want a no-code route today, the cleanest modern path is to use Prospector. Start with a domain, expand to competitors or customers, search employees, then add work-email enrichment as a column.

That is a lot less annoying than stitching together Google, a SERP API, a CSV export, and a separate enrichment step.

Additional tips

A few things that still matter if you are doing LinkedIn X-ray search in 2026:

1. Use exact phrases first. "VP Sales" beats VP Sales.
2. Prefer Google exclusions over wishful thinking. -recruiter -jobs -hiring often cleans up garbage fast.
3. Use country-specific subdomains when relevant. site:de.linkedin.com/in/ or site:uk.linkedin.com/in/ can help.
4. Do not assume every public profile is fresh. Indexed does not mean current.
5. Do not mistake discoverability for contactability. Finding a profile is step one, not the outcome.

You now have three options

1. You can take your newly gained knowledge and do nothing with it.
2. You can take your newly gained knowledge about LinkedIn X-ray searches and implement it manually.
3. You can use a linkedin xray search tool where it helps, then move the rest of the workflow into a proper system.

If you are starting from scratch in 2026, I would do #3.

Use the generator above to build your query. Test whether the open web actually surfaces the profiles you need. If it does, good.

If you then need enrichment, list-building, work emails, or company monitoring, move that work into NinjaPear instead of building a brittle pile of scripts around a sourcing trick. Come in with a work email, name + company, role + company, or a company website. That is how NinjaPear wants to work, and honestly, that constraint usually improves the workflow.

If you want the more modern path, start with NinjaPear. If your real use case is “find the right people at a target company,” Prospector and NinjaPear’s Employee API will get you further than a pure LinkedIn X-ray workflow. If you specifically need to monitor target accounts for timing signals after you build the list, Company Monitor is the natural next step.

LinkedIn X-ray search is still useful. It is just no longer the whole game.