Vì sao thẻ schema đơn lẻ là chưa đủ?
Phần lớn website dừng ở mức gắn vài thẻ rời rạc: một Organization ở trang chủ, một FAQPage ở trang hỏi đáp, một Product ở trang sản phẩm. Với máy, đó là ba mảnh ghép không biết có liên quan nhau không. Công cụ AI xây dựng hiểu biết theo thực thể và quan hệ: sản phẩm này của tổ chức nào, bài viết này do ai viết, người đó làm việc cho tổ chức nào. Nếu các thẻ không nối nhau, máy phải tự suy — và khi phải suy, nó thường chọn nguồn khác rõ ràng hơn. Nền móng xem tại dữ liệu có cấu trúc cơ bản.
JSON-LD lồng nhau với @graph hoạt động thế nào?
Thay vì nhiều khối JSON-LD rời, bạn khai báo một khối duy nhất chứa mảng @graph: mỗi thực thể là một nút có @id riêng (thường là URL kèm neo, ví dụ https://example.com/#org), và các thực thể tham chiếu nhau qua chính @id đó. Trang sản phẩm khai báo Product có trường brand và manufacturer trỏ về @id của Organization; bài viết khai báo author trỏ về @id của Person, và Person có worksFor trỏ về Organization. Kết quả là một đồ thị mini ngay trong HTML — máy đọc một lần, hiểu toàn bộ cấu trúc.
Neo thực thể bằng sameAs có ý nghĩa gì?
sameAs là cách bạn nói với máy: «tổ chức này chính là thực thể đã được ghi nhận ở đó». Trỏ về Wikidata, Wikipedia, Hồ sơ doanh nghiệp, tài khoản mạng xã hội chính thức giúp công cụ AI khử nhập nhằng tên gọi — đặc biệt quan trọng với tên thương hiệu dễ trùng hoặc tên tiếng Việt có nhiều cách viết Latinh. Khi đồ thị trong website khớp với thực thể trong đồ thị tri thức bên ngoài, giai đoạn grounding có đủ điểm neo để xác nhận danh tính. Chi tiết xem tại thực thể và đồ thị tri thức và Knowledge Panel.
Checklist hành động
- Chuẩn hóa một @id duy nhất cho mỗi thực thể lõi (tổ chức, sản phẩm chính, người đại diện) và dùng nhất quán trên toàn website
- Gom JSON-LD về một khối @graph mỗi trang, tránh nhiều khối rời trùng lặp thông tin
- Khai báo sameAs trỏ về Wikidata, Wikipedia (nếu có), mạng xã hội chính thức — chỉ trỏ nguồn thật sự là bạn
- Nối quan hệ đầy đủ: Product → Organization, Article → Person → Organization
- Kiểm tra bằng công cụ xác thực schema và Rich Results Test sau mỗi lần triển khai
- Bảo đảm nội dung trong JSON-LD khớp từng chữ với nội dung hiển thị — lệch nhau là tín hiệu bất tin
Sai lầm thường gặp
Lỗi đầu tiên là khai báo dữ liệu không có trên trang: gắn AggregateRating ảo hoặc thông số không hiển thị cho người đọc — vừa vi phạm chính sách Google vừa tạo mâu thuẫn khi grounding đối chiếu. Lỗi thứ hai là trùng lặp: nhiều plugin cùng xuất Organization với thông tin hơi khác nhau, tạo «hai thực thể» làm máy phân vân. Lỗi thứ ba là lạm dụng sameAs trỏ bừa: trỏ về thực thể Wikidata của người khác còn tệ hơn không trỏ. Lỗi thứ tư là cho rằng schema «có là tốt» bất kể chất lượng — schema sai còn nguy hiểm hơn không có, vì nó đưa thông tin sai vào thẳng kênh máy đọc tin cậy nhất.
Ưu tiên triển khai theo thứ tự nào?
Với website chưa có gì, thứ tự hợp lý: một, Organization toàn cục với @id và sameAs chuẩn; hai, LocalBusiness (nếu có địa điểm) khớp với Hồ sơ doanh nghiệp; ba, Product/Service trên các trang thương mại chính; bốn, Article kèm Person cho nội dung chuyên môn; năm, FAQPage cho cụm câu hỏi trụ cột. Mỗi lớp triển khai xong đều kiểm chứng bằng công cụ xác thực trước khi sang lớp tiếp theo. Sau khi đồ thị trong website ổn định, bước tiếp theo là đồng bộ thực thể bên ngoài qua Wikipedia và Wikidata để khép kín vòng neo danh tính.