Çok Lokasyonlu Kliniklerde SEO Mimarisi: Her Şube İçin Hangi Sayfalar Açılmalı?

Bir klinik tek marka altında birden fazla fiziksel lokasyonda hizmet verebilir.

Örneğin:

• Kadıköy
• Ataşehir
• Bakırköy

gibi üç gerçek şube bulunabilir.

Bu durumda SEO problemi yalnız üç yeni lokasyon sayfası açmak değildir.

Her şubede:

• Farklı doktorlar
• Farklı branşlar
• Farklı hizmetler
• Farklı çalışma saatleri
• Farklı Google İşletme Profilleri

bulunabilir.

Çok lokasyonlu klinik SEO’nun temel görevi organization, location, practitioner ve service ilişkilerini gerçek operasyon yapısına göre modellemektir.

Temel yapı:

ORGANIZATION
      ↓
  LOCATIONS
   /   |   \
  A    B    C
  ↓    ↓    ↓
DOCTORS + SERVICES

DigitalPlus Klinik SEO çalışmalarında yeni URL’leri lokasyon keyword sayısına göre değil, gerçek fiziksel varlık, search intent ve kullanıcı ihtiyacına göre planlıyoruz.

Önce Organization ile Location Entity’yi Ayırın

Çok şubeli yapının merkezinde tek bir ana organization bulunabilir.

Örneğin:

ABC Klinik

ana organization entity’sidir.

Bu organizasyon altında:

• ABC Klinik Kadıköy
• ABC Klinik Ataşehir
• ABC Klinik Bakırköy

gibi gerçek fiziksel lokasyonlar bulunabilir.

ABC KLİNİK
    │
    ├── KADIKÖY
    ├── ATAŞEHİR
    └── BAKIRKÖY

Bu locations aynı markayı taşıyabilir ancak aynı entity değildir.

Her şubenin:

• Gerçek adresi
• Telefonu
• Çalışma saatleri
• Doktor kadrosu
• Branşları
• Hizmet kapsamı

farklı olabilir.

Organization markayı; location ise markanın belirli fiziksel hizmet noktasını temsil eder.

Her Gerçek Şube İçin Ayrı Location Page Açılmalı mı?

Gerçek ve kullanıcıya açık bir fiziksel şube varsa bağımsız location page çoğu çok lokasyonlu yapıda anlamlı olabilir.

Ancak bunun gerekçesi yalnız lokasyon adının aranması değildir.

Location page kullanıcıya gerçekten şubeye özgü bilgi sağlamalıdır.

Örneğin:

• Şubenin gerçek adresi
• Doğrudan iletişim bilgileri
• Çalışma gün ve saatleri
• Bu lokasyonda çalışan gerçek doktorlar
• Bu şubede bulunan gerçek branşlar
• Burada gerçekten sunulan hizmetler
• Ulaşım veya kullanıcı için yararlı location bilgileri
• Uygun iletişim veya randevu yolu

bulunabilir.

Yanlış model:

• /kadikoy-klinik
• /uskudar-klinik
• /besiktas-klinik
• /sisli-klinik

sayfalarını üretmek ama gerçekte yalnız Kadıköy’de tek klinik bulunmasıdır.

Location keyword, location entity değildir.

Location Page’in Primary Görevi Nedir?

Bir location page temel olarak şu sorunun cevabını vermelidir:

Bu klinik şubesinde kullanıcı için ne var?

Sayfanın merkezinde belirli bir fiziksel lokasyon bulunur.

Örneğin:

/lokasyonlar/kadikoy

URL’sinin temel görevi Kadıköy şubesini temsil etmektir.

Sayfa:

• Organization ile ilişkisini
• Gerçek adresini
• İletişimini
• Doktor kadrosunu
• Branşlarını
• Sunulan hizmetleri

gösterebilir.

Ancak location page bütün treatment sayfalarının şehir adı eklenmiş ikinci versiyonu olmamalıdır.

Ana Klinik Sayfası ile Location Page Nasıl Ayrılmalı?

Ana Klinik / Organization Page

Temel soru:

Bu klinik kim?

Görevleri:

• Marka veya organization’ı tanımlamak
• Gerçek locations’ı göstermek
• Ana branşlara yönlendirmek
• Ana services’a dağıtmak
• Kurumsal güven ve iletişim yüzeyi oluşturmak

Location Page

Temel soru:

Bu klinik nerede ve bu şubede ne bulunuyor?

Görevleri:

• Belirli fiziksel lokasyonu temsil etmek
• O lokasyondaki doctors’ı göstermek
• O lokasyondaki specialties’i göstermek
• O lokasyonda gerçekten sunulan treatments’ı göstermek
• Şubeye özgü iletişim bilgisini sunmak

Organization ≠ location.

Ana Sayfa mı Location Page mi Local Query’nin Owner’ı Olmalı?

Site yapısına göre değişir.

Tek Lokasyonlu Klinik

Homepage organization ve location rollerinin önemli kısmını birlikte taşıyabilir.

Ayrıca ayrı location page açmak gereksiz overlap oluşturabilir.

Çok Lokasyonlu Klinik

Her gerçek şubenin bağımsız kullanıcı görevi varsa location pages local branded ve branch-oriented sorgular için daha doğal owner olabilir.

Örneğin:

ABC Klinik

→ homepage / organization.

