Franchise ağları, bir web sitesi kurarken iki çelişen taleple yüzleşir: marka tutarlılığı ve yerel alaka. İstanbul'daki şube ile Ankara'daki şube aynı logoyu, aynı renk paletini ve aynı hizmet listesini paylaşır; ama bir kullanıcı "Kadıköy'de oto servis" yazarak arama yaptığında Ankara şubesinin sayfası değil, Kadıköy'deki şubeye ait net bir sayfa gelmesi gerekir. Bu iki gereksinim yan yana gelince mimari karar kaçınılmaz hale gelir.

Yanlış kurulan franchise mimarileri genellikle iki uçta hata yapar. Kimileri merkezi yapıyı o kadar sıkı korur ki şehir sayfaları sadece adres değiştirilmiş kopyalara dönüşür; kimileri ise yerel sayfaları o kadar serbest bırakır ki marka kimliği dağılır ve SEO tarama botları için tutarsız bir yapı ortaya çıkar. İkisi arasındaki dengeyi kurmak bir tasarım kararıdır, bir teknoloji kararı değil.

Senaryo üzerinden ilerleyeceğiz: Türkiye genelinde 40 şubeye sahip bir kurye şirketi. Kararlar soyut kalmayacak, bu ağ üzerinden somutlaşacak.

Franchise site mimarisi neden tekli domain altında kurulur?

Franchise ağlarının bir kısmı her şube için ayrı domain açar. "ankara-kurye.com", "istanbul-kurye.com" gibi yapılar kısa vadede cazip görünür; şubeler bağımsız hareket edebilir, yerel çalışmalar ayrı ayrı yürütülür. Ama zamanla bu yapının maliyeti ortaya çıkar: her domain ayrı bir otorite birikimi gerektirir, merkezi içerik çabaları dağılır ve marka bütünlüğü yönetilemez hale gelir.

Tekli domain seçeneğinde birikim merkezileştiği için çoğu durumda daha sağlam bir zemin oluşur. kurye.com/istanbul ve kurye.com/ankara yapısında ana domain için alınan her iç bağlantı tüm alt sayfalara akar. Şube sayfaları sıfırdan otorite kazanmak zorunda kalmaz; anasayfadan ve üst kategori sayfalarından akan yapısal güç onları da taşır.

Subdomain seçeneği (istanbul.kurye.com) zaman zaman orta yol olarak tercih edilir. Teknik açıdan ayrı site gibi davranabilen subdomainler bazı tarama botları tarafından farklı değerlendirilebilir ve tekli domainin sunduğu birikimi tam olarak aktaramayabilir. Büyük kurumsal yapılarda veya farklı ülke pazarlarına açılan franchise modellerinde subdomain tercih edilir; tek ülke, tek dil, tek marka için ise tekli domain ve alt dizinler daha net bir mimari sunar.

Tekli domain her zaman doğru seçim değildir. Çok farklı hizmet kategorileriyle çalışan franchise ağlarında şubeler arasındaki içerik farkı o kadar büyüyebilir ki aynı domain altında tutmak karmaşıklığı da beraberinde getirir. Asıl soru şudur: şubelerin içerikleri yüzde seksenin üzerinde örtüşüyor mu, yoksa her şube fiilen farklı bir işletme mi? Yanıt ikincisiyse, ayrı domain daha dürüst bir mimari olabilir.

URL hiyerarşisi: şehir, ilçe ve şube sayfalarının yeri

Tekli domain kararı verildikten sonra URL yapısı kurulur. Franchise mimarisinde en yaygın üç katman şehir, ilçe ve hizmet düzeyidir. Hangi katmanların URL'ye yansıyacağı ağın büyüklüğüne ve kullanıcı arama davranışına göre belirlenir.

40 şubeli kurye şirketi için makul bir yapı şöyle görünür:

/istanbul/
/istanbul/besiktas/
/istanbul/besiktas/ayni-gun-kurye/

