周一至周五 09:00 - 18:00(UTC+08:00) ©2026 NST LABS TECH LTD. 保留所有权利。
如何在2026年抓取LinkedIn个人资料:逐步指南
Kai Watanabe Scraping Infrastructure Evangelist
如何在2026年抓取LinkedIn个人资料:逐步指南
TL;DR
只有公开可见的 LinkedIn 个人资料字段才能安全收集。 任何登录用户(姓名、标题、当前职位、地点和公共帖子)可见的内容,法律和技术类别与受登录保护的数据(如连接、消息或完整工作历史)不同。
LinkedIn 的服务条款明确禁止自动抓取, 其机器人检测可以限制速度、阻止或禁止发出请求的账户或 IP。
hiQ Labs 诉 LinkedIn 并未从一般意义上使抓取 LinkedIn "合法"。 第九巡回法院认为抓取公共数据不违反联邦计算机欺诈和滥用法,但2022年的一项单独裁定认定 hiQ 违反了 LinkedIn 的合同条款,该案最终以对 hiQ 的永久禁令而非抓取者的胜利结束。
一个有效的提取路径使用 requests 和 BeautifulSoup(或者对 JavaScript 渲染部分使用 Playwright)访问公共资料 URL, 解析页面中嵌入的结构化数据,而不是猜测不断变化的 CSS 类名。
速率限制、会话处理和 IP 声誉决定请求是否成功, 而不是巧妙的变通方法——将这些视为可靠性工程,而不是规避。
GDPR 和 CCPA 对抓取的个人数据适用, 与您存储的任何其他个人数据相同,因此在您构建任何名称和职位的数据库之前,合法依据和保留限制很重要。
从抓取的个人资料建立潜在客户列表或联系人数据库本身带有法律风险, 与抓取方法本身分开,商业规模的收集应首先通过法律顾问。
介绍:“抓取 LinkedIn 个人资料” 实际上意味着什么
LinkedIn 个人资料页面混合了两种非常不同的数据表面:可供任何拥有 URL 的人看到的子集,以及只有在登录后才能看到的子集。未登录访问 linkedin.com/in/some-name 的访客通常会看到该人的姓名、标题、当前公司和职位、一般地点,以及他们公开发布的任何帖子——这些信息与搜索引擎可以索引的信息相同。超过这一点的所有内容,包括完整的连接列表、私人消息和大多数详细的历史部分,都在 LinkedIn 的身份验证墙后面。
本指南仅涵盖公共表面。它展示了提取这些公共数据的有效 Python 方法,解释了底层合规决策为何比代码本身更重要,并明确了“可能”和“允许”之间的界限。
公共 LinkedIn 个人资料数据的使用案例
招聘人员、销售团队和研究人员从公共 LinkedIn 数据中提取用于一系列特定的重复工作,每个工作对风险和规模的容忍度不同。
招聘管道丰富化 ——将候选人的当前标题和公共头条附加到现有申请跟踪记录中,一次查找一个,而不是批量爬取。
公司组织结构图研究 ——在销售电话之前确认目标账户中当前持有角色的人,通过单个公共资料检查。
关于公共职业趋势的学术和市场研究 ——聚合匿名的、公开可见的职称和行业样本,而不保留姓名。
品牌和提及监测 ——检查公共帖子是否涉及公司或产品,类似于监测其他任何公共网页。
免费试用 Nstproxy →
这些使用案例均不需要触及连接列表、收件箱或任何受登录保护的字段——而且没有一个案例证明可以在 LinkedIn 的整个会员基础上进行无限制的自动爬取。相同的有针对性的单页面模式在 抓取公共亚马逊产品数据 中出现:一次提取一页,按定义的时间表进行,而不是将整个网站视为一个爬取目标。
抓取 LinkedIn 个人资料合法吗? LinkedIn 自己的 用户协议 禁止从该平台自动收集数据,违反该协议可能导致涉事账户的暂停,在某些情况下,LinkedIn 可能对操作员采取法律行动。无论收集的数据在技术上是否公开,该禁令都适用——“公开”描述谁可以查看数据,而不是 LinkedIn 是否同意自动收集这些数据。
引用此问题时最常提到的案例是 hiQ Labs v. LinkedIn ,其实际结果比大多数摘要所暗示的要狭窄。第九巡回法院在2019年做出了裁决,并在2022年再次裁决,因2021年的最高法院裁定与 Van Buren v. United States 相关,认为没有登录情况下抓取公开可访问的数据并不违反《联邦计算机欺诈和滥用法》(CFAA)—— LinkedIn作为私营公司并没有资格针对从未绕过任何访问控制的抓取者引用联邦反黑客法规。这个先例依然有效,并且在2024年的一项不同抓取争议中得到了加强,该争议再次拒绝了针对收集公开可访问数据的抓取者的CFAA理论。
但同样的hiQ诉讼对hiQ整体来说并没有好结果。2022年11月,同一地区法院发现hiQ因抓取数据以及指示承包商创建工作账户而单独违反了LinkedIn的用户协议——这是一个合同索赔,而不是CFAA索赔。案件于2022年12月结案,法院对hiQ颁发了一项规定的永久禁令,而不是有利于hiQ的审判裁决。实际教训是:应对CFAA挑战和应对合同违约索赔是两个独立的法律问题,而LinkedIn在第二个问题上赢得了与第一个问题相同原告的胜诉。
仅收集在未登录状态下可见的数据 ,并且永远不要收集LinkedIn身份验证后面的字段(连接、消息、仅对已登录用户显示的完整个人资料部分)。
**将GDPR和CCPA视为适用,前提是抓取的记录识别出真实的人。**这意味着必须有法律依据来持有数据,最小化存储的内容以满足实际使用案例的需求,并且不要纯粹基于抓取的姓名和电子邮件构建未经请求的联系推广数据库。
在任何商业规模的收集工作之前寻求法律意见 ,因为hiQ案件中证明的合同违约风险独立于CFAA所允许的内容。
本指南不涵盖,也将不涵盖,绕过LinkedIn的登录墙、破解验证码、自动生成虚假账户或任何旨在大规模规避LinkedIn的机器人检测的技术——这些内容跨越了“收集公共数据”与“规避访问控制”,这既违反了LinkedIn的条款,也是一个与上述公共数据问题有实质性不同和风险更高的法律立场。
方法及工具契合度 以下工作流程有三个关键部分:获取一个公共个人资料页面,解析其嵌入的结构化数据,而不是易碎的CSS选择器,并管理请求的速率和IP声誉,以便在开始之前不会被阻止。
提供给已登出的访问者的公开LinkedIn个人资料页面包含一个JSON-LD <script type="application/ld+json"> 块,带有 Person 架构——以供搜索引擎读取的结构化格式的姓名、职位和所属单位。解析该块比解析视觉HTML类更为稳健,因为LinkedIn会在没有通知的情况下更改它,这些类因地区和页面是服务器渲染还是客户端水合作用而有所不同。
剩余的变量是请求本身。来自住宅连接的偶尔单次查找很少会引发任何警报。来自一个数据中心IP的每分钟多次持续查找是LinkedIn的自动流量检测所捕捉的模式,与请求的数据无关。这就是代理基础设施适用的地方:不是作为绕过身份验证的一种方式,而是作为一种保持适度、间隔请求模式看起来像普通住宅流量的方式,这样重试和分页的行为可预测,而不是在批处理一半时失败。
Nstproxy的 Residential Lite Proxies 正是为这种稳定、适度流量的收集工作而设计的。该线路从200多个国家和地区的5000万多个真实住宅IP池中汲取,采用 预付费套餐 而不是自动续订的订阅,这适合于以突发方式进行而非持续运行的工作负载。具体来说,本教程的使用案例:
住宅IP池 ——请求通过真实的消费者ISP连接而非数据中心范围路由,这符合合法、低流量公共个人资料查找所期望的流量模式。
广泛的国家覆盖 ——当需要检查的个人资料属于不同地区的人时,当地可信的请求来源对于一致的页面渲染是有用的。
预付费、按需计费 ——比起固定的月度承诺,更适合于边界明确、偶尔进行的查找工作。
团队如果超出了自制的 requests/BeautifulSoup 脚本的能力——因为他们需要 JavaScript 渲染、重试以及将结构化输出(Markdown、JSON 或截图)捆绑在一个 API 后,而不是在内部维护——可以考虑 Nstproxy Crawl 作为一个独立的选项;请查看其 API 文档 了解请求/响应的格式。这不是本教程中 DIY 方法的主要推荐,但它为一般较大的提取管道解决了同样的“可靠获取而无需自己构建管道”的问题,适用于任何公共页面,而不仅仅是 LinkedIn。
保持公共档案查找的可靠性
通过遍布200多个地区的真实住宅IP路由偶尔的小量公共数据请求,以便在被标记的数据中心地址上重试和分页不会停滞。
获取住宅代理
前提条件
已安装 Python 3.9 或更高版本 并在系统路径中。
要检查的具体、个别公共个人资料 URL 列表 — 本指南是为有针对性的查找而构建的,而不是对 LinkedIn 会员基础的开放式爬取。
代理或 IP 轮换计划 如果查找量超出少量手动检查,因为来自一个 IP 的请求暴增最有可能被限制速率 — 有关如何将代理与 BeautifulSoup 一起使用的更详细信息,请参阅 如何使用代理与 BeautifulSoup 。
知道 下面的代码尚未在真实 LinkedIn 个人资料上以任何量运行过 。LinkedIn 的机器人检测和服务条款使得仅为了生成博客文章的输出而进行这种测试既不可靠也不合规 — 该代码具有示范性,是基于 schema.org 人员规范 中记录的相同 JSON-LD 结构数据模式构建的,并由公共搜索引擎使用,应该在您有权检查的单个个人资料上进行验证,之后再进行更广泛的使用。
安装 Python 环境 创建一个隔离的环境并安装本指南所需的两个库。Playwright 是可选的,仅在第 3 步中实现 JavaScript 渲染的后备。
python3 -m venv venv
source venv/bin/activate # 在 Windows 上:venv\Scripts\activate
pip install requests beautifulsoup4 playwright
python -m playwright install chromium # 仅在第 3 步中需要
验证状态:仅配置 — 标准 pip/venv 语法,不特指 LinkedIn 的声明。
第 1 步:获取公共个人资料页面 向公共个人资料 URL 发送单个 GET 请求,并使用现实浏览器的 User-Agent 头。请勿尝试登录或附加任何会话 cookie — 此步骤仅适用于登出状态下的公开服务版本页面。
import requests
PROFILE_URL = "https://www.linkedin.com/in/example-public-profile"
headers = {
"User-Agent" : (
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/128.0.0.0 Safari/537.36"
) ,
"Accept-Language" : "en-US,en;q=0.9" ,
}
# 路由通过住宅代理进行单次手动检查以外的任何请求。
proxies = {
"http" : "http://USERNAME:PASSWORD@gate.nstproxy.com:PORT" ,
"https" : "http://USERNAME:PASSWORD@gate.nstproxy.com:PORT" ,
}
response = requests . get ( PROFILE_URL , headers = headers , proxies = proxies , timeout = 15 )
response . raise_for_status ( )
html = response . text
验证状态:说明性 — 显示的 requests API(requests.get、headers、proxies、timeout、raise_for_status)与当前的 官方 requests 文档 相符,但此代码片段未在本文章的真实 LinkedIn URL 上执行;参见前提条件。
第 2 步:解析嵌入的结构化数据 LinkedIn 的公共个人资料页面,像大多数为搜索引擎索引而构建的页面一样,包括一个 <script type="application/ld+json"> 块,使用 schema.org 的 Person 词汇来描述个人。解析该块在标记更改方面比针对视觉 CSS 类更稳定。
import json
from bs4 import BeautifulSoup
soup = BeautifulSoup ( html , "html.parser" )
profile_data = { }
for script_tag in soup . find_all ( "script" , type = "application/ld+json" ) :
try :
payload = json . loads ( script_tag . string or "{}" )
except json . JSONDecodeError :
continue
if payload . get ( "@type" ) == "Person" :
profile_data = {
"name" : payload . get ( "name" ) ,
"headline" : payload . get ( "description" ) ,
"location" : ( payload . get ( "address" ) or { } ) . get ( "addressLocality" ) ,
"current_role" : ( payload . get ( "worksFor" ) or { } ) . get ( "name" ) ,
}
break
print ( profile_data )
# 示例说明输出:
# {'name': 'Jordan Example', 'headline': '在示例公司担任高级数据分析师',
# 'location': '德克萨斯州奥斯汀', 'current_role': '示例公司'}
验证状态:说明性 — Person schema 字段名称遵循 schema.org 规范,以及本文章所审查的当前 LinkedIn 抓取参考文献中记录的一般模式;示例值是占位符,未从真实档案中抓取。
第 3 步:使用 Playwright 处理 JavaScript 渲染的部分 公共档案的某些部分(旧帖子,一些详细面板)通过客户端 JavaScript 在初始 HTML 响应后加载。当 JSON-LD 块没有携带您需要的字段时,请使用无头浏览器渲染页面,而不是在普通 HTTP 客户端中添加更多请求头 — 有关何时此步骤是必要的与可选的更广泛处理,请参见 抓取 JavaScript 渲染的网站 。
from playwright . sync_api import sync_playwright
def fetch_rendered_html ( url : str , proxy_server : str | None = None ) - > str :
with sync_playwright ( ) as p :
launch_args = { "headless" : True }
if proxy_server :
launch_args [ "proxy" ] = { "server" : proxy_server }
browser = p . chromium . launch ( ** launch_args )
page = browser . new_page ( )
page . goto ( url , wait_until = "networkidle" , timeout = 20000 )
rendered_html = page . content ( )
browser . close ( )
return rendered_html
rendered_html = fetch_rendered_html (
PROFILE_URL ,
proxy_server = "http://gate.nstproxy.com:PORT" ,
)
验证状态:说明性 — sync_playwright,chromium.launch,page.goto 和 page.content 与 Playwright 当前的 官方 Python API 文档 相符;出于披露的前提缺口,未针对 LinkedIn 运行实时浏览器会话。
输出架构 在存储任何字段之前,规范化您提取的字段为一个一致的记录格式,以便下游代码不必在哪个步骤生成给定字段上进行分支。
字段 类型 来源 备注 name字符串 JSON-LD Person.name 仅公共显示名称 headline字符串 JSON-LD Person.description 显示在名称下方的一行标题 location字符串 JSON-LD Person.address.addressLocality 一般城市/地区,而不是确切地址 current_role字符串 JSON-LD Person.worksFor.name 当前雇主名称(如果公开列出) profile_url字符串 请求的 URL 用于去重和审计跟踪 fetched_atISO 8601 时间戳 设置在请求时间 需要执行保留/过期策略
不要添加仅存在于登录墙后面的字段 — 如果字段不在登出后的 HTML 或 JSON-LD 块中,它就不是此公共数据工作流的一部分。
观察和限制
JSON-LD 块没有携带每个登录视图显示的字段。 完整工作历史列表、技能背书和推荐通常在公共登出页面中不完整或缺失。
标记和 JSON-LD 字段的可用性可能会在没有通知的情况下改变。 将每个字段提取视为需要定期重新验证的内容,而不是永久合同。
单个被标记的 IP 或异常快速的请求模式可能会在该 IP 上触发临时阻塞, 无论请求是否针对公共或私有数据 — 这是一个需要考虑的可靠性约束,而不是需要规避的安全控制。
该工作流不返回连接、消息或任何仅限认证的字段, 设计上如此 — 要扩展以做到这一点需要登录,这将使活动超出本文所涵盖的范围以及 LinkedIn 的允许使用范围。
批量、无限制收集姓名和头衔与抓取方法本身是不同的风险。 即使是正确抓取的公共数据,一旦聚合到可搜索的可识别人员数据库中,也可能会产生 GDPR/CCPA 暴露。
结论 抓取公共 LinkedIn 个人资料数据在技术上是简单直接的:获取未登录的页面,解析其结构化的 Person 数据,并按照任何负责任的抓取者对任何网站管理请求量的方式管理请求量。更困难的部分是保持在 LinkedIn 的条款和当前案例法实际划定的边界内——仅访问公共字段,不绕过登录,并在数据变成一个存储的、可搜索的真实人数据集之前有一个有据可查的合法依据。根据上述步骤构建技术部分——并将其结构化为一个较大、可维护的代码库,而不是一次性脚本,请参见 将 Python 网络抓取项目构建为完整管道 ——将合规性视为项目在扩展之前必须通过的一个关卡,而不是在抓取器已经工作后加上的事后想法。
常见问题解答 根据第九巡回法院在 hiQ Labs 诉 LinkedIn 案件中的裁决,抓取无需登录即可查看的数据本身并不违反联邦计算机欺诈和滥用法,但这确实违反了 LinkedIn 的用户协议,而 LinkedIn 在同一诉讼中也对 hiQ 获得了违约判决。将“不是 CFAA 违规”与“LinkedIn 条款允许”视为两个不同的问题,它们有两个不同的答案。
不需要——本指南中的每个步骤都在 LinkedIn 提供给非登录访问者的页面上操作,且没有任何代码附加会话 cookie 或凭证。登录以抓取其他字段超出了本指南的范围,且超出了 LinkedIn 允许的使用。
不可以。连接、消息以及大部分详细的个人资料部分仅显示给经过身份验证的用户,并不在未登录的 HTML 或其 JSON-LD 块中,因此该工作流程无法检索它们。
问:如果我大规模运行,LinkedIn 会阻止我的 IP 吗?
从一个 IP 快速运行多个请求是最可能触发临时阻止的模式,无论请求的数据是否是公共的。间隔请求并在住宅 IP 池中轮换降低了这种风险,作为一种流量模式的问题,而不是作为规避任何访问控制的方式。
问:步骤 2 中的 JSON-LD 字段提取有多稳定?
LinkedIn 可以在没有通知的情况下更改页面标记和结构化数据字段,因此将每个字段映射视为需要定期重新检查的内容,而不是一个永久的模式,并且预计在字段缺失时更新解析逻辑。
问:GDPR 或 CCPA 是否适用于抓取的 LinkedIn 数据?
是的,一旦抓取的记录识别出一个真实的活人,标准数据保护规则适用的方式与通过任何其他方法收集的个人数据相同,包括拥有合法依据来持有数据和定义保留期限。
问:官方 LinkedIn API 是比抓取更好的选择吗?
对于大多数用例,是的,只要有访问权限——LinkedIn 的官方 API 对大多数数据类型的批准伙伴有严格限制,因此许多不在该伙伴计划中的团队只能选择抓取公共表面(本指南的范围)或根本不收集数据;没有返回完整个人资料数据的通用公共 API 可供任意开发人员使用。
请法律顾问审查收集的具体数据、相关人员的司法管辖区和预期用途,因为在 hiQ 案件中所显示的违约风险独立于 CFAA 的任何允许,一旦数据集变得足够大以成为真实的合规表面,GDPR/CCPA 还会添加自己的单独要求。
立即访问住宅、数据中心、IPv6 与 ISP 高质量代理池。 创建免费账号并立即试用 ->