İşletme Web Sitesinde Yapılandırılmış Veri Nasıl Kurulur?

İşletme web sitesinde yapılandırılmış veri kurmak, önce her sayfanın ana varlığını ve diğer sayfalarla ilişkisini belirleyip sonra görünür bilgilerle eşleşen işaretlemeyi üretmektir. Bu yaklaşım, ana şirketi şubeyle, ürün listesini tek ürünle veya işletme bilgisini hizmetin kendisiyle karıştırma riskini azaltır.

Schema markup’ın temelini ve Organization, LocalBusiness, Product ile FAQ örneklerini ayrı yazılarda bulabilirsiniz. Burada amaç, bir web sitesindeki sayfa ve varlıkların tamamını uygulama planına dönüştürmektir.

Önce sayfaları ve gerçek varlıkları envantere alın

CMS’ye kod eklemeden önce önemli URL’leri listeleyin. Her satırda sayfanın amacını, ana konusunu, orada görünen bilgileri ve bu bilgilerin kaynağını kaydedin. Başlangıç tablosu şöyle olabilir:

Bu tablo, her satıra otomatik bir tür atamak için değil, sayfanın esas işlevini unutmamak için kullanılır. Bir katalog sayfası, tekil ürün sayfası değildir. Şirketin genel adresi, şube adresleri yerine geçmez. İşletmenin genel iletişim kanalı da tek başına belirli bir hizmetin başvuru yolu olduğunu kanıtlamaz.

Kuruluş ve şube bilgilerini ayrı varlıklar olarak tutun

Organization kaydı şirketin veya kurumun kimliğini anlatır. Belirli bir fiziksel yer ya da şube ise LocalBusiness türüyle modellenebilir. Zincir mağaza, klinik veya birden çok şubeli işletmede tüm şube adreslerini tek bir işletme kaydına yığmak, hangi bilginin hangi konuma ait olduğunu belirsizleştirir.

Her şubenin kendi sayfası ve gerçek adresi varsa şube için ayrı kimlik kullanın. Kuruluş ana kaydı ile şube kayıtları arasındaki ilişkiyi açık kurun. Şube telefonları, çalışma saatleri ve adresleri ayrı kaynaklardan yönetiliyorsa, her sayfada elle yazmak yerine bunları CMS’de aynı doğrulanmış kaynaktan üretin. Bir alan bilinmiyorsa tahmin etmek yerine boş bırakın.

Hizmetleri ürünlerden ve genel işletme açıklamasından ayırın

Schema.org’daki Service, bir kuruluşun sağladığı hizmeti tanımlamak için kullanılabilir. Bu tür; hizmetin adı, açıklaması, sağlayıcısı, hizmet alanı veya erişim kanalı gibi sayfada ve iş akışında gerçekten desteklenen bilgileri ilişkilendirebilir. Ancak her işletme ana sayfasındaki “hizmetlerimiz” listesini otomatik olarak eksiksiz bir hizmet kataloğu saymayın.

Hizmetin kapsamı, hangi koşullarda sunulduğu ve başvurunun nereden yapıldığı ayrı bilgiler olabilir. Kullanıcı “bu hizmet için nasıl başvururum?” diye sorduğunda, hizmet sayfasındaki gerçek form veya iletişim yolunun hizmetle bağlantılı olması gerekir. Form yoksa veya başvuru yöntemi sayfada açıklanmıyorsa schema alanı ekleyerek eksik süreci varmış gibi göstermeyin. Site içindeki içerik, hizmet kaydı ve başvuru kanalı birbiriyle tutarlı olmalıdır.

Ürün, teklif ve kategori ilişkisini karıştırmayın

Ürün, teklif ve liste farklı varlıklardır. Product belirli bir ürünü tanımlar; Offer o ürünün satılması, kiralanması veya hizmet olarak sunulması için geçerli teklifi anlatabilir. Bir kategorideki çok sayıda ürün sayfasını tek Product kaydına çevirmeyin. Google’ın ürün zengin sonuç rehberi de tek ürün veya aynı ürünün varyantlarına odaklanan sayfalara işaret eder.

Fiyat, para birimi, stok, teslimat veya seçenek bilgisi zamanla değişiyorsa, kaynak sistem ile görünür sayfa ve işaretleme aynı veriyi kullanmalıdır. Kampanya fiyatı bitince eski değerin JSON-LD’de kalması tutarsızlıktır. İşaretlemeye yorum sayısı, yıldız puanı veya indirim oranı eklemek için görünür ve gerçek kanıt gerekir.

Aynı varlığı sayfalar arasında nasıl bağlamalısınız?

