Dữ liệu có cấu trúc2026-06-24·10 phút đọc·Ban biên tập KKpower GEO

Hướng dẫn triển khai dữ liệu có cấu trúc Schema.org (JSON-LD): giúp AI và Google hiểu website của bạn

Các engine AI và Google không "đọc" trang web của bạn mà "phân tích cú pháp" (parse) nó. Một khối dữ liệu có cấu trúc JSON-LD đúng định dạng chẳng khác nào nói thẳng với chúng bằng ngôn ngữ mà máy hiểu được: đây là công ty kiểu gì, bài viết này ai viết, sản phẩm này giá bao nhiêu, trang này có những câu hỏi thường gặp nào. Thiếu nó, AI chỉ có thể đoán; có nó, khả năng bạn được nhận diện và trích dẫn đúng tăng lên đáng kể. Bài này dẫn bạn triển khai các loại thường dùng từ con số không, đặt đúng vị trí và kiểm tra để chắc chắn không có lỗi.

Dữ liệu có cấu trúc là gì? Vì sao dùng JSON-LD

Dữ liệu có cấu trúc là phần đánh dấu được viết theo bộ từ vựng chung của Schema.org, dùng các cặp khóa-giá trị mà máy đọc được để nói cho công cụ tìm kiếm và engine AI biết "nội dung trang này đại diện cho điều gì". Cùng một chuỗi như "Nguyễn Văn A, 0912-345-678", con người hiểu đó là người liên hệ và số điện thoại, nhưng máy cần bạn đánh dấu rõ name và telephone thì mới không hiểu nhầm.

Có ba định dạng triển khai (JSON-LD, Microdata, RDFa), nhưng cả Google lẫn cách làm phổ biến hiện nay đều khuyên dùng JSON-LD. Lý do là nó gom toàn bộ phần đánh dấu vào một khối <script> độc lập, không phải đan xen vào các thẻ HTML, dễ bảo trì nhất, ít xung đột với bố cục nhất, và cũng dễ để bot AI phân tích cú pháp một cách ổn định nhất.

JSON-LD đặt ở đâu trên trang?

Bọc phần đánh dấu trong khối <script type="application/ld+json">. Đặt trong <head> hay <body> của trang đều được nhận diện, nhưng theo thông lệ thì đặt ở <head>. Một trang có thể có nhiều khối JSON-LD, và cũng có thể dùng một mảng @graph để gom nhiều thực thể lại với nhau; cả hai cách đều hợp lệ.

Nguyên tắc then chốt là: dữ liệu có cấu trúc phải được xuất ra ở phía máy chủ và tồn tại trong HTML gốc. Đa số bot thu thập của AI không thực thi JavaScript, nên nếu JSON-LD của bạn được JS chèn động chỉ sau khi phía front-end tải xong, thì bot AI rất có thể chỉ đọc được một cái vỏ rỗng không có phần đánh dấu. Hãy dùng "Xem mã nguồn" (View Source) thay vì bảng Elements trong công cụ dành cho nhà phát triển để xác nhận nó thực sự nằm trong phản hồi gốc.

Organization và LocalBusiness: định nghĩa bạn là ai

Đây là phần nên ưu tiên làm trước nhất của cả website, thường đặt ở trang chủ. Nó định nghĩa thực thể thương hiệu của bạn, là căn cứ cốt lõi khi AI trả lời "công ty này là ai, có đáng tin không". Nếu có cửa hàng thực tế hoặc khu vực phục vụ, hãy dùng LocalBusiness chính xác hơn (hoặc các kiểu con như Restaurant, Store) thay cho Organization, và bổ sung địa chỉ cùng giờ mở cửa.

Các trường bắt buộc của Organization: name (tên thương hiệu), url (website chính thức), logo (URL hình ảnh logo).
sameAs: đặt vào một mảng các liên kết chính thức của bạn như Facebook, Instagram, LinkedIn, Wikipedia, v.v. Đây là chìa khóa để "gắn" các danh tính thương hiệu rải rác thành cùng một thực thể, giúp giảm mạnh khả năng AI nhận nhầm đối tượng.
LocalBusiness thêm: address (dùng cấu trúc PostalAddress, tách thành đường/thành phố/mã bưu chính), telephone, openingHours, geo (tọa độ kinh độ và vĩ độ), priceRange.
contactPoint: nêu rõ số điện thoại chăm sóc khách hàng, email và ngôn ngữ phục vụ, để AI tìm thấy bạn khi trả lời các câu hỏi liên quan đến liên hệ.

Article, Product, BreadcrumbList: chọn đúng schema theo loại trang

Các trang khác nhau dùng loại khác nhau, nguyên tắc là "trang này chủ yếu nói về gì thì đánh dấu cái đó". Blog và tin tức dùng Article (hoặc BlogPosting/NewsArticle); trang sản phẩm dùng Product; bất kỳ trang nào có phân cấp đều nên bổ sung BreadcrumbList.

