Chỉ một năm trước, việc lấy dữ liệu từ Google có thể thực hiện bằng một GET-request với tham số num=100 — một trăm kết quả được gửi về dưới dạng HTML thuần. Vào năm 2026, điều này không còn hiệu quả nữa: Google đã chấm dứt quyền truy cập mà không cần JavaScript, cắt giảm số lượng kết quả trên mỗi trang xuống còn một trăm và thêm vào kết quả một khối AI Overviews, được render một cách bất đồng bộ và không thể nhìn thấy từ mọi IP. Chúng ta sẽ tìm hiểu cách thu thập SERP trong điều kiện mới, nơi có những cạm bẫy ẩn giấu và tại sao việc lựa chọn loại proxy trở nên quan trọng hơn cả trình thu thập dữ liệu.
Ai là người cần hướng dẫn này
Việc thu thập dữ liệu từ kết quả tìm kiếm (SERP scraping) không chỉ liên quan đến vị trí SEO. Ngày nay, nó được sử dụng bởi:
- Các chuyên gia SEO và các agency — theo dõi lưu lượng tự nhiên, featured snippets, "Người cũng hỏi", kết quả địa phương và xem liệu trang web có nằm trong AI Overviews hay không.
- Các nhà phân tích thị trường — giám sát những ai được Google trích dẫn trong các khối AI cho các truy vấn thương mại, và cách mà trang đầu tiên của đối thủ thay đổi.
- Các đội ngũ AI và dữ liệu — thu thập SERP như một nguồn dữ liệu cho các hệ thống RAG, đào tạo mô hình và kiểm tra sự thật.
Tất cả họ đều gặp phải một vấn đề chung: Google vào năm 2026 đã tích cực phân biệt lưu lượng tự động với lưu lượng thực, và nếu không có cơ sở hạ tầng đúng đắn, việc thu thập dữ liệu sẽ gặp khó khăn ngay từ những truy vấn đầu tiên.
Những gì đã thay đổi: ba cú đánh của Google vào các scraper
Để hướng dẫn này trung thực, chúng ta bắt đầu với lý do tại sao các hướng dẫn cũ không còn hiệu quả.
Tháng 1 năm 2025 — SearchGuard. Google đã triển khai hệ thống thách thức JavaScript: một yêu cầu HTTP thông thường thông qua requests hoặc httpx giờ đây không nhận được HTML mà là một trang thách thức. Nếu không thực thi JavaScript, bạn không thể thấy kết quả — việc thu thập dữ liệu "trực tiếp" sẽ bị rớt ngay lập tức.
Tháng 9 năm 2025 — kết thúc num=100. Google đã loại bỏ tham số cho phép nhận 100 kết quả trong một yêu cầu. Giờ đây, top-100 là mười yêu cầu riêng biệt với phân trang. Đối với việc giám sát sâu, điều này thực sự làm tăng gấp mười số lượng yêu cầu (và do đó, tải lên proxy và ngân sách).
Tháng 12 năm 2025 — áp lực pháp lý. Vào ngày 19 tháng 12 năm 2025, Google đã đệ đơn khiếu nại DMCA chống lại SerpApi, tuyên bố rằng SearchGuard là "biện pháp bảo vệ kỹ thuật" (technological protection measure), và việc vượt qua nó thuộc về các quy định chống vượt qua. Tiền lệ này vẫn chưa được giải quyết, nhưng nó đặt ra một tông điệu: việc thu thập dữ liệu xám từ Google trở nên đắt đỏ hơn cả về mặt kỹ thuật và pháp lý.
Đặc biệt lưu ý: API Tìm kiếm Tùy chỉnh chính thức của Google đang bị thu hẹp — các khách hàng hiện tại đã được thông báo về thời hạn di chuyển đến ngày 1 tháng 1 năm 2027. Điều này có nghĩa là lựa chọn "hợp pháp" cũng đang bị thu hẹp.
Điểm mới chính của kết quả — AI Overviews
AI Overviews (trước đây là SGE) — là một bản tóm tắt được tạo ra bởi AI ở đầu kết quả với các liên kết đến nguồn. Đối với việc thu thập dữ liệu, đây là yếu tố khó khăn nhất của năm 2026 vì ba lý do.
Có nhiều cái. Theo dữ liệu từ Ahrefs, AI Overviews xuất hiện trong khoảng 30% các truy vấn; các ước tính sau này (Olostep) cho thấy lên đến 48% tất cả các truy vấn và đến 80% thông tin. Bỏ qua khối này có nghĩa là thu thập một bức tranh không đầy đủ về kết quả.
Chúng được render một cách bất đồng bộ. Khối này tồn tại trong ba trạng thái: có thể đến ngay trong HTML (hiếm khi), được tải thêm qua JavaScript sau vài giây sau trang chính (trường hợp phổ biến nhất) hoặc không xuất hiện hoàn toàn. Khi tải thêm, phản hồi HTTP thô chứa một container trống — nội dung sẽ được kéo vào sau, và parser cần phải chờ (trên thực tế — khoảng 8 giây trong tự động hóa trình duyệt).
Chúng không thể thấy từ mọi IP. Đây là điểm quan trọng mà các hướng dẫn cũ không đề cập: Google coi người dùng di động là đối tượng ưu tiên cho tìm kiếm AI. Trên thực tế, điều này có nghĩa là với IP trung tâm dữ liệu, AI Overview thường không được trả về, trong khi cùng một truy vấn qua nhà cung cấp di động trả về toàn bộ khối. Ngay cả các aggregator hàng đầu cũng thừa nhận sự không đầy đủ: SerpApi vào đầu năm 2026 đã tuyên bố khoảng 68% phát hiện thành công AI Overviews.
Phân tích từng bước: cách thu thập SERP trong năm 2026
- Xác định khối lượng. Đến ~100 truy vấn mỗi ngày có thể thực hiện trên tự động hóa trình duyệt của riêng bạn. Từ 100 đến 10.000 — bạn sẽ cần một trình thu thập dữ liệu được quản lý hoặc SERP-API. Hơn 10.000 mỗi ngày mà không có cơ sở hạ tầng doanh nghiệp với các batch và webhook sẽ không thể thực hiện được. Điều này xác định toàn bộ stack tiếp theo.
- Thu thập URL đúng. Endpoint cơ bản là /search, các tham số chính: q (truy vấn, mã hóa URL), hl (ngôn ngữ giao diện), gl (quốc gia của kết quả), start (phân trang: start=10 — trang thứ hai, start=20 — trang thứ ba và cứ thế). Hãy nhớ: num=100 không còn hiệu lực, độ sâu chỉ được tăng lên bằng phân trang.
- Sử dụng rendering trình duyệt. Vì không có JavaScript thì không có kết quả, stack cơ bản là Playwright hoặc Selenium với Chromium headless. Nhất định phải gỡ bỏ các dấu hiệu tự động hóa (cờ --disable-blink-features=AutomationControlled), nếu không, anti-bot sẽ phát hiện trình duyệt được quản lý qua các thuộc tính navigator.
- Chờ đợi AI Overview. Sau khi tải trang, đừng lấy DOM ngay lập tức: hãy để networkidle ổn định và chờ khối được tải thêm (hướng dẫn — đến 8 giây). Sự hiện diện của khối nên được xác định một cách đáng tin cậy qua văn bản tiêu đề "AI Overview", chứ không phải qua các lớp CSS — chúng của Google là động và thay đổi (các lớp điều kiện Kevs9, Y3BBE hôm nay là một, ngày mai là cái khác).
- Parse theo cấu trúc, không theo lớp. Lưu lượng tự nhiên lấy theo các thẻ tiêu đề (h3) và ngữ nghĩa, không phải theo các tên lớp dễ vỡ. Trong kết quả năm 2026 có sẵn: kết quả tự nhiên, featured snippets, "Người cũng hỏi", các truy vấn liên quan, knowledge graph, gói địa phương, quảng cáo và trích dẫn bên trong AI Overview.
- Thay đổi IP và giảm tốc độ. Đặt khoảng thời gian thực tế giữa các yêu cầu (4–12 giây) và thay đổi IP khoảng mỗi 5 phút, thay đổi thành phố/nhà cung cấp. Nhịp điệu quá đều và một IP — là cách nhanh nhất để gặp captcha.
Cạm bẫy
- AI Overview "trống rỗng". Nếu bạn lấy DOM ngay sau khi tải, khối bị trì hoãn sẽ trống — và bạn sẽ nghĩ rằng nó không tồn tại. Luôn luôn tính đến việc chờ đợi và kiểm tra lại.
- Phiên một lần cho việc tải thêm. Một số API có khóa phiên cho việc tải thêm AI Overview bị trì hoãn là một lần và sống khoảng 60 giây — đừng mong đợi sử dụng lại nó sau này.
- Tiết kiệm sai lầm trên trung tâm dữ liệu. IP trung tâm dữ liệu rẻ tiền sẽ gặp captcha ngay trên 5–10 yêu cầu và không hiển thị AI Overviews. Việc tiết kiệm này dẫn đến dữ liệu không đầy đủ và thời gian bị lãng phí.
- Selectors dễ vỡ. Nếu bạn phụ thuộc vào tên lớp CSS — parser sẽ bị hỏng khi có bất kỳ thiết kế lại nào của kết quả. Hãy giữ vững văn bản và cấu trúc.
- Dấu vết yêu cầu đồng nhất. User-Agent, thời gian và tiêu đề giống nhau trên tất cả các luồng sẽ tiết lộ botnet. Đa dạng hóa fingerprint cũng như IP.
Chọn loại proxy nào
Vào năm 2026, chính proxy, không phải parser, quyết định xem bạn có thấy toàn bộ kết quả hay không. Hãy phân tích theo nhiệm vụ.
Proxy di động — cho AI Overviews và các truy vấn "nặng" nhất. Vì Google trả về các khối AI trước tiên cho khán giả di động, các IP từ nhà cung cấp thực (T-Mobile, Verizon, Vodafone và các tương tự) kích hoạt AI Overview ổn định nhất và chịu được nhiều hơn — theo quan sát, 50–200 yêu cầu trước khi gặp khó khăn so với 5–10 ở trung tâm dữ liệu. Thêm vào đó, IP CGNAT di động chia sẻ một địa chỉ với hàng trăm thuê bao thực, vì vậy Google ngại cấm nó. Nếu nhiệm vụ của bạn là thu thập chính xác AI Overviews hoặc giám sát SERP được bảo vệ nhất, hãy bắt đầu với proxy di động.
Proxy cư trú — ngựa làm việc cho lưu lượng tự nhiên và khối lượng. Để thu thập kết quả thông thường, vị trí, featured snippets và gói địa phương, các IP cư trú (địa chỉ từ các nhà cung cấp gia đình) mang lại tỷ lệ giá và thành công tốt nhất. Chúng khó bị phân biệt với người dùng thực, và việc thay đổi cho phép mở rộng thu thập mà không bị dồn từ một địa chỉ. Lựa chọn tối ưu, khi AI Overview không phải là tâm điểm, mà khối lượng và địa lý quan trọng, là proxy cư trú với việc thay đổi.
Trung tâm dữ liệu — chỉ dành cho các lần chạy thử thô. Nhanh chóng và rẻ, nhưng chống lại Google vào năm 2026 chỉ sống sót qua một số yêu cầu và không thấy các khối AI. Phù hợp để gỡ lỗi logic của parser, không phải để thu thập dữ liệu thực sự.
Nếu bạn không chắc chắn nên chọn gì cho nhiệm vụ cụ thể, hãy bắt đầu với phân tích proxy cư trú so với proxy di động trong năm 2026: ở đó có chi tiết về loại nào tiết kiệm tiền, và loại nào tiết kiệm dữ liệu.
Kết luận
Việc thu thập dữ liệu từ Google vào năm 2026 đã không còn là nhiệm vụ "viết parser". SearchGuard đã buộc phải render JavaScript, việc hủy bỏ num=100 đã làm tăng gấp mười số lượng yêu cầu, và AI Overviews đã thêm vào một khối mà chủ yếu chỉ thấy từ các IP di động và được tải thêm với độ trễ. Về mặt kỹ thuật, mọi thứ đều có thể giải quyết: tự động hóa trình duyệt, thu thập dữ liệu theo cấu trúc, thời gian chờ hợp lý và thay đổi. Nhưng nền tảng mà sự đầy đủ và ổn định của việc thu thập dựa vào là các proxy đúng: di động cho AI Overviews và các truy vấn được bảo vệ, cư trú cho lưu lượng tự nhiên và khối lượng. Hãy bắt đầu với loại proxy phù hợp với nhiệm vụ của bạn — và parser sẽ không còn gặp khó khăn với captcha.
```