Nối JSON-LD bằng @id và @graph: hết cảnh ba plugin khai ba “tổ chức” khác nhau

Mở mã nguồn một trang sản phẩm trên site WordPress bình thường, đếm thẻ <script type="application/ld+json">: thường có ba bốn khối. Một do giao diện chèn (Organization với tên viết tắt), một do plugin SEO chèn (Organization với tên đầy đủ, WebSite, WebPage, BreadcrumbList), một do WooCommerce chèn (Product), một do plugin đánh giá chèn (Product thứ hai với AggregateRating). Với Google, trang này có hai tổ chức và hai sản phẩm không rõ liên hệ. Bài dữ liệu có cấu trúc JSON-LD đã nói loại nào còn đáng làm; bài này đi vào chuyện kỹ thuật nối chúng lại cho sạch, bằng hai từ khoá của JSON-LD: @id và @graph.

@id: một cái tên cố định cho mỗi thực thể

@id là một định danh dạng địa chỉ, gắn cho một thực thể để chỗ khác có thể nhắc tới nó mà không phải khai lại. Quy ước phổ biến: lấy địa chỉ trang chính của thực thể, thêm một mảnh băm mô tả.

Thực thể	@id gợi ý	Khai đầy đủ ở
Tổ chức (doanh nghiệp)	https://tenmien.vn/#to-chuc	Trang chủ
Website	https://tenmien.vn/#website	Trang chủ
Trang hiện tại	https://tenmien.vn/bai/ten-bai#trang	Chính trang đó
Bài viết	https://tenmien.vn/bai/ten-bai#bai	Chính trang đó
Tác giả	https://tenmien.vn/tac-gia/lan-anh#nguoi	Trang tác giả
Sản phẩm	https://tenmien.vn/san-pham/sofa-go#san-pham	Trang sản phẩm

@id không bắt buộc phải là địa chỉ truy cập được, nhưng dùng địa chỉ thật của site giúp nó duy nhất và dễ đọc. Điều bắt buộc là cố định: cùng một tổ chức thì mọi trang dùng đúng một chuỗi @id, không đổi theo trang, không đổi theo thời gian.

@graph: gom mọi thực thể của trang vào một khối

Thay vì bốn khối rời, một khối duy nhất chứa mảng @graph, các thực thể tham chiếu nhau bằng @id:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://tenmien.vn/#to-chuc",
      "name": "Nội thất Gỗ Việt",
      "url": "https://tenmien.vn/",
      "logo": "https://tenmien.vn/logo.png",
      "sameAs": ["https://www.facebook.com/noithatgoviet"]
    },
    {
      "@type": "WebSite",
      "@id": "https://tenmien.vn/#website",
      "url": "https://tenmien.vn/",
      "name": "Nội thất Gỗ Việt",
      "publisher": { "@id": "https://tenmien.vn/#to-chuc" }
    },
    {
      "@type": "WebPage",
      "@id": "https://tenmien.vn/bai/chon-sofa-go#trang",
      "url": "https://tenmien.vn/bai/chon-sofa-go",
      "isPartOf": { "@id": "https://tenmien.vn/#website" },
      "breadcrumb": { "@id": "https://tenmien.vn/bai/chon-sofa-go#vet" }
    },
    {
      "@type": "Article",
      "@id": "https://tenmien.vn/bai/chon-sofa-go#bai",
      "headline": "Chọn sofa gỗ cho phòng khách nhỏ",
      "mainEntityOfPage": { "@id": "https://tenmien.vn/bai/chon-sofa-go#trang" },
      "author": { "@id": "https://tenmien.vn/tac-gia/lan-anh#nguoi" },
      "publisher": { "@id": "https://tenmien.vn/#to-chuc" },
      "datePublished": "2026-10-02T08:00:00+07:00"
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://tenmien.vn/bai/chon-sofa-go#vet",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Trang chủ", "item": "https://tenmien.vn/" },
        { "@type": "ListItem", "position": 2, "name": "Cẩm nang", "item": "https://tenmien.vn/cam-nang" },
        { "@type": "ListItem", "position": 3, "name": "Chọn sofa gỗ cho phòng khách nhỏ" }
      ]
    }
  ]
}

Đọc khối này, Google thấy: một tổ chức, sở hữu một website, website có một trang, trên trang là một bài viết do tổ chức xuất bản. Không có chỗ nào phải đoán. Tác giả chỉ được nhắc bằng @id; thông tin đầy đủ về người đó nằm ở trang tác giả.

Khai đầy đủ một lần, các trang khác chỉ tham chiếu

Hai cách làm đều hợp lệ:

• Khai đầy đủ ở mọi trang: khối Organization giống hệt nhau (cùng @id, cùng tên, cùng logo) xuất hiện ở mọi trang. Đơn giản, chắc chắn Google luôn thấy đủ.
• Khai đầy đủ ở trang chính, chỗ khác chỉ {"@id": ...}: gọn hơn, nhưng Google phải đã đọc trang chủ để biết #to-chuc là ai.

