Checklist Mobile-First 2026: 59 tiêu chí kiểm tra website

Bạn mở website bằng điện thoại. Banner vẫn vừa màn hình, menu vẫn bấm được, vậy là trang đã chuẩn mobile?

Chưa chắc.

Nếu khách phải cuộn qua bốn màn hình mới hiểu bạn bán gì, nút liên hệ bị thanh chat che mất hoặc form khó nhập đến mức họ bỏ cuộc, website vẫn đang mất lead dù giao diện không hề bị vỡ.

Đó cũng là lý do một website responsive chưa chắc đã là một website mobile-first. Responsive chủ yếu giúp giao diện thích ứng với kích thước màn hình. Mobile-first đi xa hơn: nội dung nào cần xuất hiện trước, thao tác nào phải dễ thực hiện và trang có giữ được khả năng tạo chuyển đổi trên điện thoại hay không.

Trong bài này, danh sách kiểm tra di động-first được chia thành 7 giai đoạn với 59 tiêu chí. Bạn có thể dùng nó trước khi ra mắt website mới, sau một đợt thiết kế lại hoặc khi traffic mobile tăng nhưng số lead không tăng theo.

Checklist được xây dựng trên ba câu hỏi đơn giản:

• Google có đọc được đầy đủ phiên bản mobile không?
• Người dùng có hiểu và thao tác thuận lợi không?
• Website có giúp họ hoàn thành hành động quan trọng không?

Nếu chỉ muốn kiểm tra nhanh, hãy dành 30 phút cho quy trình ở cuối bài. Nếu đang chuẩn bị làm mới website, bạn có thể tham khảo thêm quy trình thiết kế website chuẩn SEO để đưa Mobile-First vào dự án ngay từ giai đoạn đầu.

Tải checklist Mobile-First 2026 (PDF)

Bạn không cần đọc xong toàn bộ bài mới bắt đầu kiểm tra. Markdao đã chuyển 59 tiêu chí thành một file PDF thực hành để đội marketing, SEO, thiết kế và phát triển cùng audit trên một chuẩn chung.

Trong file, mỗi tiêu chí có ô Đạt, Chưa đạt và N/A, kèm khu vực ghi bằng chứng, owner và hạn xử lý. Bạn cũng có thể dùng thang điểm 100 để biết nên sửa nền tảng hay tiếp tục tối ưu chuyển đổi.

• 7 giai đoạn từ khả năng Google đọc trang đến kiểm tra lead trong CRM.
• Quy trình audit nhanh trong 30 phút.
• Thang điểm 100, mức ưu tiên P0-P2 và mẫu kế hoạch sửa lỗi trong một sprint.

TẢI CHECKLIST MOBILE-FIRST 2026 (PDF)

File PDF 12 trang · 59 tiêu chí · Có thể in hoặc dùng khi nghiệm thu website.

Mobile-First là gì? Vì sao website vừa màn hình vẫn chưa đủ?

Mobile-First là cách thiết kế và xây dựng website bắt đầu từ nhu cầu của người dùng trên màn hình nhỏ, sau đó mới mở rộng trải nghiệm cho máy tính bảng và máy tính. Cách làm này buộc đội ngũ phải chọn điều gì quan trọng nhất, bỏ bớt phần gây nhiễu và làm cho hành động chính dễ hoàn thành bằng thao tác chạm.

Responsive và Mobile-First không đối lập nhau.

• Responsive là cách giao diện co giãn để phù hợp nhiều kích thước màn hình.
• Mobile-First là cách ưu tiên nội dung, hiệu suất và hành trình sử dụng ngay từ màn hình nhỏ.
• Mobile SEO bảo đảm Google đọc đúng và đủ phiên bản mobile.
• Mobile CRO giúp người dùng hoàn thành cuộc gọi, form, đặt lịch hoặc đơn hàng với ít trở ngại hơn.

Ví dụ, trên máy tính, ba bảng giá có thể đặt cạnh nhau. Khi xuống điện thoại, nếu chỉ xếp cả ba bảng thành một cột dài, trang vẫn responsive nhưng khách phải cuộn rất lâu mới thấy nút đăng ký. Thiết kế website mobile-first sẽ buộc đội ngũ chọn gói cần ưu tiên, rút gọn phần so sánh và đặt lời kêu gọi hành động đúng lúc.

Google hiện dùng phiên bản mobile làm cơ sở chính để thu thập dữ liệu và lập chỉ mục. Vì vậy, nội dung quan trọng bị thiếu trên điện thoại không chỉ làm khách khó dùng mà còn khiến Google nhận được một phiên bản nghèo thông tin hơn. Bạn có thể xem nguyên tắc chính thức tại hướng dẫn Mobile-First Indexing của Google.

Trước khi kiểm tra website trên di động, hãy xác định khách vào trang để làm gì

Một checklist chỉ có ý nghĩa khi gắn với mục tiêu của từng trang. Trang dịch vụ, trang sản phẩm và bài blog không thể dùng chung một tiêu chuẩn chuyển đổi.

Trước khi bắt đầu, hãy trả lời năm câu hỏi:

• Người dùng đến từ Google, quảng cáo, mạng xã hội hay đường dẫn trực tiếp?
• Họ muốn đọc thông tin, so sánh lựa chọn, gọi điện, đặt lịch hay mua hàng?
• Hành động quan trọng nhất trên trang là gì?
• Bao nhiêu phần trăm traffic và lead hiện đến từ điện thoại?
• Trang nào có nhiều lượt truy cập mobile nhưng tỷ lệ chuyển đổi thấp?

Với một trang dịch vụ B2B, mục tiêu không phải để khách đọc hết mọi đoạn chữ. Họ cần hiểu doanh nghiệp giải quyết vấn đề gì, xem bằng chứng phù hợp và dễ dàng gửi yêu cầu tư vấn. Với một trang thương mại điện tử, nhiệm vụ lại là giúp khách tìm đúng sản phẩm, so sánh nhanh và thanh toán thuận lợi.

Hãy ghi mục tiêu của trang thành một câu. Ví dụ: “Sau khi đọc trang này trên điện thoại, khách phù hợp có thể hiểu dịch vụ và gửi form tư vấn trong dưới ba phút”. Câu này sẽ giúp bạn phân biệt yếu tố thật sự cần sửa với phần chỉ mang tính thẩm mỹ.

Giai đoạn 1: Google có nhìn thấy đầy đủ phiên bản mobile không?

Một giao diện đẹp không có nhiều ý nghĩa nếu Google chỉ nhìn thấy một phần nội dung. Giai đoạn đầu tiên của checklist SEO mobile là kiểm tra khả năng thu thập dữ liệu, lập chỉ mục và sự nhất quán giữa mobile với desktop.

8 tiêu chí cần kiểm tra

• Googlebot Smartphone có truy cập được URL và nhận mã trạng thái 200 không?
• Nội dung chính trên mobile có đầy đủ như desktop không?
• Title, meta description và H1 có đúng với chủ đề của trang không?
• Structured data trên mobile có đầy đủ và hợp lệ không?
• Robots meta, canonical và hreflang có được cấu hình đúng không?
• CSS, JavaScript, hình ảnh và font quan trọng có bị chặn với Googlebot không?
• Nội dung chính có tải được mà không cần người dùng bấm, vuốt hoặc thực hiện một hành động đặc biệt không?
• Internal link quan trọng có còn xuất hiện và truy cập được trên giao diện mobile không?

Cách kiểm tra

Mở URL Inspection trong Google Search Console, nhập URL cần kiểm tra và chạy kiểm tra phiên bản đang hoạt động. Xem ảnh chụp trang Google nhận được, HTML đã kết xuất và danh sách tài nguyên không tải được.

Sau đó mở cùng URL trên máy tính và điện thoại. So sánh các phần sau:

• Nội dung dịch vụ hoặc sản phẩm.
• Heading và đoạn trả lời câu hỏi chính.
• Hình ảnh, video và alt text.
• Breadcrumb và internal link.
• FAQ, review và dữ liệu có cấu trúc.
• Nút liên hệ, form và thông tin doanh nghiệp.

Accordion và tab vẫn có thể sử dụng trên mobile, miễn là nội dung đã có trong HTML và người dùng có thể mở bằng thao tác bình thường. Điều cần tránh là tải nội dung chính chỉ sau một cú nhấp mà Googlebot không thể thực hiện.

Khi nào được xem là đạt?

