Schema là gì? Cách Nha dùng Structured Data đúng cách mà không biến website thành nồi lẩu JSON-LD

Có một thời gian Nha khá thích Schema.

Mỗi lần phát hiện thêm một loại markup mới là trong đầu lại có cảm giác:

Ồ, cái này thêm vào website chắc Google thích.

Article?

Thêm.

Breadcrumb?

Thêm.

FAQ?

Thêm luôn.

Person?

Cũng thêm.

Organization nhìn có vẻ xịn?

Thêm nốt.

Nếu Schema.org có một loại tên là WebsiteRatLaTamHuyet, chắc ngày trước Nha cũng tìm cách nhét vào.

Vấn đề là:

Có nhiều Schema hơn chưa chắc website được hiểu đúng hơn.

Thậm chí nếu khai báo sai thực tế, dùng sai loại dữ liệu hoặc cứ thấy một Schema tồn tại trên Schema.org là đưa vào website, chúng ta có thể tạo ra một mớ dữ liệu nhìn rất kỹ thuật nhưng chẳng giúp ích gì.

Sau một thời gian làm website, SEO và rồi quay lại sửa chính blog của mình, cách Nha nhìn Schema đơn giản hơn nhiều:

Schema không phải thứ để nói với Google rằng website của mình tốt.

Nó là cách nói rõ cho máy biết thứ đang nằm trên trang là gì.

Hai chuyện đó khác nhau khá nhiều.

Schema là gì?

Khi người làm SEO nói “Schema”, phần lớn chúng ta đang nói tới structured data – dữ liệu có cấu trúc sử dụng bộ từ vựng của Schema.org.

Structured Data là cách biểu diễn thông tin theo một cấu trúc chuẩn để máy có thể hiểu rõ hơn ý nghĩa của dữ liệu trên trang.

Ví dụ một người đọc bài này có thể nhìn và hiểu ngay:

• tiêu đề bài viết là gì;
• người viết là Nha;
• ngày đăng là ngày nào;
• ảnh nào đại diện cho bài;
• bài thuộc chủ đề gì.

Máy cũng có thể suy luận những thông tin này từ HTML.

Nhưng Structured Data cho phép chúng ta nói rõ hơn:

{   "@type": "BlogPosting",   "headline": "Schema là gì?",   "author": {     "@type": "Person",     "name": "Mãnh Tử Nha"   } }

Nói nôm na:

HTML nói:

Đây là một đoạn chữ tên “Mãnh Tử Nha”.

Schema có thể nói thêm:

“Mãnh Tử Nha” ở đây là một Person và là author của BlogPosting này.

Đó mới là giá trị cốt lõi.

Schema.org, Structured Data và Rich Result không phải một thứ

Đây là phần Nha nghĩ rất nhiều người mới dễ nhầm.

Ba khái niệm thường bị trộn với nhau:

• Schema.org;
• Structured Data;
• Google Rich Results.

Chúng liên quan, nhưng không giống nhau.

Schema.org là bộ từ vựng

Schema.org định nghĩa rất nhiều loại thực thể và thuộc tính.

Ví dụ:

• Person;
• Organization;
• Article;
• BlogPosting;
• Product;
• Event;
• Recipe;
• BreadcrumbList;
• ProfilePage.

Có thể hiểu Schema.org giống như một cuốn từ điển chung để các hệ thống thống nhất cách mô tả dữ liệu.

Structured Data là dữ liệu mình triển khai

Mình lấy những từ trong bộ từ vựng đó để mô tả trang cụ thể.

Ví dụ:

{   "@context": "https://schema.org",   "@type": "Person",   "name": "Mãnh Tử Nha" }

Đó là Structured Data.

Rich Result là cách Google có thể hiển thị dữ liệu

Một số loại Structured Data được Google hỗ trợ để tạo những kiểu hiển thị đặc biệt trên kết quả tìm kiếm.

Nhưng đây là điểm quan trọng:

Schema.org có một type không đồng nghĩa Google sẽ tạo Rich Result cho type đó.

Và kể cả Structured Data của bạn hoàn toàn hợp lệ:

Google cũng không cam kết Rich Result sẽ xuất hiện.

Nha thấy chỉ cần hiểu rõ hai câu này đã tránh được khá nhiều “phép thuật Schema” trên Internet.

Schema có giúp tăng thứ hạng Google không?

Nếu hỏi:

Cài Schema xong website có từ top 10 lên top 3 không?

Nha sẽ không xem Schema như một nút tăng ranking như vậy.

Structured Data giúp công cụ tìm kiếm hiểu nội dung rõ hơn và một số loại markup có thể giúp trang đủ điều kiện cho những Search feature nhất định.

Nhưng:

Schema không biến nội dung yếu thành nội dung tốt.

Nó không cứu được:

• bài viết trả lời sai Search Intent;
• nội dung sao chép;
• website không crawl được;
• trang đang noindex;
• nội dung không có giá trị riêng;
• trang chậm hoặc trải nghiệm kém;
• một sản phẩm tệ;
• hay một website không đáng tin.

Nói vui một chút:

Schema giống như dán nhãn rất rõ lên một chai nước.

Nó giúp máy biết đây là nước gì.

Nhưng nếu nước bên trong dở thì cái nhãn JSON-LD đẹp đến mấy cũng không làm nước ngon hơn.

JSON-LD là gì?

Structured Data có thể được triển khai bằng nhiều định dạng.

Google hiện hỗ trợ:

• JSON-LD;
• Microdata;
• RDFa.

Nha ưu tiên JSON-LD.

Không phải vì JSON-LD có “SEO power” cao hơn.

Mà vì nó thường dễ triển khai, đọc và bảo trì hơn.

JSON-LD thường nằm trong:

<script type="application/ld+json"> {    ... } </script>

Ví dụ:

<script type="application/ld+json"> {   "@context": "https://schema.org",   "@type": "BlogPosting",   "headline": "Schema là gì?",   "author": {     "@type": "Person",     "name": "Mãnh Tử Nha"   } } </script>

Người dùng bình thường không nhìn thấy đoạn dữ liệu này trong phần nội dung.

Nhưng crawler có thể đọc nó.

Nguyên tắc quan trọng nhất: Schema phải phản ánh nội dung thật trên trang

Nếu Nha chỉ được chọn một nguyên tắc trong cả bài này thì đó là:

Structured Data phải mô tả đúng thứ thực sự tồn tại trên trang.

Ví dụ trang không có sản phẩm nhưng thêm:

"@type": "Product"

chỉ vì Product có thể có rating đẹp trên Google?

Không nên.

Trang không phải FAQ nhưng cố nhét FAQPage?

Không nên.

Mình là blogger cá nhân nhưng khai báo mình thành một công ty?

Cũng không nên.

Điểm cuối này Nha muốn nói kỹ hơn vì chính Nha cũng từng làm chưa chuẩn.

Person và Organization: đừng biến mình thành công ty chỉ vì copy một mẫu Schema

Rất nhiều mẫu Article Schema trên mạng có dạng:

"publisher": {   "@type": "Organization",   "name": "ABC" }

Điều này hoàn toàn hợp lý nếu ABC thực sự là một tổ chức xuất bản nội dung.

Ví dụ:

• một tờ báo;
• một doanh nghiệp;
• một tổ chức;
• một website được vận hành bởi công ty.

Nhưng manhtunha.com là blog cá nhân.

“Mãnh Tử Nha” là một người.

Vậy nếu muốn mô tả chính Nha, loại phù hợp phải là:

"@type": "Person"

chứ không nên cố biến thành:

"@type": "Organization"

Schema.org cũng cho phép publisher của một CreativeWork là Person hoặc Organization.

Nên với blog cá nhân, Nha có thể dùng:

"publisher": {   "@type": "Person",   "@id": "https://manhtunha.com/manh-tu-nha.php#person",   "name": "Mãnh Tử Nha" }

Điều thú vị là một lỗi nhỏ như vậy rất dễ xảy ra.

Bởi vì chúng ta thường:

1. Google “Article Schema mẫu”.
2. Copy.
3. Đổi tên website.
4. Xong.

Schema chạy qua validator vẫn có thể hợp lệ về cú pháp.

Nhưng hợp lệ về cú pháp chưa chắc đúng về ngữ nghĩa.

Đó mới là chỗ đáng quan tâm.

Blog như manhtunha.com thực sự cần những Schema nào?

Nha không muốn biến mọi URL thành một rừng Schema.

Với một blog cá nhân, Nha thấy có vài loại thực sự đáng ưu tiên.

1. WebSite cho trang chủ

Trang chủ có thể khai báo:

{   "@context": "https://schema.org",   "@type": "WebSite",   "@id": "https://manhtunha.com/#website",   "url": "https://manhtunha.com/",   "name": "Mãnh Tử Nha" }

WebSite giúp mô tả chính website.

Google cũng sử dụng WebSite structured data trên homepage như một trong các tín hiệu để hiểu site name.

Không cần mỗi bài blog lại tạo thêm một WebSite khác.

Một website vẫn là một website.

2. ProfilePage + Person cho trang tác giả

Nha hiện có trang:

/manh-tu-nha.php

Trang này nói về chính tác giả, nên khá phù hợp với:

{   "@context": "https://schema.org",   "@type": "ProfilePage",   "@id": "https://manhtunha.com/manh-tu-nha.php#profile",   "url": "https://manhtunha.com/manh-tu-nha.php",   "mainEntity": {     "@type": "Person",     "@id": "https://manhtunha.com/manh-tu-nha.php#person",     "name": "Mãnh Tử Nha"   } }

Đây là một chỗ Nha đánh giá đáng đầu tư hơn việc rải 20 type không cần thiết.

Bởi vì sau đó các bài viết có thể cùng tham chiếu về một tác giả:

"author": {   "@id": "https://manhtunha.com/manh-tu-nha.php#person" }

Thay vì mỗi bài vô tình tạo ra một “Mãnh Tử Nha” mới.

@id quan trọng ở chỗ nào?

@id là một khái niệm Nha thấy rất hữu ích khi bắt đầu nhìn Schema dưới góc độ entity.

Ví dụ Nha dùng:

https://manhtunha.com/manh-tu-nha.php#person

làm định danh cho entity Mãnh Tử Nha trên website.

Sau đó ở nhiều nơi:

• ProfilePage;
• BlogPosting;
• About page;
• các bài viết;

đều có thể tham chiếu lại cùng @id.

Nói nôm na:

Thay vì mỗi lần gặp chữ “Mãnh Tử Nha” máy phải tự hỏi đây có phải cùng một người không, mình cho nó một định danh nhất quán.

Đây là cách sử dụng Schema Nha thấy hợp lý hơn nhiều so với tư duy:

Trang này thêm được bao nhiêu type?

3. BlogPosting cho từng bài viết

Với một bài blog như bài bạn đang đọc, BlogPosting là loại rất tự nhiên.

Schema.org định nghĩa BlogPosting là một dạng cụ thể hơn của Article.

Google cũng hỗ trợ:

• Article;
• NewsArticle;
• BlogPosting.

Với manhtunha.com, Nha chọn:

"@type": "BlogPosting"

thay vì NewsArticle.

Vì đây là blog cá nhân, không phải báo điện tử.

Những thuộc tính Nha ưu tiên gồm:

• headline;
• description;
• image;
• datePublished;
• dateModified;
• author;
• mainEntityOfPage;
• inLanguage;
• articleSection;
• keywords hoặc about nếu phù hợp.

datePublished và dateModified không phải một thứ

Đây là chi tiết khá nhỏ nhưng rất dễ làm sai.

datePublished là:

Ngày bài được xuất bản lần đầu.

dateModified là:

Ngày nội dung thực sự được cập nhật.

Nha không thích kiểu:

Mỗi ngày hệ thống tự đổi dateModified thành hôm nay để Google tưởng bài mới.

Nếu nội dung không thay đổi đáng kể thì ngày sửa cũng không nên giả vờ thay đổi.

