Giải thích JSON-LD cho website cá nhân

 (hawksley.dev)
2 điểm bởi GN⁺ 8 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Ngay cả website cá nhân cũng có thể thêm dữ liệu có cấu trúc để crawler hiểu rõ hơn mối quan hệ giữa trang, con người và bài viết, từ đó cải thiện chất lượng hiển thị trên tìm kiếm và phần xem trước liên kết
  • Cách triển khai là đặt <script type="application/ld+json"> trong <head>, chỉ định @context là Schema.org và bố trí các node như WebSite, Person, BlogPosting trong @graph
  • Nếu dùng cùng một @id, web crawler có thể hợp nhất thuộc tính của các node trên nhiều trang, nhưng scraper hoặc LLM chỉ đọc một trang thì không hợp nhất, đây là điểm khác biệt cần lưu ý
  • Ở trang gốc, nên dùng mặc định WebSite, ProfilePage, Person; còn với trang blog, dự án hoặc trang danh sách thì thêm Blog, BlogPosting, SoftwareApplication, CollectionPage, BreadcrumbList tùy theo tính chất
  • Các trường như sameAs của Person, breadcrumb của trang, cùng image, license, ngày tháng của bài viết được dùng trực tiếp cho nhận diện cá nhân, đường dẫn trong kết quả tìm kiếm, xem trước bài viết, điều kiện sử dụng và đánh giá độ mới

Vai trò và cấu trúc cơ bản của JSON-LD

  • JSON-LD là viết tắt của JSON Linked Data, một định dạng để thêm dữ liệu có cấu trúc vào trang web
  • Nó giúp crawler hiểu cấu trúc ngữ nghĩa của website và có thể góp phần tạo phần xem trước liên kết phong phú hơn cũng như cải thiện tiềm năng xếp hạng tìm kiếm
  • Khi thêm vào trang, hãy chèn script theo dạng sau trong phần <head>
    • <script type="application/ld+json"> khai báo MIME type là application/ld+json
    • Khi chỉ định kiểu này, JavaScript engine của trình duyệt sẽ không thực thi nó
    • Các crawler chuyên biệt như Googlebot sẽ tìm phần tử đó và phân tích nội dung

@context, @graph, ID của node

  • @context chỉ định ngữ cảnh mà dữ liệu JSON-LD tuân theo, và web crawler dùng Schema.org làm tiêu chuẩn
  • Schema.org định nghĩa các cặp khóa-giá trị hợp lệ có thể dùng trong JSON
  • Tài liệu JSON-LD có thể được xem như một đồ thị có hướng gắn nhãn, và dữ liệu được lưu dưới @graph
  • Đồ thị có thể chứa nhiều node, các node được nối với nhau bằng các liên kết có hướng
  • Mỗi node gồm các thành phần sau
    • @type: cho biết node là gì. Ví dụ: WebSite, SoftwareApplication
    • @id: định danh của node, thường là URL kèm một giá trị hash duy nhất ở cuối
    • thuộc tính: các cặp khóa-giá trị thể hiện đặc điểm của node
  • Web crawler có thể hợp nhất thuộc tính của các node dùng cùng @id trên nhiều trang
  • Tuy nhiên, scraper hoặc LLM chỉ đọc một trang sẽ không hợp nhất thuộc tính, nên cần lưu ý khác biệt này khi tái sử dụng JSON-LD trên nhiều trang
  • Nên dùng @id theo cách gắn một hash phía sau URL để định danh duy nhất cho node, như #website

Các node mô tả site và trang

  • WebSite

    • WebSite chứa metadata của site và cung cấp gợi ý để crawler quyết định cách hiển thị site
    • Ở trang gốc, có thể dùng phiên bản đầy đủ với các thuộc tính như url, name, alternateName, description, inLanguage, publisher, image
    • Không cần đưa toàn bộ node WebSite vào mọi trang
    • Trang gốc của domain nên được viết chi tiết, còn các trang khác chỉ cần bản rút gọn gồm @type, @id, url, name là đủ
    • Bản rút gọn cung cấp ngữ cảnh cần thiết để crawler chỉ đọc một trang vẫn hiểu đúng tên site

  • WebPage

    • WebPage biểu thị chính trang hiện tại, tức trang HTML vật lý
    • Cần phân biệt nó với loại nội dung như BlogPosting; WebPage là trang đang chứa nội dung đó
    • Các thuộc tính ví dụ gồm url, isPartOf, name, inLanguage, breadcrumb
    • ProfilePage, CollectionPage là các subtype cụ thể hơn của WebPage
    • Có thể xem thêm các subtype ít phổ biến hơn trong định nghĩa WebPage của Schema.org

