Cách thêm schema markup bằng JSON-LD

Tuy nhiên, nhiều website hiện nay vẫn triển khai schema theo cách sao chép mẫu có sẵn hoặc sử dụng plugin mà không kiểm tra dữ liệu đầu ra. Điều này dẫn đến tình trạng schema hợp lệ về cú pháp nhưng không phản ánh đúng nội dung thực tế, tạo dữ liệu trùng lặp hoặc không đủ điều kiện xuất hiện Rich Results.

Bài viết này sẽ hướng dẫn toàn bộ quy trình triển khai schema markup bằng JSON-LD từ góc độ kỹ thuật, giúp bạn xây dựng hệ thống dữ liệu có cấu trúc chính xác, dễ bảo trì và phù hợp với SEO lâu dài.

Schema markup bằng JSON-LD là gì?

Schema markup giúp công cụ tìm kiếm hiểu nội dung theo ngữ nghĩa

Một trang web không chỉ chứa văn bản mà còn bao gồm rất nhiều loại dữ liệu như tên sản phẩm, giá bán, hình ảnh, tác giả, ngày xuất bản, doanh nghiệp, địa chỉ, đánh giá hay câu hỏi thường gặp.

Người dùng có thể dễ dàng nhận biết các thành phần này nhờ giao diện hiển thị. Ngược lại, công cụ tìm kiếm cần một cách mô tả rõ ràng hơn để hiểu chính xác từng thành phần đang đại diện cho dữ liệu gì.

Schema markup chính là lớp dữ liệu bổ sung giúp mô tả ý nghĩa của nội dung trên website theo chuẩn Schema.org.

Ví dụ, trên một trang sản phẩm có dòng:

Áo sơ mi nam Oxford – 590.000 VNĐ

Đối với người đọc, đây là tên sản phẩm và giá bán. Nhưng với Google, nếu không có schema thì chỉ là hai chuỗi văn bản xuất hiện gần nhau. Khi triển khai Product Schema, website có thể khai báo rõ:

• Tên sản phẩm

• Giá bán

• Đơn vị tiền tệ

• Tình trạng còn hàng

• Thương hiệu

• Mã sản phẩm

Nhờ đó công cụ tìm kiếm hiểu chính xác bản chất của từng dữ liệu thay vì phải suy luận từ bố cục HTML.

JSON-LD là định dạng được sử dụng phổ biến nhất

Schema markup có thể được triển khai bằng ba định dạng:

• JSON-LD

• Microdata

• RDFa

Trong đó JSON-LD được sử dụng phổ biến nhất vì dữ liệu được đặt trong một thẻ

Việc tách riêng dữ liệu có cấu trúc mang lại nhiều lợi ích:

• Dễ đọc và dễ bảo trì

• Không làm rối HTML

• Thuận tiện khi dữ liệu được sinh tự động từ CMS

• Dễ cập nhật khi thay đổi template

• Giảm nguy cơ lỗi khi chỉnh sửa giao diện

Đây cũng là lý do hầu hết các nền tảng CMS và framework hiện nay đều ưu tiên JSON-LD thay vì Microdata.

Thành phần cơ bản của JSON-LD

Một đoạn JSON-LD thường bao gồm các thành phần sau:

• @context

• @type

• @id

• Các thuộc tính mô tả

• Quan hệ giữa các thực thể

Ví dụ:

{
 "@context":"https://schema.org",
 "@type":"BlogPosting",
 "@id":"https://example.com/schema/#article",
 "headline":"Hướng dẫn thêm schema markup bằng JSON-LD",
 "datePublished":"2026-07-30",
 "author":{
   "@type":"Person",
   "name":"Nguyễn Văn A"
 }
}

Trong đó:

• @context xác định hệ thống từ vựng đang sử dụng.

• @type xác định loại thực thể.

• @id tạo định danh duy nhất cho thực thể để các đối tượng khác có thể tham chiếu.

• Các thuộc tính còn lại mô tả chi tiết đối tượng.

Schema hợp lệ không đồng nghĩa với Rich Results

Đây là điểm rất nhiều người triển khai schema hiểu chưa chính xác.

Một đoạn JSON-LD có thể:

• Đúng cú pháp JSON.

• Hợp lệ theo Schema.org.

• Không phát sinh lỗi.

