Các loại schema markup phổ biến

Website nên sử dụng những loại schema markup nào?

Không có một bộ schema cố định áp dụng cho mọi website. Loại schema cần dùng phụ thuộc vào mô hình kinh doanh, loại nội dung và mục đích của từng URL.

Phần lớn website có thể bắt đầu với nhóm schema nền tảng gồm Organization, WebSite, WebPage và BreadcrumbList. Sau đó, từng mẫu trang sẽ sử dụng schema chuyên biệt như Article cho bài viết, Product cho sản phẩm, LocalBusiness cho địa điểm kinh doanh, Event cho sự kiện hoặc JobPosting cho tin tuyển dụng.

Ba lớp schema nên có trên website

Một hệ thống structured data hoàn chỉnh thường được tổ chức thành ba lớp.

Lớp thứ nhất mô tả chủ thể sở hữu hoặc vận hành website. Đây có thể là Organization, LocalBusiness, OnlineStore, EducationalOrganization hoặc Person.

Lớp thứ hai mô tả website và cấu trúc trang. Các loại thường dùng gồm WebSite, WebPage và BreadcrumbList.

Lớp thứ ba mô tả nội dung chính của từng URL. Ví dụ:

• Trang bài viết dùng Article hoặc BlogPosting

• Trang chi tiết sản phẩm dùng Product

• Trang chi nhánh dùng LocalBusiness

• Trang hồ sơ tác giả dùng ProfilePage và Person

• Trang sự kiện dùng Event

• Trang tuyển dụng dùng JobPosting

• Trang công thức dùng Recipe

• Trang video dùng VideoObject

Cách phân lớp này giúp website tránh tạo nhiều khối schema rời rạc, trùng lặp hoặc mâu thuẫn với nhau.

Nguyên tắc chọn main entity cho từng URL

Mỗi trang nên có một thực thể chính, còn gọi là main entity. Đây là đối tượng quan trọng nhất mà nội dung của URL đang mô tả.

Ví dụ:

• Trang chủ có thể lấy Organization hoặc WebSite làm thực thể trung tâm

• Trang sản phẩm lấy Product làm main entity

• Trang bài viết lấy Article làm main entity

• Trang tác giả lấy Person làm main entity

• Trang chi nhánh lấy LocalBusiness làm main entity

Một trang có thể chứa nhiều loại schema, nhưng không nên có nhiều thực thể cùng cạnh tranh vai trò nội dung chính mà không có quan hệ rõ ràng.

Schema hợp lệ chưa chắc tạo rich result

Schema.org cung cấp một hệ thống từ vựng rất rộng. Trong khi đó, công cụ tìm kiếm chỉ hỗ trợ một số loại schema và thuộc tính nhất định cho các hình thức hiển thị nâng cao.

Điều này có nghĩa là một đoạn dữ liệu có thể hợp lệ về cú pháp nhưng không tạo rich result. Ví dụ, một loại schema tồn tại trong Schema.org không đồng nghĩa Google sẽ sử dụng loại đó để bổ sung thông tin trên trang kết quả.

Doanh nghiệp nên phân biệt rõ hai mục tiêu:

• Mô tả nội dung và quan hệ thực thể

• Đáp ứng điều kiện cho một loại kết quả tìm kiếm nâng cao

Schema không phải cam kết về thứ hạng và cũng không bảo đảm kết quả tìm kiếm luôn hiển thị theo hình thức mong muốn.

Nhóm schema nền tảng cho hầu hết website

Nhóm schema nền tảng giúp công cụ tìm kiếm hiểu ai sở hữu website, website có tên gì, từng URL thuộc website nào và trang đang nằm ở đâu trong cấu trúc điều hướng.

Organization

Organization mô tả doanh nghiệp, thương hiệu, tổ chức, cơ quan hoặc đơn vị đứng sau website.

Các thuộc tính thường được sử dụng gồm:

• Tên tổ chức

• Tên pháp lý

• URL chính thức

• Logo

• Địa chỉ

• Thông tin liên hệ

• Hồ sơ chính thức trên các nền tảng khác

• Ngày thành lập

• Mã số thuế hoặc thông tin pháp lý khi phù hợp

Organization nên được tạo như một thực thể thống nhất, sử dụng một định danh ổn định và được các schema khác tham chiếu lại.

