Cách xác thực dữ liệu có cấu trúc mà không dùng công cụ của Google

Việc xác thực dữ liệu có cấu trúc đã trở nên phụ thuộc một cách hơi kỳ lạ vào các công cụ hướng tới Google. Điều đó có thể hiểu được: nhiều đội ngũ thêm JSON-LD vì họ muốn có rich results, và các công cụ kiểm thử của Google thì quen thuộc. Nhưng dữ liệu có cấu trúc không phải là một định dạng của Google. Thông thường, đó là JSON-LD dùng từ vựng Schema.org, được nhúng trong HTML, được nhiều bên tiêu thụ diễn giải, và được duy trì bởi chính quy trình xuất bản của bạn.

Nếu bạn chỉ xác thực qua lăng kính công cụ tìm kiếm, bạn có thể bỏ sót những vấn đề cơ bản: JSON không hợp lệ, dữ liệu biến mất sau khi render, giá sản phẩm lỗi thời, URL canonical mâu thuẫn, hoặc markup hợp lệ về mặt kỹ thuật nhưng vô lý về mặt ngữ nghĩa.

Một quy trình tốt hơn là ưu tiên tiêu chuẩn. Hãy xác thực dữ liệu như dữ liệu, sau đó xác thực từ vựng, rồi xác thực trang như cách nó tồn tại trên production.

Bạn thực sự đang xác thực điều gì?

“Dữ liệu có cấu trúc” không phải là một thứ duy nhất. Trên hầu hết website, nó có bốn lớp:

1. Cú pháp JSON — mã có phân tích cú pháp được không?
2. Mô hình JSON-LD — nó có mở rộng thành dữ liệu liên kết có ý nghĩa không?
3. Từ vựng Schema.org — các kiểu và thuộc tính có hợp lý không?
4. Sự thật ở cấp trang — markup có khớp với những gì người dùng và crawler có thể thấy không?

Các công cụ của Google chủ yếu tập trung vào lớp thứ tư cộng với điều kiện đủ cho rich-result riêng của Google. Hữu ích, đúng. Đầy đủ, không.

Ví dụ, đoạn này có thể là JSON-LD hợp lệ nhưng vẫn là dữ liệu có cấu trúc kém:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Best winter jackets",
  "datePublished": "2026-01-12",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  }
}

Không có gì bị hỏng ở đây. Nhưng nếu trang hiển thị có tiêu đề khác, không có ghi nhận tác giả, và ngày sửa đổi gần nhất mâu thuẫn với markup, thì bạn đang có vấn đề về chất lượng chứ không phải vấn đề cú pháp.

Bước 1: Phân tích cú pháp JSON trước khi nghĩ về SEO

Hãy bắt đầu với bước kiểm tra nhàm chán: JSON có phân tích cú pháp được không?

JSON-LD nhúng trong HTML thường bị hỏng vì những lỗi nhỏ trong template:

• dấu phẩy thừa ở cuối
• dấu ngoặc kép chưa escape trong tên sản phẩm
• xuống dòng không hợp lệ bên trong chuỗi
• thiếu ngoặc nhọn sau các trường có điều kiện
• các script block bị lặp do kế thừa layout
• plugin CMS xuất ra các object không hoàn chỉnh

Để kiểm tra cục bộ, bạn không cần một nền tảng SEO. Hãy dùng các công cụ đã có trong stack phát triển của bạn.

Trong JavaScript:

const blocks = [...document.querySelectorAll('script[type="application/ld+json"]')];

for (const block of blocks) {
  try {
    JSON.parse(block.textContent);
  } catch (error) {
    console.error('Invalid JSON-LD:', error.message, block);
  }
}

Trong CI, hãy trích xuất nội dung script từ HTML đã render và phân tích chúng như JSON. Việc này bắt được nhiều vấn đề trước khi chúng lên production.

Điểm quan trọng: hãy làm việc này trước mọi bước xác thực Schema.org. Một trình xác thực từ vựng không thể giúp gì nếu dữ liệu không phải là JSON hợp lệ.

Bước 2: Kiểm tra hành vi JSON-LD, không chỉ cú pháp JSON

JSON hợp lệ không tự động là JSON-LD hợp lệ. JSON-LD dùng các khái niệm như @context, @type, @id và quan hệ graph. Nếu những phần này sai định dạng, parser có thể diễn giải dữ liệu của bạn khác với ý định của bạn.

Tối thiểu, hãy xác nhận:

• mọi block đều có @context phù hợp
• các thực thể chính có giá trị @type rõ ràng
• các thực thể lặp lại dùng giá trị @id ổn định khi hữu ích
• các thực thể lồng nhau được kết nối một cách logic
• array được dùng khi có thể có nhiều giá trị