Google nhìn thấy cùng nội dung chính, heading, liên kết và dữ liệu có cấu trúc như người dùng mobile. Phiên bản mobile không tự gắn noindex, không canonical sai và không làm mất đường dẫn đến các trang quan trọng.

Nếu chưa đạt, nên sửa từ đâu?

Ưu tiên lỗi chặn lập chỉ mục trước. Sau đó sửa sự khác biệt về nội dung, metadata, schema và internal link. Nếu website dùng một phiên bản riêng dạng m.domain.com, cần kiểm tra thêm chuyển hướng, canonical và hreflang giữa hai phiên bản. Với phần lớn website doanh nghiệp hiện nay, responsive dùng chung URL thường dễ quản trị hơn.

Nếu cần rà soát toàn bộ hệ thống ngoài Mobile SEO, bạn có thể tham khảo dịch vụ SEO tổng thể của Markdao.

Giai đoạn 2: Khách có hiểu website trong vài giây đầu không?

Người dùng mobile thường đến với một câu hỏi cụ thể. Họ muốn biết mình có vào đúng nơi hay không và cần làm gì tiếp theo. Nếu màn hình đầu chỉ có một hình ảnh lớn, câu giới thiệu chung chung và nhiều nút cạnh tranh nhau, khách phải tự giải mã trước khi hành động.

8 tiêu chí cần kiểm tra

• Màn hình đầu có nói rõ doanh nghiệp đang cung cấp gì không?
• Người đọc có nhận ra sản phẩm hoặc dịch vụ dành cho ai không?
• Lợi ích chính có cụ thể thay vì chỉ là một câu khẩu hiệu không?
• Trang có một hành động chính nổi bật hơn các hành động phụ không?
• CTA có dùng lời rõ ràng như “Nhận tư vấn”, “Xem bảng giá” hoặc “Đặt lịch” không?
• Hình ảnh đầu trang có hỗ trợ thông điệp thay vì chỉ dùng để trang trí không?
• Popup, cookie banner hoặc quảng cáo có che nội dung trước khi khách kịp đọc không?
• Nội dung quan trọng có xuất hiện đủ sớm mà không bị banner và khoảng trắng đẩy xuống quá sâu không?

Cách kiểm tra

Đưa điện thoại cho một người chưa biết thương hiệu. Cho họ xem trang trong năm giây rồi tắt màn hình. Hỏi ba câu:

• Website này cung cấp gì?
• Dành cho ai?
• Nếu quan tâm, bạn sẽ bấm vào đâu?

Nếu họ không trả lời được, vấn đề thường nằm ở thứ tự nội dung chứ không phải màu sắc hay hiệu ứng.

Khi nào được xem là đạt?

Một khách mới có thể hiểu đề nghị chính và nhận ra bước tiếp theo mà không cần đọc toàn bộ trang. CTA đầu tiên không nhất thiết phải bán hàng ngay, nhưng phải phù hợp với mức độ sẵn sàng của người đọc.

Nếu chưa đạt, nên sửa từ đâu?

Bắt đầu bằng việc viết lại màn hình đầu theo ba lớp:

• Bạn giúp ai?
• Bạn giúp họ đạt kết quả gì?
• Họ nên làm gì tiếp theo?

Giữ một CTA chính. Những hành động như xem case study, đọc thêm hoặc theo dõi mạng xã hội nên có mức ưu tiên thấp hơn. Nếu trang có nhiều nhóm khách, điều hướng họ bằng lựa chọn rõ ràng thay vì cố gộp tất cả vào một câu giới thiệu.

Giai đoạn 3: Nội dung có thực sự dễ đọc trên điện thoại không?

Nội dung đầy đủ chưa chắc đã dễ tiếp nhận. Một bài viết có thể chuẩn SEO trên máy tính nhưng trở nên nặng nề trên điện thoại vì đoạn quá dài, bảng quá rộng và infographic chứa quá nhiều chữ nhỏ.

8 tiêu chí cần kiểm tra

• Nội dung có đọc được mà không cần phóng to không?
• Mỗi đoạn có tập trung vào một ý chính không?
• Heading có giúp người đọc lướt nhanh và tìm đúng phần cần xem không?
• Dòng chữ có đủ thoáng, không quá dài hoặc quá sát nhau không?
• Bảng biểu có thích ứng với màn hình nhỏ mà vẫn đọc được không?
• Hình ảnh và infographic có chữ đủ lớn trên điện thoại không?
• Trang có bị cuộn ngang ở chiều rộng 320, 360, 390 hoặc 430 px không?
• Nội dung quan trọng có bị xóa khỏi mobile chỉ để trang trông ngắn hơn không?

Cách kiểm tra

Đừng chỉ nhìn trang ở kích thước iPhone mới. Hãy kiểm tra cả màn hình nhỏ. Cuộn từ đầu đến cuối và đánh dấu nơi bạn phải dừng lại để phóng to, kéo ngang hoặc đọc lại lần thứ hai.

Với bảng biểu, thử ba cách:

• Chuyển mỗi hàng thành một thẻ thông tin.
• Giữ các cột quan trọng, đưa chi tiết vào phần mở rộng.
• Cho phép cuộn ngang có chỉ dẫn rõ ràng nếu không thể rút gọn.

Với infographic, đừng lấy một hình dành cho desktop rồi thu nhỏ xuống. Nếu người đọc không thể đọc chữ ở kích thước hiển thị thật, hình đó không còn làm nhiệm vụ giải thích.

Khi nào được xem là đạt?

Người dùng có thể đọc, lướt và hiểu nội dung bằng một tay, không cần phóng to và không gặp đoạn nào bị cắt. Heading phản ánh đúng câu hỏi người đọc đang tìm, thay vì chỉ chứa từ khóa cho máy tìm kiếm.

Nếu chưa đạt, nên sửa từ đâu?

Chia đoạn dài thành các khối nhỏ. Đưa kết luận lên trước, phần giải thích ở sau. Chuyển bảng rộng thành thẻ hoặc so sánh từng tiêu chí. Với nội dung phụ, có thể dùng accordion nhưng không nên xóa khỏi mobile.

Đây cũng là nguyên tắc quan trọng khi thiết kế landing page chuẩn SEO: nội dung cần đủ để Google hiểu, nhưng phải được sắp xếp để khách tìm thấy câu trả lời nhanh.

Giai đoạn 4: Khách có bấm và điều hướng thuận lợi bằng một tay không?

Nhiều lỗi mobile chỉ xuất hiện khi người dùng thật bắt đầu chạm. Nút có thể nhìn đủ lớn nhưng vùng bấm lại nhỏ. Menu có thể mở được nhưng không đóng được. Thanh Zalo, chat, cookie và CTA có thể cùng chiếm phần dưới màn hình.

9 tiêu chí cần kiểm tra

• Nút, liên kết và vùng điều khiển có kích thước đủ để chạm chính xác không?
• Các hành động đặt cạnh nhau có đủ khoảng cách để tránh bấm nhầm không?
• Menu mobile có mở, đóng và quay lại cấp trước một cách rõ ràng không?
• Toàn bộ điều hướng có hoạt động bằng thao tác chạm, không phụ thuộc vào hover không?
• CTA quan trọng có nằm ở vị trí dễ tiếp cận trong ngữ cảnh sử dụng không?
• Sticky bar có che nội dung, nút gửi hoặc thông báo lỗi không?
• Chat, hotline, Zalo và cookie banner có chồng lên nhau không?
• Người dùng có thể nhận biết phần tử đang được chọn hoặc đang có focus không?
• Trang có sử dụng màu sắc, độ tương phản và nhãn điều khiển đủ rõ không?

Kích thước vùng chạm nên là bao nhiêu?

Theo WCAG 2.2, mục tiêu chạm ở mức AA cần đạt tối thiểu 24 x 24 CSS px hoặc đáp ứng ngoại lệ về khoảng cách. Với CTA chính, menu và các điều khiển thường xuyên sử dụng, khoảng 44 x 44 CSS px là một mức thực tế dễ thao tác hơn. Xem chi tiết tại W3C Target Size Minimum.

Không nên áp dụng thumb zone như một bản đồ cố định cho mọi website. Vị trí dễ chạm còn phụ thuộc tay thuận, cách cầm máy, độ tuổi, kích thước thiết bị và thói quen đã hình thành. Một menu ở đáy màn hình có thể dễ chạm nhưng vẫn gây bối rối nếu đi ngược quy ước quen thuộc của người dùng.

Cách kiểm tra