Ví dụ, Article có thể liên kết đến Organization qua thuộc tính publisher. WebSite cũng có thể liên kết đến cùng Organization. Khi đó, công cụ tìm kiếm có thể hiểu bài viết và website đều thuộc cùng một đơn vị xuất bản.

Lỗi thường gặp là website tạo một Organization khác nhau trên từng trang hoặc để nhiều plugin sinh ra các Organization có tên, logo và URL không đồng nhất.

WebSite

WebSite đại diện cho toàn bộ website, không phải một URL riêng lẻ.

Schema này giúp làm rõ:

• Tên website

• URL chính

• Đơn vị sở hữu hoặc xuất bản

• Mối quan hệ giữa website và các trang con

WebSite thường chỉ cần được khai báo như một thực thể chung. Các WebPage bên trong có thể tham chiếu lại bằng thuộc tính isPartOf.

Không nên tạo nhiều WebSite có định danh khác nhau trên cùng một tên miền nếu chúng đều mô tả cùng một website.

WebPage

WebPage đại diện cho một URL cụ thể. Nó đóng vai trò liên kết giữa website, nội dung chính, breadcrumb, tác giả và nhà xuất bản.

Một trang bài viết có thể được mô hình hóa như sau:

• WebSite đại diện cho toàn bộ website

• WebPage đại diện cho URL bài viết

• Article là nội dung chính của WebPage

• Person là tác giả

• Organization là đơn vị xuất bản

• BreadcrumbList mô tả vị trí của trang

WebPage còn có nhiều loại chuyên biệt như AboutPage, ContactPage, CollectionPage, ProfilePage hoặc ItemPage.

Website không nhất thiết phải xây dựng WebPage quá phức tạp trên mọi URL. Tuy nhiên, với hệ thống nhiều loại nội dung, WebPage là lớp hữu ích để kết nối các thực thể thành một graph rõ ràng.

BreadcrumbList

BreadcrumbList mô tả đường dẫn phân cấp của trang.

Ví dụ:

Trang chủ → Kiến thức SEO → Technical SEO → Schema markup

Loại schema này đặc biệt hữu ích cho website có nhiều danh mục, website thương mại điện tử, báo điện tử hoặc cổng nội dung lớn.

Breadcrumb schema phải phản ánh đúng điều hướng thực tế. Không nên tạo một chuỗi breadcrumb giả để chèn thêm từ khóa.

Các lỗi phổ biến gồm:

• Sai thứ tự vị trí

• URL trung gian không tồn tại

• Breadcrumb trong schema khác với breadcrumb hiển thị

• Mọi trang đều sử dụng cùng một chuỗi

• Bỏ qua cấp danh mục quan trọng

• Dùng URL chuyển hướng thay vì URL chính

Nhóm schema cho nội dung xuất bản

Website blog, báo điện tử, trang kiến thức và nền tảng chuyên môn thường cần Article, BlogPosting, NewsArticle, Person và ProfilePage.

Article

Article là loại tổng quát dành cho nội dung bài viết.

Schema này phù hợp với:

• Bài phân tích

• Bài hướng dẫn

• Bài nghiên cứu

• Nội dung kiến thức

• Bài chuyên môn

• Bài tin tức khi không dùng loại chuyên biệt hơn

Các thuộc tính quan trọng thường gồm:

• Tiêu đề

• Mô tả

• Hình ảnh

• Ngày xuất bản

• Ngày cập nhật

• Tác giả

• Đơn vị xuất bản

• Trang chính chứa bài viết

• Chuyên mục

• Ngôn ngữ

Article schema nên lấy dữ liệu trực tiếp từ CMS. Nếu tiêu đề, tác giả hoặc ngày sửa đổi được nhập thủ công ở một nguồn khác, rất dễ xảy ra sai lệch giữa nội dung hiển thị và dữ liệu có cấu trúc.

BlogPosting

BlogPosting là loại chuyên biệt của Article, phù hợp với bài đăng blog hoặc nội dung kiến thức được xuất bản theo mô hình blog.

Dùng BlogPosting khi URL rõ ràng thuộc khu vực blog, tài nguyên, kiến thức hoặc chuyên mục tư vấn.

Không nên dùng BlogPosting cho:

• Trang dịch vụ

• Trang danh mục

• Trang giới thiệu doanh nghiệp

• Landing page bán hàng

• Trang hồ sơ tác giả

