Baki Bilişim

Mağaza zinciri dijital çözümleri: mağaza verisi tek kaynaktan

Bir mağazanın adresi, telefonu ve çalışma saati; web sitesinde, mobil uygulamada ve harita işletme profilinde aynı kaynaktan okunmalıdır. Mağaza zinciri dijital çözümleri önce bu tek kaynağı kurar, üzerine mağaza bulucu mimarisini, yerel arama görünürlüğünü ve kampanya operasyonunu inşa eder.

Sektör: Perakende · Mağaza zincirleri Son güncelleme:

Mağaza zincirlerinin dijital sorunu neden mağaza sayısıyla birlikte büyür?

Cevap

Çünkü her yeni mağaza tek bir kayıt değil, birbirini tekrar eden birden çok kayıt üretir: web sitesindeki mağaza sayfası, mobil uygulamadaki liste, harita işletme profili, kampanya sayfasındaki mağaza listesi ve çağrı merkezi ekranı. Bu kayıtlar ayrı ayrı güncellendiğinde yerel arama görünürlüğü mağaza sayısıyla orantılı olarak dağılır.

Aşağıdaki üç soru, çok lokasyonlu perakende yapılarında en sık karşılaştığımız üç yapısal hatayı tarif ediyor. Üçü de tasarım hatası değil, veri sahipliği hatasıdır.

Aynı mağazanın adresi kaç ayrı yerde yazılı?

Cevap

Uygulamada bu liste hiç kısa değildir: mağaza sayfası, mağaza bulucu veri kaynağı, mobil uygulama, harita işletme profilleri ve kampanya materyalleri. NAP tutarsızlığı, yani ad-adres-telefon üçlüsünün kanallar arasında farklılaşması, arama motorunun hangi kaydın doğru olduğuna karar verememesine ve mağazanın yerel sonuçlarda geriye düşmesine yol açar.

NAP, işletmenin adı, adresi ve telefonundan oluşan üçlüdür; yerel aramada bir işletmeyi tekilleştirmek için kullanılan temel kimlik verisidir. Terimin tanımı için sözlük sayfasına bakabilirsiniz.

Mağaza bulucu neden tek bir sayfada toplanamaz?

Cevap

Tek sayfada toplanan ve yalnızca JavaScript ile doldurulan bulucular, arama motorlarına tek bir URL gösterir; “İzmit’te mağaza” gibi bir sorgunun karşılığı olacak indekslenebilir sayfa yoktur. Her mağazanın kalıcı bir URL’si, kendi başlığı ve kendi yapılandırılmış verisi olduğunda arama motoru mağazayı ayrı bir varlık olarak okuyabilir.

Kampanya operasyonu performansı neden bozar?

Cevap

Sezon kampanyaları çoğunlukla şablonun dışına çıkar: ölçüsü verilmemiş banner görselleri, sonradan eklenen üçüncü taraf etiketleri ve geçici açılış sayfaları. Sonuç, düzen kaymasının artması ve en büyük içerik ögesinin gecikmesidir. Kampanya alanları şablonun içinde tanımlandığında aynı içerik performans bütçesini bozmadan yayınlanabilir.

2,5 sn

Google’ın “iyi” kabul ettiği LCP (Largest Contentful Paint) eşiği. Eşik site geneli için değil, her URL için ayrı ayrı geçerlidir; mağaza bulucu, ilçe listesi ve kampanya sayfaları da bu ölçüme dahildir.

Kaynak: Google web.dev — Core Web Vitals (yeni sekmede açılır) · Erişim: 29 Temmuz 2026

Metriklerin tanımı ve ölçüm yöntemi için Core Web Vitals rehberine bakın.

Perakende zincirinde bu kararı kim veriyor ve neye bakıyor?

Cevap

Kararı tek kişi vermez. Pazarlama tarafı kampanya yayın hızına, perakende operasyon tarafı mağaza verisinin doğruluğuna, bilgi teknolojileri tarafı entegrasyon ve yetkilendirmeye, satın alma tarafı sözleşme ve sahipliğe bakar. Teklif bu dört bakışın hepsine aynı belgede cevap vermiyorsa süreç değerlendirme aşamasında durur.

