Örnek Çalışma: Doktor Schema Haritası Nasıl Kurulur?

Ö

Dört Ayrı Gerçeklik: Kişi, Klinik, Hizmet, Tıbbi Prosedür

Doktor sitelerinde en sık gördüğüm hata, her şeyi tek bir Organization ya da LocalBusiness nesnesinin içine doldurmaktır. Oysa ortada dört ayrı gerçeklik vardır ve bunlar birbirinin içinde erimez:

• Kişi: Doktorun kendisi. Person tipiyle tanımlanır.
• Yer: Kliniğin fiziksel konumu. MedicalClinic tipiyle tanımlanır.
• Hizmet: Kurumun sunduğu ticari hizmet. Service tipiyle tanımlanır.
• Tıbbi kavram: Prosedürün tıbbi tanımı. MedicalProcedure veya SurgicalProcedure tipiyle tanımlanır.

Bunu bir arşiv gibi düşünüyorum. Doktorun özlük dosyası ayrı, kliniğin işletme kaydı ayrı, danışana sunulan hizmet ayrı, prosedürün tıbbi tanımı ayrı. Bu dosyalar birbirinin içine geçmez, @id referanslarıyla birbirine bağlanır. Bu ayrımın doğrudan karşılığı olan bir örnek: rinoplasti tıbbi bir prosedür olarak tanımlanır (SurgicalProcedure), Meridyen Klinik’in sunduğu rinoplasti hizmeti ise ayrı bir varlıktır (Service). Biri “rinoplasti nedir” sorusuna, diğeri “bu kurum rinoplastiyi nasıl sunuyor” sorusuna cevap verir.

Sabit @id Sözleşmesi Nasıl Kurulur

Aynı gerçek varlık, sitenin her yerinde aynı @id ile anılmalıdır. Rinoplasti prosedürü ana sayfada, tedavi sayfasında ve ilgili blog yazısında üç kez yeniden tanımlanmaz; bir kez tanımlanır, diğer yerlerden ona referans verilir.

{
  "@type": "SurgicalProcedure",
  "@id": "https://ornek-klinik.com/tedaviler/rinoplasti/#procedure",
  "name": "Rinoplasti"
}

Aynı prosedüre başka bir sayfadan bağlanmak için tüm alanları tekrar yazmaya gerek yok, sadece referans veriliyor:

{ "about": { "@id": "https://ornek-klinik.com/tedaviler/rinoplasti/#procedure" } }

Bu, sitenin bilgi grafiğinin omurgasıdır. Marka varlık optimizasyonu yazımda anlattığım entity SEO mantığının teknik karşılığı da tam olarak budur: markanın, kliniklerin, doktorların ve hizmetlerin sitede tutarlı ve tekil kimliklerle var olması.

Bu tekilliği ölçekte korumanın en pratik yolu, en baştan bir fragment sözleşmesi belirlemektir. Yeni bir klinik, doktor veya tedavi eklendiğinde aynı desen tekrarlanır; böylece hangi varlığın @id’sinin nasıl kurulacağı hiç tartışma konusu olmaz:

Örnek Senaryo: İki Klinik, Üç Doktor

Meridyen Klinik’in İstanbul’da merkez, İzmir’de şube kliniği var. Üç doktor farklı kliniklerde ve farklı odaklarla çalışıyor:

Klinikler markaya parentOrganization ile bağlanır, marka da her iki kliniğe subOrganization ile referans verir. Doktorlar worksFor ile markaya, practicesAt ile çalıştıkları kliniğe bağlanır; practicesAt, v24 ile gelen ve yalnızca IndividualPhysician’da bulunan tıbbi bağ özelliğidir. Rinoplasti hizmeti her iki klinikte de sunulduğu için, her iki MedicalClinic’in availableService alanı aynı prosedüre işaret eder; prosedür tek, sunum noktası iki.

Çalışan Doktor Profilinde Hangi Tip Kullanılmalı

Physician tipi schema.org’da uzun süre kafa karıştırıcı bir yapıya sahipti: hem bireysel doktoru hem de doktor ofisini temsil edebiliyordu ve Organization, LocalBusiness gibi işletme tiplerinden türüyordu. Schema.org bu karışıklığı kendisi de fark etti ve 9 Ocak 2024’teki v24 güncellemesiyle Physician’ı ikiye ayırdı: kişiyi temsil eden IndividualPhysician ve kliniği temsil eden PhysiciansOffice.

Kurumsal bir markanın çalışanı olan doktor için pratik sonuç şu: temel tip olarak Person yeterli ve güvenli. medicalSpecialty gibi doktora özgü tıbbi alanlara ihtiyaç varsa, Person’a ek olarak IndividualPhysician tipi de eklenebilir.

