Dữ liệu có cấu trúc: cách thắng rich results trên Google

Bạn đã viết một bài hướng dẫn tốt, tối ưu tiêu đề, gắn từ khoá đầy đủ — nhưng khi tìm trên Google thì kết quả của bạn chỉ là một dòng xanh và hai dòng mô tả nhạt nhoà, trong khi đối thủ phía trên có cả ngôi sao đánh giá, danh sách câu hỏi bung ra, ảnh thu nhỏ và giá tiền hiển thị ngay trên trang kết quả. Cùng một thứ hạng, nhưng họ chiếm gấp ba diện tích màn hình và hút phần lớn cú nhấp. Khác biệt đó hầu như không nằm ở nội dung — nó nằm ở một lớp dữ liệu mà bạn chưa khai báo.

Lớp dữ liệu đó là dữ liệu có cấu trúc (structured data). Nó là cách bạn nói chuyện trực tiếp với máy của Google bằng ngôn ngữ máy hiểu được, thay vì để máy tự đoán nội dung trang qua câu chữ con người đọc. Khi máy hiểu rõ "đây là bài viết, tác giả là ai, đăng ngày nào, đây là câu hỏi thường gặp, đây là sản phẩm giá bao nhiêu", nó mới đủ tự tin để trao cho bạn những định dạng hiển thị nổi bật gọi là rich results — và ngày càng quan trọng hơn, để trích dẫn bạn trong các câu trả lời do AI tạo ra.

Bài viết này là một playbook thực hành về dữ liệu có cấu trúc cho web Việt: nó là gì, vì sao nó giúp bạn thắng rich results và lọt vào AI Overview, những loại schema nào thực sự đáng làm, cách viết JSON-LD đúng chuẩn, cách kiểm thử bằng công cụ của Google, và những sai lầm khiến công sức của bạn đổ sông đổ biển. Không cần bạn là lập trình viên — chỉ cần bạn hiểu nguyên lý và làm đúng thứ tự.

Dữ liệu có cấu trúc là đoạn mã chuẩn hoá (thường viết bằng JSON-LD theo từ điển Schema.org) gắn vào trang web để mô tả nội dung theo cách máy hiểu được. Nhờ nó, Google biết chắc trang của bạn là bài viết, sản phẩm hay câu hỏi thường gặp, từ đó có thể hiển thị rich results — sao đánh giá, FAQ bung ra, giá, breadcrumb — và dễ trích dẫn bạn trong AI Overview hơn.

Dữ liệu có cấu trúc thực ra là gì

Hãy tưởng tượng một trang sản phẩm. Mắt người nhìn vào là thấy ngay: đây là tên sản phẩm, đây là giá, đây là số sao trung bình, còn đây là nút mua. Nhưng máy của Google không "nhìn" như bạn — nó đọc mã nguồn và phải suy đoán đâu là giá, đâu là tên, đâu chỉ là một con số ngẫu nhiên trong trang. Phần lớn thời gian nó đoán đúng, nhưng "đoán đúng phần lớn" không đủ để nó mạo hiểm hiển thị giá sai cho hàng triệu người dùng.

Dữ liệu có cấu trúc xoá bỏ trò đoán đó. Thay vì để máy suy luận, bạn đặt thẳng vào trang một khối dữ liệu nói rõ ràng: kiểu nội dung là Product, tên là "X", giá là 199000, đơn vị tiền là VND, đánh giá trung bình là 4,7 trên 312 lượt. Khối dữ liệu này con người không nhìn thấy trên giao diện — nó dành riêng cho máy đọc. Đó là lý do người ta gọi nó là lớp ngữ nghĩa: nó không thay đổi giao diện bạn thấy, nó thay đổi mức độ chắc chắn mà máy hiểu trang.

Bộ "từ điển" chung mà cả Google, Bing và các cỗ máy khác cùng dùng là Schema.org — một danh mục các kiểu thực thể (Article, Product, Organization, FAQPage, BreadcrumbList…) và các thuộc tính kèm theo (tên, ngày đăng, tác giả, giá…). Bạn không tự bịa ra tên thuộc tính; bạn tra trong Schema.org và dùng đúng tên nó quy định. Còn cách đóng gói các khai báo đó vào trang thì có ba kiểu cú pháp, nhưng trong thực tế năm 2026 chỉ còn một kiểu đáng dùng, và phần sau sẽ nói rõ.