Perakende zincirinde dijital tedarikçi kararına katılan roller
Karar veren Sorduğu soru Kanıt olarak istediği
Pazarlama / dijital direktörü Bir kampanyayı mağaza kırılımıyla birlikte kaç günde yayına alabilirim? Şablon envanteri ve yayın akışı; kampanya bloğunun tanımlı alanları
Perakende operasyon direktörü Bir mağazanın çalışma saati değişince kaç sistemi elle güncellemem gerekiyor? Tek kaynak veri modeli ve güncelleme akışının şeması
Bilgi teknolojileri Mağaza verisi hangi sistemden okunuyor, kim yazma yetkisine sahip? Entegrasyon şeması, yetki modeli ve veri sahipliği tablosu
Satın alma Kaynak kod, tasarım ve mağaza hesapları kimin adına kalıyor? Sözleşme kapsamı, telif ve devir maddeleri — Çalışma Modelimiz’de yazılı
Bölge / mağazacılık müdürü Kendi mağazamın sayfasındaki bilgi doğru mu, yanlışsa nasıl düzeltilir? Mağaza bazlı doğrulama ve düzeltme talebi akışı

Bu beş rolün sorularının tek bir tedarikçide karşılanmasının nedeni pratik: mağaza verisini yazan ekip ile o veriyi arama motorlarına açan ekip farklı olduğunda, tutarsızlık kimsenin sorumluluğunda kalmıyor. Gerekçenin ayrıntısı Neden Baki Bilişim sayfasında.

Bir mağaza zinciri için hangi hizmet kombinasyonu doğru?

Cevap

Çekirdek kombinasyon dörttür: bayi ve şube ağı dijital yönetimi, kurumsal web sitesi, yapılandırılmış veri ve Core Web Vitals. Sadakat senaryosu varsa mobil uygulama, çevrim içi satış varsa e-ticaret eklenir. Hizmetler ayrı ayrı da alınabilir; aşağıdaki tablo bir paket değil, uygulama sırası önerisidir.

Mağaza zinciri için ihtiyaç–hizmet eşlemesi ve önerilen sıra
Sıra İhtiyaç Hizmet Neden bu sırada
01 Mağaza veri modeli, lokasyon şablonu ve yetki akışı Bayi ve Şube Ağı Dijital Yönetimi Tek kaynak kurulmadan diğer her çalışma aynı hatayı çoğaltır
02 Site altyapısı, bulucu ve kampanya şablonları Kurumsal Web Sitesi Şablon sistemi, mağaza sayısı büyüdükçe maliyeti sabit tutar
03 Çoklu lokasyonun makine tarafından okunabilmesi Yapılandırılmış Veri (Schema) Mağaza sayfaları yayına girer girmez varlık olarak tanımlanmalı
04 Kampanya ve sezon trafiğinde hız kaybı yaşanmaması Core Web Vitals ve Hız Performans bütçesi kampanya kurgusundan önce tanımlanmalı
05 Şehir, ilçe ve mağaza sorgularında görünürlük Kurumsal SEO Teknik altyapı hazır olduktan sonra anlamlı sonuç verir
06 “Yakınımda açık mağaza” tipi cevaplarda kaynak gösterilme AEO — Answer Engine Optimization Cevaplanabilir pasaj yapısı, mağaza verisi netleştikten sonra kurulur
07 Sadakat, kupon ve tekrar eden kullanım Kurumsal Mobil Uygulama Uygulama, site ile aynı mağaza verisini okuyacak biçimde kurgulanır
08 Çevrim içi satış, mağazadan teslim ve stok görünürlüğü E-ticaret Mağaza ve stok verisi doğrulanmadan satış akışı kurulmamalı

Hizmetlerin tamamı ve kapsam matrisi Hizmetler sayfasında. Bayilik ve franchise modeliyle çalışan zincirler için yetki ve marka tutarlılığı tarafı ayrıca Bayilik ve Franchise Ağları sayfasında ele alınıyor.