{
  "@type": ["Person", "IndividualPhysician"],
  "name": "Kerem Aydın",
  "medicalSpecialty": "https://schema.org/PlasticSurgery",
  "practicesAt": { "@id": "https://ornek-klinik.com/klinik/istanbul/#clinic" }
}

Peki neden ["Person", "IndividualPhysician"] gibi iki tip birden? Çünkü medicalSpecialty gibi tıbbi özelliklerin geçerlilik alanı (domain) düz Person’ı içermez; düğüme IndividualPhysician tipini eklemek, bu özelliği o kişi düğümünde meşru kılan şeydir. Yani bu birleşim dağınıklık değil, tıbbi alanları kişiye bağlamanın temiz yoludur. IndividualPhysician’ın üst tip zincirinin Person değil MedicalOrganization tarafından geldiğini not edin; pratikte doğrulayıcılar bu birleşime hata vermez, ama ontolojik olarak neden iki tip kullandığınızı bilerek kurmanız gerekir.

Bağımsız bir muayenehanesi olan, kurumsal bir markanın çalışanı olmayan doktor için durum farklı: o zaman doktorun kendisi aynı zamanda bir işletme entity’si olduğundan PhysiciansOffice veya MedicalClinic tipi düşünülebilir. Ama üç doktoru bir markanın çatısı altında çalışan bir klinikte, her doktoru otomatik olarak Physician yazmak, kişiyle işletmeyi aynı nesnede eritmek anlamına gelir.

Küçük bir güncel not: Schema.org, sonraki v26 sürümünde v24’te yanlışlıkla atlanan PhysiciansOffice’i tekrar MedicalBusiness alt tipi olarak tanımladı. Kişiyi Person, kliniği MedicalClinic ile tanımlama pratiğini bu değişiklik etkilemez; yalnızca PhysiciansOffice tercih ederseniz tip zincirinin güncel halini bilmiş olursunuz.

Bir uyarı daha: v24, Physician tipine ABD’ye özgü usNPI (National Provider Identifier) alanını da ekledi. Bu on haneli numara yalnızca ABD sağlık sistemine kayıtlı sağlayıcılar için geçerli; Türkiye’deki bir hekim için karşılığı yok, dolayısıyla bu alan boş bırakılır. Türkiye bağlamında kimlik güvenini usNPI değil, aşağıda anlattığım hasCredential ve gerçek dış profillere işaret eden sameAs taşır.

Sertifika ve Diploma: hasCredential ile Modelleme

Hekimin diplomasını, uzmanlık belgesini veya board sertifikasını schema’ya taşımanın doğru yolu hasCredential özelliğidir; değeri bir EducationalOccupationalCredential nesnesidir. Bu, doktor E-E-A-T sinyalinin yapısal karşılığıdır. Tek koşul şu: belge sayfada gerçekten görünür olmalı. Görünmeyen bir sertifikayı yalnızca şemaya yazmak, ilerideki bölümde değindiğim en riskli hatalardan biridir.

{
  "@type": ["Person", "IndividualPhysician"],
  "@id": "https://ornek-klinik.com/ekip/kerem-aydin/#physician",
  "name": "Kerem Aydın",
  "medicalSpecialty": "https://schema.org/PlasticSurgery",
  "practicesAt": { "@id": "https://ornek-klinik.com/klinik/istanbul/#clinic" },
  "hasCredential": {
    "@type": "EducationalOccupationalCredential",
    "credentialCategory": "Uzmanlık Belgesi",
    "recognizedBy": {
      "@type": "Organization",
      "name": "Sağlık Bakanlığı"
    }
  }
}

Çok Dilli Sitelerde Değişen ve Değişmeyen Varlıklar

Türkçe ve İngilizce sayfalar aynı gerçek kurumu, kliniği, doktoru ve hizmeti anlatıyorsa, bunların kimliği dile göre değişmez. Değişen tek şey, o varlığı anlatan içerik düğümleridir.

İki dildeki sayfa arasındaki bağ translationOfWork ve workTranslation özellikleriyle kurulur. Ama şema tek başına çok dilli SEO yapmaz; HTML tarafında karşılıklı hreflang etiketleri ve her sayfada self-canonical bulunması gerekir. Schema, entity’nin kim olduğunu; hreflang ise hangi dil sürümünün hangi bölgeye hitap ettiğini taşır. Biri diğerinin yerine geçmez.

<link rel="alternate" hreflang="tr-TR" href="https://ornek-klinik.com/tedaviler/rinoplasti/">
<link rel="alternate" hreflang="en-GB" href="https://ornek-klinik.com/en/treatments/rhinoplasty/">

