SEO WordPress #23: Kiểm tra và xác nhận Schema

1. Kiểm tra schema là kiểm những gì?

Kiểm tra schema gồm bốn câu hỏi độc lập, và mỗi câu có một công cụ riêng trả lời: cú pháp có hợp lệ không, loại khai có đủ điều kiện hiện kết quả đặc biệt không, Googlebot có nhận được khối schema đó không, và nó có còn nguyên sau khi cập nhật theme hay plugin không. Bốn câu này không suy ra được từ nhau.

Đây là chỗ sai phổ biến nhất của cả chủ đề: một trang xanh trong Schema Markup Validator vẫn có thể không hiện kết quả đặc biệt nào, và một trang xanh trong Rich Results Test vẫn có thể mất schema trên bản mà Google đã lập chỉ mục. Ba tình huống đó đều đo được, và đều không phải nghịch lý: chúng là ba câu hỏi khác nhau.

Bài #22 về schema cơ bản lo phần khai cái gì và khai cho nhất quán. Bài này lo phần sau đó: chứng minh khối đã khai hợp lệ, tới được Googlebot, được Google đọc ra đúng, và không mất đi sau mỗi lần có người bấm nút cập nhật.

Đầu ra cần có: bảng kết quả bốn công cụ cho từng mẫu trang, ảnh chụp HTML mà Googlebot nhận được, ảnh chụp báo cáo trong Search Console, và một bản gốc để so sau mỗi lần cập nhật. Nền của chủ đề nằm ở mục tra cứu Schema Markup.

2. Checklist Kiểm tra Schema: 10 tiêu chí từ 194 đến 203

Mười tiêu chí dưới đây xếp theo đúng dòng thời gian của một lần triển khai: bốn tiêu chí kiểm trước khi lên, hai tiêu chí kiểm lúc lên, và bốn tiêu chí giám sát sau khi lên. Đọc theo thứ tự đó thì rõ vì sao tiêu chí 200 nằm sau tiêu chí 199 mà lại phải làm trước.

Sáu tiêu chí Bắt buộc chia thành hai nhóm khác hẳn nhau về hậu quả. Nhóm 194, 195, 196 và 198 là lỗi kỹ thuật: khai sai thì không được hiện kết quả đặc biệt, hết. Nhóm 199 là lỗi vô hình: khai đúng nhưng Googlebot không nhận được, nên mọi công cụ khác vẫn xanh. Còn 202 là nhóm chính sách, tức hậu quả nặng nhất và không sửa được bằng kỹ thuật.

Một điểm về thứ tự làm: tiêu chí 200 xếp thứ chín trong bảng nhưng phải làm TRƯỚC khi triển khai lên toàn website. Xếp nó ở đây theo nhóm logic, chứ không theo thứ tự thao tác.

3. Tiêu chí 194: Rich Results Test không có lỗi nghiêm trọng

Rich Results Test kiểm xem những loại schema Google hỗ trợ trên trang có đủ điều kiện hiện kết quả đặc biệt không, và mọi lỗi nghiêm trọng phải được sửa hết. Cảnh báo thì khác: chúng không chặn kết quả đặc biệt, nhưng phải được xem xét từng cái vì chúng thường là trường khuyến nghị đang thiếu.

Công cụ có hai chế độ và chúng trả lời hai câu khác nhau. Chế độ URL lấy trang sống rồi render như Googlebot, nên nó kiểm được cả phần schema do JavaScript chèn. Chế độ dán mã chỉ kiểm đúng đoạn đã dán, nên nó dùng để thử một khối trước khi đưa lên, không dùng để kết luận về trang thật.

Phân biệt lỗi với cảnh báo là phần quan trọng nhất khi đọc kết quả. Lỗi nghĩa là item đó không đủ điều kiện, tức khai như không khai. Cảnh báo nghĩa là item vẫn đủ điều kiện nhưng thiếu một trường khuyến nghị, và kết quả hiện ra sẽ ít thông tin hơn. Vì vậy thứ tự xử lý là sửa hết lỗi trước, rồi mới lần lượt xét cảnh báo theo mức hữu ích.

Nhắc lại một điều đã nói ở bài trước vì nó bị hiểu sai nhiều nhất: thông báo không tìm thấy loại nào đủ điều kiện KHÔNG phải lỗi, nếu trang chỉ khai những loại Google không dùng cho kết quả đặc biệt. Điều kiện nghiệm thu: 0 lỗi nghiêm trọng trên mọi mẫu trang, và mỗi cảnh báo còn lại đều có một quyết định đã ghi lại là sửa hay bỏ qua.

4. Tiêu chí 195: Schema Markup Validator không có lỗi

