İçeriğe geç
Digital Plus
Genel

Çok Şubeli İşletmeler İçin Yerel SEO: Şube ve Lokasyon Mimarisi

Digitalplus çok şubeli işletmeler yerel SEO stratejisi: Ana marka hiyerarşisinde Kadıköy, Beşiktaş ve Bakırköy şubeleri için Google İşletme Profili ve landing page (giriş sayfası) bağlantı şeması.

Bir işletmenin aynı marka altında birden fazla fiziksel lokasyonda faaliyet göstermesi yerel SEO’yu yalnız “birkaç Google İşletme Profili daha açma” probleminden çıkarır.

Artık yönetilmesi gereken yapı şudur:

ANA MARKA
    │
    ├── ŞUBE A
    ├── ŞUBE B
    └── ŞUBE C
          │
          ├── GBP
          ├── LANDING PAGE
          ├── TELEFON
          ├── ÇALIŞMA SAATLERİ
          ├── HİZMETLER
          └── YORUMLAR

Bu yapıda her şube gerçek bir fiziksel location entity olabilir.

Ancak üç şube bulunması, her hizmet ve şehir kombinasyonu için onlarca yeni landing page gerektiği anlamına gelmez.

Çok şubeli SEO, aynı landing page’i şehir adı değiştirerek çoğaltmak değildir. Her gerçek şubenin marka, Google İşletme Profili ve web sitesi üzerindeki location owner’ı ile doğru ilişkilendirilmesidir.

DigitalPlus Yerel SEO çalışmalarında Google İşletme Profili, web sitesi, gerçek lokasyonlar ve dönüşüm ölçümünü aynı local search architecture içinde değerlendiriyoruz.

Çok Şubeli Yerel SEO Nedir?

Çok şubeli yerel SEO, aynı marka veya işletme ağı altında birden fazla gerçek fiziksel lokasyonun Google Arama, Google Haritalar ve web sitesi üzerinde doğru biçimde temsil edilmesini sağlayan SEO sistemidir.

Bu sistem yalnız:

  • Google İşletme Profili açmak
  • Adres eklemek
  • Şehir adını title’a yazmak
  • Her ilçeye landing page üretmek

değildir.

Asıl amaç:

marka → şube → GBP → landing page → hizmet → kullanıcı aksiyonu

ilişkisini doğru kurmaktır.

Örneğin bir markanın:

  • Kadıköy şubesi
  • Bakırköy şubesi
  • Beşiktaş şubesi

bulunuyorsa kullanıcının her location için doğru:

  • Adres
  • Telefon
  • Çalışma saatleri
  • Hizmet bilgisi
  • Google profili
  • Web sayfası

ile karşılaşması gerekir.

Çok Şubeli İşletme ile Hizmet Bölgesi İşletmesi Aynı Şey Değildir

Multi-location architecture kurulmadan önce işletmenin gerçekten fiziksel şubelere sahip olup olmadığı doğrulanmalıdır.

Çok Şubeli Fiziksel İşletme

Müşteri ayrı fiziksel locations’a gidebilir.

Örneğin:

  • Mağaza zinciri
  • Restoran zinciri
  • Klinik
  • Oto servis ağı
  • Eğitim merkezi
  • Spor salonu

Hizmet Bölgesi İşletmesi

İşletme müşteriyi kendi şubesinde ağırlamak yerine müşterinin bulunduğu yere gider.

Örneğin tek merkezden İstanbul genelinde çalışan bir temizlik şirketi sırf 20 ilçeye hizmet veriyor diye 20 gerçek şubeye sahip değildir.

Bu iki modelin Google İşletme Profili ve web sitesi architecture’ı farklıdır.

Tek merkezli service-area modelini Hizmet Bölgesi İşletmeleri Google’da Nasıl Konumlanmalı? rehberinde ayrıca ele alıyoruz.

Hizmet verilen bölge ≠ fiziksel şube.

Her Şube İçin Ayrı Sayfa Açılmalı mı?

Gerçek fiziksel şube bulunması bağımsız location page için güçlü bir sinyaldir ancak tek başına bütün durumlarda otomatik karar değildir.

Yeni şube URL’si açmadan önce QDP mantığıyla şu soruları kontrol ediyoruz:

  1. Gerçek fiziksel location var mı?
  2. Kullanıcı bu location hakkında bağımsız bilgiye ihtiyaç duyuyor mu?
  3. Şubenin kendi Google İşletme Profili bulunuyor veya uygun mu?
  4. Şubeye özgü adres ve iletişim bilgileri var mı?
  5. Çalışma saatleri farklı mı?
  6. Şubenin hizmet veya ürün availability’si farklı mı?
  7. Gerçek location-specific içerik üretilebiliyor mu?
  8. Başka bir URL zaten aynı local intent’i sahipleniyor mu?

Gerçek location + ayrı kullanıcı görevi + özgün işletme verisi varsa şube page anlamlı hale gelir.

Şube Sayfası Hangi Durumda Ayrı URL Hak Eder?

Gerçek Fiziksel Lokasyon

En temel koşuldur.

Şube gerçekten var olmalı ve işletme orada faaliyet göstermelidir.

Sanal ofis, posta adresi veya sırf Maps görünürlüğü için alınmış adres gerçek şube değildir.

Ayrı Adres

Her branch farklı physical address ile temsil edilmelidir.

Ayrı Çalışma Saatleri

Şubeler farklı saatlerde çalışıyorsa kullanıcı bunu location page ve Business Profile üzerinde doğru görmelidir.

Ayrı Telefon

Mümkün olduğunda şubeye doğrudan ulaşan local telefon kullanılması location relationship’i daha açık hale getirir.

Tek merkezi call center kullanılıyorsa website’te hangi numaranın hangi lokasyon için kullanıldığı kullanıcı açısından yine açık olmalıdır.

