← Tất cả bài viết

Cào Dữ Liệu Các Trang Tuyển Dụng Mà Không Bị Dừng Lại Ở Mức 50 Lần Lưu

Việc cào dữ liệu trang tuyển dụng đã trở thành một trong những công việc khó nhất trên web mở vào năm 2026. Đây là những gì đã thay đổi và cách các nhóm talent intelligence tiếp tục thu thập dữ liệu.

Thách thức

Một benchmark từ ApplyArc vào tháng 6 năm 2026 đã thử nghiệm 5 công cụ scraper tin tuyển dụng LinkedIn trên 200 lượt trích xuất dữ liệu việc làm thực tế. 3 công cụ đã khiến tài khoản bị gắn cờ hoặc bị bóp băng thông âm thầm sau khoảng 50 lượt lưu. Chỉ có 2 công cụ vượt qua trót lọt.

Benchmark đó phản ánh toàn bộ thực tế. Các trang tuyển dụng từng là mục tiêu dễ khai thác. Giờ đây chúng nằm trong số những trang web khó xử lý nhất trên web mở.

Nếu bạn đang xây dựng bất kỳ giải pháp nào phụ thuộc vào dữ liệu tin tuyển dụng (quy hoạch nhân sự, đối chuẩn tiền lương, lập bản đồ nhân tài, dùng tín hiệu tuyển dụng để nghiên cứu cổ phiếu), tầng thu thập dữ liệu của bạn đang phải đối đầu với một loạt lớp bảo vệ chưa từng tồn tại hai năm trước. Indeed hiển thị trang xác minh cho các phiên truy cập lạ. LinkedIn liên kết các tín hiệu phía trình duyệt qua các lần xoay vòng IP. Glassdoor giới hạn rate limit theo từng ASN thay vì từng IP. ZipRecruiter đẩy dải lương và ngày đăng vào JavaScript, chỉ render khi header của bạn trông giống một người dùng thực tế thay vì một script.

Vì vậy, rào cản 50 lượt lưu không phải là vấn đề riêng của LinkedIn. Đó là đặc tính chung của toàn bộ nhóm này.

Lý do các trang tuyển dụng ngày càng khó cào dữ liệu

Ba yếu tố đã thay đổi vào năm 2026 và kết hợp lại với nhau.

Đầu tiên là hệ thống phát hiện bot đã chuyển sang phân tích hành vi. Các bước kiểm tra tĩnh (User-Agent, danh tiếng IP, số lượng request mỗi giây) từng đủ để ngăn chặn các scraper nghiệp dư. Giờ thì không còn tác dụng. Các lớp bảo vệ hiện nay theo dõi cách bạn di chuyển trên trang: bạn tải những trang nào theo thứ tự ra sao, thời gian dừng lại bao lâu, bạn có tải lại các gói JS mà một trình duyệt thực sự sẽ lưu vào cache hay không. Chúng tôi đã viết về sự thay đổi đó trong Hệ thống phát hiện bot đã chuyển sang phân tích hành vi. Các trang tuyển dụng đã áp dụng phương pháp này từ sớm vì khách truy cập của họ chỉ thực hiện một số ít hành động lặp lại (tìm kiếm, nhấp chuột, đọc, lưu), điều đó khiến một script rất dễ bị phát hiện khi bỏ qua một nửa quy trình này.

Thứ hai là quy mô proxy pool không còn đóng vai trò quyết định. Một pool 50 triệu IP dân cư không mang lại lợi ích gì khi cơ chế phòng thủ dựa trên việc liên kết fingerprint ở tầng kết nối kết hợp với danh tiếng ASN. Chúng tôi đã đề cập đến vấn đề đó trong bài Lý do quy mô proxy pool không còn quan trọng. Giải pháp hiệu quả là chọn đúng điểm thoát cho trang web mục tiêu, thay vì sở hữu nhiều điểm thoát hơn những người khác.

Thứ ba là vấn đề pháp lý. Cả Indeed và LinkedIn đều sở hữu đội ngũ pháp lý sẵn sàng khởi kiện. Kỷ nguyên vận hành một scraper công khai từ IP tại nhà đã kết thúc đối với bất kỳ ai có kế hoạch thương mại hóa dữ liệu họ thu thập được.

Mô hình thu thập dữ liệu hiện nay

Đối với mảng phân tích thông tin nhân tài vào năm 2026, mô hình duy trì hiệu quả là một stack tách biệt: thực hiện fetch qua render bằng trình duyệt thực cho các trang tuyển dụng được bảo vệ, kết hợp với việc lựa chọn điểm thoát cẩn thận để bạn không đến từ cùng một nhà cung cấp với mọi bot khác.

Với một nền tảng như FourA, quy trình đó là sự kết hợp giữa hai sản phẩm giao tiếp với nhau.

