Mobile-first indexing: website doanh nghiệp cần gì trên di động để Google hiểu đủ

Chủ doanh nghiệp có thể duyệt website chủ yếu trên máy tính, nhưng Google chủ yếu đọc website qua bản di động. Nếu bản di động thiếu nội dung hoặc bị chặn tài nguyên, phần thiếu có thể không vào chỉ mục dù bản máy tính đầy đủ.

Bài này giải thích mobile-first indexing, điều Google cần ở bản di động, 3 cách phục vụ trang di động, thẻ viewport, cách kiểm bằng Search Console và lộ trình 14 ngày. Nguồn chính là Google Search Central, web.dev, MDN, Chrome for Developers và Web Almanac 2025, đối chiếu đến ngày 23/10/2026.

Click Star đã có bài riêng về Googlebot, Core Web Vitals, INP, WCAG và robots.txt. Bài này chỉ hỏi: bản di động có đủ để Google hiểu trang hay không. Click Star làm dịch vụ thiết kế website chuẩn SEO tải nhanh, nên có lợi ích liên quan.

Điểm chính

• Theo Google Search Central (cập nhật 10/12/2025), Google dùng bản di động của nội dung, thu thập bằng trình thu thập điện thoại, để lập chỉ mục và xếp hạng. Có bản di động không bắt buộc, nhưng được khuyến nghị rất mạnh.
• Ngày 31/10/2023, Google thông báo việc chuyển sang mobile-first đã hoàn tất, trừ một tập rất nhỏ website không chạy được trên di động.
• Bản di động cần cùng nội dung chính, tiêu đề, mô tả, thẻ robots, dữ liệu có cấu trúc và ảnh kèm alt như bản máy tính. Gom nội dung vào tab hoặc accordion được phép nếu nội dung vẫn tương đương.
• Responsive là cấu hình Google khuyến nghị vì dễ triển khai và bảo trì nhất. Theo Web Almanac 2025, thẻ viewport có ở 95,2% trang bản di động, còn Vary: User-Agent chỉ xuất hiện ở dưới 1% trang.
• Thẻ viewport nên là width=device-width, initial-scale=1, và không nên tắt zoom của người dùng.
• Cách kiểm: URL Inspection, báo cáo Page indexing và Crawl Stats. Mobile-Friendly Test và báo cáo Mobile Usability đã ngừng từ 1/12/2023.

Mobile-first indexing là gì và đã hoàn tất chưa

Mobile-first indexing nghĩa là Google dùng bản di động của trang để lập chỉ mục và xếp hạng. Theo blog Google Search Central ngày 31/10/2023, Google coi trọng thiết bị di động từ bản cập nhật mobile-friendly năm 2015, bắt đầu thu thập và lập chỉ mục ưu tiên di động năm 2016, và công bố hoàn tất vào 31/10/2023.

Cũng theo bài đó, một tập rất nhỏ website không chạy được trên di động: báo lỗi với mọi người dùng di động, chặn bản di động bằng robots.txt trong khi bản máy tính được phép, hoặc chuyển hướng mọi trang di động về trang chủ. Google tiếp tục thu thập các site này bằng trình thu thập máy tính cũ và đánh giá lại vài lần mỗi năm.

Trang Googlebot (cập nhật 3/2/2026) mô tả 2 loại: Smartphone mô phỏng người dùng di động và Desktop mô phỏng người dùng máy tính. Với đa số website, phần lớn yêu cầu thu thập đến từ trình thu thập di động.

Vì sao bản di động quyết định kết quả

Cơ chế là một chuỗi: trình thu thập điện thoại tải trang và tài nguyên đi kèm như CSS, ảnh, rồi lập chỉ mục từ nội dung hiển thị trên bản di động. Theo trang trợ giúp Crawl Stats, Google tải các tài nguyên quan trọng để hiển thị trang trước khi lập chỉ mục.

Hệ quả đầu tiên: nội dung chỉ có ở bản máy tính không vào chỉ mục, vì tài liệu mobile-first ghi chỉ nội dung hiển thị trên bản di động được dùng để lập chỉ mục. Nếu chủ ý để bản di động ít nội dung hơn, Google cho biết có thể mất một phần lưu lượng.

Hệ quả thứ hai: 2 loại Googlebot dùng chung 1 token trong robots.txt, nên không chặn riêng được 1 loại. Hệ quả thứ ba: theo tài liệu về tải lười, Google Search không cuộn hay bấm, nên nội dung chỉ hiện sau thao tác của người dùng có thể không bao giờ được thấy.

Nội dung và dữ liệu có cấu trúc phải có trên bản di động

Theo tài liệu mobile-first của Google, nội dung chính phải tương đương. Bố cục có thể khác, chẳng hạn gom nội dung vào accordion hoặc tab, miễn là nội dung vẫn tương đương và tiêu đề mục giống bản máy tính.

Thẻ robots. Dùng cùng thẻ robots meta ở 2 bản. Nếu bản di động có noindex hoặc nofollow, Google có thể không thu thập và lập chỉ mục trang khi website được bật mobile-first.