ABC Klinik Kadıköy

→ Kadıköy location page.

ABC Klinik Ataşehir

→ Ataşehir location page.

Multi-location architecture tek lokasyonlu site mimarisinin çoğaltılmış hali değildir.

Her Şube İçin Treatment Sayfaları Yeniden Açılmalı mı?

Hayır.

Bu çok lokasyonlu klinik SEO’daki en önemli ownership problemlerinden biridir.

Örneğin ana treatment URL:

/implant

olsun.

Hizmet iki gerçek şubede de sunuluyor olabilir:

• Kadıköy
• Ataşehir

Yanlış başlangıç:

• /kadikoy-implant
• /atasehir-implant

sayfalarını otomatik oluşturmaktır.

Önce şu sorular sorulmalıdır:

1. Hizmet gerçekten her iki lokasyonda da sunuluyor mu?
2. Lokasyon bazında ayrı search intent bulunuyor mu?
3. SERP bağımsız local landing page ihtiyacını destekliyor mu?
4. İki location-treatment page gerçekten farklı değer üretebilir mi?
5. Ana treatment owner ile cannibalization oluşacak mı?

Location relationship her zaman yeni treatment URL anlamına gelmez.

Tek Treatment Owner + Birden Fazla Location Relationship

Çoğu klinik için daha temiz başlangıç modeli şudur:

             TREATMENT A
              /       \
             ↓         ↓
         KADIKÖY    ATAŞEHİR

Tek canonical treatment owner hizmeti sahiplenir.

Treatment page:

• Hizmetin hangi gerçek locations’da sunulduğunu gösterir
• İlgili location pages’e bağlantı verebilir
• Gerçek practitioners’ı gösterebilir

Location page ise:

• Bu şubede Treatment A’nın sunulduğunu gösterir
• Canonical treatment owner’a contextual link verebilir

Böylece relationship iki yönlü görünür hale gelir fakat yeni kombinasyon URL üretilmez.

Location + Treatment Sayfası Ne Zaman Mantıklı Olabilir?

Location-treatment kombinasyon URL’si tamamen yasak değildir.

Ancak bağımsız page açmak için güçlü gerekçe gerekir.

Örneğin:

/kadikoy/implant

ancak şu sinyaller birlikte bulunuyorsa değerlendirilebilir:

• Gerçek Kadıköy şubesi var
• Hizmet gerçekten bu şubede sunuluyor
• Location-specific search intent güçlü
• SERP bağımsız local service pages gösteriyor
• Şubede farklı practitioner seti bulunuyor
• Kullanıcının location-specific journey’si farklı
• Şubeye özgü gerçek content value üretilebiliyor
• Ana treatment owner ile ownership net biçimde ayrılabiliyor

“Kadıköy implant” keywordü tek başına yeni page gerekçesi değildir.

Her Location × Service Kombinasyonunu Açarsak Ne Olur?

Örneğin üç şube ve yirmi treatment bulunduğunu düşünelim.

Matematik:

3 × 20 = 60 location-treatment kombinasyonu

çıkarabilir.

Buna on doctor eklendiğinde insanlar doğal olarak Excel’e yenilip site haritasını sanayi üretim hattına çevirebilir.

Sonuç:

• Near-duplicate pages
• Thin local content
• Cannibalization
• Internal linking karmaşası
• Yüksek bakım maliyeti
• Güncelliğini kaybeden doctor/service bilgileri
• Yanlış location-service relationships

olabilir.

Relationship sayısı URL sayısını belirlemez.

Doktorlar Locations ile Nasıl İlişkilendirilmeli?

Her doctor profile kişinin güncel gerçek çalışma lokasyonlarını göstermelidir.

Örneğin:

DR. A
→ KADIKÖY

DR. B
→ ATAŞEHİR

DR. C
→ KADIKÖY
→ ATAŞEHİR

Location pages tarafında da yalnız gerçekten o şubede çalışan doctors gösterilmelidir.

KADIKÖY
   ├── DR. A
   └── DR. C

ATAŞEHİR
   ├── DR. B
   └── DR. C

Bu çift yönlü relationship:

doctor profile ↔ location page

internal linking ile görünür hale getirilebilir.

Aynı Doktor İki Lokasyonda Çalışıyorsa İki Doctor URL Gerekir mi?

Genellikle hayır.

Tek canonical practitioner profile:

/doktorlar/dr-ayse-yilmaz

kullanılabilir.

Profile üzerinde doktorun hasta kabul ettiği gerçek locations gösterilebilir.

Yanlış model:

• /kadikoy/dr-ayse-yilmaz
• /atasehir/dr-ayse-yilmaz

şeklinde aynı kişiyi iki duplicate person URL ile temsil etmektir.

One practitioner → one primary person owner.

Location relationship canonical person profile üzerinde ayrıca modellenebilir.

Doktor profile mimarisini Doktor Profil Sayfası SEO rehberinde ayrıntılı olarak ele alıyoruz.

Aynı Doctor İki Şubede Farklı Hizmetlerle İlişkiliyse?

Örneğin:

DR. A
│
├── KADIKÖY
│     └── SERVICE A
│
└── ATAŞEHİR
      └── SERVICE B

relationship gerçek olabilir.

Bu durumda tek doctor profile:

• İki gerçek location relationship’i
• Gerçek service relationships’i

gösterebilir.

