Klinik Sitelerinde Branş Sayfası mı Hizmet Sayfası mı?

Çok branşlı bir klinik sitesinde Dermatoloji, Ortopedi veya Kadın Hastalıkları gibi uzmanlık alanları bulunabilir. Aynı branşların altında kullanıcıların ayrıca araştırdığı çok sayıda hizmet veya tedavi de sunulabilir.

Burada iki uç yaklaşım sık görülür.

Birincisi, branşa ilişkin bütün doktorları, hizmetleri ve tedavileri tek büyük sayfaya doldurmaktır.

İkincisi ise bulunan her branş, tedavi, doktor ve lokasyon kombinasyonu için ayrı landing page üretmektir.

Doğru karar sayfa sayısıyla değil, kullanıcının yaptığı aramanın hangi entity ve search intent’i temsil ettiğiyle verilir.

Temel model şöyle düşünülebilir:

KLİNİK
   ↓
BRANŞ / SPECIALTY
   ↓
HİZMET / TEDAVİ
   ↕
DOKTOR

Ancak bu bütün kliniklere uygulanacak sabit bir URL şablonu değildir.

DigitalPlus Klinik SEO çalışmalarında branş, treatment ve practitioner sayfalarını keyword listesine göre değil, gerçek organization yapısı ve search intent ownership üzerinden planlıyoruz.

Branş, Hizmet ve Doktor Aynı Arama Görevini Taşımaz

Klinik sitesindeki üç temel page role birbirinden ayrılmalıdır.

Branş / Specialty

Merkezinde belirli uzmanlık veya tıbbi branş bulunur.

Örneğin:

• Dermatoloji
• Ortopedi ve Travmatoloji
• Kadın Hastalıkları ve Doğum

gibi gerçek branşlar olabilir.

Hizmet / Treatment

Merkezinde kullanıcının araştırdığı belirli sağlık hizmeti veya tedavi bulunur.

Örneğin:

• Belirli dermatoloji uygulamaları
• Diz protezi
• Belirli cerrahi veya medikal hizmetler

gerçek hizmet kapsamı ve search intent desteklediğinde ayrı owner olabilir.

Doktor / Practitioner

Merkezinde gerçek sağlık profesyoneli bulunur.

Doctor profile şu soruya cevap verir:

Bu kişi kim?

Branş page şu soruya cevap verir:

Bu uzmanlık alanı klinikte nasıl temsil ediliyor?

Treatment page ise şu soruya cevap verir:

Kullanıcının araştırdığı bu hizmet veya tedavi klinikte nasıl konumlanıyor?

Specialty ≠ treatment ≠ practitioner.

Branş Sayfasının SEO Görevi Nedir?

Branş page’in görevi belirli uzmanlık alanının clinic architecture içindeki ana referans veya navigation noktası olmaktır.

Gerçek yapıya göre sayfa:

• Branşın klinikte bulunduğunu açıklar
• Bu branşta çalışan gerçek doktorlara yönlendirir
• İlgili hizmet ve treatment owner’lara bağlantı verir
• Gerekirse gerçek location ilişkilerini gösterir
• Kullanıcının branş içindeki seçenekleri anlamasını kolaylaştırır

Örneğin:

/dermatoloji

bir specialty hub görevi taşıyabilir.

Ancak branş page bütün dermatoloji bilgi ve treatment sorgularının tek sahibi olmak zorunda değildir.

Branş sayfası katalog değil, specialty navigation ve ownership node’udur.

Hizmet veya Tedavi Sayfasının SEO Görevi Nedir?

Treatment veya service page daha dar bir kullanıcı ihtiyacını karşılar.

Sayfa gerçek hizmet modeline göre:

• Belirli service intent’i sahiplenir
• Hizmetin klinikte gerçekten sunulduğunu açıklar
• İlgili gerçek practitioners ile ilişki kurar
• Relevant supporting health content’e bağlanabilir
• Gerçek location availability bilgisini gösterebilir
• Kullanıcının uygun sonraki aksiyona ulaşmasını sağlar

Örneğin:

/diz-protezi