Nhưng vẫn không xuất hiện Rich Results trên Google.

Lý do là Rich Results còn phụ thuộc vào nhiều yếu tố khác như:

• Loại schema có được Google hỗ trợ hay không.

• Nội dung trên trang có khớp với schema.

• Chất lượng website.

• Chính sách của Google đối với từng loại kết quả.

• Quá trình crawl và index.

Vì vậy, mục tiêu của việc triển khai schema không phải là "ép Google hiển thị Rich Results", mà là cung cấp dữ liệu có cấu trúc chính xác để công cụ tìm kiếm hiểu nội dung đầy đủ nhất.

Cách lựa chọn loại schema phù hợp

Xác định đúng thực thể chính của URL

Trước khi viết bất kỳ dòng JSON-LD nào, cần xác định rõ:

Trang này đang mô tả điều gì?

Đó được gọi là thực thể chính (Primary Entity).

Một URL nên tập trung vào một thực thể chính duy nhất.

Ví dụ:

Website có thể chứa nhiều schema trên cùng một URL, nhưng các schema phải bổ trợ cho nhau thay vì cạnh tranh vai trò.

Ví dụ, một bài viết có thể bao gồm:

• BlogPosting

• Organization

• Person

• BreadcrumbList

Trong trường hợp này, BlogPosting vẫn là thực thể trung tâm.

Schema cho trang chủ

Trang chủ thường đại diện cho toàn bộ website và doanh nghiệp.

Thông thường nên triển khai ba loại:

• Organization

• WebSite

• WebPage

Trong đó:

Organization mô tả doanh nghiệp.

WebSite mô tả website.

WebPage mô tả chính trang chủ.

Ví dụ:

{
 "@type":"Organization",
 "@id":"https://example.com/#organization",
 "name":"ABC Company",
 "url":"https://example.com"
}

Nếu doanh nghiệp có các kênh chính thức như Facebook hoặc LinkedIn, có thể khai báo thêm trong thuộc tính sameAs.

Schema cho bài viết

Đối với blog hoặc website chia sẻ kiến thức, BlogPosting là lựa chọn phù hợp nhất.

Một bài viết đầy đủ thường khai báo:

• Tiêu đề

• Mô tả

• URL

• Hình ảnh

• Ngày xuất bản

• Ngày cập nhật

• Tác giả

• Nhà xuất bản

Ví dụ:

{
 "@type":"BlogPosting",
 "headline":"Cách thêm schema markup bằng JSON-LD",
 "datePublished":"2026-07-30",
 "dateModified":"2026-07-31"
}

Không nên thay đổi dateModified chỉ để làm bài viết trông mới hơn nếu nội dung chưa thực sự được chỉnh sửa.

Schema cho sản phẩm

Trang bán hàng thường sử dụng Product kết hợp Offer.

Các thuộc tính quan trọng gồm:

• name

• image

• description

• sku

• brand

• offers

Ví dụ:

{
 "@type":"Product",
 "name":"Áo sơ mi Oxford",
 "sku":"OXF001",
 "offers":{
   "@type":"Offer",
   "price":"590000",
   "priceCurrency":"VND",
   "availability":"https://schema.org/InStock"
 }
}

Toàn bộ dữ liệu này nên lấy trực tiếp từ hệ thống bán hàng thay vì nhập thủ công.

Nếu giá trên giao diện là 590.000 đồng nhưng schema vẫn giữ giá cũ 650.000 đồng, Google sẽ nhận được hai nguồn dữ liệu mâu thuẫn.

Schema cho doanh nghiệp địa phương

Website của cửa hàng, nhà hàng, phòng khám hoặc doanh nghiệp có địa điểm phục vụ khách hàng nên sử dụng LocalBusiness.

Một LocalBusiness thường khai báo:

• Tên doanh nghiệp

• Địa chỉ

• Điện thoại

• Website

• Giờ mở cửa

• Hình ảnh

• Tọa độ

Nếu doanh nghiệp có nhiều chi nhánh, mỗi địa điểm nên có một URL và một thực thể riêng thay vì dùng chung một schema.

Schema cho FAQ và Breadcrumb

FAQPage chỉ nên sử dụng khi toàn bộ câu hỏi và câu trả lời đều xuất hiện trên giao diện.

BreadcrumbList giúp Google hiểu vị trí của URL trong cấu trúc website.