Schema Markup Validator kiểm cú pháp và từ vựng của schema.org một cách tổng quát, không giới hạn theo những loại Google dùng. Đây là công cụ trả lời câu khai có hợp lệ không, và nó là công cụ duy nhất đọc được toàn bộ đồ thị kể cả những node Google chưa có kết quả đặc biệt nào.

Cần nói rõ điều ngược lại để không kết luận sai: kết quả hợp lệ ở đây KHÔNG đồng nghĩa trang đủ điều kiện hiện kết quả đặc biệt trên Google. Hai công cụ không xếp trên dưới nhau, chúng đo hai thứ. Một đồ thị hợp lệ hoàn toàn vẫn có thể không đủ điều kiện vì thiếu một trường mà chỉ tài liệu của Google đòi.

Ba dạng lỗi công cụ này bắt được mà Rich Results Test bỏ qua: tên thuộc tính viết sai chính tả nên không thuộc từ vựng schema.org; kiểu dữ liệu sai, ví dụ đưa chuỗi vào chỗ cần số; và thuộc tính dùng cho một loại không hỗ trợ nó. Cả ba đều là lỗi thật nhưng nằm ngoài phạm vi Rich Results Test.

Dùng kèm JSON-LD Playground cho một việc mà cả hai công cụ trên không làm: xem dạng đã làm phẳng để kiểm mọi tham chiếu @id có trỏ đúng đích trong cùng graph. Một tham chiếu trỏ vào @id không tồn tại là đồ thị vẫn hợp lệ về cú pháp nhưng đứt về quan hệ. Điều kiện nghiệm thu: 0 lỗi trong Validator, và mọi tham chiếu @id đều có đích.

5. Tiêu chí 196: Không dùng data-vocabulary cũ

Không còn markup theo data-vocabulary.org trên website, vì Google đã ngừng hỗ trợ từ vựng đó cho kết quả đặc biệt từ tháng 4 năm 2020. Đây là tiêu chí rẻ nhất và dễ kiểm nhất trong cả bài: một lệnh tìm chuỗi là xong, nhưng nếu còn thì kết quả đặc biệt tương ứng đã mất từ nhiều năm.

Chỗ còn sót gần như luôn là breadcrumb của theme cũ. Trước năm 2020, rất nhiều theme WordPress in breadcrumb kèm thuộc tính itemtype trỏ về data-vocabulary.org, và đoạn mã đó nằm trong tệp theme nên nó sống sót qua mọi lần cập nhật plugin. Công bố của Google ghi rõ mốc ngừng hỗ trợ.

curl -sS https://ten-mien.com/duong-dan/ | grep -c "data-vocabulary.org"

Cách kiểm toàn website: crawl rồi tìm chuỗi data-vocabulary trong mã nguồn. Nếu còn, cách xử lý đúng không phải chuyển đổi từng dòng mà là tắt phần breadcrumb của theme rồi dùng breadcrumb do plugin SEO sinh, vì plugin sinh cả phần hiển thị lẫn phần JSON-LD từ cùng một nguồn.

Điều kiện nghiệm thu: 0 lần xuất hiện chuỗi data-vocabulary trên toàn website, và breadcrumb đang dùng từ vựng schema.org.

6. Tiêu chí 197: Ưu tiên JSON-LD

Nên ưu tiên JSON-LD khi hệ thống cho phép, nhưng cần nói đúng mức: Google vẫn chấp nhận Microdata và RDFa, nên đây là khuyến nghị về triển khai và bảo trì chứ không phải điều kiện bắt buộc. Microdata đang chạy tốt thì không phải lỗi, và đổi nó chỉ để đổi là công việc không có người nhận kết quả.

Lý do nên ưu tiên nằm ở chỗ bảo trì. JSON-LD là một khối dữ liệu tách khỏi HTML, nên sửa nó không đụng vào giao diện, và đọc nó không phải lần theo các thuộc tính rải trong thân trang. Microdata thì ngược lại: dữ liệu nằm trong chính các thẻ hiển thị, nên một lần đổi bố cục là một lần có thể làm đứt markup mà không ai thấy.

Hệ quả thực tế trên WordPress: với Microdata, mỗi lần cập nhật theme hoặc đổi template là một lần phải kiểm lại schema, vì markup nằm trong phần vừa bị thay. Với JSON-LD, khối dữ liệu do plugin sinh nên nó độc lập với bố cục. Đó chính là lý do tiêu chí 203 về kiểm hồi quy có ích hơn hẳn với website còn dùng Microdata.

