# Schema (Yapısal Veri) Rehberi: JSON-LD, @id Grafı ve Test Araçları Yazar: Fatih Emin Çakıroğlu (https://fatihemincakiroglu.com) Kaynak: https://fatihemincakiroglu.com/rehber/schema-yapisal-veri Yayın: 2026-10-18 Güncelleme: 2026-10-18 Yapısal veri (schema), sayfanızdaki bilgileri schema.org sözlüğünü kullanarak makinelerin okuyabileceği biçimde etiketlemektir. Bir insan sayfaya baktığında fiyatı, yazarı ya da adresi hemen anlar; arama motoru ise bu bilgiyi yapısal veri sayesinde tahmin etmeden, açıkça okur. Bu rehberde formatı seçmekten @id ile birbirine bağlı bir schema grafı kurmaya ve işaretlemeyi test etmeye kadar sahada uyguladığım yöntemi anlatıyorum. Yapısal veri [teknik SEO denetiminin](https://fatihemincakiroglu.com/rehber/teknik-seo) bir parçası olarak ele alınmalı; tek başına bir sıralama hilesi değildir. > Kısa cevap: Schema, sayfadaki bilgiyi schema.org sözlüğüyle etiketleyen yapısal veridir ve Google'ın önerdiği format JSON-LD'dir. Doğru işaretleme bazı zengin sonuç türleri için uygunluk sağlar; ancak zengin sonucu gösterip göstermemek Google'ın kararıdır ve işaretleme sayfada görünen içerikle birebir uyumlu olmalıdır. ## JSON-LD, Microdata ve RDFa: hangi schema formatı seçilmeli? Google üç formatı da destekliyor, ama önerdiği format JSON-LD. Yeni projelerde başka bir format kullanmam için neredeyse hiç sebep görmüyorum. | Format | Nasıl eklenir? | Ne zaman tercih edilir? | | --- | --- | --- | | JSON-LD | HTML'den ayrı bir script type=application/ld+json bloğu olarak | Çoğu site için ilk tercih; Google'ın önerdiği format | | Microdata | HTML etiketlerine itemscope ve itemprop öznitelikleri eklenerek | Eski temalarda karşılaşılır; tasarım değiştikçe bakımı zorlaşır | | RDFa | HTML'e typeof ve property öznitelikleri eklenerek | Bazı içerik yönetim sistemlerinde; yeni projede nadiren gerekir | JSON-LD'nin asıl avantajı şablondan bağımsız olmasıdır: tasarım değişse de işaretleme bozulmaz ve veritabanındaki bilgiden otomatik üretilebilir. Google, JavaScript ile sonradan eklenen JSON-LD'yi de okuyabiliyor; yine de diğer sistemlerin de sorunsuz görebilmesi için işaretlemeyi sunucu tarafında HTML'e yazmayı tercih ediyorum. ## Hangi sayfada hangi schema türü kullanılır? Sahada en sık gördüğüm hata, her sayfaya aynı genel işaretlemeyi basmak. Her türün doğal bir yeri var: | Tür | Nerede kullanılır? | Önemli özellikler | | --- | --- | --- | | Organization | Ana sayfa veya Hakkımızda | name, url, logo, sameAs, contactPoint | | Person | Yazar ve uzman profil sayfaları | name, jobTitle, worksFor, sameAs, image | | Article / BlogPosting | Blog yazıları ve rehberler | headline, author, datePublished, dateModified, image | | Product | Ürün detay sayfaları | name, image, offers (price, priceCurrency, availability), varsa review veya aggregateRating | | LocalBusiness ve alt türleri | Fiziksel adresi olan işletmeler | address, telephone, openingHoursSpecification, geo | | BreadcrumbList | Hiyerarşik yapıdaki sayfalar | itemListElement içinde sıralı position, name, item | | FAQPage | Görünür bir soru-cevap bölümü olan sayfalar | mainEntity içinde Question ve acceptedAnswer | Ürün sayfalarında fiyat, para birimi ve stok durumunun sayfada görünen bilgiyle aynı olması kritik; varyantlar ve stokta olmayan ürünler için yaklaşımı [e-ticaret SEO rehberinde](https://fatihemincakiroglu.com/rehber/e-ticaret-seo) anlattım. Fiziksel işletmelerde LocalBusiness yerine mümkünse Dentist, Restaurant gibi daha özel bir alt tür seçin ve adres-telefon bilgisini [Google Business Profile kaydınızla](https://fatihemincakiroglu.com/blog/google-business-profile) birebir eşleştirin; konunun tamamı [yerel SEO rehberinde](https://fatihemincakiroglu.com/rehber/yerel-seo) var. Bir uyarı: işletmenin kendi sitesinde kendisi hakkında gösterdiği yorumlar (self-serving reviews), LocalBusiness ve Organization için yıldızlı zengin sonuç almaz. Bu yüzden ana sayfaya aggregateRating eklemek fayda sağlamaz, yorumlar sayfada görünmüyorsa yönergelere de aykırıdır. ## @id ile schema grafı nasıl kurulur? Birçok sitede her eklenti kendi bağımsız bloğunu üretir: bir yerde Organization, başka bir yerde yazarın adı düz metin, makalede ise publisher olarak farklı yazılmış bir şirket adı. Arama motoru bunların aynı varlık olduğunu tahmin etmek zorunda kalır. @id bu sorunu çözer. @id, bir varlığa verdiğiniz kalıcı ve benzersiz bir kimliktir; genellikle sayfanın kanonik adresi ile bir parça tanımlayıcı birleştirilir. Varlığı bir kez tam olarak tanımlarsınız, diğer bloklarda yalnızca bu kimliğe atıf yaparsınız. Aşağıdaki örnekte makalenin yazarı ve yayıncısı, aynı grafın içindeki Person ve Organization düğümlerine bağlanıyor: ``` ``` - **Kalıcı olsun:** @id değerlerini bir kez belirleyin ve değiştirmeyin; tüm sayfalarda aynı varlık için aynı @id kullanılmalı. - **Kanonik adrese dayansın:** Organization için ana sayfa, Person için profil sayfası adresi en mantıklı temeldir. - **Tek kaynak olsun:** Organization bilgisi tek bir yerde tam tanımlanır; diğer sayfalar yalnızca @id ile bağlanır. - **sameAs'i doğru kullanın:** yalnızca markanın ya da kişinin resmî profillerini ekleyin. Bu yapı, markanın kim olduğunu tutarlı biçimde tanımladığı için [GEO uygulama rehberinde](https://fatihemincakiroglu.com/rehber/geo-uygulama) anlattığım varlık netliği çalışmasının da teknik temelidir. ## FAQPage ve HowTo şemasının zengin sonuç durumu nedir? Bu konuda hâlâ çok eski bilgi dolaşıyor, o yüzden net yazayım. Google, Ağustos 2023'te FAQ zengin sonuçlarını yalnızca iyi bilinen, yetkili devlet ve sağlık siteleriyle sınırladı; 7 Mayıs 2026'dan itibaren ise FAQ zengin sonuçlarını Google Arama'da hiç göstermiyor ve Haziran 2026'da bu özelliğin dokümantasyonunu kaldırdı. HowTo zengin sonuçları 2023'te kaldırılmıştı. Tarihli liste için [Google güncellemeleri günlüğüne](https://fatihemincakiroglu.com/google-guncellemeleri) bakabilirsiniz. | Şema | Google'daki zengin sonuç durumu | Kullanmaya değer mi? | | --- | --- | --- | | FAQPage | Mayıs 2026'dan beri zengin sonuç olarak gösterilmiyor | Zengin sonuç için değil; sayfada gerçek bir SSS varsa geçerli işaretlemedir ve içeriğin makineler tarafından anlaşılmasına yardımcı olabilir | | HowTo | Zengin sonuç özelliği 2023'te kaldırıldı | Google'da görünüm beklentisiyle öncelik değil | FAQPage işaretlemesini, sayfada kullanıcının gerçekten gördüğü soru-cevaplar varsa ekliyorum; çünkü içeriğin yapısını makineler için netleştiriyor. Ama müşterilere “SSS şeması ekleyelim, arama sonucunda yer kaplasın” vaadiyle sunmuyorum. Sağlık sitesi olmak da tek başına yeterli değil; [sağlık sektörü SEO rehberinde](https://fatihemincakiroglu.com/rehber/saglik-seo) bu tür sitelerin öncelikleri ayrıca anlatılıyor. ``` { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [{ "@type": "Question", "name": "Siparişler ne zaman kargoya verilir?", "acceptedAnswer": { "@type": "Answer", "text": "Siparişler iki iş günü içinde kargoya verilir." } }] } ``` Google desteklediği zengin sonuç türlerini zaman zaman sadeleştiriyor; FAQ ve HowTo bunun en bilinen örnekleri. Bir türü uygulamadan önce Google Search Central'daki güncel yapısal veri galerisine bakmanızı öneririm. ## Schema işaretlemesi nasıl test edilir ve izlenir? Test iki farklı soruyu cevaplar: işaretleme schema.org açısından geçerli mi, ve Google'ın zengin sonuç gereksinimlerini karşılıyor mu? Bu yüzden iki aracı birlikte kullanıyorum. | Araç | Ne işe yarar? | | --- | --- | | Zengin Sonuç Testi (Rich Results Test) | Google'ın desteklediği türler için uygunluğu, hataları ve uyarıları gösterir; URL ya da kod ile çalışır | | Schema Markup Validator (validator.schema.org) | Tüm schema.org türlerini sözdizimi ve sözlük açısından doğrular; Google'a özgü değildir | | Search Console geliştirme raporları | Site genelinde tespit edilen öğeleri, geçerli ve geçersiz sayılarını izler | | Search Console URL Denetleme | Google'ın sayfada tespit ettiği yapısal veri öğelerini gösterir | - [ ] Yayından önce her sayfa şablonundan birkaç örneği test edin - [ ] Sayfada görünen fiyat, tarih, yazar ve adresin işaretlemeyle aynı olduğunu kontrol edin - [ ] Kaynak kodda aynı türden tekrar eden blok olup olmadığına bakın - [ ] Yayından sonra Search Console raporlarını birkaç hafta izleyin - [ ] Tema, eklenti veya platform güncellemelerinden sonra testi tekrarlayın ## En sık yapılan schema hataları Denetimlerde karşılaştığım hataların çoğu teknik değil, içerikle işaretleme arasındaki uyumsuzluktan kaynaklanıyor: - **Görünmeyen bilgiyi işaretlemek:** sayfada olmayan yorumları, puanları veya SSS'leri işaretlemek Google'ın yönergelerine aykırıdır ve yapısal veriyle ilgili manuel işleme yol açabilir. - **Çakışan eklentiler:** tema ve SEO eklentisinin ayrı ayrı Organization üretmesi, iki farklı logo ve isim. - **Uyuşmayan ürün bilgisi:** indirim bitmiş ama işaretlemede eski fiyat, tükenmiş ürün için InStock. - **Tarih oyunları:** içerik değişmeden dateModified güncellemek; ya da tersine, büyük güncellemeden sonra tarihi eski bırakmak. - **Kopyalanmış şablonlar:** başka bir siteden alınan örnekte kalan yabancı URL'ler ve @id değerleri. - **Yer tutucu değerler:** zorunlu alanları boş ya da “örnek” gibi değerlerle doldurmak. Site taşıma ve platform değişikliklerinde yapısal verinin sessizce kaybolması da sık görülür; bu yüzden [site taşıma SEO](https://fatihemincakiroglu.com/rehber/site-tasima-seo) kontrol listenize yapısal veri testini de ekleyin. Kendi sitenizdeki işaretlemenin bir uzman gözüyle incelenmesini isterseniz [SEO uzmanı](https://fatihemincakiroglu.com/seo-uzmani) hizmetime göz atabilir veya [iletişim sayfasından](https://fatihemincakiroglu.com/iletisim) bana yazabilirsiniz. ## Sıkça Sorulan Sorular ### Schema sıralamayı doğrudan yükseltir mi? Google, yapısal verinin genel bir sıralama faktörü olmadığını belirtiyor. Etkisi dolaylıdır: sayfanın daha doğru anlaşılmasını sağlar ve uygun türlerde zengin sonuç için aday olmanızı mümkün kılar. Zengin sonuç da tıklama oranını etkileyebilir. ### WordPress eklentisinin ürettiği schema yeterli mi? Yaygın SEO eklentileri iyi bir başlangıç grafı üretir. Yine de Organization bilgilerini, yazar profillerini ve sameAs bağlantılarını elle tamamlamak, tema veya başka eklentilerle oluşan tekrarları temizlemek gerekir. Eklentinin ürettiği çıktıyı mutlaka test araçlarıyla kontrol edin. ### Search Console'daki uyarılar sorun mu? Uyarılar genellikle önerilen ama zorunlu olmayan bir özelliğin eksik olduğunu gösterir; öğe yine geçerlidir. Hatalar ise öğeyi zengin sonuç için uygunsuz kılar ve öncelikle düzeltilmelidir. Uyarıları, eksik bilgiyi gerçekten sağlayabiliyorsanız giderin. ### Yapısal veri ChatGPT gibi asistanlarda görünmeye yardım eder mi? Yapay zekâ asistanlarının yapısal veriyi nasıl kullandığına dair kesin, doğrulanmış bir bilgi yok. Ben yapısal veriyi marka bilgisini tutarlı ve makine tarafından okunabilir hâle getirdiği için GEO çalışmasında da kullanıyorum, ama tek başına bir çözüm olarak görmüyorum. Ölçüm için [markanızın ChatGPT'de nasıl göründüğünü test etme yöntemini](https://fatihemincakiroglu.com/blog/chatgpt-marka-gorunurlugu) kullanabilirsiniz. ### Çok dilli bir sitede schema nasıl kurulmalı? Her dil sayfası kendi dilinde, o sayfada görünen içeriği yansıtan işaretlemeye sahip olmalı; inLanguage özelliği dili belirtmek için kullanılabilir. Organization ise tek bir varlık olduğu için tüm dillerde aynı @id ile tanımlanmalıdır. ### Schema değişikliklerinin arama sonuçlarına yansıması ne kadar sürer? Sabit bir süre yok; Google'ın sayfayı yeniden taraması ve işlemesi gerekir. Önemli sayfalar için Search Console'daki URL Denetleme aracından yeniden tarama isteyebilirsiniz. Zengin sonuç uygunluğu oluşsa bile gösterim kararı Google'a aittir. --- Alıntılarken kaynak gösterin: "Fatih Emin Çakıroğlu (fatihemincakiroglu.com)". Orijinal: https://fatihemincakiroglu.com/rehber/schema-yapisal-veri