Firecrawl batch scrape: job, trạng thái, phân trang và báo cáo

Firecrawl batch scrape là cách gửi một danh sách URL vào một job duy nhất của Firecrawl, để dịch vụ tải song song rồi trả kết quả dạng Markdown hay HTML cho từng trang. Khác với gọi scrape từng URL một, batch đưa thêm một lớp việc: theo dõi trạng thái job, đọc kết quả theo trang, lấy danh sách lỗi riêng và quyết định khi nào dừng. ProxyVN chạy thử ngày 29/10/2026: gọi thật Firecrawl không khóa và với khóa giả để ghi lỗi, rồi dựng máy chủ giả lập job batch theo schema tài liệu cùng một website lab cục bộ. Kết quả cho thấy một bẫy dễ gặp: hủy job vì quá hạn rồi đọc kết quả quá sớm làm mất 7 trang đã tải và đã tính credit.

Firecrawl batch scrape: mục tiêu dữ liệu, quyền và phạm vi truy cập

Phần đầu chốt batch scrape dùng cho việc gì, đầu ra cần gì, và ranh giới với các bài khác cùng chủ đề.

Batch scrape là gì

Theo tài liệu Batch Scrape của Firecrawl, batch scrape cho phép tải nhiều URL trong một job. Anh em gửi danh sách URL cùng tùy chọn, Firecrawl xử lý song song và trả mọi kết quả cùng nhau. Cách gọi giống /crawl nhưng không tự đi theo link, chỉ tải đúng các URL được đưa vào.

API v2 có ba endpoint chính cho việc này: POST /v2/batch/scrape để tạo job, GET /v2/batch/scrape/{id} để xem trạng thái và kết quả, GET /v2/batch/scrape/{id}/errors để xem lỗi. Có thêm endpoint hủy job.

Đầu ra mà bài này hướng tới

Đầu ra là bảng báo cáo cho từng URL đầu vào: thành công, lỗi HTTP kèm mã, lỗi tải kèm loại lỗi, bị robots.txt chặn, URL không hợp lệ, hoặc chưa xong. Kèm theo là nội dung Markdown của các trang thành công, metadata nguồn và thông tin job như số credit đã dùng, thời điểm hết hạn.

Bảng báo cáo là thứ quan trọng nhất. Job báo completed không có nghĩa mọi URL đều có nội dung. Chỉ bảng từng URL mới cho biết phải làm gì với phần còn lại.

Chỉ đưa vào URL được phép

Batch scrape tải đúng những URL anh em đưa vào. Trách nhiệm chọn URL là của anh em: URL của website cho phép thu thập, không nằm trong vùng robots.txt cấm, không cần đăng nhập mà mình không có quyền. Bài robots.txt khi crawl website bàn cách kiểm.

Firecrawl có cơ chế riêng theo robots.txt. Endpoint errors trả trường robotsBlocked liệt kê URL bị chặn bởi robots.txt. Đó là lớp kiểm thứ hai, không thay cho lớp kiểm của anh em trước khi gửi.

Ranh giới với so sánh công cụ

Bài Crawl4AI và Firecrawl so sánh hai công cụ và cách dùng scrape đơn lẻ. Bài Crawl4AI proxy bàn cấu hình proxy cho Crawl4AI. Bài này không so sánh, không cài đặt Firecrawl tự host, mà chỉ bàn quy trình job batch: tạo, theo dõi, lấy kết quả, báo cáo.

Dữ liệu và quyền với nội dung

Nội dung tải về vẫn thuộc website nguồn. Firecrawl lưu kết quả job trên hệ thống của họ trong một khoảng thời gian. Tài liệu ghi kết quả job có qua API trong 24 giờ sau khi hoàn tất. Đừng đưa URL chứa token hay thông tin nhạy cảm vào job.

Lab không đăng ký tài khoản, không có khóa thật. Mọi số liệu về job trong bài đến từ máy chủ giả lập, với website lab tự dựng trên máy.

Ai cần batch scrape

Nhóm có sẵn danh sách URL từ sitemap hay từ kết quả tìm kiếm, cần nội dung của tất cả. Nhóm làm RAG cần làm mới định kỳ một tập trang tài liệu cố định. Nhóm theo dõi cần chụp nội dung một nhóm trang theo lịch.

Cả ba đều cần biết URL nào lỗi và vì sao, để chạy lại đúng phần lỗi thay vì chạy lại cả job.

Thu nhóm URL được phép bằng Firecrawl batch scrape và quản lý job, status, output

