Schema Service rộng nhất để định nghĩa một dịch vụ được cung cấp bởi một doanh nghiệp, và thường là cốt lõi của hoạt động kinh doanh.  Mục đích chính của Service Schema là giúp các công cụ tìm kiếm, như Google, “hiểu rõ ràng về các dịch vụ được cung cấp, khu vực phục vụ và người cung cấp”. 

Vậy Schema Service có những thuộc tính nào? Thực hành và khai báo Schema Service ra sao? Tất cả sẽ được mình, Nguyễn Thanh Trường – Founder & CEO của SEO Center giải đáp chi tiết trong bài viết dưới đây.

Mục tiêu của bài viết này là giúp bạn hiểu rõ hơn về bản chất, kiến thức căn bản đến nâng cao của Schema Service, qua đó giúp bạn có thể tự mình triển khai cho chính website của mình được hiệu quả nhất. 

Nội dung chính của bài viết: 

  • Service Schema là dữ liệu có cấu trúc giúp Google hiểu rõ các dịch vụ bạn cung cấp, cải thiện đối sánh với truy vấn người dùng và tăng khả năng hiển thị trên công cụ tìm kiếm.
  • Dù Service Schema không trực tiếp tạo Rich Results, việc khai báo chi tiết các thuộc tính cốt lõi như tên, mô tả, nhà cung cấp, khu vực phục vụ và kết quả đầu ra là rất quan trọng để Google hiểu sâu về dịch vụ.
  • Để đạt được Rich Results và ngữ cảnh đầy đủ, Service Schema cần được kết hợp thông qua đa kiểu hóa với các loại schema khác như Product (cho giá, đánh giá) hoặc LocalBusiness (cho dịch vụ địa phương).
  • Thực hành tốt nhất là tạo schema riêng cho từng dịch vụ trên mỗi trang cụ thể, đồng thời liên tục kiểm tra và xác thực bằng các công cụ của Google.
  • Tuyệt đối không sử dụng Service schema trực tiếp làm đối tượng đánh giá (itemReviewed) để hiển thị rich snippets; thay vào đó, hãy lồng ghép đánh giá vào schema LocalBusiness hoặc Organization phù hợp.

Nội dung bài học

Service Schema là gì?

Service Schema là một loại dữ liệu có cấu trúc (structured data) được khai báo vào các trang dịch vụ để định nghĩa và mô tả các dịch vụ mà doanh nghiệp đang cung cấp. 

Service Schema là một loại dữ liệu có cấu trúc được khai báo vào các trang dịch vụ
Service Schema là một loại dữ liệu có cấu trúc được khai báo vào các trang dịch vụ

Service Schema là một phần trong hệ thống schema markup giúp công cụ tìm kiếm hiểu rõ ngữ cảnh của nội dung trang, từ đó phục vụ kết quả phù hợp hơn cho các truy vấn liên quan đến dịch vụ.

Nói một cách đơn giản, nếu công việc kinh doanh của bạn xoay quanh việc cung cấp các hoạt động, sự hỗ trợ, hoặc chuyên môn cho khách hàng (chứ không phải bán một sản phẩm vật lý cụ thể), thì đó chính là một “Service”.

Ví dụ:

  • Một công ty lợp mái nhà cung cấp “Dịch vụ Lợp mái”.
  • Một trung tâm Anh ngữ cung cấp “Dịch vụ Dạy tiếng Anh”.
  • Một công ty luật cung cấp “Dịch vụ Tư vấn pháp lý”.
  • Một dịch vụ giao hàng cung cấp “Dịch vụ Giao hàng tận nơi”.

Mục đích của Service Schema là gì?

Mục đích chính của việc sử dụng Service Schema là giúp các công cụ tìm kiếm (như Google) hiểu rõ ràng và tường minh những thông tin quan trọng về dịch vụ của bạn. Cụ thể, nó giúp Google biết:

  • Dịch vụ gì đang được cung cấp? (Ví dụ: “Sửa máy lạnh”, “Thiết kế website”).
  • Khu vực nào được phục vụ? (Ví dụ: “Toàn bộ TP.HCM”, “Chỉ quận Hoàn Kiếm, Hà Nội”).
  • Ai là người đang cung cấp dịch vụ đó? (Ví dụ: “Công ty TNHH Điện lạnh An Tâm”, “Cá nhân tự do”).

Khi Google hiểu rõ những điều này, nó có thể kết nối bạn với những người tìm kiếm phù hợp hơn.

Lợi ích của việc sử dụng Service Schema

Kết nối với biểu đồ tri thức (knowledge graph) của công cụ tìm kiếm

Khi bạn đánh dấu dịch vụ bằng dữ liệu có cấu trúc, thông tin đó có thể được liên kết trực tiếp vào biểu đồ tri thức của công cụ tìm kiếm. Biểu đồ tri thức là một kho dữ liệu khổng lồ mà Google xây dựng, chứa đựng các thực thể (người, địa điểm, tổ chức, dịch vụ…) và mối quan hệ giữa chúng.

Việc này giúp cung cấp sự liên quan và ngữ cảnh sâu sắc hơn cho nội dung của bạn.

Ví dụ: Nếu bạn cung cấp “Dịch vụ gia sư Toán cấp 2 tại nhà”, khi bạn dùng Service Schema, Google không chỉ biết bạn có trang này, mà còn hiểu rằng đây là một dịch vụ giáo dục, dành cho học sinh cấp 2, môn Toán, và có thể diễn ra tại nhà, liên kết nó với các khái niệm như “học tập”, “phát triển kỹ năng”.

Cải thiện khả năng đối sánh dịch vụ với truy vấn tìm kiếm của người dùng