Bunun karşılığı:

• /kadikoy-dr-a-service-a
• /atasehir-dr-a-service-b

gibi kombinasyon landing pages değildir.

Person + service + location relationship yeni canonical entity yaratmaz.

Practitioner Google İşletme Profili Çok Lokasyonlu Yapıda Nasıl Ele Alınmalı?

Website doctor profile mimarisi ile Google Business Profile architecture birebir aynı değildir.

Bir doktorun website üzerinde canonical profile’a sahip olması her location için Google Business Profile oluşturulabileceği anlamına gelmez.

Her practitioner-location ilişkisi için:

• Kişi public-facing mi?
• Gerçekten o doğrulanmış lokasyonda çalışıyor mu?
• Belirtilen saatlerde doğrudan ulaşılabilir mi?
• İşletme profile yapısı güncel Google kurallarıyla uyumlu mu?

kontrol edilmelidir.

“Dr. A üç şubede çalışıyor → üç GBP” otomatik bir SEO kuralı değildir.

Aynı Practitioner İçin Hizmet Sayısı Kadar GBP Açılmalı mı?

Hayır.

Bir doctor veya başka public-facing practitioner:

• Service A
• Service B
• Service C

ile ilişkili olabilir.

Bu hizmetlerin tamamı için ayrı ayrı practitioner Business Profile oluşturmak doğru model değildir.

Service relationships website’teki canonical practitioner ve treatment pages üzerinden gösterilebilir.

Clinic GBP ile Location Page Nasıl Eşleştirilmeli?

Çok lokasyonlu kliniklerde her gerçek clinic location için uygun Business Profile mevcutsa website destination olarak ilgili location page değerlendirilebilir.

Örneğin:

KADIKÖY GBP
      ↓
/lokasyonlar/kadikoy

ATAŞEHİR GBP
      ↓
/lokasyonlar/atasehir

Bu DigitalPlus information architecture yaklaşımıdır.

Google’ın zorunlu URL formatı değildir.

Amaç:

Google local surface → corresponding real-world location → corresponding website location owner

ilişkisini kullanıcı açısından açık hale getirmektir.

Bütün Clinic GBP’leri Homepage’e Göndermek Yanlış mı?

Mutlak olarak her durumda yanlış değildir.

Ancak gerçek çok lokasyonlu yapılarda her GBP farklı fiziksel şubeyi temsil ederken bütün profilleri generic homepage’e göndermek location-specific kullanıcı journey’sini zayıflatabilir.

Güçlü location pages mevcutsa ilgili profile’ın ilgili location URL’ye gitmesi daha açık bir architecture oluşturabilir.

Özellikle:

• Adres
• Telefon
• Doktor kadrosu
• Service availability
• Çalışma saatleri

şubeye göre değişiyorsa location destination daha anlamlı olabilir.

GBP Website ve Telefon Bilgileri Lokasyonla Tutarlı Olmalı

Google Business Profile ile website aynı gerçek fiziksel entity hakkında çelişkili bilgi sunmamalıdır.

Kontrol edilmesi gerekenler:

• Business name
• Address
• Local phone
• Website destination
• Opening hours
• Current services
• Current practitioners

olabilir.

Örneğin Kadıköy şubesinin profile’ı Ataşehir adresini veya artık kurumda çalışmayan doktorları göstermemelidir.

Branşlar Her Location’da Aynı Olmak Zorunda mı?

Hayır.

Gerçek multi-location kliniklerde specialty availability farklı olabilir.

Örneğin:

KADIKÖY
├── DERMATOLOJİ
└── BESLENME

ATAŞEHİR
├── DERMATOLOJİ
└── ORTOPEDİ

Website location pages bu gerçek farklılığı göstermelidir.

Yanlış model bütün branches’ı bütün şubelere otomatik eklemektir.

Site architecture gerçek sağlık hizmet sunumunu takip etmelidir.

Hizmetler Her Şubede Aynı Değilse Ne Yapılmalı?

Aynı prensip treatments ve services için de geçerlidir.

Örneğin:

TREATMENT A
→ KADIKÖY
→ ATAŞEHİR

TREATMENT B
→ SADECE KADIKÖY

TREATMENT C
→ SADECE ATAŞEHİR

Treatment page:

Bu hizmet hangi locations’da sunuluyor?

sorusunu cevaplayabilir.

Location page ise:

Bu şubede hangi services sunuluyor?

sorusunu cevaplar.

Relationship iki yönde de internal links ile gösterilebilir.

Branş ile Treatment Ownership Çok Lokasyonlu Yapıda Nasıl Korunmalı?

Location katmanı eklendiğinde branş ve treatment ownership değişmez.

Örneğin:

DERMATOLOJİ
       ↓
TREATMENT A
     /     \
    ↓       ↓
KADIKÖY  ATAŞEHİR

Specialty page dermatoloji intent’ini, treatment page Service A intent’ini, location pages ise fiziksel şubeleri temsil eder.

Location eklemek treatment’ın primary owner’ını otomatik değiştirmez.

Branş ve service ayrımını Klinik Sitelerinde Branş Sayfası mı Hizmet Sayfası mı? rehberinde ayrıca ele alıyoruz.

Multi-Location Navigation Nasıl Kurulmalı?

Gerçek birden fazla şube varsa kullanıcı locations’ı kolayca keşfedebilmelidir.