ayrı service/treatment intent taşıyorsa Ortopedi branş sayfasından farklı bir owner olabilir.

Branş hizmet evrenini organize eder; treatment page belirli service demand’i sahiplenir.

Branş ve Hizmet Aynı Sayfada Olabilir mi?

Evet.

Her klinikte ayrı specialty hub ve ayrı treatment pages bulunması gerekmez.

Özellikle:

• Tek branşlı kliniklerde
• Tek veya az sayıda doctor bulunan yapılarda
• Hizmet kapsamı dar olduğunda
• Search demand yeterince ayrışmadığında
• Bağımsız treatment page için yeterli kullanıcı değeri üretilemediğinde

aynı güçlü page birden fazla ihtiyacın temel kısmını karşılayabilir.

Örneğin yalnız dermatoloji alanında faaliyet gösteren küçük bir klinikte güçlü organization/specialty homepage kullanıcının:

• Kliniği tanımasını
• Doktorları görmesini
• Ana hizmetleri keşfetmesini

sağlıyorsa ayrıca boş bir specialty hub oluşturmak gereksiz olabilir.

SEO architecture sitenin gerçek karmaşıklığı kadar karmaşık olmalıdır.

Branş ve Treatment Ne Zaman Ayrılmalı?

İki ayrı canonical owner oluşturmadan önce birden fazla sinyali birlikte değerlendiriyoruz.

1. Branşın Ayrı Search Intent’i Var mı?

Kullanıcı genel uzmanlık alanını mı araştırıyor?

2. Treatment Ayrı Search Intent Taşıyor mu?

Kullanıcı spesifik bir hizmet veya tedavi mi değerlendiriyor?

3. SERP’ler Ayrışıyor mu?

Branş sorgusu ile treatment sorgusunda farklı URL ve page type’lar mı öne çıkıyor?

4. Klinik Hizmeti Gerçekten Sunuyor mu?

Search volume bulunması gerçek clinical capability oluşturmaz.

5. İki Sayfaya Ayrı İçerik Değeri Üretilebilir mi?

Treatment page specialty page’in yalnız birkaç kelimesi değiştirilmiş kopyası mı olacak?

6. Practitioner Relationships Farklı mı?

Belirli treatment yalnız bazı doktorlarla mı ilişkili?

7. User Journey Farklı mı?

Branş araştıran kullanıcı ile belirli treatment’ı değerlendiren kullanıcının soruları gerçekten farklı mı?

Bu sinyaller ayrıştıkça iki ayrı URL ihtiyacı güçlenir.

Örnek: Dermatoloji Mimarisi

Çok kapsamlı dermatoloji hizmeti bulunan bir yapıda şu model anlamlı olabilir:

DERMATOLOJİ
    │
    ├── DOKTORLAR
    ├── AKNE İLE İLİŞKİLİ HİZMETLER
    ├── LAZER UYGULAMALARI
    └── DİĞER GERÇEK TREATMENTS

Website architecture açısından:

/dermatoloji

specialty owner olurken, ayrı search intent ve gerçek service scope taşıyan bazı treatments kendi canonical URL’lerine sahip olabilir.

Ancak:

Dermatoloji altında üç keyword bulduk → üç landing page açalım

şeklinde karar verilmez.

Her treatment için ayrı:

• Search intent
• SERP
• Gerçek hizmet
• Page value
• Practitioner relationship

doğrulanmalıdır.

Örnek: Ortopedi Mimarisi

Ortopedi tarafında üç farklı entity katmanı kolayca görülebilir.

Specialty

/ortopedi

Treatment / Service

Örneğin gerçekten sunuluyorsa:

• Diz protezi
• Belirli omuz cerrahisi hizmetleri
• Diğer gerçek ortopedik treatments

Practitioner

Ortopedi uzmanı Dr. A.

Bu yapıda:

ORTOPEDİ
   ↓
DİZ PROTEZİ
   ↕
DR. A

relationship bulunabilir.

Ancak üç entity’nin ilişkili olması aynı page olmalarını gerektirmez.

