Schema thương mại

TL;DR — “Commerce schema” là cách gọi tắt của tôi cho các kiểu schema.org dùng để đánh dấu những thứ mọi người có thể tìm kiếm và thực hiện hành động — sản phẩm để mua và công việc để ứng tuyển. Có ba kiểu: Product (một mặt hàng bán riêng lẻ), ProductGroup (một nhóm biến thể, chẳng hạn một chiếc áo có nhiều kích cỡ và màu sắc) và JobPosting (một vị trí đang tuyển). Chọn đúng kiểu giúp trang đủ điều kiện nhận một kết quả tìm kiếm nổi bật hơn — kết quả sản phẩm theo kiểu Shopping hoặc thẻ Google for Jobs. Điều đó không giúp trang xếp hạng cao hơn, không bảo đảm kết quả sẽ thực sự xuất hiện hay mang lại nhiều lượt nhấp hơn, và cũng không phải cách để được AI trích dẫn. Hub này dẫn bạn đến đúng kiểu; các bảng thuộc tính đầy đủ nằm trong bài viết riêng của từng kiểu.

”Commerce schema” có nghĩa là gì?

“Commerce schema” là một cách nhóm thực tế, không phải một kiểu Schema.org hay tính năng Google duy nhất. Bằng chứng cho nhận định này Commerce schema is an editorial grouping rather than a single Schema.org type or Google feature. Phạm vi: This article's taxonomy; Schema.org and Google document individual types and search experiences. Độ tin cậy: cao · Đã xác minh: 2026-07-14 Schema.org: Product Google ghi lại các yêu cầu và điều kiện đủ riêng cho đánh dấu sản phẩm, merchant listing và tổ chức. Bằng chứng cho nhận định này Google documents distinct structured-data requirements for product snippets and merchant listings, and valid markup does not guarantee display. Phạm vi: Google Product structured data and merchant-listing experiences. Độ tin cậy: cao · Đã xác minh: 2026-07-14 Google: Product structured data

Khi nhìn vào một trang bán áo khoác, bạn có thể biết giá, các lựa chọn màu và nhãn “in stock” (bản dịch) «còn hàng» chỉ bằng cách đọc. Công cụ tìm kiếm chỉ thấy văn bản thuần túy nên phải suy đoán. Schema markup là đoạn mã bạn thêm vào để nói rõ — “this is the price” (bản dịch) «đây là giá», “this is the availability” (bản dịch) «đây là tình trạng còn hàng», “this is a job title” (bản dịch) «đây là chức danh công việc» — bằng vốn từ vựng dùng chung của trang schema.org.

“Commerce schema” không phải thuật ngữ chính thức. Đây chỉ là tên gọi bao quát của tôi cho các kiểu schema.org mô tả danh sách thương mại hoặc giao dịch — những mặt hàng riêng lẻ mà một người có thể tìm kiếm, lọc và thực hiện hành động:

• Product — một mặt hàng bán riêng lẻ.
• ProductGroup — kiểu cha liên kết các biến thể của một mặt hàng (kích cỡ, màu sắc) để công cụ tìm kiếm hiểu đó là các lựa chọn của cùng một sản phẩm, không phải những sản phẩm tách biệt.
• JobPosting — một vị trí đang tuyển trên trang việc làm.

Tôi nhóm ba kiểu này vì chúng có cùng một vai trò trong SEO: bạn thêm chúng để Google có thể biến danh sách của mình thành một kết quả tìm kiếm chuyên biệt. Nhưng cần nói rõ — Google và schema.org không xếp chúng vào cùng một nhóm. Tôi sẽ quay lại điểm minh bạch này trong tab Advanced vì nó rất quan trọng.

Từ đó, vai trò của hub này cũng rõ ràng: đây là một router, không phải hướng dẫn triển khai. Hãy xác định trang của bạn thuộc kiểu nào trong ba kiểu, rồi đọc bài chuyên sâu tương ứng (và nếu có review, chính sách trả hàng hoặc vận chuyển, hãy xem thêm các bản ghi Review/MerchantReturnPolicy/OfferShippingDetails liền kề) để dùng các bảng thuộc tính thực tế.

Vì sao nên quan tâm: kết quả nhiều định dạng

Lợi ích là kết quả nhiều định dạng (rich results) — những danh sách nổi bật hơn trong tìm kiếm:

• 🛍️ một sản phẩm có giá, nhãn “in stock” (bản dịch) «còn hàng» và sao đánh giá
• 👕 một sản phẩm hiển thị các lựa chọn kích cỡ và màu sắc
• 💼 một việc làm xuất hiện trong hộp Jobs của Google cùng công ty, địa điểm và mức lương

Thêm schema tương ứng với đầy đủ chi tiết bắt buộc thì trang của bạn sẽ đủ điều kiện nhận cách hiển thị đó. Đủ điều kiện không có nghĩa là chắc chắn — Google vẫn quyết định có thực sự hiển thị hay không.

Điều nhiều người hiểu sai nhất

Thêm commerce schema không giúp bạn xếp hạng cao hơn. Google đã nói rõ điều này nhiều lần. Schema giúp trang đủ điều kiện nhận danh sách phong phú hơn và giúp công cụ hiểu trang. Điều đó khác với việc xếp hạng tốt hơn — và “đủ điều kiện” cũng không đồng nghĩa “được bảo đảm”: mã đánh dấu hợp lệ không hứa hẹn kết quả nhiều định dạng sẽ xuất hiện, không hứa hẹn có thêm lượt nhấp, và không phải cách để được trích dẫn trong câu trả lời AI. Hãy xem mỗi kết quả là một mục tiêu riêng.

Một cái bẫy khác với người mới: các kiểu này không thể thay thế lẫn nhau. Dùng Product cho một mặt hàng, ProductGroup khi mặt hàng có các biến thể, và JobPosting cho một vị trí tuyển dụng — tuyệt đối không dùng cho trang liệt kê nhiều việc làm cùng lúc. Quy tắc cuối nghiêm ngặt hơn nhiều người tưởng.

Muốn xem bản đầy đủ — các kiểu này nằm ở đâu trong hệ phân cấp schema.org, kết nối với Merchant Center và Google for Jobs như thế nào, và nên đọc bài nào tiếp theo? Hãy chuyển sang tab Advanced.