Tıklama derinliği üçü geçmemelidir. Dördüncü seviyeye inmek sayfa keşif süresini uzatır; SEO tarama botları sınırlı kaynak ayırdığından derin sayfalara daha az zaman bırakır. Bunun pratik anlamı şudur: şube bazlı çok ayrıntılı URL yapısı, taranması en zor sayfaların tam da en yerel sayfalar olması sonucunu doğurabilir ve bu hiyerarşinin amacıyla çelişir.

Şehir mi ilk, hizmet mi ilk? Bu sıralama, kullanıcıların arama sorgularında hangi boyutu öne çektiğine göre verilir. "Beşiktaş kurye" sorgusu ilçe-hizmet sırasını önerirken "kurye İstanbul" sorgusu şehir-hizmet sırasını işaret eder. İkisi aynı anda doğru olamaz; bir sıra seçilir ve tutarlı uygulanır. Tutarsız URL yapısı hem kullanıcı hem de tarama botu için anlamsız bir hiyerarşi üretir ve ilerleyen dönemde düzeltmek yüksek maliyete yol açar.

Her şeye URL açmak da bir tuzaktır. 40 şubede her ilçe ve her hizmet kombinasyonu için ayrı sayfa açmak matematiksel olarak hızla yüzlerce sayfaya ulaşır; içeriğin bu sayfalara yetişmesi ise nadiren mümkün olur. URL kararı içerik kapasitesiyle birlikte verilmelidir.

Merkezi içerik ile yerel içerik arasındaki sınır

Sınır nettir. Merkezi şablondan gelen içerik: marka tanımı, hizmet kategorisi açıklamaları, genel süreç bilgileri, yasal metinler. Yerel içerik: adres, çalışma saatleri, o şubenin kapsadığı mahalleler, şubeye ait iletişim bilgileri ve varsa o bölgeye özel hizmet notları. İkisinin karışması kaçınılmazdır; ama hangi parçanın hangi kaynaktan geldiği net olmalıdır.

Sorun, şablonun sayfanın büyük bölümünü doldurduğu ama yerel kısmın boş kaldığı durumda başlar. "40 şubemiz boyunca kaliteli hizmet sunuyoruz, adres: Beşiktaş" biçimindeki bir sayfa gerçek anlamda yerel değildir. SEO tarama botları bu sayfayı indeksler ama bölgesel sorgularda güçlü bir sinyal veremez; daha önemlisi, kullanıcı için hiçbir ek değer taşımaz.

Sınırı çizmenin pratik yolu her sayfa tipi için şu soruyu sormaktır: "Sadece bu şubeye ait olan ne var?" Yanıt birkaç kelimeden ibaretse sayfa hâlâ şablona dayanıyor demektir. Bilgi mimarisi planlamasında içerik sorumluluk sınırlarını erkenden belirlemek, bu tür birikim sorunlarını daha ağ küçükken önler; 40 şubede sorun görünür hale geldiğinde düzeltmek çok daha maliyetlidir.

Bir de hibrit içerik sorunu var. Şube sayfasında hem merkezi hem yerel bilgi yer alıyorsa bu iki katmanın sayfa içinde net biçimde yapılandırılması gerekir. Kullanıcı sayfaya geldiğinde ne bulmak istediğini bilir: adres, saat, kapsam. Bunlar sayfanın alt yarısına gömülü değil, hızlıca görünür yerde olmalıdır. Yapısal sıralama içerik kalitesiyle doğrudan ilişkilidir.

Tekrarlayan içerik riski ve farklılaşma mantığı

40 şubeli bir ağda şablon kullanımı kaçınılmazdır. Ama şablon oranı yüksek, özgün içerik oranı düşük sayfalar yığıldığında tekrarlayan içerik sorunu baş gösterir. Tarama botları bu sayfaları aynı içeriğin farklı URL'lerdeki kopyaları olarak değerlendirebilir.

İki yaklaşım var. İlki içerik farklılaştırmasıdır: her şube sayfasına o konuma özgü bilgi eklenir. Servis alanı, çalışma saatleri, kapasite, yakın referans noktaları, varsa o şubenin sunduğu ek hizmetler. Bu bilgiler şablona girilen dinamik verilerdir ama sayfa içinde anlamlı biçimde yer almalıdır; yalnızca meta alanlara gömülü kalmamalıdır.