Với sự hiểu biết sâu sắc hơn, công cụ tìm kiếm có thể hiển thị dịch vụ của bạn cho những người đang tìm kiếm với nhu cầu chính xác nhất.

Giúp Google và các công cụ tìm kiếm khác hiểu chính xác các dịch vụ và điều hướng lưu lượng truy cập phù hợp

Schema Markup trao cho bạn khả năng kiểm soát việc định nghĩa các dịch vụ mà doanh nghiệp bạn bán. Điều này cho phép Google và các công cụ tìm kiếm khác hiểu chính xác chúng, từ đó điều hướng lưu lượng truy cập phù hợp đến đúng trang trên website của bạn.

Google có thể hiển thị thông tin dịch vụ theo những cách độc đáo thông qua các tính năng SERP (như rich snippets), giúp nổi bật so với đối thủ

Mặc dù Google chủ yếu tập trung vào Product schema cho rich results (kết quả hiển thị đa dạng), nhưng thông tin từ Service Schema vẫn có thể được sử dụng để làm nổi bật website của bạn trên trang kết quả tìm kiếm (SERP).

Các thông tin này có thể góp phần vào việc hiển thị các tính năng SERP độc đáo, giúp bạn nổi bật hơn giữa hàng loạt đối thủ cạnh tranh.

Lưu ý chung từ Google khi triển khai schema Service

Tính năng dữ liệu có cấu trúc của Google không trực tiếp bao gồm “Service” cho rich results

Hiện tại, Google không trực tiếp ưu tiên loại schema “Service” để hiển thị các rich results (kết quả tìm kiếm hiển thị phong phú, nổi bật vớema). 