Article/BlogPosting: headline, author (dùng Person hoặc Organization, đừng chỉ để văn bản thuần), datePublished, dateModified, image, publisher. Tác giả và ngày tháng là tín hiệu quan trọng để AI đánh giá độ mới và độ uy tín của nội dung.
Product: name, image, description, brand, offers (bên trong gồm price, priceCurrency, availability). Nếu có đánh giá thì thêm aggregateRating và review, nhưng điểm số phải khớp với các nhận xét thực sự hiển thị trên trang.
BreadcrumbList: dùng itemListElement để liệt kê theo thứ tự đường dẫn breadcrumb (Trang chủ › Danh mục › Trang này), giúp engine hiểu cấu trúc website và vị trí của trang này trong website.
Mẹo nhỏ khi chọn loại: một trang có thể đồng thời có nhiều loại (ví dụ một bài đánh giá sản phẩm vừa là Article vừa là Product), chỉ cần dùng @graph gom lại với nhau là được.

Tò mò xem trang của bạn được AI chấm bao nhiêu điểm?

Quét miễn phí — nhận ngay điểm sẵn sàng AI 0–100 và các bản sửa dán-là-xong.

Kiểm tra GEO miễn phí →

FAQPage: chiêu hữu ích trực tiếp nhất cho GEO

Nếu chỉ muốn bắt đầu với một loại có thể ảnh hưởng ngay đến việc AI trích dẫn, hãy chọn FAQPage. Nó ghép từng cặp "câu hỏi - câu trả lời" thành định dạng mà máy đọc được, vừa khớp với logic trích xuất của engine AI là "tìm một đoạn nội dung có thể dùng trực tiếp làm câu trả lời", nên đây là bước có tỷ suất sinh lời rất cao.

Cách làm là dùng mainEntity để liệt kê nhiều mục Question, dưới mỗi mục đặt một acceptedAnswer (kiểu Answer, điền câu trả lời vào trường text). Quy tắc bất di bất dịch: câu hỏi và câu trả lời trong phần đánh dấu phải là nội dung mà người dùng thực sự nhìn thấy được trên trang, không được chỉ tồn tại trong JSON-LD. Chính sách của Google quy định rõ nội dung FAQ phải hiển thị được trên trang, nếu không sẽ bị coi là nội dung ẩn vi phạm.

Kiểm tra thế nào? Ba bước kiểm tra bắt buộc phải chạy

Viết xong nhất định phải kiểm tra, vì chỉ một tên trường viết sai hoặc thiếu một dấu phẩy là cả khối đánh dấu có thể bị bỏ qua. Việc kiểm tra chia làm hai cấp độ: cú pháp có đúng không, và có đủ điều kiện kích hoạt Rich Results không.

Schema Markup Validator (validator.schema.org): kiểm tra bản thân cú pháp Schema.org có đúng không, áp dụng cho mọi loại, không giới hạn ở những loại Google hỗ trợ.
Google Rich Results Test (search.google.com/test/rich-results): dán URL hoặc mã vào để xem Google có công nhận không, có lấy được kết quả tìm kiếm dạng rich result không, đồng thời liệt kê các lỗi và cảnh báo.
Báo cáo "Kết quả nhiều định dạng" trong Search Console: sau khi lên trực tuyến, hãy liên tục theo dõi trạng thái và lỗi mà Google thực sự thu thập được, phản ánh tình hình thực tế tốt hơn một lần kiểm tra duy nhất.
Đừng quên dùng "Xem mã nguồn" để xác nhận phần đánh dấu thực sự xuất hiện trong HTML mà máy chủ trả về, chứ không phải chỉ dựa vào việc JS chèn vào.

Năm lỗi thường gặp nhất (nhất là lỗi đầu tiên sẽ bị coi là spam)

Làm sai dữ liệu có cấu trúc còn tệ hơn không làm: nhẹ thì bị bỏ qua, nặng thì bị xác định là thao túng. Năm lỗi sau đây là những cái bẫy hay mắc nhất.

Đánh dấu không khớp với nội dung: JSON-LD ghi đánh giá năm sao nhưng trên trang chẳng có, hoặc câu trả lời FAQ không thấy được trên trang — điều này sẽ bị Google coi là spam, có thể khiến dữ liệu có cấu trúc của cả website mất tư cách. Phần đánh dấu phải phản ánh trung thực nội dung thực tế trên trang.
Dùng sai loại hoặc trường: đánh dấu sản phẩm thành Article, điền author bằng chuỗi văn bản thuần thay vì Person/Organization, price không kèm priceCurrency, v.v. đều khiến engine không phân tích cú pháp đúng được.
Dựa vào JavaScript chèn động: bot AI và trong một số trường hợp không đọc được, coi như làm vô ích. Nhất định phải xuất ra ở phía máy chủ.
Thực thể không nhất quán: trang chủ gọi "KKpower", trang khác gọi "KK Power", liên kết mạng xã hội lại không khớp, khiến AI khó gắn chúng thành cùng một thương hiệu. Hãy giữ name, url và sameAs nhất quán cố định.
Đánh dấu quá đà và nhồi nhét: cố nhét tất cả mọi thứ trên trang thành schema, hoặc khai báo lặp lại cùng một thực thể, ngược lại làm tăng nguy cơ sai sót và bị xác định là thao túng. Chỉ cần đánh dấu cái quan trọng và cái có thật là đủ.