İkincisi teknik kontroldür: standart içerikle doldurulamayan şube sayfaları geçici olarak dizin dışında tutulur; içerik tamamlandığında indekse alınır. Yüzlerce boş sayfa yerine sınırlı sayıda ama kaliteli sayfa dizini daha sağlam bir yapı üretir.

İki yaklaşım çelişmez; büyük ağlarda genellikle birlikte uygulanır. Hazır içeriği olan şubeler indekslenir, içerik bekleyenler devre dışında tutulur ve kademeli olarak sisteme dahil edilir. Bu yaklaşım ağın büyüme hızıyla içerik üretim kapasitesini dengelemenin en doğrudan yoludur.

Crawl bütçesi ve dizin yönetimi

Büyük franchise ağlarında sayfa sayısı hızla büyür. 40 şube, her şubede ortalama 3 ilçe ve her ilçede 5 hizmet sayfası kombinasyonu bile 600 sayfayı aşar. SEO tarama botları bir siteyi her ziyaretinde sınırlı kaynak ayırır; bu kaynağın dağılımı sitenin iç yapısına göre şekillenir. Derin URL yapısı, kötü iç linkleme ve büyük miktarda ince içerik bir araya geldiğinde bütçenin önemli bir kısmı değersiz sayfalara gider, asıl önem taşıyan şube sayfaları ise seyrek ziyaret edilir.

Crawl bütçesini düzenlemek için birkaç araç kullanılır. Robots.txt ile geçici içeriklere, filtre parametrelerine veya hazır olmayan şube sayfalarına erişim kısıtlanabilir. Canonical etiket, şablon nedeniyle birebir aynı içerik sunan iki sayfa arasında hangisinin tercih edileceğini işaret eder. Sitemap, öncelikli sayfaların listesini net biçimde sunar; hazır olmayan şube sayfaları sitemapa dahil edilmeden bota gösterilmez.

40 şubeli bir ağda sitemapı tek dosyada tutmak yerine şehir bazlı parçalara ayırmak pratik bir düzen sağlar. Sitemap indeksi ana sitemapa bağlanır; her şehir kendi dosyasını taşır. Bu yapı hem yönetimi kolaylaştırır hem de hangi şubenin hangi sayfasının aktif olduğunu takip etmeyi basitleştirir.

Yerel sayfalar arası iç linkleme planı

Şube sayfaları tek başına çalışmaz; birbirlerine ve üst kategori sayfalarına bağlanmaları gerekir. Ama bu bağlantı planlanmadan oluşursa ağ değil, dağınık bir sayfa yığını ortaya çıkar. Yapısal kontrol listesi kapsamında iç linkleme planının sayfalar yayına girmeden önce çizilmesi bu dağınıklığı önler.

Franchisede iç linklemenin üç akışı vardır. Birincisi dikey akış: şube sayfası ilçe sayfasına, ilçe sayfası şehir sayfasına, şehir sayfası ulusal hizmet sayfasına bağlanır. Bu akış hiyerarşiyi güçlendirir ve tarama botunun yapıyı anlayarak ilerlemesini sağlar. İkincisi yatay akış: aynı şehirdeki şubeler birbirine bağlanır. Kullanıcı yanlış şubeye geldiğinde doğruya yönlendirilir. Üçüncüsü hizmet kesişimi: Beşiktaş ilçe sayfasından aynı gün kurye hizmetine bağlantı kurulur; hizmet sayfasından da bölge sayfalarına dönülür.

Her üç akış da otomatik değildir. Şablon bu bağlantıları içeriyorsa büyük ağlarda sürdürmek kolaylaşır; içermiyorsa editöryal müdahale gerekir. Editöryal müdahale ölçeklendiğinde tutarlılık bozulur. Periyodik mimari denetimde iç link haritası okunduğunda hangi sayfaların kopuk kaldığı görünür hale gelir; bu bilgi olmadan kopukluk birikir ve düzeltmek giderek zorlaşır.