Mağaza zinciri sitesinin karşılaması gereken teknik şartlar neler?

Cevap

Dört şart: her mağaza için kalıcı ve indekslenebilir bir URL; her mağaza sayfasında lokasyonu tanımlayan yapılandırılmış veri ve haftalık çalışma saatleri; mağaza verisinin site, uygulama ve işletme profillerine tek kaynaktan dağıtılması; kampanya bloklarının performans bütçesi içinde kalması. Bu dördü sağlanmadan yerel görünürlük çalışması kalıcı sonuç vermez.

Mağaza bulucu bilgi mimarisi nasıl kurulur?

Cevap

Dört seviyeli ve her seviyesi indekslenebilir bir ağaç kurulur: ülke, il, ilçe, mağaza. Her seviye kendi kalıcı URL’sinde yayınlanır ve o seviyeye özgü bilgi taşır. Böylece “İstanbul mağazaları” ile “Kadıköy mağazası” sorguları farklı sayfalara düşer, sayfalar birbirinin yerine geçmez.

  1. /magazalar/

    Seviye 00 · Ülke — tüm mağazalar, il listesi, arama ve filtre

    1. /magazalar/istanbul/

      Seviye 01 · İl — ilçe listesi, il geneli mağaza sayısı ve hizmetler

      1. /magazalar/istanbul/kadikoy/

        Seviye 02 · İlçe — o ilçedeki mağazalar ve ulaşım bilgisi

        1. /magazalar/istanbul/kadikoy/moda/

          Seviye 03 · Mağaza — adres, çalışma saatleri, hizmetler, yapılandırılmış veri

Mağaza bulucu bilgi mimarisi: dört seviye, dört ayrı indekslenebilir URL. Seviye adları örnektir; kırılım marka ve mağaza dağılımına göre belirlenir.

Buradaki asıl risk ince içeriktir: yalnızca adresi değişen, geri kalanı birebir aynı olan mağaza sayfaları arama motoru tarafından kopya kabul edilebilir. Her mağaza sayfasının kendine ait en az bir özgün bilgi taşıması gerekir — otopark ve erişilebilirlik durumu, o mağazaya özgü hizmet noktaları, ulaşım tarifi, bayram ve istisna günü saatleri gibi.

Çoklu lokasyon yapılandırılmış verisi nasıl yazılır?

Cevap

Her mağaza sayfasına, o mağazayı tanımlayan tek bir yapılandırılmış veri düğümü yazılır: Store tipi, kalıcı bir @id, merkez şirkete bağlanan parentOrganization ilişkisi, tam adres ve OpeningHoursSpecification ile haftalık saatler. Bu düğüm, işletme profilindeki veriyle çelişmemelidir.

{
  "@context": "https://schema.org",
  "@type": "Store",
  "@id": "https://ornek-marka.com/magazalar/istanbul/kadikoy/moda/#store",
  "name": "{MARKA} — Moda Mağazası",
  "branchCode": "IST-KAD-01",
  "parentOrganization": { "@id": "https://ornek-marka.com/#organization" },
  "url": "https://ornek-marka.com/magazalar/istanbul/kadikoy/moda/",
  "telephone": "+90...",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "...",
    "addressLocality": "Kadıköy",
    "addressRegion": "İstanbul",
    "addressCountry": "TR"
  },
  "openingHoursSpecification": [
    { "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"],
      "opens": "10:00", "closes": "22:00" },
    { "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Sunday",
      "opens": "11:00", "closes": "21:00" }
  ],
  "areaServed": { "@type": "AdministrativeArea", "name": "Kadıköy" }
}

Örnektir; alan adı, telefon ve adres alanları gerçek mağaza verisiyle doldurulur. Graf mimarisi, @id tasarımı ve doğrulama yöntemi için Schema.org rehberine bakın.

Kampanya ve sezon içerikleri operasyonda nasıl yönetilir?

Cevap

