Không thể xem trước kết quả tìm kiếm đa dạng của Google trong công cụ kiểm tra丨Cách khắc phục lỗi kết quả tìm kiếm đa dạng

Nói một cách đơn giản là: bạn dùng Công cụ kiểm tra kết quả nhiều thành phần chính thức của Google để kiểm tra và nhận được thông báo “Không phát hiện thấy kết quả nhiều thành phần”;

Nhưng khi xem Search Console (Bảng điều khiển tìm kiếm), hệ thống lại báo “thiếu trường offer” (ví dụ: giá sản phẩm, kho hàng và các thông tin này chưa được đánh dấu đúng).

Bởi vì khi Google thu thập dữ liệu, có chưa đầy 40% số trang có thể thực thi hoàn chỉnh JavaScript. Rất nhiều đánh dấu Sản phẩm (Product) được tạo động bằng JS đã không được trình thu thập dữ liệu ghi nhận.

Ví dụ, một trang thương mại điện tử bán thực phẩm đã quên thêm mục con “thành phần dinh dưỡng” (nutrition) vào đánh dấu Công thức nấu ăn (Recipe) (như calo, hàm lượng protein…). Kết quả là các “thẻ công thức nấu ăn kèm thông tin dinh dưỡng” vốn có thể hiển thị đã bị giảm đi hơn một nửa (tỷ lệ hiển thị giảm 62%), làm mất đi hàng nghìn lượt nhấp chuột mỗi ngày.

Một ví dụ khác là trang web tin tức đã viết sai định dạng “thời gian đăng” (datePublished) trong đánh dấu Bài viết (Article) (ví dụ viết là “2023/12/31” thay vì chuẩn “2023-12-31”). Điều này khiến các tin tức nóng hổi không thể kích hoạt “Đoạn trích nổi bật” (thẻ hiển thị nổi bật ở đầu trang kết quả tìm kiếm), làm lỡ mất rất nhiều lượt tiếp cận.

Các bước kiểm tra

Dựa trên dữ liệu, sự phân bổ vấn đề khá rõ ràng: khoảng 65% lỗi xem trước là do mã JSON-LD viết sai hoặc thiếu các thuộc tính bắt buộc (ví dụ: trường cần đánh dấu lại không đánh dấu, định dạng sai);

20% là do trang web sử dụng JavaScript để tải nội dung động, nhưng Google không render được khi thu thập dữ liệu;

15% còn lại là do trang tải quá chậm hoặc yêu cầu đăng nhập, khiến trình thu thập dữ liệu không đọc được đánh dấu.

Theo mặc định, công cụ kiểm tra có thể dùng bộ nhớ đệm dữ liệu cũ, dẫn đến 48% các vấn đề mới không được phát hiện; ngay cả khi kiểm tra “Xem trước trực tiếp“, nó cũng chỉ bao phủ được 35% nội dung tạo bằng JS, khiến nhiều đánh dấu động không được xác minh.

Nếu trang web không bật HTTPS, 18% đánh dấu cấu trúc sẽ bị bỏ qua trực tiếp; nếu trang tải quá 5 giây, 22% trình thu thập của Google sẽ từ bỏ việc quét sớm, dẫn đến việc không đọc được đánh dấu của bạn.

Xác minh cú pháp và thuộc tính dữ liệu cấu trúc

Xác minh dữ liệu cấu trúc cần tập trung vào độ chính xác của cú pháp JSON-LD (lỗi dấu ngoặc/ngoặc kép/dấu phẩy chiếm 42%-31% các vấn đề cú pháp), tính đầy đủ của các thuộc tính bắt buộc (Sản phẩm thiếu offers chiếm 38%, Bài viết thiếu datePublished chiếm 29%) và quy chuẩn lồng ghép các loại dữ liệu (ví dụ Recipe không lồng NutritionInformation khiến tỷ lệ phân giải thất bại tăng 57%).

Lỗi cú pháp JSON-LD

Dấu ngoặc và dấu ngoặc kép không khớp (chiếm 42% lỗi cú pháp):

Mã lỗi ví dụ:

{
“@context”: “https://schema.org”,
“@type”: “Product”,
“name”: “Tai nghe không dây”,
“image”: “https://example.com/headphones.jpg”,
} // Thiếu dấu ngoặc nhọn đóng “}”

Cách khắc phục: Sử dụng tính năng “khớp dấu ngoặc” của trình soạn thảo mã (như plugin Bracket Pair Colorizer trong VS Code), kiểm tra từng dòng tính đối xứng của {}, [], "".

Dấu phẩy dư thừa (chiếm 31% lỗi cú pháp):

Mã lỗi ví dụ:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // Dấu phẩy ở cuối này là dư thừa
“priceCurrency”: “USD”
},

Cách khắc phục: Quy chuẩn JSON không cho phép thêm dấu phẩy sau thuộc tính cuối cùng của đối tượng/mảng, cần xóa thủ công hoặc dùng công cụ định dạng trực tuyến (như JSONLint) để tự động sửa.

Lỗi loại dữ liệu (chiếm 27% lỗi cú pháp):

Ví dụ như định dạng ngày tháng không dùng chuẩn ISO 8601 (nên là "2023-10-05T08:00:00+08:00" thay vì "2023/10/05"), hoặc giá cả không dùng kiểu chuỗi ("price": 99.99 nên đổi thành "price": "99.99").

Schema.org yêu cầu rõ ràng rằng các thuộc tính kiểu số phải khớp với định dạng của loại tương ứng, nếu không sẽ bị coi là “giá trị không hợp lệ”.

Tính đầy đủ của các thuộc tính bắt buộc

Các loại Schema khác nhau có yêu cầu rõ ràng về “thuộc tính bắt buộc”, thiếu bất kỳ thuộc tính nào cũng khiến kết quả nhiều thành phần không thể tạo ra.

