Medikal SEO Denetimi Vakası: Sağlık Grubunda 5 Kritik Hata

M

Bu 5 teknik vaka aynı güven zincirinin nerelerini kırıyor?

Sağlık sektöründe güven tek bir ekranda kurulmaz. Kullanıcının gördüğü yüzey ile Google’ın ve dil modellerinin yorumladığı teknik katman aynı kurum hikayesini anlatmalıdır. Ben bu yapıyı dört katmanda kontrol ediyorum:

1. Kimlik: Kurum, şube, doktor, uzmanlık ve içerik ilişkileri doğru modelleniyor mu?
2. Kanıt: Kullanıcıya gösterilen uzmanlık, yazarlık ve akreditasyon sinyalleri doğrulanabilir mi?
3. Ölçüm: Sistem gerçekten değerli randevu aksiyonlarını mı dönüşüm sayıyor?
4. Deneyim: Kullanıcı, bilgi arayışından randevuya hızlı ve kesintisiz ilerleyebiliyor mu?

Bu yapıyı sağlık SEO ve doktor yapay zeka optimizasyonu çalışmalarında Kimlik → Kanıt → Ölçüm → Deneyim zinciri olarak ele alıyorum. GEO açısından burada bir “AI citation garantisi” yoktur. Asıl amaç, kurum → doktor → şube → uzmanlık ilişkilerindeki belirsizliği azaltmak ve Google ile dil modellerinin daha tutarlı yorumlayabileceği bir varlık yapısı kurmaktır.

Vaka 1: Google ve dil modellerine yanlış kurumu tanıtmak

İncelenen ana sayfada kullanıcı çok lokasyonlu bir hastane grubunu görüyordu. Fakat yapılandırılmış veri katmanında farklı bir hikaye vardı: ana sayfa bir Article olarak işaretlenmiş, yazarı test isimli bir kişi olarak tanımlanmış ve bu kişi kurumla ilişkilendirilmişti. Aynı graph içinde CommunityHealth bir organizasyon tipi gibi kullanılıyor, çok lokasyonlu yapı ise tek bir fiziksel Place düğümüne bağlanıyordu.

Buradaki güven iki katmanlıdır. Görünür yüzeyde kullanıcı; doktor fotoğrafını, unvanı, klinik lokasyonunu, akreditasyon rozetini ve sağlık içeriğini görür. Teknik katmanda ise Google ve dil modelleri; kurum, şube, doktor, uzmanlık, yazarlık ve doğrulama ilişkilerinin nasıl bağlandığını yorumlamaya çalışır. Bu iki katman farklı şeyler söylüyorsa sorun estetik değil, yapısaldır.

• Ana sayfa bir sağlık kurumu ana sayfası olmasına rağmen Article olarak işaretlenmiş ve yazar olarak test isimli bir kişi tanımlanmıştı.
• Ana sayfada öne çıkan altı sağlık içeriğinin beşinde jenerik kurumsal yazar taksonomisi, yalnızca birinde isimlendirilmiş uzman taksonomisi vardı; kartlarda ise yazar bilgisi görünür değildi.
• Akreditasyon logosu görünüyordu; fakat HTML çevresinde kapsamı, hangi kurum veya şubeye ait olduğu ve nasıl doğrulanabileceği açıklanmıyordu.
• Kurumun gerçek sosyal profilleri HTML’de bağlıydı; buna rağmen Organization graph’ında sameAs ilişkileri yoktu. Görünür altı lokasyondan yalnızca biri yapılandırılmış veride fiziksel varlık olarak temsil ediliyordu.

Bu, klasik anlamda “schema yok” problemi değildir. Daha tehlikeli olan, schema’nın mevcut olup yanlış ilişkiler kurmasıdır. Google’ın yapılandırılmış veri yönergeleri, işaretlemenin sayfanın gerçek ana içeriğini temsil etmesini ve mümkün olan en spesifik uygun türlerin kullanılmasını ister. Organizasyon schema’sı da kurum kimliğinin ayırt edilmesine yardımcı olabilir. Doktor ve medikal sitelerde yapısal veri yapısının önemine dair yazımı okuyabilirsiniz.