Nhận diện cá nhân và trang hồ sơ

  • Person

    • Khuyến nghị đưa node Person vào mọi trang của website cá nhân
    • Person cho biết chủ site là ai và được dùng như một phần trong các chỉ số đánh giá chất lượng nội dung của Google
    • Crawler của LLM cũng ngày càng dùng thông tin Person để quyết định sẽ trích dẫn ai trong câu trả lời
    • Khác với WebSite, Person là ngữ cảnh đủ quan trọng để có mặt trên mọi trang
    • Các thuộc tính quan trọng gồm
      • url: trỏ tới trang gốc để cố định node
      • name, givenName, familyName: thể hiện rõ tên
      • image: nếu có thể, dùng ảnh cá nhân hoặc logo liên quan để liên kết với hình ảnh chính thức
      • sameAs: cho crawler biết các hồ sơ khác, giúp nhận diện đúng người
    • sameAs đặc biệt hữu ích để phân biệt người trùng tên khi tên khá phổ biến, đồng thời dùng để tạo biểu diễn knowledge graph trên nhiều trang
    • Các thuộc tính Person khác hữu ích để bổ sung chi tiết nhưng không bắt buộc, và lược bớt cũng không ảnh hưởng nhiều

  • ProfilePage

    • ProfilePage biểu thị một trang trong site nói về một người cụ thể
    • Nếu trang chủ dùng để giới thiệu bản thân thì có thể dùng ở đó; nếu có trang about riêng thì đặt ở đó sẽ phù hợp hơn
    • Điều quan trọng là dùng isPartOf để liên kết với node WebSite rộng hơn
    • mainEntity cho crawler biết trang đó đang nói về ai
    • dateCreated, dateModified hữu ích như tín hiệu về độ mới cho crawler, nhưng nếu site không dễ cung cấp thì cũng không cần quá lo

Dự án và đường dẫn phân cấp

  • SoftwareApplication

    • Nếu trang giới thiệu phần mềm, nên dùng node SoftwareApplication để chứa metadata của phần mềm đó
    • Các type cụ thể hơn có thể dùng gồm MobileApplication, WebApplication, VideoGame
    • Thuộc tính url nên trỏ đến nơi dự án được phát hành
    • Ví dụ như trang phát hành trên crates.io
    • sameAs dùng cho các trang khác liên quan tới dự án như kho mã nguồn
    • Các giá trị hợp lệ cho applicationCategory có thể xem trong định nghĩa SoftwareApplication của Google
    • Ngay cả dự án FOSS cũng nên có offers và đặt giá là 0

  • BreadcrumbList

    • BreadcrumbList hữu ích rộng rãi cho mọi trang trừ trang gốc
    • Nó biểu thị đường dẫn phân loại của trang và không nhất thiết phải trùng với đường dẫn URL thực tế
    • Có thể dùng nó để kiểm soát cách công cụ tìm kiếm hiển thị đường dẫn của một trang cụ thể
    • Nếu đường dẫn site vốn đã ngắn thì lợi ích của node này không nhiều và có thể bỏ qua
    • Với site có đường dẫn dài, BreadcrumbList hữu ích để rút ngắn đường dẫn trong kết quả tìm kiếm

Trang danh sách, blog và bài viết

  • CollectionPage

    • CollectionPage là subtype của WebPage, chủ yếu dùng cho các trang chứa danh sách
    • Ví dụ như trang /elsewhere/ tập hợp các hồ sơ khác, hoặc trang /blog/ liệt kê bài viết blog
    • Có thể liên kết node Person liên quan bằng about
    • breadcrumb bắt buộc phải liên kết đúng tới BreadcrumbList của trang hiện tại

  • Blog

    • Thêm node Blog vào trang index hoặc trang chủ của blog
    • Nó đóng vai trò node trung gian giữa WebSite và từng BlogPosting
    • dateModified hữu ích như tín hiệu về độ mới, nhưng có thể bỏ qua nếu không dễ cung cấp
    • license giúp crawler biết bài viết có thể được dùng theo điều kiện nào
    • Với website cá nhân, có thể đặt publisher là Person thay vì Organization
    • Tài liệu của Google hiện cũng cho phép hợp lệ với Person, khác với trước đây, và điều này có thể chính xác hơn cho website cá nhân

  • BlogPosting

    • BlogPosting nên có trong mọi bài blog đã xuất bản
    • Nó cung cấp thêm thông tin để crawler biểu diễn bài viết chính xác hơn
    • Có thể được dùng để xác định vị trí chính xác hơn trong kết quả tìm kiếm và hiển thị chi tiết phong phú hơn
    • Với site cá nhân, author và publisher có thể cùng trỏ đến một node Person
    • Thuộc tính image nên khớp với ảnh OG đã dùng cho phần xem trước liên kết của bài viết
    • license có thể dùng để thể hiện điều kiện sử dụng bài viết