Giữ điện thoại bằng một tay và hoàn thành các tác vụ chính. Làm lại bằng tay còn lại. Sau đó bật cỡ chữ hệ thống lớn hơn và zoom trình duyệt để xem giao diện có còn dùng được không.

Đặc biệt kiểm tra những điểm thường bị bỏ qua:

• Nút đóng popup.
• Checkbox đồng ý điều khoản.
• Mũi tên của carousel.
• Link trong footer.
• Nút quay lại trong menu nhiều cấp.
• Nút gửi form khi bàn phím đang mở.

Khi nào được xem là đạt?

Người dùng không phải đổi tư thế cầm máy liên tục, không thường xuyên bấm nhầm và không có hành động quan trọng nào bị lớp giao diện khác che mất.

Nếu chưa đạt, nên sửa từ đâu?

Sửa xung đột giữa các lớp nổi trước. Sau đó tăng vùng chạm, khoảng cách và trạng thái focus. Nếu có nhiều nút cố định ở đáy màn hình, giữ lại một hành động chính, chuyển hành động phụ vào menu hoặc một vùng ít gây cản trở hơn.

Giai đoạn 5: Website có nhanh với người dùng thật không?

Điểm PageSpeed không phải mục tiêu cuối cùng. Điều cần quan tâm là khách thật có phải chờ, bấm mà trang không phản hồi hoặc đang đọc thì bố cục bất ngờ nhảy đi hay không.

8 tiêu chí cần kiểm tra

• Dữ liệu thực tế trên mobile có đạt Core Web Vitals không?
• LCP có không quá 2,5 giây ở phân vị 75 không?
• INP có không quá 200 mili giây ở phân vị 75 không?
• CLS có không quá 0,1 ở phân vị 75 không?
• Hình ảnh đầu trang có đúng kích thước, định dạng và dung lượng cần thiết không?
• Font, CSS và JavaScript quan trọng có làm chậm nội dung đầu tiên không?
• Script bên thứ ba như chat, quảng cáo và theo dõi có được kiểm soát không?
• Website có được kiểm tra trong điều kiện mạng chậm và trên điện thoại tầm trung không?

Field data và lab data khác nhau thế nào?

Field data là dữ liệu từ người dùng thật, thường được tổng hợp trong Chrome User Experience Report và hiển thị trên PageSpeed Insights hoặc Search Console. Lab data là kết quả mô phỏng trong một điều kiện kiểm thử cụ thể.

Có thể hiểu đơn giản:

• Field data cho biết người dùng thật đang gặp vấn đề gì.
• Lighthouse và lab data giúp tìm nguyên nhân có thể gây ra vấn đề đó.

Một lần chạy Lighthouse thấp không đủ để kết luận toàn bộ người dùng đều gặp trải nghiệm kém. Ngược lại, một lần đạt 95 điểm cũng không chứng minh website luôn nhanh với mọi thiết bị. Google cũng lưu ý điểm hiệu suất có thể thay đổi theo môi trường kiểm thử, thiết bị, tiện ích trình duyệt và nội dung động. Xem thêm tại Lighthouse performance scoring.

Cách kiểm tra

Mở PageSpeed Insights và nhập URL. Nếu có dữ liệu thực tế, đọc phần trải nghiệm của người dùng thật trước. Sau đó dùng phần chẩn đoán để xác định nguyên nhân.

Kiểm tra theo từng mẫu trang, không chỉ trang chủ:

• Trang chủ.
• Trang dịch vụ hoặc danh mục.
• Trang sản phẩm.
• Bài blog nhiều hình.
• Landing page chạy quảng cáo.
• Form hoặc quy trình thanh toán.

Các nguyên nhân thường gặp

LCP kém thường đến từ ảnh hero quá nặng, máy chủ phản hồi chậm, CSS chặn hiển thị hoặc tài nguyên quan trọng được phát hiện quá muộn.

INP kém thường liên quan đến JavaScript nặng, tác vụ dài trên luồng chính, bộ lọc phức tạp hoặc quá nhiều script của bên thứ ba.

CLS kém thường xuất hiện khi ảnh không khai báo kích thước, font thay đổi sau khi tải hoặc banner được chèn vào phía trên nội dung đang đọc.

Khi nào được xem là đạt?

Ba chỉ số Core Web Vitals đạt ngưỡng tốt ở phân vị 75 cho người dùng mobile. Quan trọng hơn, trang phản hồi ổn định trên thiết bị thật và không chỉ đẹp trong một lần kiểm thử thuận lợi. Ngưỡng chính thức được cập nhật tại Core Web Vitals của web.dev.

Nếu chưa đạt, nên sửa từ đâu?

Ưu tiên mẫu trang có nhiều traffic hoặc tạo nhiều doanh thu. Sửa yếu tố LCP, lỗi layout shift và tác vụ JavaScript dài trước khi tối ưu các chi tiết nhỏ. Đừng xóa toàn bộ tracking một cách vội vàng. Hãy xác định script nào thực sự phục vụ đo lường và script nào đang chạy nhưng không còn được sử dụng.

Giai đoạn 6: Form và hành trình tạo lead có hoàn thành được không?

Đây là nơi một website có thể vượt qua mọi bài kiểm tra kỹ thuật nhưng vẫn không tạo ra kết quả. Nút bấm hoạt động không có nghĩa là hành trình chuyển đổi đã ổn. Khách còn phải hiểu điều gì sẽ xảy ra, nhập thông tin thuận lợi và nhận được xác nhận rõ ràng.

10 tiêu chí cần kiểm tra

• CTA có dẫn đúng đến hành động mà nội dung đã hứa không?
• Form có chỉ hỏi thông tin cần thiết cho bước hiện tại không?
• Mỗi trường có label rõ và không biến mất khi người dùng bắt đầu nhập không?
• Bàn phím có đúng với dữ liệu cần nhập như số điện thoại, email hoặc mã số không?
• Trình duyệt có thể tự điền những thông tin phù hợp không?
• Thông báo lỗi có chỉ rõ trường nào sai và cách sửa không?
• Bàn phím có che trường nhập, thông báo lỗi hoặc nút gửi không?
• Nút gửi có phản hồi rõ để người dùng không bấm nhiều lần không?
• Sau khi gửi, khách có nhận được thông báo hoặc bước tiếp theo rõ ràng không?
• Lead, cuộc gọi hoặc giao dịch có được ghi nhận đúng trong công cụ đo lường và CRM không?

Cách kiểm tra

Đừng chỉ bấm thử nút gửi. Hãy đóng vai một khách mới và hoàn thành toàn bộ hành trình:

• Tìm trang từ Google hoặc một đường dẫn chiến dịch.
• Đọc phần giới thiệu và bằng chứng.
• Bấm CTA.
• Điền form với dữ liệu hợp lệ.
• Thử bỏ trống một trường bắt buộc.
• Thử nhập sai email hoặc số điện thoại.
• Gửi form khi bàn phím vẫn đang mở.
• Kiểm tra thông báo thành công.
• Kiểm tra lead có vào email, CRM hoặc hệ thống bán hàng không.
• Kiểm tra sự kiện chuyển đổi có được ghi nhận một lần không.

Một form có thể gửi thành công nhưng lead không đến đội bán hàng. Một nút gọi điện có thể mở đúng ứng dụng nhưng không được gắn sự kiện đo lường. Những lỗi này không xuất hiện trong báo cáo giao diện, nhưng ảnh hưởng trực tiếp đến doanh thu.

Khi nào được xem là đạt?

Một khách phù hợp có thể hoàn thành hành động chính bằng điện thoại mà không cần đoán, không phải nhập lại và không bị ngắt giữa chừng. Doanh nghiệp nhận được dữ liệu đúng và biết lead đến từ nguồn nào.

Nếu chưa đạt, nên sửa từ đâu?

Sửa lỗi khiến hành trình không thể hoàn thành trước. Sau đó giảm số trường, cải thiện thông báo lỗi và bổ sung autocomplete. Cuối cùng mới thử nghiệm vị trí CTA, câu chữ và bằng chứng gần form.

Để đi sâu hơn vào mối quan hệ giữa giao diện và chuyển đổi, xem 7 nguyên tắc UX/UI cho CRO.

Giai đoạn 7: Website có được kiểm tra trên thiết bị thật và theo dõi sau khi sửa không?

Chrome DevTools rất hữu ích để phát hiện lỗi sớm, nhưng không thể mô phỏng đầy đủ trình duyệt, bàn phím, thao tác chạm, font và hiệu suất của từng điện thoại. Kiểm tra website trên di động chỉ hoàn chỉnh khi có thiết bị thật và dữ liệu sau khi thay đổi.

