1. Multi-lokasyon nedir? (tanım + neden zor)
Multi-lokasyon, aynı markanın birden fazla şehir/ilçe veya aynı şehir içinde birden fazla şube/lokasyonda hizmet vermesidir. Zincir otellerde bu “otel grubu”, franchise yapılarda “şubeler” şeklinde görülür. Zorluk; her lokasyonun kendine ait NAP, saat, yorum, harita, fotoğraf ve yerel bağlama sahip olması gerekirken marka bütünlüğünü ve otoriteyi de korumaktır.
Bu yapı, SEO hizmetleri içinde çok lokasyonlu yerel mimari olarak yalnızca ayrı sayfa açma kararı değil; içerik ayrıştırma, teknik yapı, NAP yönetimi ve ölçümleme katmanlarının birlikte planlanmasını gerektirir.
☑ Mini Check (Multi-location Gerçekliği)
- •Her lokasyonun farklı adres/telefon/saat bilgisi var mı?
- •Aynı şehirde birden çok şube var mı?
- •Her lokasyonun farklı yorum profili ve fotoğraf seti var mı?
Ne yapmalıyım?
- • Lokasyon envanteri çıkarın (şehir/ilçe/şube).
- • Her lokasyonun “tekil kimlik” bilgilerini (NAP + saat) standardize edin.
- • Site mimarisi kararından önce GBP envanterini netleştirin.
2. Her şube için ayrı site mi, tek domain mi? (PAA + karar çerçevesi)
Kısa cevap
Çoğu senaryoda tek domain altında çok lokasyon yaklaşımı daha sağlıklıdır; çünkü marka otoritesi dağılmaz, yönetim kolaylaşır ve iç link/breadcrumb ile lokasyonlar arasında tutarlı bir mimari kurulur. Ancak (Varsayım) tamamen farklı markalar veya ayrı yönetim/teknik altyapılar varsa ayrı domain düşünülebilir.
Özellikle destinasyon bazlı rezervasyon rekabetinde çok şubeli otel zinciri SEO bakışı da önemlidir; çünkü lokasyon mimarisi, kampanya görünürlüğü ile direct booking akışının hangi şubeye yönleneceğini doğrudan etkiler.
Karar kriterleri (pratik)
- •Marka tek mi? → tek domain daha mantıklı
- •Yönetim/CRM/rezervasyon altyapısı ortak mı? → tek domain
- •Lokasyonlar birbirini destekliyor mu? → tek domain + iç link
- •Ülkeler/diller ayrışıyor mu? → alt dizin/alt alan adı (Varsayım)
☑ Mini Check (Domain Kararı)
- •Marka otoritesi tek yerde mi toplanmalı?
- •İçerik ve teknik ekipler tek mi?
- •Lokasyon sayısı artacak mı (ölçek)?
Ne yapmalıyım?
- • Tek domain varsayımıyla /lokasyonlar/ mimarisini planlayın.
- • Ayrı site düşünüyorsanız önce “operasyonel maliyet”i çıkarın (içerik, teknik, takip).
- • Canonical/redirect gibi teknik riskleri minimize edin.
3. Tek domain altında çok şube yapısı: /lokasyonlar/ bilgi mimarisi
Ölçeklenebilir bir yapı için URL ve dizin mantığı basit olmalı. En yaygın ve yönetilebilir yaklaşım:
Önerilen dizin yapıları (2 seçenek)
Seçenek A — /lokasyonlar/ + il/ilçe + şube
- •/lokasyonlar/
- •/lokasyonlar/antalya/
- •/lokasyonlar/antalya/belek/
- •/lokasyonlar/antalya/belek/{sube-adi}/
Seçenek B — /il/ilce/ + marka standardı
- •/antalya/
- •/antalya/belek/
- •/antalya/belek/{sube-adi}/
Varsayım: Mevcut site yapınız, yeni bir /lokasyonlar/ dizinini destekliyor.
Neden “il/ilçe” katmanı önemli?
Çünkü şehir/ilçe sayfaları, hem kullanıcıya “seçim ekranı” sunar hem de arama motoru için bölgesel bağlam yaratır. Ayrıca aynı şehirde birden fazla şube varsa cannibalisation riskini azaltır: şube sayfalarını “ilçe” katmanı altında ayrıştırırsınız.
Bu ayrım, lokasyon bazlı landing sayfası mimarisi kurgulanırken şehir, ilçe ve şube seviyesinde hangi sayfanın hangi sorgu grubunu karşılayacağını netleştirmek için kritik rol oynar.
☑ Mini Check (Mimari Sağlaması)
- •Lokasyonlar tek bir dizinde toplanıyor mu?
- •İl/ilçe katmanı var mı?
- •Breadcrumb mantığı tutarlı mı?
- •Şube sayfaları aynı şablonla ama farklı içerikle mi?
Ne yapmalıyım?
- • URL standardını kilitleyin ve değişiklikleri log’layın.
- • Lokasyon sayfaları için template çıkarın (aşağıda).
- • “Aynı şehirde çok şube” senaryosunu özellikle test edin.
4. Lokasyon bazlı landing sayfaları: her şube için hangi bileşenler olmalı?
Lokasyon landing sayfaları, “kopyala-yapıştır şehir sayfası” olmamalı. Her şube için gerçekten o lokasyona özel veri taşımadığınızda, hem kullanıcı hem Google “aynı sayfa” hissine kapılır.
Aynı mantık, otel içindeki ikincil işletmeler için yerel SEO tarafında da geçerlidir; restoran, spa veya beach club gibi alt birimlerin ne zaman ana otel sayfasından ayrışacağı bu landing mimarisinde baştan tanımlanmalıdır.
Şube landing bileşenleri (oteller ve yerel işletmeler için ortak)
- •H3: Şube kimliği (NAP + çalışma saatleri)
- •H3: Harita embed + ulaşım/otopark
- •H3: Yerel SSS (o lokasyonun soruları)
- •H3: Yorumlar/puan (lokasyona özel)
- •H3: Fotoğraf seti (lokasyona özel)
- •H3: Hizmet/oda/konsept farkları (varsa)
- •H3: CTA (ara/rota/rezervasyon)
| Bileşen | Zorunlu alanlar | Lokasyona özgü örnek | SEO/UX etkisi | Not |
|---|---|---|---|---|
| Şube kimliği | NAP + çalışma saatleri | Belek şubesi adresi, telefon ve sezonluk saat bilgisi | Doğru lokasyon eşleşmesi ve güven | Her lokasyonda farklı ve güncel olmalı |
| Harita embed + ulaşım | Harita, rota, otopark/ulaşım bilgisi | Antalya Havalimanı’ndan Belek şubesine ulaşım | Kullanıcı kararını kolaylaştırır | Pin doğruluğu kontrol edilmeli |
| Yerel SSS | Minimum 5 lokasyon sorusu | Bu şubede otopark var mı? Check-in saati nedir? | PAA ve Voice yanıt potansiyeli | Kopya SSS kullanılmamalı |
| Yorumlar/puan | Lokasyona özel yorum ve puan | Şube bazlı Google yorumları | Güven ve dönüşüm etkisi | Marka genel yorumu ile karıştırılmamalı |
| Fotoğraf seti | Lokasyona özel görseller | O şubeye ait oda, dış cephe, resepsiyon, çevre fotoğrafları | Kopya sayfa algısını azaltır | Aynı görsel seti tüm şubelerde kullanılmamalı |
| Hizmet/oda/konsept farkları | Şubeye özel farklar | Aile odası, spa, toplantı salonu, sahile mesafe | Niyet eşleşmesini güçlendirir | Varsa kullanılmalı |
| CTA | Ara, rota, rezervasyon | Belek şubesini ara / rota al / rezervasyon yap | Dönüşüm ve mikro aksiyon takibi | CTA lokasyonla eşleşmeli |
☑ Mini Check (Şube Sayfası Kalitesi)
- •NAP ve saatler lokasyona özel mi?
- •Harita ve ulaşım bilgisi var mı?
- •SSS lokasyona özgü mü?
- •Fotoğraflar/yorumlar aynı mı, farklı mı?
Ne yapmalıyım?
- • Her lokasyona “tekil içerik kotası” koyun (Varsayım: min. 400–800 kelime özgün blok).
- • Lokasyon fotoğraflarını aynı setten değil, şubeye özel seçin.
- • SSS’yi lokasyon bazlı güncelleyin (check-in, otopark, giriş vb.).
5. Her şube için ayrı GBP profili ve landing eşleştirme (GBP → URL haritası)
Multi-location yapılarda en kritik kırılma: her lokasyon için ayrı GBP oluşturmak ve onu doğru landing’e bağlamak. Aksi halde kullanıcı yanlış şubeye yönlenir; marka aramasında karışıklık artar.
Bu eşleşmenin sağlıklı çalışması için her lokasyon için NAP tutarlılığı ayrı ayrı korunmalı; şube adı, adres, telefon ve dizin kayıtları farklı lokasyonlar arasında karışmamalıdır.
GBP → landing eşleştirme kuralı
- •Her GBP profili tek bir lokasyon landing’ine gider.
- •Landing sayfasında o GBP’nin NAP/saatleri bulunur.
- •Aynı şehirde birden fazla şube varsa, GBP profilleri birbirine karışmayacak şekilde ayrışır (adres/pin doğruluğu).
☑ Mini Check (GBP Eşleştirme)
- •GBP profilleri lokasyon bazlı listelendi mi?
- •Her profile doğru landing URL atanmış mı?
- •Pin ve adres doğrulandı mı?
- •NAP tutarlılığı tüm platformlarda sağlandı mı?
Ne yapmalıyım?
- • GBP envanteri + landing envanteri çıkarın, 1:1 eşleyin.
- • Yanlış/duplicate profilleri temizleyin (önce).
- • Eşleştirme sonrası 30 gün KPI takip edin: call/rota/web click.
Bu aşamadan sonra lokasyon bazlı performans raporlama ile her GBP profili ve landing sayfası için görünürlük, tıklama, rota ve dönüşüm verisi ayrı izlenmelidir.
7. Teknik not: Kopya lokasyon sayfalarından kaçının (kalite + karışıklık riski)
Technical SEO notu gereği: Her lokasyon sayfasının gerçekten o şubeye özel NAP, çalışma saatleri ve içerik içermesi şarttır. Kopya/çok benzer şehir sayfaları; kalite sorunu ve cannibalisation doğurur; ayrıca marka aramalarında “yanlış şubeye” yönlendirme ve karışıklık yaşanabilir.
Bu yüzden çok lokasyonlu sayfalarda teknik SEO kontrolü URL standardı, canonical, indexlenebilirlik ve duplicate riskinin en baştan tanımlandığı ayrı bir disiplin olarak ele alınmalıdır.
8. Lokasyon Yapısı & Landing Bileşenleri Planlama Şablonunu İndir — SEO / Multi-Location
Lokasyon Yapısı & Landing Bileşenleri Planlama Şablonunu İndir — SEO / Multi-Location (v1.0)
Bu şablon; çok lokasyonlu markalarda /lokasyonlar/ dizin mimarisini, şehir/ilçe/şube hiyerarşisini ve her şube landing’inde olması gereken bileşenleri tek tabloda planlamanızı sağlar. Ayrıca GBP profillerini ilgili landing URL’leriyle 1:1 eşleştirme alanı sunar. Sonuç: marka karışıklığı azalır, lokasyon bazlı görünürlük daha ölçeklenebilir hale gelir.
Kim Kullanır?
Zincir otel yöneticisi, franchise operasyon ekibi, SEO uzmanı, ajans proje yöneticisi.
Nasıl Kullanılır?
- Lokasyon envanterini (şehir/ilçe/şube) tabloya girin.
- Her şube için landing bileşenlerini ve özgün içerik alanlarını doldurun.
- GBP profillerini landing URL ile eşleştirip yayın sonrası KPI takibini başlatın.
Ölçüm & Önceliklendirme (Kısa sürüm)
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
9. Sonuç: Çok lokasyonlu yerel SEO’da kazanç, mimariyi doğru kurmakla başlar
Çok şubeli ve çok lokasyonlu yapılarda yerel SEO, yalnızca her şube için ayrı bir sayfa açmak değildir. Asıl mesele; tek domain altında ölçeklenebilir bir URL yapısı kurmak, her lokasyona benzersiz içerik ve NAP bilgisi vermek, her GBP profilini doğru landing URL ile eşleştirmek ve iç link/breadcrumb yapısıyla marka otoritesini dağıtmadan büyütmektir.
Doğru kurulan multi-location mimarisi; kullanıcıya doğru şubeyi seçtirir, Google’a lokasyon sinyallerini net verir ve çok lokasyonlu yapılar için Yerel SEO mimarisi ile lokasyon bazlı görünürlük ve dönüşüm takibini daha yönetilebilir hale getirir. Karar aşamasında Yerel SEO hakkında sık sorulan sorular sayfası da duplicate kayıtlar, lokasyon sayfaları ve NAP yönetimi için iyi bir kontrol noktası olur.
Bir Sonraki Adım
Lokasyon hiyerarşinizi, URL yapınızı ve GBP→landing eşleşmesini ölçeklenebilir şekilde tasarlayın.
Sık Sorulan Sorular
Çok şubeli işletmelerde yerel SEO nasıl yapılır?▾
Her şube için ayrı site mi, tek domain mi?▾
Lokasyon landing sayfalarında hangi içerikler olmalı?▾
Zincir oteller için yerel SEO mimarisi nasıl kurulur?▾
İlgili İçerikler