Google Tag Manager ile Schema Eklemek: Google JavaScript ile Gelen Yapısal Veriyi Okur mu?

Google Tag Manager ile schema eklemek Google tarafından okunuyor mu?

Evet, Google Search, sayfayı işlediğinde DOM içinde hazır duran ve JavaScript ile üretilen yapısal veriyi işleyebiliyor. Google Tag Manager ile schema eklemek bu yüzden teknik olarak mümkün. Ancak okuma, verinin doğru, eksiksiz ve zamanında göründüğünü garanti etmiyor.

Resmî Google Search Central belgesi bu yöntemi açıkça tarif ediyor. Aynı belge, sık değişen veride dinamik işaretlemenin sorun çıkarabileceğini de söylüyor. Bu yazı yalnızca bu tek durumu ele alıyor: GTM ile JSON-LD eklemek hangi koşulda işe yarıyor, nerede sorun çıkarıyor.

Genel SEO anlatımına girmiyoruz. Kavramlara yeni başlıyorsanız önce schema markup nedir yazımızı okuyun, sonra buraya dönün.

Kısa özet şu: Yöntem çalışıyor, ama her veri türü için eşit güvenilir değil. Sabit bilgi için makul, hızlı değişen bilgi için riskli. Geri kalan bölümlerde bu ayrımı adım adım açıyoruz.

Google Tag Manager ile schema eklemek teknik olarak nasıl çalışıyor?

Sayfaya GTM kapsayıcısı yükleniyor. Kapsayıcının içindeki bir etiket tarayıcıda çalışıyor ve sayfaya bir JSON-LD bloğu yazıyor. Google sayfayı işlediğinde bu bloğu DOM içinde buluyor ve yapısal veri olarak değerlendiriyor. Yani veri, sunucudan gelen ilk HTML içinde değil, sonradan oluşan sayfada yer alıyor.

Bu fark önemli. Sunucu tarafında yazdığınız işaretleme, ilk HTML ile birlikte geliyor. GTM ile eklediğiniz işaretleme ise etiketin çalışmasını bekliyor. Etiket hiç tetiklenmezse işaretleme de hiç doğmuyor. Dolayısıyla tüm sistem, kapsayıcının ve tetikleyicinin sağlıklı çalışmasına bağlı.

Kavramı kısaca oturtalım. JSON-LD, yapısal veriyi sayfanın görünen içeriğinden ayrı bir blokta anlatan biçim. Schema.org ise bu verinin ortak sözlüğü. Blok ne kadar düzenli olursa Google o kadar kolay ayrıştırıyor.

Kod örneği vermiyoruz. Amaç, mantığı anlamanız ve kendi şablonunuza uyarlamanız.

Bu yöntemin cazibesi hızdır. Geliştiriciye ihtiyaç duymadan, kapsayıcı üzerinden birkaç dakikada yeni bir işaretleme yayınlayabiliyorsunuz. Ancak aynı hız, kontrolsüz değişikliği de kolaylaştırıyor. Bu yüzden yetkileri sınırlamanızı ve her yayını not etmenizi öneriyoruz.

Google Tag Manager ile schema eklemek için hangi adımları izlersiniz?

Resmî belgedeki yaklaşım kısa bir sıraya dayanıyor. Biz de sahada aynı sırayı izliyoruz, çünkü sıra bozulduğunda hata ayıklamak zorlaşıyor.

1. Sitenizde GTM kapsayıcısının doğru yüklendiğini doğrulayın.
2. Yeni bir Custom HTML (özel HTML) etiketi oluşturun ve içine JSON-LD bloğunu yerleştirin.
3. Sayfadaki değişen bilgileri (başlık, adres gibi) değişkenlerle besleyin.
4. Etiketi yalnızca ilgili sayfalarda çalışan bir tetikleyiciye bağlayın.
5. Önizleme modunda etiketin gerçekten tetiklendiğini görün.
6. Kapsayıcıyı yayınlayın ve canlı URL'yi test edin.

Kapsayıcıyı ilk kez kuruyorsanız önce Google Tag Manager nedir yazımızı okuyun. Orada kurulumun temelini anlattık, burada tekrar etmiyoruz.

Menü adları zamanla değişebiliyor. Bu yüzden arayüzdeki kesin buton metnine yaslanmıyoruz, mantığı anlatıyoruz.