TL;DR — “Commerce schema” là cách nhóm theo thực hành của tôi, không phải danh mục của Google hay schema.org, dành cho các kiểu danh sách tạo ra kết quả nhiều định dạng giao dịch: Product, ProductGroup và JobPosting. Google thực sự tách chúng ra — Product/Variants nằm dưới “Shopping”, còn Job posting nằm trong danh sách feature guides chung. schema.org cũng không hợp nhất chúng: Product → ProductGroup là quan hệ cha/con thực sự (Thing > Product > ProductGroup), trong khi JobPosting nằm ở nhánh Intangible (Thing > Intangible > JobPosting), không liên quan đến Product. Điểm duy nhất gắn cả ba là mục đích sử dụng SEO — danh sách có cấu trúc được Google chuyển thành cách hiển thị SERP chuyên biệt (merchant listing và dịch vụ Google for Jobs). Không kiểu nào là yếu tố xếp hạng; nó chỉ mang lại điều kiện đủ — không bảo đảm hiển thị, tăng CTR hay được AI trích dẫn; đó là ba kết quả riêng biệt và không được bảo đảm. Điều kiện đủ của Review/AggregateRating có hồ sơ riêng, còn dữ liệu trả hàng/vận chuyển tách thành chính sách cấp Organization và ngoại lệ cấp Offer — thêm hai hợp đồng mà hub này chỉ dẫn đến. Rủi ro vòng đời cũng khác nhau: Product cũ chủ yếu mất điều kiện đủ, nhưng JobPosting cũ chưa hết hạn có thể kích hoạt manual action.

Trước hết, nói cho đúng: đây là cách nhóm của tôi, không phải của Google

Cách nhóm trong bài viết này kết hợp một số vốn từ vựng và tính năng tìm kiếm liên quan để tiện theo dõi. Bằng chứng cho nhận định này Commerce schema is an editorial grouping rather than a single Schema.org type or Google feature. Phạm vi: This article's taxonomy; Schema.org and Google document individual types and search experiences. Độ tin cậy: cao · Đã xác minh: 2026-07-14 Schema.org: Product Mỗi trải nghiệm Google có các thuộc tính bắt buộc và được khuyến nghị riêng, và mã đánh dấu hợp lệ không bảo đảm sẽ được hiển thị. Bằng chứng cho nhận định này Google documents distinct structured-data requirements for product snippets and merchant listings, and valid markup does not guarantee display. Phạm vi: Google Product structured data and merchant-listing experiences. Độ tin cậy: cao · Đã xác minh: 2026-07-14 Google: Product structured data

Tôi muốn nói rõ ngay từ đầu vì nhiều nội dung về schema “commerce” hoặc “ecommerce” ngầm khiến người đọc nghĩ đây là một họ chính thức. Không phải vậy.

• Tài liệu của Google tự tách chúng ra. Trong structured data gallery, “Job posting” nằm trong danh sách Feature guides phẳng, cùng với các kiểu không liên quan như Article, Local business và Organization. Trong khi đó, “Product snippet”, “Merchant listing” và “Variants” nằm trực tiếp dưới tiêu đề Shopping riêng biệt. Đây là hai họ tài liệu khác nhau.
• schema.org cũng không hợp nhất chúng. Hệ phân cấp kiểu này có một nhóm riêng “Product, Offer, and AggregateOffer” — còn JobPosting không xuất hiện trong nhóm cấp cao nhất cùng với chúng.

Vậy tại sao đặt chúng trong một bài viết? Vì trong thực tế — cách một SEOer thực sự làm việc — chúng là cùng một dạng vấn đề: nội dung kiểu danh sách có cấu trúc được đánh dấu để mở khóa một trải nghiệm tìm kiếm chuyên biệt. Mục đích dùng chung đó là có thật và hữu ích; cách phân loại chung thì không. Tôi thà nói thẳng còn hơn giả vờ Google đã vẽ ra chiếc hộp này.

Ba kiểu ở một glance

• Product (schema.org/Product) — một mặt hàng bán riêng lẻ. Google biến mã Product hợp lệ thành hai trải nghiệm: product snippets (sao đánh giá và giá trên các trang không mua hàng) và merchant listings (kết quả theo kiểu Shopping đầy đủ hơn trên các trang có thể mua mặt hàng). Mức tối thiểu để có điều kiện đủ cho rich result là name cộng với ít nhất một trong offers, review hoặc aggregateRating — nhưng nhánh review/aggregateRating còn phải tuân theo các quy tắc Review snippet riêng của Google (bao gồm hạn chế về review tự phục vụ), không phải cứ trang sản phẩm nào cũng hiện sao. Xem bài chuyên sâu về Review schema để hiểu hồ sơ điều kiện đủ này.
• ProductGroup (schema.org/ProductGroup) — kiểu cha nhóm các variants của một mặt hàng khái niệm (một áo thun có nhiều kích cỡ và màu sắc) để Google hiểu chúng là các lựa chọn của cùng sản phẩm, không phải các danh sách không liên quan. Nó liên kết các biến thể bằng hasVariant, variesBy và productGroupID. Quan trọng là nó không thay thế Product — mỗi biến thể vẫn là một Product đầy đủ của riêng mình; ProductGroup nằm phía trên chúng.
• JobPosting (schema.org/JobPosting) — một vị trí đang tuyển, được đánh dấu để trang đủ điều kiện xuất hiện trong trải nghiệm Google for Jobs (thẻ/băng chuyền danh sách trong Search). Các thuộc tính bắt buộc cơ bản là title, description, datePosted, hiringOrganization và jobLocation (hoặc applicantLocationRequirements cho vai trò hoàn toàn từ xa).

Tôi cố ý không đi sâu vào bảng thuộc tính của từng kiểu trong hub này — các bài chuyên sâu về ba kiểu ở cuối bài mới là nơi có nội dung đó.

Chúng nằm ở đâu trong hệ phân cấp schema.org

Đây là phần hầu như không ai trích dẫn chính xác, và nó phân biệt một phỏng đoán với một sự thật:

• Product — Thing > Product.
• ProductGroup — Thing > Product > ProductGroup. Đây là một kiểu con của Product thực sự, kế thừa mọi thuộc tính của Product và thêm hasVariant, productGroupID và variesBy. Vì vậy, “Product so với ProductGroup” không phải lựa chọn loại trừ lẫn nhau — ProductGroup là một Product chuyên biệt, được xây dựng cho trường hợp có biến thể.
• JobPosting — Thing > Intangible > JobPosting. Đây là một nhánh hoàn toàn tách biệt. Định nghĩa JobPosting không tham chiếu Product, Offer hay bất kỳ kiểu thương mại nào.