Hai loại schema này không thay thế thực thể chính mà chỉ đóng vai trò bổ trợ cho quá trình hiểu nội dung và điều hướng.

Quy trình triển khai schema markup bằng JSON-LD

Bước 1: Lập bản đồ dữ liệu

Đây là bước quan trọng nhất nhưng thường bị bỏ qua.

Thay vì viết JSON-LD ngay, hãy xác định nguồn dữ liệu cho từng thuộc tính.

Ví dụ:

Khi tất cả dữ liệu đều lấy từ cùng một nguồn, website sẽ tránh được tình trạng nội dung trên giao diện và schema không đồng nhất.

Bước 2: Chỉ khai báo dữ liệu thực sự tồn tại

Một sai lầm phổ biến là cố gắng điền đầy đủ mọi thuộc tính của Schema.org.

Thực tế, chỉ nên khai báo:

• Trường bắt buộc.

• Trường khuyến nghị có dữ liệu thật.

• Trường được website quản lý ổn định.

Không nên thêm:

• Giá trị rỗng.

• Đánh giá giả.

• Giá bán không tồn tại.

• Tác giả không hiển thị.

• Hình ảnh không sử dụng.

Ít dữ liệu nhưng chính xác luôn tốt hơn một schema rất dài nhưng chứa nhiều thông tin sai.

Bước 3: Sinh JSON bằng hàm chuẩn

Không nên nối chuỗi JSON thủ công.

Ví dụ không nên dùng:

echo '{"headline":"'.get_the_title().'"}';

Thay vào đó nên sử dụng các hàm sinh JSON của ngôn ngữ lập trình như json_encode() hoặc wp_json_encode() để tự động xử lý dấu ngoặc kép, ký tự Unicode và các ký tự đặc biệt.

Điều này giúp hạn chế lỗi cú pháp khi tiêu đề hoặc mô tả chứa dấu ngoặc, dấu nháy hoặc ký tự tiếng Việt.

Triển khai schema markup bằng JSON-LD trên website

Thêm JSON-LD vào website HTML

Đối với website HTML tĩnh, JSON-LD thường được đặt trong một thẻ script có kiểu dữ liệu application/ld json. Thẻ này có thể đặt trong phần hoặc trước thẻ đóng . Cả hai vị trí đều được Google hỗ trợ, tuy nhiên đặt trong phần đầu trang sẽ giúp dữ liệu có cấu trúc được tải ngay từ đầu.

Nếu website chỉ có vài chục trang, việc chèn trực tiếp từng đoạn JSON-LD không quá phức tạp. Tuy nhiên, với website lớn có hàng trăm hoặc hàng nghìn URL, cách làm này sẽ khó bảo trì và dễ phát sinh sai sót khi thay đổi nội dung.

Triển khai trên WordPress

WordPress là nền tảng được sử dụng nhiều nhất hiện nay nên cũng có nhiều cách triển khai schema.

Đối với website thông thường, plugin SEO đã có khả năng tạo tự động các loại schema như Organization, WebSite, WebPage, BlogPosting hoặc Breadcrumb. Đây là giải pháp phù hợp khi website không có nhiều yêu cầu tùy chỉnh.

Trong trường hợp cần kiểm soát dữ liệu chi tiết hơn, lập trình viên có thể tạo JSON-LD bằng code và lấy dữ liệu trực tiếp từ WordPress như tiêu đề bài viết, ngày xuất bản, ngày cập nhật, tác giả hoặc ảnh đại diện.

Dù sử dụng plugin hay tự lập trình, cần kiểm tra mã nguồn sau khi triển khai để đảm bảo website không tạo hai schema giống nhau cho cùng một đối tượng.

Triển khai trên PHP

Website xây dựng bằng PHP nên sinh dữ liệu JSON-LD trực tiếp từ cơ sở dữ liệu thay vì nhập thủ công.

Ví dụ, tiêu đề bài viết nên lấy từ trường tiêu đề trong cơ sở dữ liệu, URL lấy từ canonical URL, ngày xuất bản lấy từ dữ liệu của bài viết và ngày cập nhật được đồng bộ với thời điểm chỉnh sửa cuối cùng.

Việc sinh dữ liệu tự động giúp hạn chế tình trạng nội dung trên giao diện và nội dung trong schema bị khác nhau sau nhiều lần cập nhật.