8 tiêu chí cần kiểm tra

• Website đã được thử trên ít nhất một iPhone dùng Safari chưa?
• Website đã được thử trên ít nhất một điện thoại Android dùng Chrome chưa?
• Màn hình nhỏ và màn hình lớn đều hiển thị đúng không?
• Chế độ dọc và ngang có làm vỡ bố cục hoặc che nút không?
• Cỡ chữ hệ thống lớn và zoom 200% có làm nội dung mất hoặc chồng lên nhau không?
• Menu, popup, video, form, upload và thanh toán đã được thử từ đầu đến cuối chưa?
• Các lỗi đã được ghi rõ mức độ, ảnh chụp, người phụ trách và hạn xử lý chưa?
• Sau khi sửa, doanh nghiệp có theo dõi traffic, Core Web Vitals và chuyển đổi mobile không?

Ma trận thiết bị tối thiểu

Với một website doanh nghiệp thông thường, bộ kiểm tra tối thiểu nên gồm:

• Một iPhone màn hình nhỏ hoặc trung bình với Safari.
• Một điện thoại Android tầm trung với Chrome.
• Một thiết bị màn hình lớn.
• Chế độ dọc và ngang.
• Wi-Fi và mạng di động chậm.
• Font hệ thống lớn và zoom trình duyệt.

Nếu phần lớn khách hàng dùng một dòng thiết bị hoặc trình duyệt cụ thể, hãy ưu tiên theo dữ liệu trong GA4 thay vì cố kiểm tra mọi thiết bị trên thị trường.

Khi nào được xem là đạt?

Hành trình quan trọng hoạt động ổn định trên những thiết bị đại diện cho phần lớn người dùng. Mỗi lỗi đều có người phụ trách và được kiểm tra lại sau khi sửa. Các thay đổi không chỉ được xác nhận bằng cảm giác mà còn bằng dữ liệu thực tế.

Nếu chưa đạt, nên sửa từ đâu?

Phân loại lỗi theo tác động:

• P0: Trang không lập chỉ mục được, CTA hoặc form không hoạt động, thanh toán thất bại, nội dung chính biến mất.
• P1: Hành trình vẫn hoàn thành được nhưng khó dùng, chậm hoặc dễ bấm nhầm.
• P2: Lỗi thẩm mỹ và tính nhất quán chưa ảnh hưởng trực tiếp đến tác vụ chính.

Sửa P0 trước khi chạy quảng cáo hoặc đẩy thêm traffic. P1 được xử lý trong đợt phát hành gần nhất. P2 có thể gom thành một đợt cải thiện giao diện.

Cùng một checklist, mỗi loại website cần ưu tiên khác nhau

Một lỗi có thể rất nghiêm trọng với website này nhưng ít quan trọng hơn với website khác. Dưới đây là cách điều chỉnh thứ tự ưu tiên theo mô hình kinh doanh.

Website dịch vụ B2B

Người mua B2B thường cần hiểu năng lực, xem bằng chứng và đánh giá mức độ phù hợp trước khi liên hệ. Trên mobile, hãy ưu tiên:

• Thông điệp rõ về vấn đề và nhóm khách hàng.
• Dịch vụ, ngành đã phục vụ và phạm vi công việc.
• Case study hoặc bằng chứng gần CTA.
• Form ngắn ở lần liên hệ đầu.
• Nút gọi điện, gửi yêu cầu hoặc đặt lịch hoạt động ổn định.
• File năng lực có thể đọc được trên điện thoại.

Ví dụ, một trang dịch vụ có thể có bài viết chuyên môn rất dài nhưng lại giấu form sau năm màn hình. Cách sửa không nhất thiết là cắt bài. Có thể thêm CTA theo ngữ cảnh sau phần giải thích vấn đề và sau case study.

Nếu doanh nghiệp đang chuẩn bị xây lại hành trình này, dịch vụ thiết kế website chuyên nghiệp của Markdao có thể giúp kết nối cấu trúc nội dung, trải nghiệm và mục tiêu tạo lead ngay từ đầu.

Website thương mại điện tử

Khách mua hàng trên điện thoại cần tìm nhanh, so sánh đủ và thanh toán thuận lợi. Hãy ưu tiên:

• Tìm kiếm và bộ lọc dễ dùng.
• Ảnh sản phẩm tải nhanh nhưng vẫn đủ rõ.
• Giá, biến thể, tình trạng hàng và phí giao hàng dễ thấy.
• Nút thêm vào giỏ không bị che.
• Giỏ hàng giữ đúng sản phẩm và số lượng.
• Mã giảm giá không làm gián đoạn thanh toán.
• Hình thức thanh toán phù hợp với mobile.
• Thông báo lỗi rõ khi giao dịch không thành công.

Một bộ lọc đẹp nhưng chậm phản hồi có thể gây hại hơn một bộ lọc đơn giản. Trên màn hình nhỏ, tốc độ nhận phản hồi và khả năng quay lại danh sách quan trọng hơn số hiệu ứng chuyển động.

Website phòng khám, nhà hàng và doanh nghiệp địa phương

Người dùng thường đang cần hành động ngay. Họ có thể đang di chuyển, so sánh địa điểm hoặc tìm giờ mở cửa. Hãy ưu tiên:

• Nút gọi điện và đặt lịch.
• Địa chỉ, bản đồ và giờ mở cửa.
• Dịch vụ hoặc thực đơn dễ xem.
• Chi phí hoặc cách nhận báo giá.
• Review và bằng chứng tin cậy.
• Thông tin nhất quán với Google Business Profile.
• Form ngắn, không bắt tạo tài khoản nếu không cần.

Website SaaS

Với SaaS, mục tiêu mobile có thể khác desktop. Một hệ thống phức tạp không nhất thiết phải đưa toàn bộ trải nghiệm quản trị lên điện thoại, nhưng người dùng vẫn cần:

• Hiểu sản phẩm giải quyết việc gì.
• Xem tính năng và trường hợp sử dụng.
• Xem demo hoặc video không bị vỡ.
• Đăng ký dùng thử hoặc đặt lịch.
• Nhận email xác nhận và bước onboarding tiếp theo.
• Đăng nhập và xử lý những tác vụ khẩn cấp nếu sản phẩm hỗ trợ mobile.

Mobile-First không có nghĩa là ép mọi tác vụ desktop vào màn hình nhỏ. Nó có nghĩa là xác định đúng tác vụ người dùng thực sự cần trên điện thoại và làm tốt những tác vụ đó.

Cách chấm điểm checklist Mobile-First theo thang 100

Để tránh một danh sách dài nhưng không biết bắt đầu từ đâu, hãy chấm điểm theo sáu nhóm:

• Google đọc được đầy đủ: 20 điểm.
• Nội dung rõ và dễ đọc: 15 điểm.
• Điều hướng, thao tác chạm và accessibility: 15 điểm.
• Tốc độ và độ ổn định: 20 điểm.
• Form và chuyển đổi: 20 điểm.
• Thiết bị thật và theo dõi: 10 điểm.

Cách hiểu kết quả:

• 85 đến 100 điểm: Nền tảng tốt, tiếp tục xử lý các lỗi P1 và thử nghiệm chuyển đổi.
• 70 đến 84 điểm: Website dùng được nhưng còn điểm nghẽn đáng kể. Chưa nên tăng mạnh traffic trước khi sửa.
• Dưới 70 điểm: Cần xử lý lại các phần nền tảng trước khi đầu tư thêm cho SEO hoặc quảng cáo.

Có một nguyên tắc quan trọng: tổng điểm cao không thể bù cho lỗi nghiêm trọng. Nếu trang bị noindex, form không gửi được hoặc nút thanh toán bị che trên mobile, website chưa đạt dù tổng điểm vẫn trên 85.

Quy trình kiểm tra website mobile trong 30 phút

Nếu chưa có thời gian làm toàn bộ 59 tiêu chí, hãy dùng quy trình rút gọn sau.

0 đến 5 phút: Xem Google nhìn thấy gì

• Kiểm tra URL bằng Search Console.
• So sánh nội dung chính giữa mobile và desktop.
• Kiểm tra title, H1, canonical và trạng thái lập chỉ mục.

5 đến 10 phút: Xem khách có hiểu trang không

• Mở trang bằng điện thoại thật.
• Đọc màn hình đầu trong năm giây.
• Xác định thông điệp chính và CTA.
• Kiểm tra popup có che nội dung không.