Browser xử lý phần rendering: gửi một URL cùng unblocker: true, nhận lại HTML đã render, cookie, và ảnh chụp màn hình từ một phiên trình duyệt thực tế. JS được thực thi, các trường lazy-load được tải đầy đủ, và request vượt qua các bước kiểm tra tầng kết nối vốn chặn phần lớn client cơ bản. Quá trình chọn proxy diễn ra ngầm bên dưới: nền tảng chọn một exit cho mỗi request và trả về ID base36 ẩn danh của nó trong response (tại r.proxy cấp cao nhất trên Single/Browser, hoặc r.session.proxy trên Auto), giúp các lệnh gọi tiếp theo có thể tái sử dụng cùng một exit khi bạn cần duy trì session. Đối với hầu hết tác vụ cào job board, Auto là điểm khởi đầu phù hợp, nó tự động điều phối Single, Proxy, và Browser dựa trên nhu cầu của từng mục tiêu, giúp code của bạn không cần phải tự xử lý.

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"Authorization": "Bearer pk_live_..."},
    json={
        "url": "https://www.example-jobs.com/search?q=data+engineer&l=Remote",
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ["data-testid=\"job-card\""],
                       "fail":   ["Just a moment", "captcha"]},
        },
    },
).json()

# r["data"] or r["body"]   — rendered content (Auto picks Single→"data" or Browser→"body" per host)
# r["session"]              — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# Reuse r["session"]["proxy"] on the next call to stick to the same exit, or pass it
# via `ignoreProxies: [<id>]` to force a different one.

Hai lưu ý về những giá trị thực tế mà giải pháp này mang lại.

Giới hạn chặn 50 lượt lưu kiểu ApplyArc phần lớn là vấn đề về session, không phải vấn đề về pool proxy. Một browser session thực thụ, được luân chuyển hợp lý, duy trì hoạt động lâu hơn nhiều trước khi kích hoạt rate limit so với một HTTP client thông thường. Ngoài ra, response trả về một proxy id ẩn danh thay vì một IP exit thô, giúp mã nguồn của bạn luôn tinh gọn và không phải theo dõi IP exit nào đã xử lý request nào.

Lưu ý thứ hai là về những gì KHÔNG nằm trong đoạn mã ví dụ. Việc khử trùng lặp (deduplication) trên nhiều nền tảng tuyển dụng (cùng một vị trí data engineer trên LinkedIn, Indeed và trang tuyển dụng riêng của công ty, với ba chức danh hơi khác nhau) là bài toán của bạn, không phải của tầng thu thập dữ liệu. Chúng tôi đã thấy nhiều nhóm đánh giá thấp vấn đề này. Chuẩn hóa dữ liệu tiêu tốn nhiều thời gian kỹ thuật hơn cả việc fetch dữ liệu, và đó chính là nơi hầu hết các sản phẩm talent intelligence cạnh tranh với nhau.

Kết quả

Một nhóm talent intelligence theo dõi 200 công ty trên ba nền tảng tuyển dụng cần khoảng 50.000 lượt fetch trang mỗi tuần: kết quả tìm kiếm, trang chi tiết công việc và các đợt làm mới trang công ty định kỳ. Các chỉ số bạn cần hướng tới cho khối lượng công việc đó:

  • Tỷ lệ thành công trên 95% đối với các mục tiêu tương đương Indeed, trong đó thành công có nghĩa là HTML đã được render đầy đủ dải lương và ngày đăng tin.
  • Chi phí cho mỗi tin tuyển dụng dưới $0.004 toàn trình, đã bao gồm render và lựa chọn IP exit.
  • Tần suất làm mới từ 6 đến 12 giờ cho các vị trí đang tuyển, giúp dashboard tín hiệu tuyển dụng của bạn không bị trễ so với thị trường.

Các số liệu này mang tính chất tham khảo, dựa trên báo cáo từ các nhóm đang áp dụng mô hình phân tách kiến trúc này. Chi phí thực tế của bạn phụ thuộc vào các nền tảng bạn nhắm tới và mức độ quyết liệt khi lọc các tin đăng mới.

Điểm mấu chốt

Độ khó khi cào dữ liệu các nền tảng tuyển dụng hiện nay đã gần với ad-tech và bán vé hơn là e-commerce thông thường. Đây là một sự chuyển dịch thực sự, giải thích lý do vì sao các thư viện scraping từng hoạt động tốt trong năm 2024 lại liên tục bị chặn vào năm 2026.

Những nhóm mở rộng quy mô thành công không còn xem "scraper" là một khối xử lý duy nhất. Họ tách session, IP exit và khử trùng lặp thành ba bài toán riêng biệt, đồng thời mua hạ tầng cho hai phần đầu để kỹ sư của họ có thể tập trung thời gian vào phần thứ ba. Dữ liệu tin tuyển dụng rẻ nhất chính là dữ liệu bạn không phải thu thập lại sau khi bị gắn cờ cảnh báo.