Kişisel web siteleri için JSON-LD açıklaması

 (hawksley.dev)
2 puan yazan GN⁺ 8 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Kişisel web siteleri de yapılandırılmış veri eklerse, tarayıcılar sayfa, kişi ve yazılar arasındaki ilişkiyi daha iyi anlayabilir; bağlantı önizlemelerini ve arama görünürlüğü kalitesini iyileştirebilir
  • Uygulama, <head> içindeki <script type="application/ld+json"> bölümünde @contexti Schema.org olarak belirtip @graph içine WebSite, Person, BlogPosting gibi düğümler yerleştirme şeklindedir
  • Aynı @id kullanılırsa web tarayıcıları birden fazla sayfadaki düğüm özelliklerini birleştirebilir; ancak yalnızca tek sayfa okuyan scraper'lar veya LLM'ler bunu yapmaz
  • Kök sayfada varsayılan olarak WebSite, ProfilePage, Person bulunmalı; blog, proje ve liste sayfalarında ise niteliğine göre Blog, BlogPosting, SoftwareApplication, CollectionPage, BreadcrumbList eklenmelidir
  • Person içindeki sameAs, sayfadaki breadcrumb, yazıdaki image, license ve tarih alanları; kişi kimliği, arama sonucu yolu, yazı önizlemesi, kullanım koşulları ve güncellik değerlendirmesinde doğrudan kullanılır

JSON-LD'nin rolü ve temel yapısı

  • JSON-LD, JSON Linked Data'nın kısaltmasıdır ve web sayfalarına yapılandırılmış veri ekleme biçimidir
  • Tarayıcıların sitenin anlamsal yapısını anlamasına yardımcı olur ve daha zengin bağlantı önizlemeleri ile arama sıralamasında olası iyileştirmelere katkı sağlayabilir
  • Sayfaya eklerken <head> bölümü içine aşağıdaki biçimde bir script yerleştirilir
    • <script type="application/ld+json">, MIME türünü application/ld+json olarak tanımlar
    • Bu tür belirtildiğinde tarayıcının JavaScript motoru bunu çalıştırmaz
    • Googlebot gibi özel tarayıcılar bu öğeyi bulup içeriği parse eder

@context, @graph, düğüm ID'leri

  • @context, JSON-LD verisinin bağlı olduğu bağlamı belirtir ve web tarayıcıları standart olarak Schema.org kullanır
  • Schema.org, JSON içinde kullanılabilecek geçerli anahtar-değer çiftlerini tanımlar
  • JSON-LD belgesi, etiketlenmiş yönlü bir grafik olarak görülebilir ve veriler @graph altında saklanır
  • Grafikte birden fazla düğüm bulunur ve bu düğümler yönlü bağlantılarla birbirine bağlanır
  • Her düğüm şu öğelerden oluşur
    • @type: Düğümün ne olduğunu gösterir. Örn. WebSite, SoftwareApplication
    • @id: Genellikle URL sonuna benzersiz bir hash değeri eklenmiş düğüm tanımlayıcısı
    • Özellikler: Düğümün niteliklerini gösteren anahtar-değer çiftleri
  • Web tarayıcıları, aynı @idyi paylaşan düğümlerin özelliklerini birden fazla sayfa boyunca birleştirebilir
  • Yalnızca tek bir sayfa okuyan scraper'lar veya LLM'ler özellikleri birleştirmediğinden, JSON-LD'yi birden fazla sayfada yeniden kullanırken bu fark dikkate alınmalıdır
  • @id için #website gibi, URL sonuna düğümü benzersiz tanımlayan bir hash ekleme yöntemi önerilir

Siteyi ve sayfayı açıklayan düğümler

  • WebSite

    • WebSite, sitenin metadatasını içerir ve tarayıcılara sitenin nasıl gösterileceğine dair ipuçları verir
    • Kök sayfada url, name, alternateName, description, inLanguage, publisher, image gibi özellikler içeren ayrıntılı bir sürüm bulunabilir
    • Her sayfaya tam WebSite düğümünü eklemek gerekmez
    • Alan adının kök sayfası ayrıntılı yazılabilir; diğer sayfalarda ise yalnızca @type, @id, url, name içeren kısaltılmış sürüm yeterlidir
    • Kısaltılmış sürüm, yalnızca tek sayfa okuyan tarayıcıların site adını doğru anlaması için gereken bağlamı sağlar

  • WebPage

    • WebPage, mevcut sayfanın kendisini, yani fiziksel HTML sayfasını ifade eder
    • BlogPosting gibi içerik türlerinden ayrılmalıdır; WebPage, bu içeriği barındıran sayfayı gösterir
    • Örnek özellikler arasında url, isPartOf, name, inLanguage, breadcrumb bulunur
    • ProfilePage, CollectionPage, WebPagein daha özel alt türleridir
    • Daha az yaygın alt türler Schema.org'un WebPage tanımında görülebilir