Ayrı Ekip veya Hizmet

Her şube aynı operasyonu yürütmek zorunda değildir.

Örneğin:

KADIKÖY
├── Hizmet A
├── Hizmet B
└── Hizmet C

BAKIRKÖY
├── Hizmet A
└── Hizmet C

gibi gerçek farklılıklar bulunabilir.

Ayrı Google İşletme Profili

Gerçek ve uygun locations Google Business Profile tarafında da ayrı fiziksel işletme noktaları olarak temsil edilebilir.

Local Proof

Şubeye özgü gerçek:

  • Fotoğraflar
  • Ekip bilgileri
  • Proje veya uygulama örnekleri
  • Ulaşım bilgileri
  • Mağaza veya mekan detayları

page’in kullanıcı değerini güçlendirebilir.

Ayrı Yorum Profili

Her fiziksel location kendi Business Profile üzerinde kendi müşteri deneyimi ve yorum geçmişini oluşturabilir.

Şubenin özgünlüğü copywriter’ın şehir adını değiştirmesinden değil, real-world işletme farklılıklarından gelmelidir.

Şube Sayfası Hangi Durumda Gereksiz Olabilir?

Örneğin website’te:

  • /kadikoy-magaza
  • /besiktas-magaza
  • /bakirkoy-magaza

sayfaları oluşturulmuş olsun.

Ancak üç page de:

  • Aynı adres dışındaki metni
  • Aynı telefon numarasını
  • Aynı hizmet listesini
  • Aynı fotoğrafları
  • Aynı CTA’yı

taşıyorsa gerçek location value zayıf olabilir.

Bu durumda yalnız keyword hedeflemek için şube sayfası üretmiş oluruz.

Location page’in varlık nedeni local keyword değil, gerçek location entity olmalıdır.

Lokasyon Sayfaları Nasıl Yapılandırılmalı?

URL yapısı kısa, açıklayıcı ve sürdürülebilir olmalıdır.

Örneğin:

/subeler/istanbul-kadikoy/

/subeler/istanbul-bakirkoy/

/subeler/istanbul-besiktas/

gibi bir yapı kullanılabilir.

Başka sitelerde:

/lokasyonlar/kadikoy/

veya doğrudan:

/kadikoy/

modeli daha uygun olabilir.

Folder adı SEO gücü üretmez. Önemli olan URL’nin kalıcı olması ve site içindeki location relationship’inin açık kurulmasıdır.

Şube Sayfasında Hangi Bilgiler Bulunmalı?

Location page gerçek kullanıcının şubeyi seçmesine yardımcı olmalıdır.

İşletme modeline göre şu alanlar değerlendirilebilir:

  • Şube adı
  • Tam adres
  • Telefon
  • Çalışma saatleri
  • Harita veya yön bilgisi
  • Gerçek şube fotoğrafları
  • Bu şubede sunulan hizmetler
  • Bu şubede bulunan ekip
  • Ulaşım bilgileri
  • Varsa otopark gibi operasyonel bilgiler
  • Uygun iletişim, rezervasyon veya randevu aksiyonu

Şube page’in amacı ilçe adını yirmi kez tekrarlamak değildir.

Kullanıcının “bu location bana uygun mu?” sorusunu cevaplamaktır.

Her Şube İçin Google İşletme Profili Açılmalı mı?

Gerçek ve uygun fiziksel location varsa ayrı Business Profile değerlendirilebilir.

Ancak her location Google Business Profile uygunluk şartlarını karşılamalıdır.

Google gerçek işletme konumunun doğru temsil edilmesini ve aynı business location için birden fazla organization profile oluşturulmamasını ister.

Örneğin gerçekten:

  • Kadıköy mağazası
  • Bakırköy mağazası
  • Beşiktaş mağazası

bulunuyorsa üç gerçek location ayrı profiles ile temsil edilebilir.

Ancak:

“İstanbul’un her ilçesinde Maps sonucu istiyoruz”

gerekçesi yeni şube profili oluşturmak için yeterli değildir.

Bir Google İşletme Profiline Birden Fazla Adres Eklenebilir mi?

Multi-location işletme modeli tek Business Profile içine birçok fiziksel adres doldurmak değildir.

Gerçek locations ayrı local entities olarak yönetilir.

İşletmenin çok sayıda şubesi varsa bunlar aynı hesap veya Business Group altında merkezi biçimde yönetilebilir.

10 veya daha fazla uygun location bulunan işletmeler Google’ın toplu location management araçlarından da yararlanabilir.

Merkezi yönetim, tek profile bütün şubeleri doldurmak anlamına gelmez.

Şubelerin Google İşletme Profili Adları Nasıl Olmalı?

Google zincir ve çok lokasyonlu işletmelerde isimlerin gerçek dünyadaki marka kullanımını yansıtmasını bekler.

Örneğin markanın bütün şubelerde gerçek adı:

ABC Coffee

ise profile adlarını sırf local keyword için:

  • ABC Coffee Kadıköy En İyi Kahve
  • ABC Coffee Bakırköy Kahveci
  • ABC Coffee Beşiktaş Cafe

şeklinde değiştirmemek gerekir.

Gerçek storefront veya marka kullanımında location-specific isim gerçekten bulunuyorsa bu ayrıca değerlendirilebilir.

Şube adı alanı local keyword title etiketi değildir.

Şubelerde Kategori Tutarlılığı Nasıl Yönetilmeli?

Aynı işi yapan zincir locations için ana kategorinin tutarlı olması gerekir.

Örneğin bütün locations gerçekten aynı mağaza modelini temsil ediyorsa aynı primary category kullanılması beklenebilir.

Ancak bazı locations farklı operation type taşıyorsa:

  • Mağaza
  • Dağıtım merkezi
  • Servis noktası

gibi alt gruplar ayrıca değerlendirilebilir.