Việc một trang có nhiều chữ không đồng nghĩa trang đó là bài blog.

NewsArticle

NewsArticle phù hợp với nội dung có tính thời sự, phản ánh sự kiện mới hoặc được xuất bản theo mô hình báo chí.

Các dữ liệu thời gian cần được quản lý chính xác. Ngày cập nhật chỉ nên thay đổi khi nội dung có chỉnh sửa đáng kể. Không nên tự động đổi dateModified mỗi ngày để tạo cảm giác bài mới.

Website cũng không nên dùng NewsArticle cho nội dung evergreen chỉ vì kỳ vọng được nhận diện như tin tức.

Person

Person mô tả một cá nhân như tác giả, chuyên gia, bác sĩ, luật sư, giảng viên hoặc người đại diện.

Một Person schema có thể khai báo:

• Họ tên

• Chức danh

• Ảnh đại diện

• Nơi làm việc

• Chuyên môn

• Hồ sơ chính thức

• Bằng cấp hoặc chứng chỉ

• Trang hồ sơ trên website

Person có giá trị nhất khi thông tin đó cũng được thể hiện rõ trên trang hồ sơ và có thể được người dùng kiểm chứng.

Không nên khai báo bằng cấp, kinh nghiệm hoặc chuyên môn chỉ trong schema mà không xuất hiện trên website.

ProfilePage

ProfilePage dùng cho trang tập trung mô tả một cá nhân hoặc tổ chức cụ thể.

Ví dụ:

• Trang tác giả

• Hồ sơ bác sĩ

• Hồ sơ luật sư

• Trang chuyên gia

• Trang thành viên cộng đồng

ProfilePage và Person thường đi cùng nhau. ProfilePage là trang hồ sơ, còn Person là thực thể được trang đó mô tả.

Cách triển khai này giúp Article liên kết đến đúng tác giả thay vì chỉ khai báo tên dưới dạng văn bản đơn lẻ.

Nhóm schema cho thương mại điện tử

Website bán hàng nên ưu tiên Product, Offer, ProductGroup, Review, AggregateRating và các schema liên quan đến vận chuyển, đổi trả.

Product

Product mô tả một sản phẩm cụ thể.

Các thuộc tính thường gồm:

• Tên sản phẩm

• Mô tả

• Hình ảnh

• Thương hiệu

• SKU

• GTIN hoặc MPN

• Giá

• Tiền tệ

• Tình trạng hàng

• Đánh giá

• URL sản phẩm

• Tình trạng sản phẩm mới hoặc đã qua sử dụng

Product nên được triển khai trên trang chi tiết sản phẩm, nơi một sản phẩm là nội dung chính.

Không nên dùng Product cho:

• Trang danh mục

• Trang kết quả tìm kiếm nội bộ

• Trang thương hiệu

• Bài viết nhắc đến nhiều sản phẩm

• Trang dịch vụ

• Landing page tổng hợp không có sản phẩm cụ thể

Offer

Offer mô tả điều kiện giao dịch của sản phẩm, chẳng hạn:

• Giá

• Loại tiền tệ

• Tình trạng còn hàng

• URL mua hàng

• Tình trạng sản phẩm

• Thời hạn áp dụng giá

• Người bán

• Chính sách giao hàng

• Chính sách đổi trả

Product và Offer cần lấy dữ liệu từ cùng nguồn đang hiển thị trên giao diện.

Ví dụ, nếu giá trên trang được lấy từ hệ thống ERP nhưng giá trong schema được nhập thủ công tại CMS, hai giá trị sẽ lệch nhau ngay khi chương trình khuyến mãi bắt đầu.

Các trường như price, availability và priceValidUntil nên được cập nhật tự động theo dữ liệu thương mại thực tế.

ProductGroup

ProductGroup dùng để mô tả một nhóm sản phẩm có nhiều biến thể.

Các biến thể có thể khác nhau theo:

• Màu sắc

• Kích thước

• Dung lượng

• Chất liệu

• Kiểu dáng

ProductGroup giúp thể hiện rằng nhiều Product con thuộc cùng một dòng sản phẩm, thay vì coi mỗi biến thể là một sản phẩm hoàn toàn tách biệt.

Nếu mỗi biến thể có URL riêng, website cần bảo đảm:

• SKU riêng

• Giá riêng

• Tồn kho riêng

• Hình ảnh tương ứng

• URL chính xác