Birleşik Krallık Gibi Bir Hedefte Sık Yapılan Hata

Uluslararası bir hedef kitle belirlendiğinde en sık görülen refleks şu: hedef ülkede sahte bir adres, hatta sahte bir klinik varlığı oluşturmak. Bu yanlış, çünkü şema gerçek dünyayı temsil etmek zorunda; olmayan bir fiziksel konum yaratmak hem Google’ın structured data ilkelerine hem de gerçekliğe aykırı.

Doğru ayrım şu üç satırda:

• Hizmetin fiziksel konumu: Türkiye, İstanbul ve İzmir klinikleri.
• Hizmetin hedef kitlesi: Birleşik Krallık, audience.geographicArea ile işaretlenir.
• İletişim dili: en-GB, sayfa ve ServiceChannel düzeyinde belirtilir.

{
  "@type": "ServiceChannel",
  "availableLanguage": "en-GB",
  "serviceLocation": { "@id": "https://ornek-klinik.com/klinik/istanbul/#clinic" },
  "servicePhone": { "@type": "ContactPoint", "telephone": "+90..." }
}

Bu ayrım aynı zamanda cevap motorlarının kurumu doğru konumlandırması için de belirleyici. Doktorlar için AI optimizasyonu yazımda değindiğim gibi, cevap motorları bir kurumun nerede fiziksel olarak var olduğunu ve kime hitap ettiğini ayrı sinyaller olarak okuyor; ikisini birbirine karıştırmak entity’nin güven skorunu düşürüyor.

Tam @graph Şablonu: Meridyen Klinik Örneği

Buraya kadar varlıkları tek tek tanımladım. Şimdi hepsini tek bir @graph içinde, sabit @id referanslarıyla birbirine bağlanmış halde veriyorum. Aşağıdaki blok, iki klinikli ve üç doktorlu bir yapının çekirdek iskeletidir; kendi kurumunuza uyarlarken varlık türlerini ve @id desenini koruyun, yalnızca değerleri değiştirin. Okunabilirlik için tek doktoru tam gösteriyorum: Dr. Elif Demirtaş ve Dr. Mert Kaya için aynı deseni tekrarlayın, tek fark practicesAt ve medicalSpecialty değerleridir.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://ornek-klinik.com/#organization",
      "name": "Meridyen Klinik",
      "url": "https://ornek-klinik.com/",
      "logo": "https://ornek-klinik.com/logo.png",
      "sameAs": [
        "https://www.instagram.com/meridyenklinik",
        "https://www.linkedin.com/company/meridyenklinik"
      ],
      "subOrganization": [
        { "@id": "https://ornek-klinik.com/klinik/istanbul/#clinic" },
        { "@id": "https://ornek-klinik.com/klinik/izmir/#clinic" }
      ]
    },
    {
      "@type": "MedicalClinic",
      "@id": "https://ornek-klinik.com/klinik/istanbul/#clinic",
      "name": "Meridyen Klinik İstanbul",
      "parentOrganization": { "@id": "https://ornek-klinik.com/#organization" },
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "Örnek Mah. Örnek Cad. No: 1",
        "addressLocality": "İstanbul",
        "postalCode": "34000",
        "addressCountry": "TR"
      },
      "telephone": "+90 212 000 00 00",
      "availableService": { "@id": "https://ornek-klinik.com/tedaviler/rinoplasti/#procedure" }
    },
    {
      "@type": "MedicalClinic",
      "@id": "https://ornek-klinik.com/klinik/izmir/#clinic",
      "name": "Meridyen Klinik İzmir",
      "parentOrganization": { "@id": "https://ornek-klinik.com/#organization" },
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "Örnek Mah. Örnek Cad. No: 2",
        "addressLocality": "İzmir",
        "postalCode": "35000",
        "addressCountry": "TR"
      },
      "telephone": "+90 232 000 00 00",
      "availableService": { "@id": "https://ornek-klinik.com/tedaviler/rinoplasti/#procedure" }
    },
    {
      "@type": ["Person", "IndividualPhysician"],
      "@id": "https://ornek-klinik.com/ekip/kerem-aydin/#physician",
      "name": "Kerem Aydın",
      "jobTitle": "Plastik Cerrahi Uzmanı",
      "medicalSpecialty": "https://schema.org/PlasticSurgery",
      "worksFor": { "@id": "https://ornek-klinik.com/#organization" },
      "practicesAt": { "@id": "https://ornek-klinik.com/klinik/istanbul/#clinic" },
      "hasCredential": {
        "@type": "EducationalOccupationalCredential",
        "credentialCategory": "Uzmanlık Belgesi",
        "recognizedBy": { "@type": "Organization", "name": "Sağlık Bakanlığı" }
      }
    },
    {
      "@type": "SurgicalProcedure",
      "@id": "https://ornek-klinik.com/tedaviler/rinoplasti/#procedure",
      "name": "Rinoplasti"
    },
    {
      "@type": "Service",
      "@id": "https://ornek-klinik.com/tedaviler/rinoplasti/#service",
      "name": "Rinoplasti Hizmeti",
      "serviceType": "Rinoplasti",
      "provider": { "@id": "https://ornek-klinik.com/#organization" },
      "about": { "@id": "https://ornek-klinik.com/tedaviler/rinoplasti/#procedure" },
      "areaServed": { "@type": "Country", "name": "Türkiye" },
      "availableChannel": {
        "@type": "ServiceChannel",
        "availableLanguage": "tr-TR",
        "serviceLocation": { "@id": "https://ornek-klinik.com/klinik/istanbul/#clinic" },
        "servicePhone": { "@type": "ContactPoint", "telephone": "+90 212 000 00 00" }
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://ornek-klinik.com/tedaviler/rinoplasti/#webpage",
      "url": "https://ornek-klinik.com/tedaviler/rinoplasti/",
      "about": { "@id": "https://ornek-klinik.com/tedaviler/rinoplasti/#procedure" },
      "mainEntity": { "@id": "https://ornek-klinik.com/tedaviler/rinoplasti/#service" }
    }
  ]
}

