Con số 2MB trong tài liệu Googlebot: đổi chữ, không đổi hành vi

Ngày 3 tháng 2 năm 2026, tài liệu về Googlebot trên Search Central đổi một con số. Giới hạn kích thước mà máy thu thập dữ liệu của Google đọc mỗi tệp ghi 2MB, thay cho 15MB nằm ở đó nhiều năm. Không thông cáo, không bài đăng, chỉ là dòng ngày cập nhật ở chân trang.

Giới làm web phát hiện trong vòng vài ngày, và phản ứng đầu tiên là hoảng. Một con số bị cắt gần chín phần mười nghe như Google vừa siết mạnh tay.

Sự thật kém kịch tính hơn nhiều.

Tài liệu đổi, hành vi thì không

Người của Google trả lời trên mạng xã hội rằng chẳng có gì vừa thay đổi cả. Họ chỉ mô tả kỹ hơn những thứ vốn đã như vậy. Một thành viên đội hỗ trợ nói thẳng hơn. Tài liệu cũ ghi sai, Googlebot xưa nay chỉ đọc 2MB mã HTML thô đầu tiên, và tài liệu đang được sửa lại.

Chuyện đáng lưu ý vì thế không phải một chính sách mới. Suốt nhiều năm, cả ngành đã tối ưu dựa trên một con số sai trong tài liệu chính thức của bên cung cấp. Ai từng viện dẫn mốc 15MB để bảo rằng trang mình an toàn thì đã viện dẫn nhầm ngay từ đầu.

Hai giai đoạn, hai giới hạn

Bản tài liệu mới tách rõ hai việc trước đây bị gộp làm một. Giai đoạn tải về giữ ngưỡng 15MB. Giai đoạn xử lý để đưa vào chỉ mục mới là chỗ áp mốc 2MB, và mốc đó dành riêng cho Googlebot.

Các máy thu thập khác của Google, loại chuyên ảnh hay video, vẫn chạy theo mặc định 15MB. Tệp PDF được cấp riêng một mức 64MB, vì bản chất tài liệu đó vốn nặng.

Vài chi tiết nhỏ nhưng hay bị đọc lướt. Giới hạn tính trên dữ liệu chưa nén, chứ không phải dung lượng truyền qua mạng — trang nén gzip xuống 300KB vẫn có thể là 2,5MB ở dạng thô. Phần tiêu đề của yêu cầu HTTP cũng được tính vào. Và mỗi tệp CSS hay JavaScript chịu chung một ngưỡng như thế, tính riêng từng tệp.

Bao nhiêu trang thật sự chạm ngưỡng

Rất ít. Số đo trên diện rộng cho thấy trang HTML trung vị chỉ nặng khoảng hai chục kilobyte ở dạng chưa nén. Ngay ở nhóm nặng nhất, mức phân vị thứ chín mươi cũng chưa tới bốn trăm kilobyte. Từ đó tới 2MB còn một quãng rất xa.

Có người đã thử dựng trang vượt 2MB rồi soi bằng công cụ kiểm tra URL trong Search Console. Kết quả không thấy dấu vết cắt cụt nào. Cơ chế cắt được áp lúc nào, chặt tới đâu, Google chưa nói rõ, nên phần này vẫn còn khoảng mờ.

Nhóm thật sự đáng soát lại là site dựng bằng khung ứng dụng một trang, nơi cả giao diện lẫn nội dung gói vào một tệp JavaScript lớn. Nhiều website doanh nghiệp vài năm gần đây đi theo hướng đó vì thi công nhanh và hiệu ứng đẹp. Không ít trong số đó chưa từng tách gói mã.

Site thương mại điện tử tự dựng cũng vậy. Thư viện giao diện, mã theo dõi hành vi, các tiện ích bên thứ ba. Chồng lên nhau qua nhiều năm vá víu là cách chắc chắn nhất để một tệp phình ra.

Cái khó chịu của lỗi kiểu này là nó không báo động. Trang vẫn trả mã 200, người thật vẫn xem bình thường, chỉ bản dựng phía máy tìm kiếm là thiếu. Đọc mã nguồn trên trình duyệt của mình thì không thấy gì cả; phải xem bản HTML mà Google thực sự dựng ra mới lộ.

Cái gì quan trọng thì đừng để nó phải chờ

Đợt này nhắc lại một nguyên tắc cũ hơn mọi con số trong tài liệu. Máy tìm kiếm không phải người dùng ưu tiên của bạn, nhưng nó là người dùng ít kiên nhẫn nhất. Trang nào chỉ hiện đủ nội dung sau khi tải xong vài megabyte mã thì luôn mang rủi ro bị đọc thiếu.

Ngưỡng của bên nào là bao nhiêu cũng vậy, và ngưỡng đó có thể đổi mà không ai báo — như vừa rồi. Làm nhẹ phần khung là cách bền, vì nó không phụ thuộc vào con số của một thời điểm. Khi khách nhờ chúng tôi soi tốc độ trang, đây thường là chỗ nhìn trước tiên.

Nội dung chỉ tồn tại sau khi trình duyệt chạy xong mã luôn là nội dung mong manh. Nó phụ thuộc vào quá nhiều thứ có thể hỏng dọc đường. Đưa những gì quan trọng nhất vào HTML gốc là cách bền nhất, bất kể giới hạn của bên nào có đổi.

Bài khác

Đội ngũ Rainbow E-Commerce