Bir adım daha ekleyin: Yayından önce kapsayıcıya anlaşılır bir sürüm notu yazın. Böylece sorun çıktığında hangi değişikliğin neyi bozduğunu hızlıca bulursunuz.

Değişken kullanımı schema verisini nasıl besliyor?

Her sayfa için ayrı bir etiket yazmak sürdürülebilir değil. Bu nedenle GTM değişkenleri devreye giriyor. Değişken, sayfadaki bir değeri okuyup etikete taşıyan bir yer tutucu. Örneğin sayfa başlığını, bir adres bilgisini ya da veri katmanındaki bir değeri okuyabiliyor.

Resmî belge de sayfa bilgisini çıkarmak için değişken kullanmayı öneriyor. Kavram basit: etikete sabit bir metin yazmak yerine, sayfadan okunan değeri yerleştiriyorsunuz. Böylece tek etiket, birçok sayfa için doğru çıktı üretiyor.

Burada bir uyarı yapmak gerek. Değişken boş dönerse işaretleme eksik ya da bozuk çıkıyor. Özellikle zorunlu özellikler boş kalırsa Google o bloğu kullanamıyor. Bu yüzden her değişkeni sayfa türüne göre ayrı ayrı doğrulamanızı öneriyoruz.

Ayrıca değişkenin okuduğu kaynağa dikkat edin. Sayfa şablonu değişirse değişken de sessizce bozulabiliyor. Şablon değiştiren herkesin GTM'den haberdar olması gerekiyor.

Örneğin tema güncellemesi sayfa başlığının bulunduğu alanı değiştirirse, değişken boş ya da yanlış değer dönebiliyor. Etiket yine çalışıyor, ama içindeki veri artık geçersiz oluyor. Bu tür sessiz bozulmaları ancak düzenli test yakalıyor.

Render gecikmesi riski ne anlama geliyor?

Google, JavaScript içeren sayfaları üç aşamada ele alıyor: tarama, işleme (render) ve dizine ekleme. Resmî JavaScript SEO belgesine göre sayfalar, işleme için ayrıca sıraya giriyor. Yani tarama ile işleme aynı anda gerçekleşmeyebiliyor.

Bunun sonucu şu: Sunucu tarafında yazdığınız işaretleme taramayla birlikte ortaya çıkıyor. GTM ile eklediğiniz işaretleme ise işleme aşamasından sonra ortaya çıkıyor. Aradaki farkın ne kadar sürdüğüne dair resmî bir süre yok, biz de bir süre vermiyoruz.

Haber, fiyat ya da stok gibi hızlı değişen verilerde bu fark sorun yaratıyor. Google eski değeri görürken sayfada yeni değer yazıyor olabilir. Bu nedenle sık değişen veride sunucu tarafı yazımını daha öngörülebilir buluyoruz.

Sabit kalan veride ise bu gecikmenin pratik bir bedeli çoğu zaman olmuyor. Karar, verinin değişme hızına bağlı.

İşleme aşamasında bir kaynak engellenirse risk daha da büyüyor. Örneğin etiketin dayandığı bir dosya erişilemezse sayfa eksik işlenebiliyor. Bu yüzden robots kurallarınızın gerekli kaynakları engellemediğinden emin olun.

Sonucu nasıl test edersiniz?

Test için resmî belge Rich Results Test (Zengin Sonuç Testi) aracını öneriyor. Kod yapıştırmak yerine URL girmeyi tercih edin. Çünkü yapıştırdığınız kodda JavaScript'in bazı sınırlamaları, örneğin CORS kısıtları, gerçek sonucu gizleyebiliyor.

Testte iki şeye bakın:

• Araç, beklediğiniz yapısal veri türünü algılıyor mu?
• Zorunlu özellikler dolu mu, hata ya da uyarı var mı?

Hata görürseniz önce sözdizimini, ardından eksik zorunlu özellikleri kontrol edin. Sonra ilgili veri türünün resmî belgesine dönün. Test başarılı olsa bile bu, zengin sonucun görüneceği anlamına gelmiyor. Google bunu kendi yönergelerinde açıkça belirtiyor.

Bir de zamanlamayı unutmayın. Testte görünen sonuç, anlık bir görüntü. Birkaç gün sonra sayfa değişirse sonuç da değişebiliyor. Bu yüzden önemli sayfalar için testi düzenli aralıklarla yineleyin.