Khi nào chấp nhận giữ Microdata: khi nó đang đúng, đang đủ trường, và việc chuyển đổi phải sửa vào theme mà không ai bảo trì. Lúc đó hãy ghi lại quyết định và đưa website vào nhóm cần kiểm hồi quy chặt hơn. Tài liệu gốc về ba định dạng nằm ở trang giới thiệu dữ liệu có cấu trúc của Google. Điều kiện nghiệm thu: website mới dùng JSON-LD; website cũ còn Microdata thì có quyết định đã ghi và có lịch kiểm hồi quy.

7. Tiêu chí 198: Đủ thuộc tính bắt buộc

Mỗi loại kết quả đặc biệt có danh sách thuộc tính bắt buộc riêng trong tài liệu của Google, và thiếu một trường bắt buộc là item đó không đủ điều kiện. Các thuộc tính khuyến nghị thì không chặn, nhưng bổ sung chúng thường làm kết quả hiện ra nhiều thông tin hơn.

Chỗ cần cẩn thận: danh sách bắt buộc của Google KHÔNG giống danh sách thuộc tính của schema.org. Từ vựng schema.org hầu như không có trường nào bắt buộc, nên Validator sẽ báo hợp lệ trong khi Google vẫn coi là thiếu. Vì vậy nguồn duy nhất để đối chiếu tiêu chí này là thư viện kết quả đặc biệt, mở đúng trang của loại đang khai.

Cách làm gọn: mở tài liệu của loại đó, chép danh sách bắt buộc và khuyến nghị thành một bảng hai cột, rồi đối chiếu với khối JSON-LD thật của một mẫu trang. Làm một lần cho mỗi loại, không làm lại cho mỗi URL, vì schema do template sinh nên thiếu trường là thiếu trên toàn nhóm trang.

Một dạng thiếu đặc biệt hay gặp và đáng nói riêng: trường có mặt nhưng giá trị rỗng hoặc là chuỗi giữ chỗ do plugin để lại. Công cụ thấy trường tồn tại nên không báo thiếu, còn Google đọc ra một giá trị không dùng được. Điều kiện nghiệm thu: mọi loại đang khai đều đủ trường bắt buộc theo tài liệu Google, và không trường nào mang giá trị rỗng hay giữ chỗ.

8. Tiêu chí 199: Schema có trong HTML Google render

Schema phải có mặt trong HTML mà Googlebot thật sự nhận được sau khi render, chứ không chỉ có trong mã nguồn khi anh chị mở trang bằng trình duyệt của mình. Đây là tiêu chí vô hình nhất của cả bài: khai đúng, hợp lệ, đủ trường, mọi công cụ xanh, mà Google vẫn không nhận được gì.

Năm nguyên nhân làm khối schema không tới được Googlebot, tất cả đều đo được: một tệp JavaScript sinh ra schema bị robots.txt chặn nên lúc render không có gì để chạy; trang có thẻ noindex nên nó không vào chỉ mục và kết quả đặc biệt thành vô nghĩa; nội dung nằm sau đăng nhập; một lỗi JavaScript làm đoạn chèn schema dừng giữa đường; và bản cache đang phục vụ là bản cũ chưa có khối mới.

Cách kiểm đúng dùng hai công cụ theo thứ tự. Trước, dùng Kiểm tra URL trong Search Console và đọc tab HTML đã thu thập: đó là HTML mà Google đang có. Sau, bấm Kiểm tra URL trực tiếp để lấy bản mới nhất và đọc cả phần thông báo lỗi JavaScript cùng danh sách tài nguyên bị chặn. Hai bản này khác nhau là dấu hiệu rõ nhất của vấn đề cache hoặc vấn đề render.

Nguyên tắc rút ra từ đây, và nó đáng viết vào quy trình: nếu hệ thống cho phép, hãy in schema ở phía máy chủ thay vì chèn bằng JavaScript. Khối in sẵn trong HTML không phụ thuộc render, không phụ thuộc tài nguyên bị chặn, và không phụ thuộc một lỗi script ở nơi khác trên trang. Điều kiện nghiệm thu: HTML đã thu thập trong Search Console chứa đúng khối schema mong đợi, và không tài nguyên nào cần cho nó bị chặn.

9. Tiêu chí 200: Kiểm thử URL đại diện trước triển khai

Trước khi áp schema cho toàn website, phải thử trên một URL đại diện cho từng mẫu trang, vì schema do template sinh nên một lỗi trên một mẫu là một lỗi nhân lên bằng số trang dùng mẫu đó. Chọn đúng danh sách mẫu là phần quyết định chất lượng của cả lượt kiểm, và cũng là phần hay bị làm tắt.