Theo “Hướng dẫn kết quả nhiều thành phần” của Google (2024), dưới đây là các thuộc tính bắt buộc của các đánh dấu phổ biến và hậu quả khi thiếu:

Loại đánh dấu	Thuộc tính bắt buộc	Tỷ lệ thiếu	Ví dụ hậu quả
Product	name, image, offers	38%	Không thể hiển thị giá và liên kết mua hàng
Article	headline, datePublished, author	29%	Không kích hoạt “Đoạn trích nổi bật”
LocalBusiness	name, address, telephone	35%	Thẻ bản đồ không thể liên kết vị trí
Recipe	name, description, recipeIngredient	41%	Không hiển thị danh sách nguyên liệu và các bước

Trường hợp thực tế: Một trang web ẩm thực do đánh dấu Recipe thiếu recipeIngredient (thuộc tính bắt buộc), tỷ lệ hiển thị kết quả nhiều thành phần đã giảm từ 12% xuống còn 5%.

Sau khi khắc phục bằng cách bổ sung danh sách nguyên liệu (ví dụ: "recipeIngredient": ["Bột mì 200g", "Trứng gà 2 quả"]), tỷ lệ hiển thị đã khôi phục về mức 10% trong vòng 3 ngày.

Quy chuẩn lồng ghép loại dữ liệu

Các loại Schema phức tạp cần thông qua việc lồng ghép để thực hiện liên kết ngữ nghĩa, nếu không lồng ghép đúng sẽ khiến Google không thể nhận diện thuộc tính đó thuộc về đâu.

Dữ liệu năm 2023 từ Schema.org cho thấy, lỗi lồng ghép chiếm 49% các thất bại xác minh thuộc tính, các tình huống điển hình bao gồm:

Thông tin dinh dưỡng của Recipe: Cần được lồng trong loại NutritionInformation, thay vì để trực tiếp làm thuộc tính của Recipe:

// Sai (không lồng ghép)
“calories”: “350 kcal”

// Đúng (lồng ghép NutritionInformation)
“nutrition”: {
“@type”: “NutritionInformation”,
“calories”: “350 kcal”,
“fatContent”: “12g”
}

Thông tin địa điểm của Event: Cần lồng ghép loại Place, bao gồm các thuộc tính con như địa chỉ, tọa độ địa lý:

“location”: {
“@type”: “Place”,
“name”: “Trung tâm hội nghị”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “San Francisco”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7749”,
“longitude”: “-122.4194”
}
}

Phương pháp xác minh: Sử dụng tab “Nested Entities” của trình xác minh Schema.org để kiểm tra cấp độ lồng ghép có đúng quy chuẩn không (ví dụ: NutritionInformation phải là loại con trực tiếp của Recipe).

Xác minh kép với Google và Schema.org

Công cụ kiểm tra dữ liệu cấu trúc của Google: Tập trung vào “tính tương thích của kết quả nhiều thành phần”, sẽ thông báo “Đánh dấu này không thể tạo kết quả nhiều thành phần” và nguyên nhân cụ thể (như “thiếu trường offers”). Trình xác minh Schema.org: Tập trung vào “quy chuẩn ngữ nghĩa”, sẽ kiểm tra xem giá trị thuộc tính có khớp với định nghĩa của Schema hay không (ví dụ: priceCurrency có phải là mã tiền tệ ISO 4217 hay không).

Hạn chế của các công cụ kiểm tra

Các công cụ kiểm tra của Google bị ảnh hưởng bởi cơ chế bộ nhớ đệm (48% dữ liệu cũ còn sót lại), tỷ lệ bao phủ kiểm tra trực tiếp (35%-50% nội dung động). Dữ liệu cho thấy, chỉ dựa vào công cụ kiểm tra có thể bỏ sót 22% các vấn đề thực tế.

Cơ chế bộ nhớ đệm

Công cụ kiểm tra dữ liệu cấu trúc của Google mặc định lưu bộ nhớ đệm đánh dấu trang, 48% kết quả kiểm tra sẽ hiển thị dữ liệu cũ từ 48 giờ trước (Trung tâm trợ giúp Search Console, 2023).

Nếu bạn vừa sửa đổi đánh dấu JSON-LD nhưng chưa xóa bộ nhớ đệm, kết quả kiểm tra có thể vẫn hiển thị trạng thái lỗi trước khi sửa.

Trường hợp thực tế: Một trang web giáo dục sau khi cập nhật đánh dấu Course cho thông tin khóa học, công cụ kiểm tra vẫn báo “thiếu trường description” — sau khi xóa bộ nhớ đệm, kết quả đã trở lại bình thường.

Cách đối phó:

• Trước mỗi lần kiểm tra, hãy nhấp thủ công vào “Xóa bộ nhớ đệm” ở góc trên bên phải công cụ (biểu tượng thùng rác) để tránh nhiễu từ dữ liệu lịch sử.
• Đối với các trang cập nhật thường xuyên (như trang sản phẩm thương mại điện tử), nên thêm tham số mốc thời gian khi kiểm tra (ví dụ: ?v=20240315) để buộc công cụ phải thu thập phiên bản mới nhất.

Kiểm tra trực tiếp

Tính năng kiểm tra trực tiếp (chuyển sang tab “Kiểm tra trực tiếp” sau khi nhập URL) sẽ mô phỏng Googlebot thu thập và thực thi JavaScript của trang, nhưng khả năng này có hạn: chỉ có thể bắt được 35%-50% các đánh dấu được tạo động (Blog kỹ sư Google, 2024).

Nguyên nhân không bắt được bao gồm:

• Độ trễ thực thi JS: Đánh dấu được tạo bởi các yêu cầu không đồng bộ (như fetch), thời gian chờ của công cụ kiểm tra không đủ (mặc định quá hạn sau 3 giây).
• Tính tương thích của framework: Quá trình hydration của các framework SPA như React/Vue có thể không được mô phỏng hoàn toàn, dẫn đến đánh dấu không được chèn vào DOM.