Kết luận: Product và ProductGroup có quan hệ phân loại (cha/con, có thể kiểm chứng và trích dẫn); JobPosting không có quan hệ phân loại với chúng. Sợi dây nối cả ba là mục đích dùng trong SEO, không phải quan hệ kế thừa. Nói rõ như vậy là bạn đang đứng trên nền tảng vững chắc.

Product so với ProductGroup: khi nào dùng kiểu nào

Quy tắc đơn giản:

• Một cấu hình có thể mua → dùng Product thông thường. Một SKU, một mức giá, một trang có thể mua được.
• Một mặt hàng khái niệm có nhiều biến thể có thể mua → dùng ProductGroup bao quanh các thành viên Product của nó. Đây là trường hợp một chiếc áo có năm màu. Bản thân ProductGroup không được chào bán — các thành viên hasVariant mới được bán, mỗi thành viên có sku/gtin, giá và tình trạng còn hàng riêng.

Google cũng ghi lại ProductGroup theo cách khác: nó nằm trên trang Variants, không phải một hướng dẫn tính năng cấp cao nhất độc lập — càng cho thấy Google coi đây là phần mở rộng của Product chứ không phải một loại rich result hoàn toàn tách biệt. Bảng thuộc tính đầy đủ, điểm dễ nhầm về URL đầy đủ của variesBy và việc đối soát với item_group_id của Merchant Center thuộc bài chuyên sâu ProductGroup, không phải hub này.

JobPosting: trường hợp ngoại lệ

JobPosting không có quan hệ phân loại nào với Product — nhưng nó có cùng dạng vấn đề nên vẫn có chỗ trong hub này. Về vận hành, có hai điểm khiến nó khác biệt:

1. Luôn một việc làm trên mỗi trang. Quy tắc của Google: “The JobPosting markup must only be used on pages that contain a single job posting.” (bản dịch) «Mã đánh dấu JobPosting chỉ được dùng trên các trang chứa một tin tuyển dụng duy nhất.» Không bao giờ đặt nó trên trang danh sách hoặc kết quả tìm kiếm. Product/ProductGroup không có hạn chế một-mặt-hàng-mỗi-trang tương đương — thực tế ProductGroup tồn tại chính để xử lý nhiều biến thể trên cùng một trang.
2. Tin đã hết hạn là nghĩa vụ tuân thủ, không phải việc cài đặt rồi bỏ đó. Phần rủi ro bên dưới là nơi mức độ khác biệt với Product rõ nhất.

Các quy tắc chung cho cả ba kiểu

Dù ba kiểu không cùng hệ phân loại, chúng vẫn tuân theo các nguyên tắc chung về dữ liệu có cấu trúc của Google, nên đáng nêu các quy tắc một lần:

• Thuộc tính bắt buộc là cổng điều kiện đủ. Thiếu một thuộc tính bắt buộc thì trang không đủ điều kiện cho rich result đó. Thuộc tính được khuyến nghị giúp nâng chất lượng — Google dùng mức lương trong tin tuyển dụng làm ví dụ: người dùng thích tin nêu rõ lương hơn tin không nêu. Logic “đầy đủ hơn thì tốt hơn” cũng áp dụng cho Product.
• Điều kiện đủ ≠ bảo đảm hiển thị. Mã đánh dấu hợp lệ đưa bạn vào nhóm đủ điều kiện; hệ thống Google vẫn quyết định riêng có hiển thị phần nâng cao hay không.
• Chỉ đánh dấu nội dung hiển thị và chính xác. Không dùng mã đánh dấu ẩn, review giả hay dữ liệu gây hiểu lầm — chính sách spam và chất lượng nội dung của Google áp dụng cho cả ba, đồng thời mỗi kiểu còn có chính sách riêng của tính năng (chẳng hạn chính sách nội dung JobPosting).
• JSON-LD là định dạng được khuyến nghị cho cả ba — dễ bảo trì ở quy mô lớn hơn Microdata/RDFa nhúng.

Mỗi kiểu kết nối ra sao ngoài mã đánh dấu trên trang

Giá trị thống nhất thực sự không nằm ở phân loại — mà ở chỗ Google dành cho nội dung dạng danh sách một cách hiển thị theo dòng sản phẩm riêng:

• Product / ProductGroup ↔ Google Merchant Center. Bạn có thể cung cấp dữ liệu sản phẩm bằng dữ liệu có cấu trúc trên trang, nguồn cấp Merchant Center hoặc cả hai. Google khuyến nghị dùng cả hai để tối đa hóa điều kiện đủ, và đối soát hai nguồn này — chúng là các hệ thống tách biệt được xác thực riêng, không phải một lần gửi duy nhất. Vượt qua Rich Results Test không có nghĩa nguồn cấp hợp lệ, và ngược lại. Giá và tình trạng còn hàng phải khớp giữa mã đánh dấu trên trang, nguồn cấp và bước thanh toán.
• JobPosting ↔ Google for Jobs. Mã JobPosting hợp lệ giúp một trang có duy nhất một tin tuyển dụng đủ điều kiện vào trải nghiệm Jobs — một vertical riêng, không phải bề mặt Shopping.
• Trả hàng và vận chuyển cũng tách ở cấp chi tiết hơn. MerchantReturnPolicy thường nằm ở cấp Organization — chính sách mặc định toàn trang về thời hạn và điều khoản trả hàng. OfferShippingDetails hoạt động ở cấp Offer và dùng để ghi đè mặc định cấp tổ chức cho một mặt hàng cụ thể (ví dụ sản phẩm nặng hơn hoặc khu vực có mức phí khác). Hãy coi đó là hai bản ghi riêng có thể cũ lệch nhau; chính sách cấp tổ chức và mọi ngoại lệ cấp offer đều cần được duy trì riêng. Quy tắc ưu tiên đầy đủ nằm trong bài chuyên sâu MerchantReturnPolicy và OfferShippingDetails.
• Dữ liệu có cấu trúc trên trang, nguồn cấp Merchant Center và nội dung mà các tính năng Google Search hoặc câu trả lời AI thực sự hiển thị là ba hợp đồng riêng, không phải một pipeline — mã đánh dấu hợp lệ chỉ mang lại điều kiện đủ ở lớp đầu, không tự động điền lớp thứ hai và không bảo đảm bất kỳ điều gì ở lớp thứ ba. Vượt qua một lớp không chứng minh các lớp còn lại tương đương.