Điểm cốt lõi cần nhớ: dữ liệu có cấu trúc không phải là một thủ thuật SEO để "lừa" thứ hạng. Nó không nâng thứ hạng trực tiếp. Nó làm một việc khác và quan trọng không kém — nó giúp trang của bạn được trình bày đẹp hơn, chiếm nhiều diện tích hơn, và đáng tin hơn trong mắt cả máy lẫn người ở đúng cái khoảnh khắc người ta quyết định nhấp vào đâu.

Vì sao nó giúp bạn thắng rich results và lọt vào AI Overview

Có hai phần thưởng tách biệt, và đáng để phân biệt rõ vì chúng vận hành theo logic khác nhau.

Phần thưởng thứ nhất là rich results — những định dạng hiển thị mở rộng trên trang kết quả tìm kiếm. Đó là khi kết quả của bạn không còn là dòng xanh trơ trọi mà có thêm: sao đánh giá vàng óng cho một sản phẩm hay công thức nấu ăn, danh sách câu hỏi có thể bấm vào để bung câu trả lời cho một trang FAQ, đường dẫn phân cấp "Trang chủ › Hướng dẫn › Bài này" thay cho một URL dài loằng ngoằng, ảnh thu nhỏ và thời lượng cho video. Mỗi định dạng này đòi hỏi đúng loại schema tương ứng, và Google chỉ trao nó khi dữ liệu của bạn hợp lệ và khớp với nội dung người dùng thực sự thấy.

Vì sao điều này đáng giá? Vì trên một trang kết quả chật chội, diện tích là tất cả. Một kết quả có sao và FAQ bung ra có thể chiếm gấp đôi gấp ba chiều cao một kết quả thường. Trong các thử nghiệm thường thấy, một kết quả giàu định dạng kéo tỷ lệ nhấp cao hơn rõ rệt so với cùng thứ hạng nhưng trơ trọi — không phải vì bạn lên hạng cao hơn, mà vì bạn hút mắt và hút lòng tin tốt hơn ngay tại vị trí đang có. Nói cách khác, rich results là cách bạn "thắng" mà không cần leo hạng.

Phần thưởng thứ hai mới hơn nhưng đang lớn nhanh: khả năng được AI trích dẫn. Khi Google hiển thị AI Overview — đoạn tóm tắt do AI tạo ngay đầu trang kết quả — hay khi các trợ lý AI khác trả lời người dùng, chúng phải nhanh chóng hiểu và tin một nguồn trước khi trích dẫn. Một trang đã khai báo rõ ràng kiểu nội dung, tác giả, ngày tháng và cấu trúc câu hỏi–câu trả lời sẽ dễ được máy bóc tách chính xác hơn nhiều so với một trang để máy tự đoán. Dữ liệu có cấu trúc không đảm bảo bạn được trích, nhưng nó loại bỏ một rào cản hiểu lầm — và trong một cuộc đua mà mọi nguồn đều cạnh tranh để được AI chọn, bớt một rào cản là một lợi thế thật. Nếu bạn muốn đào sâu cách viết nội dung để máy dễ trích, bài tối ưu nội dung cho AI Overview của Google đi kèm rất tốt với phần kỹ thuật ở đây.

Một lưu ý trung thực: dữ liệu có cấu trúc là điều kiện cần chứ không phải điều kiện đủ. Nếu nội dung mỏng, không đáng tin, hoặc trang vi phạm chính sách, schema đẹp đến mấy cũng không cứu được. Hãy coi nó là tấm vé vào cửa — bạn vẫn phải có nội dung xứng đáng để được trao phần thưởng.

Năm loại schema đáng làm trước tiên

Schema.org có hàng trăm kiểu, nhưng với phần lớn website Việt — blog, doanh nghiệp dịch vụ, SaaS, thương mại điện tử — chỉ một nhóm nhỏ mang lại gần như toàn bộ giá trị. Đừng cố phủ kín mọi kiểu; hãy làm đúng năm loại sau và làm cho chuẩn.

Article — cho mọi bài blog, tin tức, hướng dẫn

