Entity SEO là gì? Nha thử giúp Google hiểu Mãnh Tử Nha là ai

Có một câu hỏi Nha từng nghĩ khá đơn giản:

Google có biết Mãnh Tử Nha là ai không?

Website có tên Nha.

Bài viết có tên tác giả.

Facebook cũng có.

LinkedIn cũng có.

Vậy chắc Google biết chứ?

Nhưng nghĩ thêm một chút thì câu chuyện bắt đầu phức tạp.

Nha có tên thật là Nguyễn Văn Nha.

Trên blog thường dùng Mãnh Tử Nha.

Một số nội dung cũ giới thiệu Nha là Developer - Blogger - Marketer.

Những nội dung mới lại nói nhiều hơn về công nghệ, SEO, AI, dữ liệu, thương mại điện tử và chuyển đổi số.

Blog tồn tại gần 10 năm.

Thông tin cũng thay đổi theo con người.

Vậy làm sao Google biết:

• Mãnh Tử Nha và Nguyễn Văn Nha là cùng một người?
• manhtunha.com là blog của người đó?
• những bài nào do người đó viết?
• những profile bên ngoài nào thực sự thuộc về người đó?
• và người đó thường viết về những chủ đề nào?

Đây là lúc câu chuyện về Entity SEO trở nên thú vị.

Entity là gì?

Entity có thể hiểu đơn giản là một thực thể có thể được nhận diện như một đối tượng riêng.

Đó có thể là:

• một người;
• một tổ chức;
• một địa điểm;
• một sản phẩm;
• một sự kiện;
• một thương hiệu;
• hoặc một khái niệm.

Ví dụ:

Nguyễn Văn Nha là một người.

Mãnh Tử Nha là tên Nha thường sử dụng khi viết blog.

manhtunha.com là một website.

SEO là một chủ đề.

Google là một tổ chức.

Điểm quan trọng không chỉ là những cái tên này xuất hiện.

Mà là:

Máy có hiểu chúng đang nói về đối tượng nào và chúng có quan hệ gì với nhau hay không?

Entity SEO là gì?

Entity SEO là cách gọi phổ biến trong cộng đồng SEO cho việc giúp công cụ tìm kiếm hiểu rõ hơn các thực thể, thuộc tính và mối quan hệ giữa chúng.

Cần nói cho chính xác:

Google không công bố một ranking factor riêng có tên “Entity SEO”.

Không có:

Entity SEO Score: 92/100

trong Google Search Console.

Cũng không có một nút:

Submit Entity

để Nha khai:

Xin chào Google, đây là tôi.

Nhưng Google có các hệ thống giúp hiểu người, địa điểm, tổ chức, sự vật và các mối quan hệ giữa chúng.

Một trong những khái niệm quen thuộc nhất là Knowledge Graph.

Knowledge Graph là gì?

Google mô tả Knowledge Graph là cơ sở dữ liệu chứa hàng tỷ thông tin về con người, địa điểm và sự vật.

Nó giúp Google trả lời những câu hỏi kiểu:

• ai là người này;
• địa điểm này nằm ở đâu;
• công ty này thuộc lĩnh vực nào;
• người này có quan hệ gì với tổ chức kia;
• hay sự kiện này diễn ra khi nào.

Điểm Nha thấy đáng chú ý là:

Google không chỉ nhìn một chuỗi ký tự.

Nó cố gắng hiểu đối tượng phía sau chuỗi ký tự đó.

Entity khác Keyword như thế nào?

Lấy ví dụ:

Apple.

Nếu chỉ nhìn keyword thì đó là năm ký tự.

Nhưng Apple có thể là:

• quả táo;
• Apple Inc.;
• một thương hiệu công nghệ;
• một công ty;
• một thực thể có website, sản phẩm, lãnh đạo và lịch sử riêng.

Máy tìm kiếm phải hiểu:

Apple nào?

Với Nha cũng tương tự.

Keyword có thể là:

Mãnh Tử Nha.

Nhưng entity cần hiểu thêm:

• đây là nickname của ai;
• website chính là gì;
• các bài viết nào thuộc về tác giả đó;
• profile nào trên web đại diện cho cùng người;
• và thông tin nào hiện tại là chính xác.

Nói theo cách Nha dễ nhớ:

Keyword là cái tên.

Entity là thứ đứng phía sau cái tên đó.

Knowledge Panel có phải Entity SEO không?

Không.

Knowledge Panel là một trong những cách Google có thể hiển thị thông tin về một entity mà hệ thống đã nhận diện.