• Quan hệ với nhóm sản phẩm

• Canonical phù hợp

Không nên dùng ProductGroup khi sản phẩm không có biến thể thực tế.

Review

Review mô tả một đánh giá cụ thể.

Một đánh giá đầy đủ thường có:

• Đối tượng được đánh giá

• Người đánh giá

• Nội dung

• Điểm số

• Thang điểm

• Ngày đánh giá

Review không phải là schema có thể gắn vào mọi trang để tạo sao.

Đánh giá phải có thật, xuất hiện trên trang và mô tả đúng đối tượng. Không nên dùng đánh giá về toàn doanh nghiệp cho từng sản phẩm riêng lẻ.

AggregateRating

AggregateRating mô tả điểm tổng hợp từ nhiều đánh giá.

Các thông tin thường gồm:

• Điểm trung bình

• Số lượng đánh giá

• Thang điểm cao nhất

• Thang điểm thấp nhất

Nếu trang hiển thị 4,6 điểm từ 120 đánh giá, schema không được khai báo 5 điểm từ 500 đánh giá.

Website cũng không nên tự tạo điểm mặc định cho sản phẩm chưa có đánh giá hoặc tự đánh giá chính doanh nghiệp của mình.

MerchantReturnPolicy và dữ liệu vận chuyển

Website thương mại điện tử có thể mở rộng structured data bằng thông tin đổi trả và vận chuyển.

MerchantReturnPolicy có thể mô tả:

• Thời hạn đổi trả

• Điều kiện đổi trả

• Phương thức trả hàng

• Chi phí trả hàng

• Hình thức hoàn tiền

• URL chính sách

Dữ liệu vận chuyển có thể thể hiện:

• Khu vực giao hàng

• Phí vận chuyển

• Thời gian xử lý

• Thời gian giao dự kiến

Những dữ liệu này chỉ hữu ích khi được đồng bộ với chính sách thực tế. Một chính sách đã thay đổi nhưng schema chưa cập nhật có thể tạo thông tin sai lệch ngay trên kết quả tìm kiếm.

Nhóm schema cho doanh nghiệp địa phương và dịch vụ

Doanh nghiệp có địa điểm phục vụ khách hàng nên cân nhắc LocalBusiness và các loại con cụ thể.

LocalBusiness

LocalBusiness mô tả một doanh nghiệp có địa điểm vật lý hoặc khu vực phục vụ rõ ràng.

Ví dụ:

• Nhà hàng

• Cửa hàng

• Phòng khám

• Salon

• Khách sạn

• Trung tâm đào tạo

• Văn phòng dịch vụ

• Xưởng sửa chữa

Các dữ liệu thường gồm:

• Tên địa điểm

• Địa chỉ

• Số điện thoại

• Giờ mở cửa

• Tọa độ

• URL

• Khoảng giá

• Khu vực phục vụ

• Hình ảnh

Website nên chọn loại con cụ thể hơn khi có thể, chẳng hạn Restaurant, Dentist, Store hoặc MedicalClinic.

Website có nhiều chi nhánh

Mỗi chi nhánh nên có một URL riêng và một LocalBusiness riêng.

Mỗi thực thể cần có:

• Địa chỉ riêng

• Số điện thoại riêng

• Giờ mở cửa riêng

• Tọa độ riêng

• URL riêng

• Định danh riêng

Không nên gộp tất cả chi nhánh vào một LocalBusiness nếu điều đó khiến thông tin địa điểm không còn chính xác.

Một mô hình tốt là Organization đại diện cho thương hiệu, còn mỗi LocalBusiness đại diện cho một địa điểm cụ thể.

LocalBusiness không thay thế hồ sơ doanh nghiệp

Schema trên website và hồ sơ doanh nghiệp trên nền tảng tìm kiếm là hai nguồn dữ liệu khác nhau.

LocalBusiness giúp mô tả thông tin trên trang. Nó không thay thế quá trình tạo, xác minh và quản lý hồ sơ địa điểm.

Hai nguồn dữ liệu nên đồng nhất về tên, địa chỉ, số điện thoại và giờ hoạt động.

Nhóm schema cho sự kiện, tuyển dụng và khóa học

Các website có nội dung gắn với thời gian, địa điểm hoặc cơ hội tham gia cần dùng loại schema đúng với bản chất của từng trang.

Event