Doktor Profil Sayfası Branş Sayfasının Yerine Geçebilir mi?

Genellikle primary görevleri farklıdır.

Doctor Profile

Bu kişi kim?

Specialty Page

Bu uzmanlık alanı clinic organization içinde nasıl temsil ediliyor?

Treatment Page

Bu belirli hizmet veya treatment nedir ve clinic architecture içinde kimlerle ilişkilidir?

Doktor profile üzerinde kişinin uzmanlığı ve gerçek treatments ilişkisi bulunabilir.

Ancak doctor profile’ı bütün branş ve treatment sorgularının generic landing page’i haline getirmemek gerekir.

Doktor entity’sinin site içindeki görevini Doktor Profil Sayfası SEO rehberinde ayrıntılı olarak ele alıyoruz.

Tek Branşlı Kliniklerde Branş Sayfası Gerekir mi?

Her zaman değil.

Örneğin kliniğin bütün organization identity’si zaten dermatoloji etrafında kurulmuşsa homepage şu görevleri birlikte taşıyabilir:

• Organization
• Ana specialty
• Ana service navigation
• Practitioner navigation

Böyle bir yapıda ayrıca:

/dermatoloji

oluşturmak homepage ile ciddi intent overlap yaratabilir.

Karar için:

• Homepage’in current search role’ü
• Branded ve non-brand query davranışı
• SERP
• Klinik büyüklüğü
• Hizmet sayısı
• Future site architecture

birlikte değerlendirilmelidir.

Tek branşlı siteye çok branşlı hastane taxonomy’si giydirmiyoruz.

Çok Branşlı Kliniklerde Specialty Hub Daha Mantıklı mı?

Birden fazla gerçek branş bulunan yapılarda ayrı specialty pages kullanıcı navigation’ı açısından daha anlamlı hale gelebilir.

Örneğin klinikte:

• Dermatoloji
• Ortopedi
• Kadın Hastalıkları

bulunuyorsa her specialty node ilgili:

• Doktorları
• Gerçek treatments’ı
• Gerekirse locations’ı

organize edebilir.

Model:

                   KLİNİK
               /      |      \
              ↓       ↓       ↓
       DERMATOLOJİ  ORTOPEDİ  DİĞER BRANŞ
           │          │
        DOCTORS     DOCTORS
           │          │
       TREATMENTS  TREATMENTS

Ancak çok branşlı olmak bile bütün branşların otomatik ayrı indexable hub olması gerektiğini kanıtlamaz.

Kullanıcı görevi ve search demand yine incelenmelidir.

Aynı Hizmet Birden Fazla Branşla İlişkiliyse?

Bazı services birden fazla specialty ile gerçek relationship taşıyabilir.

Bunun karşılığı aynı treatment’ın iki kopyasını üretmek olmamalıdır.

Örneğin:

SPECIALTY A ──────┐
                  ↓
              SERVICE X
                  ↑
SPECIALTY B ──────┘

Daha temiz başlangıç modeli:

tek canonical service owner + birden fazla gerçek specialty relationship

şeklindedir.

Yanlış model:

• /brans-a/service-x
• /brans-b/service-x

adreslerinde aynı kullanıcı ihtiyacını ve aynı içeriği iki kez üretmektir.

Bir service’in iki branşla ilişkili olması iki service entity olduğu anlamına gelmez.

Aynı Branşta Birden Fazla Doktor Varsa?

Branş page birçok gerçek practitioner ile ilişkili olabilir.

DERMATOLOJİ
    │
    ├── DR. A
    ├── DR. B
    └── DR. C

Her doctor kendi canonical person profile’ına sahip olabilir.

Ancak:

• /dr-a-dermatoloji
• /dr-b-dermatoloji
• /dr-c-dermatoloji

gibi specialty × practitioner kombinasyonları sırf üç doktor bulunduğu için oluşturulmamalıdır.

Practitioner relationship yeni specialty URL gerekçesi değildir.

Bir Doktor Birden Fazla Treatment ile İlişkiliyse?

Bu normal relationship modelidir.