Câu hỏi thường gặp

Q. Dữ liệu có cấu trúc nhất định phải dùng JSON-LD sao? Dùng Microdata được không?

Microdata và RDFa về mặt cú pháp vẫn hợp lệ, nhưng cả Google lẫn thực tiễn phổ biến hiện nay đều khuyên dùng JSON-LD. Nó gom phần đánh dấu vào một khối <script> độc lập, không phải đan xen vào các thẻ HTML, dễ bảo trì nhất, ít xung đột với bố cục nhất, và cũng dễ để bot AI phân tích cú pháp một cách ổn định nhất. Website làm mới thì cứ chọn JSON-LD là đúng.

Q. Thêm dữ liệu có cấu trúc rồi thì Google chắc chắn sẽ cho tôi Rich Results (ngôi sao, FAQ mở rộng) chứ?

Không bảo đảm. Đánh dấu đúng chỉ là "đạt tư cách", còn có thực sự hiển thị kết quả dạng rich result hay không là do thuật toán của Google quyết định, dựa vào chất lượng nội dung, có tuân thủ chính sách không, ngữ cảnh truy vấn, v.v. Nhưng dù không kích hoạt được Rich Results trực quan, dữ liệu có cấu trúc đúng vẫn giúp công cụ tìm kiếm và engine AI hiểu và trích dẫn nội dung của bạn, nên giá trị không hề uổng phí.

Q. Câu hỏi và câu trả lời trong phần đánh dấu FAQPage có nhất thiết phải thấy được trên trang không?

Có, đây là quy định bắt buộc. Chính sách của Google yêu cầu câu hỏi và câu trả lời của FAQ phải là nội dung mà người dùng thực sự nhìn thấy được trên trang; nếu chỉ viết trong JSON-LD mà trên trang không thấy thì bị coi là nội dung ẩn vi phạm, có thể khiến dữ liệu có cấu trúc của bạn mất tư cách thậm chí ảnh hưởng cả website. Phần đánh dấu phải tương ứng trung thực với những gì trang thực sự trình bày.

Q. Viết sai dữ liệu có cấu trúc có làm hại website của tôi không?

Có. Nghiêm trọng nhất là "đánh dấu không khớp với nội dung" (ví dụ đánh giá giả, FAQ không thấy được trên trang), điều này bị coi là thao túng, có thể khiến dữ liệu có cấu trúc của website bị hủy tư cách. Các vấn đề thường gặp khác như dùng sai loại, viết sai tên trường, hay dựa vào JS chèn động khiến bot không đọc được, phần lớn là "không hợp lệ nhưng vô hại", engine chỉ đơn giản bỏ qua. Nguyên tắc là: thà đánh dấu ít mà đúng còn hơn đánh dấu nhiều mà giả.

Q. Tôi nên ưu tiên làm loại schema nào?

Hãy làm hai loại trước. Một là Organization ở trang chủ (có cửa hàng hoặc khu vực phục vụ thì dùng LocalBusiness), để định nghĩa thực thể thương hiệu và thông tin liên hệ; hai là FAQPage ở trang nội dung, vì định dạng hỏi-đáp của nó sát nhất với cách engine AI trích xuất câu trả lời, hiệu quả trực tiếp nhất cho việc được trích dẫn. Sau đó tùy theo loại trang mà bổ sung Article, Product và BreadcrumbList.

Q. Làm sao xác nhận dữ liệu có cấu trúc của tôi thực sự được đọc?

Ba bước: trước tiên dùng Schema Markup Validator (validator.schema.org) xác nhận cú pháp đúng; rồi dùng Google Rich Results Test xác nhận Google công nhận và kiểm tra có kích hoạt được kết quả rich result không; sau khi lên trực tuyến dùng báo cáo kết quả nhiều định dạng trong Search Console để theo dõi liên tục. Cuối cùng nhất định phải dùng "Xem mã nguồn" của trình duyệt để xác nhận JSON-LD xuất hiện trong HTML gốc mà máy chủ trả về, chứ không phải chỉ do JavaScript phía front-end chèn vào.

Kiểm chứng điều vừa học trên trang của bạn trong 10 giây