Kategori seçimi bütün şubelere aynı keywordleri doldurma mekanizması değildir.

Google İşletme Profili’nin kategori, isim, çalışma saatleri ve diğer alanlarını Google İşletme Profili optimizasyon rehberinde ayrıca ele alıyoruz.

Ana Marka ile Şube Entity’leri Nasıl İlişkilendirilmeli?

Web sitesindeki ana brand veya organization page bütün locations için parent görevi taşıyabilir.

Örnek:

ABC MARKA
   │
   ├── KADIKÖY
   ├── BAKIRKÖY
   └── BEŞİKTAŞ

Homepage veya uygun şube hub’ı bütün current locations’a crawlable links verebilir.

Her location page de ana organization relationship’ini açık biçimde göstermelidir.

Örneğin:

  • Logo
  • Brand adı
  • Breadcrumb
  • Şubeler navigation’ı
  • Organization information

aynı marka ağına ait olduğunu kullanıcı için görünür hale getirir.

Ana marka ile şubeler arasındaki ilişki yalnız URL klasöründen kurulmaz.

Şube Hub Sayfası Gerekli mi?

Birden fazla gerçek location bulunan yapılarda:

/subeler/

gibi bir hub kullanıcı açısından yararlı olabilir.

Hub:

  • Tüm current locations’ı listeler
  • Şehir veya bölgeye göre seçim sağlar
  • Her location page’e crawlable link verir
  • Kullanıcıya en uygun şubeyi bulma imkanı sunar

Ancak iki küçük şubesi bulunan işletmede homepage aynı görevi gayet iyi karşılıyorsa sırf taxonomy yaratmak için thin `/subeler/` page açmak zorunlu değildir.

Hub’ın da gerçek kullanıcı görevi olmalıdır.

GBP Hangi Landing Page’e Bağlanmalı?

Çok şubeli yapıda her Business Profile’ın website linki mümkün olduğunca temsil ettiği physical location ile uyumlu olmalıdır.

Örneğin:

KADIKÖY GBP
     ↓
/subeler/istanbul-kadikoy/

BAKIRKÖY GBP
     ↓
/subeler/istanbul-bakirkoy/

gibi bir model kullanılabilir.

Bu bütün işletmeler için zorunlu teknik URL şablonu değildir.

Ancak kullanıcının Kadıköy profile’ından website’e tıklayıp generic homepage üzerinde yeniden Kadıköy adresini aramak zorunda kalması gereksiz friction yaratabilir.

Local profile → corresponding local landing page

ilişkisi multi-location yapılarda güçlü bir kullanıcı deneyimi sağlar.

Bütün GBP’leri Homepage’e Bağlamak Yanlış mı?

Mutlak olarak yanlış değildir.

Ancak location-specific landing pages gerçekten mevcut ve kullanıcıya daha doğru bilgi sağlıyorsa ilgili şube URL’si daha açıklayıcı destination olabilir.

Özellikle:

  • Telefonlar farklıysa
  • Çalışma saatleri farklıysa
  • Hizmet availability değişiyorsa
  • Ekip farklıysa
  • Rezervasyon sistemi location-specific ise

generic homepage daha zayıf destination haline gelebilir.

NAP Tutarlılığı Çok Şubeli İşletmelerde Nasıl Yönetilmeli?

NAP:

  • Name
  • Address
  • Phone

bilgilerini ifade eder.

Çok şubeli yapıda bütün locations’ın tek NAP bilgisine sahip olması beklenmez.

Asıl hedef:

her location’ın kendi bilgilerinin bütün ilgili yüzeylerde tutarlı olmasıdır.

Örneğin Kadıköy location için:

  • Website location page
  • Google Business Profile
  • İletişim sistemi
  • Relevant business directories

aynı güncel address ve phone bilgisini yansıtmalıdır.

Bakırköy location’ın farklı telefonu olması bir tutarsızlık değildir.

Yanlış olan Kadıköy profile’da Bakırköy telefonunun görünmesidir.

Şubeler Aynı Hizmetleri Veriyorsa Duplicate Content Nasıl Önlenir?

Çok şubeli işletmelerde aynı core services’in bütün locations’da bulunması normaldir.

Bu durumda location pages’i yapay olarak birbirinden ayırmak için anlamsız metin yazmak gerekmez.

Örneğin üç şubede de:

Hizmet A

sunuluyorsa hizmetin uzun commercial açıklamasını üç location page’e tamamen kopyalamak yerine canonical service page kullanılabilir.

Location page:

Bu hizmet bu şubede sunuluyor.

ilişkisini gösterir ve ana hizmet owner’a link verebilir.

Örneğin:

HİZMET A
   │
   ├── KADIKÖY
   ├── BAKIRKÖY
   └── BEŞİKTAŞ

Tek canonical service owner birden fazla real location relationship taşıyabilir.

Service × location relationship otomatik yeni landing page değildir.

Şube Sayfaları Nasıl Gerçekten Farklılaşır?

Gerçek differences şunlardan gelebilir:

  • Adres
  • Telefon
  • Çalışma saatleri
  • Ekip
  • Hizmet availability
  • Ürün availability
  • Gerçek mekan fotoğrafları
  • Ulaşım bilgileri
  • Otopark
  • Rezervasyon veya randevu akışı
  • Şubeye özgü operasyon

Şubeler gerçekten aynıysa bunun üzerine yapay “Kadıköy halkına yıllardır…” türü metin uydurmak bilgi değeri üretmez.

Location information gain gerçek dünyadaki location differences’tan çıkar.

Her Hizmet × Şube Kombinasyonu İçin URL Açılmalı mı?

Hayır.

Örneğin dört şube ve on hizmet bulunan bir işletme:

4 × 10 = 40

kombinasyon oluşturabilir.

Bunun üzerine:

  • 4 şube page
  • 10 service page