Vòng đời job

Phần này đi qua vòng đời của một job theo tài liệu.

Tạo job

import os, requests
B = "https://api.firecrawl.dev/v2/batch/scrape"
H = {"Authorization": f"Bearer {os.environ['FIRECRAWL_API_KEY']}",
     "Content-Type": "application/json"}
r = requests.post(B, headers=H, timeout=30, json={
    "urls": urls, "formats": ["markdown"],
    "maxConcurrency": 4, "ignoreInvalidURLs": True})
job = r.json()
print(job["id"], job.get("invalidURLs"))

Response có success, id, url của job, và invalidURLs. Tạo job trả về ngay, việc tải diễn ra sau.

ignoreInvalidURLs

Tài liệu ghi ignoreInvalidURLs mặc định true. Khi danh sách có URL không hợp lệ, chúng bị bỏ qua thay vì làm hỏng cả request, job được tạo với các URL hợp lệ còn lại, và URL không hợp lệ được trả trong invalidURLs.

Đọc invalidURLs ngay sau khi tạo job và ghi vào báo cáo. Nếu không đọc, các URL này biến mất khỏi job mà không ai biết.

maxConcurrency

Mặc định job dùng toàn bộ giới hạn trình duyệt đồng thời của nhóm. maxConcurrency giới hạn riêng cho job. Tài liệu lưu ý đặt quá thấp với batch lớn sẽ làm chậm đáng kể, chỉ hạ khi cần chừa chỗ cho job khác.

Với website nguồn nhỏ, giới hạn đồng thời cũng là cách lịch sự với máy chủ của họ. Hai mươi request song song tới một website cá nhân có thể làm nó chậm cho người dùng thật.

Trạng thái job

GET /v2/batch/scrape/{id} trả status là scraping, completed hoặc failed, cùng total là số trang đã thử, completed là số trang đã tải xong, creditsUsed, expiresAt, createdAt, completedAt, next và data. Mỗi phần tử data có markdown hay định dạng đã yêu cầu, cùng metadata gồm title, sourceURL, url, statusCode, error.

statusCode trong metadata là mã HTTP mà trang nguồn trả. Một trang 404 vẫn có thể nằm trong data với statusCode 404. Đếm data không đủ, phải đọc statusCode.

Trường next

Tài liệu ghi next là URL để lấy 10 MB dữ liệu tiếp theo, được trả khi job chưa hoàn tất hoặc khi response lớn hơn 10 MB. Ví dụ trong tài liệu có next dạng URL job kèm tham số skip.

Đây là phân trang của kết quả, không phải của danh sách URL. Đọc data của một response không có nghĩa đã có mọi kết quả. Phải đi theo next cho tới khi nó rỗng.

Endpoint errors

GET /v2/batch/scrape/{id}/errors trả errors là danh sách lỗi, mỗi lỗi có id, timestamp, url, error, và robotsBlocked là danh sách URL bị robots.txt chặn. Theo dõi thành công qua endpoint trạng thái, theo dõi thất bại qua endpoint này.

Webhook thay cho polling

Tài liệu mô tả có thể theo dõi job qua webhook thay vì poll liên tục. Webhook đẩy sự kiện về máy chủ của anh em khi trang xong hay job xong. Lab dùng polling vì không có máy chủ nhận webhook công khai. Với job lớn chạy định kỳ, webhook nhẹ hơn cho cả hai bên.

Kết quả gọi thật không có khóa hợp lệ

Bảng: Kết quả gọi thật không có khóa hợp lệ

Request	Mã	Giây	Thông báo
POST batch không khóa	401	1,05	Endpoint không có trong gói miễn phí không khóa
POST batch khóa giả	401	0,99	Unauthorized: Invalid token
GET job giả khóa giả	401	0,98	Unauthorized: Invalid token

Không có khóa, Firecrawl trả 401 với thông báo endpoint batch không được hỗ trợ ở gói miễn phí không khóa và mời đăng ký khóa. Như vậy một số endpoint khác có thể gọi được không khóa, nhưng batch thì không.

Chuẩn bị URL, khóa và phiên bản API cho Firecrawl batch scrape

Phần này gom các quyết định trước khi gửi job: làm sạch danh sách, khóa, hạn chót và môi trường giả lập.

Làm sạch danh sách URL

Trước khi gửi, chuẩn hóa và khử trùng URL. Lab cố ý đưa trang page-3 vào hai lần. Máy chủ giả lập tải cả hai lần và tính hai credit. Firecrawl thật xử lý URL trùng thế nào, lab không xác nhận được. Khử trùng phía client loại bỏ câu hỏi đó.