DR. A
  │
  ├── SERVICE A
  ├── SERVICE B
  └── SERVICE C

Doctor profile kişinin gerçek çalışma alanlarını gösterebilir ve ayrı canonical owner olan service pages’e contextual internal links verebilir.

Ancak:

doctor × service

kombinasyonlarının tamamı için yeni landing page üretmek gerekmez.

Branş ve Treatment Internal Linking Nasıl Kurulmalı?

Site hiyerarşisi yalnız URL klasörlerinden oluşmaz.

Gerçek ilişkiler crawl edilebilir internal links ile görünür hale getirilmelidir.

                  KLİNİK
                    ↓
                 SPECIALTY
                /         \
               ↓           ↓
          TREATMENT      DOCTOR
               ↕           ↕
             DOCTOR     TREATMENTS
               ↑
        SUPPORT CONTENT

Specialty → Treatment

Branşta gerçekten sunulan ve bağımsız owner olan services’a bağlantı verilebilir.

Specialty → Doctor

O branşta gerçekten çalışan practitioners gösterilebilir.

Doctor → Specialty

Kişinin gerçek uzmanlık alanına bağlantı kurulabilir.

Doctor → Treatment

Gerçek service relationships varsa contextual links verilebilir.

Treatment → Doctor

Hizmeti gerçekten sunan practitioners’a geçiş verilebilir.

Support Content → Treatment

Bilgilendirici sağlık içeriği kullanıcı açısından doğal olduğunda doğru commercial/service owner’a bağlantı verebilir.

Internal linking bütün sayfaları birbirine bağlamak değil, entity relationships’i görünür hale getirmektir.

Branş Sayfasından Bütün Treatment’lara Link Vermek Gerekir mi?

Branş page’in doğal bir navigation hub görevi varsa önemli treatments’a erişim sağlaması mantıklı olabilir.

Ancak yüzlerce treatment veya sağlık konusunu sırf internal authority dağıtmak için tek sayfaya dökmek gerekmez.

Link seçimi:

• Gerçek clinical relationship
• Kullanıcı navigation ihtiyacı
• Site hiyerarşisi
• Service importance

üzerinden yapılmalıdır.

Branş ve Treatment Sayfalarını Orphan Bırakmayın

Bir specialty veya treatment URL’nin XML sitemap’te bulunması site mimarisinde güçlü biçimde bağlı olduğu anlamına gelmez.

Önemli owner URL’ler uygun olduğunda:

• Clinic veya service navigation’dan
• İlgili specialty pages’den
• İlgili practitioners’dan
• Supporting health content’ten
• Gerçek location pages’den

crawl edilebilir links almalıdır.

DigitalPlus’ın clinic, doctor, treatment ve location ilişkilerinin tamamına yaklaşımını Doktor ve Klinik Sitelerinde SEO Sayfa Mimarisi rehberinde ele alıyoruz.

Breadcrumb Branş ve Treatment İlişkisini Nasıl Göstermeli?

Breadcrumb gerçek kullanıcı navigation yolunu temsil etmelidir.

Örneğin branş page için:

Ana Sayfa
→ Branşlar
→ Dermatoloji

Treatment page için gerçek site yapısına göre:

Ana Sayfa
→ Tedaviler
→ Treatment A

veya:

Ana Sayfa
→ Dermatoloji
→ Treatment A

kullanılabilir.

İki modelden hangisinin doğru olduğu gerçek site navigation’ına bağlıdır.

Breadcrumb yalnız URL klasörlerini tekrar eden dekorasyon değildir.

URL Klasörü Entity Relationship’i Kanıtlar mı?

Hayır.

Örneğin:

/dermatoloji/akne-tedavisi

kullanılabilir.

Ancak:

/akne-tedavisi

de teknik olarak geçerli bir yapı olabilir.

Site içindeki specialty-treatment relationship esas olarak:

• Navigation
• Breadcrumb
• Contextual internal links
• Page content
• Canonical consistency

üzerinden görünür hale getirilebilir.

URL klasör derinliğini semantic authority puanına çevirmiyoruz.

URL Nasıl Seçilmeli?