Structured Data vẫn quay lại nguyên tắc cũ:

Mô tả sự thật.

Chứ không phải tạo ra một phiên bản sự thật mà mình mong Google tin.

4. BreadcrumbList cho breadcrumb

Nếu giao diện website thực sự có cấu trúc kiểu:

Trang chủ → Online Marketing → Schema là gì?

thì có thể khai báo BreadcrumbList tương ứng.

Ví dụ:

{   "@type": "BreadcrumbList",   "itemListElement": [     {       "@type": "ListItem",       "position": 1,       "name": "Trang chủ",       "item": "https://manhtunha.com/"     },     {       "@type": "ListItem",       "position": 2,       "name": "Online Marketing",       "item": "URL_CHUYEN_MUC"     },     {       "@type": "ListItem",       "position": 3,       "name": "Schema là gì?"     }   ] }

Breadcrumb giúp mô tả vị trí của trang trong cấu trúc website.

Nhưng cũng cần cập nhật một chi tiết:

Google hiện chỉ hiển thị Breadcrumb rich result trên desktop, không còn trên mobile.

Điều đó không có nghĩa Breadcrumb vô dụng.

Nó vẫn là một cấu trúc website tốt cho người đọc.

Chỉ đừng dùng nó với kỳ vọng:

Thêm Breadcrumb Schema là mobile SERP sẽ đẹp ngay.

Có nên thêm FAQ Schema vào mọi bài không?

Đây là một ví dụ rất hay về lý do chúng ta phải cập nhật kiến thức SEO.

Có một thời gian khá nhiều checklist viết bài có mục:

Cuối bài thêm 5 FAQ + FAQPage Schema.

Rồi dần dần nó biến thành một nghi thức.

Bài về cái gì cũng FAQ.

Không ai hỏi cũng FAQ.

Câu hỏi đôi khi được tác giả tự nghĩ chỉ để… có FAQ Schema.

Nhưng Google đã ngừng FAQ rich results từ ngày 7/5/2026 và sau đó xóa tài liệu feature này vào tháng 6/2026.

Vậy từ đây có hai chuyện phải tách riêng.

FAQ trong nội dung vẫn có thể hữu ích

Nếu người đọc thực sự hay hỏi:

• Schema có tăng SEO không?
• JSON-LD đặt ở đâu?
• Blog nên dùng loại Schema nào?

thì viết phần hỏi đáp vẫn rất tốt.

Nhưng đừng thêm FAQ chỉ để săn Google Rich Result

Feature đó không còn nữa.

Nha nghĩ đây là ví dụ đẹp cho một nguyên tắc rộng hơn:

Nội dung dành cho người dùng có thể sống rất lâu.

Một Search feature của Google thì có thể biến mất.

Nếu chiến lược content phụ thuộc quá nhiều vào một rich snippet, tới lúc Google bỏ feature thì cả đội lại ngồi nhìn nhau.

Schema.org có 800 thứ, có phải dùng càng nhiều càng tốt?

Không.

Google thậm chí khuyến nghị:

Ít thuộc tính nhưng đầy đủ và chính xác tốt hơn rất nhiều thuộc tính nhưng thiếu, sai hoặc không chính xác.

Nha rất thích tinh thần này.

Ví dụ một BlogPosting đơn giản nhưng đúng:

{   "@type": "BlogPosting",   "headline": "...",   "image": "...",   "datePublished": "...",   "dateModified": "...",   "author": {     "@id": "...#person"   } }

có thể hợp lý hơn một graph khổng lồ gồm:

• Article;
• WebPage;
• CreativeWork;
• Organization;
• Person;
• Service;
• Product;
• FAQPage;
• HowTo;
• Review;

trong khi nửa số đó chẳng mô tả đúng trang.

Schema không phải Pokémon.

Không cần bắt đủ bộ.

Một trang có được dùng nhiều Schema không?

Có.

Miễn chúng mô tả những thực thể thực sự tồn tại và mối quan hệ giữa chúng.

Ví dụ bài này có thể có:

• WebPage;
• BlogPosting;
• BreadcrumbList;
• Person được tham chiếu làm author.

Không có vấn đề gì.

Thậm chí có thể dùng @graph để biểu diễn nhiều entity trong cùng JSON-LD:

{   "@context": "https://schema.org",   "@graph": [     {       "@type": "BlogPosting",       "@id": "ARTICLE_URL#article"     },     {       "@type": "BreadcrumbList",       "@id": "ARTICLE_URL#breadcrumb"     }   ] }

Nhưng câu hỏi Nha luôn đặt trước khi thêm là:

Entity này có thực sự tồn tại trên trang và giúp mô tả trang rõ hơn không?

Nếu câu trả lời là:

Không biết, nhưng plugin bảo thêm.

thì nên kiểm tra lại.

Có nên tạo Schema riêng cho từng bài?

Có một sự khác biệt giữa:

Schema template chung

và:

dữ liệu cụ thể của từng bài.

Ví dụ tất cả bài blog đều có thể dùng một template:

BlogPosting ├── headline ├── description ├── image ├── datePublished ├── dateModified ├── author ├── articleSection └── keywords

Hệ thống lấy dữ liệu động cho từng bài.

Không cần mỗi bài ngồi viết lại toàn bộ Schema bằng tay.

Nhưng từng bài có thể bổ sung những entity phù hợp qua:

"about"

Ví dụ bài này:

"about": [   {     "@type": "Thing",     "name": "Structured Data"   },   {     "@type": "Thing",     "name": "Schema.org"   },   {     "@type": "Thing",     "name": "JSON-LD"   } ]

Đó là cách Nha thích hơn kiểu:

Bài nào cũng tạo một đống Schema khác nhau cho có vẻ “GEO”.

Schema có giúp AEO và GEO không?

Đây là câu rất dễ bị thổi phồng.

Nha sẽ trả lời:

Structured Data có thể giúp máy hiểu rõ nội dung và entity hơn, nhưng Schema không phải vé đảm bảo website được AI trích dẫn.

Google trong hướng dẫn generative search năm 2026 vẫn nhấn mạnh các nền tảng SEO:

• crawl;
• index;
• nội dung hữu ích;
• internal link;
• chất lượng nội dung;
• giá trị khác biệt;
• thông tin máy có thể hiểu.

Không có công thức:

Thêm Schema → AI hiểu → AI trích dẫn → GEO hoàn thành

Nếu đơn giản vậy chắc SEOer đỡ mất ngủ hơn nhiều.

Nha nhìn Schema trong AEO/GEO theo cách thực tế hơn:

Content nói điều gì.

HTML trình bày điều đó cho người đọc.

Structured Data giúp mô tả rõ hơn các thực thể và quan hệ quan trọng cho máy.

Ba lớp bổ sung nhau.

Không lớp nào thay thế lớp còn lại.

Nha cũng đã nói về mối quan hệ này trong bài SEO, AEO và GEO khác nhau như thế nào.

Schema không cứu được Search Intent sai

Giả sử Nha viết một bài:

“Tour Nhật Bản giá bao nhiêu?”

Người dùng muốn:

• giá tour;
• ngày khởi hành;
• lịch trình;
• dịch vụ bao gồm;
• đặt tour.

Nhưng trang chỉ có một bài 4.000 từ kể về lịch sử Nhật Bản.

Sau đó Nha cài Structured Data cực đẹp.

Schema đúng 100%.

Validator xanh hết.

Search Intent vẫn sai.

Trong bài Search Intent là gì?, Nha đã nói khá kỹ:

Từ khóa là dấu vết của nhu cầu, không phải bản thân nhu cầu.

Schema cũng tương tự.

Nó mô tả nội dung.

Không tạo ra giá trị mà nội dung vốn không có.

Rich Results Test xanh có nghĩa mọi thứ đã hoàn hảo?

Không hẳn.

Rich Results Test giúp kiểm tra markup theo những feature Google hỗ trợ.

Nó rất hữu ích để tìm:

• syntax error;
• required property bị thiếu;
• kiểu dữ liệu sai;
• một số vấn đề Structured Data.