Triển khai trên React và Next.js

Đối với React hoặc Next.js, JSON-LD thường được tạo từ dữ liệu API hoặc dữ liệu render phía máy chủ.

Khi website sử dụng Server Side Rendering hoặc Static Site Generation, dữ liệu có cấu trúc sẽ xuất hiện ngay trong HTML mà Google nhận được. Đây là phương pháp được nhiều website hiện đại sử dụng vì vừa đảm bảo SEO vừa dễ bảo trì.

Trong quá trình lập trình cần chú ý xử lý đúng các ký tự đặc biệt để tránh làm hỏng cấu trúc JSON.

Quản lý nhiều schema trên cùng một trang

Sử dụng @id để liên kết dữ liệu

Một website thường không chỉ có một loại schema.

Ví dụ một bài viết có thể đồng thời chứa:

• Organization

• WebSite

• WebPage

• BlogPosting

• Person

• BreadcrumbList

Nếu mỗi schema đều khai báo lại toàn bộ thông tin doanh nghiệp sẽ tạo ra nhiều dữ liệu trùng lặp.

Giải pháp là sử dụng thuộc tính @id để các thực thể tham chiếu lẫn nhau. Khi đó Google sẽ hiểu rằng nhiều schema đang mô tả cùng một đối tượng thay vì nhiều đối tượng khác nhau.

Việc sử dụng @id cũng giúp hệ thống dữ liệu có cấu trúc dễ mở rộng khi website phát triển thêm nhiều chuyên mục hoặc nhiều loại nội dung.

Khi nào nên sử dụng @graph

Nếu một URL chứa nhiều thực thể liên quan chặt chẽ với nhau, nên sử dụng @graph để nhóm toàn bộ dữ liệu vào một cấu trúc thống nhất.

Ví dụ, một bài viết có thể bao gồm doanh nghiệp xuất bản, tác giả, trang web, trang bài viết và đường dẫn điều hướng. Khi đặt các thực thể này trong cùng một @graph, Google sẽ hiểu rõ hơn mối quan hệ giữa chúng.

Đối với website nhỏ, việc sử dụng nhiều đoạn JSON-LD riêng biệt vẫn có thể chấp nhận được. Tuy nhiên, với website lớn hoặc hệ thống nhiều loại nội dung, @graph sẽ giúp việc quản lý thuận tiện hơn.

Kiểm tra schema sau khi triển khai

Kiểm tra cú pháp

Trước khi kiểm tra trên Google, cần chắc chắn rằng dữ liệu JSON-LD không bị lỗi cú pháp.

Những lỗi thường gặp gồm:

• Thiếu dấu ngoặc.

• Thiếu dấu phẩy.

• Thiếu dấu ngoặc kép.

• Giá trị rỗng.

• Ký tự đặc biệt chưa được xử lý.

• Sai định dạng ngày tháng.

Chỉ cần một lỗi cú pháp nhỏ cũng có thể khiến toàn bộ schema không được xử lý.

Kiểm tra bằng Rich Results Test

Sau khi JSON hợp lệ, nên kiểm tra URL bằng Rich Results Test.

Công cụ này giúp xác định:

• Google phát hiện những loại schema nào.

• Có lỗi nghiêm trọng hay không.

• Có cảnh báo cần bổ sung hay không.

• Loại dữ liệu nào đủ điều kiện tham gia Rich Results.

Cần lưu ý rằng cảnh báo không phải lúc nào cũng ảnh hưởng đến khả năng hoạt động của schema. Tuy nhiên, lỗi nghiêm trọng cần được xử lý trước khi triển khai trên toàn bộ website.

Kiểm tra dữ liệu thực tế

Ngoài việc kiểm tra công cụ, hãy mở trực tiếp URL đã xuất bản và so sánh dữ liệu hiển thị với dữ liệu được khai báo.

Các thông tin cần đối chiếu gồm:

• Tiêu đề.

• URL.

• Ảnh đại diện.

• Tác giả.

• Ngày xuất bản.

• Ngày cập nhật.

• Giá bán nếu là trang sản phẩm.

Nếu dữ liệu trên giao diện và dữ liệu trong schema khác nhau, website cần được đồng bộ lại trước khi Google thu thập dữ liệu.

Xử lý schema bị trùng lặp

Trường hợp không phải lỗi