Yeni canonical URL mümkün olduğunca:

• Anlaşılır
• Kalıcı
• Yönetilebilir
• Gereksiz parametrelerden uzak
• Sayfanın konusunu kullanıcı açısından açıklayıcı

olmalıdır.

Taxonomy değişirse bütün kritik URL’lerin sürekli taşınmasına yol açacak aşırı karmaşık path yapılarından kaçınmak faydalı olabilir.

Branş Page ile Homepage Cannibalization Nasıl Oluşur?

Özellikle tek specialty clinic sitelerinde bu risk daha yüksektir.

Örneğin homepage:

Dermatoloji Kliniği | Dermatoloji Hizmetleri…

şeklinde dermatoloji intent’ini yoğun biçimde sahiplenirken yeni:

/dermatoloji

sayfası da aynı primary query, aynı doctor listesi ve aynı service kapsamıyla oluşturulursa iki owner ortaya çıkabilir.

Bu durumda kontrol:

• Primary query
• Title
• H1
• Content scope
• Internal links
• SERP
• GSC query → page relationship

üzerinden yapılmalıdır.

Yeni taxonomy node açmadan önce mevcut homepage ownership’i kontrol edin.

Branş ve Treatment Cannibalization Nasıl Oluşur?

Örneğin:

/dermatoloji

ve:

/akne-tedavisi

doğal biçimde bazı ortak kelimeleri kullanabilir.

Bu tek başına cannibalization değildir.

Problem iki sayfanın da:

• Aynı primary query cluster’ı
• Aynı page title yaklaşımını
• Aynı H1’i
• Aynı service copy’yi
• Aynı user journey’yi
• Aynı CTA’yı

sahiplenmeye çalışmasıdır.

Keyword overlap olabilir. Search intent ownership overlap olmamalıdır.

Aynı Treatment Birden Fazla URL’de Bulunuyorsa Ne Yapılmalı?

Örneğin:

• /akne-tedavisi
• /dermatoloji/akne-tedavisi
• /hizmetler/akne-tedavisi

aynı hizmet ve aynı kullanıcı ihtiyacını temsil ediyor olabilir.

Bu durumda primary canonical owner belirlenir.

Ardından ihtiyaca göre:

• Redirect
• Canonical
• Internal linking
• Navigation
• Sitemap

aynı owner kararını destekleyecek biçimde düzenlenir.

Teknik implementation tarafını Teknik SEO kapsamında ayrıca değerlendiriyoruz.

Service Birden Fazla Specialty ile İlişkiliyse Breadcrumb Ne Olmalı?

Bir treatment’ın iki specialty ile relationship taşıması, iki ayrı canonical service page gerektiği anlamına gelmez.

Site navigation gerçekten iki farklı mantıklı kullanıcı yolu sunuyorsa breadcrumb ve internal linking buna göre tasarlanabilir.

Ancak URL’yi iki klasörde duplicate ederek relationship çözmeye çalışmamak gerekir.

Multiple relationships tek canonical owner ile temsil edilebilir.

Branş Sayfası Blog İçeriğine Dönüşmeli mi?

Branş page’in primary görevi clinic specialty node’udur.

Bu nedenle sayfayı:

• Uzmanlık alanının tarihçesi
• Bütün hastalıkların uzun açıklaması
• Bütün semptomların ansiklopedik listesi
• Yüzlerce FAQ

ile şişirmek gerekmez.

Kullanıcının daha dar health-information ihtiyaçları supporting içeriklerde ele alınabilir.

Specialty page navigation ve specialty decision görevini; informational content sağlık bilgi ihtiyacını sahiplenir.

Treatment Page Branş Sayfasının Kopyası Olmamalı

Yeni treatment page açıldığında parent specialty page üzerindeki tüm detayın aynısını tekrar etmek ayrı page value oluşturmaz.

Specialty page:

• Branşı
• Doktorları
• Ana hizmet alanlarını
• Navigation’ı

organize ederken treatment page spesifik service need üzerine yoğunlaşmalıdır.