Danh sách mẫu tối thiểu cho một website WordPress: trang chủ, trang danh mục hoặc lưu trữ, bài viết đơn, trang tĩnh, trang liên hệ, và trang của loại nội dung đặc biệt nếu có như sản phẩm, dịch vụ hay khóa học. Thêm hai mẫu hay bị bỏ mà lại dễ sai: trang phân trang từ thứ hai, và trang kết quả tìm kiếm nội bộ.

Thử ở đâu: trên staging nếu có, vì lúc đó sửa được trước khi ai thấy. Không có staging thì thử bằng chế độ dán mã của Rich Results Test cho khối dự kiến, rồi triển khai cho một mẫu duy nhất, kiểm lại bằng chế độ URL, rồi mới mở rộng. Cách thứ hai chậm hơn nhưng vẫn giữ được tính chất quan trọng nhất: phát hiện lỗi khi nó còn ở một trang.

Lưu kết quả của lượt này làm BẢN GỐC. Đó chính là thứ tiêu chí 203 sẽ đem ra so sau mỗi lần cập nhật, và không có bản gốc thì câu hỏi nó có bị mất gì không sẽ không có cách trả lời. Điều kiện nghiệm thu: mỗi mẫu trang có một URL đã thử và một khối JSON-LD đã lưu, trước khi schema được bật cho phần còn lại.

10. Tiêu chí 201: Theo dõi báo cáo Rich result

Sau khi Google lập chỉ mục, phải theo dõi số item hợp lệ và không hợp lệ trong báo cáo kết quả đặc biệt của Search Console, sửa lỗi, kiểm lại URL trực tiếp rồi gửi yêu cầu xác thực lại. Đây là phép kiểm duy nhất nói được Google đang thấy gì trên toàn bộ URL đã thu thập, thay vì trên trang vừa thử.

Ba điểm cần biết để đọc báo cáo cho đúng. Thứ nhất, báo cáo chỉ xuất hiện khi Google đã phát hiện loại tương ứng, nên một loại vừa khai xong mà chưa thấy báo cáo không phải lỗi. Thứ hai, dữ liệu chạy theo lượt thu thập nên nó trễ vài ngày tới vài tuần. Thứ ba, trạng thái chia ba mức: hợp lệ, hợp lệ kèm cảnh báo, và không hợp lệ, trong đó mức giữa vẫn đủ điều kiện hiện.

Luồng sửa lỗi có một bước hay bị bỏ: sau khi sửa, phải bấm xác thực lại trong chính báo cáo đó. Google sẽ thu thập lại một tập mẫu rồi trả kết quả đạt hay không đạt, và quá trình này mất từ vài ngày tới vài tuần. Không bấm thì lỗi vẫn nằm đó tới lượt thu thập tự nhiên kế tiếp.

Hệ quả về cách dùng: đừng dùng báo cáo này làm phép kiểm ngay sau khi triển khai, vì nó trễ. Dùng Rich Results Test cho phần ngay, dùng báo cáo Search Console cho phần theo dõi. Tài liệu gốc nằm ở trang tổng quan báo cáo kết quả đặc biệt. Điều kiện nghiệm thu: mỗi loại đang khai có một báo cáo đang theo dõi, 0 item không hợp lệ, và mọi lần sửa đều đã gửi xác thực lại.

11. Tiêu chí 202: Không có Manual Action về Structured Data

Báo cáo Tác vụ thủ công trong Search Console không được có tác vụ về markup dữ liệu có cấu trúc dạng spam, và nếu có thì phải sửa nguyên nhân rồi gửi yêu cầu xem xét lại. Đây là tiêu chí duy nhất trong bài thuộc nhóm chính sách, nên hậu quả của nó khác hẳn chín tiêu chí còn lại.

Khác biệt cần nắm: chín tiêu chí kia là lỗi kỹ thuật, sai thì không được hiện kết quả đặc biệt, hết. Tác vụ thủ công thì là một quyết định của người xét, và nó có thể ảnh hưởng tới cả phần hiển thị thông thường của trang hoặc của website, không chỉ phần kết quả đặc biệt.

Nguyên nhân dẫn tới tác vụ này gần như luôn thuộc một trong ba dạng, và cả ba đều là vi phạm tiêu chí 192 ở bài trước: khai nội dung không hiện trên trang; khai loại không liên quan tới nội dung thật của trang; và khai thông tin gây hiểu nhầm như đánh giá không có thật hay giá không đúng. Nói cách khác, tiêu chí này là hậu quả, còn nguyên nhân nằm ở bài #22.

Cách xử lý khi có: đọc đúng phạm vi tác vụ là toàn website hay một nhóm trang, sửa hết nguyên nhân theo chính sách dữ liệu có cấu trúc, rồi gửi yêu cầu xem xét lại kèm mô tả đã sửa gì. Chỉ gửi khi đã chắc, vì một lần gửi khi chưa dọn sạch làm chậm toàn bộ tiến trình. Tài liệu gốc: báo cáo Tác vụ thủ công. Điều kiện nghiệm thu: báo cáo trống, và có một lượt kiểm định kỳ đọc lại nó.