Google nói Knowledge Panel được tạo tự động khi hệ thống có đủ thông tin từ web và các nguồn khác.

Vì vậy:

Không có Knowledge Panel không có nghĩa Google không hiểu gì về entity.

Và ngược lại:

Có Knowledge Panel cũng không đồng nghĩa Entity SEO đã hoàn thành.

Nếu một entity đã có Knowledge Panel, chủ thể hoặc đại diện chính thức có thể xác minh và đề xuất chỉnh sửa.

Nhưng Nha không thể tự tạo Knowledge Panel chỉ bằng một đoạn Schema.

Có cần Wikipedia để Google hiểu Entity không?

Không.

Đây là một hiểu lầm khá phổ biến.

Wikipedia có thể là một trong nhiều nguồn Google tham khảo.

Nhưng:

Không có Wikipedia ≠ Không có Entity

Và càng không nên tự tạo một trang Wikipedia chỉ vì muốn “SEO Entity”.

Wikipedia có quy định riêng về độ nổi bật và nguồn độc lập.

Entity có thể tồn tại và được Google hiểu mà không cần có một bài Wikipedia.

Có cần Wikidata không?

Cũng không bắt buộc.

Nếu một người hoặc tổ chức đủ phù hợp với tiêu chí của Wikidata thì đây có thể là một nguồn nhận diện hữu ích.

Nhưng Nha không xem:

Wikidata = Entity SEO

hay:

Không Wikidata = Google không hiểu mình

Cả hai đều đơn giản hóa vấn đề quá mức.

Vậy Nha thử áp dụng Entity SEO cho manhtunha.com như thế nào?

Nha bắt đầu bằng một câu hỏi đơn giản:

Entity chính phía sau blog này là ai?

Câu trả lời:

Mãnh Tử Nha, tên thật Nguyễn Văn Nha.

Sau đó Nha audit những nơi đang mô tả entity này.

Và đây là lúc Nha thấy vài thứ khá thú vị.

Bước 1: Chọn một trang chính cho tác giả

Trên blog hiện tại, Nha dùng trang:

Mãnh Tử Nha - Nguyễn Văn Nha | Giới thiệu tác giả

làm trang giới thiệu chính.

Trang này nên là nơi trả lời rõ:

• Mãnh Tử Nha là ai;
• tên thật là gì;
• background ra sao;
• đang làm gì;
• thường viết về lĩnh vực nào;
• các profile chính thức ở đâu;
• và những nội dung tiêu biểu nào đã viết.

Nha xem đây như:

“Nhà chính” của entity tác giả trên manhtunha.com.

Bước 2: Kết nối Mãnh Tử Nha và Nguyễn Văn Nha

Con người đọc:

Mãnh Tử Nha, tên thật Nguyễn Văn Nha...

là hiểu ngay.

Structured Data cũng có thể mô tả điều đó:

{

"@type": "Person",

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

"name": "Mãnh Tử Nha",

"alternateName": "Nguyễn Văn Nha",

"url": "https://manhtunha.com/manh-tu-nha.php" }

Ở đây Nha không dùng Schema để cố tăng ranking.

Nha chỉ đang nói rõ:

Hai cách gọi này thuộc về cùng một người.

Bước 3: Một Entity nên có một @id nhất quán

Trong bài Schema là gì? Cách Nha dùng Structured Data đúng cách, Nha đã nói khá kỹ về @id.

Ví dụ Nha chọn:

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

làm định danh cho entity Mãnh Tử Nha trong dữ liệu có cấu trúc của website.

Sau đó:

• ProfilePage;
• BlogPosting;
• các nội dung cần tham chiếu tác giả;

đều dùng lại cùng định danh đó.

Điều Nha muốn tránh là:

Bài thứ nhất:

#author

Bài thứ hai:

#manhtunha

Bài thứ ba:

#nguyenvannha

trong khi cả ba đều đang nói về cùng một người.

Bước 4: BlogPosting phải nói rõ ai là Author

manhtunha.com hiện đã có BlogPosting Schema cho từng bài.

Vậy Nha không cần tạo thêm “Entity Schema”.

Thứ cần kiểm tra là:

Tất cả BlogPosting có đang nhận diện cùng một tác giả hay không?

Google hiện khuyến nghị khi khai báo tác giả nên cung cấp:

• author;
• author.name;
• author.url;
• hoặc sameAs nếu phù hợp.

Với blog Nha, cấu trúc hợp lý có thể là:

"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" }

Google nói author.url có thể trỏ tới trang About Me hoặc trang profile giúp xác định duy nhất tác giả.

Đây là một trong những chỗ Entity và E-E-A-T gặp nhau.

Trước khi đánh giá:

Người này có đáng tin không?

ít nhất hệ thống cần hiểu:

“Người này” là ai.

Bước 5: Trang tác giả dùng ProfilePage

Google hiện xác nhận một:

About Me page trên blog

là use case hợp lệ của ProfilePage.

Vì vậy trang tác giả của Nha có thể có cấu trúc:

{

"@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",

"alternateName": "Nguyễn Văn Nha"

} }

Như vậy ta có:

ProfilePage

│

└── mainEntity

│

└── Person

↑

│

BlogPosting author

Nha thích cấu trúc này vì nó dễ hiểu.

Cả với dev.

Lẫn với máy.

Bước 6: sameAs không phải danh sách backlink

sameAs rất hay bị biến thành một chỗ để nhét link profile.

Nha không muốn làm vậy.

Nếu sử dụng sameAs, Nha chỉ đưa những URL thực sự giúp nhận diện cùng một entity.

Ví dụ:

• LinkedIn chính thức;
• Facebook chính thức;
• YouTube chính thức;
• GitHub nếu đó thực sự là profile của Nha và có giá trị nhận diện;
• những profile mà Nha thực sự sử dụng.

Không phải:

• 50 profile tạo tự động;
• website bookmarking;
• directory không sử dụng;
• forum profile chỉ được tạo để lấy backlink.

Quan trọng hơn:

Một bài báo nói về Nha không nhất thiết là sameAs.

Bài báo là một nguồn đề cập tới entity.

Nó không phải chính entity đó.

Bước 7: Homepage phải nhất quán về Site Name

Entity không chỉ là tác giả.

Website cũng cần có identity rõ.

Google hiện cho biết việc xác định Site Name là hoàn toàn tự động và có thể sử dụng:

• WebSite Structured Data;
• og:site_name;
• title;
• heading;
• nội dung homepage;
• và các tham chiếu trên web.

Trong đó, nếu chủ website muốn chỉ định tên ưu tiên, Google khuyến nghị dùng WebSite Structured Data trên homepage.

Ví dụ:

{

"@context": "https://schema.org",

"@type": "WebSite",

"name": "Mãnh Tử Nha",

"url": "https://manhtunha.com/" }

Nhưng điều quan trọng không chỉ nằm trong JSON-LD.

Homepage cũng phải sử dụng tên đó một cách nhất quán.

Bước 8: Audit cho thấy blog vẫn còn thông tin cũ

Đây là phần Nha thích nhất vì nó là vấn đề thật.

Khi kiểm tra lại manhtunha.com vào tháng 11/2026, phần giới thiệu hiện vẫn còn dòng:

Developer - Blogger - Marketer

Trong khi phần mô tả mới trên blog đã rộng hơn khá nhiều:

• công nghệ;
• AI;
• dữ liệu;
• SEO;
• marketing;
• thương mại điện tử;
• chuyển đổi số.

Nha không xem dòng cũ này là “lỗi Entity SEO nghiêm trọng”.

Nhưng nó là một ví dụ rõ về:

thông tin không còn nhất quán.

Người đọc nhìn vào có thể hiểu:

Chắc phần này viết từ lâu.

Máy lại phải tự đánh giá tín hiệu nào mới hơn và đại diện tốt hơn.

Nếu sửa được thì tại sao bắt nó đoán?

Bước 9: Trang About cũ vẫn tồn tại thì xử lý thế nào?

Blog Nha còn URL tự sự cũ:

/about-me/tu-su.php

Trang này vẫn có giá trị.

Nó là một phần lịch sử.

Nha không muốn xóa chỉ vì đã có trang tác giả mới.

Nhưng hai trang cần có vai trò khác nhau.

Ví dụ:

/manh-tu-nha.php

là:

Trang tác giả chính, thông tin hiện tại, entity hub.

Còn:

/about-me/tu-su.php

có thể là:

Một bài tự sự về hành trình của Nha ở một giai đoạn trước đây.

Như vậy cả người đọc lẫn máy đều dễ phân biệt hơn.

Nha không cần xóa lịch sử.

Chỉ cần nói rõ lịch sử đang đứng ở đâu.

Bước 10: Entity không chỉ là tên người

Nếu Entity SEO chỉ là:

Tạo Person Schema.