Sự bất đối xứng với Bing đáng được nói thẳng: Bing xác thực cả ba kiểu một cách chung theo hình dạng schema.org, nhưng không công bố bảng thuộc tính bắt buộc/khuyến nghị hay chính sách nội dung riêng cho bất kỳ kiểu nào, và không có trải nghiệm tương đương Merchant listings hoặc Google for Jobs. Riêng ProductGroup, Fabrice Canel của Bing nói (tháng 9 năm 2024) rằng Bing vẫn chưa dùng mã ProductGroup trong chú thích mua sắm, dù nó “on their radar”. (bản dịch) «đang được họ theo dõi.» Tóm lại: cùng vốn từ vựng nền tảng, nhưng chỉ Google đã xây dựng các trải nghiệm rich result chuyên biệt, được ghi lại, trên đó.

Khác biệt về rủi ro và vòng đời

Đây là điểm tương phản tôi muốn mọi người ghi nhớ nhất vì ít nơi trình bày rõ: danh sách cũ cần vệ sinh vòng đời ở cả ba kiểu — nhưng mức độ rủi ro khác nhau rõ rệt.

• Một Product cũ hoặc hết hàng chủ yếu mất điều kiện đủ cho rich result hoặc hiển thị nhãn “sold out”/“out of stock”. Khó chịu, nhưng không thảm họa.
• Một JobPosting cũ chưa gỡ là cấp rủi ro khác. Google nói: “We don’t allow expired job postings,” (bản dịch) «Chúng tôi không cho phép tin tuyển dụng đã hết hạn», và việc không hết hạn hoặc gỡ tin đã đóng “may result in a manual action.” (bản dịch) «có thể dẫn đến manual action.» Đây là hậu quả tệ hơn đáng kể so với việc chỉ không đủ điều kiện. Có ba cách Google chấp nhận để hết hạn một tin: đặt validThrough ở quá khứ, trả về 404/410 hoặc gỡ mã đánh dấu.

Bài học chung là danh sách có cấu trúc cần một quy trình vòng đời — nhưng nếu chỉ xây dựng một pipeline dọn dẹp, hãy ưu tiên cho việc làm.

Commerce schema có giúp SEO không?

Không, không giúp xếp hạng. John Mueller nói trực tiếp: “Structured data won’t make your site rank better.” (bản dịch) «Dữ liệu có cấu trúc sẽ không giúp trang web của bạn xếp hạng tốt hơn.» Schema giúp đạt điều kiện đủ cho rich result và trải nghiệm chuyên biệt, đồng thời giúp Google hiểu các trang của bạn. Đánh đồng “I added schema” (bản dịch) «Tôi đã thêm schema» với “I’ll rank better” (bản dịch) «Tôi sẽ xếp hạng tốt hơn» là một trong những lầm tưởng phổ biến nhất về cả ba kiểu.

Và vấn đề không chỉ là thứ hạng. Điều kiện đủ, rich result thực sự được hiển thị, mức tăng CTR và doanh thu là bốn tuyên bố riêng biệt — đừng gộp chúng làm một. Mã đánh dấu hợp lệ không bảo đảm danh sách của bạn xuất hiện trong Shopping hay trải nghiệm Jobs (điều kiện đủ không đồng nghĩa hiển thị), không bảo đảm có thêm lượt nhấp, và — vì không kiểu schema nào trong hub này được ghi nhận là tín hiệu tăng khả năng hiển thị trong AI — cũng không phải đòn bẩy để xuất hiện hoặc được trích dẫn trong AI Overviews hay AI Mode. Hãy đo từng kết quả riêng; triển khai schema đáng làm để giành một tính năng tìm kiếm mà nó có thể mang lại, không phải làm đại diện cho mọi kết quả còn lại.

Quan điểm của tôi cũng giống Mueller: hãy hiểu schema thực sự dùng để làm gì trước khi dành thời gian phát triển cho nó. Schema vẫn còn được dùng — Mueller cũng từng nói Google không khai tử schema — nhưng bạn triển khai nó để giành một tính năng tìm kiếm, không phải để đẩy thứ hạng, bảo đảm một lượt nhấp hay đưa câu trả lời AI lên cao hơn.

Đọc gì tiếp theo

Hub này là bản đồ; mỗi mục sau đây có bài chuyên sâu riêng nằm bên dưới:

• Product schema — hai trải nghiệm Google (product snippets và merchant listings), cách tách thuộc tính bắt buộc/khuyến nghị, enum availability và gỡ rối nhầm lẫn giữa nguồn cấp và mã đánh dấu. Bắt đầu ở đây nếu trang của bạn bán một mặt hàng.
• ProductGroup schema — nhóm biến thể bằng hasVariant/variesBy/productGroupID, mô hình một trang so với nhiều trang, điểm dễ nhầm về URL đầy đủ của schema.org và đối soát với item_group_id của Merchant Center. Bắt đầu ở đây nếu mặt hàng có các kích cỡ/màu sắc/chất liệu.
• JobPosting schema — thuộc tính bắt buộc so với khuyến nghị, xử lý remote/hybrid, quy tắc một tin mỗi trang, vệ sinh hết hạn và thay đổi quyền truy cập Indexing API giai đoạn 2024–2025 cho job board. Bắt đầu ở đây cho trang tuyển dụng hoặc job board.
• MerchantReturnPolicy schema — kiểu thuộc tính lồng nhau cho chính sách trả hàng: thứ tự ưu tiên giữa mã đánh dấu và cài đặt Merchant Center, cùng nhầm lẫn giữa applicableCountry và returnPolicyCountry.
• OfferShippingDetails schema — thuộc tính đi kèm về phí vận chuyển/điểm đến/thời gian giao và khi nào Google thực sự yêu cầu chúng cho free listings.
• Review schema — hồ sơ điều kiện đủ riêng đằng sau nhánh review/aggregateRating của rich result Product: quy tắc review đơn lẻ so với tổng hợp, hạn chế review tự phục vụ và lý do không phải trang sản phẩm nào cũng tự động đủ điều kiện hiện sao. Hãy bắt đầu ở đây khi bạn đã qua câu hỏi “which of the three do I use” (bản dịch) «Tôi dùng kiểu nào trong ba kiểu» và muốn biết “can this page actually show review stars” (bản dịch) «trang này có thực sự hiển thị sao đánh giá không».