10 đến 15 phút: Thử thao tác bằng một tay

• Mở và đóng menu.
• Bấm CTA, carousel và link trong footer.
• Kiểm tra chat, Zalo, cookie và sticky bar.
• Thử chế độ dọc và ngang.

15 đến 20 phút: Kiểm tra tốc độ

• Chạy PageSpeed Insights.
• Đọc dữ liệu người dùng thật nếu có.
• Xác định LCP, INP hoặc CLS đang không đạt.
• Ghi lại nguyên nhân lớn nhất được công cụ gợi ý.

20 đến 25 phút: Hoàn thành hành động chính

• Gọi điện, gửi form, đặt lịch hoặc mua hàng.
• Thử một dữ liệu không hợp lệ.
• Kiểm tra thông báo thành công.
• Kiểm tra lead hoặc giao dịch có được ghi nhận không.

25 đến 30 phút: Xếp thứ tự sửa

Với mỗi lỗi, ghi năm thông tin:

• URL và thiết bị gặp lỗi.
• Ảnh hoặc video ghi lại lỗi.
• Tác động đến SEO, trải nghiệm hoặc chuyển đổi.
• Mức ưu tiên P0, P1 hoặc P2.
• Người phụ trách và hạn hoàn thành.

12 vấn đề thiết kế mobile thường gặp và cách khắc phục

Phần lớn lỗi mobile không bắt đầu từ một breakpoint sai. Chúng xuất hiện khi đội ngũ mang nguyên bố cục desktop xuống màn hình nhỏ, trong khi người dùng đang đọc nhanh, thao tác bằng một tay và có thể dùng mạng không ổn định. Vì vậy, mỗi lỗi dưới đây được trình bày theo cùng một cách: nhận biết, kiểm tra, sửa và nghiệm thu. Designer, developer và marketing có thể dùng trực tiếp khi review một trang đang tạo traffic hoặc lead.

1. Hero vẫn mang tư duy desktop, thông điệp chính bị chìm

Hướng dẫn áp dụng: 1) Viết lại theo thứ tự: lời hứa cụ thể, đối tượng, bằng chứng. 2) Chỉ giữ một CTA chính trong màn hình đầu. 3) Bỏ ảnh và hiệu ứng không giúp hiểu đề nghị.

Đạt khi: Người mới trả lời được ba câu hỏi trong năm giây và thấy CTA mà không cần cuộn.

Dấu hiệu: Màn hình đầu chứa ảnh lớn, câu chữ chung chung, nhiều logo hoặc hiệu ứng nhưng chưa trả lời rõ doanh nghiệp giúp ai, giải quyết việc gì và người đọc nên làm gì tiếp theo. CTA chính nằm dưới nếp gấp hoặc bị cạnh tranh bởi nhiều nút ngang hàng.

Tác động: Khách từ quảng cáo hoặc Google phải cuộn và tự ghép thông tin trước khi hiểu đề nghị. Với website dịch vụ B2B, đây là điểm rơi lead phổ biến vì người có nhu cầu không biết trang có phù hợp với ngành và quy mô của họ hay không.

Cách kiểm tra thực tế: Mở trang trên điện thoại, che phần bên dưới màn hình đầu và nhờ một người chưa biết thương hiệu trả lời ba câu hỏi trong năm giây: Đây là dịch vụ gì? Dành cho ai? Bước tiếp theo là gì? Nếu họ phải đoán, hero chưa đạt.

Cách khắc phục: Sắp xếp hero theo thứ tự lời hứa cụ thể, đối tượng, một bằng chứng ngắn và một CTA chính. Ảnh chỉ giữ lại khi giúp người đọc hiểu sản phẩm hoặc kết quả. Đưa CTA lên trong màn hình đầu; CTA phụ như xem case study có thể dùng kiểu chữ hoặc viền để không tranh cấp bậc.

Tiêu chí nghiệm thu: Ở màn hình rộng 320 đến 430 CSS px, người đọc thấy trọn ý chính và CTA mà không phải phóng to. CTA chính chỉ có một cách gọi xuyên suốt trang và sự kiện nhấp được ghi nhận đúng.

Ví dụ thực tế: Một trang dịch vụ thiết kế website không nên mở bằng “Kiến tạo trải nghiệm số khác biệt”. Câu rõ hơn là “Thiết kế website B2B giúp đội sales nhận lead đủ thông tin”, sau đó mới đặt bằng chứng và nút “Nhận tư vấn cấu trúc website”.

2. Nội dung mobile bị cắt bớt hoặc sai thứ tự ưu tiên

Hướng dẫn áp dụng: 1) Đối chiếu H1, heading, nội dung, link và CTA với desktop. 2) Khôi phục phần quan trọng; dùng accordion thay vì xóa. 3) Sắp thứ tự trong HTML: vấn đề, giải pháp, bằng chứng, hành động.

Đạt khi: Không có thông tin ra quyết định nào chỉ tồn tại trên desktop; Google và người dùng nhận cùng nội dung chính.

Dấu hiệu: Desktop có mô tả dịch vụ, case study, FAQ hoặc liên kết quan trọng nhưng mobile lại ẩn bằng CSS. Một dấu hiệu khác là nội dung vẫn đủ nhưng thứ tự vô lý: ảnh xuất hiện trước tiêu đề, CTA đứng trước bằng chứng hoặc bảng giá tách xa phần giải thích.

Tác động: Người dùng thiếu thông tin để ra quyết định, còn Google có thể nhận một phiên bản mobile nghèo hơn. Mobile-First không đồng nghĩa với rút gọn bằng cách xóa; mục tiêu là tổ chức lại để nội dung quan trọng dễ tiếp cận hơn.

Cách kiểm tra thực tế: Đặt hai cửa sổ desktop và mobile cạnh nhau. Đối chiếu H1, heading, nội dung chính, liên kết nội bộ, dữ liệu có cấu trúc và CTA. Sau đó đọc riêng phiên bản mobile từ đầu đến cuối để xem chuỗi “vấn đề, giải pháp, bằng chứng, hành động” có liền mạch không.

Cách khắc phục: Giữ cùng nội dung quan trọng nhưng chia thành đoạn ngắn, danh sách, tab hoặc accordion có nhãn rõ. Dùng CSS order rất thận trọng vì thứ tự nhìn thấy có thể khác thứ tự trong mã nguồn và thứ tự đọc của công nghệ hỗ trợ. Nếu cần đổi cấu trúc, hãy đổi ngay trong HTML theo trình tự nội dung đúng.

Tiêu chí nghiệm thu: Không có thông tin ra quyết định nào chỉ tồn tại trên desktop. Mobile và desktop thống nhất về nội dung chính, metadata, structured data và internal link; accordion vẫn mở được bằng bàn phím và công nghệ hỗ trợ.

3. Menu quá tải, hành động chính bị giấu trong hamburger

Hướng dẫn áp dụng: 1) Gom liên kết theo nhu cầu của khách, không theo phòng ban. 2) Giữ ít nhóm cấp một; nhãn và nút đóng phải rõ. 3) Đặt hành động tạo doanh thu ngoài hamburger khi cần.

Đạt khi: Người dùng tìm dịch vụ và hoàn thành CTA trong tối đa ba lần chạm, không mất focus hoặc khóa cuộn.

Dấu hiệu: Menu mobile chứa hàng chục liên kết cùng cấp, nhãn mơ hồ hoặc nhiều lớp submenu. Người dùng phải mở menu mới thấy số điện thoại, đặt lịch, đăng nhập hoặc giỏ hàng. Khi quay lại trang, menu không giữ được trạng thái hoặc nút đóng nằm ngoài vùng chạm thuận tiện.

Tác động: Điều hướng trở thành một nhiệm vụ riêng thay vì giúp người dùng tiến nhanh tới mục tiêu. Lead có ý định cao dễ rời trang chỉ vì không tìm được dịch vụ, địa điểm hoặc CTA mà họ vừa thấy trên kết quả tìm kiếm.

Cách kiểm tra thực tế: Dùng một tay và thực hiện ba nhiệm vụ: tìm một dịch vụ, quay về trang chính và hoàn thành CTA. Ghi lại số lần chạm, số lần phải quay lại và vị trí người dùng do dự. Thử thêm khi cỡ chữ hệ thống được tăng.