thì bài này đã xong từ lâu.

Điều thú vị hơn là mối quan hệ.

Ví dụ:

Mãnh Tử Nha

│

├── tác giả của → manhtunha.com

│

├── viết về → SEO

│

├── viết về → AI

│

├── viết về → Data

│

├── viết về → Programming

│

└── chia sẻ → trải nghiệm cá nhân

Mối quan hệ này không được tạo ra chỉ bằng Schema.

Nó còn đến từ:

• lịch sử bài viết;
• category;
• tag;
• Internal Link;
• About Page;
• profile;
• và các nguồn bên ngoài.

Internal Link đóng vai trò gì?

Nha đã viết riêng bài Internal Link là gì? Cách Nha biến những bài viết cũ thành một thư viện kiến thức.

Ở góc Entity, Internal Link giúp thể hiện quan hệ.

Ví dụ:

E-E-A-T

│

├── author → Mãnh Tử Nha

│

├── liên quan → Schema

│

├── liên quan → Entity SEO

│

└── liên quan → SEO / AEO / GEO

Một bài không chỉ nên có tag SEO rồi đứng đó một mình.

Nó cần có đường nối tới kiến thức liên quan.

Anchor Text cũng giúp tạo ngữ cảnh

Ví dụ:

<a href="/manh-tu-nha.php">Mãnh Tử Nha</a>

cho biết rõ trang đích liên quan tới ai hơn:

<a href="/manh-tu-nha.php">xem thêm</a>

Nha không nói exact-match anchor có “sức mạnh Entity” đặc biệt.

Chỉ đơn giản:

Link có ngữ cảnh rõ thì con người và máy đều đỡ phải đoán.

Entity SEO và E-E-A-T có giống nhau không?

Không.

Trong bài E-E-A-T là gì? Nha thử áp dụng E-E-A-T cho chính blog gần 10 năm của mình, Nha tập trung vào:

• Experience;
• Expertise;
• Authoritativeness;
• Trustworthiness.

Entity lại hỏi:

Ai đang nói?

Hai thứ liên quan.

Nếu hệ thống hiểu rõ tác giả là ai thì việc kết nối lịch sử nội dung, profile và các tín hiệu khác trở nên dễ hơn.

Nhưng:

Nhận diện được một người không làm người đó tự nhiên trở thành chuyên gia.

Person Schema không thể biến Nha thành bác sĩ.

Entity clarity hỗ trợ nhận diện.

Expertise vẫn phải đến từ kiến thức thật.

Entity SEO và Topical Authority có giống nhau không?

Cũng không.

Entity SEO quan tâm nhiều tới:

Ai hoặc cái gì?

Topical Authority lại là cách cộng đồng SEO nói về chiều sâu và mức độ đáng tin của một nguồn trong một lĩnh vực.

Ví dụ:

Google hiểu:

Mãnh Tử Nha = Nguyễn Văn Nha = tác giả trên manhtunha.com.

Đó là entity identity.

Còn việc Nha có hàng loạt bài SEO được viết, cập nhật, liên kết và duy trì nhiều năm lại là một câu chuyện khác.

Đó sẽ là bài Nha viết tiếp sau bài này.

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

Có thể hỗ trợ khả năng hiểu thông tin.

Nhưng Nha không dùng công thức:

Entity SEO → GEO → AI trích dẫn

Không có tài liệu Google nào bảo đảm điều đó.

Trong môi trường Search có AI, việc hiểu:

• ai đang nói;
• nói về cái gì;
• các đối tượng liên quan với nhau thế nào;
• nguồn chính thức ở đâu;

rõ ràng là hữu ích.

Nhưng nội dung vẫn phải:

• được crawl;
• được index;
• liên quan;
• chính xác;
• hữu ích;
• và đáng tin.

Entity chỉ là một lớp.

Không phải phép màu.

Làm sao “báo Google” Entity là ai?

Không có nút Submit Entity.

Nha sẽ làm theo cách giảm mơ hồ.

1. Có một Author Page chính

Ví dụ:

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

2. Author Page dùng ProfilePage + Person

Nếu website hiện đã có thì chỉ cần kiểm tra đúng và nhất quán.

3. Mỗi BlogPosting trỏ về cùng Author

Dùng cùng:

author.url

và nếu có:

@id

4. Homepage dùng WebSite đúng Site Name

Ví dụ:

Mãnh Tử Nha

5. Metadata nhìn thấy và Structured Data không mâu thuẫn

Schema nói một người.

Trang cũng phải nói cùng người đó.