Nhưng một kết quả “Valid” chủ yếu nói:

Cấu trúc này hợp lệ đối với feature đang kiểm tra.

Nó không nói:

Nội dung này hay.

Nó cũng không nói:

Trang chắc chắn có Rich Result.

Và càng không nói:

Google sẽ xếp trang top 1.

Đây là ba thứ cần tách ra.

Google không đảm bảo Rich Result xuất hiện

Điều này Google ghi khá rõ trong hướng dẫn Structured Data.

Ngay cả khi:

• markup hợp lệ;
• đúng type;
• đúng property;
• Rich Results Test không báo lỗi;

Google vẫn không bảo đảm trang sẽ được hiển thị dưới dạng Rich Result.

Google còn xem xét nhiều yếu tố khác.

Vì vậy nếu dev báo:

Schema valid rồi anh.

thì Nha hiểu là:

Tốt. Chúng ta đã hoàn thành phần markup.

Chứ không phải:

Tốt. SEO xong.

Dữ liệu trong Schema và dữ liệu người dùng nhìn thấy phải khớp nhau

Đây là nguyên tắc cực kỳ quan trọng.

Ví dụ trên trang hiển thị:

Giá: 2.000.000 đồng

nhưng Product Schema ghi:

"price": "1500000"

thì có vấn đề.

Hoặc nội dung hiện 4 sao nhưng Schema khai 5 sao.

Hoặc bài được viết bởi Nha nhưng Schema khai tác giả khác.

Structured Data không nên chứa một “thế giới bí mật” đẹp hơn thế giới mà người dùng thực sự nhìn thấy.

Google có chính sách khá rõ về việc markup phải đại diện đúng cho nội dung trên trang.

Cẩn thận với Review và Rating Schema

Rating là một trong những thứ dễ khiến người làm website ham nhất.

Vì ngôi sao trên SERP trông đẹp.

Nên phản xạ có thể là:

Trang nào cũng gắn AggregateRating được không?

Nha không khuyến khích suy nghĩ như vậy.

Nếu website có:

• hệ thống review thực;
• người dùng đánh giá thực;
• dữ liệu hiển thị trên trang;
• đúng loại nội dung Google hỗ trợ;

thì khai báo rating là hợp lý.

Nếu tự tạo ra một con số chỉ để lấy ngôi sao thì câu chuyện đã đi từ SEO sang… trang điểm dữ liệu.

Schema không nên chứa thông tin mình không thể chứng minh

Ví dụ khai:

"sameAs": [   "URL_WIKIPEDIA",   "URL_WIKIDATA" ]

chỉ vì muốn xây entity, trong khi các trang đó không nói về mình?

Không nên.

sameAs về bản chất nói rằng:

Đây là những URL khác đại diện cho cùng một entity.

Vì vậy với Person có thể dùng các profile thực sự thuộc về người đó.

Không phải link tới bất kỳ trang nào có nhắc tên.

Cách Nha sẽ tổ chức Schema cho manhtunha.com

Nếu làm lại cấu trúc hiện tại, Nha sẽ chia thành ba tầng.

Tầng 1: Website

Trang chủ:

• WebSite;
• Person nếu phù hợp với cấu trúc graph;
• site name;
• URL;
• các thuộc tính nhận diện cần thiết.

Tầng 2: Tác giả

/manh-tu-nha.php:

• ProfilePage;
• mainEntity = Person;
• name;
• alternateName;
• description;
• image;
• sameAs hợp lệ;
• một @id cố định.

Tầng 3: Nội dung

Mỗi bài:

• BlogPosting;
• headline;
• description;
• image;
• datePublished;
• dateModified;
• articleSection;
• author tham chiếu tới Person;
• mainEntityOfPage;
• about/keywords khi có giá trị;
• BreadcrumbList nếu giao diện có breadcrumb.

Như vậy các entity được nối thành một hệ thống:

manhtunha.com       |       +-- WebSite       |       +-- ProfilePage       |       |       |       +-- Person: Mãnh Tử Nha       |       +-- BlogPosting 1       |       |       |       +-- author → Person       |       +-- BlogPosting 2       |       |       |       +-- author → Person       |       +-- BlogPosting 3               |               +-- author → Person

