Kiểm tra Mobile Friendly thế nào sau khi Google bỏ công cụ cũ?
Google đã dừng Mobile-Friendly Test và báo cáo Mobile Usability từ tháng 12/2023. Hiện không có một công cụ duy nhất thay thế hoàn toàn. Muốn kiểm tra Mobile Friendly đúng, bạn cần kết hợp bốn lớp: thao tác trên điện thoại thật, Chrome DevTools để tìm lỗi responsive, PageSpeed Insights để đo hiệu suất và URL Inspection để kiểm tra nội dung Google nhận được trên mobile.[1]
Một website co vừa màn hình chưa chắc dễ sử dụng. Menu có thể không đóng được, nút gọi quá sát mép, bàn phím che form hoặc bảng làm toàn trang tràn ngang. Ngược lại, một trang đạt 100 điểm SEO trong Lighthouse vẫn có thể tải nội dung chính quá chậm trên điện thoại.
Trước khi đi vào chi tiết, nếu bạn chưa nắm phần nền, xem thêm technical SEO là gì.
- Mở URL trên điện thoại thật và hoàn thành tác vụ chính.
- Dùng DevTools kiểm tra viewport, overflow và breakpoint.
- Đọc PageSpeed mobile, ưu tiên Field Data khi có.
- Dùng URL Inspection kiểm tra rendered HTML và SEO parity.
Mobile Friendly là gì?
Mobile Friendly là trạng thái một trang có thể đọc, điều hướng và hoàn thành tác vụ thuận tiện trên màn hình nhỏ. Trang cần thích ứng với viewport, không buộc người dùng zoom hoặc cuộn ngang toàn trang, có nút dễ bấm, nội dung đầy đủ và hiệu suất đủ tốt trong điều kiện thiết bị di động.
Mobile Friendly là kết quả trải nghiệm. Responsive Web Design là một phương pháp triển khai để đạt kết quả đó. Google khuyến nghị responsive vì cùng một URL và cùng HTML giúp việc triển khai, bảo trì và giữ nội dung nhất quán đơn giản hơn.[2]
| Khái niệm | Nói về điều gì? | Câu hỏi kiểm tra |
|---|---|---|
| Responsive | Cách layout thích ứng theo kích thước và khả năng thiết bị | Giao diện có đổi bố cục đúng ở các breakpoint không? |
| Mobile Friendly | Chất lượng sử dụng trang trên mobile | Người dùng có đọc, bấm và hoàn thành tác vụ thuận tiện không? |
| Mobile-First Indexing | Google dùng phiên bản mobile để index và xếp hạng | Nội dung, metadata, link và schema trên mobile có đầy đủ không? |
| Core Web Vitals | Trải nghiệm tải, phản hồi và ổn định bố cục của người dùng thật | LCP, INP và CLS ở phân vị 75 có đạt ngưỡng tốt không? |
Bốn khái niệm liên quan nhưng không thay thế nhau. Một trang có responsive vẫn có thể chậm. Một trang nhanh vẫn có thể thiếu nội dung trên mobile. Vì vậy, audit cần kiểm tra cả giao diện, hành vi, hiệu suất và khả năng Google đọc trang.
Google Mobile-Friendly Test còn dùng được không?
Không. Google đã ngừng Mobile-Friendly Test, Mobile-Friendly Test API và báo cáo Mobile Usability trong Search Console từ ngày 01/12/2023. Việc khai tử công cụ không có nghĩa trải nghiệm mobile hết quan trọng. Google giải thích rằng đã có nhiều nguồn kiểm tra mạnh hơn, trong đó có Lighthouse của Chrome.[1]
Vì vậy, những hướng dẫn yêu cầu truy cập công cụ cũ, dán URL rồi chờ kết quả “Trang thân thiện với thiết bị di động” đã lỗi thời. Bạn cũng không nên thay nó bằng một website checker khác rồi coi dấu tích xanh là kết luận cuối.
| Công cụ | Trả lời tốt nhất | Không thể kết luận một mình |
|---|---|---|
| Điện thoại thật | Người dùng có đọc, bấm, nhập và hoàn thành tác vụ được không? | Không chỉ ra đầy đủ request hoặc nguyên nhân kỹ thuật |
| Chrome DevTools | Lỗi breakpoint, overflow, DOM, CSS và tái hiện nhiều viewport | Chế độ mô phỏng không thay thế thiết bị thật |
| PageSpeed Insights | Field Data, Lab Data, hiệu suất và gợi ý chẩn đoán | Không kiểm thử toàn bộ hành trình hoặc mọi template |
| URL Inspection | Google có crawl, render và nhận nội dung chính của URL không? | Không thay thế kiểm thử UX bằng tay |
| Search Console CWV | Nhóm URL nào có vấn đề trải nghiệm thực tế theo thời gian? | Không chỉ ngay component cần sửa |
Ví dụ thật: Lighthouse SEO 100 nhưng Performance mobile chỉ 68
Ngày 02/08/2026 lúc 17:26, Mạnh Digital chạy PageSpeed Insights cho chính URL này trước khi viết lại. Báo cáo chưa có đủ dữ liệu CrUX cấp URL. Trong lần chạy lab mobile bằng Lighthouse 13.4.1, Performance đạt 68, trong khi Hỗ trợ tiếp cận, Best Practices và SEO đều đạt 100.
| Chỉ số | Kết quả | Điều cần đọc |
|---|---|---|
| Performance | 68 | Cần cải thiện trong lần chạy lab |
| FCP | 4,0 giây | Nội dung đầu tiên xuất hiện chậm |
| LCP | 5,3 giây | Nội dung chính xuất hiện chậm |
| TBT | 0 ms | Main thread không bị chặn đáng kể trong lần chạy |
| CLS | 0 | Bố cục ổn định trong lần chạy |
| Lighthouse SEO | 100 | Chỉ xác nhận nhóm kiểm tra SEO tự động cơ bản |
Ví dụ này cho thấy không nên hỏi “website có Mobile Friendly không?” như một câu chỉ có Có hoặc Không. Trang có thể vượt qua nhiều kiểm tra tự động nhưng vẫn cần xử lý LCP mobile. Đọc sâu hơn tại bài hướng dẫn Google PageSpeed Insights.
Bốn lớp kiểm tra ở trên đủ để phát hiện lỗi, nhưng xếp chúng theo P0–P2 và truy ngược về nguyên nhân trong theme lại thuộc phạm vi dịch vụ SEO audit.
Quy trình kiểm tra Mobile Friendly theo 7 bước
Bước 1: Chọn URL và tác vụ đại diện
Đừng chỉ kiểm tra trang chủ. Hãy chọn ít nhất một URL cho mỗi template quan trọng, chẳng hạn landing page dịch vụ, bài blog, trang sản phẩm và form nhận lead. Với mỗi URL, ghi rõ tác vụ cần hoàn thành như mở menu, gọi điện, đọc bảng giá hoặc gửi form.
Ưu tiên trang đang có traffic, conversion hoặc lỗi trong Search Console. Nếu một component bảng xuất hiện trên 50 bài, một lỗi tại đó có phạm vi lớn hơn lỗi trang trí chỉ có ở một URL.
Bước 2: Mở trang trên điện thoại thật
Thử ít nhất một thiết bị iOS và một thiết bị Android nếu có thể. Dùng cả Wi-Fi và mạng di động. Đọc từ đầu trang, mở menu, chạm internal link, xoay ngang, điền form và thử CTA gọi điện hoặc Zalo.
Điện thoại thật làm lộ những vấn đề chế độ mô phỏng thường bỏ sót như thanh địa chỉ thay đổi chiều cao, vùng an toàn quanh tai thỏ, bàn phím ảo che nút gửi, autofill làm vỡ form hoặc thao tác cuộn bị khóa sau khi đóng modal.
Bước 3: Dùng Chrome DevTools để tái hiện theo viewport
Mở DevTools, bật Device Mode rồi kiểm tra các chiều rộng 320, 375, 390, 414 và 768 CSS px. Đây là các mốc kiểm thử, không phải danh sách thiết bị cần thiết kế riêng. Hãy kéo liên tục giữa các mốc để tìm breakpoint gãy thay vì chỉ chọn một mẫu iPhone có sẵn.
Chrome lưu ý Device Mode chỉ là phép gần đúng. Nó mô phỏng viewport, user agent và một số điều kiện thiết bị, nhưng không biến máy tính thành điện thoại thật.[3]
Bước 4: Tìm overflow, chữ khó đọc và touch target nhỏ
Nếu toàn trang cuộn ngang, hãy kiểm tra ảnh có chiều rộng cố định, bảng, đoạn code, iframe, chuỗi ký tự dài và component dùng width lớn hơn viewport. Bảng nhiều cột có thể đặt trong vùng cuộn ngang riêng, nhưng không nên làm cả trang trượt sang hai bên.
Với nút và liên kết, mục tiêu thực dụng là vùng chạm khoảng 48 × 48 CSS px hoặc có khoảng cách đủ để tránh chạm nhầm. Kích thước biểu tượng có thể nhỏ hơn nếu padding mở rộng vùng bấm.[5]
document.documentElement.scrollWidth > document.documentElement.clientWidthNếu trả về true, trang đang rộng hơn viewport. Đây là tín hiệu để tìm phần tử gây tràn, không phải tên của nguyên nhân.
Bước 5: Kiểm thử menu, form và CTA bằng ngón tay
Kiểm tra menu có mở, đóng và giữ focus hợp lý không. Với form, thử kiểu dữ liệu sai, để trống trường bắt buộc, dùng autofill và quan sát khi bàn phím mở. Thông báo lỗi cần nằm gần trường liên quan và không chỉ biểu đạt bằng màu sắc.
CTA sticky không được che nội dung, nút chấp nhận cookie hoặc chat không nên phủ nút gửi. Nếu người dùng không thể gửi form hoặc gọi điện trên thiết bị phổ biến, đó là lỗi P0 vì chặn conversion.
Bước 6: Chạy PageSpeed Insights mobile
Đọc Field Data trước khi có đủ mẫu vì nó phản ánh người dùng Chrome thật trong cửa sổ 28 ngày. Dùng Lab Data để tìm nguyên nhân trong một lần mô phỏng. “Không có dữ liệu” chỉ có nghĩa chưa đủ mẫu CrUX, không phải trang đã nhanh.[4]
Không dừng ở điểm Performance. Hãy xem phần tử LCP, request chặn hiển thị, JavaScript không dùng đến, long task và tác động bên thứ ba. Với khả năng phản hồi, TBT trong lab hỗ trợ chẩn đoán nhưng không thay thế INP của người dùng thật.
Bước 7: Kiểm tra SEO parity bằng URL Inspection
Google dùng nội dung phiên bản mobile, được crawl bằng smartphone agent, để index và xếp hạng. Trong URL Inspection, hãy xem rendered page và xác nhận nội dung chính, heading, internal link, ảnh quan trọng, metadata và structured data vẫn đầy đủ.[2]
Không ẩn nội dung quan trọng chỉ để mobile ngắn hơn. Có thể dùng accordion hoặc tab để tiết kiệm không gian, miễn nội dung vẫn tồn tại trong HTML và không đòi hỏi người dùng tương tác mới được tải. Bài Mobile-First Indexing đi sâu vào phần kiểm tra mobile–desktop parity.
Sửa xong menu, nút bấm và bảng tràn ngang trên mobile mới chỉ là một mắt xích. Nội dung, internal link và kỹ thuật vẫn cần chạy song song, chứ không đợi mobile xong mới bắt đầu SEO tổng thể.
Checklist Mobile Friendly có thể dùng ngay
| Nhóm | Checklist | Dấu hiệu hoàn thành |
|---|---|---|
| Viewport | Có meta viewport, layout thích ứng, không tràn toàn trang | Không cần zoom hoặc cuộn ngang để đọc |
| Typography | Cỡ chữ, độ tương phản và chiều dài dòng dễ đọc | Đọc được trên máy thật ở độ sáng bình thường |
| Touch | Nút, link và control có vùng chạm đủ lớn, không quá sát | Không chạm nhầm trong luồng chính |
| Navigation | Menu, dropdown, accordion, modal và back button hoạt động | Không kẹt focus hoặc mất trạng thái |
| Form | Đúng input type, autofill, validation và bàn phím không che CTA | Gửi thành công trên iOS và Android mẫu |
| Content | Heading, text, link, ảnh và CTA tương đương desktop | Không mất intent hoặc đường dẫn chuyển đổi |
| SEO Technical | 200, canonical đúng, indexable, initial HTML đầy đủ, schema khớp | Googlebot Smartphone render được nội dung chính |
| Performance | Đọc Field Data, lab metrics, LCP element và script bên thứ ba | Đầu việc gắn với nguyên nhân và metric |
| Media | Ảnh responsive, có width và height, không tải bản quá lớn | Không tràn, không gây CLS, dung lượng hợp lý |
| Accessibility | Focus nhìn thấy, label rõ, thứ tự tab và trạng thái control đúng | Dùng được bằng bàn phím và công nghệ hỗ trợ cơ bản |
Danh sách lỗi mobile dài mà nguồn lực dev có hạn là tình huống rất phổ biến. Bạn có thể mang chính danh sách đó vào brief SEO miễn phí để cùng chốt thứ tự ưu tiên.
Cách sửa 7 lỗi Mobile Friendly thường gặp
1. Thiếu meta viewport
Thêm <meta name="viewport" content="width=device-width, initial-scale=1"> trong <head>. Không khóa zoom bằng user-scalable=no vì điều đó có thể gây vấn đề accessibility.[6]
2. Toàn trang bị cuộn ngang
Tìm phần tử rộng hơn viewport rồi sửa nguyên nhân. Ảnh nên có kích thước linh hoạt. Bảng và đoạn code dài nên nằm trong container cuộn riêng. Tránh dùng overflow-x: hidden để che lỗi khi phần tử quan trọng vẫn bị cắt.
3. Nút nhỏ hoặc quá sát nhau
Tăng padding và khoảng cách thay vì chỉ phóng to icon. Kiểm tra toàn bộ vùng bấm của thẻ a hoặc button, đặc biệt ở menu, phân trang, nút đóng và nhóm icon chia sẻ.
4. Form bị bàn phím che
Dùng đúng input type, cho phép trang cuộn tới trường đang focus và tránh đặt nút gửi ở vị trí bị bàn phím hoặc CTA sticky phủ. Test autofill, mã OTP, thông báo lỗi và trạng thái gửi chậm.
5. Ảnh mobile tải bản quá lớn
Dùng srcset và sizes để trình duyệt chọn ảnh phù hợp. Khai báo width và height để giữ chỗ. Ảnh dưới màn hình đầu có thể lazy-load, còn ảnh LCP không nên bị trì hoãn vô lý. Xem thêm quy trình Image SEO.
6. Nội dung hoặc internal link bị ẩn trên mobile
So DOM và rendered HTML giữa mobile với desktop. Đảm bảo nội dung trả lời Search Intent, internal link quan trọng, alt text và schema vẫn có mặt. Thiết kế gọn hơn không đồng nghĩa cắt đi thông tin mà Google cần.
7. JavaScript làm trang có vẻ ổn nhưng thao tác chậm
Ghi Performance trace để tìm long task, handler nặng và script bên thứ ba. Giảm bundle, trì hoãn công cụ không cần ngay và kiểm tra lại INP bằng dữ liệu thực tế. Đọc thêm bài Core Web Vitals và INP là gì.
Xếp lỗi mobile theo P0, P1 và P2
| Mức | Khi nào dùng? | Ví dụ | Nghiệm thu |
|---|---|---|---|
| P0 | Chặn truy cập, index hoặc conversion trên nhóm thiết bị quan trọng | Form không gửi, menu khóa trang, nội dung chính không render | Tác vụ hoàn thành trên máy thật và URL render đúng |
| P1 | Ảnh hưởng nhiều URL, Core Web Vitals hoặc trải nghiệm chính | Component bảng tràn, ảnh hero làm LCP xấu, link quá sát diện rộng | Sửa ở component và đo lại URL đại diện |
| P2 | Lỗi thẩm mỹ hoặc phạm vi hẹp, chưa chặn tác vụ | Khoảng cách chưa đẹp, animation phụ chưa mượt | Không tạo regression ở breakpoint khác |
Một ticket tốt cần có URL, thiết bị, hệ điều hành, chiều rộng viewport, bước tái hiện, ảnh hoặc video, tác động và kết quả mong đợi. “Sửa giao diện mobile” quá rộng để developer nghiệm thu.
Đọc thêm: redirect 301 vs 302 · cách thêm FAQ schema vào website đúng chuẩn google
Mobile Friendly liên quan gì đến SEO, GEO và AI Search?
Với SEO, Google dùng phiên bản mobile của trang để index và xếp hạng. Vì vậy, nội dung, metadata, internal link, ảnh và structured data trên mobile cần tương đương desktop. Mobile Friendly cũng nằm trong bức tranh page experience, nhưng không có một điểm tự động nào bảo đảm thứ hạng.
Với GEO và AI Search, Google không yêu cầu “schema dành cho AI” hoặc một điểm Mobile Friendly riêng. Điều kiện nền tảng vẫn là URL được crawl, index và đủ điều kiện hiển thị snippet. Initial HTML nên có câu trả lời chính, heading rõ, nguồn đáng tin và nội dung không bị khóa sau thao tác.[7]
Khả năng thao tác còn quan trọng khi hệ thống AI sử dụng DOM và accessibility tree để hiểu control. Nút cần tên rõ, form có label và trạng thái phải được biểu đạt bằng HTML phù hợp. Tuy nhiên, các bài kiểm tra “Agentic Browsing” còn đang phát triển. Không nên coi điểm thử nghiệm này là tín hiệu xếp hạng hoặc cam kết được AI trích dẫn.
8 sai lầm khi kiểm tra Mobile Friendly
- Tiếp tục dùng hướng dẫn trỏ tới Mobile-Friendly Test đã ngừng hoạt động.
- Thu nhỏ cửa sổ desktop rồi coi đó là test mobile.
- Chỉ kiểm tra một chiếc iPhone mới và Wi-Fi nhanh.
- Cho rằng responsive đồng nghĩa trang dễ sử dụng.
- Dùng điểm Lighthouse SEO 100 để kết luận toàn bộ trải nghiệm.
- Che overflow thay vì tìm phần tử gây tràn.
- Ẩn nội dung, link hoặc schema trên mobile để giao diện ngắn hơn.
- Tạo ticket không có thiết bị, bước tái hiện và mức ảnh hưởng.
Câu hỏi thường gặp
Google Mobile-Friendly Test còn hoạt động không?
Không. Google đã ngừng Mobile-Friendly Test, API của công cụ và báo cáo Mobile Usability trong Search Console từ ngày 01/12/2023. Hiện nên kết hợp điện thoại thật, Chrome DevTools, PageSpeed Insights, báo cáo Core Web Vitals và URL Inspection thay vì tìm một dấu “đạt” thay thế.
Công cụ nào kiểm tra Mobile Friendly tốt nhất?
Không có một công cụ tốt nhất cho mọi phần. Điện thoại thật kiểm tra tác vụ, DevTools tìm lỗi responsive, PageSpeed đo hiệu suất và URL Inspection cho biết Google render gì. Một quy trình đủ bốn lớp đáng tin hơn bất kỳ checker đơn lẻ nào.
Website responsive có chắc Mobile Friendly không?
Không. Responsive chỉ cho biết layout có khả năng thích ứng. Website vẫn có thể có chữ khó đọc, nút quá sát, form bị bàn phím che, nội dung mobile thiếu hoặc JavaScript khiến thao tác chậm. Mobile Friendly phải được xác nhận bằng trải nghiệm và tác vụ thật.
Điểm PageSpeed mobile bao nhiêu là tốt?
Điểm Performance 90–100 nằm trong vùng tốt của Lighthouse, nhưng đây là lab score của một lần chạy. Hãy ưu tiên Core Web Vitals của người dùng thật khi có dữ liệu và đọc từng metric để tìm nguyên nhân. Không nên tối ưu chỉ để đạt một con số.
Có cần kiểm tra mọi URL trên website không?
Không cần kiểm thủ công từng URL. Hãy lấy mẫu theo template và hành trình, ưu tiên URL có traffic hoặc conversion. Khi tìm thấy lỗi ở component dùng chung, sửa component rồi dùng crawler, test tự động và một nhóm URL đại diện để xác nhận phạm vi.
Search Console còn báo lỗi Mobile Usability không?
Báo cáo Mobile Usability cũ đã bị Google loại bỏ. Search Console vẫn hữu ích qua URL Inspection và Core Web Vitals. URL Inspection giúp kiểm tra crawl và rendered page, còn Core Web Vitals cho biết nhóm URL nào có trải nghiệm thực tế cần cải thiện.
Chiều rộng 320 px có phải chuẩn bắt buộc không?
Không phải một chuẩn xếp hạng riêng. Đây là mốc kiểm thử hữu ích để phát hiện layout gãy trên màn hình hẹp. Bạn nên kéo viewport liên tục, thử thêm 375, 390, 414 và 768 px, sau đó xác nhận trên thiết bị thật.
Kết luận
Kiểm tra Mobile Friendly năm 2026 không còn là dán URL vào một công cụ rồi chờ dấu tích xanh. Quy trình đúng phải kết hợp thiết bị thật, DevTools, PageSpeed Insights và URL Inspection. Mỗi lớp trả lời một câu hỏi khác nhau và cùng tạo ra bằng chứng đủ để ưu tiên sửa lỗi.
Hãy bắt đầu từ tác vụ tạo giá trị như đọc nội dung, gọi điện hoặc gửi form. Sửa P0 trước, sau đó xử lý component ảnh hưởng nhiều URL và theo dõi dữ liệu sau deploy. Nếu lỗi trải trên nhiều template hoặc chưa rõ nguyên nhân gốc, một SEO Audit nên xác định phạm vi, bằng chứng và mức ưu tiên trước khi sửa.
Nguồn tham khảo
- Google Search Central: The Search Console mobile friendly testing tool, retired, cập nhật ngày 01/12/2023.
- Google Search Central: Mobile site and mobile-first indexing best practices, cập nhật ngày 10/12/2025.
- Chrome for Developers: Simulate mobile devices with Device Mode, truy cập ngày 02/08/2026.
- Google Developers: About PageSpeed Insights, truy cập ngày 02/08/2026.
- web.dev: Accessible tap targets, truy cập ngày 02/08/2026.
- web.dev: Responsive web design basics, truy cập ngày 02/08/2026.
- Google Search Central: Optimizing your website for generative AI features, truy cập ngày 02/08/2026.