Loại URL không phải http hay https, URL không có tên máy. Lab đưa vào chuỗi khong-phai-url và một URL ftp. Cả hai bị trả lại trong invalidURLs.

Kiểm robots.txt trước khi gửi

Lọc URL bị robots.txt cấm ngay ở client. Website lab cấm thư mục private trong robots.txt. Nếu không lọc, URL này đi vào job, bị chặn, và chỉ xuất hiện trong robotsBlocked của endpoint errors. Lọc trước thì job sạch hơn và báo cáo rõ hơn.

Kích thước batch hợp lý

Không có con số chung cho kích thước batch. Batch quá nhỏ thì tốn request tạo job và poll cho mỗi vài URL. Batch quá lớn thì một lỗi ở giữa khó xử lý, và kết quả dài phải đi theo next nhiều lần. Với nhu cầu làm mới định kỳ, chia theo nhóm có ý nghĩa như theo website nguồn hay theo mục tài liệu.

Chia theo website nguồn còn có lợi ích khác: maxConcurrency có thể đặt riêng cho từng nhóm, phù hợp với sức chịu tải của từng website.

Theo dõi nhiều job cùng lúc

Khi chạy nhiều job song song, lưu id của từng job vào tệp hay cơ sở dữ liệu ngay khi tạo. Nếu tiến trình poll bị dừng giữa chừng, khởi động lại vẫn tìm được job đang chạy và đọc tiếp kết quả, miễn là chưa quá expiresAt.

Không có danh sách id, job vẫn chạy và vẫn tính credit trên hệ thống Firecrawl, nhưng kết quả không về tới anh em.

Đặt hạn chót cho job

Một trang chậm có thể giữ job ở trạng thái scraping lâu. Đặt hạn chót tính bằng giây từ lúc tạo job. Quá hạn thì hủy job hoặc chấp nhận kết quả từng phần, tùy nhu cầu. Không đặt hạn chót là để job treo vô thời hạn trong vòng poll.

Khóa và phiên bản

Khóa Firecrawl gửi qua Authorization dạng Bearer, đọc từ biến môi trường. Bài dùng API v2 với đường dẫn /v2/batch/scrape. Ghi phiên bản API vào cấu hình. Code mẫu cũ trên mạng có thể dùng v1 với khuôn response khác.

Máy chủ giả lập theo schema

Lab dựng hai máy chủ cục bộ. Cổng 9792 là website lab với 8 trang tài liệu, một trang 404, một trang 500, một trang chậm 6 giây, một trang trong thư mục private bị robots.txt cấm. Cổng 9793 là API giả lập với các endpoint tạo job, trạng thái có phân trang 4 kết quả mỗi trang, errors và hủy.

Worker của API giả lập tải thật từng trang của website lab bằng requests với timeout 4 giây, đọc robots.txt của website lab, chạy song song theo maxConcurrency. Chính sách tính credit của máy chủ giả lập là mỗi trang tải được một credit, kể cả trang 404 và 500. Đó không phải chính sách của Firecrawl.

Môi trường lab

Python 3.12.10, requests 2.34.2, http.server và concurrent.futures của thư viện chuẩn. Firecrawl có SDK firecrawl-py với hàm batch_scrape chờ tới khi xong. Lab gọi bằng requests để thấy rõ từng bước poll và phân trang.

Thu dữ liệu có phân trang và trạng thái job theo đúng nguồn với Firecrawl batch scrape

Phần này ghi kết quả hai lượt chạy trên máy chủ giả lập.

Lượt một: hạn chót 20 giây

Danh sách 15 URL: 8 trang tài liệu, trang 404, trang 500, trang private, trang chậm, 2 URL không hợp lệ, và page-3 lặp lại. Job tạo với maxConcurrency bằng 4.

Bảng: Lượt một: hạn chót 20 giây

Chỉ số	Giá trị
invalidURLs	2
total	13
completed	12
creditsUsed	11
Số lần poll	6
Số trang kết quả đi theo next	3
Tổng thời gian	6,76 giây
Trạng thái cuối	completed

Job hoàn tất sau 6,76 giây. Kết quả nằm trên 3 trang, client đi theo next để lấy đủ 11 phần tử data.

Báo cáo từng URL của lượt một

Báo cáo từng URL

Bảng: Báo cáo từng URL của lượt một