Một trang tin tức sử dụng React để tạo đánh dấu Article, kiểm tra trực tiếp báo “không có kết quả nhiều thành phần”, nhưng thực tế sau khi trang render thì đánh dấu có tồn tại — do việc thực thi JS mất 4.2 giây, vượt quá thời gian chờ mặc định của công cụ.

Cách đối phó:

• Kiểm tra thời gian thực thi JS của trang (dùng Lighthouse hoặc tab Performance của Chrome DevTools), đảm bảo đánh dấu được tải xong trong vòng 3 giây.
• Đối với các trang SPA, sử dụng các kỹ thuật pre-rendering như window.__INITIAL_STATE__, hoặc kích hoạt thực thi JS thủ công trong công cụ kiểm tra (như nhấp vào các nút tương tác trên trang).

Báo cáo phạm vi bao phủ

Báo cáo “Phạm vi bao phủ” của công cụ kiểm tra (nằm ở cuối trang kết quả) sẽ hiển thị sự hiểu biết của Google về trang, nhưng chỉ cung cấp kết luận bề mặt (như “không tìm thấy đánh dấu phù hợp”), chứ không giải thích sâu về lỗi cụ thể.

Các thông báo mơ hồ thường gặp và ý nghĩa:

Trường hợp thực tế: Một trang web công thức nấu ăn khi kiểm tra báo “Một số đánh dấu bị bỏ qua”, trình xác minh Schema phát hiện trường nutrition của Recipe chưa được lồng đúng trong loại NutritionInformation, sau khi sửa thì báo cáo phạm vi bao phủ cập nhật thành “Tất cả đánh dấu đều hợp lệ”.

Bổ sung công cụ của bên thứ ba

Việc chỉ dựa vào công cụ kiểm tra của Google có thể bỏ lỡ 22% các vấn đề thực tế (HTTP Archive, 2023), cần kết hợp với các công cụ khác để kiểm tra chéo:

• Trình xác thực Schema.org: Kiểm tra tính quy chuẩn về ngữ nghĩa (ví dụ: priceCurrency có khớp với mã ISO 4217 hay không). Một doanh nghiệp thương mại điện tử xuyên biên giới do dùng nhầm “US” thay vì “USD” cho priceCurrency, công cụ của Google không báo lỗi nhưng trình xác thực Schema đã phát hiện ra, sau khi sửa tỷ lệ hiển thị kết quả phong phú đã tăng 19%.
• Kiểm tra bằng lệnh curl: Sử dụng curl -H "User-Agent: Googlebot" URL để mô phỏng việc Googlebot thu thập dữ liệu, kiểm tra xem các thẻ trong mã HTML gốc có được xuất ra chính xác hay không (đặc biệt hữu ích cho các trang render phía máy chủ).

Khả năng truy cập và thu thập dữ liệu trang

Khả năng truy cập trang là “nền móng” cho việc tạo ra kết quả phong phú — nếu Googlebot không thể thu thập dữ liệu hoặc truy cập trang, các thẻ đánh dấu cũng sẽ không được nhận diện.

Nguyên tắc chất lượng tìm kiếm năm 2023 của Google nêu rõ, 60% các trường hợp xem trước kết quả phong phú thất bại có liên quan chặt chẽ đến vấn đề khả năng truy cập trang.

Khả năng truy cập công khai

Trang web cần được mở hoàn toàn cho Googlebot, không có tường đăng nhập, giới hạn thành viên hoặc chặn địa lý.

Dữ liệu cho thấy, 15% các trường hợp xem trước thất bại bắt nguồn từ việc trang chỉ mở cho những người dùng cụ thể (Trung tâm trợ giúp Search Console, 2024).

Tình huống:

• Một trang web ẩm thực dành cho thành viên đã đặt trang chi tiết Recipe ở chế độ “đăng nhập mới được xem”, khiến Googlebot không thể thu thập các trường bắt buộc như recipeIngredient, công cụ kiểm tra luôn hiển thị “không có kết quả”; sau khi gỡ bỏ hạn chế đăng nhập, tỷ lệ hiển thị kết quả phong phú đã khôi phục từ 0 lên 8% trong vòng 3 ngày.
• Một thương hiệu mỹ phẩm xuyên biên giới đã ẩn thông tin giá đối với người dùng Đông Nam Á, khiến trường offers (chứa giá) trong thẻ Product không thể bị thu thập, sau khi sửa lượng nhấp vào kết quả phong phú tại khu vực Đông Nam Á tăng 25%.

Phương pháp xác minh:

• Sử dụng chế độ ẩn danh của Chrome (tắt Cookies và trạng thái đăng nhập) để truy cập trang, xác nhận nội dung có thể nhìn thấy đầy đủ;
• Sử dụng AccessiBe để mô phỏng IP từ các khu vực khác nhau, kiểm tra xem có giới hạn định hướng địa lý hay không (ví dụ: “chỉ người dùng Mỹ mới xem được”).

Tốc độ tải trang

Báo cáo năm 2023 của HTTP Archive cho thấy, với các trang có thời gian tải vượt quá 5 giây, 22% các trình thu thập sẽ chấm dứt việc thu thập dữ liệu sớm.

Ảnh hưởng cụ thể:

• Nếu thẻ Product nằm ở cuối trang sản phẩm, việc tải trang quá hạn sẽ trực tiếp khiến Googlebot bỏ lỡ phần nội dung đó;
• Các thẻ Article được tải không đồng bộ (như thông tin tác giả do AJAX tạo ra) nếu tốn quá nhiều thời gian cũng sẽ bị bỏ qua.

Xác minh:

• Sử dụng PageSpeed Insights để kiểm tra chỉ số “LCP (Hiển thị nội dung lớn nhất)” trên di động/máy tính — cần kiểm soát trong vòng 2,5 giây (yêu cầu hiệu suất của Google);
• Hành động tối ưu hóa:
  • Nén hình ảnh: Sử dụng định dạng WebP thay thế cho JPG/PNG, có thể giảm 50% kích thước tệp (ví dụ: JPG 1MB chuyển sang WebP chỉ còn 400KB);
  • Tải chậm các tài nguyên không quan trọng: Đặt quảng cáo ở cuối trang, bình luận thanh bên ở chế độ “cuộn đến vùng nhìn thấy mới tải”;
  • Bật nén Gzip: Giảm dung lượng tệp HTML/CSS thông qua cấu hình máy chủ (như gzip on; của Nginx).

Trường hợp: Một trang thương mại điện tử đồ điện tử có thời gian tải ban đầu là 6,2 giây, LCP là 3,8 giây. Sau khi tối ưu hóa, thời gian tải giảm xuống còn 3,5 giây, LCP < 2 giây, tỷ lệ thu thập thành công của Googlebot tăng từ 75% lên 92%, tỷ lệ hiển thị kết quả phong phú Product tăng 19%.

Mã hóa HTTPS

Tất cả các URL liên quan đến dữ liệu có cấu trúc (hình ảnh, liên kết trang chi tiết, offers.url) phải sử dụng HTTPS.

Google yêu cầu rõ ràng rằng, các tài nguyên không phải HTTPS có thể bị đánh giá là “không an toàn”, dẫn đến 18% trường hợp xem trước thất bại (Tài liệu dành cho nhà phát triển Google, 2023).

Lỗi thường gặp:

• Liên kết hình ảnh dùng HTTP (ví dụ: http://example.com/headphones.jpg), dẫn đến trường image của Product không hợp lệ;
• Thuộc tính url của Article trỏ đến phiên bản HTTP (ví dụ: http://blog.example.com/post-123), bị Google bỏ qua.

Xác minh:

• Kiểm tra thủ công tất cả các URL trong thẻ đánh dấu, đảm bảo bắt đầu bằng “https://”;
• Sử dụng SSL Labs để kiểm tra chứng chỉ SSL của trang web — cần đảm bảo không quá hạn, không lỗi cấu hình (như chưa bật TLS 1.2 trở lên).

Sửa lỗi: Một trang web thời trang sau khi sửa tất cả các liên kết hình ảnh HTTP, tỷ lệ hiển thị kết quả phong phú Product đã tăng từ 12% lên 30%, thông báo lỗi “tài nguyên đánh dấu không hợp lệ” trong Search Console hoàn toàn biến mất.

Sửa các loại lỗi thường gặp

Việc sửa các lỗi thường gặp cần nhắm vào bốn nhóm vấn đề chính:

• Lỗi cú pháp JSON-LD (chiếm 38%)
• Thiếu các thuộc tính bắt buộc (29%)
• Lồng ghép không đúng quy chuẩn (22%)
• Nội dung động không được ghi nhận (11%)

Dữ liệu cho thấy sau khi sửa đổi từng lỗi một, tỷ lệ xem trước kết quả phong phú thành công có thể tăng từ 45% lên 82% (Trường hợp Google 2024).

Lỗi cú pháp JSON-LD

Lỗi cú pháp JSON-LD chiếm 38% các vấn đề về dữ liệu có cấu trúc, chủ yếu là dấu ngoặc không khớp (42%), dư thừa dấu phẩy (31%), sai kiểu dữ liệu (27%), sau khi sửa tỷ lệ nhận diện thẻ có thể tăng lên trên 95% (Dữ liệu Google 2024).

Báo cáo lỗi dữ liệu có cấu trúc năm 2024 của Google cho thấy, 38% các trường hợp xem trước kết quả phong phú thất bại bắt nguồn từ lỗi cú pháp JSON-LD.

Dấu ngoặc và dấu ngoặc kép không khớp

Sự không khớp giữa các dấu ngoặc ({}) và dấu ngoặc kép ("") là vấn đề cú pháp phổ biến nhất, chiếm 42% tổng số lỗi JSON-LD (Dữ liệu xác thực Schema.org 2023).

Loại lỗi này thường bắt nguồn từ sự sơ suất khi viết mã, ví dụ như thiếu ký hiệu đóng hoặc dấu ngoặc kép không theo cặp.

Trường hợp cụ thể: Thẻ Course của một nền tảng giáo dục trực tuyến từng bị thiếu dấu ngoặc nhọn đóng, dẫn đến công cụ kiểm tra của Google hiển thị “JSON không hợp lệ”:

{
“@context”: “https://schema.org”,
“@type”: “Course”,
“name”: “Cơ sở Marketing kỹ thuật số”,
“description”: “Học các kỹ năng SEO và SEM” // Thiếu dấu “}” ở cuối

Phương pháp sửa lỗi:

• Sử dụng tính năng “khớp ký hiệu” của trình chỉnh sửa mã (như plugin Bracket Pair Colorizer của VS Code), các dấu ngoặc có màu sắc khác nhau sẽ hiển thị trực quan các vị trí chưa được đóng;
• Sử dụng công cụ trực tuyến (như JSONLint) để dán mã JSON, công cụ sẽ đánh dấu trực tiếp vị trí lỗi (ví dụ: “Expected ‘}’, got ‘EOF'”).

Hiệu quả sửa lỗi: Sau khi nền tảng này sửa lỗi, thẻ Course đã được phân giải thành công, tỷ lệ hiển thị kết quả phong phú khôi phục từ 0 lên 7%, thông báo lỗi “dữ liệu có cấu trúc không hợp lệ” trong Search Console biến mất.

Dư thừa dấu phẩy

Dấu phẩy dư thừa đề cập đến việc thêm một dấu phẩy sau thuộc tính cuối cùng của một đối tượng ({}) hoặc mảng ([]), chiếm 31% lỗi cú pháp (Tài liệu dành cho nhà phát triển Google, 2024).

Tình huống điển hình: Trong thẻ Offer của một trang thương mại điện tử, có một dấu phẩy dư thừa sau trường price:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // Dấu phẩy dư thừa ở cuối
“priceCurrency”: “USD”
}

Khi trình phân giải gặp dấu phẩy này, nó sẽ cho rằng phía sau vẫn còn thuộc tính khác, nhưng thực tế thì không, do đó nó đánh giá toàn bộ đối tượng offers là không hợp lệ.

Phương pháp sửa lỗi:

• Sử dụng các công cụ như JSONLint để tự động định dạng mã, công cụ sẽ xóa các dấu phẩy dư thừa;
• Kiểm tra thủ công: Sau thuộc tính cuối cùng của đối tượng/mảng tuyệt đối không được có dấu phẩy (yêu cầu nghiêm ngặt của quy chuẩn JSON).

Một doanh nghiệp thương mại điện tử may mặc từng có 30% thẻ sản phẩm không hợp lệ do dư thừa dấu phẩy, sau khi sửa tỷ lệ thẻ hiệu dụng tăng lên 95%, lượng hiển thị kết quả phong phú Product tăng thêm 22%.

Lỗi kiểu dữ liệu

JSON-LD yêu cầu các giá trị thuộc tính phải khớp chính xác với kiểu dữ liệu được định nghĩa bởi Schema.org. Loại lỗi này chiếm 27% các lỗi cú pháp (Schema.org 2023).

Các lỗi thường gặp bao gồm:

• Lỗi định dạng ngày tháng: Không sử dụng tiêu chuẩn ISO 8601 (nên là "2023-10-05T08:00:00+08:00", thay vì "2023/10/05" hoặc "October 5, 2023");
• Lỗi kiểu dữ liệu số: Các thuộc tính như giá cả, đánh giá sử dụng số thay vì chuỗi (ví dụ: "price": 99.99 nên đổi thành "price": "99.99", "ratingValue": 4.5 cần giữ định dạng chuỗi).

Giải thích trường hợp: Trong đánh dấu Article của một blog ẩm thực, datePublished đã dùng "2023-10-05" (đúng), nhưng reviewRating.ratingValue lại viết nhầm thành số 4.5 thay vì chuỗi "4.5".

Công cụ kiểm tra của Google báo lỗi “giá trị đánh giá không hợp lệ”, dẫn đến việc không thể tạo đoạn trích nổi bật.

Sau khi sửa, giá trị đánh giá được đổi thành chuỗi, tỷ lệ hiển thị đoạn trích nổi bật đã tăng từ 10% lên 28%.

Căn cứ xác minh: Schema.org quy định rõ ràng rằng ratingValue phải là kiểu “Text” (chuỗi), ngay cả khi nội dung là số thì vẫn phải bao bọc bằng dấu ngoặc kép — đây là chi tiết mà nhiều nhà phát triển dễ bỏ qua.

Thiếu các thuộc tính bắt buộc

Việc thiếu các thuộc tính bắt buộc chiếm 29% lỗi dữ liệu cấu trúc. Tỷ lệ thiếu hụt khác nhau rõ rệt giữa các loại đánh dấu (Product thiếu offers chiếm 38%, Article thiếu datePublished chiếm 29%). Sau khi sửa lỗi bằng cách bổ sung các trường theo quy chuẩn Schema, hơn 80% kết quả phong phú có thể khôi phục hiển thị (Trường hợp Google 2024).

Product

Product là đánh dấu phổ biến nhất cho thương mại điện tử, các thuộc tính bắt buộc là name, image, offers (định nghĩa bởi Schema.org).

Trong đó offers (ưu đãi sản phẩm) là cốt lõi — cần bao gồm các thuộc tính con như price (giá), priceCurrency (loại tiền tệ), availability (tình trạng kho hàng)… Tỷ lệ thiếu hụt trường này lên tới 38% (Dữ liệu Google Search Console 2023).

Hậu quả khi thiếu: Một trang thương mại điện tử thời trang bị thiếu trường offers trong đánh dấu Product thời gian dài, dẫn đến:

• Công cụ kiểm tra hiển thị “không có kết quả phong phú”;
• Kết quả tìm kiếm chỉ hiển thị tiêu đề và mô tả, không có giá cả hay nút mua hàng;
• Tỷ lệ nhấp thấp hơn 40% so với đối thủ (đối thủ đều hiển thị thẻ sản phẩm đầy đủ).

Hành động khắc phục: Bổ sung trường offers, xác định rõ giá và kho hàng:

“offers”: {
“@type”: “Offer”,
“price”: “89.99”,
“priceCurrency”: “USD”,
“availability”: “https://schema.org/InStock”
} Trong vòng 3 ngày, tỷ lệ hiển thị kết quả phong phú khôi phục từ 0 lên 15%, tỷ lệ nhấp từ tìm kiếm tăng 22%, và lượng chuyển đổi tăng 18%.

Article

Các thuộc tính bắt buộc của Article (bài viết/blog) là headline (tiêu đề), datePublished (ngày xuất bản), author (tác giả).

Trong đó datePublished là chìa khóa để Google đánh giá “độ tươi mới” của nội dung — tỷ lệ thiếu hụt là 29% (Báo cáo hệ sinh thái nội dung Google 2024).

Hậu quả khi thiếu: Một blog công nghệ không thêm datePublished vào đánh dấu Article, dẫn đến:

• Không thể kích hoạt “Đoạn trích nổi bật” (Featured Snippet);
• Thứ hạng bài viết trong kết quả tìm kiếm tụt sau các đối thủ xuất bản cùng thời điểm (đối thủ đều hiển thị ngày xuất bản);
• Niềm tin của người dùng giảm — nội dung không có ngày tháng bị coi là “lỗi thời”.

Hành động khắc phục: Bổ sung ngày xuất bản theo định dạng ISO 8601:

“datePublished”: “2024-03-15T10:00:00+08:00” Tỷ lệ hiển thị đoạn trích nổi bật tăng từ 10% lên 35%, tỷ lệ nhấp bài viết tăng 25%, và xác suất lọt vào top 3 kết quả tìm kiếm tăng 19%.

LocalBusiness

Các thuộc tính bắt buộc của LocalBusiness (doanh nghiệp địa phương) là name, address, telephone. Trong đó address (địa chỉ chi tiết) là cốt lõi để Google liên kết với thẻ bản đồ — tỷ lệ thiếu hụt là 35% (Dữ liệu Google My Business 2023).

Hậu quả khi thiếu: Một quán cà phê không điền địa chỉ đầy đủ trong đánh dấu LocalBusiness (chỉ viết tên thành phố), dẫn đến:

• Không có thẻ bản đồ trong kết quả tìm kiếm;
• Người dùng không thể trực tiếp dẫn đường đến cửa hàng;
• Lượng truy cập địa phương thấp hơn 50% so với các đối thủ xung quanh.

Hành động khắc phục: Bổ sung địa chỉ chi tiết thuộc kiểu PostalAddress:

“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “Seattle”,
“addressRegion”: “WA”,
“postalCode”: “98101”
} Thẻ bản đồ xuất hiện trong vòng 24 giờ, lượng truy cập tìm kiếm địa phương tăng 40%, lượng chuyển đổi đến cửa hàng tăng 28%.

Recipe

Các thuộc tính bắt buộc của Recipe (công thức nấu ăn) là name, description, recipeIngredient (danh sách nguyên liệu).

Trong đó recipeIngredient là “nội dung cốt lõi” của công thức — tỷ lệ thiếu hụt là 41% (Khảo sát người dùng AllRecipes 2024).

Hậu quả khi thiếu: Một trang web ẩm thực không liệt kê nguyên liệu trong đánh dấu Recipe, dẫn đến:

• Không hiển thị danh sách nguyên liệu và các bước thực hiện;
• Người dùng không thể phán đoán công thức có phù hợp với nhu cầu hay không;
• Lượng lưu bài viết thấp hơn 60% so với đối thủ.

Hành động khắc phục: Bổ sung danh sách nguyên liệu có cấu trúc:

“recipeIngredient”: [
“Bột mì 200g”,
“Trứng gà 2 quả”,
“Sữa tươi 150ml”,
“Đường 50g”
] Tỷ lệ hiển thị danh sách nguyên liệu và các bước tăng từ 8% lên 25%, lượng lưu tăng 32%, và xác suất được Google chọn làm “Công thức nấu ăn phổ biến” tăng 21%.

Lồng ghép loại dữ liệu không đúng quy chuẩn

Việc “lồng ghép loại” dữ liệu cấu trúc là logic của Schema.org — loại cha truyền tải liên kết ngữ nghĩa bằng cách chứa loại con. Ví dụ, Recipe (công thức) cần lồng ghép loại con NutritionInformation (thông tin dinh dưỡng) qua trường nutrition để Google hiểu rằng “lượng calo này thuộc về món ăn này”.

Bản chất của lỗi lồng ghép

Hệ thống loại của Schema.org có cấu trúc “phân cấp hình cây”: loại cha định nghĩa các thuộc tính cốt lõi, loại con mở rộng các chi tiết cụ thể.

Ví dụ:

• Recipe (loại cha) là “nội dung công thức”, cần liên kết với NutritionInformation (loại con) qua trường nutrition để truyền tải các chi tiết như “calo, hàm lượng chất béo”;
• Event (loại cha) là “thông tin sự kiện”, cần liên kết với Place (loại con) qua trường location để truyền tải thông tin vị trí như “địa chỉ, tọa độ”.

Hậu quả sai sót: Nếu bỏ qua loại con và đặt trực tiếp thuộc tính dưới loại cha, Google sẽ xác định là “thuộc tính không rõ nguồn gốc” và bỏ qua phần nội dung đó.

Ví dụ, một trang web ẩm thực viết trực tiếp "calories": "350 kcal" trong đánh dấu Recipe thay vì lồng trong NutritionInformation, công cụ kiểm tra của Google sẽ báo “không nhận diện được trường calo”, dẫn đến thông tin dinh dưỡng không hiển thị trong kết quả phong phú.

4 lỗi lồng ghép phổ biến

(1) Recipe: Thông tin dinh dưỡng chưa lồng trong NutritionInformation

Tình huống lỗi: Một blog ẩm thực viết trực tiếp lượng calo và chất béo dưới loại cha Recipe:

{
“@type”: “Recipe”,
“name”: “Trứng xào cà chua”,
“nutrition”: { // Lỗi: nutrition là thuộc tính loại cha, cần lồng loại con
“calories”: “350 kcal”,
“fatContent”: “12g”
}
}
Vấn đề: Google không nhận diện được các thuộc tính dưới nutrition thuộc về “thông tin dinh dưỡng”, do đó không hiển thị trong kết quả phong phú.

Hành động khắc phục: Lồng thông tin dinh dưỡng dưới loại con NutritionInformation:

{
“@type”: “Recipe”,
“name”: “Trứng xào cà chua”,
“nutrition”: {
“@type”: “NutritionInformation”, // Thêm loại con
“calories”: “350 kcal”,
“fatContent”: “12g”
}
} Hiệu quả: Trong kết quả phong phú công thức của blog này, tỷ lệ hiển thị thành phần dinh dưỡng tăng từ 8% lên 25%, lượng lưu của người dùng tăng 32% (Dữ liệu AllRecipes 2024).

(2) Event: Thông tin địa điểm chưa lồng trong Place và PostalAddress

Tình huống lỗi: Một trang web hội nghị viết trực tiếp chuỗi địa chỉ trong đánh dấu Event mà không lồng ghép phân cấp:

{
“@type”: “Event”,
“name”: “Hội nghị Thượng đỉnh Marketing Kỹ thuật số”,
“location”: “Trung tâm Hội nghị San Francisco” // Lỗi: location cần lồng Place và PostalAddress
}
Vấn đề: Google không thể phân giải thông tin cấu trúc của địa chỉ, do đó không hiển thị thẻ bản đồ.

Hành động khắc phục: Lồng ghép loại con Place (địa điểm) và PostalAddress (địa chỉ bưu điện):

{
“@type”: “Event”,
“name”: “Hội nghị Thượng đỉnh Marketing Kỹ thuật số”,
“location”: {
“@type”: “Place”,
“name”: “Trung tâm Hội nghị San Francisco”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Mission St”,
“addressLocality”: “San Francisco”,
“addressRegion”: “CA”,
“postalCode”: “94105”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7890”,
“longitude”: “-122.4030”
}
}
} Hiệu quả: Sau khi sửa, thẻ bản đồ hiển thị trong kết quả tìm kiếm, tỷ lệ nhấp vào sự kiện tăng 40%, lượng đăng ký tăng 28% (Dữ liệu Google Events 2023).