12. Tiêu chí 203: Kiểm thử hồi quy sau cập nhật

Sau mỗi lần cập nhật theme, plugin SEO, plugin thương mại điện tử, plugin cache hoặc template, phải kiểm lại các URL đại diện để phát hiện schema bị mất, bị trùng hoặc bị sai. Lý do rất đơn giản và cũng là điều dễ bỏ qua nhất: schema là thứ do plugin sinh, nên nó đổi theo plugin mà không ai sửa một chữ nào trong nội dung.

Bốn dạng hồi quy đã đo được trong thực tế. Mất hẳn: bản cập nhật đổi tên một tùy chọn nên cấu hình schema quay về mặc định tắt. Trùng: bản cập nhật của theme bật lại phần schema riêng của nó, nên trang có hai Organization. Sai: một trường đổi nguồn dữ liệu nên giá trị lấy từ chỗ khác. Và cũ: plugin cache đang phục vụ bản HTML cũ chưa có khối mới.

Quy trình tối thiểu sau mỗi lần cập nhật, mất chừng năm phút: mở một URL đại diện của mẫu quan trọng nhất, đọc số node của từng thực thể, so với bản gốc đã lưu ở tiêu chí 200. Với cập nhật lớn thì crawl lại toàn website và so số lượng, vì có dạng hồi quy chỉ xuất hiện ở một nhóm trang.

Gắn phép kiểm này vào ngay quy trình cập nhật, không để thành một việc riêng. Cụ thể: thêm một dòng vào danh sách việc sau khi cập nhật, cùng chỗ với việc xóa cache và việc kiểm trang chủ. Điều kiện nghiệm thu: mỗi lần cập nhật đều có một dòng ghi lại đã kiểm mẫu nào và kết quả so với bản gốc.

13. Bốn công cụ trả lời bốn câu hỏi khác nhau

Bốn công cụ trong bài không xếp trên dưới nhau và không thay thế nhau, vì mỗi công cụ chỉ nhìn được một phần, nên dùng sai công cụ là nhận một kết luận không liên quan tới câu đang hỏi. Bảng dưới đây là cách phân vai ngắn nhất để nhớ.

Hai chế độ của Rich Results Test cũng cần phân biệt, vì đây là chỗ hay nhầm nhất. Chế độ URL lấy trang sống và render, nên nó trả lời về trang thật. Chế độ dán mã chỉ đọc đúng đoạn đã dán, nên nó trả lời về một khối, không trả lời về trang. Kiểm một khối dự kiến thì dùng chế độ hai; kết luận về trang đang chạy thì bắt buộc dùng chế độ một.

Với Search Console cũng có hai thứ dễ lẫn: bản đã lập chỉ mục và bản kiểm trực tiếp. Bản đã lập chỉ mục là thứ Google đang có, có thể cũ vài tuần. Bản kiểm trực tiếp là thứ Google lấy ngay lúc bấm. So hai bản với nhau là cách phát hiện vấn đề cache, và không công cụ nào khác làm được việc đó.

Còn một công cụ thứ năm không nằm trong bốn cái trên nhưng cần cho hai tiêu chí 196 và 203: một crawler. Chỉ crawler mới trả lời được câu trên toàn website có bao nhiêu trang còn data-vocabulary và bao nhiêu trang có hai node Organization.

14. Lỗi, cảnh báo, và thứ không phải lỗi

Đọc kết quả kiểm schema cần phân ba mức, và mức thứ ba là mức gây mất thời gian nhiều nhất: những thông báo trông như lỗi mà thật ra không phải lỗi. Biết phân ba mức giúp một lượt kiểm kết thúc bằng danh sách việc thật thay vì một danh sách dài không ai xử lý hết.

Mức một, lỗi nghiêm trọng: thiếu trường bắt buộc, kiểu dữ liệu sai, cú pháp JSON sai. Hậu quả rõ ràng là item không đủ điều kiện. Đây là nhóm phải sửa hết và sửa trước.

Mức hai, cảnh báo: thiếu trường khuyến nghị. Item vẫn đủ điều kiện, nhưng kết quả hiện ra ít thông tin hơn. Nhóm này cần một quyết định cho từng cái, và quyết định bỏ qua cũng là một quyết định hợp lệ miễn là nó được ghi lại. Bỏ qua vì không đọc thì khác bỏ qua vì đã cân nhắc.

