LinkedIn Mass Company Profile Finder With Multi-Engine Search

LinkedIn Company Profile Finder — URLs, Ranks & Engine Data

LinkedIn Mass Company Profile Finder With Multi-Engine Search turns a list of keywords, domains, or brand names into verified LinkedIn company profile URLs — plus the search diagnostics and proxy metadata behind every match. You choose exactly which public search engines run per keyword (DuckDuckGo, Bing, or a best-effort Google option), and every row comes back as typed, normalized JSON: no HTML, no selectors, no parsing before it reaches your CRM, spreadsheet, or AI agent. Read on for the exact input fields, the full output shape, and how to run it from the Apify Console or the Apify API.

---

🧭 What is LinkedIn Mass Company Profile Finder With Multi-Engine Search?

It's an Apify Actor that resolves a bulk list of search terms — domains like alma.fr, exact names like "Acme Corp", or a brand plus a qualifier like "Stripe" payments — into LinkedIn company profile URLs, using public search engines rather than LinkedIn itself. No LinkedIn account, login, or session is ever used: the Actor queries DuckDuckGo, Bing, and/or Google with a site:linkedin.com/company filter and extracts matching links from the public results.

What it returns, per run:

• 🔗 LinkedIn company profile URLs, normalized to their canonical form and deduplicated
• 🧭 Search diagnostics — which engines were attempted and which one(s) actually returned each URL
• 🛡️ Proxy diagnostics — which proxy tier was active when the result was fetched
• 📤 Export as JSON, CSV, or Excel straight from the Apify dataset

---

📦 What data does LinkedIn Mass Company Profile Finder With Multi-Engine Search collect?

Every pushed row carries three groups of data: the resolved company match, the search engine diagnostics for that keyword, and the proxy/run diagnostics active at the time.

Data Type	Key Fields	JSON Field Names
Company match	Canonical LinkedIn company URL, its slug, the keyword that found it	linkedin, slug, input
Search diagnostics	Which engine(s) returned this URL, its arrival order, every engine attempted for the keyword	foundBy, resultRank, enginesTried
Run diagnostics	Proxy tier active for this result, failure reason when nothing was found	proxyMode, error

Need more LinkedIn data?

If you need firmographic detail beyond the profile URL, API-Empire also publishes LinkedIn Company Profile Scraper With Firmographic Filters for enriched company records, and LinkedIn Lead Scraper With Advanced Filters for individual lead-level data. Run this Actor first to resolve URLs in bulk, then feed the results into either as your next step.

---

🛠️ Why not build this yourself?

Querying one search engine for a site:linkedin.com/company result is a five-minute script. Doing it reliably at bulk-keyword scale is not. You'd need separate parsers for DuckDuckGo's API shape, Bing's paginated HTML (li.b_algo markup that changes without notice), and Google's result blocks — each with its own blocking signals (CAPTCHA pages, "unusual traffic" interstitials, HTTP 403/407/429/503). You'd also need to normalize LinkedIn URLs across country subdomains (fr.linkedin.com, uk.linkedin.com, …), filter out non-company pages like /company/setup or /company/directory, deduplicate across engines, and build a proxy escalation path that doesn't burn residential-proxy cost on every request. This Actor already does all of that, and keeps running when a search engine's markup shifts, because that maintenance is centralized here instead of in your own script.

---

🎯 Why do developers and teams scrape LinkedIn for company data?

For AI engineers and agent builders

Company URL resolution is a common tool call inside enrichment and outreach agents: given a domain or brand name extracted from a lead form or CRM record, an agent calls this Actor to resolve the canonical linkedin URL and slug, then passes that URL to a downstream scraper or stores it against the account record — all as typed JSON with no HTML to parse in the agent loop.

For sales and B2B lead-gen teams

Given a list of target-account domains or company names exported from a CRM, this Actor resolves each one to its LinkedIn company page in bulk, with foundBy and resultRank giving a quick confidence signal on ambiguous matches (a generic name like "Acme" returning several candidates) before the URL is written back to the CRM.

