Sağlık Sektörü SEO Şema Yapısı - Tam Rehber

1. Yapılandırılmış Veri ve Şema İşaretlemesi Nedir?

Yapılandırılmış veri, bir web sayfasındaki bilgilerin yalnızca insanlar tarafından değil, arama motorları ve diğer makine tabanlı sistemler tarafından da daha açık biçimde anlaşılmasını sağlayan standartlaştırılmış bir tanımlama yöntemidir. Schema.org sözlüğü; kurum, klinik, doktor, hizmet, makale, etkinlik, ürün ve çok sayıda başka varlığı tanımlamak için ortak bir dil sunar.

Sağlık sektöründe şema işaretlemesinin amacı, sayfayı anahtar kelimelerle doldurmak veya arama sonucunda özel görünüm elde etmeyi garanti etmek değildir. Asıl amaç; “Bu kurum kimdir?”, “Bu doktor hangi uzmanlık alanında çalışır?”, “Bu hizmeti kim sunuyor?”, “Bu içerik kim tarafından ve ne zaman yayımlandı?” gibi temel sorulara tutarlı makine sinyalleri vermektir.

Yönetici özeti: Şema, sıralama garantisi değildir. Doğru uygulandığında sayfanın anlamını, varlık ilişkilerini ve yayın bağlamını daha açık hale getirir.

Yapılandırılmış veri ne yapar, ne yapmaz?

2. Sağlık Sitelerinde Varlık ve Kimlik Mimarisi

Profesyonel sağlık şema yapısının merkezinde tek tek etiketler değil, varlık ilişkileri bulunur. Ana marka bir Organization veya uygun olduğunda MedicalOrganization kimliğiyle tanımlanır. Klinik sayfaları MedicalClinic, doktor profilleri Physician, hizmet sayfaları Service veya gerçek içerikle örtüşen sağlık türleri, blog içerikleri ise Article ya da uygun sayfalarda MedicalWebPage ile açıklanabilir.

@id neden önemlidir?

@id, farklı sayfalardaki aynı varlığın tek bir kimlik altında bağlanmasını sağlar. Örneğin ana marka için https://ornek.com/#organization, klinik için https://ornek.com/#clinic ve doktor için https://ornek.com/doktor/adi-soyadi#physician gibi kalıcı kimlikler kullanılabilir. Bu kimlikler gelişi güzel değiştirilmemeli, site genelinde tutarlı kalmalıdır.

Örnek varlık zinciri

• Organization: markanın kurumsal kimliği
• MedicalClinic: sağlık hizmeti sunulan fiziksel veya kurumsal yapı
• Physician: doktor profili ve uzmanlık bağlamı
• Service: sunulan hizmetin kapsamı
• Article: editoryal içerik ve yazar ilişkisi
• BreadcrumbList: sayfanın site hiyerarşisindeki konumu

3. Organization Şeması Nasıl Kullanılır?

Organization, markanın dijital kimliğini tanımlayan temel türlerden biridir. Genellikle ana sayfada veya kurumsal kimliğin merkez olduğu sayfada kullanılır. İsim, logo, web adresi, iletişim bilgileri, sosyal profiller ve varsa yasal tanımlayıcılar bu yapı içinde düzenlenebilir.

Temel alanlar

• @id ve url
• name ve varsa alternateName
• logo
• contactPoint
• sameAs
• address ve uygun olduğunda areaServed

sameAs alanına yalnızca gerçekten markayı temsil eden resmî profiller eklenmelidir. Alakasız dizinler, kontrol edilmeyen sayfalar veya yalnızca bağlantı sayısını artırmak için eklenen URL’ler varlık tutarlılığını zayıflatabilir.

Organization ile MedicalOrganization farkı

Her sağlık markası otomatik olarak aynı türle tanımlanmaz. Bir dijital ajans, yazılım firması veya sağlık turizmi danışmanlığı çoğu zaman Organization ya da daha spesifik ticari türlerle açıklanırken; doğrudan sağlık hizmeti sunan kurumlar için MedicalOrganization, Hospital veya MedicalClinic gibi daha uygun türler değerlendirilebilir.

4. MedicalOrganization ve Sağlık Kurumu Kimliği

MedicalOrganization, sağlık hizmeti sunan kurumsal yapılar için kullanılan Schema.org türlerinden biridir. Hastane, klinik, laboratuvar, eczane ve doktor kuruluşları gibi daha spesifik alt türler bu hiyerarşi içinde yer alır.

Hangi durumda kullanılmalı?

• Kurum doğrudan sağlık hizmeti sunuyorsa
• Sayfa gerçek bir sağlık kuruluşunu tanımlıyorsa
• Uzmanlık, hizmet ve sağlık personeli ilişkileri görünür içerikte yer alıyorsa

