LinkedIn 的 wise 頁面屬於 1969 年成立的印刷公司，404 反而是好結果

I run a visa agency in Bali, and the other half of my week goes into Apify Actors. One of them reads public LinkedIn company pages and returns firmographics as a flat row: website, industry, size band, employees on LinkedIn, followers, headquarters with street address, company type, founded year, specialties, every office, similar pages, affiliated pages.

The input is a LinkedIn company URL. The problem is that nobody's lead list contains LinkedIn company URLs. Lead lists contain brand names — a conference attendee sheet, a column pasted out of a CRM, the output of some other scraper. So the first thing everyone does, including me, is build the URL by hand:

slug = brand.lower().replace(" ", "")
url  = f"https://www.linkedin.com/company/{slug}"

On 27 October 2026 I ran that guess against 38 well-known brands and looked at what came back. Here is the summary before the details, because the shape of it is the point:

38 guessed slugs
  32  the company I meant
   2  HTTP 404 — free, not charged
   4  a different company — complete row, charged, no warning

The two 404s were Tesla and Plaid. They cost nothing, they arrive as an error row with a reason, and they are impossible to miss. The four that worked are the expensive ones.

The four

linkedin.com/company/wise is Wise, a trade printer in Georgia making business forms, prescription pads and jumbo label rolls since 1969. Five plants, 265 people on LinkedIn, and a completely legitimate row:

{
  "name": "Wise",
  "linkedinUrl": "https://www.linkedin.com/company/wise",
  "website": "http://www.wbf.com",
  "tagline": "Forms l Labels l Digital",
  "industry": "Printing Services",
  "companySize": "201-500 employees",
  "employeesOnLinkedIn": 265,
  "followers": 1708,
  "headquarters": "Alpharetta, GA",
  "streetAddress": "555 McFarland 400 Dr.",
  "companyType": "Privately Held",
  "founded": 1969,
  "specialties": ["Business Forms & Checks", "Unit Sets", "Prescription Pads", "Jumbo Rolls"]
}

The fintech lives at wiseaccount (and transferwise, which resolves to the same page): 11,852 employees, 715,775 followers, London, founded 2011.

Nothing in that row is wrong. Every field is populated, the address is real, the specialties are real. If it lands in a CRM next to "Wise — fintech, London", the only thing that will flag it is a human reading the tagline.

Name matching does not save you

The obvious defence is to compare the name the page returned against the brand you asked for. Normalise both to lowercase alphanumerics and check equality:

• gitlab → domify — caught.
• uber → uberagency — caught.
• wise → wise — not caught.
• square → square — not caught.

Two of four. And the two it misses are the two that matter most, because an exact name collision is precisely the case where a brand did not get its own slug. That is not a coincidence — the companies that lost the race for /company/wise lost it to another company called Wise.

Guessing harder makes it worse, not better. My second round of guesses:

plaid           → 404                (free)
plaid-inc       → PLAID, Inc.        324 employees, plaid.co.jp — a Japanese software company
plaid-technologies → 404             (free)

square          → SQUARE             55 employees, Oslo ad agency
square-inc      → SQUARE Inc.        2 employees, square-shop.ocnk.net — Japanese furniture
squareup        → 404                (free)
block           → Block              287 employees, no website at all
joinsquare      → Square             6,252 employees, squareup.com — the payments company

Four plausible guesses for Square's page. One right. Every wrong one carried "Square" or "Block" in the name and came back fully populated.

What actually separates them

Three signals in the row work, and none of them is the name.

The website domain. All four wrong rows published a website, and all four domains were visibly not the brand's: wbf.com, uberagency.com, square.co, domify.io. If your source list has a domain in it — and lead lists usually do — comparing registrable domains catches 4 of 4. This is the check to build first.

Follower count. The four wrong rows had 391, 1,708, 3,172 and 6,023 followers. The lowest follower count among the 32 correct pages was Intercom at 191,393. A 31× gap with nothing in between. For a list of companies you have heard of, a floor of 50,000 followers would have flagged all four and nothing else. Worth knowing the limit of this one: it only works because recognisable brand implies large page. On a list of 20-person manufacturers it is useless.