Điều này có nghĩa là, nếu bạn chỉ sử dụng Service schema, bạn có thể không thấy dịch vụ của mình xuất hiện với các yếu tố trực quan bắt mắt hình ảnh, đánh giá sao, giá cả…) như cách họ làm với schema sản phẩm (Product như một sản phẩm được đánh dấu bằng Product schema.

Các dịch vụ không có bất kỳ thuộc tính bắt buộc nào

Một điểm khác biệt lớn của Service schema là nó không có bất kỳ thuộc tính (properties) nào được yêu cầu là “bắt buộc”.

Lý do là các yêu cầu về thuộc tính bắt buộc thường chỉ áp dụng cho những loại dữ liệu đủ điều kiện để Google hiển thị Rich Results. Vì Service không phải là một trong những loại chính để tạo Rich Results trực tiếp, nên không có thuộc tính nào là “bắt buộc” theo quy định của Google.

Tuy nhiên, điều này không có nghĩa là bạn không nên sử dụng các thuộc tính. Ngược lại, việc cung cấp càng nhiều thông tin chi tiết bằng các thuộc tính có sẵn (như name, description, provider, areaServed, serviceOutput, v.v.) sẽ giúp Google hiểu dịch vụ của bạn một cách toàn diện hơn và vẫn mang lại các lợi ích SEO đã đề cập. 

Bạn nên quyết định điều gì quan trọng về dịch vụ đang được cung cấp và sử dụng các thuộc tính có sẵn để làm nổi bật điều đó trong markup.

15 thuộc tính hỗ trợ tốt nhất cho Schema Service

1. name

Đây là tên gọi chính thức của dịch vụ bạn đang cung cấp. Nó giúp công cụ tìm kiếm biết chính xác dịch vụ đó là gì.

Ví dụ:

  • “Dịch vụ thiết kế website chuyên nghiệp”
  • “Sửa chữa điều hòa tại nhà”
  • “Khóa học tiếng Anh giao tiếp cấp tốc”
Các loại thuộc tính hỗ trợ tốt nhất cho Schema Service
Các loại thuộc tính hỗ trợ tốt nhất cho Schema Service

2. additionalType

Thuộc tính này cho phép bạn mô tả dịch vụ một cách chi tiết hơn bằng cách liên kết đến các định nghĩa bên ngoài, thường là từ Wikidata hoặc Wikipedia. Điều này giúp cung cấp thêm ngữ cảnh cho công cụ tìm kiếm.

Ví dụ: Nếu dịch vụ của bạn là “Dịch vụ sửa ống nước”, bạn có thể liên kết đến trang Wikipedia về “Sửa ống nước” (ví dụ: https://en.wikipedia.org/wiki/Plumbing) để làm rõ đây là loại dịch vụ gì.

3. areaServed

Thuộc tính này cho biết dịch vụ của bạn có sẵn ở đâu (khu vực địa lý). Tương tự như additionalType, bạn nên sử dụng liên kết Wikidata hoặc Wikipedia cho địa điểm đó, vì các mục nhập Wikidata thường có thông tin tọa độ vị trí. Điều này đặc biệt hữu ích cho các dịch vụ tại địa phương.

Ví dụ:

  • Nếu bạn cung cấp “Dịch vụ giao hàng tại TP.HCM”, bạn có thể liên kết đến trang Wikidata hoặc Wikipedia của Thành phố Hồ Chí Minh.
  • Đối với “Dịch vụ chăm sóc sân vườn tại Hà Nội”, bạn liên kết đến Hà Nội.

4. provider

Thuộc tính này xác định ai là người chịu trách nhiệm cung cấp dịch vụ. Thường thì đây sẽ là Organization (Tổ chức) hoặc LocalBusiness (Doanh nghiệp địa phương) mà trang dịch vụ đó thuộc về. Điều này giúp liên kết dịch vụ với thực thể doanh nghiệp chính.

Ví dụ:

  • Đối với “Dịch vụ tư vấn Marketing”, provider có thể là “Công ty TNHH Giải pháp Số ABC”.
  • Đối với “Sửa chữa ô tô”, provider có thể là “Gara ô tô An Phát”.

5. serviceOutput

Đây là sản phẩm hoặc kết quả cuối cùng mà khách hàng nhận được sau khi sử dụng dịch vụ. Nó mô tả cái “output” cụ thể của dịch vụ.

Ví dụ:

  • Nếu bạn là môi giới thế chấp, serviceOutput là “một khoản vay thế chấp”.
  • Nếu dịch vụ là xây dựng nhà, serviceOutput là “một ngôi nhà được xây theo yêu cầu”.
  • Với “Dịch vụ thiết kế logo”, serviceOutput có thể là “một bộ nhận diện thương hiệu hoàn chỉnh” hoặc “file thiết kế logo cuối cùng”.

6. description

Một đoạn văn bản mô tả ngắn gọn nhưng đầy đủ về dịch vụ, nêu bật các đặc điểm, lợi ích và những gì khách hàng có thể mong đợi.

Ví dụ: “Dịch vụ thiết kế website của chúng tôi giúp doanh nghiệp sở hữu một trang web chuyên nghiệp, tối ưu SEO và thân thiện với người dùng, thu hút khách hàng tiềm năng.”

7. image

Một URL hoặc đối tượng ImageObject mô tả hình ảnh đại diện cho dịch vụ. Việc này rất quan trọng vì nó có thể giúp dịch vụ của bạn đủ điều kiện hiển thị các kết quả đa dạng (rich results) nếu được đa kiểu hóa thành Product.

Ví dụ: Một hình ảnh minh họa một trang web được thiết kế đẹp mắt cho “Dịch vụ thiết kế website”, hoặc hình ảnh đội ngũ kỹ thuật đang sửa chữa máy lạnh cho “Sửa chữa điều hòa”.

8. url

Đây là địa chỉ web (liên kết) của trang dịch vụ cụ thể mà bạn đang áp dụng Schema Markup.

Ví dụ: https://seocenter.vn/dich-vu/thiet-ke-website

Các loại thuộc tính hỗ trợ tốt nhất cho Schema Service
Các loại thuộc tính hỗ trợ tốt nhất cho Schema Service

9. availableChannel

Thuộc tính này cho biết khách hàng có thể tiếp cận dịch vụ qua những kênh nào (ví dụ: tổng đài điện thoại, trang web, địa điểm vật lý). Khi bạn tạo một ServiceChannel (kênh dịch vụ), bạn có thể tận dụng thêm các thuộc tính điểm chạm như servicePhone (số điện thoại dịch vụ), servicePostalAddress (địa chỉ bưu chính dịch vụ) và serviceSmsNumber (số SMS dịch vụ).

Ví dụ:

  • Một ServiceChannel với servicePhone là “1900-xxxx” cho dịch vụ hỗ trợ khách hàng.
  • Một ServiceChannel với serviceUrl là https://yourwebsite.com/dat-lich-hen cho dịch vụ đặt lịch trực tuyến.

10. offers

Thuộc tính này mô tả một lời đề nghị để cung cấp dịch vụ (ví dụ: bán một sản phẩm, thuê một bộ phim, thực hiện một dịch vụ). Lưu ý rằng thuộc tính này yêu cầu thông tin về tính khả dụng và giá cả của mặt hàng được cung cấp. 

Nếu bạn không có đủ thông tin này trên trang web của mình, tốt nhất nên cân nhắc kỹ trước khi sử dụng để tránh lỗi trong markup.

Ví dụ: Trong offers, bạn có thể chỉ rõ “Giá dịch vụ sửa chữa điều hòa: 350.000 VNĐ” và “Tình trạng sẵn có: Luôn có sẵn”.

11. potentialAction

Thuộc tính này mô tả một hành động lý tưởng mà dịch vụ này sẽ đóng vai trò là “đối tượng”. Nó giúp công cụ tìm kiếm hiểu được những hành động mà người dùng có thể thực hiện liên quan đến dịch vụ của bạn.

Ví dụ:

  • “Đặt lịch hẹn tư vấn” (book a demo).
  • “Yêu cầu báo giá thiết kế website” (request a quote).

12. subjectOf

Bạn có thể sử dụng thuộc tính này để liên kết dịch vụ của mình với một CreativeWork (như Blog, Bài viết, Video) mà dịch vụ đó là chủ đề chính. Hoặc ngược lại, liên kết CreativeWork với Service bằng thuộc tính about.

Ví dụ: “Video hướng dẫn tự sửa lỗi đơn giản cho máy tính” (là CreativeWork) có subjectOf là “Dịch vụ sửa chữa máy tính” (là Service).

13. serviceType

Đây là một cơ hội khác để mô tả chi tiết hơn loại dịch vụ bạn cung cấp. Giá trị của thuộc tính này có thể là văn bản hoặc liên kết đến Wikipedia. serviceType mong đợi các giá trị thuộc loại GovernmentBenefitsType (Loại phúc lợi của chính phủ) hoặc Text (Văn bản).

Ví dụ:

  • Nếu là dịch vụ phúc lợi: https://schema.org/BusinessSupport.
  • Nếu là dịch vụ phổ biến: “Dịch vụ giặt ủi”, “Dịch vụ vệ sinh công nghiệp”.

14. logo

Một URL hoặc ImageObject cho logo của dịch vụ. Tuy nhiên, nguồn khuyến nghị bạn có thể bỏ trống thuộc tính này và chỉ cần tham chiếu đến Organization và logo của nó, nếu logo dịch vụ giống với logo tổ chức.

15. termsOfService

Các tài liệu điều khoản dịch vụ dễ đọc cho con người, có thể ở dạng văn bản hoặc URL.

Ví dụ: Liên kết đến trang “Điều khoản & Điều kiện” của dịch vụ của bạn.

Các loại Service Schema cụ thể bạn nên biết

Các loại con cụ thể của Service

Mặc dù tài liệu “Hướng dẫn toàn diện về Service Schema” chỉ liệt kê các số mục mà chưa có tên cụ thể trong phần này, các nguồn khác cho thấy Schema.org có nhiều loại con cụ thể hơn của Service. Việc sử dụng các loại con này (nếu có) sẽ giúp công cụ tìm kiếm hiểu dịch vụ của bạn một cách chính xác và chi tiết hơn.

Các loại Service Schema cụ thể được ghi nhận trong Schema.org
Các loại Service Schema cụ thể được ghi nhận trong Schema.org

Dưới đây là một số loại con cụ thể của Service mà Schema.org cung cấp:

  • BroadcastService (Dịch vụ Phát sóng): Dành cho các dịch vụ liên quan đến phát thanh, truyền hình.
  • CableOrSatelliteService (Dịch vụ Cáp hoặc Vệ tinh): Dành cho các nhà cung cấp dịch vụ truyền hình cáp hoặc vệ tinh.
  • FinancialProduct (Sản phẩm Tài chính): Mặc dù có tên là “Product”, đây là một loại con của Service, dùng cho các dịch vụ tài chính như cho vay, bảo hiểm.
  • FoodService (Dịch vụ Ăn uống): Dành cho nhà hàng, quán ăn, dịch vụ cung cấp đồ ăn.
  • GovernmentService (Dịch vụ Chính phủ): Dành cho các dịch vụ do chính phủ cung cấp (ví dụ: cấp phép, hỗ trợ xã hội).
  • TaxiService (Dịch vụ Taxi): Dành cho các dịch vụ vận chuyển hành khách bằng taxi.
  • WebAPI (API Web): Dành cho các dịch vụ được cung cấp thông qua giao diện lập trình ứng dụng web.

Lưu ý: Trước đây, lớp ProfessionalService (Dịch vụ Chuyên nghiệp) thường được sử dụng, nhưng Schema.org đã ngừng sử dụng nó để ủng hộ lớp Service tổng quát hơn hoặc các lớp con cụ thể hơn. Do đó, bạn nên sử dụng Service hoặc một trong các lớp con chuyên biệt hơn thay vì ProfessionalService.

Ví dụ về các loại dịch vụ

Dịch vụ tại nhà (Home services):

  • Dịch vụ lợp mái nhà.
  • Dịch vụ sửa chữa ống nước.
  • Dịch vụ chăm sóc sân vườn.
  • Dịch vụ vệ sinh nhà cửa.
  • Dịch vụ sửa chữa & thay thế đồ dùng trong nhà.
  • Dịch vụ trang trí/thiết kế nội thất.
  • Dịch vụ lắp đặt (ví dụ: lắp đặt lò sưởi mới).

Dịch vụ chuyên nghiệp (Professional services):

  • Dịch vụ tiếp thị.
  • Dịch vụ tối ưu hóa công cụ tìm kiếm (SEO).
  • Dịch vụ bào chữa trong tòa án (dịch vụ luật pháp).

Các dịch vụ khác:

  • Dịch vụ giao hàng.
  • Dịch vụ in ấn.
  • Dịch vụ rửa xe.

Ví dụ về JSON-LD của Schema Service

Để minh họa cụ thể cách bạn tạo mã Service schema, chúng ta sẽ xem xét một ví dụ JSON-LD đơn giản và dễ hiểu, dựa trên các ví dụ thực tế của Schema.org. Tôi sẽ lấy ví dụ về một công ty “Dọn dẹp nhà cửa An Phát” cung cấp nhiều dịch vụ khác nhau.

Tình huống: Công ty “Dọn dẹp nhà cửa An Phát” cung cấp các dịch vụ như “Vệ sinh căn hộ nhẹ”, “Vệ sinh nhà cửa 2 phòng ngủ trở xuống”, “Vệ sinh nhà cửa 3 phòng ngủ trở lên”, “Lau cửa sổ”, “Giặt thảm chuyên sâu”, và “Vệ sinh chuyển nhà/chuyển đi”. Công ty hoạt động tại khu vực Hà Nội.

Đây là cách bạn có thể định nghĩa các dịch vụ này bằng JSON-LD, tập trung vào Service và OfferCatalog để nhóm các dịch vụ:

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Service",
  "name": "Dịch vụ Dọn dẹp nhà cửa An Phát",
  "description": "Công ty An Phát cung cấp đa dạng các dịch vụ dọn dẹp nhà cửa chất lượng cao tại Hà Nội, bao gồm dọn dẹp định kỳ, dọn dẹp chuyên sâu và các dịch vụ theo yêu cầu.",
  "serviceType": "Dọn dẹp nhà cửa",
  "provider": {
    "@type": "LocalBusiness",
    "name": "Dọn dẹp nhà cửa An Phát",
    "url": "https://www.anphatcleaning.vn"
  },
  "areaServed": {
    "@type": "AdministrativeArea",
    "name": "Hà Nội"
  },
  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "Danh mục Dịch vụ Vệ sinh",
    "itemListElement": [
      {
        "@type": "OfferCatalog",
        "name": "Dịch vụ Vệ sinh Định kỳ",
        "itemListElement": [
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "name": "Vệ sinh căn hộ nhẹ"
            }
          },
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "name": "Vệ sinh nhà cửa 2 phòng ngủ trở xuống"
            }
          },
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "name": "Vệ sinh nhà cửa 3 phòng ngủ trở lên"
            }
          }
        ]
      },
      {
        "@type": "OfferCatalog",
        "name": "Dịch vụ Một lần",
        "itemListElement": [
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "name": "Lau cửa sổ"
            }
          },
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "name": "Giặt thảm chuyên sâu"
            }
          },
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "name": "Vệ sinh chuyển nhà/chuyển đi"
            }
          }
        ]
      }
    ]
  }
}
</script>
JSON

