Yapılandırılmış veri eklemek, arama sonucuna otomatik olarak yıldız, soru kutusu veya farklı bir görünüm kazandırmaz. İşaretlemenin türü, içerikle uyumu ve Google’ın o özelliği hâlâ destekleyip desteklemediği önemlidir. Eski bir eğitimde gösterilen şema, bugün aynı arama görünümünü sağlamıyor olabilir.
Bu rehber, 10 Ekim 2026 tarihinde kontrol edilen Google Search Central belgelerine dayanır. Bir teknoloji blogundaki yazı sayfasını örnek alarak hangi veriyi neden işaretleyeceğimizi ve sonucu nasıl doğrulayacağımızı ele alacağız.
Schema.org türü ile Google desteği aynı şey değildir
Google’ın desteklenen yapılandırılmış veri galerisi, arama özellikleri için hangi türlerin kullanıldığını gösterir. Bir türün schema.org sözlüğünde bulunması, Google’ın o tür için ayrı bir zengin sonuç sunduğu anlamına gelmez.
Bu nedenle örnek blogumuzda işe “en çok şema ekleyen eklenti hangisi?” sorusuyla başlamayız. Önce sayfanın gerçekte ne sunduğunu belirleriz. Bir makale, ürün teklifi ve etkinlik farklı bilgi türleridir; işaretleme de bu farkı yansıtmalıdır.
2026 değişikliği: FAQ zengin sonuçları kaldırıldı
Google’ın resmî dokümantasyon değişiklik kaydı, FAQ zengin sonuçlarının 7 Mayıs 2026’dan itibaren Arama’da gösterilmeyeceğini belirtir. İlgili dokümantasyonun kaldırılması da Haziran 2026 kaydında açıklanır. Bu nedenle bugün yalnızca FAQ kutusu kazanmak için işaretleme eklemeyi vaat eden eski öneriler güncel değildir.
Bu değişiklik, okuyucuya yararlı soru-cevap bölümlerini silmeniz gerektiği anlamına gelmez. Bir kurulum rehberinde sık karşılaşılan soruları cevaplamak hâlâ içerik açısından anlamlı olabilir. Değişen şey, belirli Google arama görünümüne yönelik beklentidir.
Örnek blogumuzda mevcut bir FAQ bölümü varsa önce okuyucuya yararına bakarız. Bilgiler güncelse bölüm kalabilir. Eklentinin ürettiği işaretlemeyi değiştirmeden önce de o ayarın başka sayfalara etkisini incelemek gerekir; bütün şemaları tek seferde silmek zorunlu bir sonuç değildir.
Blog yazılarında Article yaklaşımı
Article belgesi, Article, NewsArticle ve BlogPosting gibi türlerle yazı bilgilerinin sunulmasını açıklar. Başlık, yazar, görsel ve tarih gibi alanlar ilgili içeriği tanımlamak için kullanılabilir. Seçilen tür gerçek sayfayla uyuşmalıdır; sıradan bir rehberi haber gibi etiketlemek gerekmez.
Aşağıdaki JSON-LD yalnızca yapıyı göstermek içindir. Adresler, yazar ve görseller temsilidir; gerçek sayfaya kopyalanmadan önce değiştirilmelidir:
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Örnek CSS Rehberi",
"author": {
"@type": "Person",
"name": "Gerçek Yazar Adı",
"url": "https://example.com/yazar/"
},
"datePublished": "2026-10-10T12:00:00+03:00",
"image": [
"https://example.com/gorseller/css-rehberi.jpg"
],
"mainEntityOfPage": "https://example.com/css-rehberi/"
}Bu veri, gerçek uygulamada uygun JSON-LD script öğesi içinde sunulabilir. Örneğimiz bir siteye uygulanmış veya Rich Results Test ile test edilmiş değildir. Canlı sayfada yazarı, yayın tarihini ve görsel adresini gerçek içerikten üretmek gerekir.
Görünür içerikle tutarlılık şart
Genel yapılandırılmış veri kuralları, işaretlemenin sayfadaki içeriği doğru temsil etmesini ister. Doğru sözdizimi tek başına yeterli değildir. Google, teknik olarak geçerli işaretleme bulsa bile zengin sonuç göstermeyi garanti etmez.
Örnek blogda gerçek yazar yerine uydurma uzmanlık bilgisi eklemek, içerik güvenilirliğini artırmaz. Benzer biçimde sayfada bulunmayan değerlendirmeleri veya puanları işaretlemek doğru bir yöntem değildir. İşaretlemenin görevi var olan bilgiyi anlaşılır sunmaktır.
Tarih alanlarında da gerçek editoryal süreci esas alın. Yazının içeriği değişmemişken otomatik olarak her gün yeni güncelleme tarihi üretmek, kullanıcıya yanlış bir yenilik izlenimi verebilir. Tarihleri şablon kolaylığına göre değil, yapılan gerçek işlemlere göre yönetin.
WordPress’te önce mevcut çıktıyı inceleyin
Bir WordPress sitesinde tema ve birden fazla eklenti aynı sayfa için ayrı işaretlemeler üretebilir. Örnek süreçte yeni kod eklemeden önce kaynak HTML’i ve mevcut SEO eklentisinin ayarlarını inceleriz. Hangi bileşenin hangi bilgiyi ürettiğini bilmeden eklenen ikinci yapı, yönetimi zorlaştırabilir.
Yazar adı, görsel ve canonical adresi farklı kaynaklardan geliyorsa uyumsuzlukları düzeltmek gerekir. Her eklentinin ekranında alanların dolu görünmesi, canlı sayfada aynı verinin doğru çıktığı anlamına gelmez. Kontrolün hedefi ayar paneli değil, yayımlanan sayfadır.
Doğrulama sırası nasıl olmalı?
Önce içeriğin doğru ve erişilebilir olduğunu kontrol edin. Sonra Google’ın Rich Results Test aracıyla desteklenen özelliklerin algılanıp algılanmadığını inceleyin. Hata ve uyarıları ilgili türün güncel belgesiyle birlikte değerlendirin; tüm uyarıları birbirine eşit önemde saymayın.
Ardından gerçek URL üzerinde sonuçları kontrol edip Search Console’da uygun raporlar varsa izleyin. Raporun olmaması veya zengin görünümün hemen oluşmaması, tek başına kodun bozuk olduğunu göstermez. Google’ın uygunluk ve gösterim kararları farklı aşamalardır.
Örnek blogumuz için iyi hedef, desteklenen ve gerçekten sahip olduğumuz bilgileri tutarlı biçimde sunmaktır. Şema sayısını artırmak yerine veri doğruluğuna, kaynak sahipliğine ve güncel özellik desteğine odaklanmak daha sürdürülebilir bir bakım yaklaşımı sağlar.