Örneğin ana navigation veya uygun organization section:

Lokasyonlarımız

• Kadıköy
• Ataşehir
• Bakırköy

location pages’e crawl edilebilir links verebilir.

Ana clinic page de bütün current locations’a yönlendirebilir.

Her location page ise:

• Gerçek doctors
• Gerçek branches
• Gerçek treatments

ile bağlantı kurabilir.

Çok Lokasyonlu Klinik Internal Linking Graph’ı

                     CLINIC
                       │
             ┌─────────┴─────────┐
             ↓                   ↓
         KADIKÖY             ATAŞEHİR
         /     \              /     \
        ↓       ↓            ↓       ↓
    DOCTORS   SERVICES    DOCTORS   SERVICES
        \       /            \       /
         \     /              \     /
         CANONICAL SERVICE / DOCTOR OWNERS

Bu graph’ta:

• Organization → locations
• Location → doctors
• Location → services
• Doctor → current locations
• Service → available locations

relationship’leri gösterilebilir.

Ancak:

her ok = yeni URL

değildir.

Internal Link Anchor’ları Nasıl Olmalı?

Anchor text hedef sayfanın görevini açıklayacak kadar doğal ve anlaşılır olmalıdır.

Örneğin organization page’den:

• Kadıköy kliniğimiz
• Ataşehir şubemiz

gibi contextual links kullanılabilir.

Treatment page’den:

• Kadıköy lokasyonu
• Ataşehir kliniği

gibi kullanıcı açısından anlamlı anchors kullanılabilir.

Her linki exact-match local keyword kampanyasına çevirmek gerekmez.

Location Pages Orphan Kalmamalı

Yeni şube sayfasının yalnız sitemap’e eklenmesi yeterli değildir.

Önemli location page uygun olduğunda:

• Homepage
• Organization page
• Location navigation
• Current doctor profiles
• Relevant treatment pages

üzerinden crawl edilebilir links almalıdır.

Sitemap keşfe yardımcı olur; gerçek information architecture’ın yerine geçmez.

Klinik, doctor, treatment ve location ilişkilerinin genel modelini Doktor ve Klinik Sitelerinde SEO Sayfa Mimarisi rehberinde ele alıyoruz.

Location Pages’de Duplicate Content Nasıl Önlenir?

Çok lokasyonlu sitelerde en kolay hata tek şablonu çoğaltmaktır.

Örneğin:

“ABC Klinik Kadıköy olarak kaliteli sağlık hizmetleri sunuyoruz…”

metnindeki yalnız “Kadıköy” kelimesini:

• Ataşehir
• Bakırköy
• Beşiktaş

ile değiştirmek bağımsız page value üretmez.

Gerçek location page farkları şunlardan gelebilir:

• Adres
• Telefon
• Working hours
• Doctor roster
• Specialties
• Services
• Şubeye özgü fiziksel bilgiler
• Ulaşım bilgileri
• Gerçek iletişim ve appointment journey

Lokasyon sayfasının özgünlüğü copywriter yaratıcılığından değil, gerçek şube farklılığından gelmelidir.

Şubeye Özgü Olmayan Treatment Metinleri Location Page’e Kopyalanmalı mı?

Hayır.

Bir treatment’ın kapsamlı açıklaması canonical treatment owner üzerinde bulunabilir.

Location page:

“Bu hizmet bu şubede sunuluyor.”

relationship’ini göstermeli ve ilgili treatment URL’ye bağlantı verebilir.

Aynı uzun treatment copy’nin her şubede tekrar edilmesi location page’in görevini bulanıklaştırabilir.

Structured Data Çok Lokasyonlu Kliniklerde Nasıl Kullanılmalı?

Structured data görünür gerçek location bilgilerinin makineler açısından daha açık ifade edilmesine yardımcı olabilir.

Location page üzerinde uygun yapı kullanıldığında:

• Address
• Telephone
• Opening hours
• Geo information

gibi location-specific bilgiler açıklanabilir.

Ana homepage veya organization page üzerinde Organization bilgileri de değerlendirilebilir.

Ancak:

schema gerçek şube yaratmaz.

Olmayan Beşiktaş kliniğini JSON-LD içine eklemek Beşiktaş’ta sağlık kuruluşu açmış olmak değildir.

Önce real-world entity, sonra website representation, ardından uygun markup gelir.

Her Location Page’e LocalBusiness Markup Eklenmeli mi?

Gerçek location page ve uygun business type söz konusuysa location-specific structured data değerlendirilebilir.

Ancak seçilen schema type:

• Gerçek kuruluş türüyle
• Sayfada görünür bilgilerle
• Mevcut Google structured data kurallarıyla

uyumlu olmalıdır.

Structured data seçiminde “en spesifik schema daha çok rank alır” gibi bir mantık kullanılmamalıdır.

Canonical Çok Lokasyonlu Kliniklerde Nasıl Düşünülmeli?

Gerçekten farklı kullanıcı ihtiyacı taşıyan, bağımsız indexable location pages kendi canonical owner’ları olarak değerlendirilebilir.

Örneğin:

• /lokasyonlar/kadikoy
• /lokasyonlar/atasehir

gerçekten farklı fiziksel locations’ı temsil ediyorsa her iki page’in de kendi canonical sinyalini taşıması temiz başlangıç modelidir.

Yanlış örnek:

Üç ayrı location page oluşturup üçünün canonical’ını homepage’e vermektir.

Bu durumda ayrı location URL oluşturmanın index ownership mantığı zaten zayıflar.

Duplicate veya teknik variant URL’lerde canonical kararı ayrıca teknik audit ile verilmelidir.

Location Pages XML Sitemap’te Olmalı mı?

Indexable ve canonical olarak arama sonuçlarında bulunması istenen location pages XML sitemap’e dahil edilebilir.

Sitemap içinde:

• 404
• Redirect
• Noindex
• Duplicate location variant

URL’leri tutulmamalıdır.

Canonical, sitemap ve crawl kontrollerini Teknik SEO kapsamında ayrıca değerlendiriyoruz.

Location Page ile GBP Bilgileri Uyuşmazsa Ne Olur?

Website ve Business Profile aynı real-world location hakkında farklı bilgiler sunmamalıdır.

Örneğin:

• GBP’de eski adres
• Website’de yeni adres
• Location page’de eski telefon
• GBP’de güncel çalışma saatleri
• Website’de kurumdan ayrılmış doktor

gibi inconsistencies kullanıcı açısından da kötü deneyim oluşturur.

Multi-location audit sırasında:

location-by-location entity consistency

kontrol edilmelidir.

NAP Çok Lokasyonlu Kliniklerde Nasıl Yönetilmeli?

Her location’ın kendi:

• Name
• Address
• Phone

bilgileri doğru olmalıdır.

Ancak sağlık local architecture yalnız klasik NAP kontrolüyle bitmez.

Ayrıca:

• Current doctor roster
• Specialty availability
• Service availability
• Opening hours
• Website destination
• Business Profile

ilişkileri de güncel tutulmalıdır.

Çok Lokasyonlu Clinic SEO ile Generic Yerel SEO Arasındaki Fark Nedir?

Generic local SEO:

• Business Profile
• Location
• NAP
• Reviews
• Local landing pages

gibi genel operasyonları kapsayabilir.

Çok lokasyonlu health architecture’a:

• Doctor relationships
• Specialty availability
• Treatment availability
• Health regulation
• Practitioner Business Profiles
• Doctor lifecycle

katmanları da eklenir.

Genel operasyonu Yerel SEO hizmetimizde, clinic-specific local konuları ise Klinikler İçin Yerel SEO rehberinde ele alıyoruz.

Bir Şube Kapanırsa SEO’da Ne Yapılmalı?

Kapanan location page’i otomatik homepage’e 301 yönlendirmek doğru yaklaşım değildir.

Önce gerçek durum değerlendirilmelidir.

Sorular:

• Şube tamamen kapandı mı?
• Başka location bu şubenin yerine geçti mi?
• Şube yalnız taşındı mı?
• URL organik trafik veya backlink alıyor mu?
• Kullanıcının aradığı eski location için anlamlı replacement var mı?

Sonrasında:

• UPDATE
• 301
• 404
• 410

seçeneklerinden uygun olanı değerlendirilebilir.

Kapanan her şube homepage’e gitmez.

Şube Taşınırsa Ne Yapılmalı?

Aynı physical location entity operasyonel olarak yeni adrese taşınıyorsa yalnız location page metnini değiştirmek yeterli değildir.

Kontrol edilmesi gerekenler:

• Website address
• Google Business Profile
• Phone
• Opening hours
• Structured data
• Maps/location references
• Doctor locations
• Service availability
• Internal links

olabilir.

Location URL’nin değiştirilip değiştirilmeyeceği slug’ın mevcut yapısına ve site architecture’a göre ayrıca değerlendirilmelidir.

Doktor Bir Şubeden Ayrılır Ama Klinikte Kalırsa?

Örneğin Dr. A artık Kadıköy’de çalışmıyor ancak Ataşehir’de devam ediyor olabilir.

Bu durumda doctor entity kaybolmaz.

Değişen relationship:

ESKİ:
DR. A
→ KADIKÖY
→ ATAŞEHİR

YENİ:
DR. A
→ ATAŞEHİR

Güncellenmesi gerekenler:

• Doctor profile
• Kadıköy location page
• Ataşehir location page
• Relevant services
• Structured data
• Varsa Business Profile ilişkileri

olabilir.

Doktor Klinikten Tamamen Ayrılırsa?

Bu daha geniş practitioner lifecycle problemidir.

Doctor:

• Profile
• Locations
• Treatments
• Specialties
• Authored content
• Reviewed content
• Business Profile

ile ilişkili olabilir.

Doctor relationship değişikliğinin treatment veya clinic entity lifecycle ile aynı şey olmadığını Doktor Klinikten Ayrıldığında SEO rehberinde ayrıca ele alıyoruz.

Yeni Şube Açıldığında Mevcut Treatment URL’leri Kopyalanmalı mı?

Hayır.

Yeni branch öncelikle yeni bir location relationship oluşturur.

Örneğin ABC Klinik Bakırköy açıldıysa:

• Yeni gerçek location page değerlendirilebilir
• Organization → Bakırköy relationship eklenebilir
• Bakırköy’de çalışan doctors bağlanabilir
• Bakırköy’de sunulan existing treatments bağlanabilir
• Uygun Business Profile oluşturulabilir

Ancak bütün:

/treatment-a

/treatment-b

/treatment-c

sayfalarının:

/bakirkoy-treatment-a

/bakirkoy-treatment-b

/bakirkoy-treatment-c

kopyalarını üretmek gerekmez.

Yeni Location Açıldığında Internal Linking Nasıl Güncellenmeli?

Yeni location yalnız yeni URL oluşturmak değildir.

Site graph’a eklenmelidir.

Kontrol:

• Homepage → new location
• Organization → new location
• Relevant doctors → new location
• Relevant treatments → new location
• New location → doctors
• New location → services

üzerinden yapılabilir.

LocalBusiness Structured Data GBP’nin Yerine Geçer mi?

Hayır.

Structured data website üzerindeki location bilgilerini açıklamaya yardımcı olur.

Google Business Profile ise ayrı local product ve entity surface’idir.

Schema:

• GBP oluşturmaz
• Fake şubeyi gerçek yapmaz
• Yanlış adresi düzeltmez
• Doctor eligibility oluşturmaz
• Local ranking garantisi vermez

Location Pages Sağlık Mevzuatından Bağımsız mı?

Hayır.

Location page sağlık kuruluşunun dijital bilgilendirme yüzeylerinden biridir.

Gerçek:

• Adres
• İletişim
• Çalışma saatleri
• Hasta kabul edilen branşlar
• Sağlık meslek mensupları

gibi bilgiler açık biçimde sunulabilir.

Ancak location page’i:

• “Bölgenin en iyi kliniği”
• “Kesin sonuç”
• “Rakipsiz tedavi”
• Garanti
• Yanıltıcı superiority claim
• Gerçekte sunulmayan service

gibi ifadelerle generic local commercial landing page’e çevirmemek gerekir.

Local SEO hedefi sağlık tanıtım mevzuatını ortadan kaldırmaz.

DigitalPlus SEO architecture ve search opportunity’yi planlar; nihai sağlık mevzuatı ve hukuki uygunluk kurumun gerekli hukuk ve uyum süreçlerinde ayrıca değerlendirilmelidir.

Çok Lokasyonlu Kliniklerde En Sık Yapılan SEO Hataları

1. Gerçek Olmayan İlçeler İçin Location Page Açmak

Fiziksel şube yokken local keyword üzerinden entity yaratılır.

2. Her Location × Treatment Kombinasyonu İçin URL Üretmek

Gerçek relationship seri landing page fabrikasına dönüşür.

3. Aynı Doctor İçin Her Şubede Ayrı Profil Açmak

Canonical person owner parçalanır.

4. Bütün Hizmetlerin Bütün Şubelerde Sunulduğunu Varsaymak

Website gerçek service availability ile çelişir.

5. Bütün GBP’leri Generic Homepage’e Göndermek

Gerçek location-specific journey mevcutken organization page tek destination yapılır.

6. Location Template’i Yalnız Şehir Adıyla Çoğaltmak

Gerçek location-specific information gain oluşmaz.

7. Kapanan Şubeyi Yıllarca Aktif Göstermek

Organization-location relationship güncelliğini kaybeder.

8. Doctor Roster’ı Güncellememek

Kullanıcı artık o lokasyonda çalışmayan doctor’ı görmeye devam eder.

9. Website ve GBP Bilgilerini Birbirinden Koparmak

Address, phone, hours veya website destination tutarsız kalır.

10. Structured Data ile Fake Location Üretmeye Çalışmak

Markup real-world entity’nin yerine kullanılmaya çalışılır.

11. Yeni Şube Açılınca Bütün Treatment Sayfalarını Kopyalamak

Service owner sayısı gerçek search intent yerine location sayısıyla çoğalır.

12. Location Pages’i Orphan Bırakmak

Şube yalnız sitemap’te yaşar; organization, doctors ve services ile gerçek internal relationship kurulmaz.

Çok Lokasyonlu Klinik URL Ownership Matrisi

Query / Intent	Muhtemel Primary Owner
Klinik markası	Homepage / Organization
Şube adı	Location page
Doctor adı	Doctor profile
Branş	Specialty page, gerekiyorsa
Treatment / service	Canonical treatment page
Treatment + location	Ayrı intent doğrulanırsa ayrıca değerlendir
Doctor + location	Canonical doctor profile + location relationship
Informational sağlık sorgusu	Supporting health content

Location relationship yeni primary owner yaratmak zorunda değildir.

Multi-Location Clinic Entity Modeli

                         ORGANIZATION
                         /     |     \
                        ↓      ↓      ↓
                  LOCATION A LOCATION B LOCATION C
                    /   \       / \       /   \
                   ↓     ↓     ↓   ↓     ↓     ↓
               DOCTORS SERVICES ...    DOCTORS SERVICES
                    \      \           /
                     \      ↓         /
                       CANONICAL
                   SPECIALTY / SERVICE
                        OWNERS

Bu model URL path’i değil entity relationships’i gösterir.

Gerçek implementation site büyüklüğüne ve existing architecture’a göre daha sade veya daha karmaşık olabilir.

Yeni Location Page İçin Karar Ağacı

Yeni location keyword bulundu.

↓

Gerçek fiziksel şube var mı?

Hayır → location landing page açma.

Evet ↓

Kullanıcının şubeye özgü bilgi ihtiyacı var mı?

Hayır → organization page içinde göstermeyi değerlendir.

Evet ↓

Gerçek location-specific bilgi üretilebiliyor mu?