Bu iskelette dört ilişki türü çalışıyor: marka her iki kliniğe subOrganization ile iner, klinikler markaya parentOrganization ile bağlanır; her klinik availableService ile kanonik prosedüre işaret eder (prosedür tek, sunum noktası iki); doktor practicesAt ile kliniğe, worksFor ile markaya bağlanır; ticari Service ise about ile prosedüre, provider ile markaya bağlanır ve dile özel iletişimi availableChannel içindeki ServiceChannel taşır. SurgicalProcedure düğümünü kasıtlı olarak sade tuttum; gerçek kullanımda howPerformed, preparation ve followup gibi alanlarla zenginleştirebilirsiniz. Sayfa düzeyinde WebPage’i about ile prosedüre, mainEntity ile hizmete bağladım; kendi kurulumunuzda buraya BreadcrumbList ve Organization düğümlerini de aynı @id mantığıyla iliştirin.

Entity Grafiğini Doğrulama: Hangi Araç Ne İçin?

Bir @graph kurmak yetmez; @id’lerin gerçekten çözümlendiğini ve varlıkların doğru bağlandığını test etmek gerekir. İki aracı farklı işler için kullanıyorum:

• Schema Markup Validator (validator.schema.org): Söz dizimini ve tüm tipleri doğrular. Hangi zengin sonuç özelliğini kazandığınızı umursamadan, grafiğin bütününü ve @id bağlarını görmek için bunu kullanıyorum. Entity mimarisi denetiminde birincil aracım budur.
• Rich Results Test (Google): Yalnızca Google’ın desteklediği zengin sonuç tiplerini kontrol eder. Not: FAQ kontrolü Haziran 2026’da bu araçtan kalkıyor, dolayısıyla FAQPage’i buradan doğrulamayı beklemeyin; söz dizimi kontrolü için Schema Markup Validator’a bakın.

Manuel kontrol de şart: HTML kaynağında Ctrl+F ile referans verilen her @id’yi arayın ve karşılığının grafikte gerçekten tanımlandığından emin olun. Tanımsız bir @id’ye referans, grafikte kopuk bir düğüm bırakır ve makinelerin ilişkiyi kurmasını engeller. sameAs ve practicesAt gibi bağların gerçek, erişilebilir hedeflere gittiğini de tarayıcıda tek tek açarak doğrulayın. Bu tür yayın öncesi teknik kontrollerin listesini yayın öncesi 6 kritik teknik hata dosyamda topladım.

Kurulumda Sık Karşılaşılan Hatalar