Đây là loại schema bạn dùng nhiều nhất nếu bạn xuất bản nội dung. Nó khai báo cho máy biết đây là một bài viết: tiêu đề là gì, ai là tác giả, đơn vị xuất bản là ai, đăng ngày nào và cập nhật lần cuối khi nào, ảnh đại diện ra sao. Những thông tin này nuôi tín hiệu E-E-A-T (kinh nghiệm, chuyên môn, thẩm quyền, độ tin cậy) — đặc biệt là tác giả và ngày tháng, hai thứ AI rất hay dùng để cân nhắc có nên tin và trích một nguồn hay không. Một blog không khai báo Article vẫn có thể được index, nhưng nó tự tước đi cách nói rõ ràng nhất "bài này do người này viết, mới đến mức này".

FAQPage — cho trang có câu hỏi thường gặp thật

FAQ schema từng là ngôi sao của rich results vì nó cho phép các câu hỏi bung ra ngay dưới kết quả của bạn, chiếm nhiều diện tích đáng kể. Google đã siết lại việc hiển thị FAQ rich result (chủ yếu ưu tiên cho website uy tín cao), nên đừng kỳ vọng mọi trang FAQ đều bung ra như xưa. Nhưng schema này vẫn rất đáng làm vì hai lý do: nó giúp máy đọc trang của bạn theo đúng cặp câu hỏi–câu trả lời, và đó chính là định dạng mà AI Overview thích trích nhất. Điều kiện duy nhất, và là điều kiện bắt buộc: các câu hỏi và câu trả lời trong schema phải thật sự hiển thị trên trang cho người dùng đọc — không được nhồi câu hỏi ẩn chỉ để chiếm chỗ.

Product — cho trang bán hàng và trang gói dịch vụ

Nếu bạn bán sản phẩm hay gói dịch vụ, Product schema là thứ mở khoá những hiển thị có sức bán hàng nhất: giá, tình trạng còn hàng, và đặc biệt là số sao đánh giá. Một kết quả có 4,8 sao trên trang tìm kiếm tạo lòng tin trước cả khi người ta nhấp vào. Lưu ý quan trọng cho thị trường Việt: khai báo đúng đơn vị tiền là VND và giá khớp chính xác với giá hiển thị; nếu schema ghi một giá còn trang ghi giá khác, Google sẽ coi đó là dữ liệu sai và có thể phạt nhẹ bằng cách ngừng hiển thị rich result cho cả site.

BreadcrumbList — cho cấu trúc phân cấp của site

Breadcrumb là đường dẫn phân cấp "Trang chủ › Danh mục › Trang hiện tại". Khi khai báo, Google thay URL thô trong kết quả bằng đường dẫn đẹp, dễ đọc này — vừa gọn vừa giúp người dùng hiểu trang nằm ở đâu trong site. Đây là loại schema dễ làm, ít rủi ro, và gần như mọi site có nhiều tầng nội dung đều nên có.

Organization — khai báo danh tính thương hiệu một lần

Organization schema (thường đặt ở trang chủ) khai báo bạn là ai với tư cách một thực thể: tên thương hiệu chính thức, logo, đường dẫn các kênh mạng xã hội chính thức, thông tin liên hệ. Nó là nền móng để Google xây Knowledge Panel (khung thông tin thương hiệu bên phải kết quả) và để các cỗ máy liên kết mọi nội dung của bạn về cùng một thực thể đáng tin. Bạn chỉ cần khai báo nó một lần cho cả site, nhưng nó là tín hiệu danh tính nền tảng mà nhiều site Việt bỏ quên.

JSON-LD: cú pháp duy nhất bạn nên dùng

Có ba cách kỹ thuật để đưa dữ liệu có cấu trúc vào trang: Microdata và RDFa (trộn các thuộc tính vào thẳng thẻ HTML hiển thị), và JSON-LD (một khối mã riêng, tách biệt khỏi phần HTML người dùng thấy). Cuộc tranh luận này đã ngã ngũ từ lâu: Google khuyến nghị rõ ràng JSON-LD, và đó là cú pháp duy nhất bạn nên học và dùng năm 2026.

Lý do JSON-LD thắng rất thực tế. Vì nó là một khối tách biệt — thường đặt trong thẻ <script type="application/ld+json"> ở phần đầu trang — bạn có thể chỉnh sửa dữ liệu mà không đụng vào HTML hiển thị, không sợ làm vỡ giao diện. Nó dễ đọc, dễ tạo tự động, dễ kiểm thử, và dễ tách ra khỏi nội dung. Microdata trộn thuộc tính vào từng thẻ khiến mã rối và mỗi lần đổi giao diện là một lần rủi ro làm hỏng schema. Với JSON-LD, lớp dữ liệu và lớp giao diện sống tách nhau, đúng như tinh thần "lớp ngữ nghĩa cho máy" mà phần đầu bài đã nói.

