Chuyên gia SEO bắt đầu kiểm toán kỹ thuật cho một trang web lớn — và sau 10 phút, Screaming Frog bắt đầu trả về toàn bộ 403 Forbidden hoặc 429 Too Many Requests. Máy chủ bảo vệ đã nhận diện crawler như một bot tấn công và đã chặn địa chỉ IP. Kết quả — kiểm toán sẽ phải khởi động lại, và khách hàng sẽ phải giải thích tại sao báo cáo bị trì hoãn. Vấn đề này có thể được giải quyết bằng cách cấu hình proxy cho crawler một cách hợp lý — chúng ta sẽ phân tích cách thực hiện.
Tại sao các trang web chặn Screaming Frog trong quá trình kiểm toán
Screaming Frog, Sitebulb, JetOctopus và Netpeak Spider về mặt kỹ thuật hoạt động giống như các bot của công cụ tìm kiếm: chúng nhanh chóng duyệt qua hàng ngàn URL liên tiếp, tải xuống HTML, CSS, JS và hình ảnh, kiểm tra chuyển hướng và mã trạng thái. Từ quan điểm bảo vệ trang web (Cloudflare, Qrator, DDoS-Guard, WAF tích hợp của hosting), điều này có vẻ như là hoạt động đáng ngờ — quá nhiều yêu cầu từ một IP trong thời gian ngắn.
Các chặn thường xảy ra nhất trong quá trình kiểm toán:
- các cửa hàng trực tuyến lớn trên cơ sở hạ tầng tương tự Wildberries với bảo vệ chống lại việc phân tích;
- các trang web sau Cloudflare với chế độ "Đang tấn công" hoặc mức độ bảo mật cao;
- các cổng thông tin với nội dung động, nơi mỗi yêu cầu tạo ra tải cho máy chủ (tìm kiếm, bộ lọc, danh sách sản phẩm);
- các trang web của đối thủ mà bạn phân tích không từ miền của mình — họ không có lý do gì để tin tưởng vào IP của bạn.
Sự phức tạp thêm: nếu một công ty chỉ có một IP tĩnh cho văn phòng, và việc kiểm toán các trang web diễn ra thường xuyên (vài khách hàng mỗi ngày), IP này nhanh chóng bị đưa vào danh sách đen của các hệ thống bảo vệ. Sau đó, không chỉ các kiểm toán hiện tại bị chặn, mà cả các kiểm toán tương lai từ cùng một địa chỉ — ngay cả đối với các trang web mà trước đây mở ra mà không gặp vấn đề gì.
Cách nhận diện chặn theo mã phản hồi
Trước khi thay đổi cài đặt proxy, điều quan trọng là phải hiểu chính xác điều gì đang xảy ra. Screaming Frog hiển thị mã phản hồi trong cột Mã Trạng Thái — từ đó dễ dàng xác định nguyên nhân dừng crawling.
| Mã phản hồi | Điều này có nghĩa là gì | Cần làm gì |
|---|---|---|
| 403 Forbidden | IP bị chặn bởi bảo vệ trang web | Thay đổi IP, giảm tốc độ crawling |
| 429 Too Many Requests | Vượt quá giới hạn yêu cầu trong một khoảng thời gian | Giảm số lượng luồng, thêm độ trễ |
| 503 Service Unavailable | Máy chủ quá tải hoặc bảo vệ chống bot đã được bật | Thay đổi User-Agent, sử dụng IP cư trú |
| Không có phản hồi / Timeout | IP trong danh sách đen, yêu cầu không đến được | Thay thế hoàn toàn pool proxy |
Nếu trong báo cáo xuất hiện hàng loạt cùng một mã trên hàng ngàn URL liên tiếp — điều này gần như luôn là chặn theo IP, chứ không phải là vấn đề thực sự của trang web. Kiểm tra giả thuyết rất đơn giản: mở URL gặp vấn đề trong trình duyệt thông thường từ cùng một IP. Nếu trang mở bình thường, trong khi Screaming Frog nhận được 403 — vấn đề nằm ở crawler, chứ không phải ở trang web.
Loại proxy nào phù hợp cho SEO-crawling
Việc chọn loại proxy phụ thuộc vào nhiệm vụ: kiểm toán một lần cho trang web của bạn, theo dõi đối thủ thường xuyên hoặc quét một thị trường bảo vệ. Chúng ta sẽ phân tích ba loại chính và tính khả thi của chúng cho các crawler.
| Loại proxy | Tốc độ | Rủi ro bị chặn | Khi nào sử dụng |
|---|---|---|---|
| Proxy trung tâm dữ liệu | Cao | Trung bình-cao trên các trang web bảo vệ | Kiểm toán trang web của bạn mà không có bảo vệ nghiêm ngặt |
| Proxy cư trú | Trung bình | Thấp | Kiểm toán đối thủ, các trang web sau Cloudflare, thị trường |
| Proxy di động | Trung bình-thấp | Tối thiểu | Các bảo vệ cực kỳ mạnh mẽ, kiểm toán điểm hiếm |
Đối với hầu hết các kiểm toán kỹ thuật định kỳ, proxy cư trú cung cấp sự cân bằng tối ưu — chúng sử dụng địa chỉ IP thực từ các nhà cung cấp, vì vậy bảo vệ trang web coi các yêu cầu của crawler như lưu lượng truy cập của người dùng bình thường. Điều này đặc biệt quan trọng nếu bạn đang phân tích không phải miền của mình, mà là trang web của đối thủ hoặc thị trường với hệ thống chống bot mạnh mẽ.
Proxy trung tâm dữ liệu vẫn là một lựa chọn tốt khi bạn kiểm toán trang web của mình và có thể thêm trước dải IP vào danh sách trắng ở cấp độ WAF hoặc Cloudflare — thì tốc độ quét sẽ tối đa mà không có rủi ro bị chặn.
Hướng dẫn từng bước cấu hình proxy trong Screaming Frog
Screaming Frog hỗ trợ proxy "ngay từ đầu", việc cấu hình chỉ mất vài phút:
- Mở chương trình và vào menu Cấu hình → Hệ thống → Proxy.
- Đánh dấu vào ô Sử dụng máy chủ proxy cho tất cả lưu lượng.
- Nhập địa chỉ và cổng của máy chủ proxy mà bạn nhận được từ nhà cung cấp.
- Nếu proxy yêu cầu xác thực bằng tên đăng nhập và mật khẩu — hãy chỉ định chúng trong cửa sổ pop-up khi có yêu cầu đầu tiên.
- Nhấn OK và khởi động lại crawling để áp dụng cài đặt.
Một điểm quan trọng: Screaming Frog trong phiên bản miễn phí và trả phí chỉ có thể làm việc với một máy chủ proxy tại một thời điểm thông qua giao diện tích hợp. Nếu cần xoay vòng IP ngay lập tức (cần thiết khi quét từ 50.000 trang trở lên), hãy sử dụng proxy với việc thay đổi IP tự động từ phía nhà cung cấp — điều này được cấu hình không trong chính crawler mà trong tài khoản cá nhân của dịch vụ proxy, nơi bạn có thể đặt khoảng thời gian thay đổi IP (ví dụ, mỗi 10 phút hoặc khi có yêu cầu mới).
Sơ đồ này giảm tải cho một địa chỉ: crawler tiếp tục hoạt động với một cổng, trong khi IP phía sau nó thay đổi tự động, và trang web không thấy tần suất yêu cầu bất thường cao từ một địa chỉ cụ thể.
Cài đặt tốc độ và luồng cho các trang web lớn
Ngay cả với proxy hoạt động, các cài đặt tốc độ quá mạnh có thể gây ra việc bị chặn. Trong Screaming Frog, điều này được điều chỉnh trong phần Cấu hình → Tốc độ. Các giá trị được khuyến nghị cho các trang web từ 100.000 trang:
- Luồng tối đa: 2–5 cho các trang web bảo vệ, 10–15 cho các trang web không có bảo vệ nghiêm ngặt;
- URI tối đa/s: giới hạn 2–3 yêu cầu mỗi giây khi bắt đầu, từ từ tăng lên, theo dõi các mã phản hồi;
- User-Agent tùy chỉnh: trong phần Cấu hình → HTTP Header, sử dụng User-Agent của trình duyệt thực thay vì "Screaming Frog SEO Spider" tiêu chuẩn, nếu trang web chặn các crawler theo tiêu đề;
- Tôn trọng robots.txt / crawl-delay: hãy xem xét chỉ thị Crawl-delay nếu nó được ghi rõ — việc bỏ qua thường dẫn đến việc bị cấm ở cấp độ máy chủ.
Đối với các trang web có bảo vệ chống bot mạnh mẽ, cũng có ích khi bật chế độ JavaScript Rendering chỉ ở những nơi thực sự cần thiết (các trang SPA trên React/Vue) — việc render JS làm tăng tải lên máy chủ và làm tăng khả năng bị chặn khi crawling qua một IP.
Xoay vòng IP khi quét hơn 100.000 trang
Càng lớn trang web, việc phân bổ tải giữa các địa chỉ IP càng quan trọng. Đối với các kiểm toán quy mô lớn như vậy, có hai sơ đồ hoạt động:
Xoay vòng theo thời gian. IP thay đổi tự động mỗi 5–15 phút bất kể số lượng yêu cầu. Phù hợp cho việc crawling lâu dài đồng đều, khi việc quét kéo dài trong vài giờ.
Xoay vòng theo yêu cầu. Mỗi yêu cầu HTTP mới được gửi từ một IP mới trong pool. Chế độ này cung cấp bảo vệ tối đa chống lại việc bị chặn, nhưng có thể gây khó khăn cho việc làm việc chính xác với xác thực dựa trên cookie hoặc các tham số phiên của trang web — đối với một kiểm toán kỹ thuật sạch (thu thập mã trạng thái, chuyển hướng, thẻ meta) thì điều này không quan trọng.
Đối với các công ty thực hiện kiểm toán song song cho nhiều trang web của khách hàng, việc phân chia pool IP theo dự án là hợp lý — điều này ngăn chặn tình huống mà việc chặn trên một miền "vô tình" lan rộng đến danh tiếng của IP khi làm việc với một trang web khác.
Mẹo thực tiễn: trước khi thực hiện một kiểm toán lớn, hãy khởi động một crawling thử nghiệm trên 500–1000 URL với các cài đặt tốc độ và proxy hiện tại. Nếu trong thời gian này không xuất hiện lỗi 403/429, bạn có thể tự tin mở rộng quét trên toàn bộ trang web.
Danh sách kiểm tra trước khi khởi động kiểm toán
- ✅ Proxy đã được kết nối và kiểm tra khả năng truy cập (kiểm tra qua curl hoặc trình duyệt riêng);
- ✅ Luồng tối đa và URI tối đa/s được thiết lập một cách bảo thủ cho lần chạy đầu tiên;
- ✅ User-Agent được cấu hình chính xác, không gây nghi ngờ cho WAF;
- ✅ Tôn trọng robots.txt đã được bật, nếu trang web rõ ràng yêu cầu tuân thủ Crawl-delay;
- ✅ JavaScript Rendering chỉ được bật khi thực sự cần thiết;
- ✅ Cấu hình xoay vòng IP cho các trang web từ 20.000–30.000 trang;
- ✅ Lưu tiến trình crawling đã được bật (Cấu hình → Lưu Crawl) để phòng trường hợp ngắt kết nối;
- ✅ Đối với kiểm toán các thị trường và cổng thông tin bảo vệ, đã chọn proxy cư trú hoặc di động thay vì trung tâm dữ liệu.
Những sai lầm thường gặp khi crawling qua proxy
Tốc độ quá cao ngay từ đầu. Các chuyên gia thường đặt tối đa số luồng ngay lập tức, hy vọng tăng tốc độ kiểm toán. Kết quả là bảo vệ trang web phản ứng ngay lập tức, và chỉ sau vài phút, toàn bộ pool proxy bị đưa vào danh sách đen.
Chỉ một IP tĩnh cho tất cả các dự án của khách hàng. Nếu công ty sử dụng cùng một proxy trung tâm dữ liệu cho hàng chục kiểm toán mỗi tháng, danh tiếng của IP này nhanh chóng giảm — các hệ thống bảo vệ của các trang web khác trao đổi thông tin về các địa chỉ đáng ngờ thông qua các cơ sở dữ liệu chung (ví dụ: Danh tiếng IP của Cloudflare).
Bỏ qua geo-targeting. Nếu trang web đang được kiểm toán được cấu hình cho một khu vực cụ thể (ví dụ: cửa hàng trực tuyến của Nga với việc geo-blocking lưu lượng truy cập nước ngoài), việc sử dụng proxy với IP của quốc gia khác sẽ tự nó gây ra việc hạn chế truy cập — ngay cả khi không có crawling mạnh mẽ.
Thiếu giám sát trong quá trình. Khi khởi động crawling trong vài giờ, các chuyên gia thường không kiểm tra các mã phản hồi trung gian. Kết quả là họ chỉ phát hiện vấn đề sau khi hoàn thành, khi một nửa báo cáo bao gồm các lỗi chặn, chứ không phải dữ liệu thực về trang web.
Kết luận
Việc bị chặn trong kiểm toán kỹ thuật trong Screaming Frog gần như luôn được giải quyết bằng sự kết hợp của ba yếu tố: loại proxy đúng, tốc độ crawling hợp lý và xoay vòng IP hợp lý. Đối với các trang web của riêng bạn mà không có bảo vệ nghiêm ngặt, chỉ cần proxy trung tâm dữ liệu với việc thêm vào danh sách trắng. Đối với việc kiểm toán các đối thủ, thị trường và các trang web sau Cloudflare, cần có IP trông giống như lưu lượng truy cập của người dùng bình thường.
Nếu bạn thường xuyên kiểm toán các miền của người khác hoặc các nền tảng bảo vệ, chúng tôi khuyên bạn nên bắt đầu với proxy cư trú — chúng giảm thiểu rủi ro bị chặn trên các hệ thống chống bot mạnh mẽ nhất. Đối với các nhiệm vụ cụ thể trên các tài nguyên được bảo vệ tối đa, hãy xem xét proxy di động, trong khi cho các kiểm toán quy mô lớn trên cơ sở hạ tầng của riêng bạn, proxy trung tâm dữ liệu vẫn là một giải pháp tốt và nhanh chóng.