Çok lokasyonlu bir sağlık yapısında daha doğru mantık şudur:

MedicalOrganization
├── Hospital / Şişli
├── Hospital / Beylikdüzü
├── Hospital / Büyükçekmece
├── Hospital / Bayrampaşa
└── diğer gerçek lokasyonlar

Doktor profil sayfası
└── ProfilePage → ana doktor entity'si
    ├── çalıştığı kurum / hastane ilişkisi
    └── gerçek uzmanlık alanı

MedicalWebPage / Article
├── author → gerçek yazar
└── reviewedBy → gerçek tıbbi inceleyen

Buradaki amaç schema’yı mümkün olduğunca büyütmek değildir. Amaç, gerçek dünyadaki ilişkiyi doğru modellemektir. Doktor hangi şubede çalışıyor? Hangi uzmanlık alanına sahip? İçeriği yazan veya tıbben gözden geçiren kişi kim? Kurumun ana organizasyonu ile fiziksel hastane aynı varlık mı? Bu soruların cevapları net değilse SEO ve GEO katmanında entity çözümlemesi de gereksiz belirsizlik taşır.

Doktor ve kurum güveni için hızlı kontrol

• Ana sayfanın schema tipi gerçekten ana sayfayı mı temsil ediyor?
• Test kullanıcıları, geliştirme URL’leri ve sahte yazar entity’leri graph’tan temizlenmiş mi?
• Ana sağlık organizasyonu ile fiziksel klinik şubeleri ayrı varlıklar olarak modellenmiş mi?
• Doktorun uzmanlığı, çalıştığı lokasyon ve içerik yazarlığı veya tıbbi inceleme rolü görünür bilgiyle tutarlı mı?
• Kurumun gerçek dış kimlik profilleri uygun sameAs ilişkileriyle bağlanmış mı?
• Akreditasyon ve sertifika görsellerinin kapsamı, sahibi ve doğrulama yolu kullanıcıya açıklanıyor mu?

Vaka 2: Consent Mode’da “denied” görüp sistemi doğru sanmak

İncelemede Consent Mode’un tamamen yok olmadığı görüldü. Kullanıcı izni verilmeden önce depolama durumları denied, izin sonrasında ise granted olarak güncelleniyordu. Ancak DataLayer sırası daha önemli bir sorunu gösterdi: Google Analytics ve Google Ads yapılandırma komutları çalıştıktan sonra consent default denied komutu kuyruğa giriyordu.

Google’ın önerdiği akış basittir: önce varsayılan izin durumu belirlenir, ardından tag’ler bu durumu dikkate alarak çalışır; kullanıcı tercih yaptığında consent durumu update edilir. İzin güncellemesinin geç veya yanlış sayfada yapılması, oturumun ilk sinyallerinin eksik kalmasına neden olabilir.

Burada önemli bir ayrım var: Network panelinde Google isteği görmek tek başına izinsiz çerez yazıldığını kanıtlamaz. Advanced Consent Mode kullanıldığında, denied durumunda çerezsiz ölçüm pingleri gönderilebilir. Bu nedenle gerçek doğrulama yalnızca DataLayer ekranına bakılarak yapılmamalıdır.

Consent Mode nasıl doğrulanmalı?

1. Yeni ve temiz bir tarayıcı oturumu açılmalı.
2. İzin verilmeden önce DataLayer veya Tag Assistant sırası kontrol edilmeli.
3. Application panelinde hangi çerezlerin gerçekten yazıldığı incelenmeli.
4. Network panelinde izin öncesi ve sonrası istek davranışı karşılaştırılmalı.
5. İzin verildiğinde update granted sinyalinin aynı sayfada çalıştığı doğrulanmalı.

Bu kontrol iki nedenle kritiktir. Birincisi, Türkiye’deki çerez uygulamalarında reklam, pazarlama ve performans amaçlı çerezler için açık rıza gerekliliği doğabilmektedir; KVKK rehber ve kararlarında aktif kullanıcı eylemine dayalı opt-in yaklaşımı özellikle vurgulanır. İkincisi, yanlış consent sırası yalnızca hukuki uyum riski yaratmaz; analitik oturum sinyallerini, ilişkilendirmeyi ve veri kalitesini de bozabilir.