Kişi kimliği ve profil sayfaları

  • Person

    • Kişisel web sitesindeki tüm sayfalara Person düğümü eklenmesi önerilir
    • Person, site sahibinin kim olduğunu gösterir ve Google'ın içerik kalite sinyallerinin bir kısmında kullanılır
    • LLM tarayıcıları da yanıtlarda kimi alıntılayacağına karar verirken Person bilgisini giderek daha fazla kullanıyor
    • WebSitein aksine Person, tüm sayfalarda bulunacak kadar önemli bir bağlamdır
    • Önemli özellikler şunlardır
      • url: Kök sayfayı işaret ederek düğümü sabitler
      • name, givenName, familyName: İsmi açık biçimde belirtir
      • image: Mümkünse kişinin fotoğrafı veya ilgili logo kullanılarak resmi görsel bağlanır
      • sameAs: Tarayıcılara diğer profilleri bildirerek kişi tanımlamasına yardımcı olur
    • sameAs, özellikle yaygın isimlerde adaşları ayırt etmede faydalıdır ve birden fazla sayfaya yayılan bilgi grafiği temsilleri oluşturmak için kullanılır
    • Diğer Person özellikleri daha fazla ayrıntı eklemek için faydalıdır ama zorunlu değildir; azaltılmalarının etkisi küçüktür

  • ProfilePage

    • ProfilePage, site içinde belirli bir kişiyle ilgili sayfayı ifade eder
    • Ana sayfada kendinizi tanıtıyorsanız ana sayfada kullanılabilir; ayrı bir about sayfası varsa orada yer alması daha uygun olabilir
    • isPartOf ile daha geniş WebSite düğümüne bağlanması önemlidir
    • mainEntity, bu sayfanın kimin hakkında olduğunu tarayıcılara bildirir
    • dateCreated ve dateModified, tarayıcılar için güncellik sinyali olarak faydalıdır; ancak sitede bunları sağlamak kolay değilse fazla dert etmeye gerek yoktur

Projeler ve yol gösterimi

  • SoftwareApplication

    • Sayfada bir yazılım tanıtılıyorsa, ilgili yazılımın metadata'sını SoftwareApplication düğümünde tutmak iyi olur
    • Daha özel türler olarak MobileApplication, WebApplication, VideoGame kullanılabilir
    • url özelliği, projenin yayımlandığı konumu göstermelidir
    • Örneğin crates.io gibi dağıtım sayfaları buna dahildir
    • sameAs, kaynak kod deposu gibi projeyle bağlantılı diğer sayfalar için kullanılır
    • applicationCategory için geçerli değerler Google'ın SoftwareApplication tanımında görülebilir
    • FOSS projelerinde bile offers eklenmeli ve fiyat 0 olarak ayarlanmalıdır

  • BreadcrumbList

    • BreadcrumbList, kök sayfa dışındaki neredeyse tüm sayfalarda faydalıdır
    • Sayfanın kategori yolunu gösterir; bunun gerçek URL yoluyla birebir aynı olması gerekmez
    • Arama motorlarının belirli bir sayfanın yolunu nasıl göstereceğini kontrol etmek için kullanılabilir
    • Site yolu zaten kısaysa bu düğümün getirisi az olduğundan atlanabilir
    • Yolun uzun olduğu sitelerde BreadcrumbList, arama sonuçlarındaki yolu kısaltmak için faydalıdır