Nhiều website có từ bốn đến sáu schema trên cùng một URL và điều này hoàn toàn bình thường.

Ví dụ, một bài viết có thể đồng thời khai báo:

• BlogPosting.

• Organization.

• Person.

• BreadcrumbList.

Mỗi schema mô tả một thực thể khác nhau nên không tạo ra xung đột.

Trường hợp cần xử lý

Xung đột xảy ra khi hai schema cùng mô tả một đối tượng nhưng lại chứa thông tin khác nhau.

Ví dụ:

• Hai mức giá khác nhau cho cùng một sản phẩm.

• Hai tác giả khác nhau cho cùng một bài viết.

• Hai logo doanh nghiệp khác nhau.

• Hai canonical URL khác nhau.

Trong những trường hợp này, Google sẽ khó xác định dữ liệu nào là chính xác.

Quy trình kiểm tra

Nếu phát hiện nhiều đoạn JSON-LD trên một URL, hãy thực hiện theo trình tự sau:

• Kiểm tra toàn bộ mã nguồn của trang.

• Xác định tất cả các schema đang được sinh ra.

• Tìm nguồn tạo schema như plugin hoặc theme.

• So sánh dữ liệu của từng thực thể.

• Loại bỏ nguồn tạo trùng lặp.

• Kiểm tra lại sau khi cập nhật.

Những lỗi thường gặp khi triển khai JSON-LD

Sao chép nguyên mẫu trên Internet

Nhiều website lấy nguyên một đoạn schema mẫu rồi chỉ thay tiêu đề bài viết.

Kết quả là vẫn còn:

• URL mẫu.

• Logo mẫu.

• Tên doanh nghiệp mẫu.

• Tác giả mẫu.

• Hình ảnh không tồn tại.

Điều này khiến dữ liệu có cấu trúc không phản ánh đúng website thực tế.

Khai báo thông tin không có trên giao diện

Một số website tự thêm đánh giá sao, nhận xét của khách hàng hoặc câu hỏi thường gặp trong schema mặc dù các nội dung này hoàn toàn không xuất hiện trên trang.

Schema chỉ nên mô tả những gì người dùng thực sự nhìn thấy.

Không đồng bộ dữ liệu

Website thay đổi tiêu đề, hình ảnh hoặc giá bán nhưng schema không được cập nhật.

Đây là lỗi rất phổ biến khi website sử dụng nhiều plugin hoặc nhiều nguồn dữ liệu khác nhau.

Không kiểm tra sau khi cập nhật website

Sau mỗi lần thay đổi theme, plugin hoặc framework, cần kiểm tra lại schema vì quá trình cập nhật có thể làm mất hoặc thay đổi dữ liệu có cấu trúc mà người quản trị không nhận ra.

Checklist triển khai schema markup bằng JSON-LD

Checklist dành cho SEO

• Xác định đúng thực thể chính của URL.

• Chọn loại schema phù hợp.

• Đồng bộ schema với nội dung hiển thị.

• Kiểm tra Rich Results Test.

• Theo dõi Search Console sau khi triển khai.

Checklist dành cho lập trình viên

• Sinh JSON tự động từ dữ liệu hệ thống.

• Không nhập dữ liệu thủ công.

• Sử dụng URL tuyệt đối.

• Thiết lập @id ổn định.

• Không tạo dữ liệu rỗng.

• Kiểm tra sau mỗi lần triển khai phiên bản mới.

Checklist dành cho biên tập viên

• Kiểm tra tiêu đề.

• Kiểm tra mô tả.

• Kiểm tra ảnh đại diện.

• Kiểm tra ngày xuất bản.

• Kiểm tra ngày cập nhật.

• Đảm bảo FAQ và các thông tin khác xuất hiện đầy đủ trên giao diện.

Một hệ thống schema hiệu quả không được đánh giá bằng số lượng schema được thêm vào mà bằng mức độ chính xác, đồng nhất và khả năng phản ánh đúng nội dung của website. Khi dữ liệu có cấu trúc được xây dựng từ nguồn dữ liệu thực tế, được kiểm tra thường xuyên và duy trì nhất quán trong quá trình vận hành, website sẽ giúp công cụ tìm kiếm hiểu nội dung rõ ràng hơn và tạo nền tảng tốt cho chiến lược SEO dài hạn.