Hayır → clone page açma.

Evet ↓

Bağımsız location page değerlendir.

Location + Treatment İçin Karar Ağacı

Treatment A Kadıköy’de sunuluyor.

↓

Gerçek Kadıköy location var mı?

Hayır → yeni URL açma.

Evet ↓

Ana treatment owner mevcut mu?

Evet ↓

Location-specific search intent gerçekten ayrı mı?

Hayır → treatment ↔ location relationship ile çöz.

Evet ↓

SERP bağımsız local service page destekliyor mu?

Hayır → existing treatment + location pages ile çöz.

Evet ↓

Bağımsız user journey ve özgün content value var mı?

Hayır → kombinasyon page açma.

Evet ↓

Location-treatment URL ayrıca değerlendir.

Çok Lokasyonlu Klinik SEO Checklist

Organization

• Parent clinic entity belli mi?
• Brand bilgisi tutarlı mı?
• Current locations açık mı?

Locations

• Bütün pages gerçek şubeleri mi temsil ediyor?
• Fake district pages var mı?
• Her location’ın canonical URL’si belli mi?
• Adres doğru mu?
• Telefon doğru mu?
• Working hours doğru mu?

Practitioners

• Hangi doctor hangi location’da çalışıyor?
• Aynı person için duplicate profiles var mı?
• Doctor profiles current locations’ı gösteriyor mu?
• Location pages current doctor roster’ı gösteriyor mu?
• GBP eligibility ayrıca kontrol edildi mi?

Specialties

• Hangi branş hangi location’da mevcut?
• Bütün specialties yanlışlıkla bütün locations’a kopyalanmış mı?
• Specialty pages location relationships’i doğru gösteriyor mu?

Services

• Hangi treatment hangi location’da sunuluyor?
• Tek canonical service owner belli mi?
• Location × treatment pages gereksiz çoğalmış mı?
• Service pages available locations’ı doğru gösteriyor mu?

Local

• Gerçek clinic GBP’leri mevcut mu?
• Website destination doğru mu?
• Address consistency doğru mu?
• Phone doğru location’a mı ait?
• Working hours güncel mi?
• Practitioner Business Profiles güncel kurallara uygun mu?

Internal Linking

• Organization → locations links var mı?
• Location → doctors links var mı?
• Location → services links var mı?
• Doctor → current locations links var mı?
• Service → available locations links var mı?
• Location pages orphan mı?

Technical

• Location URLs 200 mü?
• Indexable mı?
• Canonical doğru mu?
• Sitemap yalnız current canonical locations’ı içeriyor mu?
• Duplicate location URLs var mı?
• Structured data görünür gerçeklikle uyumlu mu?

Content Quality

• Her location page gerçek farklılık sunuyor mu?
• Yalnız şehir adı değiştirilmiş template mi?
• Long treatment copy bütün locations’da duplicate mi?
• Gerçek doctor/service differences bulunuyor mu?

Lifecycle

• Kapanan branches güncellendi mi?
• Taşınan branches güncellendi mi?
• Yeni locations site graph’a bağlandı mı?
• Ayrılan doctors location pages’den kaldırıldı mı?
• Service availability güncel mi?

Çok Lokasyonlu Kliniklerde Neyi Ölçüyoruz?

Location Visibility

• Brand + branch queries
• Specialty + location queries
• Service + location queries

Landing Page Performance

• Location page impressions
• Location page clicks
• Query → location ownership
• Wrong-page ranking

Service Ownership

• Local query ana treatment owner’a mı gidiyor?
• Location page treatment intent’i gereksiz yere çalıyor mu?
• Location-treatment URLs arasında switching var mı?

User Actions

Tracking altyapısı uygunsa:

• Telefon tıklaması
• Randevu linkine geçiş
• Form
• İletişim
• Yol tarifi gibi uygun local actions

location bazında ölçülebilir.

Çok lokasyonlu SEO’da toplam site trafiği kadar hangi şubenin hangi arama talebini karşıladığı da önemlidir.

Multi-Location Yapıyı SEO Audit’te Nasıl Kontrol Ediyoruz?

Çok lokasyonlu klinik audit’i yalnız NAP kontrolü değildir.

Her location için:

• Entity reality
• URL ownership
• Indexability
• Canonical
• Internal links
• Doctors
• Specialties
• Services
• GBP relationships
• Structured data
• Measurement

birlikte değerlendirilmelidir.

Sağlık sitelerindeki daha geniş audit sistemini Sağlık SEO Audit Checklist içeriğinde ele alıyoruz.

Şubeleri Çoğaltırken URL’leri Kontrolsüz Çoğaltmayın

Bir kliniğin üç gerçek lokasyona sahip olması organik aramada üç ayrı location entity bulunduğu anlamına gelebilir.

Ancak:

3 location × 20 treatment × 10 doctor

hesabından 600 landing page çıkarmak doğru SEO architecture değildir.

DigitalPlus çok lokasyonlu clinic SEO çalışmalarında:

organization → real location → practitioner → specialty → treatment

ilişkilerini önce gerçek işletme yapısı üzerinden tanımlar.

Ardından her query cluster için primary canonical owner belirler.

Yeni location-treatment veya doctor-location URL yalnız bağımsız search intent ve gerçek kullanıcı değeri varsa değerlendirilir.

Relationship ≠ new URL.