Tiêu đề và mô tả. Thẻ title và meta description phải tương đương ở 2 bản. Thiếu một trong 2 thẻ ở bản di động được liệt kê là lỗi.

Dữ liệu có cấu trúc. 2 bản cần cùng dữ liệu có cấu trúc. Nếu phải ưu tiên, Google gợi ý bắt đầu từ Breadcrumb, Product và VideoObject.

Ảnh. Dùng ảnh chất lượng cao, không quá nhỏ, và không dùng URL ảnh đổi mỗi lần tải trang. Alt, chú thích và tên tệp nên giống bản máy tính.

Video. Dùng định dạng được hỗ trợ trong thẻ video, embed hoặc object, không dùng URL đổi liên tục, và đặt video ở vị trí dễ tìm trên di động.

3 cách phục vụ trang di động

Theo Google, có 3 cấu hình. Responsive phục vụ cùng HTML trên cùng URL và chỉ đổi cách hiển thị theo kích thước màn hình. Google khuyến nghị responsive vì dễ triển khai và bảo trì nhất, và với responsive thì nội dung lẫn metadata đã giống nhau ở 2 bản.

Dynamic serving dùng cùng URL nhưng phục vụ HTML khác theo thiết bị, dựa vào user-agent và tiêu đề Vary: User-Agent. URL riêng (thường gọi m-dot) phục vụ HTML khác trên URL khác, cũng dựa vào cơ chế đó để chuyển hướng.

Web Almanac 2025 (cập nhật 9/6/2026) ghi Vary: User-Agent có ở dưới 1% trang, số trên toàn web về tần suất header, không phải tỷ lệ website dùng dynamic serving.

Với URL riêng, Google nêu thêm các điều kiện:

• Trạng thái lỗi phải giống nhau: bản di động trả trang lỗi trong khi trang máy tính bình thường thì trang biến mất khỏi chỉ mục.
• URL di động không chứa đoạn #, vì URL có fragment thường không lập chỉ mục được.
• Mỗi URL máy tính cần một URL di động tương đương; nếu nhiều URL cùng chuyển hướng về trang chủ di động, các trang đó biến mất khỏi chỉ mục.
• URL máy tính luôn là canonical: bản di động trỏ canonical về nó, còn trang máy tính khai báo rel=alternate với thuộc tính media trỏ sang bản di động.
• Xác minh cả 2 bản trong Search Console, kiểm hreflang riêng cho từng bản và bảo đảm máy chủ di động chịu được mức thu thập tăng.

Thẻ viewport, bố cục và vùng bấm

Theo web.dev (cập nhật 12/2/2019, khá cũ), trình duyệt di động mặc định vẽ trang ở chiều rộng máy tính, thường khoảng 980px, rồi thu nhỏ cho vừa màn hình. Thẻ meta viewport với width=device-width, initial-scale=1 báo trình duyệt dùng đúng chiều rộng màn hình.

MDN (sửa lần cuối 23/9/2026) khuyến nghị width=device-width và ghi initial-scale=1 thường không cần thiết. Tài liệu Chrome "Optimize viewport for mobile" (8/10/2025) nêu tiêu chí là có width và initial-scale từ 1 trở lên; nếu không, thao tác chạm có thể trễ tới 300 mili giây. Hai nguồn không thống nhất, nên Click Star khuyên khai báo cả hai.

web.dev không khuyến khích maximum-scale và user-scalable vì có thể ngăn phóng to; MDN cảnh báo user-scalable=no gây khó cho người thị lực kém.

Về bố cục, web.dev khuyên đặt max-width 100% cho ảnh và không ẩn nội dung chỉ vì không vừa màn hình. Về vùng bấm, WCAG 2.2 tiêu chí 2.5.8 (mức AA) yêu cầu mục tiêu tối thiểu 24 x 24 điểm ảnh CSS, trừ một số ngoại lệ.

Tài nguyên bị chặn, tải lười và cửa sổ che nội dung

Theo tài liệu mobile-first, đừng chặn bằng disallow các URL tài nguyên mà bản di động dùng. Ảnh quan trọng bị robots.txt chặn trên bản di động được liệt kê là lỗi.

Về tải lười, tài liệu "Fix lazy-loaded content" (10/12/2025) khuyên tải nội dung khi nó vào vùng nhìn thấy, bằng tải lười có sẵn của trình duyệt cho ảnh và iframe hoặc IntersectionObserver. Với cuộn vô hạn, mỗi đoạn cần URL riêng, ổn định, như ?page=12, và được liên kết tuần tự.

Về cửa sổ che nội dung, tài liệu về intrusive interstitials (10/12/2025) nói cửa sổ che nội dung quá mức có thể làm người dùng khó chịu và làm công cụ tìm kiếm khó hiểu nội dung. Google khuyên dùng banner nhỏ thay vì che cả trang. Click Star đã có bài riêng về banner cookie.

Cách kiểm bằng Search Console và công cụ trình duyệt

