Hãy hình dung một cửa hàng mà mọi dashboard đều trông ổn. Trang chủ đã được index, Lighthouse xanh, và công cụ kiểm tra dữ liệu có cấu trúc không báo lỗi. Nhưng đúng vào lúc đó, giá trên Google Shopping không khớp với giá trong giỏ hàng, ngăn kéo bộ lọc trên mobile giam giữ người dùng bàn phím, và mọi lượt mua đều được ghi nhận hai lần.
Không điều nào trong số đó xuất hiện trong một lượt kiểm tra sức khỏe nhanh. Đó là vì một cửa hàng online là một hệ thống liên kết, chứ không chỉ là một tập hợp các trang đơn lẻ. Dữ liệu sản phẩm chảy vào trang, vào dữ liệu có cấu trúc và vào các feed mua sắm. Các script và thẻ của bên thứ ba quyết định tốc độ tải của tất cả. Checkout biến sự quan tâm thành doanh thu, và phân tích dữ liệu được kỳ vọng sẽ ghi lại toàn bộ hành trình một cách chính xác. Khi một phần bị hỏng, nó có thể âm thầm làm sai lệch mọi thứ khác.
Đó là lý do một bản audit thương mại điện tử hữu ích đi theo người mua, chứ không đi theo sitemap. Checklist dưới đây bắt đầu từ việc khám phá cửa hàng và kết thúc bằng một đơn hàng đã hoàn tất. Nó sẽ cho bạn một danh sách các vấn đề thực sự đã được xếp hạng, mỗi vấn đề kèm bằng chứng, người chịu trách nhiệm và một phép kiểm tra rõ ràng để biết khi nào đã được khắc phục.
Khi nào nên chạy bản audit này, và vì sao thứ tự lại quan trọng
Hãy chạy audit đầy đủ khi bạn nhận một khách hàng thương mại điện tử mới, sau khi thiết kế lại hoặc chuyển nền tảng, trước một đợt tăng trưởng lớn, hoặc khi một lượt kiểm tra định kỳ phát hiện sự thoái hóa trên toàn cửa hàng. Hãy dành ba đến sáu giờ cho một lượt kiểm tra nhẹ, hoặc một đến hai ngày cho một bản audit tiêu chuẩn kiểm thử đúng cách mọi template quan trọng. Những cuộc điều tra chuyên sâu về log, feed hay dữ liệu phân tích thường cần thời gian riêng.
Thứ tự là có chủ đích. Không có ích gì khi đánh giá ma sát trong chuyển đổi nếu Google không thể index các trang danh mục, và cũng không có ích gì khi tin vào báo cáo phễu nếu thẻ tracking hành vi mua kích hoạt hai lần.
Một sự kiện mua bị trùng lặp không phải bằng chứng của việc bán được nhiều hơn, và một trang sản phẩm nhanh chưa chắc đã khỏe mạnh nếu giá mà Google nhìn thấy khác với giá trong giỏ hàng. Đó là lý do bản audit được chia thành các giai đoạn. Nó bắt đầu bằng việc khám phá ban đầu, rồi chuyển sang tính xác thực của dữ liệu sản phẩm, tốc độ và chính hành vi mua, và chỉ sau đó mới chuyển sang đo lường.
Trước khi bắt đầu, hãy thu thập những gì bạn cần. Cụ thể là quyền truy cập vào:
- Search Console,
- Analytics,
- Tag manager,
- Nguồn dữ liệu danh mục hoặc feed,
- Merchant Center,
- danh sách các thay đổi gần đây trên site.
Giai đoạn 1: Công cụ tìm kiếm có tìm thấy danh mục sản phẩm không?
1. Xây dựng một mẫu đại diện cho toàn bộ cửa hàng
Hầu hết các lỗi thương mại điện tử nằm trong các template dùng chung và những trạng thái sản phẩm bất thường. Một trang chủ sạch sẽ không nói cho bạn biết gì về các danh mục đã lọc, logic biến thể, tình trạng hết hàng hay checkout. Đó là lý do bạn nên bắt đầu bằng việc xác nhận rằng mình đang kiểm thử site production đang chạy thật, đúng thị trường, đúng tiền tệ và đúng ngôn ngữ. Sau đó chọn ít nhất một URL cho mỗi mục sau:
- trang chủ
- một danh mục ưu tiên
- một danh mục sâu hơn hoặc một trang bộ lọc đã được duyệt
- một sản phẩm điển hình
- một sản phẩm có biến thể
- một sản phẩm hết hàng hoặc đã ngừng kinh doanh
- một trang kết quả tìm kiếm nội bộ, bao gồm cả một trang không trả về kết quả nào
- giỏ hàng, trang checkout và trang xác nhận đơn hàng
Hãy thêm một ví dụ khó hoặc bất thường cho bất kỳ template nào có vẻ rủi ro. Báo cáo trang đích (landing page) trong công cụ phân tích và một bản export danh mục sản phẩm sẽ giúp bạn chọn.
Bạn hoàn thành bước này khi mọi template quan trọng và mọi trạng thái checkout đều có một URL kiểm thử được đặt tên, và bất kỳ thứ gì bạn không thể kiểm thử đều được đánh dấu là “chưa kiểm thử”.
2. Kiểm tra khả năng crawl, tình trạng index, canonical và sitemap
Nếu đường crawl bị hỏng, việc xuất bản thêm sản phẩm chỉ nhân lên số URL bị ảnh hưởng. Các tín hiệu trái ngược nhau cũng khiến vấn đề khó chẩn đoán hơn. Quy tắc robots.txt có thể nói một đằng, trong khi thẻ canonical và sitemap lại nói một nẻo hoàn toàn khác.
Hãy xem lại robots.txt, các sitemap XML, mã phản hồi, thẻ meta robots và header, thẻ canonical, phân trang và liên kết nội bộ. Dùng tính năng URL Inspection trong Search Console để xem Google thực sự đã chọn canonical nào cho các trang mẫu của bạn. Sau đó so sánh sitemap với thực tế. Nó phải liệt kê các trang đang hoạt động, có thể index và trả về mã 200, chứ không phải các chuyển hướng, lỗi, trang bị noindex hay bản trùng lặp.
Bạn hoàn thành bước này khi các trang đích mong muốn trả về mã 200, có thể được crawl, tuân theo một chính sách canonical và index nhất quán, và xuất hiện trong sitemap. Mọi trường hợp bị loại trừ đáng kể đều phải có lời giải thích hoặc một người chịu trách nhiệm.
3. Đi theo các liên kết: chuyển hướng, lỗi và JavaScript
Một cửa hàng có thể trông đầy đủ trong trình duyệt trong khi các trình thu thập dữ liệu (crawler) và công nghệ hỗ trợ lại nhìn thấy một phiên bản mỏng hơn nhiều. Hãy chạy một công cụ crawl để tìm các liên kết nội bộ bị hỏng, chuỗi chuyển hướng, vòng lặp chuyển hướng và lỗi 404 mềm. Sau đó so sánh trang đã render với HTML gốc. Thẻ sản phẩm, phân trang, breadcrumb và liên kết danh mục phải là thật và có thể crawl, và nội dung quan trọng không nên phụ thuộc hoàn toàn vào JavaScript.
Bạn hoàn thành bước này khi các liên kết nội bộ trỏ thẳng đến đích cuối cùng, các trang lỗi trả về đúng mã trạng thái, và các sản phẩm ưu tiên có thể được tìm thấy mà không phụ thuộc vào infinite scroll.
4. Kiểm thử danh mục, bộ lọc, phân trang và tìm kiếm trên site
Hệ thống danh mục và bộ lọc có thể vừa tạo ra bẫy crawl cho công cụ tìm kiếm, vừa gây bực bội cho người mua. Một trang có thể có thể index về mặt kỹ thuật mà vẫn là một trang đích yếu nếu một nửa số sản phẩm trên đó không liên quan.
Hãy thử các bộ lọc trên desktop và mobile. Kiểm tra chọn nhiều mục, “xóa tất cả”, số lượng kết quả, sắp xếp, phân trang hoặc “tải thêm”, và các tổ hợp bộ lọc không trả về kết quả nào. Xem các URL mà bộ lọc tạo ra và so sánh chúng với chính sách index của cửa hàng. Cũng để ý xem liệu một khối văn bản danh mục dài có đẩy lưới sản phẩm xuống dưới màn hình đầu tiên hay không.
Bạn hoàn thành bước này khi các điều khiển hoạt động nhất quán, các tổ hợp bộ lọc ngẫu nhiên không vô tình trở thành trang đích, và người mua có thể bỏ một bộ lọc mà không mất vị trí đang xem.
Sẵn sàng phát triển doanh nghiệp của bạn?
Bắt đầu dùng thử miễn phí ngay hôm nay và xem kết quả trong vài ngày.
Giai đoạn 2: Dữ liệu sản phẩm có nói đúng sự thật không?
5. Đối chiếu danh tính sản phẩm, giá, tồn kho và biến thể
Một trường dữ liệu sai không chỉ có thể gây nhầm lẫn cho người mua mà còn có thể dẫn tới sai lệch ngay ở bước checkout. Trong khi đó, dữ liệu có thể được định dạng hoàn hảo mà vẫn sai.
Với một vài sản phẩm đại diện, hãy so sánh tên, thương hiệu, SKU, GTIN hoặc EAN, biến thể đã chọn, giá, tiền tệ, tình trạng còn hàng, hình ảnh và các thông số kỹ thuật chính ở mọi nơi chúng xuất hiện. Kiểm tra những gì được hiển thị trên trang, trong dữ liệu có cấu trúc, trong feed của merchant, trong giỏ hàng và tại checkout. Bao gồm cả các mặt hàng khuyến mãi, biến thể, hàng hết hàng, hàng đặt trước và sản phẩm đã ngừng kinh doanh.
Bạn hoàn thành bước này khi các dữ kiện của mẫu khớp nhau trên mọi bề mặt, và mọi khác biệt có chủ đích, ví dụ thương hiệu so với nhà sản xuất, đều được thể hiện rõ ràng trong mô hình dữ liệu.
6. Kiểm tra dữ liệu có cấu trúc so với những gì người mua nhìn thấy
Dữ liệu có cấu trúc chỉ hữu ích khi nó mô tả trang một cách chính xác. Một công cụ kiểm tra sẽ vui vẻ chấp nhận “InStock” trong khi trang và checkout đều nói sản phẩm không còn hàng. Đó là lý do bạn nên chạy từng trạng thái sản phẩm qua Google Rich Results Test hoặc Schema.org Validator. Sau đó so sánh các giá trị được đánh dấu với nội dung hiển thị và với feed nguồn. Với các sản phẩm có biến thể, hãy kiểm tra xem cách đánh dấu và thiết lập canonical của bạn có khớp với cách các trang thực sự được xây dựng hay không.
Bạn hoàn thành bước này khi các trang mẫu đủ điều kiện không thiếu thuộc tính bắt buộc nào, phần đánh dấu khớp với những gì hiển thị, và đánh giá cùng xếp hạng chỉ được đánh dấu khi người mua có thể nhìn thấy chúng trên sản phẩm đó.
Giai đoạn 3: Cửa hàng có thực sự nhanh với người mua thật không?
7. Đo Core Web Vitals từ dữ liệu thực tế trước
Dữ liệu người dùng thật và một lần chạy Lighthouse trả lời những câu hỏi khác nhau. Lighthouse giúp bạn tái hiện một vấn đề, nhưng nó không thể cho bạn biết liệu người mua thật đang đạt hay không đạt.
Hãy bắt đầu với PageSpeed Insights và báo cáo Core Web Vitals trong Search Console. Ghi chú xem dữ liệu thực tế có tồn tại cho đúng URL đó hay chỉ cho toàn site. Các ngưỡng “tốt” của Google, được đo ở phân vị thứ 75, là:
- LCP (tải): từ 2,5 giây trở xuống
- INP (khả năng phản hồi): từ 200 mili giây trở xuống
- CLS (độ ổn định hình ảnh): từ 0,1 trở xuống
Hãy xem mobile và desktop riêng biệt. Nếu không có dữ liệu thực tế, hãy ghi kết quả là chưa xác định và coi kết quả trong lab là tạm thời. Chưa xác định không giống với màu xanh.
Bạn hoàn thành bước này khi mỗi template ưu tiên có một kết luận dựa trên dữ liệu thực tế cho từng thiết bị, hoặc có ghi rõ ràng việc thiếu dữ liệu, kèm nguồn và khoảng thời gian được ghi lại.
8. Tìm nguyên nhân, không chỉ tìm điểm số
Những lời khuyên chung chung như “nén ảnh của bạn” hay “giảm JavaScript” thường bỏ sót nút thắt thực sự và tạo ra công việc không cải thiện được chỉ số đang không đạt. Hãy tìm ra phần tử, request hay script cụ thể chịu trách nhiệm.
Hãy xác định phần tử LCP và điều gì đang làm nó chậm trễ. Sau đó kiểm tra những nghi phạm quen thuộc, như kích thước ảnh, lazy-loading trên ảnh ở phần đầu trang, CSS chặn render, tải font, script bên thứ ba, tác vụ dài (long task), caching, thời gian phản hồi của server, các nguồn gây dịch chuyển bố cục và các thẻ được tải hai lần.
Hãy chạy kiểm thử lặp lại trong cùng điều kiện và so sánh một chỉ số nhất quán, chứ không phải lần chạy tốt nhất của bạn. Hãy nhớ rằng Total Blocking Time là một tín hiệu hữu ích trong lab, nhưng nó không phải là INP.
Bạn hoàn thành bước này khi mọi phát hiện về hiệu năng đáng kể đều nêu rõ chỉ số không đạt, template bị ảnh hưởng, nguyên nhân có thể tái hiện và người chịu trách nhiệm.
Tham gia bản tin của chúng tôi
Nhận các mẹo, xu hướng và ưu đãi mới nhất miễn phí.
Giai đoạn 4: Người ta có thực sự mua được hàng không?
9. Kiểm thử khả năng dùng trên mobile và khả năng tiếp cận trên các điều khiển mua hàng thật
Điểm số tự động không bao phủ mọi tương tác. Một cửa hàng có thể vượt qua một lượt quét tự động trong khi ngăn kéo bộ lọc giam giữ tiêu điểm bàn phím, banner cookie che nút thêm vào giỏ hàng, hoặc bộ chọn kích cỡ không có nhãn dễ tiếp cận.
Hãy kiểm thử ở chiều rộng điện thoại từ 360 đến 390 pixel, phóng to văn bản, và thử toàn bộ hành trình chỉ bằng bàn phím. Quan sát thứ tự tiêu điểm và khả năng hiển thị trong menu, ngăn kéo và hộp thoại. Kiểm tra rằng nhãn, nút, lỗi biểu mẫu và vùng chạm vẫn hợp lý.
Bạn hoàn thành bước này khi người mua có thể đi qua hành trình chính mà không gặp điều khiển bị ẩn hay bẫy tiêu điểm, và không có gì trên mobile che khuất giá, tình trạng còn hàng, lựa chọn biến thể, nút thêm vào giỏ hàng hay checkout.
10. Chạy giỏ hàng và checkout như một bài kiểm thử có kiểm soát
Một nút checkout hiển thị được không chứng minh rằng checkout hoạt động. Lỗi checkout là sự cố thương mại, và chúng cũng làm hỏng dữ liệu phân tích của bạn.
Để kiểm thử điều này, hãy thêm một sản phẩm thường và một biến thể vào giỏ hàng. Thay đổi số lượng, xóa một mặt hàng, và áp dụng một mã giảm giá (hoặc một mã cố tình không hợp lệ) nếu bạn có. Sau đó kiểm thử checkout dạng khách và dạng tài khoản, các phương án vận chuyển, chọn phương thức thanh toán, lỗi xác thực, nút quay lại và bố cục trên mobile. Hãy dùng một đơn hàng thử hoặc một đường đi đã được duyệt không tính phí. Không bao giờ đặt đơn hàng thật khi chưa được phép.
Bạn hoàn thành bước này khi việc mua hoàn tất hoặc đi đến ranh giới kiểm thử đã thống nhất, các tổng tiền vẫn chính xác, thông báo lỗi cho người dùng biết cần làm gì, và mọi đường đi bị chặn đều được ghi lại kèm bằng chứng và tác động kinh doanh.
Giai đoạn 5: Bạn có đang đo lường hành trình một cách chính xác không?
11. Xác minh phân tích dữ liệu, thẻ trùng lặp và sự đồng thuận
Thẻ trùng lặp làm phồng số lượt xem trang, sự kiện thêm vào giỏ hàng và lượt mua. Các giá trị bị thiếu hoặc sai định dạng khiến báo cáo doanh thu không an toàn để ra quyết định. Mục tiêu rất đơn giản: một hành động của người mua phải tạo ra một sự kiện, với đúng sản phẩm, giá trị, tiền tệ, mã giao dịch và trạng thái đồng thuận.
Hãy liệt kê mọi container tag manager, thẻ Google, pixel quảng cáo, script affiliate và tích hợp phía server. Sau đó, trong một phiên có kiểm soát, hãy lần theo view_item, add_to_cart, begin_checkout và purchase. So sánh những gì trình duyệt gửi đi với GA4 DebugView và bản ghi đơn hàng ở backend. Hãy kiểm thử trước và sau khi người mua đưa ra lựa chọn đồng thuận.
Bạn hoàn thành bước này khi mỗi hành động kích hoạt sự kiện của nó đúng một lần, các lượt mua mang một mã giao dịch ổn định, giá trị và tiền tệ khớp với backend, và các thẻ không thiết yếu tuân thủ chính sách đồng thuận.
12. Đối chiếu Search Console và Merchant Center với những gì bạn đã tìm thấy
Một bài kiểm thử trang cục bộ không thể cho bạn thấy mọi canonical đã index, cảnh báo sitemap, sản phẩm bị từ chối hay truy vấn tìm kiếm bị mất. Ngược lại, một cảnh báo trên dashboard có thể mô tả một vấn đề đã được khắc phục từ trước.
Hãy kiểm tra các URL ưu tiên của bạn trong Search Console, xem lại báo cáo sản phẩm và merchant listing, và đối chiếu chẩn đoán trong Merchant Center với những gì bạn thấy trên site đang chạy thật. Ghi lại ngày tháng, vì việc recrawl và xử lý feed luôn chậm hơn so với các lần triển khai.
Bạn hoàn thành bước này khi mọi vấn đề đáng kể trên dashboard đều khớp với bằng chứng thực tế hoặc được đánh dấu là đang chờ lan truyền, và mỗi vấn đề còn mở đều có người chịu trách nhiệm.
Giai đoạn 6: Người mua có tin tưởng cửa hàng này không?
13. Kiểm tra các tín hiệu tin cậy, thông tin liên hệ, vận chuyển và đổi trả
Thông tin thương mại bị ẩn hoặc mâu thuẫn khiến người mua do dự và làm tăng số yêu cầu hỗ trợ. Hãy so sánh phần header và footer, trang liên hệ, trang checkout và các trang chính sách.
Bạn hoàn thành bước này khi danh tính doanh nghiệp rõ ràng, các tuyên bố về vận chuyển, đổi trả và thanh toán thống nhất trong suốt hành trình, và không có huy hiệu tin cậy nào không thể xác minh.
14. Kiểm tra HTTPS, nội dung hỗn hợp và tính chỉn chu của front-end
Đây không phải là một bài kiểm thử xâm nhập, mà là vấn đề vệ sinh dữ liệu cơ bản. Hãy xác nhận rằng HTTP chuyển hướng sang HTTPS chỉ trong một bước nhảy, chứng chỉ hợp lệ, không có nội dung hỗn hợp và các biểu mẫu gửi đi chính xác. Kiểm tra console để tìm các lỗi nghiêm trọng. Nếu có thứ gì đó giống như một lỗ hổng bảo mật thật sự, hãy chuyển nó cho chuyên gia thay vì tự chẩn đoán dựa trên một cảnh báo chung chung.
Bạn hoàn thành bước này khi các trang ưu tiên và checkout tải một cách an toàn, chuyển hướng chỉ mất một bước nhảy và các biểu mẫu hoạt động đúng như mong đợi.
Từ phát hiện đến khắc phục
15. Biến các phát hiện thành một hàng đợi khắc phục có người chịu trách nhiệm
Một bản audit kết thúc bằng ảnh chụp màn hình hay một điểm số không làm giảm rủi ro. Năm mươi triệu chứng do một template hỏng gây ra không nên trở thành năm mươi ticket không liên quan. Hãy nhóm các phát hiện theo nguyên nhân gốc. Ghi chú xem đó là component, template, quy tắc feed hay thiết lập tracking. Giữ các URL bị ảnh hưởng làm bằng chứng. Sau đó xếp mức ưu tiên:
- P0: một lỗi đang hoạt động gây chặn kinh doanh, hoặc một vấn đề nghiêm trọng trên toàn site
- P1: một khiếm khuyết đáng kể mà bạn chắc chắn
- P2: một vấn đề quan trọng nhưng phạm vi ảnh hưởng hạn chế
- P3: một cải tiến cần theo dõi
Bạn hoàn thành bước này khi mọi phát hiện đáng kể đều có một người chịu trách nhiệm, một hạn hoàn thành, một bài kiểm thử cho trạng thái “đã khắc phục” và một ngày để kiểm tra lại sau khi phát hành.
Sản phẩm bàn giao
Hãy bàn giao một tài liệu hoặc bảng tính có quản lý phiên bản, mỗi phát hiện một dòng và một phần tóm tắt ngắn ở đầu. Mỗi dòng nên bao gồm:
- Hành vi,
- hành vi mong đợi,
- các URL bị ảnh hưởng,
- bằng chứng và thời điểm bạn thu thập nó,
- mức độ nghiêm trọng và độ tin cậy,
- nguyên nhân có khả năng nhất,
- cách khắc phục được đề xuất,
- người chịu trách nhiệm và bài kiểm thử chứng minh đã xong.
Nhưng hãy nhớ rằng bạn không nên đánh dấu một vấn đề là đã khắc phục chỉ vì ai đó đã đóng ticket. Hãy đánh dấu là đã xác minh khi bài kiểm thử đạt trên môi trường production.
Công cụ cho công việc này
Bạn không cần bất kỳ gói đăng ký trả phí nào để thực hiện thành công một lượt kiểm tra đầu tiên vững chắc. Tất cả những gì bạn cần là các công cụ miễn phí sau:
- Google PageSpeed Insights để lấy dữ liệu thực tế (khi có) và chẩn đoán từ Lighthouse
- Google Search Console cho tình trạng index, sitemap, URL Inspection, Core Web Vitals và báo cáo dữ liệu có cấu trúc
- Google Rich Results Test và Schema.org Validator cho dữ liệu có cấu trúc
- Chrome DevTools và Lighthouse để kiểm tra network, hiệu năng, dịch chuyển bố cục, khả năng tiếp cận và console
- Google Tag Assistant và GA4 DebugView để kiểm tra tracking sự kiện
- SSL Labs Server Test để kiểm tra cấu hình TLS
Nếu bạn muốn một lối tắt, AmICited sẽ cho phép bạn tập hợp tất cả bằng chứng đó lại và giữ đường cơ sở (baseline) cho những lần sau. Chế độ xem Performance Impact so sánh các template theo LCP, INP, CLS và thời gian phản hồi của server. URL Inspection và Sitemaps and Indexing theo dõi tình trạng index cho các URL ưu tiên. Products và Assortment cho thấy phần nào của danh mục sản phẩm mang trọng lượng thương mại lớn nhất. Annotations in the Reports Hub gắn mỗi lần phát hành với những gì đã xảy ra sau đó. Các công cụ cung cấp bằng chứng. Chủ cửa hàng, lập trình viên hay chuyên viên phân tích vẫn là người quyết định điều gì đúng và những đánh đổi nào là chấp nhận được.
Sau khi audit
Hãy gửi mỗi vấn đề đã được xác nhận đến quy trình chuyên môn có thể giải quyết nó: các vấn đề về crawl và render đến một bản audit SEO kỹ thuật , các lỗi hiệu năng thực tế đến khắc phục Core Web Vitals , các vấn đề về facet và trạng thái tồn kho đến một đánh giá danh mục và sản phẩm , và các vấn đề tracking đến người phụ trách phân tích dữ liệu.
Bạn không cần chạy lại toàn bộ bản audit sau mỗi lần khắc phục. Hãy kiểm thử lại khu vực bị ảnh hưởng, ghi chú lần phát hành để bạn thấy được những gì đã thay đổi sau đó, và để lượt kiểm tra sức khỏe định kỳ bắt được sự thoái hóa tiếp theo.
Quay lại cửa hàng nơi mọi thứ đều trông ổn
Bạn còn nhớ cửa hàng ở đầu bài chứ? Trang chủ của nó đã được index, Lighthouse xanh và công cụ kiểm tra dữ liệu có cấu trúc sạch sẽ. Vậy mà Google Shopping hiển thị sai giá, ngăn kéo bộ lọc giam giữ người dùng bàn phím và mỗi lượt bán đều được đếm hai lần.
Không dashboard nào báo hiệu điều gì trong số đó. Checklist này sẽ bắt được cả ba: sai lệch giá ở bước 5, bẫy tiêu điểm ở bước 9 và lượt mua bị đếm hai lần ở bước 11. Mỗi vấn đề đều đổ vỡ ở một điểm nào đó trên đường đi của người mua, và đó chính xác là nơi bản audit tìm đến.
Đó là những gì bạn nhận được khi đi theo người mua thay vì đi theo sitemap. Bạn ngừng hỏi “site này có vẻ khỏe mạnh không?” và bắt đầu hỏi bốn câu hỏi khó hơn. Người ta có tìm được sản phẩm không? Những gì cửa hàng nói về sản phẩm có đúng không? Họ có thực sự mua được nó không? Và bạn có thấy được là họ đã mua không? Một cửa hàng trả lời “có” cho cả bốn câu hỏi đang ở tình trạng tốt hơn một cửa hàng có điểm số hoàn hảo.
Vậy hãy chọn các URL mẫu của bạn, dành ra thời gian và bắt đầu với Giai đoạn 1. Lượt kiểm tra đầu tiên là chậm nhất. Sau đó, công việc chủ yếu là đảm bảo rằng những gì bạn đã khắc phục vẫn giữ nguyên trạng thái đã khắc phục.
