← Tất cả bài viết
Ứng dụng thực tế 8 phút đọc

Giám sát SERP quy mô lớn sau num=100

Việc theo dõi thứ hạng Google ở quy mô lớn trở nên khó khăn hơn sau khi num=100 bị khai tử. Dưới đây là cách các đội ngũ kỹ thuật SEO đang tái cấu trúc hạ tầng giám sát SERP cho năm 2026.

serp-monitoringrank-trackingseoweb-scrapinggoogle-search

Thách thức

Nếu đội ngũ của bạn xây dựng công cụ theo dõi thứ hạng (rank tracker), bảng điều khiển SEO hoặc công cụ phân tích đối thủ cạnh tranh, năm 2026 đã phá vỡ hiệu quả kinh tế trên từng đơn vị (unit economics) của bạn. Google đã âm thầm khai tử tham số URL num=100 trên Google Search vào năm nay, thủ thuật mà mọi hệ thống cào dữ liệu SERP từng dùng để lấy 100 kết quả chỉ trong một request. Giờ đây, cùng một phạm vi dữ liệu đó cần đến mười request thay vì một.

Đó là chi phí thấy rõ. Những chi phí ẩn còn phức tạp hơn nhiều.

Việc theo dõi thứ hạng chỉ hiệu quả khi bạn nhìn thấy đúng trang SERP mà một người tìm kiếm thực tế nhìn thấy tại đúng quốc gia, khu vực và thành phố. Một từ khóa xếp hạng #4 ở London có thể xếp hạng #11 ở Edinburgh và #19 ở Belfast. Local 3-pack, carousel mua sắm, hộp tin tức, bảng tri thức (knowledge panel), AI Overview. Mọi tính năng trên SERP đều thay đổi theo vị trí địa lý và thiết bị. (Scrape.do đã đo lường văn bản AI Overview xuất hiện trong khoảng 36% số truy vấn vào đầu năm 2026.) Nếu scraper của bạn định tuyến qua một proxy ở sai thành phố, dữ liệu xếp hạng của bạn chỉ là thông tin bịa đặt được trình bày một cách tự tin.

Vì vậy, một sản phẩm SERP đủ sức cạnh tranh vào năm 2026 cần ba yếu tố phối hợp chặt chẽ: một request trông giống như một trình duyệt thực sự ở cấp độ đường truyền (wire level), một proxy đặt tại chính xác thành phố bạn cần giám sát, và khả năng render JavaScript khi Google quyết định tải một nửa kết quả ở phía client. Thiếu bất kỳ yếu tố nào trong ba yếu tố này, chất lượng dữ liệu của bạn sẽ âm thầm giảm sút.

Cách tiếp cận của FourA

Điểm nghẽn khi cào dữ liệu SERP ở quy mô lớn không nằm ở request. Nó nằm ở khâu định tuyến (routing).

Hầu hết các pipeline tự phát triển đều bắt đầu với một proxy pool cố định và xem truy vấn là biến số. Với cơ chế nhắm mục tiêu theo địa lý của Google, thực tế lại ngược lại. Truy vấn là thứ bạn đã có. Proxy mới là thứ bạn bắt buộc phải chọn chuẩn xác.

Chúng tôi nhận thấy các đội ngũ triển khai mô hình này trên FourA theo quy trình cơ bản như sau:

  1. Proxy Finder duy trì một pool proxy hoạt động tốt, được xác thực qua các đợt kiểm tra trạng thái sống (liveness check) mới nhất và được gắn thẻ theo quốc gia, khu vực, thành phố và ASN. Khi một request cần xuất phát từ Manchester, Boston hoặc São Paulo, Proxy Finder sẽ chọn một proxy thực sự đặt tại đó và đang hoạt động ở lần kiểm tra gần nhất. Việc lựa chọn diễn ra trước khi fetch, không phải trong quá trình fetch. Để hiểu thêm lý do tại sao lớp định tuyến đó lại quan trọng, hãy xem bài viết của chúng tôi về Smart Proxy Routing.

  2. Single xử lý chính việc fetch SERP. Đối với các kết quả tìm kiếm tự nhiên (organic) tiêu chuẩn, chỉ cần HTML thô là đủ. Thiết lập unblocker: true và request sẽ mang chữ ký trình duyệt hiện tại mà bạn không cần phải tự tìm hiểu xem Google đang kiểm tra chữ ký nào trong tuần đó. Chúng tôi đã phân tích chi tiết tác động của cờ này trên đường truyền mạng trong bài viết Web Unblocker.

  3. Browser xử lý các SERP nơi nội dung quan trọng chỉ hiển thị sau khi JavaScript chạy xong. AI Overview, gói mua sắm mở rộng, nội dung knowledge panel, local 3-pack dạng cố định (sticky). Cùng một URL, cùng một mục tiêu, request chỉ cần chạy qua một phiên trình duyệt đầy đủ và trả về trang đã được render hoàn chỉnh. (Kèm theo ảnh chụp màn hình, cứu cánh thực sự vào ngày trưởng nhóm SEO thắc mắc tại sao dashboard của bạn hiển thị #3 nhưng họ lại thấy #6 trên trình duyệt của họ.)

Một lệnh gọi duy nhất tới API đã được định tuyến qua proxy:

curl -X POST "https://api.foura.ai/api/proxy" \
  -H "x-api-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "maxTries": 3,
    "timeout_ms": 20000,
    "request": {
      "method": "GET",
      "url": "https://www.google.co.uk/search?q=plumber+manchester&hl=en-GB",
      "unblocker": true,
      "validate": {
        "status": { "accept": [200] },
        "data": { "fail": ["unusual traffic", "/sorry/", "captcha"] }
      }
    }
  }'