Về mặt thực hành, một khối JSON-LD cho một bài viết trông như một danh sách cặp "thuộc tính: giá trị": khai báo @context trỏ về Schema.org, @type là "Article", rồi headline (tiêu đề), author (tên tác giả), publisher (đơn vị xuất bản kèm logo), datePublished và dateModified (ngày đăng và ngày cập nhật theo định dạng chuẩn ISO), image (ảnh đại diện). Bạn không cần thuộc lòng cú pháp — phần lớn nền tảng có cách sinh nó tự động — nhưng bạn cần hiểu nó khai báo cái gì để kiểm tra xem nó có đúng không. Nếu site bạn chạy trên một CMS phổ biến, thường đã có sẵn plugin sinh JSON-LD; việc của bạn chuyển từ "viết tay" sang "cấu hình đúng và kiểm thử kỹ".

Một nguyên tắc bất di bất dịch xuyên suốt: mọi thứ bạn khai báo trong JSON-LD phải phản ánh trung thực nội dung người dùng thực sự thấy trên trang. Schema không phải nơi để "trang trí" thêm thông tin không có trên trang. Khai báo một tác giả không tồn tại, một đánh giá bịa, một câu FAQ không hiển thị — tất cả đều vi phạm chính sách và có thể khiến cả site mất quyền hiển thị rich result. Dữ liệu có cấu trúc là lời tuyên bố có trách nhiệm, không phải lớp sơn phủ.

Kiểm thử bằng Rich Results Test trước khi tin nó chạy

Đây là bước mà rất nhiều người bỏ qua rồi tự hỏi vì sao schema "đã gắn" mà không có rich result nào. Bạn không bao giờ nên đoán schema của mình hợp lệ — bạn phải kiểm thử nó bằng công cụ chính thức của Google trước khi tin nó chạy.

Công cụ trọng tâm là Rich Results Test của Google. Bạn dán URL trang (hoặc dán thẳng đoạn mã) vào, công cụ sẽ phân tích và cho biết: trang đủ điều kiện cho những loại rich result nào, schema có lỗi nghiêm trọng nào (lỗi sẽ chặn hiển thị hoàn toàn), và có cảnh báo nào (không chặn nhưng nên sửa để đầy đủ hơn). Hãy phân biệt rõ hai mức này: lỗi (error) là thứ phải sửa ngay vì nó vô hiệu hoá rich result; cảnh báo (warning) là thứ nên sửa khi có thời gian để dữ liệu giàu hơn, nhưng không khẩn cấp.

Một công cụ bổ trợ là Schema Markup Validator của Schema.org, dùng khi bạn muốn kiểm tra một schema không thuộc danh mục rich result của Google nhưng vẫn cần đúng cú pháp Schema.org. Và đừng quên Google Search Console: trong báo cáo Enhancements, nó cho bạn thấy theo thời gian những trang nào có schema hợp lệ, trang nào đang lỗi trên toàn site — đây là nơi bạn theo dõi sức khoẻ schema ở quy mô lớn, sau khi đã kiểm từng trang bằng Rich Results Test.

Quy trình kiểm thử lành mạnh có ba nhịp. Trước khi xuất bản: chạy Rich Results Test trên bản nháp hoặc trên đoạn mã để bắt lỗi sớm. Ngay sau khi xuất bản: chạy lại trên URL thật để chắc schema lên đúng trên môi trường thật, vì đôi khi CMS hay tầng cache làm sai lệch. Định kỳ sau đó: theo dõi báo cáo trong Search Console để phát hiện khi một thay đổi giao diện hay một bản cập nhật vô tình làm hỏng schema hàng loạt. Schema không phải làm một lần xong quên — nó là thứ cần được canh giữ.

Những sai lầm thường gặp khiến công sức đổ sông đổ biển

Phần lớn các trường hợp "đã làm schema mà không có gì xảy ra" rơi vào một nhóm lỗi quen thuộc. Biết trước chúng giúp bạn tiết kiệm hàng giờ gỡ rối.