Klinik SEO Hizmetini İncele

Yerel SEO Hizmetini İncele

Sıkça Sorulan Sorular

Her klinik şubesi için ayrı SEO sayfası açılmalı mı?

Gerçek fiziksel şube ve şubeye özgü kullanıcı ihtiyacı bulunuyorsa bağımsız location page anlamlı olabilir. Gerçek şube bulunmadan yalnız ilçe keywordü için landing page açılmamalıdır.

Her location için ayrı Google İşletme Profili olabilir mi?

Gerçek ve Google Business Profile uygunluk koşullarını karşılayan ayrı işletme locations için ayrı profiles kullanılabilir. Aynı gerçek location için duplicate organization profiles oluşturulmamalıdır.

Her şube için treatment sayfaları tekrar açılmalı mı?

Hayır. Tek canonical treatment owner birden fazla gerçek location ile ilişkilendirilebilir. Location-treatment page yalnız bağımsız local intent ve gerçek page value varsa ayrıca değerlendirilir.

Bir doctor iki şubede çalışıyorsa iki profil sayfası gerekir mi?

Genellikle hayır. Tek canonical doctor profile birden fazla gerçek location relationship taşıyabilir.

Bir doktor iki şubede çalışıyorsa iki Google Business Profile açılabilir mi?

Website profile sayısından otomatik sonuç çıkarılamaz. Google practitioner eligibility’si her doğrulanmış location için kişinin public-facing ve belirtilen saatlerde doğrudan erişilebilir olması gibi koşullar üzerinden değerlendirilmelidir.

Clinic GBP homepage’e mi location page’e mi bağlanmalı?

Tek lokasyonlu yapılarda homepage doğal destination olabilir. Gerçek multi-location yapıda ilgili şubeyi temsil eden canonical location page daha açık kullanıcı ve entity ilişkisi sağlayabilir. Bu DigitalPlus’ın information architecture yaklaşımıdır; Google’ın zorunlu URL formatı değildir.

Location page’de bütün services listelenmeli mi?

Yalnız o şubede gerçekten sunulan hizmetler gösterilmelidir. Organization’ın bütün hizmet kataloğu bütün locations’a otomatik eklenmemelidir.

Treatment page’de locations gösterilmeli mi?

Hizmetin hangi gerçek şubelerde sunulduğu kullanıcı açısından önemliyse treatment owner üzerinde available locations gösterilebilir ve ilgili location pages’e bağlantı verilebilir.

Aynı treatment iki şubede varsa iki canonical treatment page gerekir mi?

Otomatik olarak hayır. Çoğu durumda tek service owner iki location relationship taşıyabilir.

Location pages birbirinin kopyası olabilir mi?

Hayır. Gerçek şubelerin address, doctors, services, hours ve başka operasyonel bilgileri farklıysa pages bu gerçek farklılıkları yansıtmalıdır. Yalnız şehir adını değiştiren template yaklaşımı bağımsız kullanıcı değeri üretmez.

Her ilçe için klinik landing page açılmalı mı?

Hayır. Gerçek location veya bağımsız local user need bulunmadan ilçe adları üzerinden seri pages üretilmemelidir.

Location pages kendi canonical’ını kullanmalı mı?

Gerçekten ayrı, indexable ve bağımsız location owners iseler self-referencing canonical temiz başlangıç modelidir. Duplicate veya variant URLs için canonical kararı ayrıca teknik olarak değerlendirilmelidir.

Location pages sitemap’e eklenmeli mi?

Canonical ve indexable location pages sitemap’e dahil edilebilir. Redirect, noindex, 404 veya duplicate location variants sitemap’te tutulmamalıdır.

Şube kapanınca location page homepage’e 301 yapılmalı mı?

Otomatik olarak hayır. Şubenin taşınıp taşınmadığı, replacement location olup olmadığı, URL’nin search/backlink değeri ve kullanıcı ihtiyacı değerlendirilerek update, 301, 404 veya 410 kararı verilmelidir.

Şube taşınırsa yeni URL açılmalı mı?

Her zaman değil. Aynı location entity’nin adresi değişmiş olabilir. URL yapısı, mevcut performans ve kullanıcı görevi değerlendirilerek mevcut page güncellenebilir veya gerekiyorsa migration planlanabilir.

Structured data ayrı klinik şubesi oluşturur mu?

Hayır. Structured data yalnız sayfadaki gerçek organization veya location bilgisini arama motorlarına açıklamaya yardımcı olur. Gerçek fiziksel varlığın yerine geçmez.

Çok lokasyonlu klinik SEO ile klinikler için yerel SEO aynı içerik mi?

Hayır. Klinik local SEO daha genel GBP, practitioner, NAP ve local visibility sistemini kapsar. Bu rehber ise tek organization altında birden fazla gerçek location bulunduğunda URL ownership, doctor roster, service availability ve location lifecycle problemlerini sahiplenir.

Kaynaklar

• Google Business Profile: Guidelines for Representing Your Business on Google
• Google Search Central: LocalBusiness Structured Data
• Google Search Central: Organization Structured Data
• Google Search Central: Canonical URL Guidelines
• Google Search Central: Link Best Practices
• T.C. Sağlık Bakanlığı: Sağlık Hizmetlerinde Tanıtım ve Bilgilendirme Faaliyetleri Hakkında Yönetmelik