For marketers and ABM teams

Account-based marketing lists are usually just company names or domains. Turning that list into LinkedIn company URLs is the first step before building a target-account list for ad platforms or manual outreach — and running the same list with different engines selections shows which engine surfaces a given brand at all.

For data teams building enrichment pipelines

Because maxConcurrency, maxResultsPerKeyword, and maxRetries are all real, run-affecting inputs, this Actor slots into a scheduled enrichment pipeline: pull new company names from a data warehouse, run them through on a schedule, and load linkedin/slug back in as a foreign key for the next enrichment stage.

---

🚀 How to find LinkedIn company profiles (step by step)

1. Open LinkedIn Mass Company Profile Finder With Multi-Engine Search on its Apify Store listing and click Try for free (or Start, if already added to your account).
2. Provide the required input — urls: a list of keywords, domains, or brand names, one per line.
3. Open 🧭 Multi-Engine Search Control to pick which engines run (ddgs, bing, google) and set maxResultsPerKeyword, maxConcurrency, and maxRetries if the defaults don't fit your run.
4. Click Start. Results are pushed to the dataset live, one row per matched URL, as soon as each keyword resolves.
5. Open the Output tab and export as JSON, CSV, or Excel — or pull results via the Apify API while the run is still going.

What to do when LinkedIn or a search engine changes its structure

This Actor doesn't parse LinkedIn's own page markup — it matches company URLs with a regular expression against search-engine result pages, so a LinkedIn redesign alone doesn't break it. What can break it is a search engine changing its result-page HTML or blocking pattern; that surface (DuckDuckGo, Bing, and Google parsing) is maintained here, and the output field names and types stay stable, so downstream integrations don't need to change when it happens.

---

⬇️ Input

Parameter	Required	Type	Description	Example Value
urls	Yes	array of strings	Any list of search terms — domains, exact company names, brand + qualifier, or plain text. Each line is searched independently across the selected engines.	["alma.fr", "Stripe payments", "Anthropic AI"]
engines	No	array (enum: ddgs, bing, google)	Which search engines to run per keyword. An empty or invalid selection falls back to the default. Default: ["ddgs", "bing"].	["ddgs", "bing", "google"]
maxResultsPerKeyword	No	integer (min 1, max 200)	Maximum distinct LinkedIn company URLs to collect per keyword, combined across all selected engines. Default: 30.	30
maxConcurrency	No	integer (min 1, max 10)	How many keywords are processed at the same time. Default: 3.	3
maxRetries	No	integer (min 0, max 5)	How many extra attempts each engine gets on a keyword before the Actor escalates to the next proxy tier. Default: 2.	2
proxyConfiguration	No	object (proxy editor)	Default: no proxy. If search engines block the request, the Actor automatically escalates: no-proxy → Datacenter → Residential (3 retries), then reuses the working tier.	{"useApifyProxy": false}

Example JSON input

{
  "urls": ["alma.fr", "Stripe payments", "Anthropic AI"],
  "engines": ["ddgs", "bing"],
  "maxResultsPerKeyword": 30,
  "maxConcurrency": 3,
  "maxRetries": 2,
  "proxyConfiguration": { "useApifyProxy": false }
}

Common pitfall: maxResultsPerKeyword caps distinct URLs per keyword, combined across every engine you selected — it is not a per-engine limit. Selecting all three engines with maxResultsPerKeyword: 30 still stops at 30 unique company URLs for that keyword, not 30 per engine.

---

⬆️ Output

Results are pushed to the Apify dataset live, one row per matched LinkedIn company URL (or one diagnostic row per keyword that matched nothing), and are exportable as JSON, CSV, or Excel. Every row uses the same eight fields, whether the keyword resolved or not.

Scraped LinkedIn company match

{
  "linkedin": "https://www.linkedin.com/company/alma-studio-paris",
  "input": "alma.fr",
  "slug": "alma-studio-paris",
  "foundBy": "bing+ddgs",
  "resultRank": 1,
  "enginesTried": "ddgs+bing",
  "proxyMode": "no-proxy",
  "error": null
}