İki outline yan yana konulduğunda yalnız treatment adı değişiyorsa URL split yeniden değerlendirilmelidir.

Branş Sayfası İçin Karar Ağacı

Klinikte yeni specialty bulunuyor.

↓

Gerçek bir branş mı?

Hayır → specialty page açma.

Evet ↓

Klinik çok branşlı mı veya bu specialty ayrı navigation görevi taşıyor mu?

Hayır → homepage veya mevcut organization page içinde tutmayı değerlendir.

Evet ↓

Ayrı search intent ve kullanıcı ihtiyacı var mı?

Hayır → ayrı URL gerekmeyebilir.

Evet ↓

Bağımsız page value üretilebilir mi?

Hayır → taxonomy amacıyla thin page açma.

Evet ↓

Specialty hub değerlendir.

Treatment Sayfası İçin Karar Ağacı

Branş altında yeni service/treatment bulundu.

↓

Klinik hizmeti gerçekten sunuyor mu?

Hayır → commercial page açma.

Evet ↓

Ayrı search intent var mı?

Hayır → specialty page içinde ele al.

Evet ↓

SERP bağımsız treatment/service page destekliyor mu?

Hayır → mevcut owner içinde tutmayı değerlendir.

Evet ↓

Bağımsız content ve user journey var mı?

Hayır → specialty page içinde tut.

Evet ↓

Başka URL aynı primary intent’i sahipleniyor mu?

Evet → ownership ayrımı, merge veya redirect değerlendir.

Hayır ↓

Ayrı treatment/service URL değerlendir.

Branş vs Hizmet Karar Matrisi

Soru	Branş Page	Service / Treatment Page
Kullanıcı uzmanlık alanı mı arıyor?	Güçlü aday	Zayıf
Kullanıcı belirli hizmeti mi araştırıyor?	Destekleyici	Güçlü aday
Birden fazla related service var mı?	Hub rolünü güçlendirir	Tek başına gerekçe değildir
Birden fazla practitioner var mı?	Hub rolünü güçlendirebilir	Tek başına gerekçe değildir
Bağımsız commercial treatment intent var mı?	Genellikle owner değildir	Güçlü aday
Küçük tek-branşlı klinik mi?	Gereksiz olabilir	Intent varsa açılabilir
Ayrı SERP davranışı var mı?	Split’i destekleyebilir	Split’i destekleyebilir
Outline neredeyse aynı mı?	Merge eğilimi	Split için zayıf sinyal

Klinik SEO URL Ownership Örneği

KLİNİK
│
├── DERMATOLOJİ
│   ├── DR. A
│   ├── DR. B
│   ├── TREATMENT A
│   └── TREATMENT B
│
├── ORTOPEDİ
│   ├── DR. C
│   └── TREATMENT C
│
└── SAĞLIK İÇERİKLERİ

Bu graph entity relationships’i gösterir.

URL’lerin mutlaka:

/dermatoloji/treatment-a

şeklinde fiziksel folder hierarchy kullanması gerektiğini göstermez.

Relationship graph ile URL path graph aynı şey değildir.

Sağlık Mevzuatı Branş ve Hizmet Sayfalarını Etkiler mi?

Evet. SEO mimarisi ile yayın dili birbirinden tamamen bağımsız değildir.

Sağlık kuruluşunun web sitesinde gerçek organization, uzmanlık ve hizmet kapsamının doğru temsil edilmesi gerekir.

Bu nedenle SEO amacıyla:

• Gerçekte bulunmayan branş
• Sunulmayan treatment
• Gerçek olmayan practitioner-service relationship
• Üstünlük iddiaları
• Garanti ifadeleri
• Yanıltıcı sağlık iddiaları

üretilmemelidir.

Keyword opportunity gerçek sağlık hizmeti veya uzmanlık yaratmaz.

SEO ekibi search demand ve architecture fırsatını belirleyebilir. Nihai sağlık mevzuatı ve yayın uygunluğu kurumun gerekli hukuk ve uyum süreçleriyle ayrıca değerlendirilmelidir.

Klinikler İçin Yerel SEO Branş Mimarisiyle Nasıl Birleşir?

