Schema Markup: Triển Khai Structured Data Không Spam

Một đoạn JSON-LD hợp lệ có thể vượt qua Rich Results Test nhưng vẫn không tạo rich result. Điều này không phải lỗi của công cụ. Structured data chỉ giúp mô tả nội dung bằng ngôn ngữ có cấu trúc; nó không thay thế nội dung, không bảo đảm hiển thị và không phải nút tăng hạng.

Sai lầm phổ biến là bắt đầu bằng câu “website cần thêm loại schema nào?”. Câu hỏi đúng hơn là: trang này đang nói về thực thể gì, thông tin nào người dùng thật sự nhìn thấy, và Google hiện hỗ trợ cách trình bày nào cho loại nội dung đó?

Structured data và schema markup khác nhau thế nào?

Structured data là dữ liệu được tổ chức theo một định dạng máy có thể đọc. Schema.org là bộ từ vựng mô tả các loại thực thể và thuộc tính. Schema markup là cách đưa từ vựng đó vào trang bằng JSON-LD, Microdata hoặc RDFa.

Google Search hỗ trợ cả ba định dạng cho nhiều tính năng, thường khuyến nghị JSON-LD vì dễ tách khỏi HTML trình bày và dễ bảo trì. Tuy nhiên, định dạng không cứu được dữ liệu sai. Một Product viết bằng JSON-LD hoàn hảo nhưng khai giá không tồn tại trên trang vẫn vi phạm nguyên tắc nhất quán.

Schema có làm tăng thứ hạng không?

Không nên bán schema như một yếu tố tăng hạng trực tiếp. Structured data có thể giúp hệ thống hiểu trang rõ hơn và làm nội dung đủ điều kiện cho một số rich result. Cách hiển thị nổi bật hơn có thể ảnh hưởng CTR trong vài trường hợp, nhưng Google không bảo đảm rich result xuất hiện ngay cả khi markup đúng.

Kết quả còn phụ thuộc:

• Trang có được crawl và index hay không.
• Nội dung có đáp ứng chính sách Search và chính sách riêng của tính năng.
• Dữ liệu có đúng, đầy đủ, cập nhật và nhìn thấy trên trang không.
• Truy vấn, thiết bị, khu vực và cách Google chọn trình bày.
• Tính năng đó có còn được hỗ trợ theo tài liệu hiện hành không.

Vì danh sách rich result có thể thay đổi, hãy kiểm tra Search Gallery chính thức thay vì dựa vào bài hướng dẫn cũ hoặc danh sách của plugin.

Chọn loại schema từ nội dung chính

Đừng đánh dấu mọi trang bằng mọi loại có vẻ liên quan. Hãy xác định main entity:

• Bài blog hoặc tin tức: Article, BlogPosting hoặc loại cụ thể phù hợp.
• Trang sản phẩm mua được: Product với offer, giá và tình trạng thực.
• Doanh nghiệp có địa điểm: LocalBusiness hoặc subtype chính xác.
• Công thức nấu ăn: Recipe.
• Video là nội dung chính: VideoObject.
• Hồ sơ tổ chức: Organization.
• Đường dẫn phân cấp: BreadcrumbList.

Trang danh mục liệt kê sản phẩm không tự động là một Product. Bài viết nói về cách chọn laptop không nên khai chính nó là sản phẩm chỉ vì nhắc nhiều model. Loại schema phải đại diện cho điều trang thực sự cung cấp.

Bắt đầu từ dữ liệu nguồn, không bắt đầu từ chuỗi JSON

Schema bền vững được sinh từ cùng nguồn dữ liệu đang render cho người dùng:

Nếu template hiển thị giá từ database nhưng JSON-LD chứa một con số nhập tay trong CMS, hai bên sẽ lệch vào ngày khuyến mãi đầu tiên. Dữ liệu có cấu trúc nên là một cách biểu diễn khác của cùng sự thật, không phải một kho nội dung thứ hai.