Hangi durumda kullanılmamalı?

• Sağlık sektörüne hizmet veren ancak sağlık hizmeti sunmayan ajanslarda
• Yalnızca reklam veya danışmanlık hizmeti veren şirketlerde
• Sayfada görünmeyen tıbbi uzmanlıkları varmış gibi göstermek için

Şema türü seçimi, marka algısına göre değil işletmenin gerçek işlevine ve sayfanın görünen içeriğine göre yapılmalıdır.

5. MedicalClinic Şeması: Klinik Sayfalarının Temel Yapısı

MedicalClinic, belirli bir konumda veya kurumsal yapı altında sağlık hizmeti sunan klinikleri tanımlamak için kullanılabilir. Klinik ana sayfası, lokasyon sayfası veya gerçek klinik profil sayfası bu tür için uygun adaylardır.

Klinik şemasında önemli bilgiler

• Klinik adı ve kalıcı kimliği
• Adres, telefon ve çalışma saatleri
• Sunulan uzmanlık alanları
• Hizmet verilen diller
• Resmî web adresi ve logo
• Varsa ilişkili doktorlar
• Gerçekten sunulan sağlık hizmetleri

Çok lokasyonlu kliniklerde her lokasyonun ayrı URL ve ayrı kimlikle tanımlanması; ana markayla parentOrganization veya uygun ilişki alanları üzerinden bağlanması daha temiz bir yapı sağlayabilir.

Yerel SEO ile ilişki

MedicalClinic işaretlemesi, yanlış adres veya tutarsız telefon bilgisini telafi etmez. Web sitesi, Google İşletme Profili ve diğer resmî kaynaklardaki isim, adres ve telefon bilgilerinin tutarlı olması gerekir.

6. Physician Şeması: Doktor Profilleri Nasıl Tanımlanmalı?

Doktor profil sayfaları, sağlık sitelerinin en kritik güven varlıkları arasındadır. Physician türü; doktorun adı, uzmanlığı, çalıştığı kurum, profil URL’si ve uygun diğer bilgilerle ilişkilendirilebilir.

Doktor profilinde görünür olması gerekenler

• Ad ve soyad
• Uzmanlık alanı
• Eğitim ve mesleki deneyim özeti
• Çalıştığı klinik veya hastane
• Hizmet verdiği diller
• Gerçek ve güncel profil fotoğrafı
• İçeriğin son kontrol veya güncelleme tarihi

Şema içinde verilen unvan, uzmanlık ve kurum bilgileri sayfada da kullanıcıya görünmelidir. Gizli, şişirilmiş veya doğrulanamayan bilgiler kalite kurallarına aykırıdır.

Yazar ile tıbbi inceleyen kişi ayrımı

Bir makaleyi editör yazmış, doktor tıbbi doğruluk açısından incelemiş olabilir. Bu durumda içerik üretim süreci sayfada açıkça anlatılmalı; author, reviewedBy veya kullanılan yayın sistemine uygun alanlar, gerçek rolleri yansıtacak şekilde planlanmalıdır.

7. Service ve Sağlık Hizmeti Sayfaları

Hizmet sayfalarında en sık yapılan hata, her tedaviyi doğrudan MedicalProcedure olarak işaretlemektir. Oysa sayfanın gerçekten ne anlattığı önemlidir. Bir kurumun sunduğu ticari hizmet için Service; gerçek bir tıbbi prosedür hakkında ayrıntılı bilgi veren ve bağlamı uygun olan sayfalarda ise Schema.org sağlık türleri değerlendirilebilir.

Service şemasında planlanabilecek alanlar

• name ve description
• provider
• areaServed
• serviceType
• audience
• availableChannel veya uygun iletişim bilgileri

Fiyat, garanti, tedavi sonucu veya tıbbi başarı gibi hassas bilgiler şemaya eklenmeden önce hem görünür içerikle hem de sağlık iletişimi kurallarıyla uyumu değerlendirilmelidir.

8. Article, BlogPosting ve MedicalWebPage Kullanımı

Sağlık bloglarında Article veya daha spesifik olarak BlogPosting; yazar, yayın tarihi, güncelleme tarihi, başlık ve görsel gibi editoryal bilgileri tanımlamak için kullanılabilir. Tıbbi bilgi sağlayan bazı sayfalarda MedicalWebPage türü de içerik bağlamına göre değerlendirilebilir.

Article için temel editoryal sinyaller

• headline
• author
• datePublished ve dateModified
• image
• publisher
• mainEntityOfPage
• articleSection ve uygun olduğunda wordCount

MedicalWebPage ne zaman düşünülebilir?