Diğer doğrulama yolu için tarayıcı geliştirici aracındaki “Application –> Cookies” bölümü kullanılabilir. Kullanıcının “onay vermediği” bir senaryoda “_fbp” gibi Meta Pixel’in veya kullandığınız diğer analitik takip çerezleri, aktif olmamalıdır. Onay verildiğindeyse tüm analitik istemcilerinin çerezleri, tarayıcının cookies yerinde görülür. Bu kurulumun doğru olduğuna işaret eder. Yine network kısmından örneğin “fbevents.js” yazarak onay sonrasında pikselin yüklenip yüklenmediğini doğrulayabilirsiniz.

Google Consent Mode konusunda benim dikkat ettiğim kural

Benim pratik kuralım şu: bu test yalnızca kurulum gününde yapılmamalı. CMP, GTM konteyneri, doğrudan gtag.js kodu, eklenti, tema veya banner mantığı değiştiğinde beş adımlı kontrol yeniden çalıştırılmalı; ayrıca periyodik olarak canlı ortam tekrar doğrulanmalıdır. Amaç yalnızca bir banner göstermek değil, olası uyumsuzluk ve idari yaptırım riskini azaltırken ölçüm sinyal kalitesini korumaktır.

Dolayısıyla sağlık kurumları için doğru soru “banner var mı?” değildir. Doğru soru şudur: Banner, Consent Mode, çerezler ve gerçek Network davranışı birlikte doğru çalışıyor mu?

Vaka 3: Sayfa görüntülemeyi dönüşüm, gerçek randevu niyetini sıradan click saymak

Ölçüm yolculuğunda aynı Google Ads conversion etiketi dört farklı içerik aşamasında tetiklendi:

• doktorlar liste sayfası,
• tıbbi bölümler sayfası,
• bir tedavi/uzmanlık sayfası,
• doktor profil sayfası.

Kullanıcı bu aşamalarda henüz randevu tamamlamamış, telefon araması yapmamış veya WhatsApp üzerinden iletişim başlatmamıştı. Buna rağmen aynı Google Ads conversion label’ı çalışıyordu.

Buna karşılık gerçek niyete daha yakın iki aksiyon, yalnızca genel GA4 click eventi olarak kalıyordu:

• WhatsApp üzerinden randevu talebi başlatma,
• doktor profilinden harici randevu platformuna geçiş.

WhatsApp numarası teknik olarak doğruydu. Problem numaranın kendisi değil, kullanıcı niyetinin semantik olarak ölçülmemesiydi. Sistem “kullanıcı dış bağlantıya tıkladı” bilgisini tutuyor; fakat “kullanıcı WhatsApp üzerinden randevu niyeti gösterdi” bilgisini ayrı bir iş olayı olarak tanımlamıyordu.

Burada hemen “Smart Bidding bozuldu” denebilir mi?

Hayır. Bu noktada Google Ads hesabı görülmeden kesin hüküm vermek doğru olmaz. Kontrol edilmesi gereken kritik ayrım, söz konusu dönüşümün Primary mi yoksa Secondary mi olduğudur.

Google Ads’te Primary aksiyonlar, ilgili hedef teklif optimizasyonunda kullanıldığında bidding ve “Conversions” raporlamasını etkileyebilir. Secondary aksiyonlar ise çoğunlukla gözlem amacıyla “All conversions” tarafında tutulur. Bu nedenle iki senaryo ayrı değerlendirilmelidir:

• Secondary ise: Veri gürültüsü ve yanlış yönetim algısı oluşturur.
• Primary ve kampanya optimizasyonunda kullanılıyorsa: Sayfa görüntüleme davranışının gerçek randevu dönüşümü yerine öğrenilmesi riski doğar.

Google Ads hesabında hangi dört şey kontrol edilmeli?

1. Dönüşüm eylemi Primary mi, Secondary mi?
2. Hesap varsayılan hedeflerine veya ilgili kampanya hedeflerine dahil mi?
3. Etiketi hangi tetikleyici çalıştırıyor: sayfa görüntüleme mi, gerçek kullanıcı eylemi mi?
4. Kampanyanın teklif stratejisi bu dönüşüm sinyalini gerçekten optimizasyon için kullanıyor mu?