Kampanya, ayrı bir mikro site değil şablonun bir bloğudur. Blok; başlangıç–bitiş tarihi, geçerli mağaza listesi ve sabit görsel ölçüleriyle tanımlanır. Yayın öncesi performans bütçesi kontrol edilir. Böylece kampanya döneminde Core Web Vitals değerleri korunur ve kampanya bittiğinde geride ölü sayfa kalmaz.

Uygulama ve sadakat programı bu yapıya nasıl bağlanır?

Cevap

Uygulama, mağaza verisini siteyle aynı kaynaktan okur; kendi ayrı mağaza listesini tutmaz. Sadakat kimliği tek olur, kampanya içeriği tek yerde yönetilir. Bu kurulum yoksa müşteri uygulamada gördüğü kampanyayı mağazada bulamaz ve hatanın hangi ekibe ait olduğu belirsizleşir.

Mağaza zinciri sitesi için teknik gereksinim listesi ve kabul ölçütleri
Gereksinim Kabul ölçütü Nasıl doğrulanır
Mağaza başına kalıcı URL Mağaza adı, adresi ve saatleri JavaScript çalışmadan da sunucudan gelir Sayfa kaynağı görüntüleme + tarayıcıda JavaScript kapalı test
Seviyeli bulucu mimarisi Ülke, il, ilçe ve mağaza seviyelerinin tamamı ayrı URL’de Site haritasında dört seviyenin de listelenmesi
Mağaza yapılandırılmış verisi Her mağaza sayfasında 0 doğrulama hatası Rich Results Test ve Search Console geliştirme raporları
Çalışma saatleri verisi Haftalık saatler ve istisna günleri yapılandırılmış veride tanımlı Doğrulayıcı çıktısı + işletme profiliyle karşılaştırma
Tek kaynak mağaza verisi Site, uygulama ve işletme profili aynı alanları aynı değerle okur Kanal envanteri karşılaştırma tablosu
NAP tutarlılığı Ad, adres ve telefon tüm kanallarda birebir aynı Dönemsel NAP denetimi ve tutarsızlık sayımı
Kampanya bloğu performans bütçesi Kampanya döneminde mobil LCP < 1,8 sn ve CLS < 0,05 Yayın öncesi Lighthouse ölçümü + yayın sonrası saha verisi
Erişilebilirlik Bulucu, filtre ve harita alternatifi klavyeyle kullanılabilir WCAG 2.1 AA kontrol listesi ve klavye ile uçtan geçiş testi

Mağaza zinciri dijitalinde ne ölçülür?

Cevap

Altı eksen ölçülür: mağaza sayfalarının indekslenme oranı, NAP tutarsızlığı sayısı, mağaza ve bulucu şablonlarının Core Web Vitals değerleri, yapılandırılmış veri hata sayısı, yerel sorgulardaki görünürlük ve mağaza sayfasından yol tarifi ya da arama eylemine dönüşüm. Sıralama garantisi verilmez.

Mağaza zinciri için ölçüm ve raporlama çerçevesi
Ölçüm Ne gösterir Araç Ritim
Mağaza sayfası indekslenme oranı Yayınlanan mağaza sayfalarının kaçının aramaya girdiği Search Console sayfa indeksleme raporu Aylık
NAP tutarsızlığı sayısı Kanallar arasında farklılaşan ad, adres, telefon kaydı adedi Kanal envanteri karşılaştırması Üç aylık
Core Web Vitals (mağaza ve bulucu şablonu) Gerçek kullanıcı deneyimi ile laboratuvar ölçümü arasındaki fark CrUX saha verisi + Lighthouse laboratuvar ölçümü Aylık
Yapılandırılmış veri hata sayısı Mağaza düğümlerinin makine tarafından hatasız okunup okunmadığı Rich Results Test + Search Console Her yayın sonrası
Yerel sorgu görünürlüğü Şehir, ilçe ve “yakınımda” tipi sorgularda gösterim ve tıklama Search Console sorgu raporu + işletme profili içgörüleri Aylık
Mağaza sayfasından eylem Yol tarifi, arama ve çalışma saati görüntüleme sayısı İşletme profili içgörüleri + site olay ölçümü Aylık