6. sameAs chỉ giữ profile thật

Không spam profile.

7. Internal Link về Author Page

Byline, author box và các vị trí hợp lý nên link tới trang tác giả.

8. Cập nhật thông tin cũ

Chức danh, mô tả, profile không còn đúng thì sửa.

9. Để Google crawl lại

Sau những thay đổi lớn, có thể sử dụng:

Google Search Console → URL Inspection → Request Indexing

cho homepage và trang tác giả.

Đây không phải submit Entity.

Chỉ là giúp Google phát hiện phiên bản mới sớm hơn.

Có cần tạo hàng chục profile để xây Entity?

Nha không làm.

Có một thời gian SEO Entity thường được trình bày như:

Tạo thật nhiều profile social rồi đồng bộ tên, mô tả và backlink.

Nha thấy cách này quá đơn giản hóa vấn đề.

Nếu có 50 profile mà 48 profile:

• không hoạt động;
• không ai đọc;
• chỉ chứa một backlink;
• và được tạo tự động;

thì Nha không xem đó là nền tảng Entity mạnh.

Nha thích:

• ít profile hơn;
• nhưng thật;
• được sử dụng;
• thông tin nhất quán;
• và có lý do tồn tại.

Có cần Schema thật nhiều để Google hiểu Entity không?

Không.

manhtunha.com đã có BlogPosting.

Trang tác giả có thể dùng ProfilePage + Person.

Homepage có WebSite.

Vậy là một nền khá tốt.

Không cần phát minh:

EntitySchema SemanticSEOSchema EEATSchema GEOSchema

những thứ mà Google không hề yêu cầu.

Nha đã nói kỹ hơn về chuyện này trong bài Schema là gì?.

Có một điều quan trọng hơn Schema: consistency

Giả sử Structured Data khai:

Mãnh Tử Nha là tác giả.

Nhưng:

• homepage gọi tên khác;
• About Page ghi nghề nghiệp khác;
• Facebook dùng một profile khác;
• LinkedIn lại mô tả một người hoàn toàn khác;

thì JSON-LD đẹp chưa giải quyết được hết vấn đề.

Nha thích nguyên tắc:

Đừng cố cho Google thật nhiều tín hiệu.

Hãy làm cho những tín hiệu quan trọng nói cùng một câu chuyện.

Kết quả audit Entity nhanh của manhtunha.com

Sau khi kiểm tra lại, Nha chia thành hai nhóm.

Những thứ đã khá rõ

• Mãnh Tử Nha được gắn với tên thật Nguyễn Văn Nha.
• Có trang tác giả riêng.
• Homepage giới thiệu đây là blog cá nhân.
• Các bài mới có byline Mãnh Tử Nha.
• Author box ở nhiều bài đã ghi rõ tên thật và phạm vi chủ đề.
• Blog có lịch sử nội dung dài, không phải một website vừa tạo để chạy keyword.

Những thứ nên tiếp tục sửa

• phần “Developer - Blogger - Marketer” đã cũ;
• trang tự sự cũ cần được phân biệt rõ với author hub hiện tại;
• kiểm tra toàn bộ BlogPosting có cùng author URL và @id hay chưa;
• rà lại sameAs và chỉ giữ profile chính thức;
• đảm bảo WebSite, homepage và metadata dùng Site Name nhất quán;
• cập nhật thông tin nghề nghiệp ở các vị trí cũ nếu không còn phản ánh đúng hiện tại.

Nha không gọi kết quả này là:

Entity SEO đạt 90 điểm.

Vì không có thước đo chính thức như vậy.

Nha chỉ có thể nói:

Website càng nhất quán thì càng ít thứ bắt người đọc và máy phải tự đoán.

Đó là kết quả đủ thực tế.

Một sai lầm Nha muốn tránh: xây Entity trước, làm nội dung sau

Ví dụ:

Tạo 50 social profile.

Thêm Person Schema.

Thêm sameAs.

Tạo Knowledge Graph.

Xong rồi viết những bài rất mỏng.

Nha không nghĩ thứ tự đó ổn.

Nếu bài viết:

• không có trải nghiệm;
• không có nguồn;
• không có kiến thức mới;
• và không giúp được người đọc;

thì việc Google hiểu cực kỳ chính xác tác giả là ai cũng không cứu được.

Có khi Google hiểu rất rõ:

À, đúng người này viết bài này.

Nhưng bài vẫn dở.

Vậy cũng hơi quê.

Entity Identity có thể khai báo, Authority thì phải tích lũy