Kết quả	Số URL
Thành công	9, gồm page-3 hai lần
Lỗi HTTP 404 và 500	2
Lỗi tải ReadTimeout	1
Bị robots.txt chặn	1
URL không hợp lệ	2
Chưa xong	0

Trang 404 và 500 có trong data với statusCode tương ứng. Trang chậm vượt timeout 4 giây của worker, nằm trong errors với ReadTimeout. Trang private nằm trong robotsBlocked. Mỗi URL đầu vào có đúng một trạng thái trong báo cáo.

Lượt hai: hạn chót 3 giây

Cùng danh sách, maxConcurrency bằng 2, hạn chót 3 giây. Sau 3 giây job còn scraping, client gọi hủy, chờ nửa giây, đọc lại trạng thái. Trạng thái vẫn là scraping vì worker chưa dừng hẳn. Client lúc đó đọc kết quả.

completed đã là 11, creditsUsed đã là 11. Nhưng client chỉ lấy được 4 phần tử data. Báo cáo ghi 5 URL thành công, 1 bị robots chặn, 2 không hợp lệ, và 7 URL chưa xong.

Bẫy của lượt hai

Hủy rồi đọc quá sớm

Bảy URL bị báo chưa xong thật ra đã được tải và đã tính credit. Lỗi nằm ở client của lab: vòng đọc kết quả dừng sau trang đầu khi trạng thái còn scraping, vì next khi đó trỏ tới phần dữ liệu chưa có. Sau lệnh hủy, trạng thái chưa kịp chuyển sang trạng thái cuối.

Cách sửa: sau khi hủy, tiếp tục poll cho tới khi trạng thái là completed, failed hoặc trạng thái hủy, có hạn chót riêng cho bước chờ này. Chỉ đọc hết kết quả theo next khi job đã ở trạng thái cuối. Nếu không, anh em trả tiền cho trang mà mình không nhận được nội dung.

Hàm chờ trạng thái cuối sau khi hủy

TERMINAL = {"completed", "failed", "cancelled"}
def wait_terminal(jid, limit_s=30):
    t0 = time.time()
    while time.time() - t0 < limit_s:
        st = requests.get(f"{B}/{jid}", headers=H, timeout=30).json()
        if st["status"] in TERMINAL:
            return st
        time.sleep(1)
    return st

Hàm poll mỗi giây tới khi trạng thái nằm trong tập trạng thái cuối, có giới hạn thời gian riêng. Tên trạng thái sau khi hủy trên Firecrawl thật cần kiểm theo tài liệu endpoint hủy, máy chủ giả lập của lab dùng cancelled.

Lab chạy lại kịch bản hủy với 12 URL hợp lệ, hạn chót 3 giây, rồi gọi hàm này. Trạng thái chuyển sang cancelled sau 2,07 giây chờ. Đọc theo next sau đó lấy đủ 10 phần tử data, khớp creditsUsed bằng 10. Không còn trang nào đã tính credit mà không về tới client.

Gọi hàm này ngay sau lệnh hủy, rồi mới bắt đầu vòng đọc kết quả theo next. Nếu hết giới hạn mà vẫn chưa tới trạng thái cuối, ghi vào báo cáo là job chưa dừng hẳn, và lên lịch đọc lại kết quả sau, trước expiresAt.

Đọc kết quả từng phần trong lúc chạy

Tài liệu ghi next được trả khi job chưa hoàn tất. Nghĩa là có thể đọc kết quả từng phần trong lúc job đang chạy. Nếu làm vậy, ghi nhớ vị trí skip đã đọc, và sau khi job xong thì đọc tiếp từ vị trí đó, đừng bắt đầu lại từ đầu hay dừng giữa chừng.

Poll với giãn cách tăng dần

Client lab bắt đầu poll mỗi 0,5 giây, nhân 1,5 sau mỗi lần, tối đa 3 giây. Lượt một cần 6 lần poll cho job 6,76 giây. Poll dày hơn không làm job nhanh hơn, chỉ tốn request và có thể chạm giới hạn tần suất.

Đối soát ID, kiểu dữ liệu, giá trị thiếu và xuất xứ từng kết quả Firecrawl batch scrape

Phần này bàn cách ghép kết quả với đầu vào và các trường cần kiểm.

Ghép theo sourceURL

Mỗi phần tử data có metadata.sourceURL là URL đã gửi, và metadata.url là URL cuối sau chuyển hướng. Ghép kết quả với danh sách đầu vào theo sourceURL. Dùng url cuối để ghép sẽ hỏng khi trang chuyển hướng.