Testi yalnızca bir sayfada değil, farklı sayfa türlerinde tekrarlayın. Bir şablonda çalışan etiket, başka şablonda boş değişken üretebiliyor.

Test sonuçlarını kaydedin. Tarih, URL ve sonuç yeterli. Böylece sonraki bir değişiklikte neyin bozulduğunu karşılaştırabilirsiniz. Ayrıca sonucu yalnızca bir kişiye bırakmayın, ikinci bir göz çoğu hatayı yakalıyor.

Rich Results Test ile URL Inspection aracı arasındaki fark nedir?

İki araç farklı soruya cevap veriyor. Rich Results Test, bir URL'nin zengin sonuç için uygun yapısal veri içerip içermediğini gösteriyor. URL Inspection Tool ise Google'ın o sayfayı nasıl gördüğünü ve işlenmiş HTML'in neye benzediğini ortaya koyuyor.

JavaScript SEO belgesi, içeriğin işlenmiş HTML içinde görünüp görünmediğini bu araçla doğrulamayı öneriyor. Biz de GTM ile eklenen işaretlemede iki kontrolü birlikte yapıyoruz. Birincisi veri türünü, ikincisi işlenmiş sayfadaki varlığını kontrol ediyor.

Araç adlarının Türkçe arayüzdeki karşılığını doğrulamadık. Bu yüzden İngilizce adlarını kullanıyoruz. Panelinizde benzer bir ad görürseniz aynı aracı arayın.

Ayrıca iki aracın sonucu farklı çıkarsa panik yapmayın. Farkın nedeni genellikle zamanlama ya da engellenen bir kaynak oluyor. Önce engelleri, sonra etiketin tetikleyicisini inceleyin.

Hangi aracın sonucuna güveneceğinizi şöyle belirleyin: Zengin sonuç uygunluğu için Rich Results Test, Google'ın gerçekte ne gördüğü için URL Inspection Tool. İkisi uyuşmuyorsa sorun çoğu zaman etiketin tetiklenme biçiminde yatıyor.

Ürün verisinde neden sunucu tarafı tercih ediliyor?

Ürün sayfasındaki fiyat ve stok bilgisi sık değişiyor. Resmî belge bu konuda net bir uyarı yapıyor: Dinamik üretilen işaretleme, alışveriş taramalarını daha seyrek ve daha az güvenilir hale getirebiliyor. Bu da özellikle ürün stoku ve fiyatı gibi hızlı değişen içerikte sorun yaratabiliyor.

Örnek senaryo: Bir mağaza indirim başlatıyor ve fiyatı sayfada güncelliyor. GTM ile eklenen işaretleme geç işlenirse Google bir süre eski fiyatı gösterebiliyor. Kullanıcı farklı fiyat görüyor ve güven zedeleniyor.

Kısacası ürün verisi için ilk tercihimiz, işaretlemeyi sunucu tarafında üretmek. Fiyat ve stok zaten sunucuda biliniyor, bu yüzden doğal çözüm bu.

Mağaza kurulumunu da yönetiyorsanız e-ticaret danışmanlığı sayfamızda bu tür kararları nasıl ele aldığımızı görebilirsiniz.

Bir ürün şablonu sunucu tarafında işaretleme üretirken, kampanya etiketini GTM'de tutmak da mümkün. Ama aynı özelliği iki yerden yazmamaya dikkat edin. Aksi halde fiyat gibi kritik alanlarda çelişki doğuyor.

Merchant ve alışveriş özelliklerinde nelere dikkat edersiniz?

Belge, alışveriş sonuçlarını hedefleyen satıcılara iki şey hatırlatıyor. Birincisi, dinamik işaretleme tarama sıklığını ve güvenilirliğini etkileyebiliyor. İkincisi, sunucunuzun Google'dan gelen artan istek trafiğini kaldırabildiğinden emin olmalısınız.

Merchant tarafındaki ayrıntılı kurallar ayrı bir konu ve değişebiliyor. Bu yüzden menü adlarını ya da kesin ayar yollarını burada yazmıyoruz. Güncel gereksinimleri Merchant Center yardım sayfalarından kontrol edin.

Pratik kural şu: Ürün, fiyat ve stok bilgisini bir sistemden (ürün akışı gibi) Google'a gönderiyorsanız, sayfadaki işaretleme o veriyle tutarlı olmalı. Tutarsızlığın kaynağı çoğu zaman GTM değil, güncellenmeyen bir alan oluyor.