Event phù hợp với một sự kiện cụ thể có thời gian và hình thức tổ chức rõ ràng.

Ví dụ:

• Hội thảo

• Webinar

• Workshop

• Buổi biểu diễn

• Triển lãm

• Khóa học theo lịch

• Hội chợ

Các thuộc tính quan trọng gồm:

• Tên sự kiện

• Ngày bắt đầu

• Ngày kết thúc

• Địa điểm

• Hình thức trực tiếp hoặc trực tuyến

• Trạng thái

• Giá vé

• Nhà tổ chức

• Người biểu diễn

• Hình ảnh

Mỗi sự kiện nên có một URL riêng. Trang danh sách nhiều sự kiện không nên được mô tả như một Event duy nhất.

Xử lý sự kiện thay đổi trạng thái

Khi sự kiện bị hoãn, hủy hoặc chuyển sang trực tuyến, website nên cập nhật trạng thái thay vì chỉ xóa markup.

Các trường hợp cần phản ánh gồm:

• Sự kiện bị hủy

• Sự kiện bị hoãn

• Sự kiện đã đổi lịch

• Sự kiện chuyển sang trực tuyến

Ngày giờ cũng cần có múi giờ rõ ràng. Việc khai báo thiếu múi giờ có thể làm công cụ tìm kiếm hiểu sai thời điểm diễn ra.

JobPosting

JobPosting dùng cho một vị trí tuyển dụng cụ thể.

Trang cần có:

• Chức danh

• Mô tả công việc

• Trách nhiệm

• Yêu cầu

• Đơn vị tuyển dụng

• Địa điểm

• Hình thức làm việc

• Ngày đăng

• Hạn ứng tuyển

• Cách ứng tuyển

Không nên dùng JobPosting cho trang danh sách công việc, trang thu thập CV chung hoặc vị trí đã đóng.

Tin hết hạn cần được gỡ, cập nhật hoặc xử lý theo quy trình rõ ràng. Nếu website tiếp tục để schema hoạt động cho một vị trí không còn tuyển, dữ liệu có thể trở nên lỗi thời.

Course

Course có thể dùng cho một khóa học cụ thể, trong khi trang danh sách nhiều khóa học có thể cần cách tổ chức khác.

Trang khóa học nên mô tả rõ:

• Tên khóa học

• Đơn vị cung cấp

• Nội dung

• Đối tượng

• Thời lượng

• Hình thức học

• Lịch học

• Học phí khi có

Không nên dùng Course cho một bài viết hướng dẫn ngắn hoặc tài liệu tải xuống không phải chương trình đào tạo.

Nhóm schema cho video, công thức và nội dung cộng đồng

Những loại schema này phù hợp với website có nội dung chuyên biệt và cần được triển khai theo đúng mô hình xuất bản.

VideoObject

VideoObject mô tả một video là nội dung chính hoặc thành phần quan trọng của trang.

Các thuộc tính thường gồm:

• Tên video

• Mô tả

• Ảnh thu nhỏ

• Ngày tải lên

• Thời lượng

• URL nội dung

• URL nhúng

• Đơn vị xuất bản

Video phải thực sự tồn tại, có thể phát và xuất hiện trên trang.

Không nên dùng VideoObject cho:

• Video nền trang trí

• Video bị chặn

• Video không thể phát

• Hình ảnh tĩnh

• Liên kết dẫn sang một nền tảng khác nhưng không có video trên trang

Schema không thể khắc phục một trang video có thumbnail lỗi, URL không ổn định hoặc nội dung không thể thu thập.

Recipe

Recipe dành cho trang công thức nấu ăn có hướng dẫn hoàn chỉnh.

Thông tin thường gồm:

• Tên món

• Hình ảnh

• Nguyên liệu

• Các bước thực hiện

• Thời gian chuẩn bị

• Thời gian nấu

• Tổng thời gian

• Khẩu phần

• Thông tin dinh dưỡng

• Video hướng dẫn

Recipe không phù hợp với trang thực đơn nhà hàng, bài giới thiệu món ăn hoặc trang bán thực phẩm không có công thức.

Dữ liệu như calories, thời gian nấu và khẩu phần chỉ nên khai báo khi thực sự có trên trang.

FAQPage

FAQPage mô tả một trang hoặc khu vực chứa các câu hỏi và câu trả lời do website cung cấp.

FAQPage phù hợp khi:

• Câu hỏi xuất hiện trên trang

• Câu trả lời hiển thị đầy đủ

• Website kiểm soát nội dung

• Câu hỏi liên quan trực tiếp đến chủ đề

Không nên tự động tạo FAQ schema từ mọi heading hoặc thêm câu trả lời chỉ trong mã nguồn.

FAQPage cũng không đồng nghĩa website sẽ xuất hiện trong khu vực People Also Ask. Đây là những cơ chế tìm kiếm khác nhau.

QAPage

QAPage dành cho trang có một câu hỏi và nhiều câu trả lời do cộng đồng đóng góp.

Ví dụ:

• Diễn đàn hỏi đáp

• Trang hỗ trợ cộng đồng

• Nền tảng chuyên gia trả lời

Không nên dùng QAPage cho trang FAQ do doanh nghiệp tự biên soạn.

DiscussionForumPosting

DiscussionForumPosting phù hợp với bài đăng thảo luận hoặc chủ đề diễn đàn.

Loại này giúp phân biệt nội dung cộng đồng với nội dung biên tập chính thức của website.

Việc chọn đúng giữa FAQPage, QAPage và DiscussionForumPosting giúp công cụ tìm kiếm hiểu ai tạo nội dung và mô hình tương tác của trang.

Cách chọn schema theo từng loại trang

Thay vì chọn schema theo ngành một cách chung chung, doanh nghiệp nên chọn theo chức năng của từng URL.

Trang chủ

Schema thường phù hợp:

• Organization

• WebSite

• WebPage

Nếu doanh nghiệp có địa điểm duy nhất và trang chủ tập trung vào địa điểm đó, có thể cân nhắc thêm LocalBusiness. Tuy nhiên, không nên để Organization và LocalBusiness đại diện cho hai doanh nghiệp khác nhau nếu thực tế chỉ có một chủ thể.

Trang giới thiệu

Trang giới thiệu thường dùng:

• AboutPage

• Organization

• BreadcrumbList

Organization nên được tham chiếu lại thay vì tạo một thực thể mới.

Trang liên hệ

Trang liên hệ có thể dùng:

• ContactPage

• Organization

• BreadcrumbList

Nếu trang tập trung vào một chi nhánh, LocalBusiness có thể là thực thể quan trọng hơn.

Trang danh mục

Trang danh mục thường không nên dùng schema của một sản phẩm hoặc một bài viết đơn lẻ.

Các loại có thể phù hợp:

• CollectionPage

• ItemList

• BreadcrumbList

ItemList chỉ nên mô tả các mục thực sự xuất hiện trên trang.

Trang bài viết

Bộ schema thường gồm:

• Article hoặc BlogPosting

• WebPage

• BreadcrumbList

• Person

• Organization

• WebSite

Article là nội dung chính, còn các thực thể khác đóng vai trò bổ trợ.

Trang sản phẩm

Bộ schema thường gồm:

• Product

• Offer

• Brand

• BreadcrumbList

• WebPage

Có thể bổ sung Review, AggregateRating, ProductGroup hoặc chính sách thương mại khi dữ liệu thực tế đáp ứng.

Trang chi nhánh

Bộ schema thường gồm:

• LocalBusiness

• WebPage

• BreadcrumbList

• Organization

LocalBusiness là địa điểm cụ thể, Organization là thương hiệu hoặc công ty sở hữu.

Trang hồ sơ tác giả

Bộ schema thường gồm:

• ProfilePage

• Person

• BreadcrumbList

• Organization

Các bài viết có thể tham chiếu đến cùng Person bằng một định danh ổn định.

Framework triển khai schema thực tế

Triển khai schema hiệu quả không nên bắt đầu bằng việc cài plugin. Quy trình nên bắt đầu từ dữ liệu và cấu trúc nội dung.

Lập bản đồ template

Liệt kê toàn bộ mẫu trang trên website:

• Trang chủ

• Trang danh mục

• Trang bài viết

• Trang sản phẩm

• Trang tác giả

• Trang địa điểm

• Trang sự kiện

• Trang tuyển dụng

• Trang công thức

• Trang video

Mỗi template cần được gán một main entity rõ ràng.

Xác định nguồn dữ liệu

Mỗi thuộc tính phải có nguồn cụ thể.

Ví dụ:

• Giá lấy từ hệ thống bán hàng

• Tồn kho lấy từ kho