yerine 40:

/kadikoy-hizmet-a

/bakirkoy-hizmet-a

/besiktas-hizmet-a

gibi landing page üretmek zorunlu değildir.

Yeni service-location URL ancak:

  • Bağımsız local search demand
  • Ayrı SERP
  • Gerçek location
  • Gerçek service availability
  • Bağımsız user journey
  • Özgün page value

birlikte doğrulanıyorsa değerlendirilmelidir.

Excel çarpım tablosu site mimarisi değildir.

Şubeler Arası Internal Linking Nasıl Kurulmalı?

Location pages’in birbirleriyle ve parent organization ile ilişkisi crawlable links üzerinden kurulmalıdır.

                 ANA MARKA
                    ↓
                ŞUBELER
             /      |      \
            ↓       ↓       ↓
        KADIKÖY  BAKIRKÖY  BEŞİKTAŞ
            ↓       ↓       ↓
         SERVICES / PRODUCTS

Homepage → Şubeler

Ana marka bütün current locations’a navigation sağlayabilir.

Şube Hub → Location Pages

Varsa `/subeler/` hub’ı bütün gerçek branch pages’e link verir.

Location → Hizmet

Şubede gerçekten sunulan services’a bağlantı verilebilir.

Hizmet → Location

Hizmetin hangi şubelerde sunulduğu kullanıcı açısından önemliyse canonical service page ilgili locations’a bağlantı verebilir.

Location → Diğer Location

Kullanıcıya “diğer şubeler” navigation’ı sunulabilir.

Ancak her paragrafın içine bütün şubelerin exact-match anchor’larını basmak gerekmez.

Şube Sayfaları Orphan Bırakılmalı mı?

Hayır.

Gerçek location page yalnız XML sitemap içinde yaşayarak güçlü site architecture oluşturmaz.

Önemli location pages uygun olduğunda:

  • Homepage
  • Şube hub’ı
  • İlgili service pages
  • İletişim sayfası
  • Location navigation

üzerinden crawlable links almalıdır.

Sitemap keşfe yardımcı olabilir ancak internal architecture’ın yerine geçmez.

Şube Sayfalarının Canonical Yapısı Nasıl Olmalı?

Gerçekten farklı physical locations’ı temsil eden ve bağımsız indexlenmesi istenen branch pages çoğu durumda kendi canonical owner’ları olarak değerlendirilir.

Örneğin:

/subeler/kadikoy/

ve:

/subeler/bakirkoy/

iki farklı physical location’ı temsil ediyorsa ikisini de homepage’e canonical etmek branch ownership’i zayıflatır.

Ayrı location entity için ayrı indexable page kararı verilmişse canonical stratejisi de bunu desteklemelidir.

Şube Sayfaları XML Sitemap’e Eklenmeli mi?

Search’te bulunması istenen canonical location pages sitemap’e dahil edilebilir.

Sitemap’te:

  • Kapanmış şubeler
  • 301 olan eski URL’ler
  • Noindex pages
  • Duplicate branch variants

tutulmamalıdır.

Şube Yorumları Nasıl Yönetilmeli?

Çok şubeli işletmede yorumlar mümkün olduğunca gerçek müşteri deneyiminin yaşandığı location ile ilişkili olmalıdır.

Örneğin kullanıcı Kadıköy şubesinden hizmet aldıysa yorum isteği Kadıköy Business Profile’a yönlendirilebilir.

Böylece:

  • Şube bazlı müşteri deneyimi
  • Operasyon kalitesi
  • Location reputation

daha doğru ölçülebilir.

Yorum talebinde:

  • Yalnız memnun müşterileri filtrelememek
  • Belirli yıldız sayısı istememek
  • Yorum karşılığında teşvik sunmamak
  • Gerçek müşterilere tarafsız biçimde talep göndermek

daha sağlıklı süreç oluşturur.

Bütün Şubelerin Yorumlarını Tek Profile Toplamak Doğru mu?

Gerçek fiziksel locations ayrı Business Profiles tarafından temsil ediliyorsa müşteri deneyiminin de ilgili profile üzerinde oluşması daha doğal modeldir.

Örneğin on şubeli bir zincirin bütün müşterilerini yalnız merkez ofis profile’ına yorum bırakmaya yönlendirmesi location-specific reputation bilgisini kaybettirebilir.

Review architecture real customer journey’yi takip etmelidir.

Şube Yorum Sayıları Aynı Olmalı mı?

Hayır.

Locations farklı:

  • Müşteri hacmine
  • Açılış tarihine
  • Operasyon yoğunluğuna

sahip olabilir.

Bu nedenle bütün şubeler için aylık aynı sayıda yorum üretmeye çalışmak organik bir review programı değildir.

Hedef yapay simetri değil, gerçek müşteri deneyimlerinin düzenli biçimde görünür hale gelmesidir.

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

Bir physical location kalıcı olarak kapanıyorsa iki ayrı sistem güncellenmelidir:

  • Google Business Profile
  • Website location URL

Business Profile

Gerçekten kapanan şube profile’ı uygun biçimde permanently closed olarak güncellenmelidir.

Website URL

Şube URL’si için otomatik:

homepage’e 301

kuralı kullanılmamalıdır.

Önce:

  • Şubenin replacement location’ı var mı?
  • Şube başka adrese taşındı mı?
  • URL backlink alıyor mu?
  • Search demand devam ediyor mu?
  • Kullanıcıya açıklanması gereken kapanış bilgisi var mı?

kontrol edilmelidir.

Sonrasında:

  • Sayfayı geçici olarak güncelleme
  • 301
  • 404
  • 410

gibi teknik aksiyonlardan uygun olanı seçilebilir.

Kapanan her location ana sayfaya gönderilmez.

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

Aynı işletme location’ı farklı adrese taşınıyorsa otomatik olarak yeni bir Business Profile açmak doğru başlangıç değildir.