Mức ba, không phải lỗi, và đây là ba thông báo hay bị xử lý oan. Một, Rich Results Test báo không tìm thấy loại nào đủ điều kiện: đúng, khi trang chỉ khai những node Google không dùng cho kết quả đặc biệt. Hai, Validator báo hợp lệ mà Rich Results Test vẫn thiếu trường: đúng, vì danh sách bắt buộc của Google không phải danh sách của schema.org. Ba, Search Console chưa có báo cáo cho loại vừa khai: đúng, vì báo cáo chỉ xuất hiện sau khi Google phát hiện loại đó.

15. Đọc báo cáo Search Console cho đúng

Báo cáo trong Search Console là nguồn duy nhất nói Google đang thấy gì, nhưng nó có ba tính chất làm người đọc kết luận sai nếu không biết trước: nó trễ, nó theo mẫu, và nó chỉ hiện những loại đã được phát hiện. Biết ba tính chất đó đổi hẳn cách dùng báo cáo.

Về độ trễ: dữ liệu chạy theo lượt thu thập nên một thay đổi hôm nay thường mất vài ngày tới vài tuần mới hiện. Hệ quả cho quy trình là đừng đo hiệu quả của một lần triển khai bằng báo cáo này trong tuần đầu. Dùng nó để trả lời câu tình trạng đang thế nào, đừng dùng để trả lời câu vừa sửa có ăn không.

Về tính mẫu: số item trong báo cáo là số trên những URL Google đã thu thập, không phải trên toàn bộ URL website có. Vì vậy khi con số thấp hơn số trang mong đợi, câu hỏi đầu tiên không phải schema sai ở đâu, mà là Google đã thu thập bao nhiêu trang trong nhóm đó.

Về luồng xác thực: sau khi sửa, bấm xác thực lại, Google thu thập một tập mẫu rồi trả về đạt hay không đạt. Nếu không đạt, báo cáo chỉ ra URL mẫu còn lỗi, và đó là chỗ nên bắt đầu điều tra thay vì kiểm lại từ đầu. Cách đọc các báo cáo khác của Search Console nằm ở mục tra cứu Google Search Console Technical.

16. Kiểm hồi quy trên toàn website bằng crawl

Kiểm từng URL bằng công cụ trực tiếp trả lời được câu trang này đúng không, nhưng chỉ một lượt crawl trả lời được câu toàn website có nhất quán không, và ba dạng lỗi chỉ lộ ra ở câu thứ hai. Ba dạng đó là schema mất ở một nhóm trang, node trùng ở một nhóm trang, và URL trong đồ thị lệch canonical.

Cách làm: bật phần trích xuất dữ liệu có cấu trúc trong crawler, crawl toàn website, rồi xuất ra ba con số cho mỗi nhóm URL: số trang có khối JSON-LD, số node của từng loại thực thể, và số trang còn chuỗi data-vocabulary. Ba con số này là bản gốc để so cho mọi lần sau.

Phép so quan trọng nhất không phải so với một chuẩn tuyệt đối mà là so với chính website ở lần crawl trước. Một website có 1.200 trang mà số node WebPage đột ngột còn 400 là dấu hiệu rõ, dù 400 vẫn là một con số hợp lệ. Vì vậy hãy lưu bản xuất của mỗi lượt, đừng chỉ lưu kết luận.

Lịch chạy: sau mỗi lần cập nhật lớn, và định kỳ theo tháng. Gắn nó vào cùng lượt kiểm với các phép kiểm toàn website khác để giảm số lần phải khởi động một lượt crawl, vì crawl là việc tốn thời gian nhất trong cả bài.

17. Quan hệ thật giữa kiểm schema và SEO

Việc kiểm schema không tự làm tăng hạng, nó chỉ đảm bảo phần schema đã khai thật sự đang hoạt động, và quan hệ thật với SEO nằm ở chỗ ngăn ba loại mất mát. Ba loại này đều đo được và đều xảy ra âm thầm, nên chúng là lý do đủ để đặt một quy trình kiểm.

Mất mát thứ nhất, phần hiển thị: một lỗi nghiêm trọng làm item không đủ điều kiện, nên kết quả tìm kiếm mất phần thông tin thêm. Ảnh hưởng đi qua tỉ lệ nhấp, không đi qua vị trí, nên khi báo cáo hãy đo tỉ lệ nhấp của nhóm trang đó.

Mất mát thứ hai, và đây là loại tệ nhất vì không ai biết: schema khai đúng mà Googlebot không nhận được. Mọi công cụ đều xanh, báo cáo thì chưa có vì Google chưa phát hiện loại nào, nên trạng thái này có thể kéo dài nhiều tháng. Đó chính là lý do tiêu chí 199 mang trọng số Bắt buộc dù nó không phải một lỗi cú pháp nào.

