← 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ác rank tracker, dashboard SEO hoặc công cụ phân tích cạnh tranh, năm 2026 đã phá vỡ bài toán unit economics của bạn. Google đã âm thầm khai tử tham số URL num=100 trên Google Search trong năm nay, thủ thuật mà mọi SERP scraper từng sử dụng để thu thập 100 kết quả chỉ trong một request. Giờ đây, để đạt được cùng một phạm vi bao phủ, bạn cần thực hiện mười request thay vì một.

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

Việc theo dõi thứ hạng chỉ hoạt động hiệu quả khi bạn nhìn thấy SERP mà một người tìm kiếm thực tế sẽ 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. Các tính năng như local 3-pack, carousel mua sắm, hộp tin tức, knowledge panel, AI Overviews. Mọi tính năng 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 thứ hạng của bạn chỉ là một câu chuyện hư cấu được kể một cách đầy tự tin.

Vì vậy, một sản phẩm SERP bền vững vào năm 2026 cần có sự kết hợp của ba yếu tố: một request trông giống như trình duyệt thực ở cấp độ wire level, một proxy nằm chính xác tại thành phố bạn muố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-side. Thiếu bất kỳ yếu tố nào trong ba yếu tố này, dữ liệu của bạn sẽ âm thầm giảm chất lượng.

Giải pháp từ FourA

Điểm nghẽn trong việc scrape SERP ở quy mô lớn không nằm ở request. Nó nằm ở việc định tuyến.

Hầu hết các pipeline tự xây dựng đều bắt đầu với một proxy pool cố định và coi truy vấn là biến số. Với tính năng nhắm mục tiêu theo địa lý của Google, điều ngược lại mới đúng. Truy vấn là thứ bạn đã có. Proxy mới là thứ bạn phải xử lý chính xác.

Chúng tôi đã thấy các đội ngũ thiết kế mô hình này trên nền tảng FourA tương tự như sau:

  1. Proxy Finder duy trì một pool hoạt động gồm các proxy được xác thực qua các lượt 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ự nằm ở đó và vẫn hoạt động trong lần kiểm tra gần nhất. Việc lựa chọn diễn ra trước khi fetch, chứ không phải trong quá trình fetch. Để hiểu thêm về 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 tự xử lý việc fetch SERP. Đối với các kết quả organic tiêu chuẩn, HTML thô là quá đủ. Thiết lập unblocker: true và request sẽ vượt qua các bức tường anti-bot ở cấp độ handshake-level mà bạn không cần biết Google đang kiểm tra signature nào trong tuần đó. Chúng tôi đã phân tích chi tiết những gì flag này thực hiện trên đường truyền trong bài viết về 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. AI Overviews, các gói mua sắm mở rộng, nội dung knowledge-panel, local 3-pack cố định. 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. (Đi kèm ảnh chụp màn hình, giúp cứu nguy cho bạn vào ngày một trưởng nhóm SEO hỏi tại sao dashboard của bạn báo xếp hạng #3 nhưng họ lại thấy #6 trên trình duyệt của họ.)

A single call against the proxy-routed API:

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 nhiệm vụ được tách biệt rõ ràng: xử lý proxy chính xác theo đị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 hoặc đoán xem IP nào vẫn còn hoạt độ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 được định danh bằng khóa (keyword, location, device, timestamp). Đó mới là đơn vị chân thực nhất để theo dõi thứ hạng. Không phải là "chúng tôi xếp hạng ở đây cho từ khóa này hôm nay", mà là "chúng tôi xếp hạng ở đây cho từ khóa này, từ thành phố này, trên thiết bị này, tại phút này". Nếu không có mức độ phân bổ 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 dữ liệu nào là chính xác. Các đội ngũ SEO giám sát các ngành dọc được bảo vệ nghiêm ngặt đã và đang phải đố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, điều này bổ sung thêm trục thứ tư (session continuity) cho các trang web phân tích chuỗi request thay vì các tín hiệu trên mỗi request đơn lẻ.

Kết quả

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

Các đội ngũ 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 riêng, chủ yếu là vì họ không còn phải trả chi phí cho việc hao hụt proxy, IP chết và số giờ 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ừ khoảng 70% lên hơn 95%, vì Proxy Finder lọc theo thành phố và xác minh liveness ở lượt kiểm tra cuối cùng trước khi bàn giao proxy.
  • Không cần quy trình đặc biệt cho AI Overviews. Một từ khóa được fetch qua Single có thể được nâng cấp lên Browser mà không cần viết lại pipeline. Giao ước 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 nào trong số này nếu chỉ theo dõi mười từ khóa bằng một chiếc laptop. Nhưng bạn sẽ cần đến nó khi pipeline phải giám sát hàng chục nghìn từ khóa trên nhiều quốc gia, khách hàng của bạn tải lại dashboard vào lúc 9 giờ sáng Thứ Hai, và thứ hạng hiển thị bắt buộc phải chính xác.

Kết luận chính

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

Nếu bạn là một đội ngũ SEO đang vận hành hệ thống theo dõi thứ hạng trên một stack tự xây dựng, câu hỏi cho năm 2026 không phải là có nên scrape Google hay không. Bạn đã và đang làm việc đó rồi. Câu hỏi là liệu hạ tầng của bạn có thể tiếp tục tạo ra các thứ hạng đáng tin cậy khi các quy tắc thay đổi mà 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 của đội ngũ kỹ thuật để duy trì điều đó.