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.
☑ 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.
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.
☑ 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.
Ş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.
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.
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.
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 lokasyon bazlı görünürlük ile dönüşüm takibini daha yönetilebilir hale getirir.
Bir Sonraki Adım
Lokasyon hiyerarşinizi, URL yapınızı ve GBP→landing eşleşmesini ölçeklenebilir şekilde tasarlayın.