Để có bức tranh rộng hơn, hub này nằm trong cụm con dữ liệu có cấu trúc lớn hơn — hãy xem thêm bài viết schema markup cùng cụm để tìm hiểu vốn từ vựng, định dạng và vòng đời ngừng dùng. Tất cả nằm trong cụm on-page, nơi dữ liệu có cấu trúc đứng cạnh phần còn lại của SEO kỹ thuật on-page.

Tóm tắt AI

Tóm tắt cô đọng của phiên bản Advanced:

• Nó là gì: “Commerce schema” là cách nhóm theo thực hành của Patrick — không phải danh mục của Google hay schema.org — dành cho các kiểu danh sách schema.org tạo ra kết quả nhiều định dạng giao dịch: Product, ProductGroup, JobPosting.
• Không phải họ chính thức: Google đặt Product/Merchant listing/Variants dưới “Shopping”, còn Job posting trong danh sách feature guides chung. schema.org nhóm “Product, Offer, and AggregateOffer” cùng nhau nhưng đặt JobPosting ở ngoài nhóm cấp cao nhất đó.
• Hệ phân cấp: Product = Thing > Product; ProductGroup = Thing > Product > ProductGroup (kiểu con thực sự của Product, dành cho biến thể); JobPosting = Thing > Intangible > JobPosting (nhánh không liên quan). Product/ProductGroup là cha/con; JobPosting tách biệt về phân loại.
• Khi nào dùng: một cấu hình có thể mua → Product; một mặt hàng có biến thể → ProductGroup bao quanh các Product của nó (bản thân ProductGroup không bán); một vị trí đang tuyển → JobPosting (mỗi trang một tin, không dùng trên trang danh sách).
• Kết quả nhiều định dạng: Product → product snippets + merchant listings; ProductGroup → merchant listing nhận biết biến thể; JobPosting → “Google for Jobs” (bản dịch) «dịch vụ tuyển dụng của Google».
• Quy tắc chung: thuộc tính bắt buộc là cổng điều kiện đủ; điều kiện đủ ≠ bảo đảm hiển thị; chỉ đánh dấu nội dung hiển thị/chính xác; JSON-LD được khuyến nghị.
• Ngoài mã đánh dấu: Product/ProductGroup ↔ Google Merchant Center (các hệ thống tách biệt nhưng được đối soát; dùng cả hai; giá/tình trạng còn hàng phải khớp giữa mã đánh dấu, nguồn cấp và thanh toán). JobPosting ↔ “Google for Jobs” (bản dịch) «dịch vụ tuyển dụng của Google». Trả hàng/vận chuyển cũng tách ở cấp chi tiết hơn — MerchantReturnPolicy thường cấp Organization, còn OfferShippingDetails ghi đè theo Offer cho ngoại lệ; hai bản ghi, hai lịch bảo trì.
• Sao review có hồ sơ riêng: nhánh review/aggregateRating của rich result Product tuân theo quy tắc điều kiện đủ Review snippet riêng của Google, không phải cứ “any product page qualifies” (bản dịch) «trang sản phẩm nào cũng đủ điều kiện» — xem bài Review schema.
• Bing: xác thực chung cả ba kiểu, không có đặc tả/chính sách riêng, không có merchant listing hay dịch vụ việc làm tương đương; theo Fabrice Canel (tháng 9 năm 2024), Bing vẫn chưa dùng mã ProductGroup trong chú thích mua sắm.
• Hồ sơ rủi ro: Product cũ chủ yếu mất điều kiện đủ; JobPosting cũ có thể kích hoạt manual action — hết hạn bằng validThrough ở quá khứ, 404/410 hoặc gỡ mã đánh dấu.
• Tác động SEO: không phải yếu tố xếp hạng (Mueller: “Structured data won’t make your site rank better” (bản dịch) «Dữ liệu có cấu trúc sẽ không giúp trang web của bạn xếp hạng tốt hơn») — schema mang lại điều kiện đủ và giúp hiểu nội dung, nhưng đó là các kết quả tách biệt với hiển thị thực tế, tăng CTR hay trích dẫn trong câu trả lời AI; không kiểu nào trong hub được ghi nhận là tín hiệu hiển thị AI.
• Hub này chỉ dẫn đường, không triển khai: các bảng thuộc tính đầy đủ nằm trong bài chuyên sâu Product, ProductGroup, JobPosting, Review, MerchantReturnPolicy và OfferShippingDetails, không nằm ở đây.

Tài liệu chính thức

Tài liệu nguồn chính cho ba kiểu commerce schema và các quy tắc chung của chúng.

Google — quy tắc chung

• Nguyên tắc chung về dữ liệu có cấu trúc — nguyên tắc điều kiện đủ, chính sách chất lượng nội dung và spam áp dụng cho cả ba kiểu.
• Thư viện tìm kiếm dữ liệu có cấu trúc — nguồn chuẩn về những gì hiện tạo ra rich result; cũng là nơi thấy sự tách biệt giữa “Shopping” và “Feature guides” (bản dịch) «các hướng dẫn tính năng».

Google — Product và ProductGroup (“Shopping”)

• Giới thiệu về dữ liệu có cấu trúc Product — sự khác nhau giữa product snippet và merchant listing, cùng mối quan hệ giữa dữ liệu có cấu trúc và nguồn cấp.
• Dữ liệu có cấu trúc product snippet — thuộc tính bắt buộc/khuyến nghị cho trải nghiệm snippet nhẹ hơn.
• Dữ liệu có cấu trúc merchant listing — yêu cầu nghiêm ngặt hơn cho “buy this here”.
• Dữ liệu có cấu trúc biến thể sản phẩm (ProductGroup) — nơi ProductGroup được ghi lại như phần mở rộng của Product.
• Đặc tả dữ liệu sản phẩm của Merchant Center — đặc tả phía nguồn cấp để đối soát với mã đánh dấu trên trang.