Mevcut profile’ın adresi güncellenebilir ve Google yeniden verification isteyebilir.

Website tarafında da:

  • Adres
  • Telefon
  • Çalışma saatleri
  • Harita
  • Structured data
  • Internal links
  • Location page içeriği

güncellenmelidir.

Location page slug’ı adres veya semt değişimine çok sıkı bağlıysa URL migration ihtiyacı ayrıca değerlendirilir.

Şube Taşındığında Yorumlar Kaybolur mu?

Aynı işletme adıyla gerçek bir physical relocation gerçekleştiğinde mevcut Business Profile’ı güncellemek, yorum geçmişini korumak açısından yeni profile oluşturmaktan daha doğru başlangıç modelidir.

Google uygun taşınma senaryolarında yorumları yeni location’a taşıyabilir.

Bu nedenle yalnız adres değişti diye sıfırdan yeni profile açıp eski profile’ı terk etmek gereksiz entity duplication oluşturabilir.

Şube Yeni Bir Adrese Taşındığında Eski Location Page Ne Olmalı?

İşletme aynı branch entity olarak devam ediyor ancak address değişiyorsa çoğu durumda mevcut page’in güncellenmesi değerlendirilebilir.

Ancak URL:

/kadikoy-subesi/

iken işletme tamamen:

Bakırköy’e

taşındıysa kullanıcı açısından eski slug yanıltıcı hale gelebilir.

Bu durumda yeni location URL + 301 migration daha temiz olabilir.

Karar mevcut URL performansı ve location identity üzerinden verilmelidir.

Yeni Şube Açıldığında Ne Yapılmalı?

Yeni physical location açılması yalnız yeni Business Profile oluşturmak değildir.

Site graph’a yeni entity eklenir.

Kontrol listesi:

  • Yeni location page gerekiyorsa oluştur
  • Homepage veya branch hub’dan link ver
  • Yeni location’ın gerçek hizmetlerini tanımla
  • Telefon ve çalışma saatlerini ekle
  • Gerçek fotoğrafları ekle
  • Business Profile’ı uygun biçimde oluştur ve doğrula
  • GBP website destination’ını kontrol et
  • NAP ve structured data’yı güncelle
  • Analytics ve conversion tracking’i location bazında ayır

Yeni şube = yeni entity relationship, bütün service pages’in kopyası değildir.

Franchise Sistemlerinde Yerel SEO Nasıl Çalışır?

Franchise yapılarında marka merkezi olabilir ancak physical locations farklı franchise işletmecileri tarafından yönetilebilir.

SEO architecture yine gerçek customer-facing location üzerinden kurulmalıdır.

Kontrol edilmesi gerekenler:

  • Marka adı gerçek kullanımda tutarlı mı?
  • Her franchise location gerçek fiziksel işletme mi?
  • Business Profile ownership ve erişimleri doğru mu?
  • Her location’ın doğru website destination’ı var mı?
  • Telefon gerçek branch’e bağlanıyor mu?
  • Çalışma saatleri merkezi veriyle güncel mi?
  • Hizmet veya ürün farkları website’te doğru mu?

Google’ın chain ve brand kurallarında franchisee olarak gerçek ve yetkili biçimde faaliyet gösteren locations underlying brand’i kullanabilir.

Ancak franchise olması işletme adını keywordlerle genişletme hakkı vermez.

Franchise Şube Sayfaları Merkezi mi Yönetilmeli?

SEO açısından merkezi template ve veri governance faydalıdır.

Örneğin merkez:

  • URL yapısını
  • Title template’ini
  • Schema yapısını
  • NAP alanlarını
  • Tracking standardını
  • Review süreçlerini

standartlaştırabilir.

Ancak her franchise location’ın gerçek:

  • Telefon
  • Adres
  • Çalışma saati
  • Hizmet bilgisi
  • Fotoğrafı

kendi verisinden gelmelidir.

Merkezi template ≠ merkezi sahte içerik.

Franchise Locations Aynı İçeriği Kullanabilir mi?

Marka açıklaması ve bazı ortak bilgiler aynı olabilir.

Her location page’in tamamını benzersiz göstermek uğruna gerçek olmayan hikayeler üretmek gerekmez.

Location-specific farkı:

  • Gerçek branch data
  • Gerçek ekip
  • Gerçek ürün/hizmet availability
  • Gerçek fotoğraflar
  • Gerçek iletişim

sağlamalıdır.

Şube Sayfalarında Structured Data Nasıl Kullanılmalı?

Uygun işletme tiplerinde location page üzerindeki gerçek local bilgiler structured data ile açıklanabilir.

Örneğin:

  • Name
  • Address
  • Telephone
  • Opening hours
  • Geo coordinates

gibi alanlar gerçek sayfa içeriğiyle uyumlu biçimde kullanılabilir.

Ana organization ise homepage veya uygun organization surface üzerinde ayrıca temsil edilebilir.

Structured data gerçek branch yaratmaz. Önce fiziksel işletme, sonra web page, sonra markup gelir.

Her Şube için LocalBusiness Schema Kullanmak Yeterli mi?

Hayır.

Structured data:

  • Google Business Profile oluşturmaz
  • Yanlış adresi doğru yapmaz
  • Fake location’ı gerçek yapmaz
  • Duplicate branch pages’i çözmez
  • Local ranking garantisi vermez

Schema mevcut local entity architecture’ı açıklayan teknik katmandır.

Sağlık ve Kliniklerde Çok Şubeli Yerel SEO Farklı mı?

Temel organization-location mantığı aynıdır ancak sağlık sektöründe practitioner, branş ve treatment relationships de sisteme girer.

Örneğin iki şubeli klinikte:

KLİNİK
  │
  ├── LOCATION A
  │     ├── DOKTORLAR
  │     └── HİZMETLER
  │
  └── LOCATION B
        ├── DOKTORLAR
        └── HİZMETLER

yapısı oluşabilir.

Bu nedenle sağlık sitesinde branch page yalnız adres sayfası değildir.

Hangi doktorun hangi location’da çalıştığı ve hangi hizmetin gerçekten nerede sunulduğu da doğru modellenmelidir.

Kliniklere özgü local entity yapısını Klinikler İçin Yerel SEO rehberinde ayrıca ele alıyoruz.

Çok Şubeli İşletmelerde Organic SEO Nasıl Ölçülmeli?

Toplam organic traffic tek başına yeterli değildir.

Location bazında:

  • Impressions
  • Clicks
  • Landing page performance
  • Brand + branch queries
  • Service + location queries
  • Wrong-page ranking

izlenebilir.

Google İşletme Profili Performansı Nasıl Ölçülmeli?

GBP tarafında location bazında mevcut metrikler ve kullanıcı aksiyonları izlenebilir.

Örneğin:

  • Website interactions
  • Calls
  • Directions
  • Diğer mevcut profile interactions

şube bazında değerlendirilebilir.

Burada amaç yalnız profile views sayısını büyütmek değildir.

Hangi branch hangi local demand’i gerçek ticari aksiyona taşıyor?

sorusunu cevaplamaktır.

Şube Bazlı Telefon Ölçümü Nasıl Yapılmalı?

Şubelerin ayrı telefonları bulunuyorsa analytics tarafında her location için ayrı click event veya conversion dimension kullanılabilir.

Örneğin:

  • phone_click_kadikoy
  • phone_click_bakirkoy

gibi event yapıları düşünülebilir.

Daha ölçeklenebilir yapıda location değeri event parameter olarak gönderilebilir.

Örneğin:

event: phone_click
location: kadikoy

Bu yaklaşım yirmi location için yirmi farklı event adı üretmekten daha yönetilebilir olabilir.

Şube Bazlı Form ve Lead Ölçümü

Form kullanıcının seçtiği location bilgisini analytics veya CRM sistemine aktarabiliyorsa SEO performansı branch level’a kadar izlenebilir.

Örneğin:

ORGANIC USER
     ↓
KADIKÖY LOCATION PAGE
     ↓
FORM
     ↓
LOCATION = KADIKÖY

Böylece yalnız “organikten 100 lead geldi” yerine:

hangi local landing page ve şubenin talep ürettiği

daha doğru değerlendirilebilir.

Directions Tek Başına Dönüşüm müdür?

Yol tarifi kullanıcının physical location’a gitme niyetini gösterebilir.

Ancak gerçek mağaza ziyaretiyle birebir aynı metrik değildir.

Bu nedenle:

  • Directions
  • Calls
  • Forms
  • Reservations
  • Sales veya CRM outcomes

işletmenin mevcut measurement imkanına göre ayrı katmanlarda değerlendirilmelidir.

UTM Çok Şubeli GBP’lerde Nasıl Kullanılmalı?

Website links uygun UTM standardıyla location bazında ayrıştırılabilir.

Örneğin campaign veya content parametresi branch bilgisini taşıyabilir.

Ama her şubenin UTM formatını farklı ekiplerin kafasına göre üretmesine izin verilirse analytics kısa sürede arkeolojik kazıya dönüşür.

Merkezi naming convention kullanılmalıdır.

Şube SEO Dashboard’unda Neler Bulunmalı?

İşletme ölçeğine göre dashboard şu katmanları içerebilir:

KatmanÖlçüm
OrganicClicks, impressions, queries
Location PageSessions, engagement, conversions
GBPCalls, directions, website actions
LeadForm, phone, reservation
BusinessQualified lead, sale veya uygun offline outcome

Her işletme bütün katmanları ölçemeyebilir.

Önemli olan mevcut veriyle profile visibility’yi doğrudan revenue diye etiketlememektir.

Çok Şubeli SEO’da En Sık Yapılan Hatalar

1. Gerçek Olmayan Şubeler İçin Page Açmak

Keyword bulunduğu için fiziksel location varmış gibi davranılır.

2. Aynı Page’i Şehir Adıyla Çoğaltmak

Location-specific user value oluşmaz.

3. Aynı Location İçin Duplicate GBP Açmak

Tek gerçek branch birden fazla profile ile temsil edilmeye çalışılır.

4. Business Name’e Şehir ve Keyword Doldurmak

Gerçek brand name yerine local search title oluşturulur.

5. Bütün GBP’leri Yanlış Landing Page’e Bağlamak

Location-specific user journey generic homepage’e gönderilir.

6. NAP’i Merkez Ofis Bilgisiyle Ezmek

Bütün locations yanlışlıkla aynı address veya phone ile temsil edilir.

7. Aynı Hizmet Metnini Bütün Şubelere Kopyalamak

Location page service page’in duplicate versiyonuna dönüşür.

8. Her Hizmet × Şube Kombinasyonu İçin URL Açmak

Gerçek relationships seri landing page üretimine dönüşür.

9. Şube Yorumlarını Yanlış Profile Toplamak

Location-specific reputation kaybolur.

10. Kapanan Şubeyi Aktif Bırakmak

Website ve Maps gerçek işletme durumuyla çelişir.

11. Taşınan Şube İçin Gereksiz Yeni GBP Oluşturmak

Aynı entity’nin history ve review relationship’i parçalanabilir.

12. Şube Page’i Sitemap’e Ekleyip Orphan Bırakmak

Location gerçek site navigation içinde yer almaz.

13. Franchise Verisini Güncel Tutmamak

Merkezi site ile gerçek branch operation birbirinden kopar.

14. Bütün Şubeleri Tek Performans Raporunda Eritmek

Hangi location’ın başarılı veya sorunlu olduğu görünmez.