Giải thích ví dụ JSON-LD trên:

  • "@context": "https://schema.org/": Luôn là phần bắt buộc, cho công cụ tìm kiếm biết bạn đang sử dụng từ vựng của Schema.org.
  • "@type": "Service": Đây là loại chính chúng ta đang định nghĩa – một Dịch vụ.
  • "name": “Dịch vụ Dọn dẹp nhà cửa An Phát”: Tên tổng thể của dịch vụ hoặc nhóm dịch vụ mà công ty cung cấp.
  • "description": "...": Một đoạn mô tả ngắn gọn về dịch vụ này.
  • "serviceType": “Dọn dẹp nhà cửa”: Cung cấp thông tin cụ thể hơn về loại hình dịch vụ. Thuộc tính serviceType có thể là văn bản hoặc liên kết đến Wikipedia/Wikidata.
  • "provider": { ... }: Cho biết ai là người cung cấp dịch vụ này. Trong trường hợp này, đó là một LocalBusiness (Doanh nghiệp Địa phương) tên là “Dọn dẹp nhà cửa An Phát” với URL website của họ. Việc liên kết đến LocalBusiness của bạn là một cách tuyệt vời để kết nối Service với thông tin doanh nghiệp chi tiết hơn.
  • "areaServed": { … }: Định nghĩa khu vực địa lý mà dịch vụ này được cung cấp. Ở đây là “Hà Nội” dưới dạng AdministrativeArea. Việc liên kết đến một thực thể Wikidata cho địa điểm (nếu có) cũng được khuyến nghị.
  • "hasOfferCatalog": { ... }: Đây là một thuộc tính rất hữu ích khi bạn có nhiều dịch vụ con hoặc gói dịch vụ. Nó cho phép bạn tạo một “danh mục ưu đãi” các dịch vụ.
    • Bên trong hasOfferCatalog, chúng ta tạo các nhóm dịch vụ (OfferCatalog) như “Dịch vụ Vệ sinh Định kỳ” và “Dịch vụ Một lần”.
    • Mỗi nhóm này lại chứa các itemListElement, trong đó mỗi phần tử là một Offer (ưu đãi) cho một itemOffered cụ thể.
    • "itemOffered": { "@type": "Service", "name": "..." }: Mỗi itemOffered lại là một Service riêng biệt với tên dịch vụ cụ thể (ví dụ: “Vệ sinh căn hộ nhẹ”). Điều này giúp công cụ tìm kiếm hiểu rõ từng dịch vụ nhỏ bạn cung cấp.