Google — JobPosting (“Feature guides” (bản dịch) «các hướng dẫn tính năng»)

• Dữ liệu có cấu trúc tin tuyển dụng — thuộc tính bắt buộc/khuyến nghị, quy tắc một tin mỗi trang, chính sách nội dung và cách xử lý hết hạn.

Schema.org (phân loại)

• schema.org/Product · schema.org/ProductGroup · schema.org/JobPosting · tổng quan hệ phân cấp kiểu

Bing / Microsoft

• Bing Webmaster Tools — Đánh dấu trang web bằng dữ liệu có cấu trúc — hỗ trợ schema.org chung; không có đặc tả điều kiện đủ riêng cho từng kiểu.

Trích dẫn từ nguồn

Các phát biểu có ghi nhận. Khi một trang công khai nguyên văn, liên kết sẽ đi thẳng đến đoạn trích dẫn.

Tài liệu Google — nguyên tắc điều kiện đủ chung

• “Specify all required properties listed in the documentation for your specific rich result type. Items that are missing required properties are not eligible for rich results. The more recommended properties that you provide, the higher quality the result is to users. For example: users prefer job postings with explicitly stated salaries than those without…” (bản dịch) «Hãy chỉ định mọi thuộc tính bắt buộc được liệt kê trong tài liệu cho loại rich result cụ thể. Mục nào thiếu thuộc tính bắt buộc sẽ không đủ điều kiện nhận rich result. Càng cung cấp nhiều thuộc tính được khuyến nghị, kết quả càng có chất lượng cao hơn đối với người dùng. Ví dụ: người dùng thích tin tuyển dụng nêu rõ mức lương hơn tin không nêu…»* Jump to quote
• “Content in structured data must also follow the additional content guidelines or policies, as documented in the specific feature guide. For example, content in JobPosting structured data must follow the job posting content policies.” (bản dịch) «Nội dung trong dữ liệu có cấu trúc cũng phải tuân theo các nguyên tắc hoặc chính sách nội dung bổ sung được ghi trong hướng dẫn tính năng cụ thể. Ví dụ, nội dung trong dữ liệu có cấu trúc JobPosting phải tuân theo chính sách nội dung tin tuyển dụng.»* Jump to quote

Tài liệu Google — Product và mối quan hệ với Merchant Center

• “Two markup types exist: Product snippets for non-purchase pages, emphasizing reviews, and Merchant listings for purchase pages, highlighting product details like sizing and shipping.” (bản dịch) «Có hai kiểu mã đánh dấu: product snippet dành cho trang không mua hàng, nhấn mạnh review; và merchant listing dành cho trang mua hàng, làm nổi bật chi tiết sản phẩm như kích cỡ và vận chuyển.»* Jump to quote
• “To provide rich product data to Google Search you can add Product structured data to your web pages, upload data feeds with Google Merchant Center and opt into free listings within the Merchant Center console, or both.” (bản dịch) «Để cung cấp dữ liệu sản phẩm phong phú cho Google Search, bạn có thể thêm dữ liệu có cấu trúc Product vào các trang web, tải nguồn cấp dữ liệu lên bằng Google Merchant Center và đăng ký free listings trong bảng điều khiển Merchant Center, hoặc làm cả hai.»* Jump to quote

Tài liệu Google — quy tắc riêng của JobPosting

• “The JobPosting markup must only be used on pages that contain a single job posting. We don’t allow the use of JobPosting markup in any other page, including pages that do not list any job.” (bản dịch) «Mã đánh dấu JobPosting chỉ được dùng trên các trang chứa một tin tuyển dụng duy nhất. Chúng tôi không cho phép dùng mã JobPosting trên bất kỳ trang nào khác, kể cả trang không liệt kê việc làm.»* Jump to quote
• “We don’t allow expired job postings. Ideally you should remove expired job postings from your website. If you prefer to not remove them, then you need to ensure the validThrough property is populated and in the past.” (bản dịch) «Chúng tôi không cho phép tin tuyển dụng đã hết hạn. Tốt nhất bạn nên xóa tin đã hết hạn khỏi trang web. Nếu không muốn xóa, bạn phải bảo đảm thuộc tính validThrough được điền và nằm trong quá khứ.»* Jump to quote
• “Jobs that are no longer open for applications must be expired in one of the following ways. Failure to take timely action on expired jobs may result in a manual action.” (bản dịch) «Các việc làm không còn nhận hồ sơ phải được làm hết hạn theo một trong các cách sau. Không xử lý kịp thời việc làm đã hết hạn có thể dẫn đến manual action.»* Jump to quote

John Mueller, Google — schema không phải yếu tố xếp hạng

• “Structured data won’t make your site rank better.” (bản dịch) «Dữ liệu có cấu trúc sẽ không giúp trang web của bạn xếp hạng tốt hơn.»* Và: “It’s fine to use it for other things in schema.org, that won’t cause problems, but you’re unlikely to see any visible change from it in Google Search.” (bản dịch) «Dùng nó cho các mục đích khác trong schema.org cũng được, điều đó không gây vấn đề, nhưng bạn khó thấy thay đổi rõ rệt nào trong Google Search chỉ vì nó.»* Coverage Được thuật lại qua bài đưa tin của Search Engine Roundtable về các bài đăng Bluesky của Mueller vào tháng 4 năm 2025; hãy coi câu chữ là bản chép lại từ nguồn đưa tin thứ cấp.
• “In order to be eligible to be shown as a rich result, you need to make sure that the page uses the right structured data and that it complies with the appropriate policies on our side.” (bản dịch) «Để đủ điều kiện được hiển thị dưới dạng rich result, bạn cần bảo đảm trang dùng đúng dữ liệu có cấu trúc và tuân thủ các chính sách phù hợp của chúng tôi.»* Coverage Được thuật lại qua bài đưa tin của Search Engine Land về câu trả lời #AskGoogleWebmasters năm 2019.
• “Exactly. Understand that markup types come and go, but a precious few you should hold on to (like title, and meta robots).” (bản dịch) «Đúng vậy. Hãy hiểu rằng các kiểu mã đánh dấu đến rồi đi, nhưng có một số ít đáng để giữ lại (như title và meta robots).»* Coverage Được thuật lại qua bài đưa tin của Search Engine Roundtable về câu trả lời trên Reddit vào tháng 11 năm 2025.