Liste, blog ve yazı sayfaları

  • CollectionPage

    • CollectionPage, esas olarak liste içeren sayfalarda kullanılan bir WebPage alt türüdür
    • Başka profilleri toplayan /elsewhere/ sayfası veya blog yazıları listesi olan /blog/ sayfası buna örnektir
    • about ile ilgili Person düğümü bağlanabilir
    • breadcrumb, mutlaka mevcut sayfanın doğru BreadcrumbListine bağlanmalıdır

  • Blog

    • Blog düğümü, blogun indeks veya ana sayfasına eklenir
    • WebSite ile tek tek BlogPostingler arasında ara düğüm görevi görür
    • dateModified, güncellik sinyali olarak faydalıdır; ancak kolayca sağlanamıyorsa atlanabilir
    • license, tarayıcıların yazıları hangi koşullarda kullanabileceğini anlamasını sağlar
    • Kişisel web sitelerinde publisher, Organization yerine Person olarak ayarlanabilir
    • Google dokümantasyonu artık eskisinden farklı olarak Personı da geçerli kabul ediyor ve bu kişisel siteler için daha doğru olabilir

  • BlogPosting

    • BlogPosting, yayımlanmış tüm blog yazılarında bulunmalıdır
    • Tarayıcıların yazıyı daha doğru temsil edebilmesi için ek bilgi sağlar
    • Arama sonuçlarında daha doğru konumlandırma ve daha zengin ayrıntılar sunmak için kullanılabilir
    • Kişisel sitelerde author ve publisherın aynı Person düğümünü göstermesi sorun değildir
    • image özelliğinin, yazı bağlantısı önizlemesinde zaten kullanılan OG görseli ile eşleşmesi iyi olur
    • license, yazının kullanım koşullarını belirtmek için kullanılabilir

Asgari uygulama ve kullanım ölçütleri

  • Kişisel bir site için gereken JSON-LD, sayfanın niteliğine göre seçmeli olarak yapılandırılabilir
  • Build aşaması olmayan statik sitelerde bile, en azından kök sayfaya aşağıdaki düğümler eklenerek fayda sağlanabilir
    • WebSite
    • ProfilePage
    • Person
  • Bir blog varsa Blog ve BlogPosting eklenebilir; yazı listesi veya harici profil listesi sayfalarında CollectionPage kullanılabilir
  • Proje tanıtım sayfalarında SoftwareApplication, kök dışındaki sayfalarda ise BreadcrumbList değerlendirmeye alınabilir

İlgili okumalar