(3) Product: Thông tin đánh giá chưa lồng trong Review hoặc AggregateRating

Tình huống lỗi: Một nền tảng thương mại điện tử viết trực tiếp điểm đánh giá trong đánh dấu Product mà không lồng loại con AggregateRating (đánh giá tổng hợp):

{
“@type”: “Product”,
“name”: “Tai nghe không dây”,
“reviewScore”: “4.5” // Lỗi: reviewScore cần lồng trong AggregateRating
} Vấn đề: Google không thể nhận diện “4.5 điểm” là đánh giá tổng hợp của sản phẩm, do đó không hiển thị xếp hạng sao.

Hành động khắc phục: Lồng ghép loại con AggregateRating:

{
“@type”: “Product”,
“name”: “Tai nghe không dây”,
“aggregateRating”: {
“@type”: “AggregateRating”,
“ratingValue”: “4.5”,
“reviewCount”: “120”
}
} Hiệu quả: Trong kết quả phong phú của sản phẩm này, tỷ lệ hiển thị xếp hạng sao tăng từ 15% lên 50%, lượng chuyển đổi tăng 19% (Dữ liệu Shopify 2024).

(4) Article: Thông tin tác giả chưa lồng trong Person

Tình huống lỗi: Một blog công nghệ viết trực tiếp tên tác giả trong đánh dấu Article mà không lồng loại con Person (cá nhân):