Sai lầm lớn nhất: schema không khớp nội dung hiển thị. Bạn khai báo một giá trong Product nhưng trang ghi giá khác; khai báo 4,9 sao nhưng trên trang không có hệ thống đánh giá nào; nhồi mười câu FAQ trong schema nhưng trang chỉ hiển thị ba. Đây là vi phạm chính sách nghiêm trọng nhất, và hậu quả không chỉ là mất rich result của trang đó mà có thể là mất quyền hiển thị rich result cho cả site. Nguyên tắc vàng: schema mô tả, không phát minh.

Đánh dấu (markup) đúng nhưng nội dung không xứng đáng. Nhiều người tưởng gắn FAQ schema là tự nhiên có FAQ bung ra, gắn Product schema là tự nhiên có sao. Không phải vậy. Schema chỉ làm cho trang đủ điều kiện; Google vẫn quyết định có trao rich result hay không dựa trên chất lượng và độ tin cậy của trang. Schema chuẩn trên một trang mỏng vẫn ra về tay trắng.

Khai báo sai loại schema cho nội dung. Dùng Article cho một trang sản phẩm, hay nhồi FAQPage vào một trang vốn không phải câu hỏi thường gặp, khiến máy hiểu sai bản chất trang. Hãy chọn loại schema khớp đúng với những gì người dùng thực sự thấy: trang blog dùng Article, trang bán hàng dùng Product, và đừng cố ép.

Bỏ trống các thuộc tính bắt buộc. Mỗi loại rich result có một bộ thuộc tính bắt buộc; thiếu một trong số đó là schema vẫn "có" nhưng không đủ điều kiện hiển thị. Đây chính là lý do bước kiểm thử bằng Rich Results Test quan trọng — nó chỉ thẳng cho bạn thuộc tính nào còn thiếu, thay vì để bạn tự đoán.

Lỗi cú pháp nhỏ làm hỏng cả khối. Một dấu phẩy thừa, một ngoặc thiếu, một ngày tháng sai định dạng — JSON rất khó tính, chỉ một ký tự sai là cả khối bị máy bỏ qua. Lại một lần nữa, công cụ kiểm thử bắt được những lỗi này trong vài giây, còn mắt người thì không.

Gắn schema rồi quên nó tồn tại. Bạn đổi theme, đổi plugin, đổi cấu trúc URL — và schema âm thầm hỏng mà không ai hay, cho đến khi rich result biến mất hàng loạt. Hãy đặt lịch ngó lại báo cáo Enhancements trong Search Console định kỳ, coi schema là một phần hạ tầng cần bảo trì chứ không phải việc làm một lần.

Nếu bạn từng nghe những lời đồn nửa đúng nửa sai về schema — kiểu "cứ gắn nhiều schema là lên top" hay "FAQ schema đã chết" — thì bài những lầm tưởng về schema markup bóc tách kỹ từng ngộ nhận, rất nên đọc kèm để khỏi mất công làm sai.

Một lộ trình triển khai cho web Việt

Lý thuyết là vậy, còn bắt tay vào thì làm theo thứ tự nào để không loạn? Đây là lộ trình gọn cho một website Việt điển hình, sắp theo tỷ lệ "công sức bỏ ra so với phần thưởng nhận được".

1. Khai báo Organization ở trang chủ. Làm một lần, đặt nền móng danh tính thương hiệu cho cả site. Tên chính thức, logo, các kênh mạng xã hội thật, liên hệ.
2. Gắn BreadcrumbList cho toàn bộ trang nhiều tầng. Dễ làm, ít rủi ro, giúp kết quả gọn đẹp ngay.
3. Gắn Article cho mọi bài blog và hướng dẫn. Khai báo đầy đủ tác giả và ngày tháng — đây là tín hiệu E-E-A-T mà AI rất hay dùng để chọn nguồn trích.
4. Gắn Product cho trang bán hàng và trang gói. Cẩn thận giá VND khớp tuyệt đối với giá hiển thị; chỉ khai báo đánh giá khi trang thật sự có hệ thống đánh giá.
5. Gắn FAQPage cho trang FAQ thật. Câu hỏi và câu trả lời phải hiển thị thật trên trang, không nhồi ẩn.
6. Kiểm thử từng loại bằng Rich Results Test, rồi theo dõi Search Console. Trước và sau khi xuất bản, rồi định kỳ.