Sayfa tıbbi bilgi veriyorsa, hedef kitlesi ve son tıbbi inceleme tarihi gibi alanların anlamlı olduğu durumlarda MedicalWebPage değerlendirilebilir. Ancak türün eklenmesi içeriği otomatik olarak güvenilir yapmaz. Uzman incelemesi, kaynaklandırma, güncellik ve kullanıcıya sunulan açıklık yine esastır.

Yayın tarihi ile güncelleme tarihi

İçerik gerçekten güncellendiğinde dateModified değiştirilmelidir. Yalnızca taze görünmek için tarih değiştirmek yerine hangi bölümlerin güncellendiğini sayfada açıklamak daha güvenilir bir yayın standardı oluşturur.

9. BreadcrumbList, WebSite ve WebPage Katmanı

BreadcrumbList, sayfanın site hiyerarşisindeki yerini tanımlar. Kullanıcının gördüğü kırıntı gezinme ile şema çıktısı aynı yolu yansıtmalıdır.

Örnek hiyerarşi

Ana Sayfa → Hizmetler → Çok Dilli SEO veya Ana Sayfa → Blog → Sağlık Sektörü SEO Şema Yapısı

WebSite alan adının bütününü, WebPage ise tek bir sayfayı temsil eder. Ana varlık, yayıncı kurum ve sayfa kimliği arasında tutarlı bağlantılar kurmak; aynı kuruluşu farklı isim ve kimliklerle tekrar tekrar üretmekten daha sağlıklıdır.

Kanonik URL ile uyum

Şemadaki sayfa URL’si, @id, mainEntityOfPage ve kanonik URL birbiriyle çelişmemelidir. HTTP/HTTPS, www kullanımı, sondaki eğik çizgi ve dil klasörleri gibi ayrıntılar site standardına göre tutarlı tutulmalıdır.

10. FAQPage Şeması Sağlık Sitelerinde Nasıl Kullanılmalı?

FAQPage, sayfada kurum tarafından hazırlanmış ve kullanıcılara görünür soru-cevap bölümü bulunduğunda kullanılabilir. Ancak Google’ın FAQ zengin sonuçlarını sınırlı biçimde göstermesi nedeniyle bu işaretleme yalnızca “arama sonucunda daha fazla alan kaplamak” amacıyla uygulanmamalıdır.

Doğru kullanım ilkeleri

• Sorular ve yanıtlar sayfada kullanıcıya görünür olmalı
• Yanıtlar sayfanın ana konusuyla ilgili olmalı
• Tıbbi iddialar uzman kontrolünden geçmeli
• Aynı SSS bütün sayfalara kopyalanmamalı
• Forum veya kullanıcı cevapları için FAQ yerine uygun Q&A yapısı düşünülmeli

FAQ şeması geçerli olsa bile zengin sonuç görünümü garanti edilmez. Bu nedenle SSS bölümü öncelikle kullanıcı deneyimi ve içerik bütünlüğü için hazırlanmalıdır.

11. JSON-LD ile Uygulama Standardı

Google, yapılandırılmış veri için JSON-LD biçimini önerir. JSON-LD, HTML içeriğinin içine gömülen ve genellikle <script type="application/ld+json"> etiketi içinde sunulan JavaScript nesne gösterimidir.

Basitleştirilmiş klinik örneği

{
  "@context": "https://schema.org",
  "@type": "MedicalClinic",
  "@id": "https://ornek.com/#clinic",
  "name": "Örnek Klinik",
  "url": "https://ornek.com/",
  "medicalSpecialty": "Dentistry",
  "parentOrganization": {
    "@id": "https://ornek.com/#organization"
  }
}

@graph yaklaşımı

Bir sayfada birbiriyle ilişkili birden fazla varlık varsa @graph kullanılarak Organization, WebSite, WebPage, BreadcrumbList ve sayfaya özel ana varlık aynı JSON-LD belgesi içinde bağlanabilir. Bu yaklaşım tek zorunlu yöntem değildir; ancak kimlik ilişkilerini merkezi biçimde yönetmeyi kolaylaştırabilir.

Dinamik CMS yapısı

Şema çıktısı içerik yönetim sisteminde otomatik üretiliyorsa boş alanlar, varsayılan metinler ve yanlış türler kontrol edilmelidir. Her sayfaya aynı şema bloğunu kopyalamak yerine içerik türüne göre değişen bir üretim mantığı kurulmalıdır.

12. Test, Doğrulama ve Yayın Sonrası Kontrol

Yapılandırılmış veri yayınlanmadan önce en az iki farklı açıdan test edilmelidir: Google’ın desteklediği zengin sonuç özellikleri için Rich Results Test ve genel Schema.org söz dizimi için Schema Markup Validator.

Kontrol sırası

