Blog details
Search Console’da yapılandırılmış veri hatası görmek moral bozabilir. Daha da kötüsü, sarı uyarılar ile gerçekten kritik sorunlar çoğu zaman birbirine karışır.
Oysa schema işaretlemesinde doğru teşhis yarı işin kendisidir. Sorun bazen tek bir eksik alandır, bazen de sayfanın tamamında yanlış tür kullanılmıştır. Bu yüzden önce etkisini anlamak, sonra kaynağı bulmak gerekir.
Önce hatanın etkisini ayırın
Her schema markup hatası aynı ağırlıkta değildir. Bu ayrımı yapmadan kod düzeltmeye başlamak zaman kaybettirir.
Search Console’da gördüğünüz hatalar kabaca üç gruba ayrılır. İlki, sentaks ve geçerlilik hatalarıdır. JSON-LD içinde eksik virgül, bozuk tırnak, yanlış kapanan parantez gibi sorunlar buna girer. Google veriyi okuyamazsa zengin sonuç da üretmez.
İkinci grup, zorunlu alan eksikleridir. Burada işaretleme okunur, ama ilgili rich result türü için yeterli bulunmaz. Örneğin bir tür için zorunlu olan özellik eksikse sayfa uygunluğunu kaybedebilir.
Üçüncü grup ise uyarılardır. Bunlar çoğu zaman önerilen alanların eksik olmasından gelir. Sayfa tamamen elenmeyebilir, ama sonuç daha zayıf görünür ya da bazı ek görünümler çıkmaz.
Search Console’daki her uyarı acil değildir. Öncelik, uygunluğu bozan kritik hatalarda olmalıdır.
Bir nokta daha var. Search Console size her zaman canlı durumu göstermez. Raporlar geçmiş taramaya dayanır. Siz kodu düzeltmiş olsanız bile hata bir süre görünmeye devam edebilir. Bu yüzden rapora bakıp karar vermek yeterli değildir, canlı URL’yi ayrıca test etmek gerekir.
Ayrıca Google’ın yapılandırılmış veri yönergeleri teknik doğrulamadan daha geniştir. İşaretlediğiniz bilgi sayfada görünmeli, yanıltıcı olmamalı ve gerçekten ilgili nesneye ait olmalıdır. Kod geçerli olsa da politika ihlali varsa sorun bitmez.
Hataları tespit etmek için en güvenilir akış
Schema sorunlarını bulmanın en temiz yolu, tek bir araca körü körüne bağlı kalmamaktır. Doğru akış, canlı sayfayı test etmek, genel doğrulama yapmak ve sonra Search Console verisini okumaktır.
Önce canlı URL’yi Rich Results Test ile kontrol edin. Bu araç, Google’ın sayfada hangi zengin sonuç türünü algıladığını gösterir. Aynı zamanda eksik alanları, geçersiz değerleri ve uygunluk sorunlarını da listeler. Yayına çıkmamış bir şablon üzerinde çalışıyorsanız kod modunda test etmek de mümkündür.
Ardından genel doğrulama için Schema Markup Validator kullanın. Bu araç, Google’a özel rich result uygunluğundan bağımsız olarak schema.org işaretlemesinin yapısını kontrol eder. Yani sayfanız bir rich result üretmese bile işaretlemenin doğru kurulup kurulmadığını görebilirsiniz.
Sonraki adım Search Console’dur. Burada raporlar, hatanın kaç URL’yi etkilediğini gösterir. Ayrıca sorun tek bir sayfada mı, yoksa bir şablonun tamamında mı, bunu anlamanızı sağlar. Google’ın kendi structured data sorunlarını düzeltme yardım sayfası da canlı URL testi ve doğrulama akışını açık biçimde anlatır.
Bu aşamada sayfanın nasıl üretildiğine bakın. İşaretleme tema içinde mi geliyor, SEO eklentisi mi yazıyor, yoksa GTM ile sonradan mı ekleniyor? JavaScript ile enjekte edilen schema, kaynak kodda görünmeyebilir. Bu normaldir. Önemli olan Google’ın render sonrası bunu gerçekten okuyup okumadığıdır.
Aynı URL’yi hem kaynak koddan hem render edilmiş sürümden kontrol etmek, tanıyı hızlandırır. Çünkü sorun bazen verinin kendisinde değil, sayfaya geç eklenmesindedir.
En sık görülen schema markup hataları ve pratik çözümler
Aşağıdaki tablo, sahada en sık karşılaşılan sorunları hızlıca ayırmak için iyi bir referanstır.
| Hata | Olası neden | Çözüm |
|---|---|---|
| JSON-LD sentaks hatası | Eksik virgül, bozuk tırnak, kapanmayan parantez | İşaretlemeyi validator’da test edin, şablon çıktısını satır satır kontrol edin |
| Zorunlu alan eksik | Tür için gerekli özellik eklenmemiş | Rich Results Test’te belirtilen alanı doldurun, verinin sayfada göründüğünü doğrulayın |
| Önerilen alan eksik | CMS alanı boş, eşleme yapılmamış | Uyarıysa önceliği düşük tutun, fakat mümkünse tamamlayın |
| Yanlış schema türü | Sayfa amacı ile seçilen tür uyuşmuyor | İçeriğe uygun tür kullanın, desteklenmeyen türle rich result beklemeyin |
| Geçersiz değer biçimi | Tarih, fiyat, URL, puan biçimi hatalı | ISO tarih, tam URL, doğru para birimi ve geçerli değer biçimi kullanın |
| Yinelenen veya çakışan işaretleme | Eklenti, tema ve GTM aynı veriyi farklı yazıyor | Tek kaynak belirleyin, diğer işaretlemeleri kaldırın |
| Sayfa içeriğiyle uyuşmayan veri | Görünmeyen puan, stok ya da yazar bilgisi işaretlenmiş | Sayfada olmayan bilgiyi schema’ya yazmayın, Google yönergelerine uyun |
Tablodaki ilk satır en teknik görünenidir, ama çözümü nettir. JSON-LD bozuksa Google işaretlemeyi hiç okuyamaz. Bu tür hatalar çoğu zaman şablon düzenlemesi sonrası çıkar. Özellikle dinamik alanlardan gelen çift tırnaklar veya boş değerler yapıyı kırar.
Zorunlu ve önerilen alanları birbirine karıştırmamak da önemlidir. Zorunlu alan eksikse uygunluk düşer. Önerilen alan eksikse sayfa bazen yine görünür, ama daha sınırlı görünür. Bu ayrımı test araçları açıkça söyler. Sizden istenen şey, her tür için her alanı ezberlemek değil; doğru türü test edip eksikleri oradan okumaktır.
Yanlış tür kullanımı daha sinsi bir sorundur. Örneğin hizmet odaklı bir sayfayı Product olarak işaretlemek, kısa vadede “bir şeyler eklenmiş” hissi verir ama Google açısından yanlış eşlemedir. Benzer biçimde her schema.org türü Google’da zengin sonuç üretmez. Bu yüzden “geçerli schema” ile “Google açısından uygun schema” aynı şey değildir.
Yinelenen işaretlemeler de sık görülür. Tema bir Article şeması üretir, SEO eklentisi ikinci kez Article yazar, GTM üçüncü bir sürüm ekler. Eğer bu üç kaynak farklı başlık, tarih ya da yazar bilgisi veriyorsa Google çelişki görür. Böyle durumlarda tek tek alan düzeltmek yetmez. Önce tek kaynak seçmek gerekir.
Bir başka kritik başlık, içerik ile işaretlemenin uyuşmasıdır. Sayfada görünmeyen puanları, yorum sayılarını ya da stok bilgisini schema içine eklemek kısa yol değildir. Bu, doğrudan politika sorunu yaratabilir. Teknik olarak geçerli görünen işaretleme, bu yüzden yine sorunlu sayılır.
Düzeltme yaparken kaynak noktayı bulun
Schema markup hatalarını kalıcı biçimde düzeltmek için satır satır URL düzeltmek yerine kaynağı bulmak gerekir. Çünkü aynı hata çoğu zaman yüzlerce sayfaya aynı yerden dağılır.
İyi çalışan sıra şöyledir:
- Önce bir örnek URL seçin ve canlı testte hatayı doğrulayın.
- Sonra işaretlemenin kaynağını bulun, tema, eklenti, özel alan, feed ya da GTM.
- Düzeltmeyi tek sayfada değil, şablon düzeyinde yapın.
- Aynı URL’yi yeniden test edin ve hatanın gerçekten kalktığını görün.
- En son Search Console’da doğrulama sürecini başlatın.
Buradaki kritik nokta, Search Console doğrulamasını erken başlatmamaktır. Eğer sorun şablondan yayılıyorsa, tüm etkilenen sayfalar düzelmeden doğrulama isteği göndermek geri dönüşe neden olur.
Ayrıca sayfanın taranabilir olduğundan emin olun. noindex, robots.txt engeli veya erişim sorunu varsa Google düzeltilmiş işaretlemeyi tekrar göremeyebilir. Bu durumda hata çözülmüş olsa bile rapor temizlenmez.
Yapılandırılmış veri, teknik SEO’nun tek parçası değil. Daha geniş bir teknik çerçevede, profesyonel SEO danışmanlığı yaklaşımıyla taranabilirlik, içerik yapısı ve sayfa şablonları birlikte incelendiğinde kalıcı sonuç alınır.
Kısa kontrol listesi
Yayın öncesi ya da hata sonrası şu listeyi hızlıca gözden geçirin:
- Sayfadaki schema türü, içeriğin gerçek amacıyla uyumlu mu?
- Zorunlu alanlar eksiksiz mi?
- Önerilen alanlar mümkün olduğunca dolu mu?
- JSON-LD sentaksı doğrulandı mı?
- Aynı veriyi tema, eklenti veya GTM ikinci kez yazıyor mu?
- İşaretlenen bilgiler sayfada görünür mü?
- Tarih, fiyat, URL ve benzeri değer biçimleri doğru mu?
- Sayfa taranabilir mi, noindex veya engel var mı?
- Canlı test sonucu ile Search Console raporu karşılaştırıldı mı?
Doğru tanı, hızlı düzeltme
Schema işaretlemesinde en büyük hata, bütün uyarıları aynı ciddiyette görmek. Önce kritik hatayı, sonra kaynağı bulduğunuzda düzeltme süreci kısa sürer.
Canlı URL testi, genel doğrulama ve Search Console raporu birlikte okunduğunda tablo netleşir. Schema markup hataları çoğu zaman karmaşık görünür, ama düzenli bir kontrol akışıyla hızlıca çözülebilir. En iyi düzeltme de aynı sorunu yarın yeniden üretmeyen düzeltmedir.