Hầu hết các dự án tối ưu hóa tìm kiếm trên trang web đều bắt đầu sai chỗ: bản demo của nhà cung cấp. Bản demo luôn hoạt động tốt vì nó được chạy trên chỉ mục của nhà cung cấp với các truy vấn của nhà cung cấp. Trong khi đó, báo cáo đánh giá chuẩn mực tìm kiếm năm 2026 của Viện Baymard cho thấy rằng... 56% các trang thương mại điện tử có trải nghiệm người dùng tìm kiếm ở mức trung bình hoặc tệ hơn.và rằng các lỗi tập trung ở các loại truy vấn cụ thể, có thể đặt tên được, chứ không phải ở "mức độ liên quan" nói chung (Baymard, cập nhật tháng 4 năm 2026Động cơ mới khắc phục được một số vấn đề đó nhưng không giải quyết được những vấn đề còn lại.
Đây là bảng chấm điểm cho công cụ tìm kiếm bạn đang sử dụng. Có 20 mục, mỗi mục 2 điểm, tổng cộng 40 điểm. Bạn chạy bảng chấm điểm này trên danh mục sản phẩm của mình trong một buổi chiều, nhận được một con số, và con số đó cho biết vấn đề của bạn nằm ở cấu hình, nội dung hay chính công cụ tìm kiếm. Bảng chấm điểm này được viết dành cho các chuyên gia UX thương mại điện tử, các nhà quản lý tăng trưởng và chủ sở hữu sản phẩm, những người được yêu cầu phải chứng minh tính hiệu quả của ngân sách tìm kiếm.
Tiêu chí này đo lường điều gì và cố tình bỏ qua điều gì?
Tiêu chí đánh giá này chấm điểm bốn yếu tố: liệu công cụ tìm kiếm có hiểu được các loại truy vấn mà người dùng thực sự nhập vào hay không, liệu nó có hoạt động tốt với dữ liệu đầu vào lộn xộn hay không, liệu nó có phục hồi khi không tìm thấy gì hay không, và liệu bạn có thể đo lường được bất kỳ yếu tố nào trong số đó hay không. Nó không chấm điểm chất lượng xếp hạng kết quả một cách trừu tượng. Xếp hạng là yếu tố cuối cùng cần tinh chỉnh và là điều đầu tiên mọi người tranh luận, và bạn không thể tinh chỉnh nó trong khi các truy vấn vẫn chưa thành công ở bộ phân tách từ.
Điểm số được tính là 0, 1 hoặc 2 cho mỗi lần kiểm tra. Hai nghĩa là nó vượt qua mọi truy vấn trong danh sách kiểm tra của bạn. Một nghĩa là nó vượt qua các từ khóa chính nhưng không vượt qua các từ khóa phụ. Không nghĩa là nó không vượt qua các từ khóa chính. Trước tiên, hãy xây dựng danh sách kiểm tra: lấy 50 truy vấn hàng đầu từ phân tích, sau đó thêm năm truy vấn bạn tự xây dựng cho mỗi trong tám loại truy vấn Baymard để đại diện cho các từ khóa phụ. Khoảng 90 truy vấn. Hãy tự chạy chúng trên thiết bị di động, khi chưa đăng nhập.
20 lần kiểm tra
| # | kiểm tra | Ghi 2 điểm khi |
|---|---|---|
| Nhóm A — Phạm vi truy vấn (các cụm lỗi của Baymard) | ||
| 1 | Truy vấn chính xác và số hiệu sản phẩm | Sản phẩm được nêu tên là kết quả đầu tiên, chứ không phải kết quả thứ tư. |
| 2 | Truy vấn loại sản phẩm | Trả về một danh sách có thể duyệt được và được phân loại theo nhiều tiêu chí, thay vì chỉ là một bảng liệt kê thông tin về mức độ liên quan. |
| 3 | Truy vấn tính năng ("áo khoác len đỏ") | Các thuộc tính thu hẹp tập hợp thay vì làm loãng nó bằng cách sử dụng phép so khớp OR. |
| 4 | Truy vấn khả năng tương thích ("bộ sạc cho model X") | Trả về các phụ kiện dành cho mẫu được chỉ định, chứ không phải chính mẫu đó. |
| 5 | Các thắc mắc không liên quan đến sản phẩm ("chính sách hoàn trả") | Trả về trang nội dung; 66% các trang web gặp lỗi này. |
| Nhóm B — Xử lý dữ liệu đầu vào | ||
| 6 | Khả năng chịu lỗi chính tả | Các lỗi một và hai ký tự trong các thuật ngữ chính vẫn khớp nhau. |
| 7 | Gấp chữ hoa và dấu phụ | Đúng cho mọi ngôn ngữ mà trang web hỗ trợ (xem bên dưới) |
| 8 | Hình thái học và số nhiều | Các dạng biến tố và thêm hậu tố tạo ra cùng một sản phẩm như dạng gốc. |
| 9 | Từ đồng nghĩa và tiếng lóng địa phương | Từ khóa của khách hàng tương ứng với từ khóa trong danh mục sản phẩm, theo cả hai chiều. |
| 10 | Tự động hoàn thành khi có lỗi chính tả. | Các gợi ý sẽ xuất hiện cho các tiền tố bị viết sai chính tả; 69% các trang web không đáp ứng được yêu cầu này. |
| Nhóm C — Kết quả và sự phục hồi | ||
| 11 | Phục hồi không có kết quả | Ít nhất có hai đường dẫn thoát khả thi: các danh mục liên quan và các truy vấn thay thế. |
| 12 | Khả năng lưu trữ truy vấn | Truy vấn vẫn còn trong trường sau khi gửi; 37% các trang web loại bỏ nó. |
| 13 | Phạm vi có thể nhìn thấy | Số lượng kết quả và phạm vi danh mục được tự động áp dụng (nếu có) đều được nêu rõ và có thể xóa bỏ. |
| 14 | Sự tương đồng về khía cạnh | Kết quả tìm kiếm hiển thị các khía cạnh tương tự như trang danh mục tương ứng. |
| 15 | Tính liên quan có thể giải thích được. | Một thành viên trong nhóm có thể giải thích tại sao kết quả thứ nhất lại được xếp hạng cao hơn kết quả thứ hai. |
| Nhóm D — Đo lường | ||
| 16 | Mọi đường dẫn tìm kiếm đều được theo dõi. | Hàm view_search_results được kích hoạt với biến search_term, bao gồm cả các bước nhảy tự động hoàn thành. |
| 17 | Các truy vấn không có kết quả nào có thể được tách biệt. | Bạn có thể liệt kê các truy vấn không có kết quả của tháng trước theo số lượng, mà không cần yêu cầu nhập liệu. |
| 18 | Quá trình tìm kiếm đến mua hàng cần được báo cáo. | Những người tìm kiếm thông tin và những người không tìm kiếm thông tin có thể được so sánh như những phân khúc. |
| 19 | Yêu cầu đánh giá có chủ sở hữu | Một người được chỉ định sẽ xem xét 50 kết quả hàng đầu và 50 kết quả cuối cùng (không có kết quả nào) theo định kỳ. |
| 20 | Các thay đổi cấu hình được ghi lại theo phiên bản. | Các thay đổi về từ đồng nghĩa và tăng cường được ghi lại, có thể đảo ngược và kiểm tra được. |
Ngưỡng của Nhóm A được lấy từ tỷ lệ lỗi theo từng loại do Baymard công bố: tìm kiếm không liên quan đến sản phẩm thất bại trên 66% trang web, tìm kiếm từ viết tắt và ký hiệu thất bại trên 54%, tìm kiếm khả năng tương thích thất bại trên 44%, tìm kiếm trường hợp sử dụng thất bại trên 43% (Baymard). Mục kiểm tra 11 tồn tại vì gần một nửa số trang web không cung cấp cho người dùng cách giải quyết hiệu quả khi gặp bế tắc (Baymard, tháng 2 năm 2025). Các bước kiểm tra 10 và 12 xuất phát từ kết quả kiểm tra tính năng tự động hoàn thành và duy trì truy vấn của cùng một tiêu chuẩn (Tiêu chuẩn tìm kiếm Baymard).
Kiểm tra mục 7 chi tiết: cái bẫy gấp chỉ xuất hiện bên ngoài tiếng Anh
Mục kiểm tra số 7 xứng đáng có một phần riêng vì nó là mục âm thầm loại bỏ một thị trường. Hầu hết các công cụ tìm kiếm đều chuyển đổi truy vấn và chỉ mục thành chữ thường trước khi khớp. Trong tiếng Anh thì điều đó vô hại. Nhưng trong tiếng Thổ Nhĩ Kỳ thì không, và vấn đề tương tự xuất hiện trong bất kỳ ngôn ngữ nào có các ký tự ngoài bảng chữ cái Latinh cơ bản.
Unicode định nghĩa quy tắc viết hoa/viết thường riêng cho tiếng Thổ Nhĩ Kỳ và tiếng Azeri: chữ I viết hoa (U+0049) và chữ thường không có dấu chấm. ı (U+0131), trong khi chữ İ viết hoa (U+0130) được viết thường thành chữ thường i (Unicode SpecialCasing.txt). Một ngăn xếp chuyển đổi chữ thường theo ngôn ngữ mặc định sẽ biến "İPHONE" thành "i̇phone" với một dấu chấm thừa, hoặc biến chữ I viết hoa trong tiêu đề sản phẩm thành chữ cái sai. Truy vấn và chỉ mục sau đó không thống nhất về một từ mà cả hai đều chứa. Không có lỗi nào xảy ra. Bạn chỉ nhận được kết quả bằng không cho một thương hiệu mà bạn đang bán.
Hai cách khắc phục này độc lập và bạn cần cả hai. Đầu tiên, hãy áp dụng việc chuyển đổi chữ thường theo ngôn ngữ địa phương tại thời điểm lập chỉ mục và truy vấn — Elasticsearch cung cấp sẵn một công cụ như vậy. turkish bộ phân tích nối apostrophe, turkish_lowercase, turkish_stop, turkish_keywords và turkish_stemmer Chính vì lý do này (Đàn hồi, bộ phân tích ngôn ngữThứ hai, hãy quyết định riêng về việc xử lý các dấu phụ, vì người mua hàng Thổ Nhĩ Kỳ thường xuyên gõ kilif cho che phủ và thù lao cho sạc pin trên bàn phím khiến dạng có dấu gõ chậm hơn. asciifolding Bộ lọc chuyển đổi các ký tự không phải Basic-Latin sang các ký tự ASCII tương đương, và nó preserve_original Tùy chọn này phát ra cả token đã được gấp lại và token gốc, vì vậy các kết quả trùng khớp chính xác vẫn được ưu tiên (Đàn hồi, đa tạp asciGấp lại để dễ nhớ, giữ nguyên bản gốc để đảm bảo độ chính xác.
Bên ngoài Thổ Nhĩ Kỳ, cách kiểm tra tương tự có những biến thể địa phương: danh từ ghép tiếng Đức cần được tách ra trước khi có thể khớp với truy vấn hai từ, dấu trọng âm tiếng Pháp và tiếng Tây Ban Nha được gõ không nhất quán, dấu sigma cuối câu tiếng Hy Lạp. Chỉ chấm điểm kiểm tra 7 là 2 nếu bạn đã kiểm tra nó bằng mọi ngôn ngữ mà cửa hàng trực tuyến của bạn thực sự phục vụ — chứ không phải ngôn ngữ mà nhóm của bạn sử dụng.
Trước tiên hãy sửa lỗi đo lường: kiểm tra từ 16 đến 20
Nếu điểm số của Nhóm D dưới 6, hãy dừng lại và khắc phục sự cố trước khi động chạm vào bất cứ thứ gì khác, vì bạn không thể xác minh việc khắc phục mà bạn không thể nhìn thấy. Trong GA4, tính năng đo lường nâng cao được kích hoạt. view_search_results với một search_term tham số khi trang kết quả chứa một trong năm tham số truy vấn mặc định — q, s, search, query or keyword — và bạn có thể thêm ý kiến của riêng mình (Trợ giúp Google AnalyticsCó hai kiểu lỗi thường gặp. Nếu trang kết quả tìm kiếm của bạn sử dụng phân đoạn đường dẫn thay vì chuỗi truy vấn, tính năng theo dõi mặc định sẽ không ghi nhận được gì. Và nếu tính năng tự động hoàn thành dẫn thẳng đến sản phẩm, tìm kiếm đó sẽ không bao giờ kích hoạt sự kiện, điều này âm thầm làm sai lệch nhật ký truy vấn của bạn theo hướng các tìm kiếm không tìm thấy kết quả nào trong lần thử đầu tiên.
Đọc điểm số của bạn
| Điểm số | Phán quyết | Bước tiếp theo |
|---|---|---|
| 32-40 | Điều chỉnh, không thay thế | Chi tiêu cho từ đồng nghĩa, quy tắc tiếp thị và sàng lọc không hiệu quả |
| 22-31 | Vấn đề cấu hình | Sửa nhóm B và kiểm tra nhóm 11 trước; chấm điểm lại sau sáu tuần. |
| 12-21 | Có lẽ là do cấu trúc | Chấm điểm lại sau khi sửa lỗi Nhóm D, sau đó lập kế hoạch thay thế với 20 bước kiểm tra này làm tiêu chí chấp nhận. |
| 0-11 | Chức năng tìm kiếm hiện chưa có. | Hãy coi đây là quá trình xây dựng, chứ không phải là tối ưu hóa. |
Nguyên tắc quan trọng: đừng bao giờ ký hợp đồng thay thế dựa trên điểm số bạn đạt được trước khi Nhóm D làm việc. Nhà cung cấp được đánh giá dựa trên kết quả tìm kiếm không đo lường được thì cũng được đánh giá dựa trên bản demo.
Một lưu ý về con số mà mọi người thường nhắc đến.
Bạn sẽ thấy một thống kê cho thấy người dùng tìm kiếm trên trang web có tỷ lệ chuyển đổi cao hơn gấp hai hoặc ba lần so với người dùng không tìm kiếm, thường là để biện minh cho ngân sách. Con số này được lan truyền rộng rãi trong các báo cáo tổng hợp của nhà cung cấp (ví dụ) và hiếm khi có thể truy vết đến một nghiên cứu có kiểm soát. Nó cũng là một hiệu ứng chọn lọc: những người tìm kiếm là những người đã có ý định mua hàng. Hãy sử dụng nó như một lý do để xem xét tìm kiếm, chứ không bao giờ như một dự báo về sự tăng trưởng. Luận điểm kinh doanh hợp lý được xây dựng dựa trên khối lượng kết quả bằng không của chính bạn và tỷ lệ chuyển đổi từ tìm kiếm sang mua hàng của chính bạn — cả hai đều được kiểm tra trong mục 17 và mục 18 để tạo ra. [CẦN DỮ LIỆU NỘI BỘ: Tỷ lệ kết quả bằng không của khách hàng Switas trước/sau khi khắc phục, nếu có thể chia sẻ.]
Điểm yếu của tiêu chí này là gì?
Bảng đánh giá này được xây dựng cho bán lẻ qua catalog. Các sàn thương mại điện tử có nhiều người bán cùng một mặt hàng cần có thêm tiêu chí về danh sách trùng lặp và chất lượng người bán, nhưng bảng đánh giá này lại không có cột nào dành cho điều đó. Các trang web có nội dung phong phú và thuộc khu vực công cần trọng số theo loại tài liệu và độ mới thay vì Nhóm A. Các trang web có dưới khoảng 500 SKU thường đạt điểm cao nhưng vẫn bị lỗ tiền từ tìm kiếm, bởi vì với một catalog nhỏ, giải pháp thực sự là cải thiện điều hướng danh mục chứ không phải cải thiện tìm kiếm. Bảng đánh giá cũng không đề cập gì đến tốc độ tìm kiếm khi tải nặng, và không nói gì về cá nhân hóa — cả hai đều là cố ý, bởi vì việc kiểm tra đúng cách cả hai đều tốn kém và chúng không phải là vấn đề của bạn nếu điểm số dưới 30. Cuối cùng, điểm số chỉ là một ảnh chụp nhanh: việc nhập catalog làm thay đổi tên thuộc tính có thể làm giảm Nhóm A xuống sáu điểm chỉ sau một đêm mà không cần triển khai bất kỳ mã nào.
FAQ
Quá trình chấm điểm mất bao lâu? Mất khoảng nửa ngày cho một người làm việc trên một cửa hàng trực tuyến, sau khi đã có danh sách thử nghiệm gồm 90 truy vấn. Việc xây dựng danh sách là phần tốn thời gian nhất; hãy dành thêm hai giờ để chọn ra các truy vấn hàng đầu và xây dựng tập hợp các truy vấn ít phổ biến hơn.
Tôi có cần kỹ sư để vận hành nó không? Không. Các bước kiểm tra từ 1 đến 15 được thực hiện trên trình duyệt. Các bước kiểm tra từ 16 đến 20 cần quyền truy cập phân tích và, đối với bước kiểm tra thứ 20, cần trao đổi với người chịu trách nhiệm cấu hình tìm kiếm.
Nếu chúng ta không có lịch sử phân tích tìm kiếm thì sao? Chấm điểm Nhóm D là 0, sửa lỗi theo dõi và thu thập dữ liệu trong bốn tuần trước khi chấm điểm các nhóm còn lại. Danh sách thử nghiệm được xây dựng mà không có nhật ký truy vấn thực tế sẽ phản ánh quá mức số lượng truy vấn mà nhóm của bạn sẽ nhập.
Điểm 28 có tốt không? Điều đó là bình thường, và bình thường có nghĩa là ở mức trung bình — tiêu chuẩn cho thấy hầu hết các trang web đều nằm ở mức đó. Tín hiệu hữu ích không phải là tổng thể mà là nhóm nào đang kéo nó xuống.
Chúng ta nên mua khả năng chịu lỗi chính tả hay tự tạo ra nó? Hãy mua nó. Việc khớp khoảng cách chỉnh sửa với ngưỡng hợp lý đã được giải quyết và chi phí thấp. Nỗ lực xây dựng nằm ở từ đồng nghĩa và cấu trúc thuộc tính, những thứ đặc thù cho danh mục của bạn và không thể mua được.
Điều này liên quan như thế nào đến việc kiểm tra trang danh mục sản phẩm? Chúng có chung các khía cạnh và bộ lọc. Nếu bước kiểm tra 14 thất bại, giải pháp thường nằm ở các mẫu danh mục chứ không phải ở chức năng tìm kiếm, vì vậy hãy chạy cả hai bài kiểm tra trong cùng một sprint.
Liệu điều này có áp dụng cho các trợ lý ảo AI đọc catalog của chúng ta không? Một phần là vậy. Các tác nhân sử dụng các thuộc tính có cấu trúc chứ không phải giao diện tìm kiếm của bạn, vì vậy Nhóm A và B có ý nghĩa với họ thông qua chất lượng dữ liệu của bạn, trong khi Nhóm C và D hoàn toàn không áp dụng. Đó là một cuộc kiểm toán riêng biệt.
Chúng ta nên chấm điểm lại bao nhiêu lần? Cập nhật hàng quý, và sau bất kỳ quá trình di chuyển danh mục, chuyển đổi nền tảng hoặc thay đổi cấu hình tìm kiếm nào. Giữ nguyên danh sách 90 truy vấn để điểm số có thể so sánh được.
Nếu bạn muốn biết kết quả mà không cần tốn cả buổi chiều: Hãy để chúng tôi thực hiện cuộc kiểm toán này cho cửa hàng của bạn. và đưa cho bạn bảng điểm, các câu hỏi bị lỗi và danh sách các lỗi cần khắc phục theo thứ tự ưu tiên.
nguồn
- Viện Baymard — Trải nghiệm người dùng tìm kiếm thương mại điện tử: 8 loại truy vấn và tỷ lệ lỗi theo từng loại (cập nhật tháng 4 năm 2026)
- Viện Baymard — Khả năng sử dụng chức năng tìm kiếm thương mại điện tử: Báo cáo & So sánh chuẩn
- Viện Baymard — 5 chiến lược UX đã được chứng minh hiệu quả cho các trang "không có kết quả" (Tháng 2 năm 2025)
- Hiệp hội Unicode — SpecialCasing.txt, quy tắc viết hoa chữ cái đầu câu tiếng Thổ Nhĩ Kỳ và tiếng Azeri.
- Elastic — Các công cụ phân tích ngôn ngữ, bao gồm cả chuỗi phân tích tiếng Thổ Nhĩ Kỳ.
- Elastic — Bộ lọc mã thông báo gấp ASCII và preserve_original
- Trợ giúp Google Analytics — Đo lường nâng cao, view_search_results và search_term
- Chào mừng đến với Hello Retail — ví dụ về hệ số nhân chuyển đổi tìm kiếm trên trang web đang lưu hành