Lưu ý riêng cho thị trường Việt: định dạng đơn vị tiền (VND), định dạng ngày tháng theo chuẩn ISO trong schema dù trang hiển thị theo kiểu Việt, và tên tác giả viết đúng có dấu — những chi tiết nhỏ này hay bị làm ẩu và là lý do nhiều site Việt khai báo schema mà vẫn không lên rich result. Đừng coi nhẹ chúng.

Một lời nhắc về bối cảnh: dữ liệu có cấu trúc đang trở nên quan trọng hơn chứ không phải kém đi, chính vì cuộc dịch chuyển sang tìm kiếm bằng AI. Khi ngày càng nhiều người nhận câu trả lời từ AI Overview thay vì cuộn qua mười kết quả xanh, việc máy hiểu và tin trang của bạn nhanh chóng trở thành lằn ranh giữa được trích và bị bỏ qua. Nếu bạn còn mơ hồ AI Overview là gì và nó thay đổi luật chơi ra sao với website Việt, bài AI Overview là gì và ý nghĩa với website Việt dựng bức tranh nền rất rõ trước khi bạn lao vào phần kỹ thuật của schema.

Đo lường và canh giữ theo thời gian

Sau khi đã gắn và kiểm thử, làm sao biết schema đang thực sự đem lại giá trị? Đừng đo bằng cảm giác — đo bằng dữ liệu cụ thể trong Search Console.

Có ba chỉ số đáng nhìn. Thứ nhất, trong báo cáo Enhancements, theo dõi số trang có schema hợp lệ tăng dần và số trang lỗi tiến về không — đây là sức khoẻ kỹ thuật của lớp dữ liệu. Thứ hai, trong báo cáo Performance, lọc theo các trang đã gắn schema và quan sát tỷ lệ nhấp (CTR): nếu rich result đang hoạt động, CTR ở cùng vị trí thường nhích lên vì kết quả của bạn nổi bật hơn. Thứ ba, để mắt tới các truy vấn mà bạn xuất hiện trong AI Overview — đây là tín hiệu mới và còn khó đo chính xác, nhưng xu hướng được trích nhiều hơn theo thời gian là dấu hiệu lớp ngữ nghĩa đang giúp máy tin bạn.

Và hãy nhớ canh giữ. Mỗi lần website của bạn thay đổi lớn — đổi giao diện, nâng cấp nền tảng, đổi cấu trúc đường dẫn, gỡ hay thay plugin — hãy coi đó là một thời điểm rủi ro cho schema và chạy lại Rich Results Test trên vài trang đại diện. Phần lớn các vụ "rich result tự dưng biến mất" không phải do Google đổi luật mà do một thay đổi nội bộ vô tình làm vỡ khối JSON-LD. Một thói quen kiểm tra sau mỗi lần triển khai lớn tiết kiệm cho bạn rất nhiều ngày hoang mang.

Đây là loại việc đáng để tự động hoá

Khi nhìn lại toàn bộ playbook này, bạn sẽ nhận ra điểm chung của mọi việc: chúng có cấu trúc, lặp lại, và phải làm đúng cho từng trang một, mãi mãi. Mỗi bài mới cần Article schema với đúng tác giả, đúng ngày; mỗi sản phẩm cần Product schema với giá khớp tuyệt đối; mỗi lần xuất bản cần một vòng kiểm thử; mỗi lần đổi giao diện cần một vòng rà soát lại toàn site. Đây đúng là loại công việc tỉ mỉ, không sai số, dễ làm một đội nhỏ quá tải và dễ bị bỏ sót khi guồng quay nội dung tăng tốc.

Đây chính là khối lượng mà một AI agent làm SEO sinh ra để gánh. Orova có thể sinh JSON-LD đúng loại cho từng trang, kiểm tính nhất quán giữa schema và nội dung hiển thị, và canh chừng để khi một thay đổi vô tình làm hỏng dữ liệu có cấu trúc thì bạn biết ngay thay vì phát hiện sau khi rich result đã biến mất hàng tuần. Nó không thay bạn quyết định nội dung nào xứng đáng được phần thưởng — phán đoán đó vẫn là của bạn — nhưng nó xoá đi phần việc lặp lại có cấu trúc đã khiến lớp dữ liệu này bị bỏ bê ở quá nhiều website. Hãy làm chuẩn năm loại schema, kiểm thử trước khi tin, và để phần canh giữ tỉ mỉ cho thứ được sinh ra để làm việc đó không biết mệt.