Mất mát thứ ba, phần chính sách: markup mô tả thứ không có trên trang dẫn tới tác vụ thủ công, và hậu quả của nó vượt ra ngoài phần kết quả đặc biệt. Đây là loại duy nhất trong ba loại có thể làm website mất nhiều hơn thứ nó đang cố giành thêm. Cách nói đúng với chủ website vì vậy là: kiểm schema không mua hạng, nó xác nhận phần đã khai đang chạy và giữ website khỏi ba loại mất mát trên.

18. Quy trình nghiệm thu: trước, ngay sau, và định kỳ

Mười tiêu chí của bài rơi vào ba thời điểm khác nhau, nên quy trình nghiệm thu cũng phải chia ba chứ không gộp thành một lượt kiểm duy nhất. Gộp lại là lý do phần giám sát dài hạn hay bị bỏ, vì nó không có chỗ trong một lượt đã kết thúc.

Trước khi triển khai, làm bốn việc theo thứ tự: chốt danh sách mẫu trang; kiểm khối dự kiến bằng chế độ dán mã của Rich Results Test và bằng Validator; đối chiếu danh sách trường bắt buộc theo tài liệu Google; và lưu khối JSON-LD của từng mẫu làm bản gốc. Đây là các tiêu chí 194, 195, 197, 198 và 200.

Ngay sau khi triển khai, làm hai việc trong cùng ngày: chạy Rich Results Test chế độ URL cho từng mẫu, và đọc HTML đã thu thập cùng bản kiểm trực tiếp trong Search Console để xác nhận Googlebot nhận được. Đây là các tiêu chí 194 và 199, và đây cũng là hai việc không thể hoãn, vì nếu sai thì càng chờ càng nhiều trang bị thu thập ở trạng thái sai.

Định kỳ, làm ba việc: đọc báo cáo kết quả đặc biệt và xử lý item không hợp lệ theo tháng; đọc báo cáo Tác vụ thủ công theo tháng; và chạy kiểm hồi quy sau mỗi lần cập nhật cộng một lượt crawl theo tháng. Đây là các tiêu chí 196, 201, 202 và 203.

Một lưu ý về cách ghi kết quả: lưu bản xuất chứ đừng lưu kết luận. Câu tháng trước có 1.200 node WebPage chỉ trả lời được khi còn bản xuất của tháng trước, còn câu tháng trước mọi thứ ổn thì không trả lời được gì.

19. Công cụ Novaverb, tài liệu gốc và hướng thực hành

Năm công cụ cho nhóm kiểm schema nên dùng theo thứ tự từ trang đang phát ra cái gì, tới hợp lệ không, tới đủ điều kiện gì, tới Googlebot nhận được không, tới Google đang thấy gì. Thứ tự đó cũng đúng là thứ tự của một lần triển khai nên dễ nhớ. Phần tài liệu gốc bên dưới là nơi tra trường bắt buộc, còn phần hướng thực hành là cách tự chạy đủ năm công cụ trên website của mình.

• Meta Tag và Schema Presence Checker của Novaverb: rà nhanh một URL đang phát ra thẻ meta và dữ liệu có cấu trúc nào, dùng làm bước đầu để biết có gì trước khi kiểm sâu.
• Schema Markup Validator: cú pháp và từ vựng schema.org, không giới hạn theo loại Google dùng.
• Rich Results Test: phần đủ điều kiện hiện kết quả đặc biệt; nhớ phân biệt chế độ URL với chế độ dán mã.
• JSON-LD Playground: dạng đã làm phẳng, để kiểm tham chiếu @id có đích.
• Google Search Console: Kiểm tra URL cho tiêu chí 199, báo cáo kết quả đặc biệt cho 201, báo cáo Tác vụ thủ công cho 202.

Tài liệu nên giữ trong hồ sơ dự án: thư viện kết quả đặc biệt để tra trường bắt buộc, tổng quan báo cáo kết quả đặc biệt, báo cáo Tác vụ thủ công và chính sách dữ liệu có cấu trúc. Dùng tài liệu gốc để phân biệt yêu cầu của Google với từ vựng của schema.org, vì đó đúng là chỗ tiêu chí 195 và 198 tách nhau.

Nếu đang tìm lộ trình đào tạo SEO, có thể dùng checklist này làm bài thực hành: chọn ba mẫu trang, chạy đủ năm công cụ, lưu bản gốc rồi cập nhật một plugin và kiểm lại. Trang khóa học SEO giúp đối chiếu chương trình theo nền tảng hiện tại.