Fabrice Canel, Microsoft Bing — về ProductGroup

• “ProductGroup markup isn’t used in our captions yet, but it’s on our radar. Our team is closely monitoring its adoption. Stay tuned!” (bản dịch) «Mã đánh dấu ProductGroup hiện chưa được dùng trong chú thích của chúng tôi, nhưng đang được theo dõi. Đội ngũ đang giám sát chặt chẽ mức độ áp dụng. Hãy chờ xem!»* Coverage Được thuật lại qua bài đưa tin của Search Engine Roundtable về phát biểu trên X vào tháng 9 năm 2024; thông tin đã có ngày tháng — hãy kiểm tra lại hỗ trợ ProductGroup hiện tại của Bing trước khi dựa vào phát biểu này.

Commerce schema ở một glance

So sánh ba kiểu

Thông tin nhanh

• “Commerce schema” là một cách nhóm theo thực hành, không phải danh mục của Google hay schema.org — ba kiểu có cùng mục đích dùng SEO, không cùng hệ phân loại.
• Product và ProductGroup là cha/con; JobPosting là nhánh không liên quan.
• Điều kiện đủ ≠ hiển thị — mã đánh dấu hợp lệ đưa trang vào nhóm đủ điều kiện; Google vẫn quyết định có hiển thị phần nâng cao hay không.
• Không phải yếu tố xếp hạng — cũng không bảo đảm CTR, hiển thị hay trích dẫn AI. Schema mang lại điều kiện đủ cho rich result và giúp công cụ hiểu nội dung. Kết quả có thực sự xuất hiện, có mang lại nhiều lượt nhấp hơn hay có xuất hiện trong câu trả lời AI đều là các kết quả riêng biệt và không được bảo đảm.
• Điều kiện đủ của Review/AggregateRating có hồ sơ riêng. Không phải trang sản phẩm hoặc merchant nào cũng tự động đủ điều kiện hiển thị sao — nhánh đó tuân theo quy tắc Review snippet riêng của Google. Xem bài chuyên sâu Review schema.
• Trả hàng và vận chuyển cũng tách ở cấp chi tiết hơn. MerchantReturnPolicy thường ở cấp Organization (chính sách mặc định); OfferShippingDetails ghi đè theo Offer cho ngoại lệ. Hai bản ghi, hai lịch bảo trì.
• JSON-LD là định dạng Google khuyến nghị cho cả ba.
• Nguồn cấp Merchant Center và mã Product trên trang là các hệ thống tách biệt được Google đối soát — nên cung cấp cả hai và giữ giá/tình trạng còn hàng nhất quán giữa mã đánh dấu, nguồn cấp và thanh toán.
• Vệ sinh tin tuyển dụng là việc có rủi ro cao nhất: hết hạn tin đã đóng (đặt validThrough trong quá khứ, trả 404/410 hoặc gỡ mã đánh dấu) nếu không muốn đối mặt với manual action.

Tôi cần kiểu commerce schema nào?

Hãy trả lời theo trang bạn đang đánh dấu; bạn sẽ đến đúng kiểu (và đúng bài chuyên sâu để đọc tiếp).

Những lỗi tôi thực sự gặp với commerce schema

Đây là những lỗi cụ thể mọi người mắc khi đánh dấu Product, ProductGroup và JobPosting — không phải giả định. Mỗi lỗi đều có cách sửa.

Đặt mã JobPosting trên trang liệt kê nhiều việc làm

Quy tắc của Google rất rõ: mã JobPosting “must only be used on pages that contain a single job posting,” (bản dịch) «chỉ được dùng trên trang chứa một tin tuyển dụng duy nhất», và không được phép trên bất kỳ trang nào khác, kể cả trang không liệt kê việc làm. Thêm nó vào trang chỉ mục tuyển dụng hoặc trang kết quả tìm kiếm không giúp bạn có thêm danh sách Jobs — chỉ khiến mã đánh dấu không tuân thủ và không đủ điều kiện.

Nên làm: cấp cho mỗi vị trí đang tuyển một URL riêng chỉ chứa tin đó và chỉ đánh dấu trang ấy. Dùng trang danh sách/chỉ mục để điều hướng, không dùng JobPosting schema.

Để tin tuyển dụng đã đóng vẫn hoạt động mà không hết hạn

Product cũ chủ yếu mất điều kiện đủ hoặc hiển thị “out of stock” (bản dịch) «hết hàng» — hơi phiền. JobPosting cũ là nhóm rủi ro khác: Google nói không cho phép tin tuyển dụng hết hạn, và không hết hạn hoặc gỡ tin đã đóng “may result in a manual action.” (bản dịch) «có thể dẫn đến manual action.» Đây là hình phạt ở cấp toàn trang, không chỉ là mất một rich-result snippet.

Nên làm: ngay khi vị trí đóng, hãy thực hiện một trong ba cách Google chấp nhận — đặt validThrough thành ngày trong quá khứ, trả về 404/410 cho URL hoặc gỡ hoàn toàn mã JobPosting. Đưa việc này vào bước offboarding của hệ thống tuyển dụng, không chờ xử lý thủ công sau đó.

Coi ProductGroup là thứ thay thế cho việc đánh dấu từng biến thể

ProductGroup là kiểu cha liên kết các biến thể bằng hasVariant, variesBy và productGroupID — nhưng không thay thế Product. Mỗi biến thể (từng tổ hợp kích cỡ, màu sắc hoặc chất liệu) vẫn cần mã Product đầy đủ của riêng mình với sku/gtin, giá và tình trạng còn hàng riêng. Chỉ xuất bản ProductGroup mà bỏ các mục Product riêng lẻ sẽ khiến biến thể thiếu dữ liệu Google cần để bán chúng.

Nên làm: đánh dấu mỗi biến thể có thể mua như một Product riêng, rồi bọc cả tập hợp trong một ProductGroup tham chiếu đến chúng.

Mong commerce schema cải thiện thứ hạng

Đây là lầm tưởng phổ biến nhất về cả ba kiểu, và Google đã nói rõ nhiều lần — John Mueller: “Structured data won’t make your site rank better.” (bản dịch) «Dữ liệu có cấu trúc sẽ không giúp trang web của bạn xếp hạng tốt hơn.» Coi việc triển khai schema là chiến dịch tăng hạng sẽ đặt sai kỳ vọng cho các bên liên quan và có thể khiến đội ngũ bỏ qua những việc khác để chạy theo một tác dụng mà mã đánh dấu vốn không bao giờ tạo ra.