• Tác giả lấy từ CMS

• Hồ sơ chuyên môn lấy từ trang tác giả

• Giờ mở cửa lấy từ dữ liệu chi nhánh

• Điểm đánh giá lấy từ hệ thống review

• Ngày sự kiện lấy từ hệ thống đăng ký

Không nên nhập thủ công những trường thay đổi thường xuyên.

Chuẩn hóa định danh thực thể

Mỗi thực thể quan trọng nên có một @id ổn định.

Ví dụ:

• Organization có một định danh dùng toàn website

• WebSite có một định danh riêng

• Mỗi Article có định danh theo URL

• Mỗi Person có định danh theo trang hồ sơ

• Mỗi Product có định danh theo trang sản phẩm

• Mỗi LocalBusiness có định danh theo chi nhánh

Định danh không nên thay đổi sau mỗi lần tải trang.

Liên kết các thực thể thành graph

Thay vì tạo nhiều khối độc lập, nên liên kết chúng.

Ví dụ:

• Article có author là Person

• Article có publisher là Organization

• Article là main entity của WebPage

• WebPage thuộc WebSite

• WebSite được Organization xuất bản

• Product có Brand và Offer

• LocalBusiness thuộc Organization

Cấu trúc graph giúp công cụ tìm kiếm hiểu quan hệ giữa các thành phần thay vì chỉ nhìn thấy danh sách đối tượng rời rạc.

Kiểm tra trên nhóm URL nhỏ

Không nên triển khai đồng loạt trên toàn website ngay từ đầu.

Có thể thử nghiệm trên:

• Một nhóm bài viết

• Một danh mục sản phẩm

• Một số chi nhánh

• Một loại sự kiện

Sau đó kiểm tra lỗi, dữ liệu thiếu và tình trạng trùng schema trước khi mở rộng.

Những lỗi schema phổ biến cần xử lý

Phần lớn lỗi không đến từ cú pháp JSON-LD mà đến từ dữ liệu sai hoặc mô hình thực thể không hợp lý.

Nội dung schema không hiển thị trên trang

Ví dụ:

• Giá chỉ tồn tại trong schema

• FAQ không xuất hiện cho người dùng

• Đánh giá không có trên giao diện

• Bằng cấp tác giả chỉ được khai báo trong mã

• Mức lương không có trong tin tuyển dụng

Structured data nên phản ánh nội dung người dùng có thể truy cập và kiểm chứng.

Nhiều plugin tạo schema trùng nhau

Website có thể đồng thời sinh schema từ:

• Theme

• Plugin SEO

• Plugin thương mại điện tử

• Plugin đánh giá

• Tag Manager

• Mã tùy chỉnh

Kết quả có thể là hai Product với giá khác nhau, hai Article với ngày khác nhau hoặc nhiều Organization có logo không thống nhất.

Cần kiểm tra mã nguồn thực tế thay vì chỉ xem cấu hình của từng plugin.

Dữ liệu động bị lỗi thời

Các trường dễ lỗi thời gồm:

• Giá

• Tồn kho

• Ngày sự kiện

• Hạn tuyển dụng

• Giờ mở cửa

• Chính sách đổi trả

• Phí giao hàng

• Điểm đánh giá

Nếu nguồn schema không dùng cùng nguồn dữ liệu với giao diện, sai lệch gần như chắc chắn sẽ xảy ra.

Dùng sai loại schema

Một số lỗi thường gặp:

• Dùng Product cho trang danh mục

• Dùng Article cho trang dịch vụ

• Dùng FAQPage cho diễn đàn

• Dùng QAPage cho FAQ do doanh nghiệp tự viết

• Dùng Event cho trang tổng hợp nhiều sự kiện

• Dùng JobPosting cho trang danh sách việc làm

• Dùng Recipe cho bài giới thiệu món ăn

Loại schema phải phản ánh bản chất trang, không chỉ dựa trên một từ khóa xuất hiện trong nội dung.

Tạo dữ liệu chỉ để loại bỏ cảnh báo

Không phải cảnh báo nào cũng cần xử lý bằng cách thêm dữ liệu.

Nếu website không có mức lương, không nên tạo mức lương giả. Nếu không có đánh giá, không nên tạo AggregateRating mặc định. Nếu không có thời gian kết thúc, không nên tự suy đoán.