Đây là điều quan trọng nhất Nha rút ra.

Chúng ta có thể giúp máy hiểu:

• tên;
• nickname;
• website;
• profile;
• tác giả;
• quan hệ giữa các trang.

Nhưng không có dòng JSON nào khai:

"authority": "very-high"

Authority phải đến từ:

• những gì đã làm;
• những bài đã viết;
• chất lượng nội dung;
• những nguồn đề cập;
• lịch sử;
• và sự nhất quán theo thời gian.

Đây cũng chính là điểm Entity bắt đầu nối sang Topical Authority.

Nhưng Nha để câu chuyện đó cho bài tiếp theo.

Checklist Entity SEO Nha sẽ dùng cho blog

Nếu audit một website cá nhân, Nha sẽ kiểm tra:

Identity

• Tên chính là gì?
• Nickname là gì?
• Hai tên có được kết nối rõ không?
• Có Author Page chính không?

Author

• Mỗi bài có byline không?
• Byline có link tới Author Page không?
• BlogPosting có author.url không?
• Các bài có cùng @id không?

Profile

• ProfilePage có mainEntity là Person không?
• Thông tin còn đúng không?
• Ảnh nhận diện có nhất quán không?
• sameAs có phải profile thật không?

Website

• WebSite Schema có đúng Site Name không?
• Homepage gọi website bằng tên gì?
• og:site_name, title và nội dung có nhất quán không?

Content

• Tác giả thực sự viết về nhóm chủ đề nào?
• Category có rõ không?
• Internal Link có thể hiện quan hệ không?
• Có nội dung cũ đang mâu thuẫn với thông tin hiện tại không?

External Identity

• LinkedIn;
• Facebook;
• YouTube;
• GitHub;
• các profile quan trọng khác;
• thông tin có nhất quá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, Nha mong bạn nhớ những điều này:

• Entity là một đối tượng có thể được nhận diện riêng như người, tổ chức, địa điểm, sản phẩm hoặc khái niệm.
• Entity SEO là cách gọi của cộng đồng SEO, không phải một ranking factor riêng mà Google công bố.
• Keyword là chuỗi chữ; Entity là đối tượng phía sau chuỗi chữ.
• Knowledge Panel không phải điều kiện để Google hiểu một Entity.
• Không bắt buộc phải có Wikipedia hoặc Wikidata.
• Author Page nên là nơi nhận diện chính của tác giả trên website.
• BlogPosting nên trỏ nhất quán về cùng một author URL hoặc @id.
• sameAs không phải danh sách backlink.
• Schema giúp mô tả Entity, nhưng không tạo Authority thay cho nội dung.
• Thông tin nhất quán quan trọng hơn việc tạo thật nhiều tín hiệu.

Ngày trước Nha nghĩ:

Muốn Google biết mình thì phải xuất hiện ở thật nhiều nơi.

Bây giờ Nha nghĩ khác một chút:

Quan trọng không phải xuất hiện bao nhiêu nơi.

Mà là mỗi lần Google gặp mình, những tín hiệu đó có đang nói về cùng một người hay không.

Entity SEO, theo cách Nha hiểu, không phải trò làm cho mình trông nổi tiếng hơn.

Nó là việc giảm bớt sự mơ hồ.

Tên rõ.

Người rõ.

Website rõ.

Quan hệ rõ.

Còn uy tín đến đâu...

phần đó phải để nội dung, trải nghiệm và thời gian trả lời.

Nguồn và tài liệu tham khảo

Nha ưu tiên tài liệu chính thức của Google và kiểm tra lại vào tháng 11/2026.

• Google - How Google's Knowledge Graph works
  Google giải thích Knowledge Graph là cơ sở dữ liệu chứa thông tin về người, địa điểm và sự vật, đồng thời cho biết dữ liệu được tổng hợp từ nhiều nguồn khác nhau.
• Google - Giới thiệu về Knowledge Panel
  Google giải thích Knowledge Panel được tạo tự động khi hệ thống hiểu một Entity dựa trên thông tin có sẵn từ nhiều nguồn trên web.
• Google Search Central - ProfilePage Structured Data
  Google xác nhận About Me page trên blog là một use case phù hợp với ProfilePage và mô tả cách sử dụng Person, alternateName và sameAs.
• Google Search Central - Article và BlogPosting Structured Data
  Google khuyến nghị sử dụng author.name và author.url hoặc sameAs để giúp hệ thống hiểu và phân biệt tác giả.