1 yorum

 
GN⁺ 8 시간 전
Hacker News yorumları

  • Bir benzetme yapacak olursak, bu geçen savaşı yeniden vermek gibi hissettiriyor
    Benim WWW sitem açısından bakınca Google artık insanları doğrudan gerçek yazılarıma göndermek yerine, üstte hatalar içeren uzun bir LLM tarafından üretilmiş özet gösteriyor
    'Breadcrumb' ya da alan adı yerine şık bir görünen ad almak, Google'ın bu tür öğeleri güzelleştirsin ya da güzelleştirmesin zaten düşük öncelikli gördüğü gerçeğini çözmüyor
    Asıl siteye doğrudan gelenler bunu zaten hiç görmüyor; Google kullananlar içinse bu, Google'ın kendi LLM'leştirilmiş sürümünün altında kalıp bulunması zor olan bir şey için fazla çaba harcamak anlamına geliyor

    • Eğer bu tür verilerin anlamlı olduğu bir dünya istiyorsanız, önce tohum ekmeniz gerekir
      Google kullanmasa bile internetin tamamı bu tür metadata'yı uygularsa, bu LLM scraping'i yapmayan rakiplerin alternatif sunması için verimli bir zemin oluşturur
      Google'a boyun eğmek sadece hakimiyetini güçlendirir, rakiplerin pazara giriş engelini yükseltir ve onları da aynı teknikleri kullanmaya zorlar
    • Kesinlikle öyle. Şirketimiz artık Google aramalarında şöyle görünüyor:
      $STATE merkezli bir BT şirketi olup, Ortabatı'daki işletmeler için pratik AI workflow'ları ve bilgi yönetimi çözümleri geliştirme konusunda uzmanlaşmıştır. Çevik sabit fiyatlı sözleşme modeliyle çalışır ve kurumsal hantallıktan kaçınırken somut sonuçlar sunmaya odaklanır
      Meğer artık pratik AI workflow'ları sunuyormuşuz
      Sonra da buna benzer ama açıkça farklı isimli bir rakibin adını karıştırıyor ve beni yönetici olarak listeliyor. İşin iyi yanı, rakibin iletişim bilgisini “danışmanlık randevusu” formunun arkasına saklamış olması; bu yüzden sadece bizim iletişim bilgimiz görünüyor
    • Artık Google'ın sitemi crawl etmesine ve indekslemesine bile izin vermiyorum
    • Artık Google da “siteye gelen botların 10GB zipbomb aldığı” hedefler arasında
      Şu anda hiçbir değer katmıyor, sadece daha fazla sorun çıkarıyor
    • Evet. Yıllarca, trafik getirir umuduyla web siteme tonla microdata etiketi ve özelliği ekledim
      Sonuçta sadece, insanların Google'dan ayrılmamasını sağlayan Google yapay zekasını eğitmiş oldum

  • Daha pratik bir yaklaşım istiyorsanız, web siteleri için Google dokümanlarında JSON-LD kısmını okumanızı tavsiye ederim
    https://developers.google.com/search/docs/appearance/structu...
    Oradaki bilgilerin çoğunun yalnızca bazı siteler için ilgili olduğunu da göreceksiniz. Rotten Tomatoes film eleştirmeni puanlarını JSON-LD ile yayımlayabilir ama ben film incelemesi yazsam bile bunun benim için pek ilgisi yok
    JSON-LD kolay ve arama motorları gerçekten kullandığı için makul. Web sayfasındaki bilgileri tekrar edebilir, ama bilginin belgede tam olarak bir kez görünmesini sağlayan kusursuz açıklama hayalinin, küresel inek ve kütlesiz halat gibi idealize edilmiş bir varsayım olduğunu düşünüyorum
    Bir web sayfası oluşturmak insan emeği gerektirir ve nihai üründe biraz tekrar olması sorun değildir

    • Büyük bir site olmasa da film incelemelerinde JSON-LD kullanabilirsiniz
      Ben sitemde kitap, oyun ve film incelemelerinde kullanıyorum; çoğu arama motorunda yıldız puanı gibi bilgiler gösteriliyor gibi görünüyor
    • 403. That’s an error.
      İstemcinin bu sunucudan /search/docs/appearance/structured-data/intro-structured-data URL'sini alma yetkisi olmadığı söyleniyor
    • Ama veriyi tekrar ederseniz su tüketimi artmaz mı. /s

  • Zengin bağlantı önizlemelerinde OpenGraph, JSON-LD'den çok daha sık destekleniyor
    Arama motoru optimizasyonu amacıyla bakarsanız, arama motorlarının desteklediği JSON-LD türleri çok spesifik ve sınırlı
    Hedef arama motorunun dokümantasyonuna, yani Google[1] ya da Bing[2]'e bakıp aynen onu takip etmek çok daha iyi; bunun dışındaki her şey neredeyse zaman kaybı
    Arama motorları dışında da, belirli bir amaç yoksa JSON-LD genelde işe yaramaz. JSON-LD gerektiren somut bir ihtiyacınız varsa faydalı olacak veriyi eklersiniz; onun dışındaki verileri eklemek ise boşluğa bağırmaya benzer
    IndieWeb[3] yapılandırılmış veri kullanıyor ama JSON-LD'yi DRY ihlali olarak görüp onun yerine Microformats[4] kullanıyor
    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/

  • Tüm web sitelerinde aslında uygulanmak istenen şey, Schema.org sözlüğünü kullanan yapılandırılmış veridir.
    JSON-LD bunun yöntemlerinden biridir; RDFa ve Microdata da vardır.
    İlk öğrenirken bu yazıya başvurmuştum ve tavsiye etmeye değer: https://neilpatel.com/blog/get-started-using-schema/
    Hangi verilerin eklenebileceğine bu araçla bakabilirsiniz: https://technicalseo.com/tools/schema-markup-generator/
    Tam liste schema.org sitesinde görülebilir: https://schema.org/docs/schemas.html

  • Birkaç yıl önce, uçak biletlerinin eklenmesi ya da kargo takip bilgilerinin görünmesi gibi gösterişli e-posta özelliklerinin tamamen e-postanın içindeki JSON-LD ile uygulandığını öğrenmiştim.
    Ama bildiğim kadarıyla bunu yalnızca Gmail destekliyor.
    Ek bilgi: https://www.emailonacid.com/blog/article/email-development/s...

    • Outlook ve iCloud da bilet veya rezervasyon gibi bazı özellikleri destekliyor.

  • Bu özelliklerin gerçekten arama görünürlüğüne yardımcı olup olmadığını, yoksa arama motorlarının kullanıcıyı sonuç sayfasında tutmasını mı kolaylaştırdığını merak ediyorum.

    • JSON-LD ekledikten sonra Google, sitemin içine giden alt bağlantıları göstermeye başladı. Bu fena değildi.
    • Bir işletme sitesi için JSON-LD, harita platformlarına veri sağlamakta kullanılabilir.
      Adres, çalışma saatleri, telefon numarası, menü gibi şeyler.

  • Zaten semantik HTML varken, tarayıcının işlemediği bir script etiketi içindeki özel, tuhaf bir JSON ile web sitesinin anlamını yeniden ifade etmek garip geliyor.

    • Kendi web sitemde JSON-LD kullandım ve bunun semantik HTML'den ayrı bir ihtiyacı karşıladığını düşünüyorum.
      Semantik HTML, başlık ve heading'ler gibi tarayıcının işleyeceği şeyleri belirler. JSON-LD verisi ise oluşturulma tarihi, güncellenme tarihi, etiketler, yazar gibi meta verilerdir.
      Bunlar HTML içinde microdata ile de ifade edilebilir, ama JSON-LD daha kolay olduğu için microdata kullanmayı bıraktım.
      JSON-LD'yi, siteyi üretmek için kullandığım aynı veriden dolduruyorum; ayrıca bu meta verilerle 2024 blog yazıları listesi ya da X konusu hakkındaki tüm yazılar gibi indeks sayfaları da oluşturuyorum. JSON-LD'nin başlıca tüketicisi arama motorlarıdır.
      Daha da sinirlenmek isterseniz aynı sayfaya OpenGraph meta verisi de koyduğumu düşünebilirsiniz. Yani aynı sayfada iki farklı meta veri biçimi var.
    • Microdata da var ve yanılmıyorsam JSON-LD ile aynı sözlüğü destekliyor. schema.org iyi bir kaynak.
      Ama JSON-LD bir süredir varsayılan haline geldi; tıpkı REST'i büyük ölçüde bırakıp RPC'ye geçmemiz gibi. Bugün önemli parser'ların microdata'nın tamamını hâlâ destekleyip desteklemediğinden emin değilim; özellikle de Google arama görünürlüğü isteyen e-ticaret siteleri gibi müşteri siteleri yaparken, varsayılan olarak LD kullandım.
      Semantik HTML ile karşılaştırınca dikkat çekici başka bir nokta daha var. Semantik HTML, markup yapısını tanımlamaya yardımcı olur ama “bu satılan bir üründür” ya da “bu bir tren tarifesidir” gibi gerçek dünya bağlamını ifade etmez.
    • Sanırım yazıyı yeterince iyi anlamamışsınız.
      HTML içinde Schema.org/FOAF/WikiData gibi ontolojileri JSON-LD ve script etiketi olmadan da kullanabilirsiniz.
    • İdeal dünyada sunucu ve tarayıcı içerik pazarlığı yapabilmeli; tarayıcı da önce web sitesinden yalnızca JSON-LD isteyip sonra kendi dahili render biçimini kullanmalıdır diye düşünüyorum.
    • Semantik HTML, JSON-LD ve diğer mikroformatların kapsadığı alanı kapsamaz.
      Yalnızca yazıda geçenlere bakınca bile, insanları, breadcrumb listelerini, yazılım uygulamalarını, blogları ve blog gönderilerini gösterecek semantik öğelerin hangileri olduğunu sormak gerekiyor.
      Semantik HTML, ekran okuyucu kullanan birinin “navigasyon” veya “makale” gibi genel öğeler arasında gezinmesine yardımcı olmak içindir.

  • Bu sadece OpenGraph'ın JSON ile yazılmış hali değil mi? Avantajı ne?

  • 2024'ten sonra içerik odaklı pazarlama sayfalarımızın trafiği yaklaşık %85 düştü.
    Anlamadığım şey şu: sıfır tıklamalı sonuç sayfaları arttıysa, Google da bundan büyük darbe almıyor mu?
    Tıklama bazlı sonuç sayfası reklam gelirleri de benzer ölçüde ciddi şekilde düşmüş olmalıydı, ama bu hipotezi çürütecek ya da doğrulayacak açık rakamlar bulamadım.

  • Belli bir noktadan sonra karşılıklı fayda sömürüye dönüşen hassas bir denge var.
    Web sitelerinin arama motorlarının yardımıyla görünürlük kazanması ilişkisi büyük ölçüde karşılıklı yarar sağlıyordu.
    Ama şimdi işler tamamen, web sitesi sahiplerinin emek vererek ürettiği çalışmadan hiçbir şey kazanamadığı bir yöne gidiyor.