Công cụ cũ đã ngừng: ghi chú đầu bài blog Google Search Central năm 2016 về công cụ này ghi Mobile Friendly Test và báo cáo Mobile Usability đã ngừng ngày 1/12/2023. Trang page experience (22/9/2026) trỏ đến Lighthouse để tìm cải thiện, gồm cả khả năng dùng trên di động.

URL Inspection. Theo trang trợ giúp, bản đã lập chỉ mục có trường Crawled as (máy tính hay di động), kèm HTML và tài nguyên đã tải. Ảnh chụp màn hình chỉ có khi chạy Live Test. "URL is on Google" không bảo đảm trang hiện trong kết quả.

Crawl Stats. Báo cáo chia yêu cầu thu thập theo loại Googlebot, gồm Smartphone và Desktop. Google ghi báo cáo dành cho người dùng nâng cao và website dưới 1.000 trang thường không cần dùng.

Trình duyệt. Chế độ thiết bị của Chrome DevTools (20/2/2024) chỉ là xấp xỉ bậc một; hãy thử cả trên điện thoại thật.

Cách đo sau khi sửa. Theo dõi lỗi trong Page indexing, tỷ lệ Smartphone trong Crawl Stats, tỷ lệ truy cập theo thiết bị trong GA4 và tỷ lệ đạt Core Web Vitals trên di động.

Ý nghĩa với doanh nghiệp Việt Nam

Click Star không tìm thấy số đo tỷ lệ truy cập di động của website doanh nghiệp Việt Nam; trang Statcounter cần JavaScript nên không đọc được bằng công cụ.

DataReportal (Digital 2026, số liệu cuối 2025, nguồn thứ cấp) ghi 137 triệu kết nối di động, tương đương 134% dân số, và 85,6 triệu người dùng internet. Một phần kết nối chỉ có thoại và SMS, nên số này không cho biết tỷ lệ truy cập website qua điện thoại.

Đánh giá của Click Star. Đây là nhận định kỹ thuật, không phải số đo. Với website mới, responsive là lựa chọn mặc định vì khớp khuyến nghị của Google và tránh phải giữ 2 bản đồng bộ. Dynamic serving và URL riêng chỉ nên giữ khi có lý do kế thừa, và khi đó cần kiểm đủ các điều kiện ở trên.

Giao diện hoặc plugin ẩn khối nội dung trên di động có thể gây lỗi (nhận định của Click Star, chưa có số đo), nên cần so bản đã hiển thị chứ không chỉ mã mẫu. Điểm Lighthouse không thay thế việc so nội dung 2 bản. Để biết khách dùng thiết bị nào, hãy xem GA4 của chính website.

Lộ trình 14 ngày

Lộ trình và số trang mẫu là khung tham khảo của Click Star, không lấy từ nguồn ngoài.

• Ngày 1 đến 2: xác định website dùng responsive, dynamic serving hay URL riêng, và chọn 5 trang quan trọng nhất làm mẫu.
• Ngày 3 đến 5: so bản di động với bản máy tính trên 5 trang về nội dung chính, tiêu đề, mô tả, thẻ robots, dữ liệu có cấu trúc, ảnh kèm alt và video.
• Ngày 6 đến 8: kiểm robots.txt, tải lười, cửa sổ che nội dung và thẻ viewport.
• Ngày 9 đến 11: chạy URL Inspection (bản đã lập chỉ mục và Live Test) cho 5 trang, ghi Crawled as, bản hiển thị và tài nguyên bị chặn.
• Ngày 12 đến 14: sửa lỗi, chạy lại kiểm tra, rồi thiết lập theo dõi Page indexing, GA4 theo thiết bị và Core Web Vitals trên di động.

Điều chưa biết

Google không công bố danh sách website hiện vẫn bị thu thập bằng trình thu thập máy tính. Bài blog năm 2023 nói sẽ đánh giá lại vài lần mỗi năm, và Click Star không tìm thấy thông báo mới hơn.

Chưa có số đo mức mất lưu lượng khi bản di động thiếu nội dung: Google chỉ nói có thể xảy ra. Tài liệu không nêu cách xử lý nội dung ẩn bằng CSS display none.

Chưa có số đo cho Việt Nam về tỷ lệ truy cập di động hay tỷ lệ website còn dùng URL riêng. Trang URL Inspection và Crawl Stats không hiển thị ngày cập nhật. Click Star chưa kiểm nghiệm độ trễ chạm 300 mili giây trên Chrome hiện hành.

Những sai lầm thường gặp

1. Chỉ kiểm bản máy tính rồi kết luận website ổn.
2. Xóa bớt nội dung trên di động thay vì gom vào tab hoặc accordion.
3. Để thẻ robots khác nhau giữa 2 bản, nhất là noindex hoặc nofollow chỉ có ở bản di động.
4. Chặn CSS, JavaScript hoặc ảnh của bản di động trong robots.txt.
5. Tải lười nội dung chính chỉ khi người dùng cuộn hoặc bấm.
6. Tắt zoom bằng user-scalable=no hoặc đặt maximum-scale thấp.
7. Chuyển hướng mọi URL máy tính về trang chủ di động, hoặc khai báo canonical sai chiều giữa 2 bản.