Với site vừa và nhỏ, cách thứ nhất cho Organization và WebSite (vài dòng, không đáng tiết kiệm) và cách thứ hai cho Person tác giả là cân bằng tốt. Điều quan trọng là không bao giờ có hai khai báo cùng loại mà khác nội dung: tổ chức tên “Gỗ Việt” ở khối này và “Công ty Nội thất Gỗ Việt” ở khối kia, logo khác nhau, số điện thoại khác nhau.

Gỡ trùng khi nhiều nguồn cùng chèn

Thực tế khó nhất không phải viết khối mẫu mà là dọn các khối thừa do nhiều thành phần cùng chèn. Quy trình:

1. Liệt kê nguồn. Xem mã nguồn trang (không phải công cụ kiểm tra, vì nó gộp lại), đếm từng khối JSON-LD, đoán nguồn theo cấu trúc: plugin SEO thường có @graph lớn; WooCommerce chèn Product riêng ở cuối trang; giao diện hay chèn Organization trong phần đầu.
2. Chọn một nguồn làm chủ cho mỗi loại thực thể. Thường plugin SEO làm chủ Organization, WebSite, WebPage, BreadcrumbList, Article; WooCommerce làm chủ Product.
3. Tắt phần trùng ở nguồn còn lại. Giao diện có tuỳ chọn tắt schema riêng; nếu không có, sửa tệp mẫu trong giao diện con. Plugin đánh giá: dùng chế độ “gộp vào Product sẵn có” nếu có, hoặc tắt phần schema của nó và để WooCommerce lấy điểm đánh giá.
4. Nối bằng @id: Product khai "brand", "manufacturer" hay "offers.seller" trỏ về {"@id": ".../#to-chuc"} nếu bạn tự bán hàng của mình.
5. Kiểm lại bằng Rich Results Test của Google và Schema Markup Validator: số thực thể mỗi loại phải đúng như mong muốn.

Trên Haravan, Shopify và site tự viết

Trên các nền tảng bán hàng, schema thường nằm trong tệp mẫu của giao diện: một đoạn Product trong tệp mẫu sản phẩm, đôi khi một đoạn Organization trong tệp khung chung. Ứng dụng đánh giá cài thêm lại chèn đoạn của riêng nó. Cách làm giống hệt: mở mã nguồn trang sản phẩm, đếm khối, chọn một nguồn làm chủ, sửa tệp mẫu để thêm @id và gỡ trùng. Khi đổi giao diện, các sửa đổi trong tệp mẫu cũ mất theo; ghi lại đoạn đã sửa để chép sang.

Với site tự viết, cách bền nhất là dựng toàn bộ JSON-LD từ một hàm duy nhất trong mã nguồn: hàm nhận loại trang và dữ liệu trang, trả về một mảng @graph đã có sẵn tổ chức, website, trang, vệt điều hướng, rồi thêm thực thể riêng của loại trang (bài viết, sản phẩm, sự kiện). Không có chỗ thứ hai nào in JSON-LD. Như vậy đổi tên doanh nghiệp, đổi logo chỉ sửa một chỗ và mọi trang khớp nhau ngay. Thêm một loại trang mới thì chỉ cần thêm một nhánh trong hàm đó.

Lỗi hay gặp với @id

Lỗi	Hậu quả
@id của tổ chức dùng địa chỉ trang hiện tại (.../san-pham/x#to-chuc)	Mỗi trang sinh một “tổ chức” khác nhau
Viết lẫn http và https, có và không có www trong @id	Thành nhiều định danh khác nhau cho cùng một thứ
Tham chiếu @id không có khai báo đầy đủ ở đâu cả	Google không biết thực thể đó là gì; trường bắt buộc như author.name bị coi là thiếu
Đặt @id trùng nhau cho hai loại khác nhau (Article và WebPage cùng #trang)	Thuộc tính hai loại bị trộn vào một
Dùng @graph nhưng mỗi phần tử lại khai @context riêng	Không sai hẳn nhưng thừa; công cụ cũ có thể đọc lỗi

Có đáng làm không

Nối bằng @id không tự nó tạo ra kết quả nhiều định dạng mới. Lợi ích của nó nằm ở chỗ khác: dữ liệu về doanh nghiệp nhất quán khắp site giúp Google và các hệ thống AI hiểu đúng bạn là ai, sản phẩm thuộc về ai, bài viết do ai viết. Đó là nền của chuyện thực thể và Knowledge Graph, xem thực thể và Knowledge Graph. Và nó loại bỏ một nguồn cảnh báo vô ích trong Search Console mỗi khi hai khối mâu thuẫn nhau.

Chấm điểm SEO của SEO Gốc kiểm trang có JSON-LD không và có lỗi cú pháp không (mã thieu_jsonld, jsonld_loi); phần nối thực thể thì kiểm bằng tay theo quy trình trên.

Checklist

1. Đếm số khối JSON-LD trong mã nguồn trang mẫu của từng loại trang.
2. Mỗi loại thực thể chỉ một nguồn chèn.
3. @id cố định, cùng giao thức và tên miền chính, không theo trang hiện tại cho thực thể toàn site.
4. Organization và WebSite giống hệt nhau ở mọi trang.
5. Article, Product trỏ về tổ chức, tác giả bằng @id.
6. Kiểm bằng Rich Results Test và Schema Markup Validator sau mỗi lần cập nhật plugin, giao diện.