similarCompanies — the part I did not expect. LinkedIn's own "similar pages" rail on the wrong page points at the right one in three of the four cases:

wise    (printer)     → Revolut, Wise /company/wiseaccount, Monzo, Stripe, Adyen, N26, Klarna, PayPal
uber    (ad agency)   → Uber /company/uber-com, Airbnb, Amazon, Salesforce, Microsoft, Adobe
gitlab  (Domify)      → Automattic, Zapier, Toptal, GitLab /company/gitlab-com, Canonical
square  (Oslo agency) → Dropbox, Toast, PayPal, Elastic, Lightspeed Commerce, Shopify

LinkedIn's recommender has clearly been trained on what people searching that page actually wanted. So the recovery is automatable: when the domain check fails, scan similarCompanies for a name that matches your brand, take its linkedinUrl, and re-run that one slug. Three of my four repaired themselves that way. The fourth — Square — did not get a direct hit, but its rail is unmistakably the payments neighbourhood, which is enough to tell a human they are on the wrong page.

Running it

{
  "companies": ["wiseaccount", "uber-com", "gitlab-com", "joinsquare"],
  "includePosts": false
}

Slugs and full URLs are both accepted. From Python, with the domain check attached:

from apify_client import ApifyClient

client = ApifyClient("<YOUR_API_TOKEN>")
targets = {"wiseaccount": "wise.com", "uber-com": "uber.com"}

run = client.actor("lergassy/linkedin-company-scraper").call(run_input={
    "companies": list(targets),
    "includePosts": False,
})

for row in client.dataset(run["defaultDatasetId"]).iterate_items():
    if row.get("type") != "company":
        continue
    host = (row.get("website") or "").split("//")[-1].split("/")[0].removeprefix("www.")
    ok = host.endswith(targets[row["slug"]])
    print(row["slug"], row["name"], row["employeesOnLinkedIn"], host, "OK" if ok else "MISMATCH")

Full run details and field list are on the LinkedIn Company Scraper page. Error rows and 404s are not billed, which is why the loud failures are also the free ones.

A second disagreement, while I had the data

Two fields in every row claim to describe headcount, and they come from different places in the page. companySize is the band the company picked in its own page settings, parsed out of the About dl. employeesOnLinkedIn is LinkedIn's count of members who list that company as their employer, read out of the page's JSON-LD.

Across the 36 rows that landed on the company I meant — the 32 good guesses, plus the repaired slugs and the two I knew by hand — 26 had a closed band (not the open-ended 10,001+). Of those 26, 15 reported more employees on LinkedIn than their own band's ceiling allows, and zero reported fewer than the floor:

Airbnb      5,001-10,000 employees   →  73,151   ×7.3
Notion        501-1,000 employees    →   7,211   ×7.2
Anthropic     501-1,000 employees    →   6,244   ×6.2
Canva       1,001-5,000 employees    →  20,019   ×4.0
Duolingo      501-1,000 employees    →   3,274   ×3.3
OpenAI      1,001-5,000 employees    →  11,490   ×2.3
Datadog     1,001-5,000 employees    →  10,333   ×2.1

The error is one-directional, which tells you it is not noise. Members keep listing an employer after they leave, contractors and franchisees list the brand they work under, and nobody goes back to update the band after a hiring year. Neither number is a headcount. One is a declaration the company made once, the other is a tally of profiles.

Practical consequence: "51–200 employees in SaaS" filtered on companySizeMin/companySizeMax and the same filter on employeesOnLinkedIn return different lists, and the second one skews large. Pick one, write down which, and do not mix them across refreshes of the same list.

When this is the wrong tool

It reads what a logged-out visitor sees, so there is no employee list — the count and the band, never the people. Follower counts on similar pages, the verified badge and the number of open roles are also logged-in-only, so they are not in the row. And it will not find a page from a name: it resolves URLs, it does not search. That gap is the subject of this post, and the honest answer is that brand → slug is a separate job with its own failure mode, not a flag you switch on.

One last detail, noticed only because Wise's page answers to two slugs and I read both: followers came back 715,775 on one read and 715,776 on the next. Identical page, identical everything else. If you diff weekly snapshots, that is the floor of your noise.