Bu yüzden ürün sayfalarında şu soruyu sorun: Fiyat değiştiğinde işaretleme kendiliğinden değişiyor mu? Cevap belirsizse sunucu tarafına geçin.

Örnek senaryo: Bir mağaza her hafta kampanya fiyatı yayınlıyor. İşaretleme GTM'de sabit yazılıysa, her kampanya için etiketi elle güncellemek gerekiyor. Unutulan her güncelleme, sayfa ile işaretleme arasında bir tutarsızlık yaratıyor.

Google Tag Manager ile schema eklemek hangi durumlarda mantıklı?

Bu yöntem her zaman kötü değil. Bazı durumlarda en makul seçenek bu:

• Sitenin kodunu değiştirme izniniz yok ya da geliştirici kuyruğu çok uzun.
• İşaretleme nadiren değişen bilgilere dayanıyor (kurumsal bilgi, iletişim, logo gibi).
• Sayfa şablonu sabit ve değişkenler güvenle okuyabiliyor.
• Hızlı bir deneme yapıp sonucu ölçmek istiyorsunuz.

Örneğin kurumsal tanıtım sayfasındaki firma bilgisi yıllarca aynı kalabiliyor. Bu tür bir işaretleme için GTM yeterli. Yine de kurulumdan sonra düzenli kontrol yapmanız gerekiyor.

Karar vermeden önce schema oluşturucu aracımızla taslağı hazırlayabilir, sonra GTM'e taşıyabilirsiniz. Böylece blok biçimini önceden sınamış oluyorsunuz.

GTM'in bir artısı daha var: Geri dönüş kolay. Önceki kapsayıcı sürümüne dönmek birkaç dakikanızı alıyor.

Bu esneklik, A/B denemesi gibi durumlarda işe yarıyor. Bir işaretleme türünün etkisini ölçmek istiyorsanız önce GTM'de deneyip, sonuç olumluysa kalıcı hale getirmek için sunucuya taşıyabilirsiniz.

Hangi durumlarda sunucu tarafı yazım daha güvenli?

Aşağıdaki durumlarda sunucu tarafı yazımı öneriyoruz:

• Ürün, fiyat, stok ve kampanya gibi sık değişen bilgiler var.
• Alışveriş özellikleri sizin için önemli.
• Sayfanın ilk HTML'inde veri bulunmasını istiyorsunuz.
• JavaScript çalıştırmayan tarayıcıların da veriyi görmesi önemli.

Son madde önemli. Google'ın JavaScript belgesi, her botun JavaScript çalıştıramadığını ve sunucu tarafı ya da ön işlemenin hâlâ iyi bir fikir olduğunu söylüyor. Bu yüzden veriyi ilk HTML'e koymak, daha geniş bir okuma güvencesi sağlıyor.

Ayrıca sunucu tarafı yazım, tek bir noktadan yönetim sağlıyor. Şablon güncellendiğinde işaretleme de birlikte güncelleniyor. GTM'de ise şablon ile etiket ayrı iki yerde duruyor ve birbirinden kopabiliyor.

Elbette sunucu tarafı yazımın da bir bedeli var. Geliştirici zamanı gerektiriyor ve yayın döngüsü daha yavaş işliyor. Yine de sık değişen veride bu bedel, tutarsız işaretlemenin yaratacağı sorundan genelde ucuz kalıyor.

GTM ile schema eklemek mi, sunucu tarafı yazım mı daha iyi?

Tek bir doğru cevap yok. Seçim, verinin ne sıklıkla değiştiğine ve kod erişiminize bağlı. Aşağıdaki tablo, kararı kolaylaştırmak için ekibimizin sahada kullandığı bakış açısını özetliyor.

Tablo bir kural değil, başlangıç noktası. Siteniz, şablonunuz ve ekibiniz farklıysa sonuç değişebiliyor.

Kararsız kalırsanız iki yöntemi karıştırın: Sabit bilgileri GTM'e, değişen bilgileri sunucuya verin. Yeter ki aynı türü iki yerde üretmeyin.

Karma kurulumda en önemli konu, sorumluluk sınırını yazıya dökmek. Hangi türü kim üretiyor, hangi sayfalarda çalışıyor, nerede test ediliyor? Bu üç sorunun cevabı tek sayfalık bir notta durabiliyor.