Tekli domain altında 40 şubeyi navigasyona taşımak neredeyse imkânsızdır. Ana menüde 40 şehir veya ilçe adı sıralansa bile kullanıcı için anlamlı bir yapı oluşmaz. Navigasyon şube listesi için değil, hizmet kategorileri için kullanılır; şube erişimi ise konum tespiti veya arama ile sağlanır.

Konum tabanlı yönlendirme yaygın bir çözümdür: kullanıcı siteye girdiğinde tarayıcı izniyle veya manuel seçimle şehri belirlenir ve ilgili şube sayfasına yönlendirilir. Bu çözüm kullanışlıdır ama bağımlılık yaratır; konum tespiti çalışmadığında kullanıcı ana sayfada kaybolabilir. Yedek olarak "Şubelerimiz" sayfası liste formatında tüm şubeleri sunar ve navigasyondan erişilebilir durumda tutulur.

Navigasyonun ölçek altında nasıl davrandığını anlamak için navigasyonun sade tutulması üzerine ayrı bir değerlendirme yapmak gerekebilir. Özellikle şube sayısı ikiye katlandığında mevcut navigasyon kararlarının çoğu işlevsiz hale gelir ve yeni bir düzenleme zorunlu olur.

Şube eklenince veya kapanınca mimari nasıl güncellenir?

Franchise ağları durağan değildir. Şube açılır, kapanır, birleşir veya başka bir ilçeye taşınır. Her değişiklik mimariyi etkiler. Kapalı şube sayfaları silinirse, o sayfalara gelen tüm bağlantılar kırılır. Arama botları ve kullanıcılar 404 hatalarıyla karşılaşır. 301 yönlendirme planı bu geçişleri yönetmenin temel aracıdır; kapanan şubenin sayfası en yakın aktif şubeye veya ilgili şehir sayfasına yönlendirilir.

Yeni şube açılışında ise süreç tersten işler. Sayfa önce hazırlanır, içerik tamamlanır, sitemap güncellenir ve indeksleme tetiklenir; bu adımlar sıralanmadan şube sayfası yayına çıkmaz. İçeriksiz veya şablon dışına çıkmamış bir sayfayı yayına almak, sonradan geri almaktan daha maliyetlidir.

Şube eklenip çıkarılması otomatikleşebilen tek süreçtir. CMS'in şube kaydını güncellediğinde siteye yansıması, canonical ve yönlendirme kurallarının otomatik oluşması büyük ağlarda manuel hatayı azaltır. Headless CMS yapılarında bu tür otomasyonlar içerik ve yapıyı birbirinden bağımsız yönetmeyi kolaylaştırır; franchise ağları için bu ayrım özellikle değerlidir.

Franchise mimarisi aslında iki paralel kararın bütünüdür: merkezi kararlar ve yerel kararlar. Merkezi kararlar değişmeden uygulanır, yerel kararlar bölgeye göre şekillenir. Bu sınır bulanıklaştığında ne marka tutarlılığı kalır ne yerel alaka. Sınırın net olduğu ağlarda ise şube sayısı ikiye katlanırken mimari karmaşıklık aynı oranda artmaz.

Senaryo boyunca 40 şubeli kurye ağı üzerinde ilerlediğimizde gördük ki her karar bir sonrakini etkiliyor: domain seçimi URL yapısını, URL yapısı crawl bütçesini, crawl bütçesi iç linkleme önceliğini belirliyor. Ağ büyüdükçe bu bağımlılıklar daha görünür hale geliyor ve baştan verilmemiş kararların maliyeti katlanıyor.

Mimari doğru kurulduğunda şube eklemek rutin bir operasyona dönüşür. Yanlış kurulduğunda her yeni şube, var olan kırıkların üzerine yeni bir katman ekler. Franchise modelinin ölçek avantajı, sitenin bu ölçeği taşıyacak şekilde tasarlanıp tasarlanmadığına bağlıdır.