2 phương pháp sử dụng Service Schema

Phương pháp 1. Loại Schema đã bị loại bỏ

Trước đây, khi bạn muốn đánh dấu một dịch vụ chuyên nghiệp (như luật sư, kế toán), có một loại schema tên là ProfessionalService đã được sử dụng khá phổ biến. Tuy nhiên, Schema.org đã quyết định loại bỏ loại này để ủng hộ một loại tổng quát hơn là Service.

Vậy điều này có ý nghĩa gì? Đơn giản là bạn không nên sử dụng ProfessionalService nữa. Thay vào đó, bạn nên dùng loại Service hoặc các lớp con (subclass) cụ thể hơn của Service nếu có, để đảm bảo mã schema của bạn luôn được cập nhật và hiệu quả.

Ví dụ minh họa: Giả sử bạn là một công ty marketing cung cấp dịch vụ SEO. Thay vì dùng ProfessionalService (đã bị loại bỏ), bạn sẽ dùng loại Service và sau đó có thể bổ sung các thuộc tính như additionalType để mô tả cụ thể hơn là “Dịch vụ Tối ưu hóa Công cụ Tìm kiếm” (Search Engine Optimization Service).

Phương pháp 2. Kết hợp Service Schema với các loại Schema khác

1. Kết hợp Service và Product

Đôi khi, ranh giới giữa một “sản phẩm” và một “dịch vụ” khá mờ nhạt. Schema.org định nghĩa Product là “Bất kỳ sản phẩm hoặc dịch vụ nào được cung cấp”. Điều này có nghĩa là về mặt lý thuyết, một dịch vụ cũng có thể được xem là một sản phẩm.

Bạn nên xem xét việc gán đa loại (multi-typing) một mục dữ liệu vừa là Product vừa là Service khi:

  • Muốn tận dụng các thuộc tính riêng của Service: Ví dụ như provider (người cung cấp) và areaServed (khu vực phục vụ).
  • Có các yếu tố cần thiết để đủ điều kiện cho kết quả phong phú (rich result) của Product: Điều này bao gồm việc có hình ảnh và thông tin về giá cả, đánh giá tổng hợp (aggregateRating) hoặc đánh giá (review).

Mặc dù vậy, luôn tốt nhất là sử dụng loại schema.org định nghĩa mục dữ liệu của bạn cụ thể nhất. Nếu một dịch vụ của bạn có thể được hưởng lợi từ cả hai bộ thuộc tính và đáp ứng các yêu cầu về rich result của Product, multi-typing là một lựa chọn mạnh mẽ.

Ví dụ minh họa: Một tiệm sửa xe máy không chỉ cung cấp dịch vụ sửa chữa (là Service) mà còn bán các phụ tùng, linh kiện (là Product). Trong trường hợp này, bạn có thể multi-type trang phụ tùng là cả Product và Service. 

Hoặc, một dịch vụ rửa xe cao cấp cung cấp gói dịch vụ (là Service) nhưng cũng bán kèm các sản phẩm chăm sóc xe độc quyền (là Product). Nếu bạn muốn trang dịch vụ rửa xe của mình hiển thị rich result với giá và đánh giá như một sản phẩm, đồng thời vẫn mô tả rõ ràng người cung cấp và khu vực phục vụ, bạn có thể multi-type nó.