When a keyword resolves to no LinkedIn company across every selected engine, the same shape is pushed with the match fields empty:

{
  "linkedin": null,
  "input": "very-rare-keyword-12345",
  "slug": null,
  "foundBy": null,
  "resultRank": null,
  "enginesTried": "ddgs+bing",
  "proxyMode": "residential",
  "error": "ddgs: no results; bing: no results"
}

Field	Description
linkedin	Canonical LinkedIn company URL (https://www.linkedin.com/company/<slug>). null when nothing was found.
input	The keyword exactly as supplied in urls.
slug	The LinkedIn company slug (everything after /company/). null on a no-match row.
foundBy	Engine(s) that returned this specific URL, +-joined (e.g. "ddgs+bing"). null on a no-match row.
resultRank	1-based order this URL arrived in for its keyword, across all selected engines. null on a no-match row.
enginesTried	Every engine actually attempted for this keyword, +-joined — including ones that returned zero hits or errored.
proxyMode	Proxy tier active when this row was produced: no-proxy, datacenter, or residential.
error	null on a successful match. Populated with the per-engine failure reasons only when every attempted engine returned nothing for that keyword.

Pricing note: this Actor charges the row_result event only for rows where a LinkedIn URL was actually found. A keyword that resolves to nothing is still pushed to the dataset for visibility (so you can see which inputs failed) but is pushed without the charged event — you are not billed for it. To read only the billed rows programmatically, filter the dataset on error === null (equivalently, linkedin !== null).

---

🔍 How does this compare to other LinkedIn company finders?

Feature	This Actor	Generic single-engine finder
Engine selection	User picks any combination of 3 engines per run	✅ / ❌ depends on the tool — most fix one engine
Per-row engine attribution	foundBy names the exact engine(s) that returned each URL	❌ Not typically exposed
Per-keyword search audit trail	enginesTried records every engine attempted, including empty ones	❌ Not typically exposed
Proxy cost control	Starts with no proxy, escalates only on a block	Varies — many always route through paid proxy
Output format	Typed, normalized JSON	Varies

If you're building an AI agent or RAG pipeline, the output format row is the decision-maker — parsing HTML inside an agent loop is a reliability failure mode, not a feature.

---

📊 How many LinkedIn company profiles can you find?

maxResultsPerKeyword caps each keyword at 1–200 distinct LinkedIn URLs (default 30), combined across whichever engines you selected — there is no separate per-engine cap. There is no hard cap on the number of keywords in a single run; per the input field's own guidance, bulk lists of "1, 10, or 1000+ keywords" are supported, with maxConcurrency (1–10, default 3) controlling how many keywords are processed in parallel. Larger keyword lists simply take longer and, if engines start blocking, may trigger the proxy escalation ladder sooner. No benchmark run time is published — actual duration depends on keyword count, maxConcurrency, maxResultsPerKeyword, and how quickly each engine responds.

---

🔗 Integrate LinkedIn Mass Company Profile Finder With Multi-Engine Search and automate your workflow

This Actor works with any language or tool that can send an HTTP request, since it runs through the standard Apify API.

REST API integration

from apify_client import ApifyClient

client = ApifyClient("<APIFY_API_TOKEN>")

run = client.actor("<ACTOR_ID>").call(run_input={
    "urls": ["alma.fr", "Stripe payments"],
    "engines": ["ddgs", "bing"],
    "maxResultsPerKeyword": 30,
    "maxConcurrency": 3,
})

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    if item["error"] is None:
        print(item["linkedin"], item["foundBy"])

Works in Python, Node.js, Go, Ruby, cURL.

Automation platforms (n8n, Make, LangChain)

In n8n, the Apify node can start this Actor and read back its dataset as part of a larger lead-enrichment workflow. In Make, the Apify app's "Run Actor" module does the same, letting you chain the results into a CRM-update scenario. In LangChain, the Apify dataset loader can pull this Actor's output directly into a document loader or agent tool, so a chain can resolve a company name to its LinkedIn URL mid-run.

---

⚖️ Is it legal to scrape LinkedIn company profile URLs?

Yes — finding publicly indexed LinkedIn company page URLs through public search engines is legal. This Actor returns only publicly available data: it never logs into LinkedIn, never requests authenticated pages, and never touches content behind LinkedIn's login wall. A LinkedIn company profile URL and its slug are business/organizational records, not personal data, so this falls under the target platforms' terms-of-service and database-rights framing rather than GDPR/CCPA, which govern personal data about identifiable individuals. Consult legal counsel before large-scale commercial use, and review LinkedIn's own terms of service for how you intend to use the resulting URLs.

---

❓ Frequently asked questions

Does this Actor work without a LinkedIn account?

Yes. It never logs into LinkedIn or calls any LinkedIn API — it queries public search engines (DuckDuckGo, Bing, and optionally Google) with a site:linkedin.com/company filter and extracts matching URLs from their public results. No LinkedIn credentials are ever required.

How often is the data updated?

Every run performs a live query against the selected search engines at the moment it executes — there is no cached or pre-scraped dataset behind it. Results reflect whatever those engines have indexed at run time.

What happens when a keyword doesn't match any LinkedIn company?

The row is still pushed to the dataset with linkedin, slug, foundBy, and resultRank set to null and error populated with the per-engine failure reasons (e.g. "ddgs: no results; bing: no results"). These rows are not charged — see the pricing note in the Output section for the exact filter.

Can I get private or login-gated LinkedIn company information?

No. The Actor only surfaces company profile URLs that are publicly indexed by search engines. It cannot and does not access anything behind LinkedIn's login wall, including any employee, follower, or analytics data visible only to logged-in members.

Do I need my own search engine API keys or credentials?

No. DuckDuckGo search runs through the ddgs library directly, and Bing/Google are queried over plain HTTP — no third-party search API key is required. You only need an Apify account to run the Actor.

Does this Actor work for AI agent workflows and LLM pipelines?

Yes. It's callable as a standard HTTP endpoint through the Apify API by any agent framework that can make a REST call, and every response is typed, normalized JSON — no HTML and no parsing step before passing results to an LLM or storing them.

How does this Actor handle search engine blocking?

Each engine gets maxRetries attempts (default 2) with exponential backoff before the Actor escalates the proxy tier: no-proxy → Datacenter → Residential, with 3 residential retries before locking in whichever tier last worked for the rest of the run. This targets blocking from the search engines themselves (CAPTCHA pages, HTTP 403/407/429/503) — the Actor never contacts LinkedIn's servers, so LinkedIn's own anti-bot measures are not in scope.

How does this Actor compare to other LinkedIn company finders?

The distinguishing feature is that engine selection and search diagnostics are real, per-row output — enginesTried, foundBy, and resultRank tell you exactly which engines ran and which one(s) produced each match, which single-engine or closed-pipeline company finders typically don't expose.

Does this Actor return data in a format LLMs can use directly?

Yes. Typed, normalized JSON with stable field names — no HTML, no selectors. Pass rows directly into an LLM context window, index them into a vector store, or route them through an agent tool.

Can I use this Actor without managing proxies myself?

Yes. By default it runs with no proxy at all to save cost, and only requests an Apify Datacenter or Residential proxy automatically if a search engine blocks the run. You can also pre-select a proxy in proxyConfiguration if you want to start on a specific tier.

What happens if a search engine changes its result-page structure?

The Actor is maintained, and its output schema stays stable — field names and types don't change on your end even if a search engine's HTML structure shifts and the underlying parser needs an update.

---

💬 Your feedback

Found a bug, or need a field this Actor doesn't return yet? Open an issue on the Actor's Apify Store page or message API-Empire through the Apify Console's built-in contact form — reports like these go straight into what gets fixed or added next.