Lab ghép theo sourceURL và gán đúng một trạng thái cho mỗi URL đầu vào. URL không có trong data, errors, robotsBlocked hay invalidURLs là chưa xong.

statusCode khác 200

Phần tử data có statusCode 404 hay 500 vẫn có markdown, là nội dung trang lỗi. Đừng đưa markdown đó vào kho tài liệu. Lọc theo statusCode trước khi lưu. Bài lỗi 410 Gone khi crawl bàn cách xử lý trang đã bị gỡ.

Lỗi tải và lỗi HTTP là hai loại

Lỗi HTTP là trang nguồn trả mã lỗi, nằm trong data. Lỗi tải là không lấy được trang, như hết thời gian chờ, nằm trong errors. Báo cáo cần tách hai loại, vì cách xử lý khác nhau. Lỗi HTTP thường không nên thử lại ngay. Lỗi hết thời gian chờ có thể thử lại với timeout dài hơn.

creditsUsed so với số trang nhận được

So creditsUsed với số phần tử data có statusCode 200. Ở lượt một của lab, 11 credit cho 9 trang thành công, vì máy chủ giả lập tính cả 404, 500 và trang lặp. Ở lượt hai, 11 credit cho 4 trang nhận được vì lỗi đọc kết quả.

Chênh lệch lớn giữa credit và trang thành công là tín hiệu cần xem lại danh sách đầu vào hoặc code đọc kết quả.

Giữ xuất xứ cho từng trang

Mỗi trang lưu sourceURL, url cuối, statusCode, title, job id, thời điểm, định dạng đã yêu cầu. Kết quả hết hạn sau 24 giờ theo tài liệu, nên lưu về hệ thống của mình ngay khi job xong. Bài JSON và CSV khi crawl dữ liệu bàn cách tổ chức.

expiresAt là hạn đọc kết quả

expiresAt cho biết khi nào kết quả không còn đọc được qua API. Job chạy lúc nửa đêm mà sáng hôm sau mới có người xử lý vẫn kịp, nhưng job chạy thứ sáu mà thứ hai mới đọc thì mất. Đọc và lưu kết quả ngay trong code tạo job, không để cho một bước thủ công sau đó.

Lưu kết quả, giới hạn request và khi nào Firecrawl batch scrape cần proxy

Phần cuối bàn chuyện chạy lại, nhịp gọi và vị trí của proxy.

Chạy lại đúng phần lỗi

Từ bảng báo cáo, lấy URL có trạng thái lỗi tải hay chưa xong, tạo job mới chỉ với các URL đó. Không chạy lại URL đã thành công, không chạy lại URL bị robots chặn, không chạy lại URL không hợp lệ. Mỗi lần chạy lại là một khoản credit.

Tách job theo loại trang

Trang tài liệu tĩnh, trang chậm và trang cần chờ JavaScript nên nằm ở các job khác nhau. Trang chậm trong job chung kéo dài thời gian của cả job và làm job có nguy cơ chạm hạn chót. Lab thấy rõ điều này: một trang chậm 6 giây quyết định thời gian của lượt một.

Khi đã biết một URL hay chậm, đưa nó vào job riêng với timeout dài hơn, để các trang nhanh không phải chờ.

Giới hạn tần suất

Tài liệu liệt kê 429 với thông báo vượt giới hạn tần suất cho cả endpoint tạo job và endpoint trạng thái. Poll quá dày cũng tính vào giới hạn. Giãn cách poll và dùng webhook cho job lớn. Bài rate limit API khi dùng proxy có mẫu bộ đếm.

Mã 402

Tài liệu liệt kê 402 Payment Required cho cả tạo job và đọc trạng thái. Hết credit giữa chừng nghĩa là job có thể dừng với phần URL chưa xong. Kiểm số credit còn lại trước khi tạo job lớn.

Proxy trong lab kiểm ở đâu

Lab chạy một job hai URL qua proxy HTTP có xác thực cục bộ: tạo job, poll, đọc kết quả, đọc errors đều đi qua proxy. Job hoàn tất, 2 trên 2 URL thành công. Log proxy ghi 5 request tới cổng 9793 của API giả lập. Với Firecrawl thật qua HTTPS, proxy chỉ thấy CONNECT tới api.firecrawl.dev cổng 443.

Proxy của anh em không phải proxy tải trang

