Structured data: dùng schema đúng nội dung website
Chọn Article, Breadcrumb và các schema phù hợp; khớp nội dung hiển thị, kiểm JSON-LD, hình ảnh và URL, tránh dữ liệu đánh giá giả.
Cập nhật: · Minh họa được tạo bằng AI
Structured data mô tả nội dung theo một định dạng máy có thể đọc. Nó có thể giúp hệ thống hiểu một trang là bài viết, sản phẩm hoặc đường phân cấp, nhưng không tạo ra dữ kiện thật thay cho nội dung. Thêm schema không bảo đảm rich result và không sửa được một trang mơ hồ.
Một website doanh nghiệp nhỏ nên bắt đầu từ kiểu nội dung đang có và tài liệu hỗ trợ chính thức, thay vì cài mọi loại schema một plugin cung cấp. Bài viết tập trung vào lựa chọn, dữ liệu và kiểm tra, không đưa ra lời hứa xếp hạng.
1. Chọn schema từ nhiệm vụ của trang
Một bài chia sẻ kiến thức có thể dùng Article hoặc BlogPosting, đường phân cấp dùng BreadcrumbList. Trang sản phẩm cần dữ liệu sản phẩm và điều kiện tương ứng. Không gắn LocalBusiness cho một địa điểm giả hoặc Product cho một bài blog chỉ để mong thêm hiển thị.
Google về structured data giải thích cách hệ thống sử dụng dữ liệu, còn Schema.org mô tả từ vựng rộng hơn. Một kiểu tồn tại trong Schema.org không đồng nghĩa Google hỗ trợ rich result cho kiểu đó. Kiểm tài liệu riêng của tính năng bạn muốn dùng.
2. Dữ liệu phải khớp nội dung nhìn thấy
Tiêu đề, tác giả, ngày xuất bản, ngày sửa và ảnh trong article schema nên khớp bài đang hiển thị. Ảnh cần là URL truy cập được và thật sự liên quan, không phải một ảnh mặc định dùng cho mọi bài khi bài có thumbnail riêng. Ngày sửa chỉ thay khi nội dung hoặc thông tin quan trọng được cập nhật.
Không thêm review, aggregateRating hoặc số lượng khách nếu không có dữ liệu hợp lệ và đáp ứng điều kiện tính năng. Lời nhận xét tự viết rồi gắn điểm sao không trở thành chứng cứ vì nó nằm trong JSON-LD. Google về chất lượng structured data là nguồn cần đọc trước khi triển khai.
3. Nối URL, ngôn ngữ và danh tính nhất quán
Giữ canonical, mainEntityOfPage, URL trong breadcrumb và URL bài viết cùng hướng tới bản nội dung đúng. Nếu có tiếng Việt và tiếng Anh với địa chỉ riêng, dùng inLanguage theo bản đang đọc và khai báo alternate đúng. Không dùng một schema tiếng Việt trên trang chỉ có nội dung tiếng Anh.
Có thể dùng @id ổn định để liên hệ các đối tượng trong graph, nhưng không cần biến website nhỏ thành mạng dữ liệu phức tạp. Danh tính tác giả và publisher phải phản ánh người hoặc tổ chức thực. Ghi URL giới thiệu phù hợp thay vì một hồ sơ mạng xã hội không thuộc chủ thể.
4. Kiểm cú pháp và điều kiện tính năng riêng
JSON hợp lệ mới là bước đầu. Sau đó kiểm property cần có, URL ảnh, kiểu giá trị và điều kiện tính năng. Rich Results Test là công cụ kiểm các rich result được hỗ trợ; một kiểu không hiện trong công cụ không nhất thiết là JSON sai. Dùng validator phù hợp khi kiểm từ vựng rộng hơn.
Kiểm HTML server trả và DOM sau tải nếu dữ liệu được sinh bằng JavaScript. Một screenshot không cho thấy JSON-LD, và một JSON đúng trên máy local không chứng minh nó được phát hành lên domain đúng. Ghi URL, thời điểm, kết quả và lỗi còn lại để người tiếp theo có thể lặp.
5. Tránh schema trùng từ nhiều plugin
Theme, plugin SEO, plugin thương mại và mã riêng có thể cùng sinh dữ liệu. Kiểm trang thực để xem có nhiều Article hoặc Product nói thông tin khác nhau không. Không xóa mù quáng một block chỉ vì trông giống nhau; xác định chủ sở hữu và mục đích của từng block.
Khi đổi thumbnail hoặc metadata, cập nhật nguồn dùng chung để social image và schema cùng đúng. Sau khi sửa, kiểm lại một mẫu mỗi template và những biến thể ngôn ngữ. Dùng checklist SEO kỹ thuật để nối việc schema với canonical, sitemap và lỗi truy cập.
6. Theo dõi sau phát hành với giới hạn đúng
Kiểm trang public và báo cáo Search Console khi có quyền. Nếu công cụ báo valid, ghi valid trong phạm vi công cụ đã kiểm. Không chuyển thành ‘Google chắc chắn hiển thị sao’ hoặc ‘SEO đã tăng’. Việc hiển thị còn tùy hệ thống và điều kiện từng tính năng.
Tạo checklist khi bài được sửa: title, excerpt, ảnh, ngày, URL, ngôn ngữ và người tạo. Nếu dữ kiện nguồn thay đổi, sửa cả nội dung lẫn markup. Dữ liệu có cấu trúc hữu ích khi nó làm rõ nội dung đáng tin, không khi nó trang trí những khẳng định chưa có căn cứ.
Câu hỏi thường gặp
Có nên thêm FAQ schema cho mọi bài?
Chỉ dùng khi đúng nội dung và điều kiện hỗ trợ hiện tại. Có phần câu hỏi hữu ích trong bài không có nghĩa website sẽ đủ điều kiện FAQ rich result. Kiểm tài liệu tính năng trước, không thêm chỉ để tăng số schema.
Nguồn tham khảo và đọc tiếp
Bạn cần áp dụng vào website hiện tại? Xem dịch vụ SEO hoặc trao đổi với Dean Vu để xác định phạm vi dựa trên website và dữ liệu thực tế.