Çift işaretleme sorunu nasıl doğuyor?

Çoğu sitede bir SEO eklentisi ya da tema zaten yapısal veri üretiyor. Üstüne GTM ile aynı türde ikinci bir blok eklerseniz sayfada iki ayrı işaretleme oluyor. Bu duruma çift işaretleme diyoruz.

Çift işaretleme çoğu zaman çelişen değerler üretiyor. Örneğin eklenti bir fiyatı, GTM etiketi başka bir fiyatı yazıyor. Google hangisine güveneceğini bilemiyor. Sonuçta zengin sonuç hiç çıkmayabiliyor ya da yanlış veri çıkabiliyor.

Önleme yolu basit:

• Eklentinin ya da temanın zaten ne ürettiğini önce testle görün.
• Aynı türü iki kez eklemeyin.
• Eklenti çıktısını kapatacaksanız, GTM etiketini yayınlamadan önce kapatın ve test edin.
• Değişiklikten sonra canlı URL'yi yeniden test edin.

WordPress kullanıyorsanız Yoast SEO mu Rank Math mı yazımız, hangi eklentinin ne ürettiğini anlamanıza yardım ediyor.

Görünen içerikle uyumsuz işaretleme neden riskli?

Google'ın genel yapısal veri yönergeleri açık: Okurların göremediği içeriği işaretlemeyin. GTM ile eklerken bu kuralı unutmak kolay, çünkü etiket sayfa şablonundan bağımsız çalışıyor.

Örneğin etikete sabit bir puan ya da yorum sayısı yazarsanız ve sayfada bunlar görünmüyorsa, bu yönergeye aykırı. Yönergeleri ihlal eden sayfalar manuel işleme takılabiliyor ve zengin sonuç uygunluğunu kaybedebiliyor.

Bu yüzden altın kural şu: İşaretlemedeki her değer, sayfada okurun gördüğü bir değerle eşleşmeli. Uydurma yorum ya da puan işaretlemesi hiçbir koşulda kabul görmüyor. Ayrıca Google, doğru işaretlemenin bile sonuçta görüneceğini garanti etmiyor.

Bu nedenle etiketi yazan kişiyle sayfa içeriğini yöneten kişi aynı masada olmalı.

Ayrıca içerik değiştiğinde işaretlemeyi de gözden geçirme alışkanlığı kazanın. Bir hizmeti sayfadan kaldırıp etikette bırakırsanız, görünmeyen bir içeriği işaretlemiş oluyorsunuz.

Çerez onayı etiketin çalışmasını etkiler mi?

Çoğu sitede çerez onay mekanizması, etiketlerin ne zaman çalışacağını belirliyor. GTM etiketinizi onay şartına bağlarsanız, ziyaretçi onay vermediğinde etiket çalışmıyor. O zaman işaretleme de doğmuyor.

Yapısal veri, kişisel veri toplamayan bir içerik tanımı. Dolayısıyla bu etiketi izleme etiketlerinden ayrı düşünmek gerekiyor. Ancak bu kararı sitenizin hukuki yapısına göre verin. Bu yazı hukuki danışmanlık değildir.

Sahada gördüğümüz sorun şu: Etiket yanlışlıkla onay şartına bağlanıyor ve Google botu onay vermediği için işaretlemeyi hiç görmüyor. Bu yüzden testi, onay vermeden açtığınız bir oturumda da yapmanızı öneriyoruz.

Hangi etiketlerin onay şartına bağlı olacağı kararını sitenizin hukuki danışmanıyla netleştirin. Biz yalnızca teknik sonucu anlatıyoruz: Etiket çalışmazsa işaretleme de yok.

Yayına almadan önce hangi kontrol listesini uyguluyoruz?

Aşağıdaki listeyi her değişiklikte kullanıyoruz:

1. Etiket yalnızca hedef sayfalarda tetikleniyor mu?
2. Değişkenler boş dönmüyor mu?
3. Sayfada başka bir kaynaktan gelen aynı tür işaretleme var mı?
4. İşaretlemedeki her değer sayfada görünüyor mu?
5. Rich Results Test canlı URL'de hatasız mı?
6. URL Inspection Tool'da işlenmiş HTML işaretlemeyi içeriyor mu?
7. Onay vermeden açılan oturumda etiket çalışıyor mu?