Cách khắc phục: Gom liên kết theo nhu cầu của khách thay vì theo sơ đồ nội bộ của công ty. Chỉ giữ nhóm chính ở cấp một, cho phép mở từng nhóm rõ ràng và luôn có nút đóng. Với hành động tạo doanh thu như đặt lịch hoặc giỏ hàng, cân nhắc đặt bên ngoài hamburger hoặc trong thanh hành động cố định, miễn là không che nội dung.

Tiêu chí nghiệm thu: Tác vụ quan trọng hoàn thành trong tối đa ba lần chạm từ bất kỳ trang chính nào. Menu không tràn, không mất focus, không khóa cuộn sau khi đóng và hoạt động ổn định ở cả chế độ dọc lẫn ngang.

4. Nút, icon và liên kết quá nhỏ hoặc đặt quá sát nhau

Hướng dẫn áp dụng: 1) Kiểm tra bằng ngón cái trên điện thoại thật, không dùng chuột. 2) Giữ tối thiểu 24 CSS px; ưu tiên 44–48 px cho nút chính. 3) Tăng padding, khoảng cách, nhãn và trạng thái focus.

Đạt khi: Tác vụ hoàn thành bằng một tay, không bấm nhầm; icon quan trọng có tên và focus nhìn thấy được.

Dấu hiệu: Icon không có nhãn, link chữ nhỏ nằm sát nhau, checkbox khó bấm hoặc nút đóng popup chỉ có một dấu “x” rất nhỏ. Người dùng thường bấm nhầm, nhất là khi cầm máy bằng một tay.

Tác động: Sai một lần chạm có thể đóng form, đổi gói giá hoặc đưa khách sang trang khác. Đây không chỉ là lỗi thẩm mỹ mà là lỗi khả năng truy cập và chuyển đổi.

Cách kiểm tra thực tế: Thử thao tác bằng ngón cái trên điện thoại thật, không phóng to và không dùng DevTools để bấm bằng chuột. Kiểm tra cả trạng thái bình thường, focus, pressed và disabled. Đặc biệt chú ý nút đóng, bộ lọc, phân trang, checkbox và điều khiển carousel.

Cách khắc phục: Theo WCAG 2.2, mục tiêu chạm ở mức AA cần đạt ít nhất 24 x 24 CSS px hoặc đáp ứng ngoại lệ về khoảng cách. Trong triển khai thực tế, nên dành khoảng 44 đến 48 CSS px cho CTA, menu và điều khiển dùng thường xuyên. Có thể tăng vùng chạm bằng padding mà không làm icon lớn quá mức; giữ khoảng cách đủ để hai mục tiêu không gây bấm nhầm.

Tiêu chí nghiệm thu: Người kiểm thử hoàn thành tác vụ bằng một tay mà không bấm nhầm. Mọi icon quan trọng có tên truy cập được, trạng thái focus dễ nhận ra và không có liên kết chữ nhỏ chen giữa hai hành động khác nhau.

5. Sticky CTA, chat, cookie và thanh trình duyệt che nội dung

Hướng dẫn áp dụng: 1) Liệt kê mọi thành phần cố định ở đáy và xếp một ưu tiên. 2) Chỉ giữ một lớp hành động chính; chat không tự bung. 3) Thêm safe-area và đổi hành vi khi bàn phím mở.

Đạt khi: Trường đang focus, thông báo lỗi và CTA luôn nhìn thấy khi cuộn, mở bàn phím hoặc xoay ngang.

Dấu hiệu: Nút gọi điện, Zalo, chat, cookie banner và sticky CTA cùng xuất hiện ở đáy màn hình. Khi bàn phím mở hoặc thanh địa chỉ thay đổi chiều cao, nút submit, thông báo lỗi hoặc dòng cuối của nội dung bị che.

Tác động: Người dùng nhìn thấy CTA nhưng không thể hoàn thành hành động. Trường đang focus bị che còn tạo cảm giác form bị hỏng, dù logic phía sau vẫn hoạt động.

Cách kiểm tra thực tế: Thử cuộn tới cuối trang, mở chat, chấp nhận hoặc từ chối cookie, focus lần lượt từng ô form và xoay ngang màn hình. Kiểm tra trên Safari iPhone và Chrome Android vì viewport và bàn phím ảo xử lý khác nhau.

Cách khắc phục: Chỉ giữ một lớp hành động cố định có ưu tiên cao nhất. Thêm khoảng đệm đáy tương ứng với chiều cao sticky bar và safe area bằng env(safe-area-inset-bottom). Khi bàn phím mở, cho phép thanh hành động thu gọn hoặc ẩn nếu nó che trường nhập. Chat không nên tự bung; cookie banner cần gọn, đóng được và không đẩy nút quan trọng ra ngoài tầm nhìn.

Tiêu chí nghiệm thu: Mọi trường khi focus đều nhìn thấy đầy đủ; không CTA, thông báo lỗi hoặc nút đóng nào bị che ở các trạng thái cuộn, mở bàn phím và xoay màn hình. Thành phần cố định không làm tăng CLS đáng kể.

6. Form tạo quá nhiều ma sát hoặc bị bàn phím phủ

Hướng dẫn áp dụng: 1) Giữ lại dữ liệu cần cho bước xử lý tiếp theo. 2) Dùng type, inputmode, autocomplete và lỗi tại trường. 3) Gửi form thật; kiểm tra trang xác nhận, tracking và CRM.

Đạt khi: Khách hoàn thành trong một lượt; một lần gửi tạo đúng một sự kiện và một bản ghi lead.

Dấu hiệu: Form hỏi quá nhiều thông tin ngay lần liên hệ đầu, dùng cùng một bàn phím cho số điện thoại và email, nhãn biến mất sau khi nhập hoặc thông báo lỗi chỉ xuất hiện ở đầu trang. Sau khi bấm gửi, người dùng không biết hệ thống đang xử lý hay đã nhận lead.

Tác động: Khách bỏ dở dù đã có ý định cao. Một lỗi khác nguy hiểm hơn là giao diện báo thành công nhưng dữ liệu không đến CRM, email hoặc đội sales.

Cách kiểm tra thực tế: Dùng dữ liệu thật để gửi form trên iPhone và Android. Thử bỏ trống, nhập sai, dùng autofill, dán số điện thoại, mở trình quản lý mật khẩu và bấm gửi khi mạng chậm. Kiểm tra đồng thời giao diện, sự kiện analytics và bản ghi nhận lead ở hệ thống đích.

Cách khắc phục: Chỉ hỏi dữ liệu cần cho bước tiếp theo; câu hỏi sàng lọc có thể chuyển sang bước hai hoặc cuộc gọi. Dùng label luôn hiển thị, type, inputmode, autocomplete và enterkeyhint phù hợp để hiện đúng bàn phím. Báo lỗi ngay cạnh trường, giữ dữ liệu người dùng đã nhập, khóa gửi lặp khi đang xử lý và cung cấp trạng thái thành công kèm bước tiếp theo.

Tiêu chí nghiệm thu: Một khách phù hợp có thể hoàn thành form trong một lượt, không nhập lại và không bị che bởi bàn phím. Lead chỉ được ghi nhận một lần, đến đúng CRM hoặc hộp thư, có nguồn và thời điểm rõ ràng.

Ví dụ thực tế: Trang đặt lịch cho dịch vụ địa phương thường chỉ cần tên, số điện thoại, nhu cầu và khung giờ. Yêu cầu thêm công ty, chức vụ, ngân sách, địa chỉ chi tiết và lời nhắn dài ngay bước đầu thường làm tăng bỏ dở mà chưa chắc cải thiện chất lượng lead.

7. Bảng giá, bảng so sánh và bộ lọc bị ép nhỏ

Hướng dẫn áp dụng: 1) Chuyển ít lựa chọn thành card; nêu khác biệt chính trước. 2) Nếu phải cuộn ngang, thêm chỉ dấu và cố định cột nhận diện. 3) Mở bộ lọc toàn màn hình, có Áp dụng, Xóa lọc và số kết quả.

Đạt khi: Người dùng chọn đúng gói hoặc bộ lọc mà không ghi nhớ dữ liệu ở màn hình trước; CTA luôn gắn đúng lựa chọn.

Dấu hiệu: Bảng desktop được thu nhỏ để vừa màn hình, khiến chữ và nút chọn gói không thể đọc. Một số cột biến mất mà không báo trước; người dùng phải kéo ngang nhưng không biết còn nội dung phía bên phải.

Tác động: Khách không so sánh được lựa chọn, dễ hiểu sai giá hoặc bỏ qua gói phù hợp. Với SaaS và thương mại điện tử, đây là lỗi trực tiếp trên hành trình doanh thu.