Neyi taahhüt etmiyoruz?

  • Arama sonuçlarında belirli bir sıra ya da harita bloğunda belirli bir konum.
  • Üçüncü taraf platformların (harita, mağaza profili, uygulama mağazası) politika değişiklikleri.
  • Üretken yapay zekâ araçlarının çıktısı — bu çıktılar deterministik değildir; ölçtüğümüz şey makine okunabilirliği ve alıntılanabilirliktir.

Ölçtüğümüz ve yayımladığımız değerlerin tamamı ölçüm tarihiyle birlikte Kanıt sayfasında.

Mağaza zincirlerinden en sık gelen beş soru

Mağaza sayfaları nasıl kurgulanır?

Her mağaza kendi kalıcı URL’sinde yayınlanır ve şu alanları taşır: tam adres, telefon, haftalık çalışma saatleri ile istisna günleri, o mağazaya özgü hizmetler (otopark, teslim noktası, servis noktası), ulaşım tarifi ve mağazayı tanımlayan yapılandırılmış veri.

Şablon tüm mağazalarda aynıdır; içerik mağazaya göre değişir. Yalnızca adresi değişen kopya sayfalar ince içerik sayılır ve indekslenmeme riski taşır.

Yerel paket görünürlüğü nasıl artar?

Yerel paket, arama sonuç sayfasında harita ile birlikte gösterilen işletme bloğudur. Görünürlük üç şeye bağlıdır: işletme profilinin eksiksiz ve güncel olması, sitedeki mağaza sayfasının profil verisiyle birebir aynı bilgiyi taşıması ve o mağaza sayfasının indekslenebilir olması.

Profil ile site çeliştiğinde arama motoru hangi kaydın doğru olduğuna karar veremez; bu belirsizlik doğrudan görünürlük kaybı olarak geri döner.

Kaç mağazadan sonra mağaza bulucu gerekir?

Mağaza sayısı tek başına ölçüt değildir. Uyguladığımız eşik şudur: birden fazla ilde mağazanız varsa ya da tek bir mağazanın bilgisini güncellemek için iki ayrı sistemi elle düzeltmeniz gerekiyorsa mağaza bulucu ve tek kaynak veri modeli gerekir.

Tek şehirde birkaç mağaza için sade bir mağaza listesi ve mağaza başına birer sayfa yeterlidir.

Kampanyalar siteyi yavaşlatır mı?

Kampanya bloğu şablonun dışına çıktığında yavaşlatır. Ölçüsü verilmemiş banner görselleri düzen kaymasına, sonradan eklenen üçüncü taraf etiketleri ise gecikmeye yol açar.

Kampanya alanları şablonda tanımlıysa, görsel ölçüleri sabitse ve yayın öncesi performans bütçesi kontrol ediliyorsa kampanya dönemi Core Web Vitals değerlerini bozmaz.

Uygulama mı mobil site mi?

İkisi farklı işlere yarar. Mobil site keşif kanalıdır: arama motorundan gelen, mağaza arayan, çalışma saatine bakan kullanıcıya hizmet eder ve indekslenir. Uygulama ise sadakat ve tekrar eden kullanım kanalıdır; indekslenmez.

Uygulama, mobil sitedeki eksiği kapatmaz. Her iki kanal da aynı mağaza verisini aynı kaynaktan okumalıdır.

Diğer sektörlerin çözüm sayfaları için Sektörel Çözümler sayfasına, cevap motorlarında kaynak gösterilme konusunun tanımı için AEO nedir? rehberine bakabilirsiniz.

Mağaza verilerinizin kanallar arasında nerede ayrıştığını 5 iş günü içinde görün.

Denetim ücretsizdir ve karşılığında bir çalışma zorunluluğu doğurmaz. Raporda mağaza sayfalarının indekslenebilirliği, NAP tutarsızlıkları, yapılandırılmış veri geçerliliği, Core Web Vitals değerleri ve WCAG 2.1 AA eksikleri madde madde yer alır.

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.