Bu yedi soruya "evet" diyemiyorsanız yayına almayın. Ardından Search Console'daki ilgili raporları birkaç hafta izleyin ve değişiklikleri tarihleriyle not edin.

GTM ile eklenen schema ayrıştırılamıyor hatası verirse ne yaparsınız?

Bazen etiket çalışıyor ama işaretleme okunamıyor. Bunun yaygın nedeni, bir değişkenin tırnak ya da özel karakter içeren değerini bloğa olduğu gibi yazması. Blok bozuluyor ve ayrıştırılamıyor.

Bu durumu ayrı bir yazıda ayrıntılı anlattık. Search Console ayrıştırılamayan yapılandırılmış veri hatası yazımız, hata mesajının nedenini ve çözüm yolunu içeriyor. Burada yalnızca şunu söyleyelim: Değişken çıktısındaki özel karakterleri etikette temizlemeyi planlayın.

İşaretlemenin sayfadaki diğer SEO alanlarıyla uyumunu görmek için SEO analiz aracımızı da kullanabilirsiniz.

JavaScript ile eklenen işaretleme sayfa hızını etkiler mi?

Etkileyebilir. GTM kapsayıcısı ve etiketler sayfaya ek JavaScript yüklüyor. Etiket sayısı arttıkça ağırlık da artabiliyor. Tek bir küçük işaretleme etiketi genellikle belirgin bir yük getirmiyor, ama kapsayıcı zaten kalabalıksa toplam etki büyüyor.

Bu yüzden gereksiz etiketleri temizlemek iyi bir alışkanlık. Hız konusunun ayrıntıları için JavaScript site hızını nasıl etkiler yazımıza bakın. Burada tekrar etmiyoruz.

Hız ölçümünü dışarıdan alınmış ortalamalarla değil, sayfanızın kendi ölçümleriyle yapın. Başka sitenin ortalaması sizin siteniz hakkında bir şey söylemiyor.

Sonuçları nasıl izler ve ne zaman geri dönersiniz?

Yayına aldıktan sonra Search Console'daki zengin sonuç ve geliştirme raporlarını izleyin. Raporlar hemen güncellenmiyor, bu yüzden sabırlı olun ve değişiklikleri tarihleriyle not edin.

Aşağıdaki işaretler geri dönüş gerektiriyor:

• Hata sayısı artıyor ya da önceki geçerli öğeler azalıyor.
• Sayfada görünen değer ile işaretlemedeki değer ayrışıyor.
• Aynı türde iki farklı işaretleme çıkıyor.

Geri dönmek kolay: GTM'de önceki kapsayıcı sürümüne dönüyorsunuz. Bu, yöntemin bir avantajı. Ancak hızlı geri dönüş, sorunun Google tarafında temizlendiği anlamına gelmiyor. Yeniden işlenmesini beklemeniz gerekiyor.

Tetikleyici seçimi etiketin güvenilirliğini nasıl değiştiriyor?

Tetikleyici, etiketin sayfa yaşam döngüsünün hangi anında çalışacağını belirliyor. Çok erken çalışırsa değişkenler henüz dolmamış olabiliyor. Çok geç çalışırsa işleme sırasında etiket hiç ateşlenmeyebiliyor. İki uç da işaretlemenin eksik çıkmasına yol açıyor.

Genel ilke şu: Değişkenin okuduğu değer sayfada hazır olduktan hemen sonra çalışan, ama kullanıcı etkileşimine bağlı olmayan bir tetikleyici seçin. Tıklama ya da kaydırma gibi etkileşimlere bağlı tetikleyiciler bu iş için uygun değil, çünkü Google botu sayfayla etkileşime girmiyor.

Ayrıca tetikleyiciyi olabildiğince dar tutun. Tüm sayfalarda çalışan bir işaretleme etiketi, alakasız sayfalara da yapısal veri yazıyor. Bu da görünen içerikle uyumsuz işaretleme riskini büyütüyor.

Önizleme modunda her sayfa türünü ayrı ayrı gezin. Etiketin hangi sayfada çalıştığını, hangisinde çalışmadığını bir tabloya yazın. Bu küçük kayıt, aylar sonra sorun çıktığında size zaman kazandırıyor.

Tek sayfa uygulamalarında GTM ile schema eklemek nasıl işliyor?

