Title Expansion: Why Generic Job-Title Search Fails for Specialized Roles

A keyword search for one job title misses most of the people who actually do that job. Type "HVAC specialist" into a people search and you get back designers, when the role you are filling is an engineer. One European engineering firm we spoke with hit exactly this, and their fix was to stop searching for the title in their head and start searching for every title the market actually uses for that work. They generate the full set of equivalent names first, then run the search.

This guide is about that first step, which we call title expansion. You take one canonical role and turn it into the set of real-world titles that mean the same thing, so a keyword title search stops missing the people who match. We will go through why a single-title search fails on specialized roles, how to build the expanded title set (by hand, from a known-good profile, or with an AI and a reference taxonomy), and how to run that expanded set against a people search API with one query. The code uses Crustdata's People Search API, one of the best candidate enrichment APIs for this kind of work, and you can try the same workflow on a free account with 100 credits to start.

Why does a single job-title search miss most candidates?

The title in the job description is rarely the title on the profile. A company that needs someone to size and route process piping in a data center might write the role up as "HVAC specialist," while the people who do that work call themselves piping engineers, mechanical designers, process engineers, or a dozen other things depending on the country and the employer. Search for the one title you wrote down, and you only catch the small slice of people who happen to use your exact words.

On common roles this is annoying but survivable. A search for "account executive" still returns thousands of people, even if it misses the ones listed as "enterprise sales" or "named account director." On specialized roles it is fatal, because the pool is small to begin with and your one title only sees a fraction of it.

The firm we spoke with put the failure plainly. When they searched their endpoint for a specialized function title, the results came back as the wrong discipline. In their words, an HVAC specialist "is more an engineer than a designer, but your application will give you more designers." The title string was close enough to match designers and too narrow to reach the engineers they wanted. A flat keyword search has no way to know that a "specialist" in their world is an engineering role, so it matched on the surface words and returned the wrong people.

That is the core problem. A title is a label a person chose for themselves, and labels for the same work scatter across many strings. So the search you want is never "find this title." It is "find everyone whose title is any of the ways people describe this role."

What is title expansion, and how is it different from normalization?

Title expansion is the practice of turning one canonical role into the set of equivalent and adjacent titles that describe the same work, so you can search for all of them at once. You start with "HVAC specialist" and you end with a list: mechanical engineer, piping engineer, process engineer, building services engineer, mechanical designer, and so on. Then you search for the whole list.

This is a different job from normalization, and the two get confused. Normalization cleans up messy values that already exist on profiles, so a filter for "Python" also catches "Python3", "python programming", and "Python (Programming Language)". The difference is the direction of the work. Normalization collapses many spellings of one value into a canonical form. Title expansion goes the other way, taking one canonical role and fanning it out into the many distinct titles that the market uses for it.

You often need both. Expansion gets you the right set of titles to look for, and normalization makes sure each one of those titles matches across its own spelling variants. This article is about the expansion half, where most specialized searches go wrong before normalization ever gets a chance to help.

How do you build the expanded set of titles?

There are three ways the teams we spoke with built their title set, and they suit different situations. Each one is a way of answering the same question, which is "what does the rest of the world call this role?"

Start from a known-good profile

The fastest way to expand a niche role is to point at one person who already does it. A boutique executive-search firm we spoke with works this way constantly. When they have a placement they are proud of, they use that person as the template for the next search. One of them described it as throwing a bellwether profile into the tool and asking for "as many close profiles" as it can find.

They had a shorthand for it. When a client wants someone like a strong seller they had placed before, the task becomes finding as many close matches to that benchmark person as fast as possible. The known-good profile carries the titles, the seniority, and the kind of company that defines the role, which saves you from writing the expanded list yourself. You read the titles off the example person and the people around them, and those become your search set.

This works best when you have a real example in hand and the role is hard to describe in the abstract. It is weaker when you are opening a brand-new kind of role and have no one to point at yet.

Generate the set with an AI and a reference taxonomy

The most repeatable approach the teams we spoke with used was to generate the title set with an AI working from a reference of the actual work. The engineering firm built a database of what each kind of profile can do, the real tasks and responsibilities behind a role, then fed that reference to an AI and let it return the title names that map to it. In their words, they "made a database and we have a reference of all the action what can do a profile, and we put it in AI, and it gave us all the different names, and it's what we inject in your API."

The reference taxonomy is what makes this reliable. An AI asked cold for "titles like HVAC specialist" will guess, and it will guess generically. An AI grounded in a description of the actual tasks for the role returns titles that match the work rather than the words, which is exactly what a flat keyword search cannot do. The output is the expanded set you feed into the search.