Çok Şubeli İşletmeler İçin URL Ownership Matrisi

Query / IntentMuhtemel Primary Owner
Marka adıHomepage / organization
Marka + şubeLocation page
Şube adresi / iletişimLocation page
Generic hizmetService page
Hizmet + lokasyonSERP ve intent’e göre service veya location owner
Gerçek location’a özgü ihtiyaçLocation page
Hizmet bölgesi sorgusuService-area architecture

Şube page’in bulunması bütün local service queries’in ona ait olduğu anlamına gelmez.

Yeni Şube Sayfası İçin Karar Ağacı

Digitalplus yerel SEO karar ağacı: Ne zaman ayrı bir şube lokasyon sayfası (landing page) açılmalı? Fiziksel şube varlığı, ayrı Google İşletme Profili ve yerel kanıt (proof) kriterlerine göre QDP karar akışı.

Yeni location hedefleniyor.

Gerçek fiziksel şube var mı?

Hayır → branch page açma.

Evet ↓

Kullanıcı location hakkında ayrı bilgiye ihtiyaç duyuyor mu?

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

Evet ↓

Şubeye özgü gerçek işletme verisi var mı?

Hayır → clone landing page üretme.

Evet ↓

Başka URL aynı local intent’in owner’ı mı?

Evet → ownership ayrımını değerlendir.

Hayır ↓

Canonical location page değerlendir.

Şube + Hizmet URL Karar Ağacı

Şubede Hizmet A sunuluyor.

Ana service owner mevcut mu?

Evet ↓

Location-specific query ayrı intent taşıyor mu?

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

Evet ↓

SERP ayrı local service landing page gösteriyor mu?

Hayır → mevcut service/location owner’ı güçlendir.

Evet ↓

Bağımsız location-specific değer üretilebilir mi?

Hayır → kombinasyon URL açma.

Evet ↓

Ayrı service-location owner değerlendir.

Çok Şubeli İşletme Yerel SEO Checklist

Real-World Locations

  • Bütün branch pages gerçek physical locations’a mı ait?
  • Fake veya virtual locations var mı?
  • Kapanmış şubeler temizlendi mi?

Google Business Profile

  • Her gerçek location için doğru profile var mı?
  • Duplicate profiles var mı?
  • Business name gerçek kullanımla uyumlu mu?
  • Primary category doğru mu?
  • Website destination doğru location’a mı gidiyor?
  • Phone doğru mu?
  • Hours güncel mi?

Location Pages

  • Her şubenin canonical page’i belli mi?
  • Adres doğru mu?
  • Telefon doğru mu?
  • Çalışma saatleri doğru mu?
  • Gerçek fotoğraflar var mı?
  • Şubeye özgü services doğru mu?
  • Location page yalnız şehir adı değiştirilmiş clone mu?

NAP

  • Her location kendi NAP bilgisiyle tutarlı mı?
  • Başka şubenin telefon veya adresi yanlışlıkla kullanılıyor mu?

Services

  • Hangi şube hangi hizmeti sunuyor?
  • Generic service owner belli mi?
  • Service × location pages gereksiz çoğalmış mı?

Internal Linking

  • Homepage → locations links var mı?
  • Şube hub → branch pages linkleri var mı?
  • Location → services links doğru mu?
  • Services → available locations links gerekli yerlerde var mı?
  • Location pages orphan mı?

Reviews

  • Review request doğru branch profile’a mı gidiyor?
  • Review gating var mı?
  • Şubelerin gerçek reputation data’sı ayrı izleniyor mu?

Technical

  • Branch URLs 200 mü?
  • Indexable mı?
  • Canonical doğru mu?
  • Sitemap current locations’ı içeriyor mu?
  • Eski location URLs doğru yönetilmiş mi?
  • Structured data görünür information ile uyumlu mu?

Measurement

  • Organic performance branch bazında ayrılıyor mu?
  • GBP actions branch bazında izleniyor mu?
  • Phone clicks location bazında ölçülüyor mu?
  • Forms branch bilgisi taşıyor mu?
  • UTM standardı merkezi mi?

Çok Şubeli SEO’da Daha Fazla Lokasyon Sayfası Hedef Değildir

Digitalplus yerel varlık grafiği (local entity) modeli: Ana marka ile şube entity'leri arasındaki ilişki. Çok şubeli işletmeler için adres, telefon, GBP, müşteri yorumları ve local schema mimarisi.

Bir işletmenin beş gerçek şubesi bulunabilir.

Bu beş location web sitesi ve Google Business Profile üzerinde doğru biçimde temsil edilmelidir.

Ancak bundan:

5 şube × 20 hizmet = 100 SEO landing page

sonucu çıkmaz.

Doğru architecture:

marka → gerçek şube → doğru GBP → canonical location page → gerçek hizmet ilişkileri → ölçülebilir kullanıcı aksiyonu

üzerinden kurulur.

DigitalPlus çok şubeli yerel SEO çalışmalarında önce physical entity’leri ve mevcut URL ownership’i belirler.

Ardından yalnız gerçek search demand ve bağımsız kullanıcı ihtiyacı bulunan location veya service-location fırsatlarını ayrı page olarak değerlendirir.

Çok şubeli yapılarda SEO problemi çoğunlukla daha fazla lokasyon sayfası değil, marka, şube, GBP ve landing page sinyallerinin yanlış eşleşmesidir.

Yerel SEO Hizmetini İncele

Sıkça Sorulan Sorular

Çok şubeli işletmeler için yerel SEO nedir?

Çok şubeli yerel SEO, aynı marka altındaki gerçek fiziksel locations’ın Google Business Profile, location pages, NAP, hizmet ilişkileri, yorumlar ve measurement katmanlarıyla birlikte yönetilmesidir.

Her şube için ayrı landing page açılmalı mı?