Cách kiểm tra thực tế: Chọn một gói hoặc lọc một sản phẩm từ đầu đến cuối trên màn hình 320 CSS px. Kiểm tra xem tên gói, giá, đơn vị tính, khác biệt chính và CTA có còn nằm trong cùng một ngữ cảnh hay không.

Cách khắc phục: Với ít thuộc tính, chuyển mỗi gói thành card và đặt khác biệt quan trọng trước. Với dữ liệu nhiều cột, cho phép cuộn ngang có chỉ dấu rõ, cố định cột nhận diện và không thu chữ dưới mức dễ đọc. Bộ lọc nên mở thành panel toàn màn hình, hiển thị số kết quả dự kiến, có “Áp dụng” và “Xóa lọc” rõ ràng; trạng thái lọc phải được giữ khi quay lại danh sách.

Tiêu chí nghiệm thu: Người dùng so sánh được các lựa chọn mà không phải ghi nhớ thông tin ở màn hình trước. Không cột quan trọng nào biến mất âm thầm; CTA luôn gắn đúng gói và sự kiện chọn gói ghi nhận đúng giá trị.

Ví dụ thực tế: Với ba gói SaaS, đừng ép bảng mười hàng vào một màn hình. Có thể hiển thị mỗi gói thành card, nêu ba khác biệt chính, cho phép mở danh sách tính năng và đặt một bảng so sánh đầy đủ có cuộn ngang ở phần sau.

8. Ảnh và video tải nặng, cắt sai hoặc làm trang nhảy

Hướng dẫn áp dụng: 1) Tìm phần tử LCP và nguồn CLS bằng dữ liệu lab lẫn thực tế. 2) Dùng picture, srcset, sizes và khai báo tỷ lệ hoặc kích thước. 3) Không lazy-load ảnh LCP; video có poster nhẹ và không tự phát âm thanh.

Đạt khi: Ảnh đúng điểm cắt, không làm trang nhảy; LCP ≤ 2,5 giây, INP ≤ 200 ms và CLS ≤ 0,1 ở p75.

Dấu hiệu: Mobile tải cùng ảnh hero 2500 px như desktop, ảnh quan trọng bị crop mất sản phẩm hoặc chữ, video tự chạy, còn nội dung nhảy xuống khi ảnh và font xuất hiện. Điểm LCP hoặc CLS kém nhưng đội ngũ chỉ nén lại một file mà không sửa cách phân phối.

Tác động: Màn hình đầu xuất hiện chậm, người dùng bấm nhầm vì bố cục thay đổi và dữ liệu di động bị tiêu tốn không cần thiết. Một trang “đẹp” trên Wi-Fi văn phòng có thể rất chậm với Android tầm trung và 4G yếu.

Cách kiểm tra thực tế: Dùng PageSpeed Insights để tìm phần tử LCP và nguyên nhân CLS, sau đó xác nhận bằng điện thoại thật với chế độ tiết kiệm dữ liệu hoặc mạng chậm. Kiểm tra từng tỷ lệ ảnh ở 320, 375, 390 và 430 CSS px.

Cách khắc phục: Dùng picture, srcset và sizes để trình duyệt chọn đúng tài nguyên; tạo ảnh mobile có điểm cắt riêng khi cần. Khai báo width, height hoặc aspect-ratio để giữ chỗ trước khi ảnh tải. Không lazy-load ảnh LCP ở màn hình đầu; ưu tiên preload có chọn lọc. Video cần poster nhẹ, nút phát rõ và không tự chạy âm thanh.

Tiêu chí nghiệm thu: Ở phân vị 75 của người dùng mobile, mục tiêu tốt là LCP không quá 2,5 giây, INP không quá 200 mili giây và CLS không quá 0,1. Ảnh vẫn truyền đạt đúng nội dung, không mờ quá mức và không làm bố cục nhảy khi tải.

9. Popup xuất hiện quá sớm và chặn toàn bộ nội dung

Hướng dẫn áp dụng: 1) Mở trang từ Google trong cửa sổ riêng tư để tái hiện. 2) Ưu tiên banner nhỏ hoặc CTA đặt trong nội dung. 3) Chỉ mở popup sau tín hiệu ý định; nút đóng phải lớn và ghi nhớ lựa chọn.

Đạt khi: Nội dung chính đọc được ngay; popup đóng trong một lần chạm, không lặp lại và không làm mất vị trí cuộn.

Dấu hiệu: Popup nhận ưu đãi, đăng ký bản tin hoặc chat xuất hiện ngay khi người dùng vừa vào trang. Nút đóng khó thấy, popup lặp lại ở mọi trang hoặc chiếm gần hết màn hình trên điện thoại.

Tác động: Khách chưa kịp hiểu nội dung đã bị yêu cầu hành động. Popup toàn màn hình còn có thể làm giảm khả năng truy cập nội dung từ kết quả tìm kiếm nếu triển khai như intrusive interstitial.

Cách kiểm tra thực tế: Mở trang trong cửa sổ riêng tư như một người mới, đi từ Google vào và thử đóng popup bằng một tay. Sau đó chuyển trang, quay lại và kiểm tra xem lựa chọn đóng có được ghi nhớ hay không.

Cách khắc phục: Ưu tiên banner nhỏ hoặc CTA trong nội dung. Nếu cần popup, kích hoạt sau tín hiệu ý định như đã đọc một phần nội dung, bấm xem tài liệu hoặc chuẩn bị rời trang; không dựa chỉ vào vài giây cố định. Nút đóng phải rõ, vùng chạm đủ lớn và popup không che chức năng thiết yếu. Thông báo pháp lý vẫn cần xuất hiện đúng yêu cầu nhưng nên chiếm ít không gian cần thiết.

Tiêu chí nghiệm thu: Người dùng vào từ tìm kiếm có thể đọc ngay nội dung chính. Popup đóng được trong một lần chạm, không mở lại liên tục và không làm mất vị trí cuộn.

10. Chữ nhỏ, đoạn dài và nhịp đọc không phù hợp với màn hình

Hướng dẫn áp dụng: 1) Dùng 16 px làm mốc khởi đầu; line-height khoảng 1,5–1,7. 2) Chia đoạn ngắn, heading có nghĩa và căn trái phần nội dung dài. 3) Kiểm tra cỡ chữ hệ thống lớn và zoom trình duyệt 200%.

Đạt khi: Không mất chữ hoặc phát sinh cuộn ngang ở 200% zoom; người đọc hiểu mạch bài chỉ bằng cách quét heading.

Dấu hiệu: Cỡ chữ thân bài quá nhỏ, dòng quá dài, khoảng cách giữa các đoạn thấp hoặc heading xuống dòng khó hiểu. Nội dung dùng nhiều căn giữa, viết hoa và chữ đặt trực tiếp trên ảnh có độ tương phản thấp.

Tác động: Người đọc phải phóng to hoặc bỏ qua những đoạn giúp họ ra quyết định. Nội dung chuyên sâu trở nên “khó” không phải vì kiến thức, mà vì cách trình bày buộc mắt phải làm việc quá nhiều.

Cách kiểm tra thực tế: Đọc liên tục ba đoạn trên điện thoại ở độ sáng thấp, sau đó tăng cỡ chữ hệ thống và zoom trình duyệt lên 200%. Tìm các điểm chữ chồng, bị cắt, tạo cuộn ngang hoặc CTA mất nhãn.

Cách khắc phục: Có thể dùng 16 px làm mốc khởi đầu thực tế cho thân bài, sau đó điều chỉnh theo font và người dùng mục tiêu. Giữ line-height khoảng 1,5 đến 1,7, đoạn ngắn, tiêu đề mang ý nghĩa và danh sách khi có nhiều điều kiện. Chỉ đặt chữ trên ảnh khi có lớp nền đảm bảo tương phản; tránh căn giữa các đoạn dài.

Tiêu chí nghiệm thu: Nội dung vẫn đọc được ở 200% zoom mà không mất chữ hoặc phát sinh cuộn ngang ngoài các thành phần được thiết kế để cuộn. Người đọc có thể quét heading và hiểu mạch bài trước khi đọc chi tiết.

11. Carousel, hiệu ứng và thao tác kéo không có phương án thay thế

Hướng dẫn áp dụng: 1) Đưa thông điệp và CTA quan trọng nhất thành nội dung tĩnh. 2) Nếu còn carousel, thêm trước, sau, tạm dừng và chỉ báo slide. 3) Kiểm tra bằng bàn phím và khi bật chế độ giảm chuyển động.