Dữ liệu chính xác quan trọng hơn việc làm cho công cụ kiểm tra hiển thị toàn bộ màu xanh.

Checklist audit schema

Audit schema nên được thực hiện theo template, không chỉ kiểm tra một vài URL ngẫu nhiên.

Kiểm tra nội dung

• Main entity có đúng với mục đích URL không?

• Dữ liệu schema có xuất hiện trên trang không?

• Tên, giá, ngày, tác giả và địa chỉ có khớp không?

• Có thuộc tính nào được suy đoán hoặc tạo giả không?

• Nội dung đã hết hạn có còn markup không?

Kiểm tra kỹ thuật

• JSON-LD có hợp lệ không?

• Có nhiều plugin tạo cùng một schema không?

• @id có ổn định không?

• Các thực thể có được liên kết không?

• Canonical có trỏ đúng URL không?

• Trang có thể được thu thập và lập chỉ mục không?

• Schema có xuất hiện sau khi render JavaScript không?

Kiểm tra vận hành

• Ai chịu trách nhiệm cập nhật dữ liệu?

• Giá và tồn kho lấy từ nguồn nào?

• Tin tuyển dụng hết hạn được xử lý ra sao?

• Sự kiện đổi lịch có tự cập nhật không?

• Chi nhánh thay đổi giờ mở cửa có đồng bộ không?

• Khi đổi plugin, schema cũ có bị giữ lại không?

Kiểm tra hiệu quả

• Số URL hợp lệ có tăng không?

• Có lỗi theo từng template không?

• Search Console có ghi nhận loại structured data tương ứng không?

• CTR có thay đổi ở nhóm URL triển khai không?

• Dữ liệu có tạo thêm giá trị tìm kiếm hoặc kinh doanh không?

Không nên đánh giá hiệu quả chỉ dựa trên việc công cụ kiểm tra báo “valid”.

Thứ tự ưu tiên triển khai schema

Website có nguồn lực hạn chế nên triển khai theo mức độ ảnh hưởng.

Ưu tiên dữ liệu nguồn

Trước khi viết schema, cần bảo đảm dữ liệu gốc đúng:

• Giá

• Tồn kho

• Tác giả

• Ngày tháng

• Địa chỉ

• Giờ mở cửa

• Trạng thái sự kiện

• Hạn tuyển dụng

Schema không thể sửa một hệ thống dữ liệu sai.

Ưu tiên schema nền tảng

Bắt đầu với:

• Organization

• WebSite

• WebPage

• BreadcrumbList

Nhóm này tạo nền cho việc liên kết thực thể trên toàn website.

Ưu tiên template tạo giá trị kinh doanh

Tùy mô hình website:

• Thương mại điện tử ưu tiên Product và Offer

• Chuỗi địa điểm ưu tiên LocalBusiness

• Website nội dung ưu tiên Article và Person

• Nền tảng tuyển dụng ưu tiên JobPosting

• Website sự kiện ưu tiên Event

• Website công thức ưu tiên Recipe

Ưu tiên dữ liệu mở rộng

Sau khi dữ liệu chính ổn định, có thể triển khai:

• ProductGroup

• MerchantReturnPolicy

• VideoObject

• ProfilePage

• QAPage

• DiscussionForumPosting

• ItemList

Không nên triển khai lớp mở rộng khi lớp dữ liệu cơ bản vẫn đang sai hoặc trùng lặp.

Kết luận

Website nên lựa chọn schema dựa trên loại nội dung và main entity của từng URL. Organization, WebSite, WebPage và BreadcrumbList thường tạo lớp nền, trong khi Article, Product, LocalBusiness, Event, JobPosting, Recipe hoặc VideoObject mô tả nội dung chuyên biệt.

Một hệ thống schema hiệu quả không được đánh giá bằng số lượng markup. Giá trị thực sự nằm ở khả năng phản ánh đúng nội dung, liên kết các thực thể nhất quán và cập nhật dữ liệu theo hoạt động thực tế của website.

Doanh nghiệp nên bắt đầu từ việc phân loại template, xác định nguồn dữ liệu, chuẩn hóa @id, kiểm tra trùng lặp do plugin và triển khai trên nhóm URL nhỏ. Khi dữ liệu nền đã chính xác, structured data mới có thể hỗ trợ công cụ tìm kiếm hiểu website tốt hơn và tạo cơ hội xuất hiện trong các hình thức kết quả phù hợp.