2. Service cho Dịch vụ tại địa phương

Google không trực tiếp bao gồm “Service” trong tài liệu dữ liệu có cấu trúc cho các tính năng nâng cao trong kết quả tìm kiếm, nhưng họ lại hỗ trợ LocalBusiness.

Để tối ưu cho các dịch vụ tại địa phương, bạn có thể:

  • Sử dụng thuộc tính provider trong schema Service để liên kết đến schema Organization hoặc LocalBusiness của doanh nghiệp bạn. Điều này giúp Google hiểu rõ ai là người cung cấp dịch vụ.
  • Sử dụng thuộc tính areaServed để chỉ rõ khu vực mà dịch vụ được cung cấp. Bạn nên liên kết thuộc tính này với một thực thể Wikidata cho địa điểm đó, vì các mục nhập Wikidata thường có thông tin tọa độ vị trí, giúp Google hiểu rõ hơn về phạm vi hoạt động của bạn.

Ví dụ minh họa: Một cửa hàng sửa chữa điện thoại di động tại quận 1, TP.HCM. Bạn có thể tạo schema LocalBusiness cho cửa hàng, và sau đó tạo schema Service cho “Dịch vụ thay màn hình iPhone”, trong đó:

  • provider sẽ trỏ về schema LocalBusiness của cửa hàng.
  • areaServed sẽ được định nghĩa là “Quận 1, TP.HCM” (có thể liên kết đến Wikidata của Quận 1 nếu có).

3. Service cho Phần mềm dưới dạng Dịch vụ

Mã schema cho SaaS có thể phức tạp hơn một chút vì từ vựng schema.org không có các loại cụ thể để mô tả trực tiếp loại hình này.

Khi áp dụng schema cho SaaS, bạn có thể:

  • Đối với các sản phẩm SaaS cụ thể: Hãy sử dụng SoftwareApplication, Product, hoặc multi-type cả hai, tùy thuộc vào định nghĩa nào phù hợp nhất với sản phẩm của bạn và bạn muốn nội dung đó đủ điều kiện cho loại rich result nào.
  • Nếu bạn chỉ muốn sử dụng Service một cách tổng quát hơn: Bạn có thể dùng thuộc tính sameAs hoặc additionalType để liên kết đến một thực thể Wiki có định nghĩa cụ thể hơn về loại dịch vụ SaaS của bạn (ví dụ: “quản lý dịch vụ CNTT” hoặc “bảo mật kỹ thuật số”).
Service cho Phần mềm dưới dạng Dịch vụ
Service cho Phần mềm dưới dạng Dịch vụ

Ví dụ minh họa: Một công ty cung cấp phần mềm quản lý kho hàng online.

  • Nếu phần mềm có tên cụ thể (ví dụ: “Phần mềm Quản lý Kho ABC”), bạn có thể dùng SoftwareApplication hoặc Product.
  • Nếu bạn muốn mô tả chung về “Dịch vụ quản lý kho dựa trên nền tảng đám mây”, bạn có thể dùng Service và trong additionalType hoặc sameAs, bạn liên kết đến trang Wikipedia hoặc Wikidata về “Quản lý chuỗi cung ứng” hoặc “Phần mềm doanh nghiệp”.

4. Schema Đánh giá Dịch vụ

Đây là một điểm khá phức tạp và thường gây nhầm lẫn. Nhiều người muốn thêm AggregateRating (đánh giá tổng hợp) vào schema JSON-LD cho các dịch vụ, đặc biệt là các dịch vụ được cung cấp bởi cá nhân hoặc freelancer.

Vấn đề nảy sinh vì Google yêu cầu phải đề cập rõ ràng đến một sản phẩm hoặc dịch vụ cụ thể bằng cách lồng ghép đánh giá vào markup của một loại schema.org khác. Người hỏi ban đầu băn khoăn liệu có nên dùng Organization hay LocalBusiness không, vì người cung cấp dịch vụ của họ chủ yếu là freelancer (không hẳn là công ty truyền thống), và loại Person (cá nhân) lại không được hỗ trợ cho rich results.

Và có 1 số khuyến nghị từ các chuyên gia từ Google như sau:

  • Aubrey Yung (Chuyên gia sản phẩm Vàng của Google) đề xuất rằng LocalBusiness hoặc Organization là những lựa chọn tốt nhất và hợp lệ cho các loại itemReviewed (đối tượng được đánh giá). Ông cũng gợi ý tìm kiếm các loại con cụ thể hơn dưới LocalBusiness (ví dụ: Plumber, Electrician) nếu phù hợp với dịch vụ.
  • Santiago Parra Suarez (Tư vấn Marketing SEO) gợi ý rằng Service có thể linh hoạt hơn cho freelancer và cá nhân cung cấp dịch vụ cụ thể, và có thể lồng ghép AggregateRating vào loại Service.

=> Bạn có thể xem chi tiết các khuyến nghị này tại Google Search Central Community với chủ đề Which schema for service reviews?1

Và quan trọng nhất, Aubrey Yung đã nhấn mạnh rằng Service không phải là một loại itemReviewed được hỗ trợ cho rich results. Nếu bạn sử dụng Service trong thuộc tính itemReviewed để hiển thị đánh giá tổng hợp, bạn sẽ gặp lỗi trong công cụ kiểm tra Rich Results Test của Google.

Người đặt câu hỏi ban đầu đã chấp nhận câu trả lời của Aubrey Yung, khẳng định rằng LocalBusiness hoặc Organization là lựa chọn tốt nhất cho mục đích đánh giá dịch vụ.