Đạt khi: Mọi nội dung tiếp cận được mà không cần swipe; CTA không đổi vị trí và carousel không bẫy focus.

Dấu hiệu: Nội dung quan trọng nằm ở slide thứ hai hoặc thứ ba, carousel tự chạy quá nhanh, chỉ kéo mới chuyển được hoặc animation làm nút thay đổi vị trí. Người dùng không biết có thêm nội dung và không thể tạm dừng.

Tác động: Thông tin bị bỏ lỡ, thao tác bằng một tay khó hơn và người nhạy cảm với chuyển động có thể khó chịu. Carousel hero còn làm nhiều thông điệp cạnh tranh trong phần quan trọng nhất của trang.

Cách kiểm tra thực tế: Thử hoàn thành tác vụ mà không dùng thao tác kéo, sau đó bật chế độ giảm chuyển động của hệ điều hành. Kiểm tra focus bằng bàn phím và xem CTA có giữ vị trí trong khi slide thay đổi không.

Cách khắc phục: Đưa thông điệp quan trọng nhất thành nội dung tĩnh. Nếu carousel thực sự cần thiết, thêm nút trước, sau có nhãn, chỉ báo số slide và khả năng tạm dừng; không bắt người dùng dựa vào swipe. Tôn trọng prefers-reduced-motion và tránh animation làm thay đổi bố cục.

Tiêu chí nghiệm thu: Mọi nội dung và hành động có thể tiếp cận mà không cần kéo. Carousel không tự làm mất CTA, không bẫy focus và không cản người dùng khi bật giảm chuyển động.

12. Tracking, chat và tiện ích bên thứ ba làm chậm hoặc làm mất lead

Hướng dẫn áp dụng: 1) Lập danh sách script, mục đích, owner và trang cần tải. 2) Loại phần trùng; trì hoãn chat, heatmap và script không thiết yếu. 3) Gửi một lead có mã nhận diện và theo dõi tới analytics, email và CRM.

Đạt khi: CTA phản hồi nhanh; một hành động tạo một sự kiện, một lead, đúng nguồn; lỗi tích hợp có cảnh báo và đường dự phòng.

Dấu hiệu: Trang tải nhiều script quảng cáo, heatmap, chat, lịch hẹn và A/B testing ngay từ đầu. CTA phản hồi chậm, form gửi hai lần hoặc dữ liệu chuyển đổi khác nhau giữa GA4, nền tảng quảng cáo và CRM.

Tác động: Website vừa chậm vừa không đáng tin cậy về đo lường. Đội marketing có thể tối ưu theo sự kiện sai, trong khi lead thật bị rơi giữa form, webhook và CRM.

Cách kiểm tra thực tế: Lập danh sách toàn bộ script bên thứ ba, người sở hữu và mục đích. So sánh thời gian phản hồi trước và sau khi chặn từng nhóm script trong môi trường kiểm thử. Gửi một lead có mã nhận diện và theo dõi xuyên suốt từ lần bấm CTA đến bản ghi CRM.

Cách khắc phục: Loại script trùng hoặc không còn người dùng; trì hoãn tiện ích không thiết yếu đến sau tương tác hoặc consent phù hợp. Tải chat và heatmap theo trang cần thiết thay vì toàn site. Dùng một định nghĩa chuyển đổi thống nhất, ngăn gửi lặp và ghi log lỗi ở điểm kết nối form, webhook, email và CRM.

Tiêu chí nghiệm thu: CTA và form vẫn phản hồi nhanh khi các script được bật. Một hành động chỉ tạo một sự kiện và một bản ghi lead; nguồn, chiến dịch và trang đích được giữ xuyên suốt. Khi tích hợp lỗi, hệ thống có cảnh báo và phương án nhận lead dự phòng.

Playbook xử lý lỗi mobile trong một sprint

Một danh sách lỗi chỉ có giá trị khi đội ngũ biết sửa lỗi nào trước và biết thế nào là xong. Quy trình dưới đây phù hợp cho một sprint ngắn, áp dụng cho website dịch vụ, SaaS, thương mại điện tử hoặc website địa phương.

Bước 1: Ghi lỗi để người khác tái hiện được

Mỗi ticket cần có URL và mẫu trang; thiết bị, hệ điều hành, trình duyệt và loại mạng; các bước gây ra lỗi; kết quả thực tế và kết quả mong đợi; ảnh hoặc video; tác động đến SEO, tác vụ hay lead; mức P0, P1 hoặc P2; người phụ trách; tiêu chí nghiệm thu; sự kiện tracking cần kiểm tra. Không ghi “mobile bị xấu” vì developer không biết phải tái hiện và sửa phần nào.

Bước 2: Ưu tiên theo điểm nghẽn kinh doanh

P0 là lỗi khiến Google không đọc được nội dung, người dùng không thể hoàn thành tác vụ hoặc doanh nghiệp không nhận được giao dịch và lead. P1 là lỗi vẫn cho phép hoàn thành nhưng gây chậm, bấm nhầm hoặc bỏ dở. P2 là lỗi trình bày chưa nhất quán nhưng chưa chặn hành trình. Sửa P0 trước khi đẩy thêm traffic; không để lỗi conversion nghiêm trọng đứng sau một chỉnh sửa màu sắc.

Bước 3: Sửa nguyên nhân gốc trên component hoặc template

Nếu cùng một lỗi xuất hiện ở mười trang sản phẩm, đừng sửa thủ công mười lần. Xác định component, CMS template, design token hoặc script đang tạo lỗi và sửa tại nguồn. Designer cần bàn giao đầy đủ trạng thái bình thường, focus, lỗi, loading, thành công và trường hợp chữ dài; developer cần ghi rõ breakpoint và hành vi khi nội dung vượt dự kiến.

Bước 4: Nghiệm thu trên thiết bị thật và hành trình thật

Tối thiểu kiểm tra Safari trên iPhone, Chrome trên Android tầm trung, màn hình nhỏ, màn hình lớn, dọc, ngang, cỡ chữ lớn và mạng chậm. Không dừng ở việc “trông đúng”. Hãy bấm CTA, gửi form, đặt lịch, chọn gói hoặc thanh toán; sau đó xác nhận dữ liệu đã đến đúng hệ thống.

Bước 5: Đo lại sau khi phát hành

Chụp mốc trước khi sửa gồm tỷ lệ chuyển đổi mobile, tỷ lệ bắt đầu và hoàn tất form, lượt bấm CTA, Core Web Vitals, lỗi JavaScript và số lead đủ điều kiện. Sau khi phát hành, kiểm tra lỗi ngay trong 24 giờ đầu và theo dõi xu hướng đủ lâu theo lượng traffic. Nếu giao diện tốt hơn nhưng lead giảm, hãy kiểm tra tracking, chất lượng traffic và thay đổi nội dung trước khi kết luận.

Mẫu nghiệm thu nhanh trước khi đóng ticket

Đạt khi lỗi không còn tái hiện trên thiết bị mục tiêu; tác vụ chính hoàn thành từ đầu đến cuối; không phát sinh lỗi mới ở template liên quan; focus, zoom và bàn phím không che nội dung; sự kiện analytics chỉ ghi một lần; lead hoặc giao dịch đến đúng hệ thống; ảnh hoặc video sau sửa được đính kèm vào ticket. Chỉ khi đủ các điều kiện này, lỗi mới được xem là hoàn tất.

Sau khi sửa, làm sao biết website thực sự tốt hơn?

Hãy ghi nhận số liệu trước khi thay đổi để có mốc so sánh. Tùy lượng traffic, nên theo dõi ít nhất hai đến bốn tuần sau khi triển khai.

Các chỉ số nên theo dõi gồm:

• Tỷ lệ chuyển đổi trên mobile.
• Số người bắt đầu và hoàn tất form.
• Lượt bấm gọi điện, Zalo hoặc đặt lịch.
• Tỷ lệ thoát tại trang đích.
• Core Web Vitals từ dữ liệu thực tế.
• Số lead đủ điều kiện đến từ mobile.
• Chênh lệch chuyển đổi giữa mobile và desktop.
• Lỗi JavaScript hoặc form phát sinh sau khi cập nhật.

Không nên đánh giá thành công chỉ bằng traffic. Mục tiêu cuối cùng là giúp đúng người tìm thấy nội dung, hiểu đề nghị và hoàn thành hành động phù hợp với ít trở ngại hơn.

‍