Merkez kontrolü ile yerel görünürlük aynı anda
Bayi ve şube ağının dijital yönetimi, tek bir marka anlatısını korurken her lokasyonun kendi aramasında bulunmasını sağlayan mimaridir. Merkez veri kaynağını, lokasyon sayfası şablonunu, çoklu işletme profilini ve NAP tutarlılığını tek bir yetki modelinde birleştiririz.
- Teslimat kalemi
- 9
- Tipik kurulum süresi
- 10–14 hafta
- Kabul kriteri
- 6
Bayi ağının dijital sorumluluğu kimde?
Bayi ağının dijital yönetimi üç işi aynı anda gerektirir: lokasyon sayfası mimarisini kurmak, her lokasyonun yapılandırılmış verisini yazmak ve marka tutarlılığını sürekli denetlemek. Pazarlama ajansı koda, yazılım ajansı yerel görünürlüğe dokunmaz; boşluk tam ortada kalır. Bu üç iş tek yetki modelinde toplanmadığında ağ büyüdükçe hata da büyür.
| Sorumluluk | Pazarlama ajansı | Yazılım ajansı | Baki Bilişim |
|---|---|---|---|
| Lokasyon sayfası şablonunu ve zorunlu yerel içerik alanlarını kim tanımlar? | Kapsam dışı | Kısmen | Kapsamında |
| Her lokasyonun LocalBusiness verisini kim yazar ve doğrular? | Kapsam dışı | Kısmen | Kapsamında |
| Bayi kendi profilini güncellediğinde NAP tutarlılığını kim denetler? | Kısmen | Kapsam dışı | Kapsamında |
Tablodaki kolonlar kategori adıdır, belirli bir şirketi işaret etmez. Bu iş bölümü sorununun tam anlatımı Neden Baki Bilişim sayfasındadır.
Bayi ağı büyüdükçe yerel aramada neden görünmez olunur?
Çünkü ağın tamamı ya tek bir kurumsal sayfaya sıkışır ya da her bayi kendi sayfasını kendi kurar. İlk durumda arama motorunun eşleştirebileceği ayrı bir lokasyon varlığı yoktur; ikinci durumda marka anlatısı, iletişim verisi ve teknik kalite lokasyon başına dağılır. İkisi de aynı sonucu verir: yerel sonuçlarda ağın kendisi görünmez.
Merkez her şeyi tek sayfada toplarsa
Ağın tamamı tek bir «bayilerimiz» listesinde toplandığında, arama motorunun her lokasyon için eşleştirebileceği bir sayfa varlığı oluşmaz. Kullanıcı ilçe veya semt adıyla arattığında ortaya çıkacak bir hedef yoktur; ağ kendi markasıyla arandığında bulunur, lokasyon niyetiyle arandığında bulunmaz. İkinci maliyet ölçümdedir: tüm trafik tek URL’de toplandığı için hangi bölgenin talep ürettiği görülemez, dolayısıyla bayiye dönen bir performans verisi de üretilemez.
Bayi kendi sayfasını kendi kurarsa
Bu kez lokasyon varlığı oluşur ama denetlenemez. Her bayi farklı bir alan adı, farklı bir tasarım, farklı bir telefon biçimi ve çoğu zaman farklı bir işletme adı kullanır. Marka anlatısı lokasyon başına dağılır; işletme adı, adres ve telefon üçlüsü (NAP) kaynaklar arasında çelişir; teknik kalite ölçülemez hale gelir. Ağ büyüdükçe merkezin elinde yalnızca bir bayi listesi kalır — kontrol değil.
10+
Google’ın toplu konum doğrulaması için aradığı eşik: aynı işletmeye ait 10’dan fazla konum. Bu eşiğin altındaki ağlarda her konum tek tek doğrulanır; üzerinde ise ağın tamamı tek talep ile doğrulanabilir.
Kaynak: Google İşletme Profili Yardım — birden fazla konumun yönetimi · Erişim: 2026-07-29 support.google.com/business ↗ (yeni sekmede açılır)
Üçüncü tuzak: çoğaltılmış lokasyon sayfaları
Şablon kurulduktan sonra en sık yapılan hata, aynı metnin yalnızca şehir adı değiştirilerek yüzlerce sayfaya kopyalanmasıdır. Arama motorları bu sayfaları kullanıcıya ek değer taşımayan geçit sayfası olarak değerlendirir ve büyük bölümünü indekslemez; ağ, sayfa sayısını artırırken görünürlüğünü artırmaz. Mimarinin işi tam olarak budur: her lokasyon sayfasında gerçekten yerel olan alanları zorunlu kılmak ve eşiği karşılamayan sayfayı yayına almamak.
Geçit sayfası tanımı için: Google Search Central — spam politikaları ↗ (yeni sekmede açılır) · Erişim: 2026-07-29
Bayi ve şube ağı dijital yönetimi neleri kapsar?
Kapsam dokuz teslimat kalemidir: ağ envanteri ve NAP referans kaydı, lokasyon sayfası şablon mimarisi, lokasyon içerik veri modeli, çoklu LocalBusiness yapılandırılmış veri grafı, lokasyon bulucu ve iç link matrisi, işletme profili yönetim akışı, NAP tutarlılık denetimi, bayi başvuru hunisi ve ağ raporlama düzeni. Her kalem yazılı formatı ve teslim haftasıyla birlikte tanımlanır.
| # | Teslimat | Format | Ne zaman |
|---|---|---|---|
| 01 | Ağ envanteri ve NAP referans kaydı | Tablo (CSV + web görünümü) | 1.–2. hafta |
| 02 | Lokasyon sayfası şablon mimarisi | Bilgi mimarisi haritası + şablon | 2.–4. hafta |
| 03 | Lokasyon içerik veri modeli ve yetki matrisi | Alan sözlüğü + doldurma kılavuzu | 3.–5. hafta |
| 04 | Çoklu LocalBusiness yapılandırılmış veri grafı | JSON-LD kod + doğrulama raporu | 4.–6. hafta |
| 05 | Lokasyon bulucu ve iç link matrisi | Çalışan arayüz + link haritası | 5.–8. hafta |
| 06 | Google İşletme Profili yönetim akışı | Rol matrisi + işletim yönergesi | 6.–8. hafta |
| 07 | NAP tutarlılık denetimi ve düzeltme listesi | Uyumsuzluk tablosu + aksiyon listesi | 6.–9. hafta |
| 08 | Bayi başvuru hunisi | Sayfa + nitelendirici form + değerlendirme akışı | 8.–11. hafta |
| 09 | Ağ raporlama düzeni ve aylık ritim | Rapor şablonu + toplantı takvimi | 10.–14. hafta |
Haftalar 20–80 lokasyonlu bir ağ içindir. Lokasyon sayısı, dil sayısı ve mevcut sistemlerin durumu takvimi değiştirir; sözleşmeden önce ağa özel takvim yazılır.
Kurulum adım adım nasıl ilerler?
Kurulum altı aşamalıdır: ağ envanteri ve NAP referansı, mimari ve şablon kararı, içerik veri modeli, yapılandırılmış veri ve teknik kurulum, işletme profili ve yetki modeli, raporlama ve devir. Her aşamanın teslimatı, ölçüm kriteri ve sorumlu tarafı önceden yazılıdır; bir aşama kriteri karşılamadan bir sonraki aşama başlamaz.
-
Ağ envanteri ve NAP referansı
Tüm lokasyonlar tek tabloda toplanır: işletme adı, adres, telefon, çalışma saati, sorumlu kişi, mevcut işletme profili ve mevcut sayfa. Kaynaklar arasındaki çelişkiler işaretlenir ve her lokasyon için tek doğru kayıt belirlenir. Bu kayıt, sonraki her aşamanın referansıdır.
-
Mimari ve şablon kararı
URL hiyerarşisi, lokasyon bulucu akışı ve sayfa şablonu kararlaştırılır. Şehir, ilçe ve lokasyon seviyelerinden hangisinin indekslenebilir olacağı gerekçesiyle birlikte yazılır. İndekslenmeyecek seviyeler de aynı netlikte belgelenir, böylece ileride tesadüfi sayfa üretimi olmaz.
-
İçerik veri modeli ve özgünleştirme
Lokasyon sayfasının hangi alanının merkezde kilitli, hangisinin yerel olduğu tanımlanır. Her yerel alan için doldurma kılavuzu ve minimum içerik eşiği yazılır. Eşiği karşılamayan lokasyon sayfası yayına alınmaz; ince içerik bu kuralla önlenir.
-
Yapılandırılmış veri ve teknik kurulum
Her lokasyon için LocalBusiness düğümü üretilir ve merkez Organization düğümüne bağlanır.
@idmimarisi, lokasyon bulucu, iç link matrisi ve şablonun performans bütçesi uygulanır. Yöntemin ayrıntısı Schema.org rehberinde anlatılıyor. -
İşletme profili ve yetki modeli
Lokasyon işletme profilleri tek yönetim hesabı altında toplanır, roller merkez, bölge ve bayi olmak üzere üç katmana dağıtılır. Güncelleme ve onay akışı yazılı yönergeye bağlanır. Hesap sahipliği her zaman müşterinin adına kalır; bu açıkça sözleşmeye yazılır.
-
Raporlama ve devir
Ağ raporlama düzeni kurulur: lokasyon başına indekslenme, NAP uyumsuzluğu, başvuru hunisi adımları ve profil güncelliği aylık izlenir. Ekip eğitimi verilir, işletim devredilir. Devirden sonra çalışmaya devam edilip edilmeyeceği ayrı bir karardır, sözleşmeye bağlı değildir.
Bu altı aşama, tüm hizmetlerde uyguladığımız çalışma modelinin bu hizmete uyarlanmış halidir. Modelin tamamı: Çalışma Modelimiz.
Bu çalışmanın başarısı hangi kriterlerle ölçülür?
Altı kabul kriteriyle: lokasyon sayfası indekslenme oranı, NAP uyumsuzluk sayısı, LocalBusiness schema hata sayısı, lokasyon başına dolu yerel alan sayısı, şablonun mobil performans skoru ve başvuru hunisi olay kapsaması. Kriterler sözleşmeye eşik değerleriyle birlikte yazılır; teslim, eşiklerin ölçülerek karşılandığı anlamına gelir.
| Kriter | Eşik | Ölçüm aracı |
|---|---|---|
| Lokasyon sayfası indekslenme oranı | ≥ %95 | Search Console — Sayfalar raporu |
| NAP uyumsuzluğu (site · schema · işletme profili) | 0 | NAP referans tablosu + manuel doğrulama |
| LocalBusiness yapılandırılmış veri hatası | 0 | Rich Results Test + Schema Markup Validator |
| Lokasyon başına dolu yerel alan | ≥ 5 | Şablon alan denetimi (yayın öncesi kontrol) |
| Lokasyon sayfası mobil Performance | ≥ 95 | Lighthouse (mobil, şablon örneklemi) |
| Başvuru hunisi olay kapsaması | 4 / 4 adım | Analitik olay denetimi |
TAAHHÜT EDİLMEYEN
Yerel sonuçlarda sıralama ve harita paketi görünürlüğü, hiçbir ajansın taahhüt edebileceği bir çıktı değildir; bu tabloda sıralama vaadi yer almaz. Ölçtüğümüz şey, sıralamanın önkoşulu olan teknik ve içerik kalitesidir: sayfa indekslenebiliyor mu, veri tutarlı mı, schema geçerli mi, sayfa hızlı mı, içerik yerel olarak özgün mü.
Bu yapı hangi sektörlerde kuruluyor?
Birden fazla fiziksel noktası olan her yapıda: bayilik ve franchise ağları, mağaza zincirleri, çok tesisli üreticiler, yurt dışı distribütör ağı olan ihracatçılar ve çok markalı holdingler. Ortak payda lokasyon sayısı değil, merkez ile yerel arasındaki yetki sorusudur; sektör bu sorunun cevabını ve zorunlu yerel alanları değiştirir.
- 01 Bayilik ve Franchise Ağı Marka tutarlılığı ile bayi özerkliği arasındaki dengenin yetki matrisiyle kurulduğu, bayi başvuru hunisinin ikinci bir satış kanalı olarak çalıştığı yapı.
- 02 Mağaza Zincirleri ve Perakende Şehir, ilçe ve mağaza seviyelerinin ayrı ayrı indekslenebildiği mağaza bulucu mimarisi ile kampanya ve çalışma saati verisinin tek kaynaktan yönetimi.
- 03 Üretim ve Fabrika Birden fazla tesisi, satış ofisi ve yetkili servisi olan üreticilerde üretim noktası ile servis noktasının ayrı varlıklar olarak temsil edilmesi.
- 04 İhracatçı Sanayi Yurt dışı distribütör ve temsilcilik ağının ülke, dil ve iletişim verisiyle doğru eşleştirilmesi; hreflang ile lokasyon mimarisinin birlikte kurulması.
- 05 Kurumsal Holding İştirak, marka ve lokasyon hiyerarşisinin tek bir varlık grafında tutarlı temsili; hangi markanın hangi lokasyonda göründüğünün denetlenebilir olması.
Bu hizmet hangi çalışmalarla birlikte alınır?
Bayi ağı yönetimi tek başına da alınabilir; ancak dört hizmetle birlikte alındığında aynı işi iki kez yapmaktan kaçınırsınız. Yapılandırılmış veri lokasyon grafını, SEO indekslenmeyi ve iç link matrisini, kurumsal web sitesi şablonun üzerinde çalıştığı kod tabanını, mobil uygulama ise aynı lokasyon kaydını okuyan ikinci arayüzü sağlar.
-
01
Yapılandırılmış Veri (Schema)
Çoklu LocalBusiness grafı,
@idmimarisi ve doğrulama bu hizmetin çekirdeğidir; ağ mimarisi doğrudan onun üzerine oturur. - 02 SEO Lokasyon sayfalarının indekslenmesi, iç link matrisi ve aynı sorguda birbiriyle yarışan sayfaların ayrıştırılması teknik SEO işidir.
- 03 Kurumsal Web Sitesi Şablonun üzerinde çalıştığı kod tabanı, performans bütçesi ve içerik yönetim akışı buradan gelir; mevcut siteniz varsa şablon onun üstüne kurulur.
- 04 Mobil Uygulama Bayi sipariş, katalog ve saha uygulaması aynı lokasyon kaydını okur; böylece adres, saat ve stok verisi iki sistemde ayrışmaz.
B2B sipariş ve cari hesap ihtiyacı da varsa bayi sipariş portalı ayrı bir kapsamdır. Tüm kapsam matrisi: Hizmetler.
Bayi ağı dijital yönetimi hakkında sık sorulanlar
Bayi ağı için tek site mi, ayrı siteler mi kurulmalı?
Tek site, lokasyon başına kendi URL’si olan sayfalarla kurulmalıdır. Ayrı alan adları otoriteyi böler, güncelleme maliyetini lokasyon sayısıyla çarpar ve marka tutarlılığını denetlenemez hale getirir.
Doğru yapı şudur: merkez alan adı altında şehir ve lokasyon seviyeli hiyerarşik bir yol düzeni, tek şablon, tek yapılandırılmış veri grafı, lokasyon başına ayrı bir kayıt. Bayiye ayrı site değil, kendi sayfasında sınırlı ve denetlenen bir düzenleme yetkisi verilir.
Şube sayfaları nasıl özgünleştirilir?
Şube sayfası, şablonda tanımlı yerel alanlar gerçekten doldurulduğunda özgünleşir. Yalnızca şehir adı değiştirilerek çoğaltılan sayfalar ince içerik sayılır ve büyük bölümü indekslenmez.
En az beş yerel alan zorunlu tutulur: tam adres ve ulaşım tarifi, çalışma saatleri, o lokasyonda gerçekten sunulan hizmet veya stok, iletişim kişisi ve telefonu, lokasyona özgü bir ayrıntı (park imkânı, servis kapasitesi, teslimat bölgesi). Alanlar boşsa sayfa yayına alınmaz.
Çoklu Google işletme profili nasıl yönetilir?
Her fiziksel lokasyon için ayrı bir işletme profili açılır ve profillerin tamamı tek bir yönetim hesabı altında toplanır. Google, aynı işletmeye ait 10’dan fazla konumu olan işletmelerden toplu doğrulama talebi kabul eder.
Yönetim modeli üç katmanlıdır: merkez sahiplik, bölge yöneticisinde düzenleme yetkisi, bayide yalnızca gönderi ve fotoğraf. Profil verisi site ile aynı NAP kaydından beslenir; farklılık çıktığında düzeltme merkezden yapılır.
Bayiye içerik yetkisi verilmeli mi?
Evet, ancak sınırlı ve alan bazlı olmalıdır. Bayi kendi lokasyonunun günlük gerçeğini merkezden daha iyi bilir: stok, kampanya katılımı, çalışma saati istisnası, ekip değişikliği.
Marka anlatısı, hizmet tanımları, fiyat çerçevesi, meta etiketler ve yapılandırılmış veri merkezde kilitli kalır. Pratikte bu, hangi alanın düzenlenebilir olduğunu belirleyen bir yetki matrisi ve yayına almadan önce bir onay adımı demektir.
NAP tutarsızlığı ne zarar verir?
NAP verisinin, yani işletme adı, adres ve telefon üçlüsünün site, işletme profili, dizinler ve sosyal hesaplar arasında farklı olması, arama motorunun aynı işletmeyi tek bir varlık olarak eşleştirmesini zorlaştırır.
Sonuç üç yerde görülür: yerel sonuçlarda güven sinyali zayıflar, kullanıcı yanlış numarayı arar, ölçüm kirlenir. Denetimde her lokasyonun NAP kaydı tek referans tabloya karşı karşılaştırılır ve uyumsuzluk sayısı sıfıra indirilir.
Bayi başvuru hunisi nasıl kurulur?
Aday bayi mevcut müşteriden bambaşka bir alıcıdır; yatırım tutarı, geri dönüş süresi, bölge koruması ve destek paketi arar. Bu yüzden başvuru hunisi ürün sayfalarından ayrı kurgulanır.
Huni dört adımdır: koşulların, destek kapsamının ve süreç takviminin açıkça yazıldığı bilgi sayfası; bölge, sermaye aralığı, deneyim ve zaman çizelgesi soran nitelendirici başvuru formu; otomatik ön değerlendirme ve bilgilendirme; satış ekibine devir. Her adım olay olarak ölçülür, böylece kaybın hangi adımda olduğu görülür.
Kaç lokasyondan sonra bu yapı gerekli olur?
Bu yapıyı beş lokasyondan itibaren öneriyoruz. Beşin altında lokasyon sayfaları ve işletme profilleri elle yönetilebilir.
Beş ile yirmi lokasyon arasında şablon, içerik veri modeli ve NAP referans kaydı zorunlu hale gelir. Yirminin üzerinde yetki modeli, onay akışı ve ağ raporlaması olmadan tutarlılık korunamaz. Google’ın toplu konum doğrulaması için aradığı 10’dan fazla konum eşiği de bu aralığa denk gelir.
Mevcut dijital varlığınızın ölçülmüş durumunu 5 iş günü içinde görün.
Denetim ücretsizdir ve karşılığında bir çalışma zorunluluğu doğurmaz. Raporda beş eksenin bulguları madde madde yer alır: AEO cevaplanabilirliği, yapay zekâ tarayıcı erişimi, Core Web Vitals laboratuvar ölçümü, yapılandırılmış veri geçerliliği ve otomatik erişilebilirlik taraması. Örnek sayfalar site yapısından otomatik seçilir; lokasyon sayfaları ayrı bir sayfa tipiyse örneklemde yer alabilir.
Kurumsal ölçekte, çok lokasyonlu veya çok dilli yapılarla çalışıyoruz. Tek seferlik küçük işler kapsamımız dışında; bu durumda daha küçük ölçekli stüdyolara yönlendiriyoruz.