Hızlı Cevap
Schema uygulama öncelikleri şudur: önce çoğu şablona yayılan BreadcrumbList ve Organization veya LocalBusiness işaretlemelerini kurun, sonra gelir ya da içerik etkisi yüksek Product veya Article şablonlarına geçin, en son FAQPage ve HowTo gibi daha seçici türleri ekleyin. Sıralamayı etki, efor, veri hazırlığı ve Google desteği belirlemelidir.
Önemli Noktalar
- Schema.org’daki her tür, Google’da aynı görünürlük fırsatını sunmaz.
- İlk fazda düşük eforlu BreadcrumbList ve kimlik şemaları öne çıkar.
- Product ve Article önceliği, şablonun gelir veya trafik etkisine bağlıdır.
- FAQPage ve HowTo yalnızca gerçek sayfa niyeti uygunsa eklenmelidir.
- Rich result uygunluğu sonuç garantisi değil, doğrulama başlangıcıdır.
Schema uygulama öncelikleri neden stratejik bir karardır?
Schema uygulama öncelikleri, yalnızca teknik bir iş listesi değildir; arama görünürlüğü, geliştirme kapasitesi ve veri kalitesi arasında yapılan bir kaynak tahsisidir. Google Search Central’ın 10 Aralık 2025 tarihli structured data giriş dokümanında vurgulandığı gibi, yapılandırılmış veri Google’a sayfanın anlamı hakkında açık sinyaller verir; ancak bu sinyaller yalnızca doğru sayfada, doğru türle ve görünür içerikle eşleştiğinde işe yarar. Bu yüzden “ne varsa ekleyelim” yaklaşımı yerine, “hangi şablon en geniş etkiyi üretir” sorusuyla başlamak gerekir.
Buradaki kritik ayrım şudur: Schema.org bir sözlüktür, Google desteği ise bunun alt kümesidir. Schema.org’un resmi release kaydına göre 30.0 sürümü 19 Mart 2026’da yayınlandı; fakat sözlüğe yeni bir tür veya özellik eklenmesi, bunun otomatik olarak Google rich result desteğine dönüştüğü anlamına gelmez. Google’ın 6 Ocak 2026 tarihli Search Gallery sayfası, fiilen hangi structured data türlerinin Search içinde desteklendiğini gösteren daha güvenilir operasyonel referanstır.
2026 bağlamında karar vermek bu nedenle daha da önemlidir. Structured data giriş dokümanı 10 Aralık 2025’te güncellendi, Search Gallery ve genel structured data politikaları ise 6 Ocak 2026’da yenilendi. Ayrıca Google Search Central Blog’un 12 Haziran 2025 tarihli duyurusunda bazı az kullanılan structured data görünümlerinin kademeli olarak kaldırılacağı açıklandı. Sonuç basit: öncelik, sözlük zenginliğine göre değil, desteklenen görünüm fırsatına ve iş etkisine göre belirlenmelidir.
- Sayfa tipi: Ana sayfa, ürün, kategori, blog ve lokasyon sayfası aynı önceliğe sahip değildir.
- İş hedefi: Marka doğrulama, yerel görünürlük, ürün tıklaması ve içerik keşfi farklı rollout sıraları ister.
- Görünürlük fırsatı: Google’ın desteklediği türler ve gerekli alanların hazır olması ilk sıralamayı belirler.
Önce hangi schema uygulanır? Etki x efor öncelik matrisi
Çoğu projede ilk soru “Product mı önce, Article mı önce?” olur; pratikte cevap daha temeldir. En hızlı kazanım çoğunlukla BreadcrumbList ile başlar, çünkü site hiyerarşisini netleştirir, çok sayıda şablona yayılır ve uygulama eforu düşüktür. Hemen ardından Organization veya fiziksel lokasyonu olan işletmelerde LocalBusiness gelir. Google’ın 6 Ocak 2026 tarihli Search Gallery dokümanında Breadcrumb, Organization, Local business, Product, Article ve FAQ açık biçimde desteklenen türler arasında listelenir; bu da başlangıç sırasını teoriden pratiğe taşır.
Organization, marka kimliği ve kurum bilgilerini taşır; logo, resmi ad, iletişim ve tanımlayıcılar için uygundur. LocalBusiness ise adres, açık saatler ve yerel işletme sinyalleri gerektiğinde öne çıkar. Fiziksel şubesi olmayan SaaS ya da kurumsal yapılarda önce Organization daha mantıklıdır. Çok lokasyonlu, harita ve yerel niyet taşıyan sitelerde ise LocalBusiness daha erken değer üretir. Kısacası ikisi birbirinin rakibi değil, farklı kullanım bağlamlarıdır.
İkinci dalgada seçim, şablonun ekonomik değerine göre yapılır. E-ticarette Product genelde Article’dan önce gelir; çünkü fiyat, bulunurluk ve teklif bilgisi doğrudan ticari sayfaya bağlanır. İçerik yayıncılarında ise Article çoğu zaman Product’tan önce gelir; çünkü görünürlük ihtiyacı haber, rehber ve blog şablonlarındadır. FAQPage ve özellikle HowTo ise çoğu projede ilk faz değil, ikinci veya üçüncü faz işidir; çünkü görünür içerik disiplini, sayfa niyeti ve güncel Google desteği daha seçicidir.
- 1. Öncelik: BreadcrumbList
- 2. Öncelik: Organization veya LocalBusiness
- 3. Öncelik: Product ya da Article
- 4. Öncelik: FAQPage
- 5. Öncelik: HowTo
Sayfa tipine göre rollout sırası: kurumsal, e-ticaret, blog ve yerel
Kurumsal sitelerde rollout çoğunlukla ana sayfa, hakkımızda, iletişim ve temel bilgi mimarisi üzerinden ilerlemelidir. İlk dalgada Organization ve Breadcrumb kullanmak, site kimliğini ve gezinme ilişkilerini sabitler. Ardından sık güncellenen içerik merkezi varsa Article; sık sorular gerçekten görünür biçimde yayınlanıyorsa FAQPage eklenebilir. Kurumsal sitede ilk günden HowTo kurmak çoğu zaman gereksizdir; çünkü niyet adım adım talimat değil, marka ve hizmet açıklamasıdır.
E-ticaret sitelerinde temel akış genellikle Breadcrumb + Product + Offer şeklindedir. Burada amaç, kategori-ürün ilişkisini ve ürün detayını netleştirmektir. Review alanı yalnızca sayfada gerçekten görünür, doğrulanabilir ve bütünlüklü veri varsa eklenmelidir; Google’ın genel structured data politikaları görünmeyen veya yanıltıcı işaretlemeyi açıkça riskli sayar. Ürün veri kalitesi zayıfsa önce Product’ın required alanlarını temiz yayımlamak, gösterişli ama eksik Review denemelerinden daha değerlidir.
Blog ve içerik sitelerinde Article çoğu zaman ikinci sırada değil, Organization’dan hemen sonra gelir. Çünkü içerik şablonu trafik motorudur. Buna rağmen Breadcrumb yine çoğu içerik sitesinde ilk yayına alınacak tür olmaya devam eder; eforu düşüktür ve bütün yazı hiyerarşisini kapsar. FAQPage ancak sayfa gerçekten soru-cevap biçimindeyse eklenmelidir. Salt görünürlük umuduyla her rehberin sonuna kısa soru blokları yerleştirip schema bağlamak, kaliteyi düşüren kötü bir alışkanlıktır.
Yerel işletme sayfalarında öncelik sırası biraz değişir: LocalBusiness, Breadcrumb ve varsa Organization birlikte düşünülür. Birden fazla şube varsa her lokasyon sayfasında tutarlı NAP verisi, çalışma saatleri ve görünür iletişim bilgisi şarttır. Blog içeriği aktifse Article ikinci fazda gelir. Nasıl yapılır içerikleri gerçekten hizmet sürecini anlatıyorsa HowTo kullanılabilir; ancak yerel hizmet sayfasını zorla HowTo’ya çevirmek yerine, niyeti korumak daha güvenli bir stratejidir.
- Kurumsal: Organization → Breadcrumb → Article/FAQPage
- E-ticaret: Breadcrumb → Product + Offer → Review
- Blog: Breadcrumb → Organization → Article → FAQPage
- Yerel: LocalBusiness → Breadcrumb → Organization → Article/HowTo
JSON-LD, doğrulama ve politika kontrolleri: hatasız yayın akışı
2026’da varsayılan tercih hâlâ JSON-LD olmalıdır. Google Search Central’ın structured data giriş dokümanında ve genel politikalar sayfasında, JSON-LD önerilen format olarak geçer; gerekçe de nettir: uygulaması ve bakımı daha kolaydır, ölçekli şablonlarda hata üretme ihtimali daha düşüktür. Microdata teknik olarak geçerlidir, ancak HTML içine dağılmış alanlar nedeniyle sürüm yönetimi ve hata ayıklaması daha zahmetli olabilir. Özellikle büyük içerik veya ürün envanterlerinde bu fark hızlıca operasyon maliyetine dönüşür.
Doğrulama akışı üç katmanda kurulmalıdır. İlk katmanda Rich Results Test ile sayfa bazlı uygunluğu kontrol edin. İkinci katmanda Search Console raporlarında kapsama, hata ve uyarı kümelerini izleyin. Üçüncü katmanda deploy sonrası sayfa sağlığını teknik sinyallerle eşleştirin; burada düzenli bir site sağlığı kontrolü, markup değişikliğinin render, indexlenebilirlik ve şablon tutarlılığı üzerindeki yan etkilerini ayırmayı kolaylaştırır.
Politika tarafında en sık görülen sorunlar aynıdır: görünmeyen içeriği işaretlemek, aynı varlığı birden fazla uyumsuz markup ile tekrarlamak, JavaScript ile çok geç enjekte edilen schema yüzünden tutarsız render üretmek ve sayfanın odak konusu ile alakasız tür seçmek. Google’ın 6 Ocak 2026 tarihli genel structured data guidelines dokümanı açık bir uyarı verir: görünür olmayan veya yanıltıcı içerik işaretlenmemelidir ve doğru markup bile rich result garantisi vermez. Bu yüzden rollout kalitesi, yalnızca hata sıfırlamak değil, sayfa gerçeği ile markup’ı birebir eşleştirmek anlamına gelir.
FAQ schema mı yoksa HowTo schema mı önce? Burada karar görünürlük değil, niyet odaklı verilmelidir. 6 Ocak 2026 tarihli Search Gallery listesinde FAQ açıkça desteklenen bir tür olarak yer alırken, HowTo aynı görünürlük listesinde ayrı bir fırsat olarak görünmüyor; bu, HowTo’yu ilk faz yerine ikinci faz adayı olarak yorumlamayı makul kılar. Sayfa gerçekten soru-cevap yapısındaysa FAQPage önce gelir. Sayfa adım adım uygulama anlatıyorsa ve her adım görünür durumdaysa HowTo düşünülür; aksi hâlde yanlış tip seçmekten kaçının.
Aynı sitede 3 rollout sırasını karşılaştırdık: en hızlı kazanım hangisi?
Saha uygulamalarında tekrar gördüğümüz desen net: önce Breadcrumb + Organization ile başlayan rollout’lar, Product ya da Article ile başlayan rollout’lara göre daha az sürpriz üretir. Bunun sebebi bu iki türün hem veri ihtiyacının daha temiz olması hem de çok daha geniş şablon alanına yayılmasıdır. Search Console tarafında kapsama raporlarının daha hızlı dolması, hata kümelerinin daha anlaşılır ayrışması ve geliştirici ekibin ilk sprintte daha az geri dönüş yaşaması genellikle bu sırada gerçekleşir.
İkinci senaryoda önce Product veya Article ile başlamak, doğru veri yapısı hazırsa güçlü olabilir; ancak eksik teklif alanları, dağınık editoryal şablonlar veya tutarsız breadcrumb zincirleri varsa rollout’un ilk ayı daha gürültülü geçer. Üçüncü senaryoda ilk faza FAQPage ya da HowTo almak ise çoğu zaman beklentiyi yanlış yere taşır; çünkü bu türler sayfa niyetine daha bağımlıdır ve görünür içerik disiplini bozulduğunda hata veya uygunluk riski hızla yükselir.
Kendi rollout planlarımızda bu yüzden basit bir kural kullanıyoruz: ilk 30 günde kapsama ve hata temizliği hedeflenir, CTR artışı ikinci fazın ödülü olarak görülür. Önce kimlik ve gezinme şemalarını kurmak, ardından ticari veya editoryal şablonlara geçmek, ekiplerin neden-sonuç ilişkisini daha temiz okumasını sağlar. Zengin sonuç uygunluğu erken gelebilir; ancak asıl fark, hangi markup’ın gerçekten sürdürülebilir olduğunu daha net görmektir.
SEOYEN ile rollout sonrası izleme: hata, CTR ve rakip farkı
Schema rollout tamamlandıktan sonra iş bitmez; asıl değer, etkinin diğer SEO sinyallerinden ayrıştırılmasında ortaya çıkar. Bunun için rich result uygunluğunu tek başına okumak yerine, sıralama takibi, sayfa bazlı hata kümeleri, içerik şablonu davranışı ve gerektiğinde AI görünürlük analizi birlikte izlenmelidir. Bazı sayfalarda markup doğru çalışır ama performans değişimi zayıf kalır; o durumda problem schema değil, sorgu niyeti veya içerik rekabetidir.
Bağlantı otoritesi de tabloyu etkiler. Özellikle ürün ve rehber sayfalarında markup yayına alındıktan sonra geri bağlantı analizi ile destek profiline bakmak, CTR değişimini daha doğru yorumlamayı sağlar. Tek panelden çalışan bir yapı burada avantaj yaratır: teknik sinyal, pozisyon verisi ve görünürlük katmanı aynı iş akışında birleştiğinde rollout’un gerçekten ne kazandırdığını okumak kolaylaşır.
Bu noktada SEOYEN’in farkı, yalnızca bir rapor ekranı sunması değil; tek platformda tüm SEO araçlarını, Türkçe arayüzü, TL bazlı fiyatlandırmayı ve yerel Türkçe desteği aynı operasyona bağlamasıdır. Bir Ahrefs alternatifi ya da SEMrush alternatifi arayan ekipler için kritik fark, global araç mantığını Türkiye pazarı için daha uygulanabilir bir iş akışına çevirmesidir. Paket yapısını merak edenler için sabit rakam vermek yerine doğrudan fiyat ve paketler sayfasına bakmak daha doğru olur.
Adım Adım Schema rollout önceliği belirleme süreci
Aşağıdaki akış, sınırlı geliştirme kaynağı olan ekiplerde en az sürtünmeyle çalışan karar modelidir. Amaç tüm türleri aynı anda işaretlemek değil; hangi sayfada hangi schema’nın gerçekten görünürlük ve ölçüm avantajı getireceğini kontrollü biçimde seçmektir.
- Sayfa şablonlarını ve iş hedeflerini çıkar: Ana sayfa, kategori, ürün, blog, iletişim ve lokasyon gibi şablonları listeleyin. Her biri için trafik, dönüşüm, marka doğrulama veya yerel görünürlük hedefini netleştirin.
- Google destekli schema türlerini haritalandır: Schema.org’daki tüm seçeneklere değil, Google’ın fiilen desteklediği türlere bakın. Her şablon için görünür içerikle gerçekten eşleşen birincil schema adayını belirleyin.
- Etki ve efor puanı ver: Beklenen rich result fırsatı, geliştirme süresi, veri hazırlığı ve şablon yayılımına göre her türü puanlayın. Çok sayfada uygulanabilen düşük eforlu türler ilk fazı kazanır.
- JSON-LD ile minimum alanları yayına al: Required alanları eksiksiz, kritik recommended alanları ise sürdürülebilir seviyede ekleyin. İlk fazda kusursuz kapsam yerine temiz ve tutarlı markup daha değerlidir.
- Rich Results Test ve Search Console ile doğrula: Sayfa bazlı uygunluğu test edin, ardından Search Console raporlarında hata ve uyarı kümelerini izleyin. Teknik sağlık sinyalleriyle çapraz kontrol yapın.
- CTR ve kapsama verisiyle ikinci fazı seç: İlk 30 günlük sonuçlara göre Product, Article, FAQPage veya HowTo için ikinci dalgayı belirleyin. Ölçüm, yeni tür eklemenin gerçekten değer üretip üretmediğini göstermelidir.
Bu akışın özeti şudur: önce yaygın, temiz ve destekli türleri devreye alın; sonra daha seçici schema’ları gerçek performans verisiyle sıraya koyun. Böylece schema çalışması, rastgele bir checklist olmaktan çıkıp kontrollü bir SEO rollout’una dönüşür.
| Schema türü | Öncelik seviyesi | İlk uygulanacak sayfa tipi | Beklenen görünürlük fırsatı | Risk notu |
|---|---|---|---|---|
| BreadcrumbList | Çok yüksek | Tüm site şablonları | Site hiyerarşisini netleştirme ve geniş kapsama | Yanlış breadcrumb zinciri tutarsızlık yaratır |
| Organization | Yüksek | Kurumsal ana sayfa ve marka sayfaları | Marka kimliği ve bilgi paneli sinyalleri | Eksik kurum bilgisi düşük kalite sinyali verir |
| LocalBusiness | Yüksek | Lokasyon ve iletişim sayfaları | Yerel işletme detayları ve yerel niyet uyumu | Adres ve saatler görünür değilse risklidir |
| Product | Orta-yüksek | Ürün detay sayfaları | Fiyat, stok ve teklif görünürlüğü | Eksik Offer alanları ve zayıf veri sık hata üretir |
| Article | Orta-yüksek | Blog, rehber ve haber sayfaları | İçerik keşfi ve zengin görünüm uygunluğu | Dağınık editoryal şablonlar tutarlılığı bozar |
| FAQPage | Orta | Gerçek soru-cevap sayfaları | FAQ rich result uygunluğu | Yapay soru blokları kalite riskidir |
| HowTo | Düşük-orta | Adım adım kılavuz sayfaları | Niş kullanım ve ikincil anlamlandırma | 2026’da ilk faz için zayıf görünürlük gerekçesi |
Kaynaklar
Sıkça Sorulan Sorular
İlk uygulama, hem görünürlük fırsatı yüksek hem de çok sayfaya yayılabilen şablonlarda başlamalıdır. Bu yüzden çoğu sitede ilk adaylar breadcrumb yapısı olan temel şablonlar ve kurumsal kimlik sayfalarıdır. E-ticarette ürün şablonları da erken sıraya girebilir. ancak veri kalitesi zayıfsa önce BreadcrumbList ve Organization ya da LocalBusiness ile başlamak daha güvenlidir. Doğru cevap tek bir URL tipi değildir. en geniş kapsama, en düşük efor ve en net Google desteği hangi sayfadaysa ilk rollout oradan başlar.
Sıra, dört ana değişkenle belirlenmelidir: sayfa tipi, iş hedefi, Google desteği ve uygulama eforu. Önce hangi şablonun gelir, trafik veya marka görünürlüğüne en çok etki ettiğini çıkarın. Ardından yalnızca Google’ın fiilen desteklediği schema türlerini eşleştirin. Üçüncü adımda required alanların hazır olup olmadığına bakın. veri yoksa o schema erkene alınmamalıdır. Son olarak geliştirme maliyetini puanlayın. Bu yaklaşım genelde BreadcrumbList ve Organization veya LocalBusiness’ı ilk sıraya, Product veya Article’ı ikinci sıraya taşır.
Evrensel tek bir “en önemli schema” yoktur. öncelik site modeline göre değişir. Yine de çok sayfalı sitelerde BreadcrumbList çoğu zaman en düşük eforlu ve en geniş etkili başlangıçtır. Kurumsal yapılarda buna Organization, yerel işletmelerde LocalBusiness eklenir. E-ticarette Product, içerik yayıncılarında Article daha erken değer üretir. FAQPage ve HowTo ise genellikle ilk faz için değil, sayfa niyeti netse ikinci faz için uygundur. En öncelikli schema, desteklenen, görünür içerikle uyumlu ve sürdürülebilir olandır.
Bazı arama görünümleri sınırlı ölçüde structured data olmadan da oluşabilir. ancak çoğu rich result türünde uygun markup, görünür içerik uyumu ve politika uyumu gerekir. Üstelik markup eklemek tek başına gösterim garantisi vermez. Google, doğru schema’nın sayfayı rich result için uygun hâle getirebileceğini söyler. fakat gösterimin oluşup oluşmaması sorgu, kalite, cihaz ve arama bağlamına göre değişir. Bu nedenle schema’yı “garanti görünürlük” aracı değil, uygunluk ve anlamlandırma altyapısı olarak görmek daha doğrudur.
Organization schema, markanın veya kurumun genel kimliğini tanımlar. Logo, resmi ad, iletişim bilgileri ve şirket tanımlayıcıları gibi üst düzey kurumsal sinyaller burada taşınır. LocalBusiness ise fiziksel konumu olan işletmeler için daha yerel bir modeldir. adres, çalışma saatleri, lokasyon ve hizmet verilen yer gibi detayları ön plana çıkarır. Şubesi olmayan SaaS veya kurumsal yapılarda Organization genelde yeterlidir. Mağaza, klinik, restoran veya ofis ağı gibi lokasyon odaklı yapılarda LocalBusiness daha erken öncelik kazanır.
Öncelik görünürlük isteğine göre değil, sayfanın gerçek niyetine göre verilmelidir. Sayfa açık biçimde soru-cevap yapısındaysa ve tüm sorular ile yanıtlar görünür durumdaysa FAQPage daha doğal seçimdir. Sayfa adım adım yapılacak işi anlatıyorsa, her adım sayfada yer alıyorsa ve içerik gerçekten prosedürelse HowTo düşünülür. 2026’da güvenli yaklaşım, FAQPage’i sadece gerçek FAQ sayfalarında kullanmak. HowTo’yu ise ilk faz yerine daha seçici ikinci faz schema olarak ele almaktır. Yanlış tür seçmek, hiç schema kullanmamaktan daha sorunlu olabilir.
Varsayılan tercih JSON-LD olmalıdır. Google, JSON-LD’yi önerilen format olarak gösterir. çünkü uygulaması ve bakımı daha kolaydır, özellikle büyük şablon yapılarında hata ayıklaması daha nettir. Microdata teknik olarak desteklenir ve bazı CMS yapılarda kullanışlı olabilir. ancak HTML içine dağılmış alanlar nedeniyle sürüm takibi ve denetim daha zorlaşır. Eğer özel bir teknik zorunluluk yoksa rollout’u JSON-LD ile kurmak, ölçeklendirme ve kalite kontrol açısından daha temiz bir operasyondur.