Ví dụ: Bạn có một website nơi các gia sư tiếng Anh độc lập (freelancer) đăng dịch vụ và học viên có thể đánh giá họ.

  • Bạn không thể trực tiếp thêm AggregateRating vào schema Service của từng gia sư để hiển thị rich snippet đánh giá.
  • Thay vào đó, bạn nên xem xét việc mỗi gia sư được định nghĩa là một LocalBusiness hoặc Organization (ví dụ: “Gia sư Tiếng Anh [Tên gia sư]”) trên trang của họ. Sau đó, bạn lồng ghép AggregateRating vào schema LocalBusiness đó. Hoặc, nếu là một nền tảng lớn, bạn có thể đánh giá cả “Nền tảng Gia sư XYZ” dưới dạng Organization.

Cách triển khai Service Schema Markup

Chiến lược triển khai Service Schema tổng thể với 7 bước

Bước 1. Xác định các trang cần tối ưu hóa

Đầu tiên và quan trọng nhất, bạn cần biết trang nào trên website của bạn đang mô tả một dịch vụ cụ thể mà bạn muốn công cụ tìm kiếm hiểu rõ.
Ví dụ: Nếu bạn có một công ty thiết kế nội thất, bạn sẽ có các trang riêng cho “Thiết kế phòng khách”, “Thiết kế phòng ngủ”, “Tư vấn chọn vật liệu”, v.v. Mỗi trang này đều là một ứng cử viên cho Service Schema.

Bước 2: Chọn từ vựng Schema.org phù hợp

Sau khi xác định trang, bạn cần quyết định loại schema.org nào sẽ mang lại kết quả tìm kiếm tự nhiên tốt nhất và nhiều rich results (kết quả phong phú) nhất từ Google.
Mặc dù chúng ta đang nói về Service schema, nhưng như đã thảo luận trước đó, đôi khi bạn cần kết hợp nó với Product hoặc LocalBusiness để đạt được rich results mong muốn.

Bước 3: Phát triển chiến lược schema của bạn

Đừng chỉ thêm schema một cách ngẫu nhiên. Hãy lập một kế hoạch chi tiết về cách bạn sẽ cấu trúc dữ liệu cho từng dịch vụ, những thuộc tính nào sẽ được sử dụng và cách chúng sẽ liên kết với nhau.
Ví dụ: Với công ty thiết kế nội thất, bạn có thể quyết định rằng mỗi dịch vụ thiết kế (như “Thiết kế phòng khách”) sẽ có schema Service riêng, liên kết đến LocalBusiness của công ty bạn bằng thuộc tính provider, và có thể đa kiểu (multi-type) với Product nếu bạn có đánh giá và giá cả rõ ràng cho gói dịch vụ đó.

Bước 4: Tạo và triển khai schema markup, sau đó xác thực

Sau khi có chiến lược, bạn sẽ bắt đầu viết mã schema và đưa nó lên website. Điều cực kỳ quan trọng là phải kiểm tra xem mã của bạn có hoạt động đúng như mong đợi hay không bằng các công cụ như Google Rich Results Test Tool.

Bước 5: Quyết định điều gì quan trọng về dịch vụ

Không phải tất cả các thuộc tính của Service schema đều cần thiết. Bạn cần xem xét thông tin nào là quan trọng nhất về dịch vụ đang được cung cấp và sử dụng các thuộc tính có sẵn để làm nổi bật thông tin đó trong mã schema.
Ví dụ: Đối với dịch vụ “Thiết kế phòng khách”, các thông tin quan trọng có thể là: tên dịch vụ (name), mô tả (description), khu vực phục vụ (areaServed), hình ảnh dự án đã thực hiện (image), và kết quả của dịch vụ (serviceOutput) là “Không gian phòng khách đẹp, tiện nghi và cá nhân hóa”.

Bước 6: Bắt đầu bằng cách tìm kiếm các thuộc tính chứa từ “service”

Để dễ dàng hơn trong việc lựa chọn, bạn có thể tìm kiếm các thuộc tính có từ “service” trong tên hoặc mô tả của chúng để bắt đầu. Các thuộc tính được khuyến nghị thường là name, additionalType, areaServed, provider, serviceOutput, description, image, url.

Bước 7: Cân nhắc thêm nội dung nếu thiếu

Nếu trang dịch vụ của bạn chưa có đầy đủ thông tin cần thiết cho một thuộc tính quan trọng (ví dụ: thiếu hình ảnh của dịch vụ), hãy cân nhắc bổ sung nội dung đó lên trang web trước để mã schema có thể trỏ đến thông tin thực tế. Điều này giúp tăng cường sự liên quan và độ tin cậy.

Vị trí đặt Service Schema

Thêm schema riêng cho từng dịch vụ trên mỗi trang dịch vụ riêng lẻ là thực hành tốt nhất. Mỗi trang dành riêng cho một dịch vụ cụ thể của bạn nên có một schema Service độc lập. Việc này giúp công cụ tìm kiếm hiểu rõ từng dịch vụ một cách cụ thể.

Thêm schema riêng cho từng dịch vụ trên mỗi trang dịch vụ riêng lẻ
Thêm schema riêng cho từng dịch vụ trên mỗi trang dịch vụ riêng lẻ

Ví dụ: Trang /dich-vu/thiet-ke-phong-khach sẽ có schema Service mô tả “Dịch vụ thiết kế phòng khách”. Trang /dich-vu/thiet-ke-phong-ngu sẽ có một schema Service khác mô tả “Dịch vụ thiết kế phòng ngủ”. Bạn không nên chỉ đặt một schema Service chung chung trên trang tổng hợp các dịch vụ của mình mà không có trên các trang con cụ thể.

Nếu trang dịch vụ của bạn có nhúng video (ví dụ: video giới thiệu dịch vụ, video dự án đã hoàn thành), bạn nên bổ sung thêm schema VideoObject để cung cấp thông tin chi tiết về video đó cho công cụ tìm kiếm.