Gerçek fiziksel location ve ayrı kullanıcı ihtiyacı varsa çoğu multi-location yapıda anlamlı olabilir. Ancak yalnız şehir veya ilçe keywordü için clone pages açılmamalıdır.

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

Gerçek ve uygun fiziksel locations ayrı Business Profiles ile temsil edilebilir. Aynı gerçek location için duplicate organization profiles oluşturulmamalıdır.

Bir Business Profile’a birden fazla şube adresi eklenebilir mi?

Multi-location işletmelerde her gerçek location ayrı profile olarak yönetilir. Profiller Business Group veya uygun bulk management sistemi altında merkezi biçimde yönetilebilir.

10’dan fazla şubesi olan işletmeler Google profillerini toplu yönetebilir mi?

Google, uygunluk koşullarını karşılayan 10 veya daha fazla location’a sahip işletmeler için bulk location management ve verification seçenekleri sunar.

Her şube profilinde işletme adı farklı olabilir mi?

Markanın gerçek dünyadaki kullanımı locations arasında aynıysa Business Profile adları da tutarlı olmalıdır. Location-specific gerçek isim farkları varsa bunlar ayrıca değerlendirilebilir. Şehir keywordü eklemek için isim değiştirilmemelidir.

Her şubenin ayrı telefon numarası olması şart mı?

Her durumda mutlak şart değildir ancak Google mümkün olduğunda individual business location’a bağlanan telefon numarasını tercih eder. Kullanıcı açısından hangi telefonun hangi şubeye ait olduğu açık olmalıdır.

Her şubenin GBP’si kendi landing page’ine bağlanmalı mı?

Gerçek location pages mevcutsa ilgili Business Profile’ı corresponding location page’e bağlamak güçlü bir kullanıcı ve entity relationship’i oluşturabilir. Google da website bilgisinin individual location’ı temsil etmesini ister.

Bütün şubeler aynı hizmetleri veriyorsa location pages duplicate olur mu?

Aynı core services’in bulunması normaldir. Location pages adres, telefon, çalışma saatleri, ekip, gerçek fotoğraflar ve hizmet availability gibi real-world differences üzerinden ayrışmalıdır. Uzun service copy her location’da tekrar edilmek zorunda değildir.

Her hizmet ve şube için ayrı sayfa açılmalı mı?

Hayır. Tek canonical service owner birçok real location ile ilişkilendirilebilir. Ayrı service-location page yalnız bağımsız search intent ve gerçek location-specific value varsa değerlendirilmelidir.

Şube yorumları ayrı mı yönetilmeli?

Müşteri belirli bir fiziksel location’da deneyim yaşadıysa yorum talebinin ilgili branch profile’a gitmesi location-specific reputation’ın daha doğru oluşmasını sağlar.

Şube taşınırsa yeni Google İşletme Profili açılmalı mı?

Genellikle yalnız adres değişikliği nedeniyle yeni profile açılmamalıdır. Mevcut profile’ın address bilgisi güncellenir ve gerektiğinde yeniden doğrulama yapılır.

Şube taşındığında yorumlar kaybolur mu?

Aynı işletme adıyla uygun relocation durumlarında Google yorumları yeni location’a taşıyabilir. Bu nedenle mevcut entity’yi güncellemek sıfırdan duplicate profile oluşturmaktan daha doğru başlangıçtır.

Şube kapanınca profile silinmeli mi?

Kalıcı kapanışta Business Profile permanently closed olarak işaretlenebilir. Website location URL’si için ise replacement, trafik, backlink ve kullanıcı ihtiyacı değerlendirilerek ayrı teknik karar verilmelidir.

Kapanan şube URL’si homepage’e 301 yapılmalı mı?

Otomatik olarak hayır. Anlamlı replacement location veya page varsa 301 değerlendirilebilir. Aksi durumda 404 veya 410 daha doğru olabilir.

Franchise işletmeler çok şubeli SEO yapabilir mi?

Evet. Gerçek physical franchise locations aynı brand architecture altında yönetilebilir. Her location’ın gerçek profile, NAP, landing page ve operasyon bilgileri doğru tutulmalıdır.

Franchisee Business Profile’da ana marka adını kullanabilir mi?

Google’ın güncel chain ve brand kurallarında yetkili ve tamamen ilgili branded ürün veya hizmete odaklanan franchisee’ler uygun durumlarda underlying brand name’i kullanabilir.

Çok şubeli SEO ile hizmet bölgesi SEO aynı şey mi?

Hayır. Çok şubeli işletmede birden fazla gerçek physical location bulunur. Service-area business müşteriye gider ve tek merkezden çok sayıda bölgeye hizmet verebilir. Her hizmet bölgesi ayrı şube değildir.

Şube sayfası sitemap’te varsa orphan değildir diyebilir miyiz?

Hayır. Sitemap keşif sinyalidir. Önemli branch pages homepage, location hub veya başka gerçek navigation yollarından crawlable internal links almalıdır.

Çok şubeli SEO’da hangi metrikler takip edilmeli?

Location bazında organic clicks ve impressions, Business Profile interactions, calls, directions, forms, reservations ve işletmenin ölçebildiği gerçek lead veya satış sonuçları birlikte değerlendirilebilir.

Kaynaklar

Berke Dalar

Berke Dalar, DigitalPlus'ta Head of SEO & Growth olarak SEO stratejisi, teknik SEO, içerik stratejisi ve organik büyüme çalışmalarını yönetmektedir. SEO süreçlerinde teknik altyapı, arama niyeti, içerik mimarisi ve performans verilerini birlikte ele alan bir yaklaşım benimser.

Organik büyümeye hazır mısınız?

Sitenizin mevcut durumunu çıkaralım; önceliklendirilmiş bir yol haritasıyla dönelim.

Ücretsiz SEO Audit Talep Et
WhatsApp Hemen Ara