Bu dört kontrol yapılmadan “dönüşümler arttı” veya “dönüşümler düştü” yorumu güvenilir değildir. Önce hangi davranışın başarı olarak sayıldığını bilmek gerekir.

Sağlık kurumları için daha doğru dönüşüm hiyerarşisi

Sağlık dijital pazarlama yolculuğunda bütün tıklamalar eşit değildir. Doktor profilini görmek ile randevu tamamlamak aynı hedef altında toplanırsa veri hacmi artar; fakat karar kalitesi düşer.

Vaka 4: Kullanıcıyı randevu platformuna geçerken analitik zincirde kaybetmek

İncelenen yolculukta ana sağlık sitesi ile harici randevu platformu farklı ölçüm mimarileri kullanıyordu:

• farklı GTM container,
• farklı GA4 Measurement ID,
• farklı GA4 client identifier,
• ana site linker yapılandırmasında randevu domain’inin görünmemesi.

Farklı domainlerde farklı çerez değerleri görmek tek başına kopuş kanıtı değildir. Doğru cross-domain ölçüm, kullanıcı kimliğini domainler arasında taşıyabilir. Ancak bu örnekte farklı GA4 kimlikleri, farklı client ID’ler ve linker yapılandırmasında randevu alan isminin görünmemesi aynı yönde sinyal üretiyordu.

Bu nedenle yüksek güvenle söylenebilecek şey şudur: standart GA4 seviyesinde ana site ile randevu platformu arasında aynı kullanıcı ve aynı oturum devamlılığı görünmüyor. Kurumun bunu CRM, server-side event, özel kullanıcı ID’si veya veri ambarı üzerinden sonradan birleştirip birleştirmediği ayrıca kontrol edilmelidir.

Cross-domain sürekliliği pratikte nasıl test edilir?

• Randevu bağlantısına tıklandığında hedef URL’de _gl veya kullanılan mimariye ait eşdeğer bir bağlama sinyali oluşuyor mu?
• Ana site ile randevu platformunda kullanıcı kimliği ve oturum sürekliliği korunuyor mu?
• Randevu platformunda kaynak/medium ve kampanya bilgileri kayboluyor ya da self-referral üretiyor mu?
• İki alan ismi farklı GA4 property veya container kullanıyorsa sonuçlar hangi ortak anahtar, CRM kaydı veya server-side event ile birleştiriliyor?

Burada yalnızca URL’ye bir parametre eklenmesi yeterli değildir. Asıl hedef; kullanıcı, kaynak ve sonuç bilgisinin aynı analiz zincirinde yeniden ilişkilendirilebilmesidir.

Medikal SEO açısından ideal randevu yolculuğu nasıl görünmeli?

Landing page
→ Tıbbi bölüm
→ Doktor profili
→ Randevu CTA
→ Randevu platformu
→ Tarih / saat seçimi
→ Randevu tamamlandı
→ CRM'de nitelikli aday / gerçekleşen ziyaret

Bu zincirde kaynak, kampanya, landing page, doktor, bölüm ve randevu sonucu mümkün olduğunca korunmalıdır. Aksi halde sağlık kurumu içerik ve reklam yatırımlarında şu soruların cevabını kaybeder:

• Hangi doktor profili gerçek randevu üretiyor?
• Hangi tıbbi bölüm organik trafikten nitelikli talep getiriyor?
• Hangi reklam kampanyası yalnızca sayfa gezintisi, hangisi gerçek randevu üretiyor?
• GEO için üretilen hangi konu kümeleri gerçek randevu yolculuğuna katkı sağlıyor?

SEO ve GEO kararlarının değerli olması için sonucun da ölçülebilir olması gerekir. İçerik hangi soruyu cevaplıyor sorusu kadar, o içerik hangi randevu yolculuğunu başlatıyor sorusu da önemlidir.

Vaka 5: Carousel’i yalnızca tasarım tercihi sanmak

Site hızı performans testinde ana sayfa şu sonuçları üretti:

• TTFB: 1,24 saniye
• FCP: 2,48 saniye
• LCP: 4,11 saniye
• TBT: 980 ms
• CLS: 0,62
• Toplam sayfa ağırlığı: 5,44 MB
• Lab skoru: %33

Google’ın iyi kullanıcı deneyimi eşikleri LCP için 2,5 saniye veya daha düşük, CLS için 0,1 veya daha düşük seviyeleri hedefler. Bu testte LCP 4 saniyenin üzerine çıkarken CLS 0,62 seviyesine ulaşıyor.

Kaynak kodda dört ayrı image-carousel widget’ı ve toplam 17 carousel görseli bulunuyordu. Bunların 11’i hala JPG veya PNG, 6’sı WebP formatındaydı. Yani modern format kullanımı vardı; ancak dönüşüm tamamlanmamıştı. Sayfanın tamamında 54 görsel bulunması ve 5,44 MB toplam ağırlık, görsel mimarisini doğrudan öncelikli hale getiriyordu. Medikal ve doktor SEO çalışmasının parçası olan site hızı optimizasyonu için detaylı bilgiyi buradna alabilirsiniz.

Bir carousel slaytı yalnızca “bir görsel daha” değildir. Her slayt; indirme, responsive boyutlandırma, DOM üretimi, JavaScript başlatma, konum hesaplama ve çoğu zaman autoplay döngüsü gibi ek maliyetler taşır. Bu vakada mobil ve masaüstü için ayrı hero carousel yapılarının aynı sayfa mimarisinde bulunması da yük yüzeyini büyütüyordu.

Burada teknik ifadeyi doğru kurmak gerekir. Elimizdeki görüntü, elementor/assets/js/image-carousel...bundle.min.js dosyasının klasik anlamda parser-blocking olduğunu tek başına kanıtlamaz. Fakat carousel katmanının kritik render sürecine ve ana iş parçacığına ölçülebilir maliyet eklediğini açıkça gösterir.

Üstelik carousel tek suçlu değildir:

• GTM yaklaşık 722 ms CPU zamanı,
• jQuery yaklaşık 556 ms CPU zamanı,
• carousel + Swiper toplam en az 310 ms CPU zamanı

tüketiyordu.

Dolayısıyla doğru teşhis şudur: ağır sunucu cevabı + yüksek üçüncü taraf ölçüm maliyeti + jQuery/Elementor bağımlılıkları + carousel başlatma maliyeti + görsel optimizasyon eksikliği birlikte sayfayı yavaşlatıyor.

Sağlık ana sayfasında carousel için karar kontrolü

• İlk görünür slayt gerçek LCP öğesi mi ve doğru önceliklendiriliyor mu?
• Görünmeyen slaytlar ilk render’da gereksiz kaynak rekabeti oluşturuyor mu?
• Mobil ve masaüstü için ayrı carousel DOM’ları gerçekten gerekli mi?
• Görseller doğru boyut, sıkıştırma ve modern formatlarla sunuluyor mu?
• Aynı iletişim hedefi statik ve net bir hero alanıyla daha hızlı anlatılabilir mi?

Carousel her zaman kaldırılmalı mı?

Hayır. Ancak özellikle sağlık ana sayfalarında şu test yapılmalıdır: “Bu slayt gerçekten randevu kararına katkı sağlıyor mu, yoksa kurumsal olarak görünmesini istediğimiz mesajları sırayla mı gösteriyoruz?”

Çoğu durumda daha güçlü bir çözüm:

• tek, net bir hero mesajı,
• ilk görünür kritik görselin önceliklendirilmesi,
• AVIF/WebP ve responsive image kullanımı,
• LCP dışındaki görsellerin lazy-load edilmesi,
• görseller için açık width/height rezervasyonu,
• kritik olmayan JavaScript’in ertelenmesi

olabilir.

Sağlık sitesinde carousel, estetik bir tasarım tercihi gibi görünür. Fakat her yeni slayt yalnızca bir görsel değildir; indirme, boyutlandırma, JavaScript başlatma ve ana iş parçacığı maliyetini de beraberinde getirir.

Doktor SEO ve GEO için doğru teknik model