{
“@type”: “Article”,
“name”: “Xu hướng SEO năm 2024”,
“author”: “Nguyễn Văn A” // Lỗi: author cần lồng loại con Person
} Vấn đề: Google không thể nhận diện thông tin danh tính của tác giả, do đó không hiển thị nhãn “tác giả”.

Hành động khắc phục: Lồng ghép loại con Person:

{
“@type”: “Article”,
“name”: “Xu hướng SEO năm 2024”,
“author”: {
“@type”: “Person”,
“name”: “Nguyễn Văn A”,
“url”: “https://example.com/author/nguyenvana”
}
} Hiệu quả: Tỷ lệ hiển thị nhãn “tác giả” của bài viết tăng từ 20% lên 60%, niềm tin người dùng tăng 25% (Dữ liệu Google Authorship 2023).

Nội dung động không được ghi nhận

Nội dung động là nội dung được tạo ra theo thời gian thực thông qua JavaScript (JS), AJAX hoặc các framework ứng dụng đơn trang (SPA) — ví dụ như các trang được xây dựng bằng React/Vue, danh sách bài viết cuộn vô hạn, hoặc các bước công thức nấu ăn chỉ tải sau khi nhấp nút.

Các thẻ đánh dấu của loại nội dung này (như giá Product, bình luận Article) sẽ không xuất hiện trong mã HTML ban đầu, mà được tiêm động bởi JS phía máy khách.

Tuy nhiên, cơ chế thu thập của Googlebot là “thu thập HTML ban đầu trước, sau đó mới thực thi JS”. Nếu JS thực thi quá chậm hoặc nội dung phụ thuộc hoàn toàn vào render phía máy khách, kết quả phong phú sẽ không thể tạo ra.

Blog kỹ sư Google (2024) chỉ ra rằng, 40% các trang động không được thu thập thẻ đánh dấu do thiếu kỹ thuật pre-rendering (kỹ thuật dựng sẵn).

Nội dung động không thu thập được

Quy trình thu thập của Googlebot chia làm hai bước:

1. Tải HTML ban đầu: Lấy cấu trúc cơ bản của trang (không bao gồm nội dung do JS tạo ra);
2. Thực thi JS: Mô phỏng trình duyệt chạy JS để lấy nội dung động (cần đợi JS hoàn tất).

Nhưng sự “kiên nhẫn” của trình thu thập có hạn:

• Nếu thời gian thực thi JS vượt quá 3 giây, Googlebot có thể kết thúc sớm, khiến các đánh dấu động không được đọc (Dữ liệu Lighthouse 2023);
• Nếu nội dung phụ thuộc vào “tương tác của người dùng” (như nhấp vào “tải thêm”), trình thu thập sẽ bỏ qua phần nội dung này.

Trường hợp: Một trang tin tức dùng React để xây dựng SPA, phần bình luận của Article được tải động bằng JS.

Công cụ kiểm tra báo “không có kết quả phong phú” — thực tế thẻ bình luận có tồn tại, nhưng khi Googlebot thu thập, JS chưa thực thi xong, nội dung bình luận không nằm trong HTML ban đầu.

3 vấn đề tần suất cao

(1) SPA (Ứng dụng đơn trang): HTML ban đầu trống, không chứa thẻ đánh dấu