Nên làm: triển khai commerce schema để đạt điều kiện đủ cho một tính năng tìm kiếm cụ thể (merchant listing, thẻ Jobs) — đó là mục tiêu chính đáng có giá trị riêng về lượt nhấp và cách trình bày — rồi đo lường theo mục tiêu đó, không theo vị trí xếp hạng.

Để mã đánh dấu trên trang, nguồn cấp Merchant Center và thanh toán lệch nhau

Dữ liệu Product có thể đến từ dữ liệu có cấu trúc trên trang, nguồn cấp Merchant Center hoặc cả hai, và Google đối soát chúng như các hệ thống riêng thay vì coi một nguồn là bản sao của nguồn kia. Vượt qua Rich Results Test không có nghĩa nguồn cấp hợp lệ, và ngược lại — nếu giá hoặc tình trạng còn hàng khác nhau giữa mã đánh dấu, nguồn cấp và số tiền thanh toán thực tế, sự lệch nhau đó làm suy yếu cả điều kiện đủ lẫn niềm tin của người dùng.

Nên làm: giữ giá và tình trạng còn hàng giống hệt trên cả ba bề mặt, đồng thời xác thực riêng mã đánh dấu trên trang và nguồn cấp thay vì cho rằng một bên đã bao phủ bên kia.

Công cụ để xây dựng và kiểm tra commerce schema

Schema Markup Validator của tôi là điểm dừng đầu tiên sau khi bạn viết JSON-LD cho bất kỳ kiểu nào trong ba kiểu. Dán một khối Product, ProductGroup hoặc JobPosting (hoặc cả trang) để công cụ chạy các kiểm tra theo mức độ nghiêm trọng dựa trên từ vựng schema.org và yêu cầu rich result của Google — hữu ích khi bắt lỗi thiếu thuộc tính bắt buộc trước khi phát hành, dù bạn đang làm với kiểu nào.

Rich-Result Eligibility Checker trả lời câu hỏi cụ thể hơn mà hub này liên tục quay lại: không phải “is this valid JSON-LD” (bản dịch) «JSON-LD này có hợp lệ không» mà là “does this page actually qualify for a rich result.” (bản dịch) «trang này có thực sự đủ điều kiện nhận rich result không». Dán JSON-LD, trang HTML hoặc URL trực tiếp; công cụ cho biết trường bắt buộc nào có mặt hay còn thiếu đối với Product (offers/review/aggregateRating) hoặc JobPosting (title, description, datePosted, hiringOrganization, jobLocation) — chính là cổng điều kiện đủ được mô tả trong bài.

PDP SEO Checker được xây dựng riêng cho phần trang chi tiết sản phẩm của hub này — nó xem một trang sản phẩm thực tế vượt ra ngoài schema, bao quát các tín hiệu trên trang đi cùng mã Product/ProductGroup khi bạn quyết định trang một SKU hay trang nhóm biến thể đã được thiết lập đúng chưa.

Sau khi mã đánh dấu vượt qua các kiểm tra đó, hãy chạy trang qua Rich Results Test của Google — đây là công cụ Google thực sự dùng để quyết định điều kiện đủ, nên là bước xác nhận cuối trước khi phát hành bất kỳ kiểu nào trong ba kiểu.

Tự kiểm tra: Commerce Schema

Năm câu hỏi nhanh về ba kiểu commerce schema, mối quan hệ giữa chúng và tác dụng (cũng như điều chúng không làm). Chọn một đáp án cho mỗi câu rồi kiểm tra.

Các tài nguyên đáng dành thời gian

Các bài viết của tôi về schema markup

• Schema Markup — góc nhìn rộng hơn của tôi về vốn từ vựng, định dạng, cách hiểu thực thể và vòng đời ngừng dùng. Commerce schema là một lát cắt trong đó.
• Hướng dẫn cho người mới về SEO kỹ thuật — nơi tôi trình bày schema như mã giúp công cụ hiểu nội dung và tạo ra các tính năng khiến một danh sách nổi bật.
• Enterprise SEO — quy tắc thực dụng của tôi, cũng áp dụng ở đây: “I’m a fan of schema markup as long as it gets you a search feature.” (bản dịch) «Tôi ủng hộ schema markup miễn là nó giúp bạn có một tính năng tìm kiếm.»

Các bài nói chuyện của tôi

• Cách Search hoạt động (SlideShare) — phần trình bày của tôi về crawling, rendering, lập chỉ mục và xếp hạng; hữu ích để hiểu dữ liệu có cấu trúc nằm ở đâu. (Tuyên bố miễn trừ thường trực của tôi: “This is my understanding of systems… not going to be 100% complete or accurate.” (bản dịch) «Đây là cách tôi hiểu các hệ thống… sẽ không hoàn toàn đầy đủ hoặc chính xác 100%.»)

Từ ngành

• Google lại khẳng định dữ liệu có cấu trúc không giúp trang web xếp hạng tốt hơn (Search Engine Roundtable) — phát biểu tháng 4 năm 2025 của Mueller, nền tảng giải thích lầm tưởng của toàn bộ hub này.
• Google không loại bỏ schema — các kiểu mã đánh dấu có thể đến rồi đi (Search Engine Roundtable) — cách diễn đạt “markup types come and go, but a precious few you should hold on to” (bản dịch) «các kiểu mã đánh dấu đến rồi đi, nhưng có một số ít bạn nên giữ lại».
• Bing có thể dùng mã ProductGroup trong tương lai (Search Engine Roundtable) — phát biểu tháng 9 năm 2024 của Fabrice Canel về việc Bing chưa hỗ trợ ProductGroup.
• Tuân thủ nguyên tắc dữ liệu có cấu trúc nếu muốn có rich result (Search Engine Land) — Mueller nói điều kiện đủ đòi hỏi cả mã đánh dấu đúng và tuân thủ chính sách.
• Hệ phân cấp kiểu schema.org — chính vốn từ vựng từ nguồn; xem nhóm “Product, Offer, and AggregateOffer” (bản dịch) «Product, Offer và AggregateOffer» và vị trí của JobPosting (cũng như nơi nó không nằm).

Nhật ký thay đổi