How to Source Candidates From Job Boards and Public Profiles

Quick answer: One prompt reads 9 job boards and the public professional web and returns two tables: the companies hiring for a role in your market with salary and requirements where published, and the candidates who have made their work public, with a source link on every row. Describe your ideal customer. Searchbase finds them across Europe in one prompt, with the source on every cell.

Before the steps, the boundary, because this is a topic where tools overpromise. Everything here reads public pages. Public job postings, public professional profiles, public portfolios, public code repositories, public conference speaker lists. Nothing behind a login, nothing behind a paywall, no private profiles, no connection graphs, no email addresses invented from a name and a company domain. If a recruiting tool tells you it has data that only exists behind someone's login, ask how.

That constraint is less limiting than it sounds, because the two jobs recruiters actually need doing are both public.

Step 1. Map the demand before you look for people

Start with who is hiring, which is the part most sourcing tools skip:

"Find companies in Milan and Turin hiring for backend engineers with Python experience in the last 60 days. For each posting give me the company, job title, seniority, posting date, salary range if published, required skills, the job board it appeared on, and the link to the posting."

This is worth doing first for a reason. It tells you who your competition for candidates is, what they are offering, and what the market rate looks like in that city this quarter. If you are recruiting for a client, it is also the whole of the market briefing they are paying you for.

The agent reads 9 job boards plus company career pages, so a role posted only on a company's own site still shows up.

Step 2. Read the plan and set the scope

The agent shows its plan before fetching: search each job board for the role and locations, filter by posting date, open each posting, extract the named fields, deduplicate the same job posted to three boards.

Deduplication is the step worth checking. One opening frequently appears on four boards with four different titles. Ask for a column recording every board it appeared on, and one row per real opening rather than one per listing. Cross-posting breadth is itself a signal about how hard the company is finding the hire.

Step 3. Watch the demand table fill

Rows stream in as postings are read. Salary is the column that teaches you the most and the one that is most often blank, because publication norms vary by market. Italian postings publish a range far less often than Dutch or German ones. The empty cells are a true reading of the market, not a failure of the tool.

Narrow mid-run if you need to: "only postings that publish a salary range", or "exclude agency and staffing listings, I want direct employers".

Step 4. Now find the people, in public

Second prompt, second table:

"Find backend engineers in Milan and Turin with public profiles showing Python and distributed systems work. Look at public professional profiles, personal sites, public code repositories and conference speaker pages. For each person give me their name, public profile URL, current role if it is stated publicly, technologies visible in their public work, city, and a public contact link."

This is sourcing from the surface people chose to publish. An engineer with a personal site, a public repository or a talk at an Italian Python meetup has published a professional record and a way to be reached. That is a legitimate approach path, and it produces better first messages than a database row, because you can reference the actual work.

What you will not get is a full population of every backend engineer in Lombardy. Most people do not publish. The honest output is the subset who did.

Step 5. Read the plan for this one carefully

The plan for a people search should read: search public professional sources, open only public pages, extract only published fields, leave contact blank where nothing is published.

Say the boundary out loud in the prompt if you want it enforced visibly: "only publicly visible profiles, do not infer email addresses". The agent does not guess addresses in any case, but stating it means the plan shows it and your compliance colleague can read the plan.

Step 6. Draft the approach, then send it yourself

From the people table:

"Draft a short first message for each person, referencing the specific public project or talk that made them a fit."

The agent writes drafts and stops. Nothing is sent from here. You read every one, edit it, and send from your own account. Today teams use LinkedIn Recruiter for the messaging layer, and these drafts move into whatever you already use.

What you get back

Two tables. The demand table has one opening per row: company, title, seniority, date, salary range, requirements, boards, link. The candidate table has one person per row: name, public profile, stated role, visible skills, city, public contact link.

Every cell carries a link to the page it came from, so you can open the posting or the profile and read it yourself. Every cell carries a freshness badge, which matters on both sides: postings close and roles change. Every cell records the extraction method.

Values that cannot be verified stay n/a. On the demand side that is usually salary. On the candidate side it is usually contact, and often current employer, because plenty of public profiles are out of date and we would rather show you an empty cell than a stale job title presented as current.

Export is JSON on every plan, CSV from Starter, the API from Pro and webhooks on Business.

What it costs in credits

A page read is about 1 credit, a social or professional profile read about 3, a Deep Research report 20 to 40.

A demand-side run across 9 job boards for one role in two cities typically reads 80 to 150 postings and lands around 100 to 180 credits. A candidate run that opens 60 public profiles plus their personal sites is around 240. A deep research report on a single hard-to-fill role and its market costs 20 to 40.

Free gives 150 credits a month, enough for one market map. Starter is €29 a month for 1,000 credits, which suits an in-house recruiter working a handful of open roles. Pro is €79 for 4,000 credits with API access, the plan for an agency running searches continuously. Business is €199 for 12,000 credits with webhooks.

Because profiles cost three times a page, do the demand map first. It is cheaper, it sharpens your candidate brief, and it means the expensive profile reads happen against a better definition.

Limits and honesty

Public data only, and we mean the boundary strictly. No private profiles, no data behind a login, no paywalled content, no connection graphs, no exporting anyone's network. If a profile is private, it is invisible here.

No email guessing. We do not generate addresses from a name and a company domain and present them as found. If someone published a contact, you get it with a source link. If not, the cell is blank.

Coverage of people is partial by construction. You get candidates who published. Excellent engineers who keep no public presence do not appear, and no honest method surfaces them.

Public profiles go stale. A profile last edited in 2023 says what was true in 2023. The freshness badge tells you when we read it, not when they wrote it, and we will not present a stated role as verified current employment.

Salary data is only what employers published. Where a market rarely publishes ranges, the column is thin. That is the market, not a gap in the read.

Outreach is drafted, never sent. The agent writes the approach messages, you review and send them. There is no bulk messaging here.

Recruiting is heavily regulated. Candidate data is personal data under the GDPR, sourcing creates records you have to be able to justify, and several European countries add their own rules on top. Being able to read a public profile is not the same as being allowed to keep it in a database indefinitely. None of this is legal advice.

Frequently asked questions

Which job boards does it read? Nine job boards plus company career pages and any public listing page you name. Company career pages matter more than people expect, because senior roles are often posted there and nowhere else.

Does it scrape LinkedIn profiles? It reads public pages only. Anything requiring a login, and anything on a profile the person has restricted, is out of scope and stays out. We do not build shadow copies of private profiles.

Can it find passive candidates? It finds people who published public evidence of their work, which includes plenty who are not job hunting. It does not identify who is open to moving. That signal is either private or self-declared, and inferring it would be a guess dressed as data.

Is the salary data reliable? It is exactly what the employer wrote in the posting, with a link to it. Where nothing was published the cell is empty. No modelled ranges, no benchmarks presented as observed pay.

Can I run this for a market outside Italy? Yes. The agent searches in the local language, so Berlin, Madrid, Lyon and Amsterdam work from the same prompt. Publication norms differ by market and the salary column will reflect that.

How often should I re-run it? Weekly for the demand map if you are actively recruiting, because postings open and close fast. The candidate table moves more slowly, and the freshness badge tells you which values were re-read.

Prices checked on 2026-09-08 on searchbase.org.