Branş ve treatment relationships local search tarafında da önem kazanabilir.

Örneğin gerçek bir clinic location üzerinde:

• Hangi branşlar bulunuyor?
• Hangi doctors hasta kabul ediyor?
• Hangi services gerçekten sunuluyor?

bilgileri website architecture içinde açık olmalıdır.

Ancak:

branş × treatment × ilçe

kombinasyonlarının tamamı için landing page oluşturulmamalıdır.

Klinik ve practitioner local entity ayrımını Klinikler İçin Yerel SEO rehberinde ele alıyoruz.

Google Search Console ile Branş-Treatment Ownership Nasıl Kontrol Edilir?

Mevcut bir klinik sitesinde GSC query ve page verileri birlikte incelenebilir.

Örneğin treatment sorgusunda beklenen service owner yerine sürekli specialty page görünüyorsa hemen yanlış ranking sonucuna varmıyoruz.

Önce:

• Query’nin güncel SERP’i
• Specialty page kapsamı
• Treatment page kapsamı
• Title ve H1 ayrımı
• Internal links
• Indexability
• Canonical

kontrol edilir.

İki olasılık vardır:

1. Google hedeflediğimiz page yerine başka owner seçiyor olabilir.
2. Biz gereksiz yere iki URL’ye böldüğümüz bir intent için yanlış ownership tasarlamış olabiliriz.

Wrong-page ranking teşhisi SERP kontrolü olmadan yapılmamalıdır.

Klinik Branş ve Hizmet Sayfası SEO Checklist

Organization

• Klinik gerçekten bu branşa sahip mi?
• Klinik gerçekten ilgili services’ı sunuyor mu?
• Organization yapısı doğru mu?

Intent

• Specialty query ayrı mı?
• Service query ayrı mı?
• Practitioner intent ayrıldı mı?
• Informational intent ayrıca değerlendirildi mi?

SERP

• Specialty query hangi page type’ı gösteriyor?
• Treatment query hangi page type’ı gösteriyor?
• İki SERP yüksek overlap gösteriyor mu?

Architecture

• Specialty page gerçekten gerekli mi?
• Treatment page gerçekten gerekli mi?
• Homepage ile specialty overlap var mı?
• Bir service birden fazla specialty altında duplicate edilmiş mi?
• Doctor × specialty kombinasyon URL’leri bulunuyor mu?

Practitioners

• Branşla ilişkili doctors doğru mu?
• Treatment ile ilişkili doctors gerçek mi?
• Doctor profiles canonical mı?

Internal Linking

• Clinic → specialty links var mı?
• Specialty → real treatment links var mı?
• Specialty → doctors links var mı?
• Doctor → specialty links var mı?
• Doctor ↔ treatment relationships doğru mu?
• Support content → commercial owner links doğru mu?
• Orphan specialty veya treatment page var mı?

Navigation

• Breadcrumb gerçek kullanıcı yolunu temsil ediyor mu?
• Menu ve contextual links page relationship’i destekliyor mu?
• URL folder yapısı gereksiz karmaşık mı?

Technical

• URL’ler 200 dönüyor mu?
• Indexable mı?
• Canonical owner doğru mu?
• Duplicate service URL’leri var mı?
• Sitemap canonical owner’ları içeriyor mu?
• Mobil navigation eksiksiz mi?

Branş Sayfası ile Treatment Sayfasını Keyword Sayısına Göre Ayırmayın

Bir klinikte Dermatoloji, Ortopedi veya başka gerçek branşlar bulunabilir.

Bu branşların altında ayrıca kullanıcıların bağımsız biçimde araştırdığı gerçek treatments da bulunabilir.

Ancak doğru architecture:

specialty → treatment → practitioner

kelimelerinin kaç kez arandığına bakıp otomatik URL üretmek değildir.

DigitalPlus klinik SEO çalışmalarında:

gerçek organization → query → search intent → SERP → page role → entity relationship → URL owner

sırasını kullanır.

Bazı kliniklerde specialty page ile treatment pages ayrı canonical owner’lar olacaktır.