Mức triển khai tối thiểu và tiêu chí áp dụng

  • JSON-LD cần cho site cá nhân có thể được cấu hình có chọn lọc tùy theo tính chất từng trang
  • Ngay cả với static site không có bước build, vẫn có thể nhận được lợi ích bằng cách thêm tối thiểu các node sau vào trang gốc
    • WebSite
    • ProfilePage
    • Person
  • Nếu có blog, hãy thêm Blog và BlogPosting; còn với trang danh sách bài viết hoặc danh sách hồ sơ bên ngoài thì có thể dùng CollectionPage
  • Với trang giới thiệu dự án, có thể dùng SoftwareApplication, và với các trang không phải trang gốc thì nên cân nhắc BreadcrumbList

Bài viết liên quan

1 bình luận

 
GN⁺ 8 giờ trước
Ý kiến trên Hacker News

  • Nếu mượn một phép so sánh thì cảm giác như đang đánh lại cuộc chiến của quá khứ
    Từ góc nhìn của trang WWW của tôi, Google giờ hiển thị một bản tóm tắt do LLM tạo ra dài dòng lẫn lỗi ở phía trên, thay vì đưa người dùng tới bài viết thực tế của tôi
    Việc có được tên hiển thị đẹp hay ‘breadcrumb’ thay vì tên miền không giải quyết được thực tế là Google đã hạ thấp mức ưu tiên chuyện có trau chuốt các yếu tố đó hay không
    Thành ra lại tốn quá nhiều công sức cho thứ mà người truy cập trực tiếp vào site thật sẽ không bao giờ thấy, còn người dùng Google thì khó tìm ra vì bị đẩy xuống dưới phiên bản đã bị LLM hóa của chính Google

    • Nếu muốn một thế giới nơi loại dữ liệu này có ý nghĩa, trước tiên phải gieo hạt
      Dù Google không dùng, nếu toàn bộ Internet áp dụng loại metadata này thì đó sẽ là nền đất tốt để các đối thủ không dựa vào việc scrape bằng LLM có thể đưa ra giải pháp thay thế
      Khuất phục trước Google chỉ làm củng cố thêm thế thống trị của họ, nâng rào cản gia nhập với đối thủ, và ép họ cũng phải dùng cùng công nghệ đó
    • Chuẩn thật. Công ty chúng tôi giờ cũng hiện ra trên Google Search như thế này:
      $STATE là một công ty CNTT chuyên xây dựng các quy trình AI thực dụng và giải pháp quản lý thông tin cho các doanh nghiệp vùng Trung Tây. Công ty vận hành theo mô hình hợp đồng giá cố định linh hoạt, tập trung mang lại kết quả cụ thể mà không rơi vào kiểu phình to như doanh nghiệp lớn
      Tôi đâu có biết là giờ chúng tôi cung cấp quy trình AI thực dụng
      Rồi nó còn trộn cả tên của một đối thủ có tên na ná nhưng rõ ràng là khác, và đưa tôi lên thành giám đốc điều hành. Điều may mắn duy nhất là đối thủ kia giấu thông tin liên hệ sau biểu mẫu “đặt lịch tư vấn”, nên chỉ hiện mỗi thông tin liên hệ của chúng tôi
    • Giờ thì tôi cũng không cho phép Google crawl và index site của mình nữa
    • Giờ Google cũng bị đưa vào nhóm “hễ bot vào site là nhận ngay 10GB zipbomb”
      Hiện tại họ chẳng tạo thêm giá trị gì mà chỉ gây thêm vấn đề
    • Đúng vậy. Trong nhiều năm tôi đã nhồi nhét đủ loại thẻ và thuộc tính microdata vào website với hy vọng nó mang traffic về
      Kết cục chỉ là huấn luyện AI của Google để người ta không phải rời khỏi Google

  • Nếu theo hướng thực dụng thì tôi khuyên nên đọc tài liệu của Google về JSON-LD cho website
    https://developers.google.com/search/docs/appearance/structu...
    Bạn cũng sẽ thấy là khá nhiều thông tin trong đó chỉ liên quan tới một số site nhất định. Rotten Tomatoes có thể xuất bản điểm đánh giá của nhà phê bình phim bằng JSON-LD, nhưng kể cả tôi có viết review phim thì chuyện đó cũng không liên quan mấy tới tôi
    JSON-LD khá dễ dùng và các công cụ tìm kiếm thực sự có sử dụng, nên nhìn chung là ổn. Nó có thể làm trùng lặp thông tin bên trong trang web, nhưng giấc mơ chú thích hoàn hảo để thông tin chỉ xuất hiện đúng một lần trong tài liệu thì theo tôi gần giống một kiểu lý tưởng hóa như con bò hình cầu và sợi dây không có khối lượng
    Làm ra một trang web cần công sức của con người, và việc thành phẩm cuối cùng có chút trùng lặp cũng không sao

    • Bạn vẫn có thể dùng JSON-LD cho review phim dù không phải site lớn
      Trên site của tôi, tôi dùng nó cho review sách, game và phim, và có vẻ như hầu hết công cụ tìm kiếm đều hiển thị những thông tin như số sao
    • 403. That’s an error.
      Nó báo là client không có quyền truy cập URL /search/docs/appearance/structured-data/intro-structured-data trên máy chủ này
    • Nhưng nếu trùng lặp dữ liệu thì sẽ làm tăng mức tiêu thụ nước mất. /s

  • Với các bản xem trước liên kết phong phú, OpenGraph được hỗ trợ thường xuyên hơn nhiều so với JSON-LD
    Nếu mục đích là tối ưu hóa cho công cụ tìm kiếm, thì các loại JSON-LD mà công cụ tìm kiếm hỗ trợ rất cụ thể và hạn chế. Tốt hơn nhiều là cứ xem tài liệu của công cụ tìm kiếm mục tiêu, tức Google[1] hay Bing[2], rồi làm đúng theo đó; ngoài ra thì gần như chỉ là phí thời gian
    Ngoài phạm vi công cụ tìm kiếm, nếu không có mục đích cụ thể thì JSON-LD nhìn chung không có mấy tác dụng. Nếu có một nhu cầu cụ thể cần JSON-LD thì hãy đưa vào dữ liệu hữu ích cho nhu cầu đó, còn thêm dữ liệu khác ngoài ra thì gần như là hét vào khoảng không
    IndieWeb[3] có dùng dữ liệu có cấu trúc, nhưng xem JSON-LD là vi phạm DRY nên thay vào đó dùng Microformats[4]
    0: https://ogp.me
    1: https://developers.google.com/search/docs/appearance/structu...
    2: https://www.bing.com/webmasters/help/marking-up-your-site-wi...
    3: https://indieweb.org/
    4: https://microformats.org/

  • Thứ thực sự muốn triển khai trên mọi website là dữ liệu có cấu trúc dùng từ vựng Schema.org
    JSON-LD là một trong những cách làm đó, ngoài ra còn có RDFa và Microdata
    Khi mới học, tôi đã tham khảo bài này và thấy rất đáng giới thiệu: https://neilpatel.com/blog/get-started-using-schema/
    Có thể xem nên thêm loại dữ liệu nào bằng công cụ này: https://technicalseo.com/tools/schema-markup-generator/
    Danh sách đầy đủ có thể xem trên trang schema.org: https://schema.org/docs/schemas.html

  • Vài năm trước, tôi mới biết rằng các tính năng email hào nhoáng như chèn vé máy bay hoặc hiển thị thông tin theo dõi giao hàng đều được triển khai bằng JSON-LD trong email
    Nhưng theo tôi biết thì chỉ Gmail hỗ trợ
    Thông tin thêm: https://www.emailonacid.com/blog/article/email-development/s...

    • Outlook và iCloud cũng hỗ trợ một số tính năng như vé hoặc đặt chỗ

  • Tôi vẫn băn khoăn liệu những thuộc tính này có thực sự giúp hiển thị trên tìm kiếm hay chỉ khiến công cụ tìm kiếm dễ giữ người dùng lại trên trang kết quả hơn

    • Sau khi thêm JSON-LD, Google bắt đầu hiển thị liên kết phụ dẫn vào bên trong website của tôi. Điều đó thì ổn
    • Nếu là website doanh nghiệp, JSON-LD có thể được dùng để cung cấp dữ liệu cho các nền tảng bản đồ
      Chẳng hạn như địa chỉ, giờ mở cửa, số điện thoại, thực đơn

  • Đã có sẵn HTML ngữ nghĩa, vậy mà kỳ lạ là lại phải diễn đạt thêm ý nghĩa của website bằng một thứ JSON tùy biến kỳ quặc nằm trong thẻ script, thứ mà trình duyệt còn không xử lý

    • Tôi đã thử dùng JSON-LD trên website của mình, và thấy nó đáp ứng một nhu cầu khác với HTML ngữ nghĩa
      HTML ngữ nghĩa quy định những gì trình duyệt xử lý, như tiêu đề và heading. Dữ liệu JSON-LD là metadata như ngày tạo, ngày sửa, thẻ, tác giả
      Những thứ này cũng có thể biểu diễn trong HTML bằng microdata, nhưng JSON-LD dễ hơn nên tôi đã ngừng dùng microdata
      JSON-LD được điền từ chính dữ liệu dùng để tạo ra website, và tôi cũng dùng metadata đó để tạo các trang chỉ mục như danh sách bài blog năm 2024 hoặc toàn bộ bài viết về chủ đề X. Bên tiêu thụ chính của JSON-LD là công cụ tìm kiếm
      Nếu muốn bực hơn nữa, hãy nghĩ đến việc tôi còn nhét cả metadata OpenGraph vào cùng một trang. Tức là có hai định dạng metadata khác nhau trên cùng một trang
    • Cũng có Microdata, và nếu tôi không nhầm thì nó hỗ trợ cùng bộ từ vựng như JSON-LD. schema.org là tài liệu rất tốt
      Chỉ là JSON-LD đã trở thành mặc định từ khá lâu, hơi giống việc chúng ta phần lớn bỏ REST để đi theo RPC. Tôi cũng không rõ hiện giờ các parser quan trọng còn hỗ trợ đầy đủ microdata hay không, nhưng khi làm website cho khách hàng, nhất là các site thương mại điện tử muốn có hiển thị trên Google, tôi mặc định dùng LD
      So với HTML ngữ nghĩa cũng có một điểm đáng chú ý. HTML ngữ nghĩa giúp định nghĩa cấu trúc markup, nhưng không diễn đạt được ngữ cảnh ngoài đời thực như “đây là một sản phẩm đang bán” hay “đây là lịch tàu”
    • Có lẽ tôi chưa hiểu bài viết đủ kỹ
      Ngay trong HTML, không cần JSON-LD hay thẻ script, vẫn có thể dùng các ontology như Schema.org/FOAF/WikiData
    • Trong một thế giới lý tưởng, máy chủ và trình duyệt có thể đàm phán nội dung, để trình duyệt trước tiên chỉ yêu cầu JSON-LD từ website rồi dùng định dạng renderer nội bộ riêng của nó
    • HTML ngữ nghĩa không bao trùm phạm vi mà JSON-LD và các microformat khác xử lý
      Chỉ nhìn vào những gì bài viết đề cập thôi cũng đủ để hỏi xem đâu là phần tử ngữ nghĩa để biểu diễn con người, danh sách breadcrumb, ứng dụng phần mềm, blog, hay bài đăng blog
      HTML ngữ nghĩa chủ yếu nhằm giúp người dùng trình đọc màn hình điều hướng qua các phần tử tổng quát như “điều hướng” hoặc “bài viết”

  • Đây chẳng phải chỉ là OpenGraph viết bằng JSON sao? Ưu điểm là gì?

  • Từ sau năm 2024, lưu lượng vào các trang marketing dựa trên nội dung của chúng tôi đã giảm khoảng 85%
    Điều tôi không hiểu là nếu trang kết quả tìm kiếm không cần nhấp chuột ngày càng nhiều, chẳng lẽ Google cũng không bị ảnh hưởng mạnh?
    Doanh thu quảng cáo trên trang kết quả tìm kiếm vốn dựa trên lượt nhấp lẽ ra cũng phải sụt giảm nghiêm trọng tương tự, nhưng tôi không tìm được số liệu công khai nào để bác bỏ hay xác nhận giả thuyết đó

  • Có một thế cân bằng mong manh mà qua một ngưỡng nào đó, cộng sinh sẽ biến thành bóc lột
    Mối quan hệ trong đó website tìm kiếm độ hiển thị nhờ công cụ tìm kiếm vốn phần lớn là cùng có lợi
    Nhưng bây giờ mọi thứ đang hoàn toàn chuyển sang hướng mà chủ website không thu lại được gì từ công sức họ bỏ ra