Đó là ba mối bận tâm được tách biệt rõ ràng: xử lý proxy chuẩn theo vị trí địa lý (Proxy Finder), bản thân request (Single), và render JavaScript khi bạn cần (Browser). Code của bạn không cần chứa logic kiểm tra sức khỏe proxy hay đoán xem IP nào còn sống lúc 3 giờ sáng. Đó là việc của hệ thống khác.

Và hãy lưu trữ mọi response theo khóa (keyword, location, device, timestamp). Đó là đơn vị chuẩn xác thực tế để theo dõi thứ hạng. Không phải "chúng ta xếp hạng ở vị trí này cho từ khóa này hôm nay," mà là "chúng ta xếp hạng ở vị trí này cho từ khóa này, từ thành phố này, trên thiết bị này, vào phút này." Nếu không có mức độ định danh chi tiết đó, dữ liệu của hai ngày có thể âm thầm mâu thuẫn với nhau và bạn sẽ không có cách nào biết kết quả nào là đúng. Các đội ngũ SEO theo dõi những ngành dọc được bảo vệ nghiêm ngặt đã và đang đối mặt với điều này. Chúng tôi cũng đã viết về việc hệ thống phát hiện bot chuyển sang phân tích hành vi, bổ sung thêm một trục thứ tư (tính liên tục của phiên) đối với các trang web xem xét chuỗi request thay vì tín hiệu trên từng request đơn lẻ.

Kết quả

Một công cụ theo dõi thứ hạng giám sát 5.000 từ khóa trên 12 thành phố, hai lần mỗi ngày, trước đây cần khoảng 120.000 request mỗi ngày theo cơ chế num=100 cũ. Bây giờ con số này gần 1,2 triệu, dựa trên phép tính phân trang đơn giản (kịch bản minh họa dựa trên các chỉ số chuẩn của ngành).

Các nhóm chuyển đổi mô hình này sang stack ba sản phẩm thường ghi nhận:

  • Giảm 40-60% chi phí trên mỗi request so với việc tự vận hành proxy pool, phần lớn là do họ không còn phải trả tiền cho hao hụt proxy, các IP chết, và giờ công kỹ thuật để duy trì việc xoay vòng proxy.
  • Độ chính xác vị trí ở cấp thành phố tăng từ ~70% lên hơn 95%, vì Proxy Finder lọc theo thành phố và xác minh trạng thái hoạt động ở lần kiểm tra cuối cùng trước khi bàn giao proxy.
  • Không cần luồng xử lý riêng cho AI Overviews. Một từ khóa đang lấy dữ liệu qua Single có thể chuyển sang Browser mà không cần viết lại pipeline. Giao diện xử lý hoàn toàn giống nhau: đưa URL vào, nhận response ra.

Bạn không cần bất kỳ điều gì trong số này cho mười từ khóa và một chiếc laptop. Nhưng bạn sẽ cần nó khi pipeline phải theo dõi hàng chục nghìn từ khóa trên nhiều quốc gia, khách hàng mở dashboard lúc 9 giờ sáng thứ Hai, và thứ hạng hiển thị bắt buộc phải chuẩn xác.

Điểm mấu chốt

Phần khó khăn của việc theo dõi SERP đã không còn nằm ở việc gửi request từ rất lâu. Vấn đề luôn nằm ở việc định tuyến. Bạn đang lấy dữ liệu từ thành phố của ai? IP đó có còn sống không? Google đã trả về bố cục mà một người tìm kiếm thực sự tại vị trí đó nhìn thấy, hay giao diện trống rỗng họ đưa ra khi phát hiện scraper?

Nếu bạn là một nhóm SEO đang tự xây dựng hệ thống theo dõi thứ hạng, câu hỏi cho năm 2026 không phải là có scrape Google hay không. Bạn vốn đã làm điều đó rồi. Câu hỏi là liệu hạ tầng của bạn có thể tiếp tục cung cấp thứ hạng đáng tin cậy khi các quy tắc thay đổi không báo trước hay không, và bạn sẵn sàng dành bao nhiêu nguồn lực kỹ thuật để duy trì trạng thái đó.