Bu gözlemden çıkan en önemli sonuç, sağlık sitelerinin teknik denetimini tek tek hata listeleriyle sınırlamamak gerektiğidir. Ben şu altı katmanı birlikte kontrol etmeyi daha doğru buluyorum:

1. Entity mimarisi

Organization → Hospital/Şube → MedicalDepartment → Physician → İçerik ilişkileri gerçek dünyaya uygun mu?

2. Uzmanlık ve kanıt katmanı

Doktorun unvanı, uzmanlığı, çalıştığı lokasyon, içerik yazarlığı veya tıbbi inceleme rolü görünür ve doğrulanabilir mi?

3. Consent ve veri yönetişimi

Default consent tag’lerden önce mi? Kullanıcı tercihi runtime’da gerçekten uygulanıyor mu? Çerez, Network ve Tag Assistant birlikte test edildi mi?

4. Dönüşüm semantiği

Sayfa görüntüleme ile gerçek randevu niyeti ayrılmış mı? Primary ve Secondary aksiyonlar iş değerine göre tanımlanmış mı?

5. Yolculuk sürekliliği

Ana site, randevu sistemi, çağrı merkezi, WhatsApp ve CRM aynı funnel içinde ilişkilendirilebiliyor mu?

6. Performans ve erişim

Kullanıcı ihtiyaç duyduğu doktor, bölüm ve randevu yoluna hızlı ulaşabiliyor mu? Tasarım bileşenleri gerçekten işlev üretiyor mu, yoksa yalnızca frontend maliyeti mi ekliyor?

Sağlık sitelerinde uygulanabilecek 10 maddelik teknik kontrol listesi

1. Ana sayfa schema’sının gerçek sayfa tipini temsil ettiğini kontrol edin.
2. Test kullanıcıları, sahte yazarlar ve geliştirme URL’lerini entity graph’tan temizleyin.
3. Çok lokasyonlu kurumlarda ana organizasyon ile fiziksel klinik yapılarını ayrı entity’ler olarak modelleyin.
4. Doktor → uzmanlık → şube → içerik ilişkilerini gerçek bilgiye dayalı biçimde bağlayın.
5. Consent Mode’u yalnızca DataLayer’da değil; çerez ve Network katmanında da test edin.
6. İzin öncesi default denied sırasını, izin sonrası update granted davranışını doğrulayın.
7. Google Ads’te şüpheli conversion action’ların Primary/Secondary ve campaign goal durumunu kontrol edin.
8. WhatsApp, telefon ve randevu başlangıcını genel click event’inden ayırın.
9. Randevu platformuna domain geçişinde kullanıcı, session ve attribution sürekliliğini test edin.
10. Carousel, GTM, jQuery ve görsel yükünü ayrı ayrı değil, aynı kritik render zincirinin parçaları olarak analiz edin.

Sonuç: Güven sinyali bir logo değil, teknik olarak tutarlı bir zincirdir

Bu incelemede görünür yüzeyde güçlü bir sağlık markası vardı: hastaneler, doktorlar, tıbbi bölümler, uluslararası danışan sayfaları, randevu sistemi ve akreditasyon unsurları. Fakat teknik katmanda üç farklı gerçeklik oluşuyordu:

• kullanıcı çok lokasyonlu bir sağlık grubu görüyordu,
• schema katmanı tek lokasyon ve hatalı ilişkiler üretiyordu,
• ölçüm sistemi pasif sayfa görüntülemelerini dönüşüm sayarken gerçek randevu yolculuğunu farklı analitik ortamlara bölüyordu.

Sağlık sektöründe teknik SEO’nun asıl değeri burada ortaya çıkar. Amaç yalnızca Google’a daha fazla veri göndermek değildir. Amaç, doğru kurumu, doğru doktoru, doğru uzmanlığı ve doğru randevu aksiyonunu aynı güvenilir sistem içinde tanımlamaktır.

Google’a ve yapay zeka sistemlerine güven anlatılmaz; tutarlı entity ilişkileri, doğrulanabilir uzmanlık sinyalleri, doğru consent mimarisi ve gerçek dönüşüm verisiyle ispatlanır.

Sık Sorulan Sorular