Bir kuruluş ana sayfada, iletişim sayfasında ve şube sayfalarında tekrar anılabilir. Bu tekrarların aynı kurumsal varlığa mı yoksa farklı noktalara mı ait olduğu makinece anlaşılmalıdır. JSON-LD’de kalıcı bir @id yaklaşımı aynı varlığa yapılan başvuruları bağlamaya yardımcı olabilir; bir ürünün, şubenin veya hizmetin kimliğini başka varlıkla paylaşmayın.

Aynı @id değerini her URL’ye kopyalamak site genelinde her kaydı tek öğeye dönüştürmez. Önce kimlik modelini belirleyin: bir kuruluş, her fiziksel şube, her ürün ve gerçekten ayrı sunulan hizmet için hangi kayıtlar tutulacak? Sonra sayfa türünü o varlıkla ve ilişkili öğelerle açıkça bağlayın. JSON-LD 1.1’de @id, bir düğümün tanımlayıcısını belirtir. Uygulama önerisi olarak aynı kuruluş farklı sayfalarda temsil ediliyorsa aynı @id IRI’sini kullanmak bu kayıtları bağlamaya yardımcı olur; ancak ayrı şube veya ürünler kendi kimliklerini korumalıdır.

Görünür içerik ile yapılandırılmış veriyi tutarlı tutun

Yapılandırılmış veri sayfada görünmeyen bir bilgiyi doğru hâle getirmez. Sayfada kullanıcıya gösterilen işletme adı “ABC Makine” iken işaretleme farklı bir ad, eski adres veya başka bir ürün fiyatı söylüyorsa, makine ve insan için iki ayrı gerçek oluşur. Google’ın genel yönergeleri, işaretlemenin ana sayfa içeriğini temsil etmesini ve kullanıcıdan gizlenmiş veriyi işaretlememeyi ister.

Bu nedenle dağıtımdan önce alanları görünür sayfa ile karşılaştırın: işletme adı ve adres, hizmet açıklaması, ürün bilgisi, teklif fiyatı, stok ve FAQ yanıtı. Otomatik üretimde kaynak verinin kim tarafından ve ne zaman güncellendiğini de belirleyin. Boş değerleri uydurma içerikle doldurmak yerine, gerçekten bilinen alanları yayımlamak daha güvenlidir.

Kurulumu nasıl test edip sürdürebilirsiniz?

İşaretlemeyi önce sayfa işlevine göre doğrulayın. Schema.org Markup Validator, genel Schema.org verisini ve grafiği incelemeye; Google Rich Results Test, Google’ın desteklediği özelliklerde uygunluğu değerlendirmeye yarar. Test aracı uyarısız sonuç verse bile görünür içerik ve alan doğruluğunu ayrıca kontrol edin.

İlk aşamada temsili sayfaları yayınlayın: ana kuruluş, bir fiziksel şube, tek bir hizmet, tek bir ürün ve makale gibi. Sonuçları sayfa türüne göre gözden geçirin, sonra CMS şablonunu diğer uygun URL’lere genişletin. Güncelleme sonrası testleri tekrarlayın; özellikle adres, fiyat, stok ve hizmet koşulları değişen kayıtları izleyin. Yapılandırılmış veri Google’ın içeriği anlamasına yardımcı olabilir, ancak sıralama, zengin sonuç veya yapay zekâ yanıtında görünme garantisi değildir. Uygulamayı işletmenizin sayfalarına göre inceletmek için teknik uyum hizmetine bakabilirsiniz.

Sık sorulan sorular

Yapılandırılmış veriyi bütün sayfalara eklemeli miyim? Hayır. Bir işaretleme yalnızca sayfanın gerçekten sunduğu varlık ve bilgileri açıklamalıdır. Önce sayfanın ana amacını ve görünür içeriğini belirleyin.

Birden fazla şube için tek LocalBusiness kaydı yeterli mi? Şubelerin ayrı fiziksel adresleri ve bilgileri varsa kayıtları tek noktaya karıştırmayın. Her şubenin kimliğini ve güncel bilgilerini kendi sayfa bağlamında tutun.

Yapılandırılmış veri yapay zekâ yanıtlarında görünmeyi sağlar mı? Bunu garanti eden bir kaynak yoktur. Yapılandırılmış veri içeriğe ilişkin makinece okunabilir ipuçları sunar; görünürlük ve yanıt seçimi ayrıca sistemlere ve içeriğe bağlıdır.

Kaynaklar

Google Search Central, “General structured data guidelines” (son güncelleme 10.07.2026).
Google Search Central, “Overview of Search appearance topics” (son güncelleme 16.09.2026).
Google Search Central, “Product snippet structured data” (son güncelleme 08.09.2026).
Schema.org, “Service”, “Organization”, “LocalBusiness”, “Product” ve “Offer” (V30.1, 16.09.2026).
Schema.org, “Schema.org Markup Validator” (V30.1, 16.09.2026).
W3C, “JSON-LD 1.1” (Recommendation, 16.07.2020).