Với các site lớn hơn, định danh ổn định đặc biệt hữu ích. Nếu tổ chức của bạn xuất hiện trong dữ liệu Article, Product, BreadcrumbList và FAQPage, việc dùng cùng một @id giúp các bên tiêu thụ hiểu rằng đây là các tham chiếu đến cùng một thực thể, chứ không phải bốn tổ chức không liên quan chỉ trùng tên.

Một mẫu điển hình trông như sau:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/"
}

Ở đây bạn không cố gây ấn tượng với trình xác thực. Bạn đang làm cho dữ liệu của mình ít mơ hồ hơn.

Bước 3: Xác thực theo từ vựng Schema.org

Khi JSON và cấu trúc JSON-LD đã ổn, hãy kiểm tra từ vựng.

Trình xác thực Schema.org hữu ích vì nó kiểm thử theo các thuật ngữ Schema.org thay vì theo quy tắc rich-result của một công cụ tìm kiếm. Nó có thể cho thấy thuộc tính có được nhận diện không, kiểu có được diễn giải như mong đợi không, và các cấu trúc lồng nhau của bạn có hợp lý không.

Đây là nơi bạn bắt các lỗi như:

• publishingDate thay vì datePublished
• imageUrl trong khi cần image
• markup Product trên trang danh mục không phải là một sản phẩm
• AggregateRating không có đối tượng được đánh giá có ý nghĩa
• dùng Person cho một tài khoản thương hiệu

Hãy cẩn thận với cảnh báo. Schema.org được thiết kế linh hoạt. Một trình xác thực có thể cho phép một thuộc tính không hữu ích cho trường hợp sử dụng của bạn, hoặc cảnh báo về thứ vốn là tùy chọn. Hãy xem xác thực là bằng chứng, không phải phán quyết.

Một quy tắc thực tế: nếu một thuộc tính giúp máy hiểu trang chính xác hơn, hãy giữ nó. Nếu nó tồn tại chỉ vì ai đó sao chép từ một snippet generator, hãy đặt câu hỏi.

Bước 4: So sánh markup với nội dung hiển thị

Công cụ tìm kiếm và các bên tiêu thụ dữ liệu khác thường không tin tưởng markup không khớp với trang. Quan trọng hơn, người dùng xứng đáng có sự nhất quán.

Với mỗi loại dữ liệu có cấu trúc, hãy so sánh markup với trang hiển thị:

Article và BlogPosting

Kiểm tra rằng tiêu đề, tác giả, ngày xuất bản, ngày sửa đổi, hình ảnh và nhà xuất bản hiển thị hoặc có thể suy ra một cách hợp lý. Nếu bạn xuất bản nội dung có hỗ trợ từ AI, dữ liệu có cấu trúc của bạn không nên được dùng để che đậy quyền tác giả không rõ ràng. Chúng tôi đã viết riêng về việc tiết lộ AI một cách trung thực trên một website nhỏ, và cùng nguyên tắc đó áp dụng ở đây: metadata nên làm rõ, không phải che mờ.

Product

Kiểm tra tên, giá, tình trạng còn hàng, tiền tệ, biến thể, xếp hạng và số lượng đánh giá. Dữ liệu có cấu trúc cho sản phẩm đặc biệt dễ lỗi thời vì giá và tình trạng tồn kho thay đổi bên ngoài CMS.

LocalBusiness

Kiểm tra tên, địa chỉ, số điện thoại, giờ mở cửa và khu vực phục vụ. Nếu footer của bạn nói một điều còn JSON-LD nói điều khác, JSON-LD không “tốt hơn”. Nó đang mâu thuẫn.

BreadcrumbList

Kiểm tra rằng vị trí breadcrumb khớp với đường dẫn breadcrumb hiển thị và URL là canonical, có thể crawl, và không bị redirect không cần thiết.

Đây không phải là công việc hào nhoáng. Nhưng cũng chính ở đây nhiều vấn đề dữ liệu có cấu trúc được phát hiện.

Bước 5: Xác thực trang đã render, không phải template của bạn

Nhiều site tạo JSON-LD thông qua JavaScript, tag manager, lớp cá nhân hóa, hoặc quá trình hydration component. Điều đó có nghĩa là file template có thể không đại diện cho những gì crawler hoặc trình duyệt thực sự thấy.

Hãy xác thực HTML đã render ở ít nhất ba trạng thái:

• bản build phát triển cục bộ
• URL staging hoặc preview
• URL production

Dùng browser DevTools để kiểm tra DOM cuối cùng. Tìm application/ld+json và sao chép đúng nội dung script tồn tại sau khi render. Nếu markup do server render khác với markup sau hydration, hãy quyết định phiên bản nào bạn kỳ vọng các bên tiêu thụ sẽ đọc.