• Sahte aggregateRating: Kendi sitesinde kendi kliniği için puan toplayıp yıldız hedeflemek. Google, işletmenin kendi kontrolündeki sayfalarda kendisi hakkında topladığı değerlendirmeleri kendinden menkul kabul ediyor ve zengin sonuç için uygun saymıyor.
• Her doktora otomatik Physician yazmak: Yukarıda anlattığım gibi, kurumsal markanın çalışanı için Person temel, gerekirse IndividualPhysician yeterli.
• Hedef ülke için sahte lokasyon üretmek: Fiziksel klinik yalnızca gerçek hizmet noktasında tanımlanır.
• Tanımsız @id’ye referans vermek: Bir düğümden çözümlenmeyen bir @id’ye bağlanmak, grafikte kopuk varlık bırakır. Referans verilen her @id’nin karşılığı grafikte tanımlı olmalı.
• sameAs ve author yapılarını yanlış kurmak: sameAs, “bu aynı varlıktır” anlamına gelir; ilgili blog yazısı, başka bir tedavi sayfası ya da rastgele bir iç link için kullanılmaz. Yalnızca doktorun veya markanın gerçekten aynı kimliği temsil eden dış profilleri için kullanılır.
• Görünmeyen kimlik bilgilerini şemaya doldurmak: Sayfada görünmeyen bir unvan, üyelik veya sertifika şemaya eklenmez.

Bu son iki maddenin pratikte ne kadar maliyetli olabileceğini medikal SEO denetimi vakasında gözlemledim. İncelediğim kurumda sameAs alanları gerçek kimlik profillerine değil ilgisiz iç linklere işaret ediyordu, author yapıları tutarsız kurulmuştu ve marka için ayrı bir entity sinyali hiç inşa edilmemişti. Sonuç şuydu: kurum global akredite kurumların sertifikasyonuna sahip olmasına rağmen, cevap motorlarında zayıf ve belirsiz bir anlatıyla yer alıyordu. Şema doğru sözdizimiyle yazılmıştı ama yanlış ilişkiler kuruyordu; teknik olarak geçerli, anlamsal olarak boştu.

Yayın Politikası Katmanı: Şema İşaretler, Sistemi Değiştirmez

Güçlü bir sağlık sitesinde doktor ve tedavi şeması tek başına yetmiyor. Kurumun yayın sistemi de görünür olmalı: kimin içerik yazabildiği, tıbbi incelemeyi kimin yaptığı, kaynakların nasıl seçildiği, içeriğin ne sıklıkla gözden geçirildiği. Bu bilgiler önce sayfada gerçek ve görünür şekilde var olmalı; publishingPrinciples, correctionsPolicy ve ethicsPolicy gibi alanlar bu sistemi işaretler, yerine geçmez. Önce editoryal süreç kurulur, şema sonra o süreci makinelere okunabilir hale getirir.

FAQ Şeması Hakkında Güncel Bir Not

Google, FAQ zengin sonucunu Ağustos 2023’te otoriter kamu ve sağlık siteleriyle sınırlamıştı; 7 Mayıs 2026 itibarıyla bu görünürlüğü kalan kamu ve sağlık siteleri dahil tüm siteler için tamamen kaldırdı. Search Console raporu Haziran 2026’da, API desteği Ağustos 2026’da devre dışı kalıyor. FAQPage tipi geçerliliğini koruyor, işaretleme hata üretmiyor ve Google kullanılmayan yapısal verinin sorun yaratmadığını belirtiyor; değişen tek şey görsel SERP çıktısı.

Burada sık tekrarlanan bir yanılgıyı düzeltmek gerekir: “FAQ şemasını cevap motorları için ekliyorum” gerekçesi yanıltıcı. ChatGPT, Perplexity ve AI Overviews atıf kararını verirken JSON-LD’yi ayrıcalıklı okumaz; sayfadaki görünür soru cevap metnini çeker, işaretleme orada olsa da olmasa da. Yani cevap motorlarındaki asıl kaldıraç, görünür ve cevap-önce (answer-first) yazılmış metindir. Bu formatı doğru kurmanın ayrıntılarını GEO uyumlu içerik üretimi yazımda ele aldım.

O halde FAQPage’i şu gerekçelerle tutuyorum: geçerli bir schema.org tipi, zarar vermiyor ve sayfadaki içeriği makineler için yapılandırıyor. Ama görünürlük ya da yapay zeka kısayolu beklentisiyle değil. Yalnızca zengin sonuç avlamak için sayfaya jenerik FAQ blokları yapıştıran siteler bu işaretlemeyi kaldırabilir; içeriği gerçekten soru cevap yapısında olan ve görünür metni güçlü sayfalar için değişen bir şey yok.

Sonraki Adım

Entity mimarisi tek seferlik bir kurulum değil, sitenin büyümesiyle birlikte genişleyen bir sistem. Yeni bir klinik, yeni bir doktor veya yeni bir tedavi eklendiğinde aynı @id mantığı ve fragment sözleşmesi korunmalı. Bu konuyu doktorlar için SEO çalışması kapsamında bütünleşik olarak ele alıyorum; şema bu çalışmanın teknik omurgasını oluşturuyor.

Sık Sorulan Sorular