Các công cụ hỗ trợ tạo Service Schema Markup

Schema App

Đây là một giải pháp end-to-end (từ đầu đến cuối) về Semantic Schema Markup. Schema App cung cấp quyền truy cập vào tất cả các thuộc tính của Schema.org/Service.

Họ có các hướng dẫn cụ thể về cách thêm schema markup cho Services bằng công cụ Schema App Editor của họ.

Nếu bạn có nhu cầu triển khai và quản lý schema markup ở quy mô lớn, đội ngũ chuyên gia dữ liệu có cấu trúc của Schema App có thể hỗ trợ bạn tiết kiệm thời gian và chi phí.

Rank Math (cho WordPress)

Nếu bạn sử dụng WordPress, Rank Math là một plugin SEO mạnh mẽ hỗ trợ việc thêm Service Schema. Việc sử dụng nó giúp các công cụ tìm kiếm hiểu rõ hơn nội dung trang của bạn và thông tin về doanh nghiệp cung cấp dịch vụ, từ đó Google có thể hiển thị chúng theo những cách độc đáo thông qua các tính năng SERP như rich snippets, giúp bạn nổi bật hơn so với đối thủ cạnh tranh.

Các bước thêm Service Schema Markup với Rank Math
Các bước thêm Service Schema Markup với Rank Math

Các bước thêm Service Schema Markup với Rank Math:

  • Bước 1: Bật mô-đun Schema: Đảm bảo mô-đun Schema của Rank Math đã được bật trong khu vực quản trị WordPress của bạn (Rank Math > Dashboard > Modules).
  • Bước 2: Chỉnh sửa bài đăng hoặc trang: Di chuyển đến bài đăng hoặc trang mà bạn muốn thêm schema và nhấp vào nút “Chỉnh sửa”.
  • Bước 3: Mở Rank Math trong thanh bên Gutenberg: Sau khi mở trang để chỉnh sửa, tìm biểu tượng Rank Math ở thanh bên Gutenberg (phía bên phải màn hình) và nhấp vào đó.
  • Bước 4: Truy cập Cài đặt Schema: Trong bảng điều khiển Rank Math, đi đến tab “Schema”, sau đó nhấp vào nút “Schema Generator”.
  • Bước 5: Chọn loại Service Schema: Trong cửa sổ bật lên, tìm “Service Schema” từ danh sách và nhấp vào “Use” để mở Schema Builder.

Các tùy chọn cấu hình chính trong Schema Builder:

  • Headline (Tiêu đề): Nhập tiêu đề chứa tên dịch vụ. Bạn có thể sử dụng các biến để tự động điền thông tin từ tiêu đề bài đăng.
  • Description (Mô tả): Thêm mô tả ngắn gọn về dịch vụ của bạn. Cũng có thể sử dụng các biến.
  • Shortcode: Bạn có thể sao chép và dán shortcode này vào nội dung để hiển thị dữ liệu Service Schema trên giao diện người dùng (phần hiển thị cho khách truy cập).
  • Service Type (Loại dịch vụ): Nhập loại dịch vụ được cung cấp (ví dụ: “rửa xe”, “trang trí nhà cửa”). Lưu ý rằng thuộc tính serviceType mong đợi các giá trị thuộc loại GovernmentBenefitsType hoặc Text.
  • Offers (Ưu đãi): Nhập giá của dịch vụ vào trường “Price” và mã tiền tệ tuân thủ ISO 4217 (ví dụ: VND cho Việt Nam đồng, USD cho đô la Mỹ) vào trường “Currency”.

Lưu và kiểm tra: Sau khi hoàn tất các thay đổi, nhấp vào “Save for this Post” và cập nhật/xuất bản trang của bạn. Cuối cùng, sử dụng Google Rich Results Testing Tool để kiểm tra xem mã Service Schema của bạn đã được áp dụng đúng cách chưa.

Ví dụ minh họa việc sử dụng Rank Math: Giả sử bạn có một trang WordPress cho dịch vụ “Vệ sinh nhà cửa định kỳ” của công ty bạn:

  • Bạn vào trang “Vệ sinh nhà cửa định kỳ” trong WordPress.
  • Mở Rank Math ở thanh bên.
  • Vào “Schema” -> “Schema Generator” -> Chọn “Service”.

Trong Schema Builder:

  • Headline: “Dịch vụ Vệ sinh nhà cửa định kỳ tại TP.HCM”
  • Description: “Giữ cho ngôi nhà của bạn luôn sạch sẽ và tươi mới với gói vệ sinh định kỳ chuyên nghiệp của chúng tôi.”
  • Service Type: “Vệ sinh nhà cửa”.
  • Offers: Price là “250000” (VND), Currency là “VND” (cho gói cơ bản).

Lưu lại và kiểm tra với Google Rich Results Testing Tool.

Kết luận

Qua những gì chúng ta đã thảo luận, có thể thấy rằng việc triển khai Service Schema là một chiến lược SEO nâng cao quan trọng giúp các doanh nghiệp truyền tải thông tin về dịch vụ của mình đến các công cụ tìm kiếm một cách rõ ràng và chính xác. 

Bài viết trên được mình nghiên cứu, phân tích và tổng hợp từ nhiều nguồn uy tín như Google Search Central, Schema.org, RankMath,…. Cùng với hơn 7 năm làm SEO của mình. Nếu bạn còn điều gì thắc mắc thì hãy để lại thông tin ở phần comment để cùng nhau trao đổi nhé!

Nguồn bài viết tham khảo:

  1. https://support.google.com/webmasters/thread/298507211/which-schema-for-service-reviews?hl=en ↩︎
Hãy đánh giá nội dung