Proxy ở máy anh em chỉ đứng giữa anh em và API của Firecrawl. Việc tải trang nguồn do hạ tầng của Firecrawl làm. Website nguồn thấy IP của Firecrawl, không thấy proxy của anh em. Đổi proxy ở phía client không đổi kết quả tải trang.

Tài liệu batch scrape của Firecrawl có tham số proxy với các giá trị basic, enhanced và auto, mặc định auto, để chọn loại proxy phía dịch vụ khi tải trang. Đó là cấu hình của Firecrawl, không phải proxy của anh em. Bài không bàn chuyện chọn loại nào để vượt cơ chế chống bot của website nguồn.

Khi nào cần proxy thật

Proxy cần khi máy chạy job nằm trong mạng nội bộ chỉ được ra Internet qua proxy. Trường hợp thứ hai là tổ chức yêu cầu lưu lượng tới dịch vụ bên ngoài đi qua một IP cố định để giám sát. Cấu hình và mã hóa mật khẩu có ký tự đặc biệt có trong bài định dạng proxy.

Bài Web Scraping proxy là gì phân biệt các vai trò của proxy trong thu thập dữ liệu.

Khi máy chủ của nhóm đặt tại Việt Nam và cần IP thoát ổn định cho các job gọi API bên ngoài, proxy tĩnh dễ quản lý hơn proxy xoay. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay qua HTTP hoặc SOCKS5. Anh em có thể mua proxy Việt Nam tại trang chủ ProxyVN rồi khai báo vào requests theo tham số proxies.

Giới hạn suy luận của bài

Lab chỉ gọi Firecrawl thật ba lần ngày 29/10/2026, không có khóa hợp lệ, để ghi mã 401. Mọi số liệu về job, trạng thái, phân trang, credit, errors và robotsBlocked đến từ máy chủ giả lập tự viết theo schema tài liệu v2, với website lab cục bộ. Chính sách credit, kích thước trang kết quả và thời gian của máy chủ giả lập không phải của Firecrawl.

Lab không có tài khoản, không thử webhook, không thử formats ngoài markdown, không thử endpoint hủy của Firecrawl thật, không thử proxy thương mại. Bẫy đọc kết quả sau khi hủy là lỗi trong client của lab, được ghi lại để anh em tránh.

Checklist Firecrawl batch scrape

Checklist Firecrawl batch

• Chuẩn hóa, khử trùng và lọc robots.txt trước khi gửi.
• Đọc invalidURLs ngay sau khi tạo job.
• Đặt maxConcurrency hợp với website nguồn.
• Poll giãn cách tăng dần, có hạn chót.
• Sau khi hủy, chờ trạng thái cuối rồi mới đọc kết quả.
• Đi theo next tới hết, ghép theo sourceURL.
• Lấy errors và robotsBlocked, báo cáo từng URL.
• Lưu kết quả trước expiresAt, chạy lại đúng phần lỗi.

Câu hỏi thường gặp về Firecrawl batch scrape

Batch scrape khác crawl thế nào?

Batch chỉ tải đúng URL được đưa vào. Crawl tự đi theo link từ URL gốc.

Kết quả batch giữ được bao lâu?

Tài liệu ghi kết quả có qua API trong 24 giờ sau khi job hoàn tất. Xem expiresAt của job.

URL không hợp lệ đi đâu?

Với ignoreInvalidURLs mặc định true, chúng bị bỏ khỏi job và trả trong invalidURLs.

Vì sao job completed mà vẫn thiếu trang?

Có thể trang lỗi HTTP, lỗi tải, bị robots chặn, hoặc code chưa đi hết next. Đối chiếu từng URL với data, errors và robotsBlocked.

Gọi batch không khóa được không?

Lab nhận 401 với thông báo batch không có trong gói miễn phí không khóa.

Proxy của mình có đổi IP mà website nguồn thấy không?

Không. Website nguồn thấy hạ tầng của Firecrawl. Proxy của anh em chỉ nằm giữa anh em và API.

Firecrawl batch scrape và những điều cần nhớ

Firecrawl batch scrape gom nhiều URL vào một job, đổi lại anh em phải quản lý trạng thái, phân trang kết quả và báo cáo từng URL. Lab ngày 29/10/2026 trên máy chủ giả lập cho báo cáo đủ 15 URL ở lượt có hạn chót rộng, nhưng lượt hủy sớm làm mất 7 trang đã tính credit vì đọc kết quả trước khi job dừng hẳn. Làm sạch đầu vào, chờ trạng thái cuối, đọc hết next. Cần IP thoát cố định cho máy chủ gọi Firecrawl batch scrape, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.