Bazı küçük veya tek branşlı yapılarda ise ek taxonomy gereksizdir.

Doğru mimari en fazla URL’ye sahip olan değil, her URL’nin neden var olduğunu açıklayabilen mimaridir.

Klinik SEO Hizmetini İncele

Sağlık SEO Yaklaşımımızı İncele

Sıkça Sorulan Sorular

Her klinikte branş sayfası açılmalı mı?

Hayır. Çok branşlı yapılarda specialty pages güçlü navigation ve search intent görevi taşıyabilir. Tek branşlı veya küçük sitelerde homepage aynı görevi yeterince karşılıyorsa ayrı branş page gereksiz overlap oluşturabilir.

Her treatment için ayrı SEO sayfası gerekli mi?

Hayır. Ayrı search intent, gerçek hizmet, uygun SERP, farklı kullanıcı ihtiyacı ve yeterli bağımsız content value varsa ayrı treatment URL değerlendirilir.

Branş ve treatment aynı sayfada olabilir mi?

Evet. Küçük veya sınırlı service yapılarında tek güçlü specialty page ana hizmetleri de açıklayabilir. Site büyüdükçe ve service intentler ayrıştıkça ayrı owner pages değerlendirilebilir.

Dermatoloji ve akne tedavisi aynı sayfa mı olmalı?

Her site için tek cevap yoktur. Dermatoloji specialty intent’i, akne ile ilişkili treatment veya informational intentlerden ayrışıyorsa bağımsız pages anlamlı olabilir. SERP, gerçek hizmet ve mevcut site yapısı kontrol edilmelidir.

Doktor profili branş sayfasının yerine geçebilir mi?

Genellikle hayır. Doctor profile person intent’i sahiplenirken specialty page klinikteki branşı ve ilgili practitioner/service relationships’i organize eder.

Bir hizmet iki branşla ilişkiliyse iki sayfa açılmalı mı?

Genellikle hayır. Aynı service intent için tek canonical owner kullanılabilir ve birden fazla gerçek specialty relationship internal linking üzerinden gösterilebilir.

Bir branşta üç doktor varsa üç branş landing page gerekir mi?

Hayır. Tek specialty owner birçok practitioner relationship taşıyabilir. Her doctor için ayrı canonical person profile kullanılabilir.

Branş ve treatment URL’leri aynı klasörde olmak zorunda mı?

Hayır. URL path site organizasyonunun bir parçasıdır ancak page relationships navigation, breadcrumbs, contextual internal links ve görünür içerik üzerinden de kurulabilir.

Treatment URL root seviyede olabilir mi?

Evet. Kullanıcı açısından açıklayıcı ve sürdürülebilir olduğu sürece service page root veya mantıklı bir klasör altında bulunabilir. Folder depth tek başına semantic authority üretmez.

Breadcrumb URL klasörüyle aynı olmak zorunda mı?

Hayır. Breadcrumb kullanıcıların site içinde izleyebileceği gerçek navigation yolunu temsil etmelidir.

Aynı keyword branş ve treatment sayfasında geçerse cannibalization olur mu?

Tek başına hayır. Cannibalization iki veya daha fazla URL’nin aynı primary search intent’i sahiplenmeye çalışmasıyla oluşur. Doğal terminology overlap normaldir.

Specialty page’den treatment page’e internal link verilmeli mi?

Gerçek clinic relationship ve kullanıcı navigation ihtiyacı varsa evet. Branş page bağımsız service owner’lara açıklayıcı contextual links verebilir.

Treatment page’den doktor profiline link verilmeli mi?

Hizmetle gerçekten ilişkili practitioners varsa bağlantı verilebilir. Bütün doctors’ı bütün treatment pages’e eklemek gerekmez.

Tek branşlı klinikte homepage specialty owner olabilir mi?

Evet. Organization ve ana specialty büyük ölçüde aynı kullanıcı yolculuğunu oluşturuyorsa homepage iki rolü birlikte taşıyabilir. Ayrı page kararı mevcut SERP ve site ownership davranışına göre verilmelidir.