Cách để Lấy dữ liệu Hồ sơ LinkedIn vào năm 2026: Hướng dẫn Từng bước
TL;DR
Chỉ những trường hồ sơ LinkedIn có thể nhìn thấy công khai mới an toàn để thu thập. Bất cứ điều gì có thể nhìn thấy bởi một khách truy cập không đăng nhập (tên, tiêu đề, chức vụ hiện tại, vị trí và các bài đăng công khai) nằm trong một thể loại pháp lý và kỹ thuật khác với dữ liệu được bảo vệ bằng đăng nhập như kết nối, tin nhắn, hoặc toàn bộ lịch sử công việc.
Điều khoản dịch vụ của LinkedIn hoàn toàn cấm việc thu thập dữ liệu tự động, và khả năng phát hiện bot của nó có thể giới hạn tốc độ, chặn, hoặc cấm tài khoản hoặc địa chỉ IP thực hiện các yêu cầu.
Vụ hiQ Labs kiện LinkedIn không làm cho việc thu thập LinkedIn trở nên "hợp pháp" theo nghĩa chung. Tòa án Ninth Circuit đã thấy rằng việc thu thập dữ liệu công khai không vi phạm Đạo luật Lừa đảo và Lạm dụng Máy tính liên bang, nhưng một phán quyết riêng biệt vào năm 2022 đã xác định hiQ vi phạm các điều khoản hợp đồng của LinkedIn, và vụ án kết thúc với một lệnh cấm vĩnh viễn đối với hiQ, chứ không phải một chiến thắng cho những người thu thập.
Một phương pháp thu thập hoạt động sử dụng requests và BeautifulSoup (hoặc Playwright cho các phần render bằng JavaScript) đối với một URL hồ sơ công khai, phân tích dữ liệu cấu trúc nhúng của trang thay vì đoán các tên lớp CSS có thể thay đổi mà không báo trước.
Giới hạn tốc độ, quản lý phiên, và danh tiếng IP quyết định liệu một yêu cầu có thành công hay không, không phải các giải pháp lén lút — coi đây là kỹ thuật độ tin cậy, không phải lẩn tránh.
GDPR và CCPA áp dụng cho dữ liệu cá nhân thu thập được theo cùng một cách mà chúng áp dụng cho bất kỳ dữ liệu cá nhân nào khác mà bạn lưu trữ, vì vậy lý do hợp pháp và giới hạn lưu trữ là vấn đề trước khi bạn xây dựng bất kỳ cơ sở dữ liệu nào về tên và chức vụ.
Xây dựng danh sách khách hàng hoặc cơ sở dữ liệu liên hệ từ các hồ sơ thu thập mang lại rủi ro pháp lý riêng khác với chính phương pháp thu thập, và việc thu thập ở quy mô thương mại nên được tham khảo ý kiến của luật sư trước.
Trải nghiem Nstproxy - Bat dau dung thu mien phi ngay
Giới thiệu: việc "thu thập hồ sơ LinkedIn" thực sự có nghĩa là gì
Các trang hồ sơ LinkedIn kết hợp hai bề mặt dữ liệu rất khác nhau: tập hợp có thể nhìn thấy bởi bất kỳ ai với URL, và tập hợp chỉ có thể nhìn thấy sau khi đăng nhập. Một khách truy cập không đăng nhập vào linkedin.com/in/some-name thường thấy tên của người đó, tiêu đề, công ty và chức vụ hiện tại, vị trí chung, và bất kỳ bài đăng nào mà họ đã công khai — thông tin giống như một công cụ tìm kiếm có thể chỉ mục. Mọi thứ qua điểm đó, bao gồm danh sách kết nối đầy đủ, tin nhắn riêng tư, và hầu hết các phần lịch sử chi tiết, nằm sau tường xác thực của LinkedIn.
Hướng dẫn này chỉ đề cập đến bề mặt công khai. Nó cho thấy một phương pháp Python hoạt động để trích xuất dữ liệu công khai đó, giải thích tại sao quyết định tuân thủ dưới các phương pháp kỹ thuật quan trọng hơn mã tự thân, và nói rõ về nơi mà ranh giới nằm giữa "có thể" và "được phép."
Các trường hợp sử dụng dữ liệu hồ sơ LinkedIn công khai
Các nhà tuyển dụng, nhóm bán hàng và nhà nghiên cứu thu thập dữ liệu LinkedIn công khai cho một tập hợp công việc lặp đi lặp lại hẹp, và mỗi cái có mức độ chấp nhận rủi ro và quy mô khác nhau.
Cải thiện quy trình tuyển dụng — đính kèm chức vụ hiện tại và tiêu đề công khai của ứng viên vào một hồ sơ theo dõi ứng viên hiện có, từng tra cứu một lần thay vì thu thập hàng loạt.
Nghiên cứu sơ đồ tổ chức công ty — xác nhận ai hiện đang giữ một vai trò tại một tài khoản mục tiêu trước cuộc gọi bán hàng, sử dụng kiểm tra hồ sơ công khai cá nhân.
Nghiên cứu học thuật và thị trường về các xu hướng nghề nghiệp công khai — tổng hợp các tiêu đề vai trò và ngành công nghiệp công khai, đã được ẩn danh trên một mẫu, mà không giữ tên.
Giám sát thương hiệu và đề cập — kiểm tra xem một bài đăng công khai có nhắc đến một công ty hoặc sản phẩm hay không, tương tự như giám sát bất kỳ trang web công khai nào khác.
Không trường hợp sử dụng nào trong số này yêu cầu chạm tới danh sách kết nối, hộp thư đến, hoặc bất kỳ trường nào được bảo vệ bởi đăng nhập — và không trường hợp nào trong số đó biện minh cho việc chạy một cuộc thu thập tự động không giới hạn trên toàn bộ cơ sở thành viên của LinkedIn. Mô hình đơn trang nhắm mục tiêu tương tự cũng xuất hiện trong thu thập dữ liệu sản phẩm công khai trên Amazon: thu thập một trang tại một thời điểm, theo lịch trình đã định, thay vì coi toàn bộ trang web như một mục tiêu thu thập.
Việc thu thập hồ sơ LinkedIn có hợp pháp không?
Thỏa thuận người dùng của LinkedIn cấm việc thu thập dữ liệu tự động từ nền tảng, và việc vi phạm thỏa thuận đó có nguy cơ bị đình chỉ tài khoản cho tài khoản liên quan và, trong một số trường hợp, hành động pháp lý từ LinkedIn chống lại người điều hành. Sự cấm này áp dụng bất kể dữ liệu được thu thập có thực sự công khai hay không — "công khai" mô tả ai có thể xem dữ liệu, không phải liệu LinkedIn có đồng ý cho việc thu thập tự động dữ liệu đó hay không.
Vụ án thường được trích dẫn nhất về câu hỏi này là hiQ Labs v. LinkedIn, và kết quả thực tế của nó hẹp hơn so với hầu hết các bản tóm tắt. Tòa án Ninth Circuit đã phán quyết vào năm 2019, và lại vào năm 2022 sau khi Tòa án Tối cao năm 2021 đã chuyển lại vụ án liên quan đến Van Buren v. United States, rằng việc thu thập dữ liệu có thể truy cập công khai mà không cần đăng nhập không vi phạm Đạo luật Gian lận và Lạm dụng Máy tính (CFAA) — việc LinkedIn là một công ty tư nhân không cho phép họ viện dẫn một đạo luật chống xâm phạm máy tính liên bang đối với một công cụ thu thập dữ liệu mà không vượt qua bất kỳ kiểm soát truy cập nào. Tiền lệ đó vẫn còn, và nó đã được củng cố bởi một phán quyết liên bang riêng vào năm 2024 trong một tranh chấp thu thập dữ liệu khác, lần nữa từ chối lý thuyết CFAA chống lại một công cụ thu thập dữ liệu đang thu thập thông tin công khai.
Nhưng vụ kiện hiQ cùng không kết thúc tốt đẹp cho hiQ. Vào tháng 11 năm 2022, cùng một tòa án cấp quận đã xác định rằng hiQ đã vi phạm Thỏa thuận Người dùng của LinkedIn bằng cách thu thập dữ liệu và chỉ đạo các nhà thầu tạo tài khoản cho công việc — một yêu cầu hợp đồng, không phải là yêu cầu CFAA. Vụ án đã khép lại vào tháng 12 năm 2022 với một lệnh cấm vĩnh viễn đã được thỏa thuận chống lại hiQ, không phải là một phán quyết xét xử có lợi cho hiQ. Bài học thực tiễn: chống đỡ một thách thức CFAA và tồn tại một yêu cầu vi phạm hợp đồng là hai câu hỏi pháp lý riêng biệt, và LinkedIn đã thắng trong yêu cầu thứ hai chống lại cùng một nguyên đơn đã thắng trong yêu cầu đầu tiên.
Ba quy tắc thực tiễn được rút ra từ điều đó:
Chỉ thu thập dữ liệu có thể nhìn thấy mà không cần đăng nhập, và không bao giờ các trường được bảo vệ bởi xác thực của LinkedIn (kết nối, tin nhắn, các phần hồ sơ đầy đủ chỉ hiển thị cho người xem đã đăng nhập).
Xem xét GDPR và CCPA là áp dụng ngay khi một bản ghi bị thu thập xác định một người thật. Điều đó có nghĩa là có một cơ sở hợp pháp được tài liệu hóa để lưu giữ dữ liệu, giảm thiểu những gì được lưu trữ xuống những gì thực sự cần thiết cho trường hợp sử dụng, và không xây dựng một cơ sở dữ liệu tiếp cận liên lạc không mong muốn chỉ dựa trên tên và email được thu thập.
Có sự tư vấn pháp lý trước bất kỳ nỗ lực thu thập quy mô thương mại nào, vì rủi ro vi phạm hợp đồng được minh chứng trong trường hợp hiQ tồn tại độc lập với những gì CFAA cho phép.
Hướng dẫn này không bao gồm, và sẽ không bao gồm, việc vượt qua bức tường đăng nhập của LinkedIn, đánh bại CAPTCHAs, tự động hóa các tài khoản giả hoặc bất kỳ kỹ thuật nào nhằm tránh phát hiện bot của LinkedIn trên quy mô lớn — những điều đó vượt qua từ "thu thập dữ liệu công khai" sang "vượt qua các kiểm soát truy cập," điều này thì cả trái với các điều khoản của LinkedIn và là một vị trí pháp lý khác biệt và rủi ro hơn nhiều so với câu hỏi dữ liệu công khai ở trên.
Cách tiếp cận và sự phù hợp của công cụ
Quy trình làm việc bên dưới có ba phần chuyển động: lấy một trang hồ sơ công khai, phân tích dữ liệu có cấu trúc nhúng của nó thay vì các trình chọn CSS dễ vỡ, và quản lý các yêu cầu với tốc độ và từ uy tín IP mà không làm cho việc lấy bị chặn trước khi bắt đầu.
Các trang hồ sơ LinkedIn công khai được phục vụ cho một khách truy cập đã đăng xuất bao gồm một khối JSON-LD <script type="application/ld+json"> với schema Person — tên, chức danh công việc, và liên kết trong một định dạng có cấu trúc được thiết kế cho các công cụ tìm kiếm đọc. Phân tích khối đó bền hơn so với việc phân tích các lớp HTML trực quan, mà LinkedIn thay đổi mà không thông báo và thay đổi theo địa phương cũng như xem xét một trang được kết xuất trên máy chủ hay được cấp nước ở phía khách hàng.
Biến số còn lại là yêu cầu bản thân. Một lần tìm kiếm thỉnh thoảng từ một kết nối dân cư hiếm khi nâng lên bất kỳ lá cờ nào. Một chuỗi tìm kiếm liên tục từ một IP trung tâm dữ liệu với nhiều tìm kiếm mỗi phút là mô hình mà việc phát hiện lưu lượng tự động của LinkedIn được xây dựng để bắt, độc lập với dữ liệu nào đang được yêu cầu. Đây là nơi mà hạ tầng proxy phù hợp: không phải là cách để vượt qua xác thực, mà là cách để giữ cho một mô hình yêu cầu khiêm tốn, có khoảng cách nhìn giống như lưu lượng dân cư bình thường mà nó được cho là, để các lần thử lại và phân trang cư xử một cách dự đoán được thay vì thất bại giữa chừng trong một lô.
Proxy Lite Residential của Nstproxy Residential Lite Proxies được xây dựng chính xác cho loại công việc thu thập ổn định, khối lượng vừa phải đó. Dòng sản phẩm này lấy từ một tập hợp 50 triệu IP dân cư thật trên hơn 200 quốc gia và khu vực, tính phí theo gói trả trước thay vì một đăng ký tự động gia hạn, điều này phù hợp với một khối lượng công việc hoạt động theo kiểu bùng nổ hơn là liên tục. Đối với trường hợp sử dụng cụ thể của hướng dẫn này:
Bể IP dân cư — các yêu cầu được định tuyến qua các kết nối ISP tiêu dùng thật thay vì các dải trung tâm dữ liệu, điều này phù hợp với mô hình lưu lượng mà một tìm kiếm hồ sơ công khai hợp pháp, có khối lượng thấp được mong đợi.
Phạm vi quốc gia rộng — hữu ích khi các hồ sơ đang được kiểm tra thuộc về những người ở các khu vực khác nhau và nguồn gốc yêu cầu có tính hợp lý địa phương quan trọng cho việc kết xuất trang nhất quán.
Thanh toán trả trước, theo nhu cầu — phù hợp hơn với một công việc tìm kiếm có giới hạn, thỉnh thoảng hơn là một cam kết cố định hàng tháng được định cỡ cho quá trình thu thập liên tục.
Các nhóm vượt qua một kịch bản requests/BeautifulSoup tự làm — bởi vì họ cần render JavaScript, retry và đầu ra có cấu trúc (Markdown, JSON hoặc hình chụp màn hình) được gói gọn bên trong một API thay vì duy trì trong nhà — có thể xem xét Nstproxy Crawl như một tùy chọn riêng biệt; xem tài liệu API của nó để biết hình dạng yêu cầu/phản hồi. Đây không phải là khuyến nghị chính cho phương pháp DIY trong hướng dẫn này, nhưng nó giải quyết cùng một vấn đề "lấy thông tin một cách đáng tin cậy mà không cần tự xây dựng cơ sở hạ tầng" cho các pipeline trích xuất lớn hơn nói chung, trên bất kỳ trang công khai nào, không chỉ riêng LinkedIn.
Giữ cho việc tra cứu hồ sơ công khai đáng tin cậy
Định tuyến các yêu cầu dữ liệu công khai thi thoảng, dung lượng thấp qua các địa chỉ IP dân cư thực ở hơn 200 vùng, để các lần thử lại và phân trang không bị dừng lại trên một địa chỉ dữ liệu trung tâm bị đánh dấu.
Python 3.9 hoặc mới hơn đã được cài đặt và có trong đường dẫn hệ thống.
Danh sách các URL hồ sơ công khai cụ thể, riêng lẻ để kiểm tra — hướng dẫn này được xây dựng cho các tìm kiếm có mục tiêu, không phải là một cuộc thu thập mở rộng từ cơ sở thành viên của LinkedIn.
Một kế hoạch proxy hoặc xoay vòng IP nếu khối lượng tìm kiếm vượt quá một vài kiểm tra thủ công, vì một loạt các yêu cầu từ một IP là mẫu dễ bị giới hạn tốc độ nhất — xem cách sử dụng proxy với BeautifulSoup để tìm hiểu sâu hơn về cách kết nối xoay vòng proxy vào ngăn xếp phân tích cụ thể này.
Nhận thức rằng mã bên dưới chưa được chạy trực tiếp trên một hồ sơ LinkedIn thực tế với bất kỳ khối lượng nào cho bài viết này. Việc phát hiện bot và các điều khoản sử dụng của LinkedIn khiến việc thử nghiệm như vậy không đáng tin cậy và không tuân thủ chỉ để tạo ra đầu ra cho bài viết trên blog — mã là minh họa, được xây dựng dựa trên cùng một mẫu dữ liệu có cấu trúc JSON-LD được tài liệu hóa trong đặc tả schema.org Person và được sử dụng bởi các công cụ tìm kiếm công khai, và nên được xác thực chống lại một hồ sơ duy nhất mà bạn được phép kiểm tra trước khi sử dụng rộng rãi.
Cài đặt môi trường Python
Tạo một môi trường cô lập và cài đặt hai thư viện mà hướng dẫn này cần. Playwright là tùy chọn và chỉ cần cho phương án dự phòng được render bằng JavaScript ở Bước 3.
python3 -m venv venv
source venv/bin/activate # Trên Windows: venv\Scripts\activatepip install requests beautifulsoup4 playwright
python -m playwright install chromium # chỉ cần cho Bước 3
Trạng thái xác minh: chỉ cấu hình — cú pháp pip/venv tiêu chuẩn, không phải là tuyên bố cụ thể về LinkedIn.
Bước 1: Lấy trang hồ sơ công khai
Gửi một yêu cầu GET đơn cho URL hồ sơ công khai với tiêu đề User-Agent của trình duyệt thực tế. Đừng cố gắng đăng nhập hoặc đính kèm bất kỳ cookie phiên nào — bước này chỉ hoạt động trên phiên bản trang phục vụ công khai, không đăng nhập.
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",}# Định tuyến qua một proxy dân cư cho bất kỳ điều gì ngoài một kiểm tra thủ công đơn lẻ.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
Trạng thái xác minh: minh họa — API requests được hiển thị (requests.get, headers, proxies, timeout, raise_for_status) khớp với tài liệu chính thức của requests, nhưng đoạn mã này không được thực hiện trên một URL LinkedIn trực tiếp cho bài viết này; xem các yêu cầu tiên quyết.
Bước 2: Phân tích dữ liệu có cấu trúc nhúng
Các trang hồ sơ công khai của LinkedIn, giống như hầu hết các trang được xây dựng cho việc lập chỉ mục bởi công cụ tìm kiếm, bao gồm một khối <script type="application/ld+json"> mô tả người dùng dựa trên từ vựng Person của schema.org. Phân tích khối đó ổn định hơn khi so với việc nhắm mục tiêu vào các lớp CSS trực quan.
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:continueif 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"),}breakprint(profile_data)# Ví dụ đầu ra minh họa:# {'name': 'Jordan Example', 'headline': 'Senior Data Analyst at Example Corp',# 'location': 'Austin, Texas', 'current_role': 'Example Corp'}
Trạng thái xác minh: minh họa — các tên trường của schema Person tuân theo tiêu chuẩn schema.org và mẫu chung được tài liệu hóa trong các tham khảo khai thác LinkedIn hiện tại đã được xem xét cho bài viết này; các giá trị mẫu là các giá trị thay thế, không được khai thác từ một hồ sơ thực tế.
Bước 3: Xử lý các phần được trình diễn bằng JavaScript với Playwright
Một số phần của hồ sơ công khai (bài viết cũ, một số bảng chi tiết) được tải sau phản hồi HTML ban đầu qua JavaScript phía khách hàng. Khi khối JSON-LD không chứa một trường mà bạn cần, hãy trình diễn trang bằng trình duyệt không đầu thay vì thêm nhiều tiêu đề yêu cầu vào một máy khách HTTP đơn giản — xem khai thác các trang web được trình diễn bằng JavaScript để có một cái nhìn tổng quát hơn về khi nào bước này là cần thiết so với tùy chọn.
Trạng thái xác minh: minh họa — sync_playwright, chromium.launch, page.goto, và page.content khớp với tài liệu API Python chính thức của Playwright; không có phiên trình duyệt trực tiếp nào được chạy chống lại LinkedIn cho bài viết này, theo khoảng cách yêu cầu đã được công bố.
Sơ đồ đầu ra
Chuẩn hóa bất kỳ trường nào bạn trích xuất thành một dạng bản ghi nhất quán trước khi lưu bất kỳ thứ gì, để mã hạ nguồn không phải phân nhánh về bước nào đã tạo ra một trường nhất định.
Trường
Loại
Nguồn
Ghi chú
name
chuỗi
JSON-LD Person.name
Chỉ hiển thị tên công khai
headline
chuỗi
JSON-LD Person.description
Tiêu đề một dòng hiển thị dưới tên
location
chuỗi
JSON-LD Person.address.addressLocality
Thành phố/khu vực chung, không phải địa chỉ cụ thể
current_role
chuỗi
JSON-LD Person.worksFor.name
Tên nhà tuyển dụng hiện tại nếu được liệt kê công khai
profile_url
chuỗi
URL đã yêu cầu
Lưu cho việc loại bỏ trùng lặp và theo dõi audit
fetched_at
thời gian ISO 8601
Đặt tại thời điểm yêu cầu
Cần thiết để thực thi chính sách lưu giữ/hết hạn
Không thêm các trường chỉ tồn tại phía sau tường đăng nhập — nếu một trường không có mặt trong HTML khi đăng xuất hoặc khối JSON-LD, nó không phải là một phần của quy trình dữ liệu công khai này.
Quan sát và giới hạn
Khối JSON-LD không chứa mọi trường mà chế độ xem đã đăng nhập hiển thị. Danh sách lịch sử công việc đầy đủ, chứng thực kỹ năng, và các khuyến nghị thường không đầy đủ hoặc vắng mặt trên trang công khai, đã đăng xuất.
Khả năng có mặt của markup và trường JSON-LD có thể thay đổi mà không cần thông báo. Coi mọi trích xuất trường như điều gì đó cần kiểm tra lại định kỳ thay vì một hợp đồng vĩnh viễn.
Một IP bị đánh dấu đơn lẻ hoặc một mẫu yêu cầu nhanh bất thường có thể kích hoạt một khối tạm thời trên IP đó, không phụ thuộc vào việc yêu cầu đó nhắm đến dữ liệu công khai hay riêng tư — đây là một hạn chế đáng tin cậy cần lập kế hoạch xung quanh, không phải là một biện pháp bảo mật để đánh bại.
Quy trình này không trả về các kết nối, tin nhắn, hoặc bất kỳ trường nào chỉ có xác thực, theo thiết kế — việc mở rộng để làm điều đó sẽ yêu cầu đăng nhập, điều này di chuyển hoạt động ra ngoài phạm vi mà bài viết này đề cập và ngoài việc sử dụng được phép của LinkedIn.
Việc thu thập hàng loạt, không giới hạn tên và tiêu đề là một rủi ro tách biệt với chính phương pháp khai thác. Ngay cả dữ liệu công khai được khai thác đúng cách cũng có thể tạo ra sự phơi bày GDPR/CCPA khi nó được tập hợp thành cơ sở dữ liệu có thể tìm kiếm về những người có thể nhận diện.
Kết luận
Scraping public LinkedIn profile data is technically straightforward: fetch the logged-out page, parse its structured Person data, and manage request volume the way any responsible scraper manages request volume against any site. The harder part is staying inside the boundary LinkedIn's terms and current case law actually draw — public fields only, no login bypass, and a documented lawful basis before that data becomes a stored, searchable dataset of real people. Build the technical piece from the steps above — and for structuring this into a larger, maintained codebase rather than a one-off script, see building a Python web scraping project as a full pipeline — and treat the compliance piece as a gate the project passes through before it scales, not an afterthought bolted on once a scraper already works.
Q: Việc thu thập dữ liệu hồ sơ LinkedIn có hợp pháp không?
Scraping dữ liệu hiển thị mà không cần đăng nhập không tự nó vi phạm Đạo luật Lừa đảo và Lạm dụng Máy tính liên bang, theo các phán quyết của Tòa phúc thẩm Ninth trong vụ hiQ Labs kiện LinkedIn, nhưng nó vi phạm Thỏa thuận Người dùng của LinkedIn, và LinkedIn đã thắng một quyết định vi phạm hợp đồng chống lại hiQ trong cùng một vụ kiện. Xem "không phải vi phạm CFAA" và "được phép theo các điều khoản của LinkedIn" là hai câu hỏi khác nhau với hai câu trả lời khác nhau.
Q: Tôi có cần đăng nhập để chạy mã của hướng dẫn này không?
Không — mỗi bước trong hướng dẫn này hoạt động trên trang mà LinkedIn phục vụ cho những người truy cập không đăng nhập, và không có mã nào đính kèm cookie phiên hoặc thông tin xác thực. Đăng nhập để thu thập thêm các trường nằm ngoài phạm vi mà hướng dẫn này đề cập và ngoài việc sử dụng được phép của LinkedIn.
Q: Tôi có thể thu thập kết nối hoặc tin nhắn theo cách này không?
Không. Kết nối, tin nhắn và hầu hết các phần chi tiết trong hồ sơ chỉ hiển thị cho những người xem đã xác thực và không có mặt trong HTML đăng xuất hoặc khối JSON-LD của nó, vì vậy quy trình này không thể và không thu thập được chúng.
Q: Liệu LinkedIn có chặn IP của tôi nếu tôi chạy điều này trên quy mô lớn không?
Chạy nhiều yêu cầu nhanh từ một IP là mẫu hành vi có khả năng kích hoạt một khối tạm thời, độc lập với việc dữ liệu được yêu cầu có công khai hay không. Giãn cách các yêu cầu và xoay vòng thông qua một nhóm IP dân cư giảm thiểu rủi ro đó như một quy tắc về mẫu lưu lượng, không phải như một cách để vượt qua bất kỳ kiểm soát truy cập nào.
Q: Trường lấy dữ liệu JSON-LD trong Bước 2 có ổn định không?
LinkedIn có thể thay đổi định dạng trang và các trường dữ liệu cấu trúc mà không cần thông báo, vì vậy hãy xem mỗi bản đồ trường như một điều cần kiểm tra lại định kỳ thay vì một lược đồ vĩnh viễn, và hãy chuẩn bị cập nhật logic phân tích khi một trường bị thiếu.
Q: GDPR hoặc CCPA có áp dụng cho dữ liệu LinkedIn đã được thu thập không?
Có, ngay khi một bản ghi đã thu thập xác định một người thật, còn sống, các quy tắc bảo vệ dữ liệu tiêu chuẩn áp dụng giống như cách mà chúng sẽ áp dụng cho dữ liệu cá nhân thu thập qua bất kỳ phương pháp nào khác, bao gồm việc có cơ sở hợp pháp để giữ nó và một khoảng thời gian lưu trữ xác định.
Q: API chính thức của LinkedIn có phải là lựa chọn tốt hơn so với việc thu thập dữ liệu không?
Đối với hầu hết các trường hợp sử dụng, có — nơi có quyền truy cập — các API chính thức của LinkedIn bị hạn chế nghiêm ngặt cho các đối tác được phê duyệt cho hầu hết các loại dữ liệu, vì vậy nhiều nhóm ngoài chương trình đối tác đó phải lựa chọn giữa việc chỉ thu thập bề mặt công khai (phạm vi của hướng dẫn này) hoặc không thu thập dữ liệu nào cả; không có API công khai đa mục đích nào trả về dữ liệu hồ sơ đầy đủ cho các nhà phát triển tùy ý.
Q: Tôi nên làm gì trước khi thu thập dữ liệu trên quy mô thương mại?
Hãy để cố vấn pháp lý xem xét dữ liệu cụ thể đang được thu thập, các khu vực pháp lý của những người liên quan, và mục đích dự kiến, vì rủi ro vi phạm hợp đồng được chứng minh trong trường hợp của hiQ tồn tại độc lập với bất kỳ điều gì mà CFAA cho phép, và GDPR/CCPA thêm các yêu cầu riêng khi tập dữ liệu đủ lớn để trở thành một bề mặt tuân thủ thực sự.
Top 5 Zyte Alternatives for Web Scraping in 2026
So sánh năm lựa chọn thực tiễn thay thế Zyte cho việc thu thập dữ liệu trên web vào năm 2026, bao gồm các mô hình giá, định dạng đầu ra và những hạn chế chân thực của từng công cụ.
Ivy Lin
Sep. 7th 2026
110M+ IP that voi ti le truy cap thanh cong 99.9%
Phan hoi trung binh ~0.5s cho tac vu dong thoi cao
Chi tu $0.1/GB
Truy cap ngay cac pool proxy residential, datacenter, IPv6 va ISP cao cap.
