Gary Illyes của Google chia sẻ các mốc thời gian, dựa trên phân tích nội bộ của Google, về crawl (thu thập và đọc nội dung trang web) và index (lập chỉ mục để trang xuất hiện trên kết quả tìm kiếm) tại Search Central Live Deep Dive Europe ở Barcelona ngày 2/10/2026. Theo bản tóm tắt của diễn giả cộng đồng John Campbell thuộc ROAST, thời gian điển hình để Google phát hiện một URL mới là khoảng 20 tiếng, còn làm mới URL đã biết thường mất khoảng 30 ngày. Với một số quy trình, mốc chậm nhất được ghi là “không bao giờ”.
Google đưa ra những mốc thời gian crawl và index nào?
Theo bản tóm tắt phiên ngày 2/10 của Campbell, mỗi quy trình đều có ba mốc: nhanh nhất, điển hình và chậm nhất, dựa trên phân tích nội bộ của Google. Bản tóm tắt không ghi mốc nhanh nhất. Illyes cảnh báo rằng nhiều quy trình liên kết với nhau: trang phải được crawl rồi mới được index, nên bước đầu chậm thì các bước sau chậm theo.
| Quy trình | Điển hình | Chậm nhất |
|---|---|---|
| Phát hiện URL mới | ~20 tiếng | Không ghi |
| Làm mới URL đã biết | ~30 ngày | Không ghi |
| Cập nhật tiêu đề và snippet | 1–2 ngày | Vài tuần đến vài tháng |
| Yêu cầu xóa qua Search Console | ~2 tiếng | Đến 24 tiếng |
| Gỡ manual action | 1–2 tuần | 4–6 tuần; lâu hơn với site không hoạt động |
| Xử lý sitemap | Không ghi | Không bao giờ (chất lượng) |
| Cập nhật structured data | Không ghi | Không bao giờ (chất lượng) |
| Index end-to-end | Không ghi | Không bao giờ (chất lượng) |
5 trong số các mốc chậm nhất ghi “không bao giờ”. Ba trong số đó, bao gồm xử lý sitemap, index end-to-end và cập nhật structured data (dữ liệu có cấu trúc giúp công cụ tìm kiếm hiểu nội dung trang), đều kèm ghi chú “(chất lượng)”, có thể hiểu là vấn đề chất lượng có thể khiến các quy trình này không bao giờ hoàn tất.
Bản tóm tắt định nghĩa index end-to-end là thời điểm “tất cả các quy trình quan trọng hoàn thành thành công”, theo báo cáo của SEJ. Cả bản tóm tắt lẫn trang sự kiện của Google đều không cung cấp cỡ mẫu, khoảng thời gian đo lường hay định nghĩa cụ thể cho “điển hình”. Slide từ phiên của Illyes không xuất hiện trên trang sự kiện Search Central tính đến ngày SEJ đăng bài (4/10/2026).
Chuyển domain và thay đổi canonical mất bao lâu?
Với site nhỏ, bản tóm tắt của Campbell cho biết quá trình chuyển domain có thể hoàn tất trong vài tuần. Nếu sau ba tháng vẫn chưa xong, site đó đang ở mức cao của khung thời gian điển hình. Trường hợp chậm nhất kéo dài từ sáu tháng đến hơn một năm.
Tài liệu hướng dẫn chuyển domain của Google, được SEJ dẫn lại, cho biết với site nhỏ đến trung bình, hầu hết các trang mất vài tuần để hoàn thành; site lớn cần thêm thời gian.
Với canonical change (thay đổi chỉ định trang chính thức để tránh nội dung bị đánh trùng), tài liệu xử lý sự cố của Google ghi nhận rằng sau khi sửa nội dung, trang có thể vẫn nằm trong duplicate cluster (nhóm trang trùng lặp chưa được giải quyết) đến hai tuần. Google bổ sung chi tiết này vào tài liệu từ tháng 7, theo báo cáo của SEJ.
Recovery sau core update thường kéo dài bao lâu?
Dữ liệu thời gian cho core update tập trung vào quá trình phục hồi sau khi thay đổi site, không phải thời gian diễn ra bản update. Theo bản tóm tắt của Campbell, phục hồi điển hình mất ba đến sáu tháng. Trường hợp chậm nhất là sáu tháng đến một năm, được ghi nhãn “core update tiếp theo” trong bảng tóm tắt.
Tài liệu của Google về core update, được SEJ dẫn lại, cho biết một số thay đổi có thể cho thấy hiệu quả sau vài ngày, nhưng để xác nhận sự cải thiện tổng thể của site có thể mất vài tháng. Nếu sau vài tháng vẫn chưa thấy tác động, tài liệu cho biết site có thể đang chờ core update tiếp theo.
Ý nghĩa với khả năng hiển thị trên AI search
Theo Hingewise, điều rõ ràng nhất: câu trả lời AI của chính Google, như AI Overviews, chỉ có thể dựa trên những trang Google đã crawl và index. Vì vậy các khung thời gian trên quyết định tốc độ một thay đổi trên site có thể xuất hiện ở đó.
Khoảng cách giữa phát hiện URL mới (~20 tiếng, điển hình) và làm mới URL đã biết (~30 ngày, điển hình) có một hàm ý ít rõ ràng hơn với các team nội dung nhắm đến trích dẫn AI. Khi bạn cập nhật một trang đã có để bổ sung định nghĩa rõ hơn, số liệu mới hơn hay cấu trúc câu trả lời tốt hơn, với thời gian làm mới điển hình, Google có thể chưa xử lý lại trong khoảng một tháng. Trong khoảng thời gian đó, phiên bản cũ nhiều khả năng vẫn nằm trong retrieval pool (cơ sở dữ liệu nội dung đã được index mà các công cụ AI search dùng khi tạo câu trả lời).
Góc nhìn Hingewise
Kiểm tra trích dẫn AI một tuần sau khi viết lại trang là quá sớm để kết luận. Hình dung bạn vừa bổ sung câu trả lời rõ hơn vào một trang sản phẩm đang chạy: với thời gian làm mới điển hình khoảng 30 ngày, câu trả lời AI của Google có thể vẫn dựa trên phiên bản cũ trong khoảng một tháng. Đăng trang mới cũng không phải đường tắt: phát hiện URL trong khoảng 20 tiếng mới chỉ là bước đầu, trang còn phải được index.
Ba mục “không bao giờ (chất lượng)” trong bảng chỉ ra điều quan trọng hơn cả tốc độ. Tín hiệu chất lượng nhiều khả năng đóng vai trò cổng lọc ở cấp index, trước khi nội dung tiếp cận giai đoạn mà AI search truy xuất. Một trang bị hệ thống của Google đánh dấu vì vấn đề chất lượng nhiều khả năng sẽ không vào được retrieval pool, dù structured data được đánh dấu kỹ đến đâu hay trang được cập nhật thường xuyên đến mức nào. Theo Hingewise, xử lý chất lượng phải là bước đầu tiên, không phải việc làm sau cùng.
Khung thời gian phục hồi ba đến sáu tháng sau core update cũng là mức sàn thực tế cho bất kỳ thay đổi đáng kể nào trong tần suất câu trả lời AI của Google trích dẫn một thương hiệu. Các thương hiệu mất traffic sau core update không nên kỳ vọng sự hiện diện trong các câu trả lời đó phục hồi nhanh hơn quá trình phục hồi của index nền tảng. Phục hồi là một pipeline, không phải công tắc.
Một điều đáng theo dõi: trước sự kiện, Google Search Central Blog cho biết Search Central Live Deep Dive Europe 2026 sẽ mang đến “các chủ đề hoàn toàn mới, tập trung phần lớn vào AI”. Liệu dữ liệu thời gian của Illyes và bối cảnh AI cụ thể xung quanh nó có được công bố chính thức ngoài bản tóm tắt của Campbell hay không vẫn chưa rõ tính đến ngày 4/10.
Trước khi đặt kỳ vọng thời gian với team hoặc khách hàng, hãy kiểm tra:
- Site move đã chạy hơn ba tháng chưa? Nếu rồi, bạn đang ở mức cao của khung điển hình theo bản tóm tắt của Campbell.
- Còn manual action (hình phạt thủ công từ Google) nào chưa được gỡ không? Gỡ thường mất 1–2 tuần, tối đa 4–6 tuần, lâu hơn với site không hoạt động.
- Các vấn đề nội dung trùng lặp đã được xử lý chưa? Trang có thể vẫn nằm trong duplicate cluster đến hai tuần sau khi sửa, theo tài liệu của Google.
- Với thay đổi tiêu đề hay snippet: đợi ít nhất 1–2 ngày; trường hợp chậm nhất kéo dài vài tuần đến vài tháng.
- Với phục hồi sau core update: bản tóm tắt ghi ba đến sáu tháng là điển hình, nên đánh giá sớm hơn nhiều so với mốc đó nhiều khả năng là quá sớm.
- Kiểm tra xem vấn đề chất lượng có đang chặn structured data hoặc sitemap không. Cả hai đều có mốc chậm nhất “không bao giờ (chất lượng)” trong bản tóm tắt.
Nguồn: Search Engine Journal, 4/10/2026; Google Search Central Blog, tháng 9/2026; bản tóm tắt phiên ngày 2/10/2026 của John Campbell (ROAST) tại Search Central Live Deep Dive Europe, Barcelona, qua SEJ.
Bài viết được soạn với sự hỗ trợ của AI từ các nguồn dẫn ở trên và đối chiếu với các nguồn đó trước khi đăng. "Góc nhìn Hingewise" là nhận định biên tập của Hingewise, dựa trên khung phân tích và lập trường chúng tôi dùng trong công việc GEO. Cách chúng tôi làm việc: Chính sách biên tập.