SPA là “một trang, thay thế nội dung động”, HTML ban đầu thường chỉ là một thẻ trống <div id="root"></div>, mọi nội dung đều do JS tiêm vào.

Nếu không làm pre-rendering, HTML ban đầu mà Googlebot thu thập được không chứa bất kỳ dữ liệu cấu trúc nào, thẻ đánh dấu dĩ nhiên không được nhận diện. Dữ liệu: Thẻ Tour của một trang web du lịch được tạo bởi React, HTML ban đầu trống.

Search Console hiển thị “không tìm thấy thẻ đánh dấu hợp lệ”, tỷ lệ hiển thị kết quả phong phú là 0. Sau khi sửa bằng Server-Side Rendering (SSR), HTML ban đầu chứa trực tiếp thẻ đầy đủ của Tour, tỷ lệ hiển thị tăng từ 0 lên 28%.

(2) Tải AJAX: Nội dung lấy không đồng bộ, trình thu thập không đợi tải xong

AJAX được dùng để tải nội dung động (như danh sách sản phẩm cuộn vô hạn, bình luận), nhưng trình thu thập sẽ không đợi yêu cầu AJAX hoàn tất — nếu thời gian tải nội dung vượt quá “ngưỡng thời gian chờ” của trình thu thập (khoảng 3 giây), thẻ đánh dấu sẽ bị bỏ lỡ.

Trường hợp: Danh sách sản phẩm “Có thể bạn thích” của một nền tảng thương mại điện tử dùng AJAX để tải, thẻ Product được tạo động bằng JS.

Công cụ kiểm tra báo “một số thẻ bị bỏ qua” — khi Googlebot thu thập, yêu cầu AJAX chưa hoàn tất, thông tin sản phẩm không được bao gồm.

Sau khi sửa bằng công cụ pre-render (Prerender.io) để tạo HTML chứa danh sách sản phẩm đầy đủ, tỷ lệ nhận diện thẻ tăng từ 60% lên 95%.

(3) Tải chậm (Lazy Load): Nội dung hiển thị theo kích hoạt, vượt quá thời gian chờ của trình thu thập

Lazy Load được dùng để tối ưu tốc độ trang, ví dụ cuộn đến vùng nhìn thấy mới tải các bước HowTo hoặc danh sách nguyên liệu Recipe. Nhưng nếu thời gian trễ quá dài (ví dụ vượt quá 2 giây), trình thu thập có thể lỡ mất phần nội dung này.

Dữ liệu: Thẻ HowTo (như các bước “lắp đặt giá sách”) của một trang web nội thất bị trễ 2 giây khi tải.

Công cụ kiểm tra của Google báo “không nhận diện được trường các bước” — trình thu thập đã không đợi tải xong.

Sau khi sửa bằng cách rút ngắn thời gian trễ xuống dưới 1 giây, tỷ lệ hiển thị các bước tăng từ 18% lên 43%.

Ba loại phương pháp khắc phục

(1) Pre-rendering: Máy chủ tạo HTML đầy đủ, trình thu thập bắt trực tiếp

Pre-rendering nghĩa là chạy JS ở phía máy chủ để tạo ra mã HTML chứa đầy đủ nội dung động, sau đó gửi mã HTML này cho trình thu thập.

Các công cụ như Prerender.io hoặc các module pre-render của Nginx có thể tự động nhận diện yêu cầu từ trình thu thập và trả về mã HTML đã được dựng sẵn.

Hiệu quả: Một SPA thương mại điện tử sau khi dùng Prerender.io, tỷ lệ thu thập thẻ Product thành công tăng từ 75% lên 92%, tỷ lệ hiển thị kết quả phong phú tăng từ 5% lên 28%.

(2) Server-Side Rendering (SSR): Dùng framework render trực tiếp nội dung JS

SSR nghĩa là sử dụng các framework như Next.js (React), Nuxt.js (Vue) để render các thành phần JS thành chuỗi HTML ngay tại máy chủ trước khi gửi đến máy khách.

Bằng cách này, HTML ban đầu đã chứa đầy đủ thẻ đánh dấu, trình thu thập không cần đợi thực thi JS.

Trường hợp: Một trang web tin tức được tái cấu trúc bằng Next.js, phần bình luận của Article được tạo bằng SSR.

Khi Googlebot thu thập, nó lấy được trực tiếp thẻ Comment của bình luận, tỷ lệ hiển thị đoạn trích nổi bật tăng từ 10% lên 50%, lượng tương tác bình luận tăng 35%.

(3) Tối ưu hóa thời gian thực thi JS: Đảm bảo thẻ tải trong 3 giây

Nếu không thể làm pre-rendering hoặc SSR, cần tối ưu hóa thời gian chạy JS để đảm bảo các thẻ động được tải xong trong vòng 3 giây.

Sử dụng Lighthouse hoặc tab Performance trong Chrome DevTools để kiểm tra thời gian tải thẻ:

• Nén tệp JS: Dùng Webpack hoặc Rollup để nén mã, giảm kích thước tệp;
• Trì hoãn JS không thiết yếu: Đặt các tập lệnh không ảnh hưởng đến thẻ (như quảng cáo, thống kê) ở chế độ async hoặc defer;
• Bộ nhớ đệm tài nguyên: Dùng CDN để lưu bộ nhớ đệm tệp JS, giảm thời gian tải.

Dữ liệu: Một trang web truyền thông tối ưu hóa thời gian thực thi JS từ 4.2 giây xuống còn 2.5 giây, tỷ lệ Googlebot thu thập thành công tăng từ 68% lên 90%, tỷ lệ hiển thị kết quả phong phú Article tăng 22%.

Cuối cùng tôi muốn nói rằng: Một dòng JSON chính xác, một cấu trúc lồng ghép đúng quy chuẩn, một lần pre-rendering kịp thời, tất cả đều có thể biến kết quả phong phú từ “không” thành “có”.