Muốn đưa audit schema vào quy trình SEO trên website thật, anh chị có thể xem phạm vi và cách học của khóa học SEO Master. Giá trị của bài thực hành nằm ở khả năng giải thích lỗi và chứng minh đã sửa bằng cùng một phép kiểm.

Kết hợp bài này với schema cơ bản cùng mục tra cứu Rich Snippets và Features: một bài lo phần khai, một bài lo phần chứng minh nó đang chạy.

20. Câu hỏi thường gặp và kết luận

Các câu trả lời dưới đây giúp phân biệt phạm vi của từng công cụ kiểm schema và bằng chứng nghiệm thu trong WordPress. Khi gặp một kết quả không rõ, hãy hỏi lại mình đang cần trả lời câu nào trong bốn câu ở mục 1, rồi mở đúng công cụ trả lời câu đó.

Validator xanh mà Rich Results Test báo thiếu trường là sao?

Cả hai đều đúng. Schema Markup Validator kiểm từ vựng schema.org, nơi hầu như không có trường nào bắt buộc. Rich Results Test kiểm theo danh sách bắt buộc riêng của Google cho từng loại kết quả đặc biệt. Hai danh sách khác nhau, nên hợp lệ không đồng nghĩa đủ điều kiện.

Rich Results Test xanh mà Google không hiện gì thì sao?

Đủ điều kiện không phải bảo đảm được hiện. Google quyết định hiện hay không theo từng truy vấn. Ngoài ra hãy kiểm ba thứ khác: trang đã được lập chỉ mục chưa, HTML Google đã thu thập có chứa khối schema không, và loại đó còn được Google dùng không.

Schema chèn bằng JavaScript có được không?

Được, nhưng nên tránh nếu hệ thống cho phép in ở phía máy chủ. Khối chèn bằng JavaScript phụ thuộc render, nên nó mất khi tệp script bị robots.txt chặn, khi có lỗi script ở nơi khác trên trang, hoặc khi bản cache cũ đang được phục vụ.

Còn data-vocabulary thì có sao không?

Có. Google đã ngừng hỗ trợ từ vựng đó cho kết quả đặc biệt từ tháng 4 năm 2020, nên markup đó không còn tác dụng gì. Chỗ còn sót gần như luôn là breadcrumb của theme cũ; cách xử lý là tắt breadcrumb của theme và dùng bản do plugin SEO sinh.

Microdata có phải đổi sang JSON-LD không?

Không bắt buộc. Google vẫn chấp nhận Microdata và RDFa, nên đây là khuyến nghị về bảo trì. Microdata đang đúng và đủ trường thì giữ được, chỉ cần ghi lại quyết định và kiểm hồi quy chặt hơn, vì markup nằm trong chính các thẻ hiển thị.

Bao lâu thì báo cáo trong Search Console cập nhật?

Vài ngày tới vài tuần, vì dữ liệu chạy theo lượt thu thập. Vì vậy đừng dùng báo cáo đó làm phép kiểm ngay sau khi triển khai. Dùng Rich Results Test cho phần ngay, dùng báo cáo cho phần theo dõi, và nhớ bấm xác thực lại sau khi sửa.

Kiểm bao nhiêu URL là đủ?

Một URL cho mỗi mẫu trang, không phải một tỉ lệ phần trăm của tổng số trang. Schema do template sinh nên lỗi nằm ở mẫu, không nằm ở từng URL. Danh sách tối thiểu gồm trang chủ, trang danh mục, bài đơn, trang tĩnh, trang phân trang và loại nội dung đặc biệt nếu có.

Sau khi cập nhật plugin có cần kiểm lại không?

Cần, và đây là việc hay bị bỏ nhất. Schema do plugin sinh nên nó đổi theo plugin dù không ai sửa nội dung. Bốn dạng hồi quy đã gặp là mất hẳn, trùng node, sai giá trị và bản cache cũ. Một lượt kiểm mẫu quan trọng nhất mất chừng năm phút.

Kết luận: kiểm schema là trả lời bốn câu hỏi độc lập bằng bốn công cụ khác nhau, rồi lặp lại câu thứ tư sau mỗi lần cập nhật. Chạy đủ mười tiêu chí 194-203 theo ba thời điểm trước, ngay sau và định kỳ, lưu bản xuất thay vì lưu kết luận, giúp SEO WordPress chứng minh được phần schema đã khai đang thật sự hoạt động chứ chỉ trông như đang hoạt động.

Schema đúng giúp máy đọc được dữ kiện của trang, còn phần người đọc có tin trang hay không thuộc về bài kế tiếp trong chuỗi: SEO WordPress #24 về E-E-A-T, gồm danh tính tác giả, nguồn dẫn kiểm chứng được và chuẩn YMYL.