1. JSON sözdizimini doğrulayın.
2. Zorunlu ve önerilen alanları inceleyin.
3. İşaretlenen bilgilerin sayfada göründüğünü kontrol edin.
4. Kanonik, robots ve HTTP durum kodunu doğrulayın.
5. Canlı URL’yi Rich Results Test ile test edin.
6. Search Console URL Inspection ile render ve indeks durumunu inceleyin.
7. Tema veya içerik güncellemesinden sonra yeniden test edin.

Hata ile uyarı arasındaki fark

Kritik hatalar çoğu zaman ilgili zengin sonuç özelliği için uygunluğu engeller. Uyarılar ise her durumda zorunlu olmayabilir; ancak veri kalitesini geliştirmek için değerlendirilmelidir. Her uyarıyı anlamsız veriyle doldurmak yerine yalnızca gerçek ve görünür bilgi eklenmelidir.

13. Sağlık Sitelerinde En Sık Görülen Şema Hataları

1. Ajansı veya aracı şirketi yanlışlıkla MedicalClinic olarak tanımlamak
2. Her sayfaya aynı Organization ve Service bloğunu kopyalamak
3. Doktor profilinde görünmeyen uzmanlıkları şemaya eklemek
4. Sahte veya kurumun kendi kendine verdiği puanları AggregateRating ile işaretlemek
5. Kullanıcıya görünmeyen SSS içeriklerini JSON-LD’ye koymak
6. Kanonik URL ile şemadaki URL’yi farklı kullanmak
7. Bir varlık için sayfadan sayfaya değişen @id üretmek
8. Çok dilli sayfalarda yanlış dil veya yanlış URL ilişkisi kurmak
9. Yayın tarihi ve güncelleme tarihini gerçeğe aykırı değiştirmek
10. Şema doğrulamasını yalnızca ilk kurulumda yapmak
11. MedicalProcedure türünü hizmet pazarlama sayfalarında bağlamsız kullanmak
12. Şema ekleyerek kalite, uzmanlık ve güven eksiklerini çözmeye çalışmak

14. İlk 90 Günlük Sağlık Şema Uygulama Planı

1–30. gün: Envanter ve kimlik modeli

• Tüm sayfa türlerini ve mevcut şema çıktılarını listeleyin.
• Ana Organization, klinik, doktor ve hizmet kimliklerini tanımlayın.
• Kanonik URL, dil ve lokasyon standartlarını belirleyin.
• Yanlış veya yinelenen şemaları tespit edin.

31–60. gün: Şablon ve entegrasyon

• Ana sayfa, klinik, doktor, hizmet ve blog şablonlarını oluşturun.
• @id ilişkilerini ortak üretim sistemine bağlayın.
• Breadcrumb, Article ve sayfa türü çıktılarını otomatikleştirin.
• Görünür içerik ile JSON-LD alanlarını eşleştirin.

61–90. gün: Test ve yönetişim

• Öncelikli URL’leri Rich Results Test ve Validator ile kontrol edin.
• Search Console hata ve tarama raporlarını izleyin.
• Editör ve teknik ekip için yayın kontrol listesi oluşturun.
• Üç aylık şema denetim takvimini başlatın.

Yayın öncesi son kontrol listesi

• Şema türü sayfanın gerçek içeriğiyle uyumlu mu?
• İşaretlenen tüm bilgiler kullanıcıya görünür mü?
• @id değerleri site genelinde tutarlı mı?
• Kanonik ve şema URL’si aynı standardı mı kullanıyor?
• Yazar, doktor ve yayıncı rolleri doğru mu?
• Test araçlarında kritik hata bulunuyor mu?

Sonuç: Sağlık Şema Yapısı Bir Kod Parçası Değil, Bilgi Mimarisi Kararıdır

Sağlık sektörü için doğru şema yapısı; klinik, doktor, hizmet, içerik ve kurumsal marka arasındaki ilişkileri açık biçimde tanımlar. Başarılı uygulama, çok sayıda tür kullanmakla değil; doğru varlıkları görünür içerikle uyumlu, kalıcı kimliklerle ve doğrulanabilir bilgilerle bağlamakla mümkündür.

Şema stratejisi teknik SEO, içerik yönetimi ve marka yönetişimiyle birlikte ele alındığında sürdürülebilir hale gelir. Bu nedenle yapılandırılmış veri çalışması, tek seferlik eklenti kurulumu değil; site mimarisinin ve yayın süreçlerinin sürekli kontrol edilen bir parçası olmalıdır.

Resmî teknik kaynaklar

• Google: Yapılandırılmış veriye giriş
• Google: Genel yapılandırılmış veri kuralları
• Google: Desteklenen yapılandırılmış veri özellikleri
• Schema.org: MedicalOrganization
• Schema.org: MedicalClinic
• Schema.org: Physician