Nha thích kiến trúc này vì nó khá dễ hiểu.

Cả cho dev.

Lẫn cho máy.

Một mẫu BlogPosting Nha thấy đủ dùng

{   "@context": "https://schema.org",   "@type": "BlogPosting",   "@id": "ARTICLE_URL#article",   "mainEntityOfPage": {     "@type": "WebPage",     "@id": "ARTICLE_URL"   },   "headline": "ARTICLE_TITLE",   "description": "ARTICLE_DESCRIPTION",   "image": [     "ARTICLE_IMAGE"   ],   "datePublished": "DATE_PUBLISHED",   "dateModified": "DATE_MODIFIED",   "inLanguage": "vi-VN",   "articleSection": "Online marketing",   "author": {     "@type": "Person",     "@id": "https://manhtunha.com/manh-tu-nha.php#person",     "name": "Mãnh Tử Nha",     "url": "https://manhtunha.com/manh-tu-nha.php"   },   "publisher": {     "@type": "Person",     "@id": "https://manhtunha.com/manh-tu-nha.php#person",     "name": "Mãnh Tử Nha"   } }

Không hoành tráng.

Nhưng phản ánh khá đúng thực tế.

Có cần khai báo keywords trong Schema không?

Có thể.

keywords là một thuộc tính của CreativeWork trong Schema.org.

Nhưng Nha không xem nó như một phiên bản mới của:

<meta name="keywords">

và càng không nghĩ:

Thêm 30 keyword vào JSON-LD là Google sẽ rank 30 keyword đó.

Nếu sử dụng, Nha chỉ khai những chủ đề thực sự liên quan tới bài.

Ví dụ bài này:

• Schema;
• Structured Data;
• JSON-LD;
• SEO;
• Schema.org.

Vậy là đủ.

Schema và Internal Link phải đi cùng kiến trúc nội dung

Structured Data nói với máy:

Bài này là gì?

Internal Link giúp máy và người đọc hiểu:

Bài này liên quan tới những bài nào?

Tag và category nói:

Nó nằm trong nhóm kiến thức nào?

Trang tác giả nói:

Ai chịu trách nhiệm cho nội dung này?

Đó là lý do Nha không xem SEO kỹ thuật như một danh sách các mẹo độc lập.

Chúng là nhiều lớp cùng mô tả một website.

7 lỗi Schema Nha nghĩ website thường gặp

1. Copy Schema của website khác rồi chỉ thay tên

Rất dễ để lại:

• @type sai;
• URL sai;
• publisher sai;
• logo sai;
• entity sai.

2. Cứ có type trên Schema.org là nghĩ Google hỗ trợ Rich Result

Không đúng.

Schema.org và Google Search feature là hai phạm vi khác nhau.

3. Thêm càng nhiều type càng thấy yên tâm

Structured Data không phải checklist “càng xanh càng tốt”.

4. Schema nói một đằng, trang hiển thị một nẻo

Đây là lỗi đáng tránh nhất.

5. Tạo nhiều entity giống nhau nhưng không dùng @id thống nhất

Đặc biệt với:

• Person;
• Organization;
• WebSite.

6. Không cập nhật Schema khi nội dung thay đổi

Ngày sửa, ảnh, title, author hay các dữ liệu động nên được đồng bộ.

7. Xem Rich Results Test là điểm SEO

Valid là điều cần.

Nhưng valid không đồng nghĩa rank.

Checklist Schema trước khi publish

Nha sẽ dùng checklist này cho những bài mới:

• Trang này thực sự là loại nội dung gì?
• Schema type có mô tả đúng không?
• Google có hỗ trợ feature này hay chỉ Schema.org có type?
• Dữ liệu Schema có xuất hiện hoặc phản ánh đúng nội dung trên trang không?
• Author dùng Person hay Organization đúng thực tế chưa?
• Author có URL/profile rõ ràng chưa?
• @id có được dùng nhất quán không?
• datePublished có phải ngày đăng thật không?
• dateModified có phải ngày cập nhật thật không?
• Image có crawl được không?
• Canonical URL và mainEntityOfPage có đúng không?
• Có Schema thừa chỉ vì plugin tự thêm không?
• Rich Results Test có lỗi critical không?
• URL Inspection có thấy markup sau khi render không?