This is the strongest approach when you hire for the same families of specialized roles repeatedly, because the reference is reusable. You build the description of the work once, and every future opening for that role family reuses it.

Discover real indexed titles with autocomplete

The third way grounds your set in titles that actually exist in the data, rather than ones you imagine. Before you commit to a filter value, you can check which title strings the index actually holds. Crustdata exposes a Person Autocomplete endpoint for exactly this, so you can type a partial title and see the real values you can filter on. It keeps your expanded set honest, because a title that returns nothing in autocomplete will return nothing in the search either.

In practice you combine these. You start from a known-good profile or an AI-generated set, then check the candidate titles against what the index really contains, and drop the ones that match nobody.

How do you search the expanded title set in one query?

Once you have the set of titles, you do not run one search per title. You run a single search that matches any title in the set, using a people search API that supports regex-style title matching. This is where the expanded list pays off, because it collapses into one query instead of a dozen.

With Crustdata's Person Search, the title field is experience.employment_details.current.title for current roles, and the (.) operator does a case-insensitive regex match. The pipe character means "or", so a single value of Mechanical Engineer|Piping Engineer|Process Engineer|HVAC Engineer|Mechanical Designer matches any profile whose current title contains any of those phrases. That one filter is your whole expanded set.

The direct-API path

If you have engineers, you build the query yourself and keep full control over the title set and the surrounding filters. The example below takes an expanded set of specialized engineering titles and pairs it with a geographic radius around a city, which is how the engineering firm we spoke with searched, because their roles are tied to a build site. The geo_distance filter finds people within a set distance of a location, so you can ask for the right titles within commuting range of the project in one request.

curl --request POST \
  --url https://api.crustdata.com/person/search \
  --header 'authorization: Bearer YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --header 'x-api-version: 2025-11-01' \
  --data '{
    "filters": {
      "op": "and",
      "conditions": [
        {
          "field": "experience.employment_details.current.title",
          "type": "(.)",
          "value": "Mechanical Engineer|Piping Engineer|Process Engineer|HVAC Engineer|Mechanical Designer|Building Services Engineer"
        },
        {
          "field": "professional_network.location.raw",
          "type": "geo_distance",
          "value": { "location": "Brussels", "distance": 40, "unit": "km" }
        }
      ]
    },
    "limit": 100
  }'

curl --request POST \
  --url https://api.crustdata.com/person/search \
  --header 'authorization: Bearer YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --header 'x-api-version: 2025-11-01' \
  --data '{
    "filters": {
      "op": "and",
      "conditions": [
        {
          "field": "experience.employment_details.current.title",
          "type": "(.)",
          "value": "Mechanical Engineer|Piping Engineer|Process Engineer|HVAC Engineer|Mechanical Designer|Building Services Engineer"
        },
        {
          "field": "professional_network.location.raw",
          "type": "geo_distance",
          "value": { "location": "Brussels", "distance": 40, "unit": "km" }
        }
      ]
    },
    "limit": 100
  }'

curl --request POST \
  --url https://api.crustdata.com/person/search \
  --header 'authorization: Bearer YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --header 'x-api-version: 2025-11-01' \
  --data '{
    "filters": {
      "op": "and",
      "conditions": [
        {
          "field": "experience.employment_details.current.title",
          "type": "(.)",
          "value": "Mechanical Engineer|Piping Engineer|Process Engineer|HVAC Engineer|Mechanical Designer|Building Services Engineer"
        },
        {
          "field": "professional_network.location.raw",
          "type": "geo_distance",
          "value": { "location": "Brussels", "distance": 40, "unit": "km" }
        }
      ]
    },
    "limit": 100
  }'

Every title in the expanded set sits in that one value string, separated by pipes, so adding a newly discovered variant is a one-line change. The geo radius keeps the result local, and you can tune the distance to the role. The firm that searched this way told us that across roughly 2,000 searches run this way, only two came back with a wrong location, so the precision held up once the title set was right.

A note on the field. Use experience.employment_details.current.title to match only the person's current role. If you want to catch people who held the title recently but have since moved, use experience.employment_details.title, which searches their full title history.

The MCP path, for teams without engineers

If you do not want to write the query, you configure Crustdata's MCP server in Claude and describe the search in plain language. The agent builds the title regex and the radius filter for you, and the expansion step becomes part of the conversation. Both firms we spoke with ran their searches this way, by talking to Claude rather than calling the API directly.

A prompt that does the whole job reads like this:

Using Crustdata's in-database people search, find people whose current title
is any of: mechanical engineer, piping engineer, process engineer, HVAC
engineer, mechanical designer, or building services engineer. Limit to people
within 40 km of Brussels. Return 100 results with their profile links

Using Crustdata's in-database people search, find people whose current title
is any of: mechanical engineer, piping engineer, process engineer, HVAC
engineer, mechanical designer, or building services engineer. Limit to people
within 40 km of Brussels. Return 100 results with their profile links

Using Crustdata's in-database people search, find people whose current title
is any of: mechanical engineer, piping engineer, process engineer, HVAC
engineer, mechanical designer, or building services engineer. Limit to people
within 40 km of Brussels. Return 100 results with their profile links

The agent expands the titles into the regex or filter, attaches the radius, and runs the search. You can iterate in the same window, adding a title you missed or tightening the radius, and the executive-search firm told us this iterative refinement is most of how they work. The underlying data is the same on both paths, so the only real decision is how much of the query you want to write yourself.

How do you keep the expanded search precise?

Expansion widens the net, which means it also lets in people you do not want. A title set built for "HVAC specialist" that includes "mechanical designer" will catch designers you were trying to avoid in the first place. So expansion and narrowing are two halves of one workflow, and the narrowing matters as much as the widening.

The cleanest way to narrow is to exclude the titles and companies you know are wrong, rather than trying to make the include list perfect. Crustdata's not_in operator removes any profile where a listed title appears in their history, so you can drop interns, junior variants, or an adjacent discipline that keeps leaking in. The executive-search firm leaned hard on exclusions, cutting people from specific employers and company types that never produce the profiles they place. Once your title set is right, the rest of the work is trimming the result down by layering exclude filters over your include list.

The other precision check is to ground every title in real data before you trust it. A title you invented that matches nobody costs you nothing, but a title that matches the wrong discipline quietly fills your results with the wrong people. Checking candidate titles against autocomplete, and reading the first page of results for any title you are unsure about, catches that early.

What does title expansion actually change?

The teams we spoke with were after the same outcome, which was to cut sourcing time sharply on roles that used to take weeks. The engineering firm needed to staff a build with hundreds of specialized people on a deadline, and the difference between a single-title search and an expanded one was the difference between a handful of matches and a real pool. The executive-search firm framed success as doing the work of a ten-person sourcing team with a handful of people, and fast title expansion off a benchmark profile is most of how they get there.

What expansion changes is where your search starts. Instead of guessing the one right title and hoping the market agrees with you, you start from the work and gather every title the market uses for it. The keyword search stops being a bet on your phrasing and becomes a search over the actual language of the role. On a common title you might never notice the gain. On a specialized one, it is the difference between finding the people and not.

So if you want to start, start with one role you hire for often. Write down the canonical title, then build the expanded set three ways and compare them: read the titles off your best past placement, ask an AI grounded in a description of the real work, and check both against the indexed values. Run the expanded set as one query, read the first page, and cut the titles that brought in the wrong discipline. You will have a reusable title set for that role family by the end of the afternoon.

Crustdata is the data layer for recruiting teams building their own sourcing on top of an API. So come and see what an expanded title search returns across your own hard-to-fill roles. Book a demo, or start free with 100 credits at crustdata.com.

Frequently asked questions

What is title expansion in candidate search? Title expansion is turning one canonical role into the set of equivalent and adjacent job titles that describe the same work, so a single search catches everyone who does the job rather than only the people who use your exact title. You generate the set, then search for all of the titles at once.

Why does searching for one job title miss qualified candidates? Because the title in your job description is rarely the title on the profile. People label the same work in many different ways, so a search for one string only reaches the slice of people who happened to use your wording. On specialized roles, where the pool is small, that slice can be a tiny fraction of the real candidates.

How is title expansion different from search normalization? Normalization collapses many spellings of one value into a canonical form, so "Python3" and "python programming" both match a search for Python. Title expansion goes the other way, taking one role and fanning it out into the many distinct titles the market uses for it. Expansion finds the right titles to look for, and normalization makes each one match across its spelling variants.

Can I expand titles without writing code? Yes. With an MCP server configured in Claude, you describe the role in plain language and the agent builds the title regex and runs the search. You can also generate the expanded set by asking an AI to list equivalent titles for the work, then paste those into a search tool.

How do I keep an expanded title search from returning the wrong people? Pair the widened include list with exclusions. Use a not_in filter to drop titles and companies that keep leaking in from an adjacent discipline, check candidate titles against autocomplete so you only search for values that exist, and read the first page of results to catch any title that matched the wrong role.