Cũng kiểm tra xem dữ liệu có cấu trúc có bị lặp không. Các block Article hoặc Product bị lặp khá phổ biến khi một plugin CMS và một component tùy chỉnh cùng xuất schema. Việc lặp không phải lúc nào cũng gây lỗi nghiêm trọng, nhưng lặp với nội dung mâu thuẫn là vấn đề: hai mức giá, hai tác giả, hai ngày xuất bản, hoặc hai URL canonical.

Điều này tương tự việc đọc báo cáo hiệu năng và chẩn đoán: nhiệm vụ đầu tiên không phải là hoảng sợ, mà là tách tín hiệu khỏi nhiễu. Thói quen tương tự cũng hữu ích khi bạn đọc báo cáo Lighthouse mà không hoảng — dù bản thân dữ liệu có cấu trúc không nên bị rút gọn thành một điểm số duy nhất.

Bước 6: Kiểm tra chi tiết truyền tải trên production

Dữ liệu có cấu trúc có thể hoàn hảo trong source của bạn nhưng vẫn thất bại trên production vì trang không truy cập được theo cách bạn giả định.

Kiểm tra:

• status code cuối cùng là 200, không phải soft 404
• URL canonical khớp với trang bạn đang xác thực
• redirect là có chủ đích và ổn định
• robots directives không chặn indexing ở nơi bạn kỳ vọng được index
• HTML không bị thay thế bằng trang lỗi đối với một số user agent
• các trang cache không phục vụ JSON-LD lỗi thời

Đây là nơi việc kiểm tra HTTP trở nên quan trọng. Nếu một trang sản phẩm redirect qua ba URL trước khi đến đích canonical, hãy xác thực trang cuối cùng, không phải URL đầu tiên sao chép từ CMS. Về cơ chế thô, hướng dẫn của chúng tôi về gỡ lỗi redirect và HTTP header trên production là tài liệu đồng hành hữu ích.

Dữ liệu có cấu trúc không tồn tại trong chân không. Nó đi cùng header, redirect, caching, canonical tag và robots directives.

Bước 7: Thêm kiểm thử dữ liệu có cấu trúc vào quy trình release

Xác thực thủ công ổn với một trang. Nó không mở rộng tốt cho hàng trăm hoặc hàng nghìn URL.

Một bộ kiểm thử tự động đơn giản có thể bắt các lỗi tốn kém nhất:

• fetch các URL đại diện từ từng loại template
• trích xuất tất cả block JSON-LD
• phân tích chúng bằng JSON.parse
• assert các trường bắt buộc cho từng loại trang
• kiểm tra rằng ngày tháng là chuỗi ISO 8601 hợp lệ
• kiểm tra rằng URL là tuyệt đối và canonical
• kiểm tra rằng giá và tình trạng còn hàng tồn tại trên trang sản phẩm
• kiểm tra rằng các thực thể lặp không mâu thuẫn

Bạn có thể chạy việc này trong CI cho template và theo lịch cho URL production. Mục tiêu không phải là chứng minh mọi tính năng rich-result sẽ xuất hiện. Không ai ngoài công cụ tìm kiếm có thể hứa điều đó. Mục tiêu là giữ dữ liệu của chính bạn chính xác, phân tích cú pháp được và nhất quán.

<!-- tool-cta:start -->

💡 Hãy thử cách này: Trước khi xác thực logic của schema, hãy chạy JSON-LD của bạn qua JSON Formatter để phát hiện các lỗi cú pháp mà nếu không sẽ làm hỏng mọi lần kiểm tra tiếp theo.

<!-- tool-cta:end -->

Checklist xác thực ưu tiên tiêu chuẩn

Dùng checklist ngắn này trước khi hỏi liệu một công cụ tìm kiếm có thích trang hay không:

• Mọi block JSON-LD có phải là JSON hợp lệ không?
• Mỗi block có bao gồm đúng @context và @type không?
• Các thuộc tính Schema.org có được viết đúng chính tả không?
• Markup có khớp với nội dung hiển thị không?
• Ngày tháng, giá, xếp hạng và tình trạng còn hàng có hiện hành không?
• URL có tuyệt đối, canonical và truy cập được không?
• Trang production đã render có phải là cùng trang bạn đã kiểm thử không?
• Các thực thể lặp có chủ đích và không mâu thuẫn không?

Nếu bạn có thể trả lời có cho các câu hỏi đó, bạn đã làm phần bền vững của công việc dữ liệu có cấu trúc. Kiểm thử riêng cho từng công cụ tìm kiếm vẫn có thể hữu ích về sau, nhưng nó nên là bước kiểm tra tương thích cuối cùng, không phải nền móng của quy trình xác thực.