Nếu trả lời được hết những câu này, Nha thấy đã đủ tốt hơn rất nhiều so với câu:

Trang này có mấy Schema?

Schema tốt không phải Schema dài nhất

Sau nhiều năm đụng tới website, Nha càng ngày càng thích những hệ thống ít “ma thuật”.

Schema cũng vậy.

Một đoạn JSON-LD ngắn nhưng:

• đúng thực thể;
• đúng quan hệ;
• đúng dữ liệu;
• được cập nhật;
• nhất quán toàn website;

giá trị hơn một graph 500 dòng chỉ vì tool chấm được 100 điểm.

Cách suy nghĩ này khá giống chuyện Nha từng thay đổi quan điểm với keyword density.

Ngày trước chúng ta thích con số.

2% keyword.

2.000 từ.

50 backlink.

15 Schema.

Càng làm lâu Nha càng thấy câu hỏi đáng hỏi hơn là:

Thứ này có đang giúp người dùng hoặc công cụ tìm kiếm hiểu website chính xác hơn không?

Bạn nên mang gì về sau bài này?

Nếu vài hôm nữa quên gần hết cú pháp JSON-LD, Nha mong bạn vẫn nhớ những điều này:

• Schema là cách mô tả dữ liệu cho máy, không phải bùa tăng thứ hạng.
• Schema.org, Structured Data và Google Rich Result là ba khái niệm khác nhau.
• Có type trên Schema.org không đồng nghĩa Google tạo Rich Result cho type đó.
• Markup hợp lệ cũng không đảm bảo Google hiển thị Rich Result.
• Dùng đúng type quan trọng hơn dùng nhiều type.
• Person phải là Person, Organization phải thực sự là Organization.
• Schema phải phản ánh đúng nội dung người dùng nhìn thấy.
• Với blog cá nhân, WebSite + ProfilePage/Person + BlogPosting + BreadcrumbList thường đã tạo được một nền tảng rất tốt.
• Dùng @id nhất quán giúp kết nối các entity tốt hơn.
• FAQ vẫn có thể hữu ích cho người đọc, nhưng FAQ Rich Result của Google đã kết thúc trong năm 2026.

Và nếu phải tóm cả bài thành một câu, Nha sẽ chọn:

Đừng dùng Schema để cố nói với máy rằng website của mình tuyệt vời. Hãy dùng Schema để nói thật rõ website của mình đang có gì.

Máy hiểu đúng đã là một việc tốt.

Còn nội dung có đủ tốt để người ta đọc, Google xếp hạng hay AI muốn trích dẫn hay không...

Phần đó JSON-LD không làm thay mình được.

Tài liệu Nha tham khảo khi cập nhật bài viết

Bài viết này được Nha kiểm tra lại theo tài liệu Schema.org và Google Search Central tại thời điểm tháng 09/2026, bao gồm:

• Introduction to Structured Data Markup;
• General Structured Data Guidelines;
• Article / BlogPosting Structured Data;
• ProfilePage Structured Data;
• Breadcrumb Structured Data;
• Site Name và WebSite Structured Data;
• các cập nhật Structured Data và FAQ Rich Result của Google Search Central.

Có một lý do Nha ghi thời điểm kiểm tra ở đây.

Schema.org tiếp tục phát triển.

Google cũng có thể thêm hoặc bỏ Search feature.

Vì vậy nếu bạn đọc bài này vài năm sau, hãy kiểm tra lại tài liệu chính thức trước khi áp dụng.

Có khi lúc đó Nha cũng đang ngồi sửa lại chính bài này.

SEO mà.

Không có gì vui bằng viết một bài hướng dẫn rồi vài năm sau quay lại… bắt lỗi chính mình.