Ví dụ BlogPosting tối giản

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/seo-hinh-anh#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/seo-hinh-anh"
  },
  "headline": "SEO hình ảnh và alt text",
  "image": [
    "https://example.com/images/seo-hinh-anh-1200x630.png"
  ],
  "datePublished": "2026-06-10T08:00:00+07:00",
  "dateModified": "2026-06-15T09:30:00+07:00",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/tac-gia/lan#person",
    "name": "Nguyễn Lan",
    "url": "https://example.com/tac-gia/lan"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example",
    "url": "https://example.com/"
  }
}
</script>

Ví dụ này chỉ minh họa cấu trúc. Khi triển khai, đối chiếu các thuộc tính bắt buộc và khuyến nghị trong tài liệu dành riêng cho Article. Đừng sao chép ngày, URL hoặc tác giả mẫu lên production.

@id giúp nối thực thể ổn định

@id không nhất thiết là một trang người dùng mở riêng; nó là định danh ổn định trong graph, thường dùng URL tuyệt đối kèm fragment:

• https://example.com/#organization
• https://example.com/#website
• https://example.com/tac-gia/lan#person
• https://example.com/san-pham/a#product

Khi publisher trong bài và Organization toàn site cùng tham chiếu một @id, hệ thống thấy đó là một thực thể thay vì hai object tên giống nhau nhưng không có quan hệ.

Định danh cần ổn định qua các lần render. Đừng tạo UUID ngẫu nhiên mới mỗi request. Đồng thời tránh dùng một @id cho hai thực thể khác nhau, chẳng hạn tổ chức và website.

Nhiều item trên một trang

Một trang có thể có nhiều khối structured data hợp lệ:

• WebPage mô tả trang.
• BlogPosting mô tả bài.
• BreadcrumbList mô tả đường dẫn.
• Organization hoặc Person được tham chiếu làm publisher, author.
• VideoObject cho video chính được nhúng.

Có thể đặt object riêng hoặc nối bằng @graph. Điều quan trọng là quan hệ đúng và không mâu thuẫn. Nếu video chỉ là quảng cáo không liên quan, thêm VideoObject để săn video rich result là sai mục đích.

Không cần lặp toàn bộ Organization dài trên mọi node. Khai một thực thể chuẩn và tham chiếu bằng @id giúp graph gọn hơn.

Required và recommended properties

Tài liệu của mỗi tính năng chia thuộc tính thành bắt buộc và khuyến nghị. Thiếu required khiến item không đủ điều kiện. Recommended giúp kết quả đầy đủ hơn nhưng chỉ nên khai khi có dữ liệu thật.

Một nguyên tắc tốt là ít nhưng chính xác và đầy đủ. Đừng thêm:

• aggregateRating khi chưa có đánh giá thật.
• priceValidUntil bằng ngày bịa để qua warning.
• author là “Admin” nếu trang không có hồ sơ hoặc trách nhiệm biên tập.
• image là logo chung không đại diện nội dung.
• sameAs trỏ tới profile không thuộc thực thể.

Warning trong test không phải mệnh lệnh điền dữ liệu giả. Nó cho biết thuộc tính khuyến nghị đang thiếu; đội sản phẩm quyết định có nguồn tin cậy để bổ sung hay không.

Nội dung markup phải nhìn thấy và nhất quán

Google yêu cầu structured data đại diện đúng nội dung chính và không mô tả thông tin bị giấu khỏi người đọc. Các trường hợp rủi ro:

• JSON-LD báo giá 990.000 đồng nhưng trang hiển thị “liên hệ”.
• Schema ghi còn hàng trong khi nút mua bị khóa.
• Markup có năm đánh giá 5 sao nhưng trang không hiển thị đánh giá.
• FAQ trong JSON-LD không tồn tại trong nội dung.
• JobPosting đã hết hạn nhưng vẫn có validThrough tương lai.

“Nhìn thấy” không có nghĩa mọi thuộc tính kỹ thuật phải thành một đoạn chữ thô. URL, ID và quan hệ graph có thể là metadata. Nhưng các claim người dùng quan tâm như giá, rating, sự kiện, câu hỏi và tác giả phải tương ứng với trải nghiệm.

Product schema: nơi lỗi dữ liệu xuất hiện nhanh nhất

Giá và tồn kho thay đổi liên tục. Product markup cần được tạo trong cùng request hoặc pipeline với giao diện. Hãy thống nhất:

• Tiền tệ theo ISO phù hợp.
• Số giá không có ký hiệu hoặc format khó parse trong trường dữ liệu.
• Availability dùng URL schema.org chính xác.
• Offer thuộc đúng variant.
• Canonical của variant và Product ID nhất quán.
• Rating chỉ tổng hợp review hợp lệ của chính sản phẩm.

Với sản phẩm nhiều biến thể, đọc tài liệu product variants thay vì gộp giá, màu và SKU tùy ý vào một object. Nếu trang không cho mua hoặc không có offer thật, đừng tạo offer giả chỉ để hết lỗi.

LocalBusiness: đừng nhân bản địa điểm bằng template rỗng

Mỗi địa điểm nên có tên, địa chỉ, số điện thoại, giờ hoạt động, khu vực phục vụ và URL đúng thực tế. Trang chi nhánh cũng phải cung cấp nội dung hữu ích tương ứng. Tạo 200 URL thành phố giống nhau rồi thêm LocalBusiness không biến chúng thành 200 cơ sở.

Thông tin schema nên khớp với trang liên hệ, hồ sơ doanh nghiệp và dữ liệu được quản lý nội bộ. Khi đổi giờ lễ, cập nhật cả giao diện lẫn nguồn JSON-LD.

Review và rating là vùng dễ thành spam

Không đánh dấu:

• Đánh giá do chính doanh nghiệp tự viết.
• Rating lấy từ một sản phẩm khác.
• Điểm tổng hợp không có review nguồn.
• Testimonial chung của công ty như rating cho mọi dịch vụ.
• Dữ liệu ẩn chỉ tồn tại trong script.

Vi phạm chất lượng có thể làm website mất khả năng hiển thị rich result và dẫn tới manual action liên quan structured data. Việc đó không đồng nghĩa toàn bộ ranking web tự động biến mất, nhưng là rủi ro không đáng đổi lấy vài ngôi sao.

FAQ schema không phải mặc định cho mọi bài

FAQ trong nội dung vẫn hữu ích cho người đọc, nhưng không nên thêm markup chỉ vì plugin có checkbox. Khả năng hiển thị và điều kiện của từng rich result thay đổi theo thời gian, lĩnh vực và chính sách. Trước khi bật ở quy mô lớn:

1. Xem loại đó còn trong Search Gallery và có phù hợp website không.
2. Đọc toàn bộ hướng dẫn dành riêng cho tính năng.
3. Đảm bảo câu hỏi và câu trả lời hiển thị trên trang.
4. Không lặp cùng FAQ trên hàng nghìn URL nếu không thực sự liên quan.
5. Đo hiệu quả thay vì coi “valid” là thành công.

Schema không nên quyết định cấu trúc biên tập. Nội dung cần FAQ thì viết FAQ; sau đó mới xem markup nào hợp lệ.

Kiểm thử theo ba lớp

Lớp 1: JSON và schema syntax

Parser phải đọc được JSON-LD: dấu phẩy, dấu ngoặc, escape và kiểu dữ liệu chính xác. Một quote trong tên sản phẩm không được escape có thể làm hỏng cả block.

Lớp 2: Rich Results Test

Công cụ này kiểm tra những loại Google hỗ trợ và hiển thị error, warning. Error cần xử lý; warning cần đánh giá theo dữ liệu thật. Một item “valid” chỉ nói markup đủ điều kiện kỹ thuật ở thời điểm test, không bảo đảm hiển thị.

Lớp 3: Trang production và Search Console

Kiểm tra URL đã deploy bằng URL Inspection, xem HTML thực tế và theo dõi báo cáo rich result. Test staging không bắt được lỗi cache, locale, feature flag, consent hoặc dữ liệu sản phẩm thật.

Chạy SEO Checker để lấy mẫu tín hiệu trang và SEO audit miễn phí để tìm template có metadata hoặc canonical bất thường trước khi quy lỗi cho schema.

Kiểm thử những trường hợp dữ liệu xấu

Template thường đẹp với sản phẩm mẫu đầy đủ nhưng hỏng ở biên:

• Không có ảnh.
• Giá bằng 0 hoặc chưa công bố.
• Hai đơn vị tiền tệ.
• Tên chứa dấu quote và ký tự xuống dòng.
• Không có tác giả.
• Ngày sửa trước ngày xuất bản do migration.
• Review count bằng 0.
• Sản phẩm ngừng bán.
• Trang tiếng Anh nhận tên organization tiếng Việt không mong muốn.

Tạo fixture cho các trường hợp này và assert JSON parse được, URL tuyệt đối đúng locale, required property có mặt khi đủ điều kiện, object không được render khi dữ liệu cốt lõi thiếu.

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

Hai plugin cùng sinh schema

Theme tạo Article, plugin SEO tạo BlogPosting, plugin review tạo Product khác ID. Kết quả là nhiều object mâu thuẫn về author, image hoặc rating. Kiểm kê toàn bộ script application/ld+json, chọn một nguồn sở hữu từng thực thể.

Schema dùng URL staging

Biến môi trường hoặc cache khiến @id, image và canonical trỏ tới domain thử nghiệm. Test production bằng cách tìm toàn bộ hostname không mong muốn trong HTML.

Dữ liệu locale bị trộn

Trang tiếng Anh có headline Anh nhưng breadcrumb và organization name lấy nhầm bản Việt. Định nghĩa phần nào dùng chung và phần nào bản địa hóa; kiểm tra inLanguage nếu dùng.

JavaScript chèn markup quá muộn

Google có thể render JavaScript, nhưng việc phụ thuộc một request client lỗi hoặc bị chặn làm dữ liệu kém ổn định. Nếu server đã có dữ liệu, render JSON-LD trong HTML ban đầu thường đơn giản và đáng tin cậy hơn.

Dùng schema để che nội dung yếu

Markup chi tiết không bù được trang sản phẩm thiếu thông tin hay bài viết sao chép. Structured data mô tả nội dung; nó không tạo giá trị mà trang không có.

Giám sát sau deployment

Đặt schema vào quy trình release như một contract:

• Unit test generator với fixture.
• Snapshot hoặc schema validation cho template chính.
• Crawl staging và production để đếm item/error.
• Cảnh báo khi tỷ lệ trang có markup giảm đột ngột.
• Theo dõi báo cáo enhancement và manual actions.
• Ghi chú ngày thay đổi để so sánh CTR, impression và lỗi.

Khi một loại rich result bị Google thay đổi hỗ trợ, không cần hoảng loạn xóa toàn bộ schema.org hữu ích. Phân biệt markup giúp hệ thống hiểu thực thể với markup chỉ phục vụ một tính năng tìm kiếm. Đánh giá chi phí duy trì và lợi ích trước khi giữ hoặc bỏ.

Checklist trước khi xuất bản

• Loại schema có đại diện đúng nội dung chính không?
• Tính năng còn được Google hỗ trợ theo tài liệu hiện hành không?
• Required property đầy đủ từ nguồn dữ liệu thật chưa?
• Claim quan trọng có hiển thị cho người dùng không?
• URL, ảnh và @id là tuyệt đối, crawlable và đúng domain chưa?
• Canonical và mainEntityOfPage có cùng URL chiến lược không?
• Date, price, availability và rating có tự cập nhật không?
• Có object trùng do plugin khác không?
• Rich Results Test qua không?
• Trường hợp thiếu dữ liệu có làm hỏng JSON không?
• Đã kiểm tra production và Search Console chưa?

Kết luận

Schema markup tốt là bản mô tả trung thực, có cấu trúc của nội dung đang hiển thị. Nó bắt đầu từ mô hình dữ liệu và quyền sở hữu nguồn, không bắt đầu từ việc sao chép một đoạn JSON-LD. Chọn đúng loại, dùng ID ổn định, khai đủ thuộc tính có thật, kiểm tra cả trường hợp biên và giám sát sau deploy.

Đừng bịa rating để hết warning, đừng đánh dấu nội dung bị ẩn và đừng hứa rich result như một kết quả chắc chắn. Khi dữ liệu trang và dữ liệu có cấu trúc cùng lấy từ một sự thật, schema trở thành phần kỹ thuật dễ duy trì thay vì một lớp trang trí dễ hỏng.

Nguồn tham khảo: Google Search Central giới thiệu structured data, nguyên tắc chung và Schema.org.