Tek sayfa uygulamalarında (single page application) sayfa geçişleri tarayıcıda gerçekleşiyor ve tam sayfa yüklemesi olmuyor. Bu durumda GTM etiketi yalnızca ilk yüklemede çalışırsa, sonraki sayfalarda işaretleme eski sayfadan kalıyor ya da hiç oluşmuyor.

Google'ın JavaScript SEO belgesi, gezinme için adres parçalarını (hash) değil, düzgün URL'leri önermek gerektiğini söylüyor. Çünkü Googlebot parça tabanlı adresleri güvenilir biçimde çözemiyor. Düzgün URL yoksa işaretleme sorununuz, aslında bir dizine ekleme sorununun yan etkisi oluyor.

Uygulamada her sayfa geçişinde etiketin yeniden çalışmasını ve eski bloğun temizlenmesini sağlamalısınız. Aksi halde bir ürün sayfasında önceki ürünün bilgisi kalıyor.

Bu karmaşıklık yüzünden tek sayfa uygulamalarında sunucu tarafı ya da ön işleme genelde daha sağlam çıkıyor. Hız konusunda da avantaj sağlıyor.

GTM ile schema eklerken en sık hangi hataları görüyoruz?

Ekibimiz sahada aynı birkaç hatayı tekrar tekrar görüyor. Aşağıdaki liste, bir örnek senaryodan değil, genel gözlemlerden oluşuyor:

• Test edilmeden yayınlanan etiket, boş değişken yüzünden eksik zorunlu özellik üretiyor.
• Aynı tür işaretleme hem eklentide hem GTM'de duruyor.
• Etiket, tüm sitede çalışıyor ve alakasız sayfalara da veri yazıyor.
• Sayfadaki fiyat değişiyor ama etiketteki sabit değer eski kalıyor.
• Çerez onayı etiketi engelliyor ve kimse fark etmiyor.
• Kapsayıcı sürümleri not edilmediği için geri dönüş zorlaşıyor.

Bunların çoğu teknik değil, süreç hatası. Yani bir kontrol listesi ve düzenli test, hatanın büyük kısmını önlüyor.

Ayrıca etiketlere anlaşılır adlar verin. Altı ay sonra kapsayıcıya bakan biri hangi etiketin ne yaptığını anlayabilmeli.

Bu hataların hiçbiri için garantili bir çözüm sunmuyoruz. Ama her birini testle yakalayabilirsiniz.

Düzenli bir bakım ritmi kurun. Ayda bir kapsayıcıyı açıp etiketleri, tetikleyicileri ve değişkenleri gözden geçirmek yeterli. Kullanılmayan etiketleri kaldırın, çünkü eski etiketler hem hızı hem de karmaşıklığı artırıyor.

Ekibimiz bu işte nasıl destek oluyor?

Talha Aslan ve ekibi olarak yapısal veri kurulumlarını sayfa türüne göre planlıyoruz. Önce hangi verinin nerede üretildiğini çıkarıyoruz. Ardından hangi bölümü GTM ile, hangisini sunucu tarafında yazacağımıza karar veriyoruz.

Bu çalışmanın sonucu için garanti vermiyoruz. Zengin sonuç göstermek Google'ın kararı. Ama doğru kurulmuş ve görünen içerikle uyumlu bir işaretleme, o kararın önündeki engelleri azaltıyor.

Siteniz için bir değerlendirme isterseniz SEO danışmanlığı sayfamızdan bize ulaşabilirsiniz. Başlık ve açıklamalarınızı görmek için Google SERP önizleme aracını da deneyebilirsiniz.

Benzer teknik SEO kararlarında nereye bakmalısınız?

GTM ile schema eklemek, tek başına bir SEO stratejisi değil. Sitenin metin ve kod dengesiyle ilgili sorular için text to HTML oranı SEO'yu etkiler mi yazımız faydalı olacaktır. Genel teknik zemini görmek için teknik SEO nedir yazımıza göz atın.

Son olarak şunu hatırlatalım: Resmî belgeler zamanla değişiyor. Bu yazıdaki ilkeler kalıcı, ama ayrıntılar için Google Search Central'ın JavaScript ile yapısal veri üretme belgesini düzenli kontrol edin.

Ayrıca [genel yapısal veri yönergelerini]

(https://developers.google.com/search/docs/appearance/structured-data/sd-policies) ve JavaScript SEO temellerini okumanızı öneriyoruz.