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


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, 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:
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:
bulunuyorsa kullanıcının her location için doğru:
ile karşılaşması gerekir.
Multi-location architecture kurulmadan önce işletmenin gerçekten fiziksel şubelere sahip olup olmadığı doğrulanmalıdır.
Müşteri ayrı fiziksel locations’a gidebilir.
Örneğin:
İş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.
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:
Gerçek location + ayrı kullanıcı görevi + özgün işletme verisi varsa şube page anlamlı hale gelir.
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.
Her branch farklı physical address ile temsil edilmelidir.
Şubeler farklı saatlerde çalışıyorsa kullanıcı bunu location page ve Business Profile üzerinde doğru görmelidir.
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.
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.
Gerçek ve uygun locations Google Business Profile tarafında da ayrı fiziksel işletme noktaları olarak temsil edilebilir.
Şubeye özgü gerçek:
page’in kullanıcı değerini güçlendirebilir.
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.
Örneğin website’te:
/kadikoy-magaza/besiktas-magaza/bakirkoy-magazasayfaları oluşturulmuş olsun.
Ancak üç page de:
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.
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.
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 page’in amacı ilçe adını yirmi kez tekrarlamak değildir.
Kullanıcının “bu location bana uygun mu?” sorusunu cevaplamaktır.
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:
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.
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.
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:
ş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.
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:
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.
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:
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.
Birden fazla gerçek location bulunan yapılarda:
/subeler/
gibi bir hub kullanıcı açısından yararlı olabilir.
Hub:
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.
Ç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.
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:
generic homepage daha zayıf destination haline gelebilir.
NAP:
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:
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.
Ç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.
Gerçek differences şunlardan gelebilir:
Ş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.
Hayır.
Örneğin dört şube ve on hizmet bulunan bir işletme:
4 × 10 = 40
kombinasyon oluşturabilir.
Bunun üzerine:
yerine 40:
/kadikoy-hizmet-a
/bakirkoy-hizmet-a
/besiktas-hizmet-a
gibi landing page üretmek zorunlu değildir.
Yeni service-location URL ancak:
birlikte doğrulanıyorsa değerlendirilmelidir.
Excel çarpım tablosu site mimarisi değildir.
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
Ana marka bütün current locations’a navigation sağlayabilir.
Varsa `/subeler/` hub’ı bütün gerçek branch pages’e link verir.
Şubede gerçekten sunulan services’a bağlantı verilebilir.
Hizmetin hangi şubelerde sunulduğu kullanıcı açısından önemliyse canonical service page ilgili locations’a bağlantı verebilir.
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.
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:
üzerinden crawlable links almalıdır.
Sitemap keşfe yardımcı olabilir ancak internal architecture’ın yerine geçmez.
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.
Search’te bulunması istenen canonical location pages sitemap’e dahil edilebilir.
Sitemap’te:
tutulmamalıdır.
Ç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:
daha doğru ölçülebilir.
Yorum talebinde:
daha sağlıklı süreç oluşturur.
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.
Hayır.
Locations farklı:
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.
Bir physical location kalıcı olarak kapanıyorsa iki ayrı sistem güncellenmelidir:
Gerçekten kapanan şube profile’ı uygun biçimde permanently closed olarak güncellenmelidir.
Şube URL’si için otomatik:
homepage’e 301
kuralı kullanılmamalıdır.
Önce:
kontrol edilmelidir.
Sonrasında:
gibi teknik aksiyonlardan uygun olanı seçilebilir.
Kapanan her location ana sayfaya gönderilmez.
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:
güncellenmelidir.
Location page slug’ı adres veya semt değişimine çok sıkı bağlıysa URL migration ihtiyacı ayrıca değerlendirilir.
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.
İş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 physical location açılması yalnız yeni Business Profile oluşturmak değildir.
Site graph’a yeni entity eklenir.
Kontrol listesi:
Yeni şube = yeni entity relationship, bütün service pages’in kopyası değildir.
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:
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.
SEO açısından merkezi template ve veri governance faydalıdır.
Örneğin merkez:
standartlaştırabilir.
Ancak her franchise location’ın gerçek:
kendi verisinden gelmelidir.
Merkezi template ≠ merkezi sahte içerik.
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ı:
sağlamalıdır.
Uygun işletme tiplerinde location page üzerindeki gerçek local bilgiler structured data ile açıklanabilir.
Örneğin:
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.
Hayır.
Structured data:
Schema mevcut local entity architecture’ı açıklayan teknik katmandır.
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.
Toplam organic traffic tek başına yeterli değildir.
Location bazında:
izlenebilir.
GBP tarafında location bazında mevcut metrikler ve kullanıcı aksiyonları izlenebilir.
Örneğin:
ş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.
Şubelerin ayrı telefonları bulunuyorsa analytics tarafında her location için ayrı click event veya conversion dimension kullanılabilir.
Örneğin:
phone_click_kadikoyphone_click_bakirkoygibi 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.
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.
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:
işletmenin mevcut measurement imkanına göre ayrı katmanlarda değerlendirilmelidir.
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.
İşletme ölçeğine göre dashboard şu katmanları içerebilir:
| Katman | Ölçüm |
|---|---|
| Organic | Clicks, impressions, queries |
| Location Page | Sessions, engagement, conversions |
| GBP | Calls, directions, website actions |
| Lead | Form, phone, reservation |
| Business | Qualified 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.
Keyword bulunduğu için fiziksel location varmış gibi davranılır.
Location-specific user value oluşmaz.
Tek gerçek branch birden fazla profile ile temsil edilmeye çalışılır.
Gerçek brand name yerine local search title oluşturulur.
Location-specific user journey generic homepage’e gönderilir.
Bütün locations yanlışlıkla aynı address veya phone ile temsil edilir.
Location page service page’in duplicate versiyonuna dönüşür.
Gerçek relationships seri landing page üretimine dönüşür.
Location-specific reputation kaybolur.
Website ve Maps gerçek işletme durumuyla çelişir.
Aynı entity’nin history ve review relationship’i parçalanabilir.
Location gerçek site navigation içinde yer almaz.
Merkezi site ile gerçek branch operation birbirinden kopar.
Hangi location’ın başarılı veya sorunlu olduğu görünmez.
| Query / Intent | Muhtemel Primary Owner |
|---|---|
| Marka adı | Homepage / organization |
| Marka + şube | Location page |
| Şube adresi / iletişim | Location page |
| Generic hizmet | Service page |
| Hizmet + lokasyon | SERP ve intent’e göre service veya location owner |
| Gerçek location’a özgü ihtiyaç | Location page |
| Hizmet bölgesi sorgusu | Service-area architecture |
Şube page’in bulunması bütün local service queries’in ona ait olduğu anlamına gelmez.

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.
Ş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.

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.
Ç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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
Otomatik olarak hayır. Anlamlı replacement location veya page varsa 301 değerlendirilebilir. Aksi durumda 404 veya 410 daha doğru olabilir.
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.
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.
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.
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.
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.
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.
Sitenizin mevcut durumunu çıkaralım; önceliklendirilmiş bir yol haritasıyla dönelim.
Ücretsiz SEO Audit Talep Et