Bir sitenin altyapısını değiştirmek, binanın çatısını yenilerken taşıyıcı duvarları yerinde tutmaya çalışmaya benzer. PHP monolitinden modern bir headless yapıya geçiş ya da eski bir içerik yönetim sistemini statik site üreticisiyle değiştirme gibi kararlar, çoğu zaman URL mimarisi üzerinde beklenmedik etkiler bırakır. Proje başında "sadece teknik altyapıyı değiştireceğiz, içerik aynı kalacak" denilen durumlarda bile URL yapısı, iç link kurgusu ve site hiyerarşisi tehdit altına girebilir.

Sorun çoğunlukla teknik değil, mimari bir karar boşluğundan kaynaklanır. Geliştirici takımı yeni sisteme içerikleri aktarırken URL şemalarını yeniden yorumlar; pazarlama ekibi kategori isimlerini günceller; içerik editörleri eski slug'ları anlamlı bulmaz ve yeniden yazar. Her biri küçük bir değişiklik gibi görünür. Toplam etki ise birkaç yüz 301 yönlendirmesini aşan bir yapısal bozulmaya dönüşebilir; URL şeması, iç link ağı ve site hiyerarşisi aynı anda ve birbirinden bağımsız biçimde değiştiğinde ortaya çıkan hasar, başlangıçtaki beklentilerin çok üzerindedir.

Eski altyapıyı değiştirirken ne korunmalı, ne değiştirilebilir ve bu kararlar hangi sıraya göre alınmalı; bu üç soruya verilen yanıtlar modernizasyon projesinin uzun vadeli etkisini büyük ölçüde belirler.

Geçişte mimari bellek nasıl kaybolur?

Eski sistemlerde URL şeması genellikle sezgisel değil, tarihsel bir birikimin ürünüdür. 2014'te eklenen bir kategori, 2018'de taşınan bir alt bölüm, 2021'de yeniden adlandırılan bir ürün grubu; bunların hepsi mevcut URL yapısının içindedir. Yeni sisteme geçiş sırasında bu tarihsel mantık görünmez hale gelir, çünkü eski sistemin veritabanı, kategori ağacı ve slug oluşturma kuralları aktarılmaz, yalnızca içerik metni aktarılır.

Mimari bellek tam olarak budur: hangi URL'nin neden o şekilde göründüğünü açıklayan bağlam. Bu bağlam kaybolunca yeni ekip mantıklı görünen ama yapısal olarak yanlış olan kararlar alır. Örneğin eski sistemde /hizmetler/kurumsal/danismanlik/ şeklinde üç seviyeye yayılmış bir URL, yeni sistemde /kurumsal-danismanlik/ biçimine çekilebilir. İçerik aynıdır, hiyerarşi değil.

Hiyerarşi basitleşince ne olur? Üst kategori sayfaları link değerini kaybeder, alt sayfalar yetim kalır, sitenin konu kümesi yapısı dağılır. Bunların hepsi tek bir mimari kararın zincirleme sonucudur ve çoğu zaman geçişten aylarca sonra fark edilir.

URL yapısını koruyup korumama kararı nasıl verilir?

Her URL'yi koruma ya da her şeyi yeniden yapılandırma arasında geniş bir alan vardır ve pratikte en sağlıklı yaklaşım bu alandadır. Karar verebilmek için önce mevcut URL havuzunu üç gruba ayırmak gerekir. Dışarıdan bağlantı alan, tarama botlarının düzenli ziyaret ettiği ve site içi linklerin yoğunlaştığı URL'ler birinci grubu oluşturur; bunlar her durumda korunur. Yalnızca iç trafiği olan ve herhangi bir dış referansı bulunmayan URL'ler ikinci gruba girer; bunlar değiştirilebilir ama yönlendirme gerektirir. Trafiği sıfıra yakın, iç linki zayıf, içerik değeri düşük URL'ler ise üçüncü gruba girer; bunlar birleştirme, silme veya yeniden yapılandırma adayıdır.

Bu gruplama için sezgisel değil, ölçülebilir kriterler kullanmak gerekir: dışarıdan kaç farklı kaynaktan bağlantı alıyor, tarama botları son altı ayda kaç kez ziyaret etti, site içinde kaç sayfadan link alıyor? Sayılar belirsizlikleri ortadan kaldırır ve tartışmayı kişisel tercihten çıkarır.

Kararın ne zaman ters etki yarattığı da önemlidir. Mevcut URL yapısı içerik mimarisini doğru yansıtmıyorsa ve kullanıcılar hiyerarşiyi anlamlandıramıyorsa, koruma çabası yapısal hatayı da birlikte devralır. Yanlış bir yapıyı korumak, yanlış bir yapıyı yeniden inşa etmekle aynı sonucu verir. Geçici trafik düşüşüne rağmen bu durumlarda yeniden yapılandırma doğru karardır.

Teknoloji seçimi URL esnekliğini baştan kısıtlar

Teknoloji seçimi mimari kararların önünde gelir. Yeni platform seçilmeden önce mevcut URL şeması analiz edilmezse, seçilen sistemin URL oluşturma kuralları yapıyı baştan kısıtlayabilir. Bazı CMS sistemleri slug'u başlıktan otomatik üretir ve bu otomasyondan çıkmak ek geliştirme gerektirir. Bazı headless çözümler kategori-içerik ilişkisini düz yapıda tutar; iç içe geçmiş URL hiyerarşileri oluşturmak için özel rota mantığı yazmak gerekir.

Doğru sorular teknoloji değerlendirme aşamasında sorulmalıdır: Platform, mevcut URL şemasını aynen devralabilir mi? Kategori hiyerarşisi URL yoluna yansıtılabilir mi? Çok dilli yapı varsa dil önekleri nasıl oluşturulur? Statik sayfa ile dinamik sayfa URL yapısı aynı sistemde tutarlı davranır mı? Bu soruları geçiş sonrasına bırakmak, çözümü mimari değil teknik bir probleme dönüştürür; teknik çözümler ise çoğu zaman mimari bütünlüğü gözetmez.

Ters etki riski şu durumda belirginleşir: Teknoloji seçimi yapıldıktan sonra URL uyumluluğu için ekstra katmanlar eklenir, bu katmanlar zaman içinde bakım yükü yaratır, geçici çözümler kalıcılaşır ve sistem giderek kırılgan hale gelir. Seçim aşamasında URL gereksinimlerini teknik değerlendirme kriterlerine dahil etmek bu riski baştan önler.

Yönlendirme haritası pasif bir geçiş adımı değildir

301 yönlendirme listesi genellikle projenin sonunda, yayına alınmadan birkaç gün önce hazırlanır. Hangi eski URL'nin hangi yeni URL'ye yönleneceği bir elektronik tabloya girilir, geliştirici yapılandırma dosyasına ekler ve iş biter. Bu yaklaşım yönlendirme haritasını pasif bir kontrol adımı olarak konumlandırır; oysa o liste bir mimari belgedir.

Yönlendirme haritasını erken hazırlamak, tercihen içerik aktarımı başlamadan önce, üç şey yapar. Hangi URL'lerin varlığını sürdüreceğini ve hangilerin birleştirileceğini netleştirir; bu netlik içerik aktarımını yönlendirir. Hiyerarşi değişikliklerini görünür kılar; üst kategoriden alt sayfaya yönlendirme ya da tam tersi her ikisi de hiyerarşi bozulmasının işaretidir. Geçiş sürecinde alınan kararların kaydını tutar; kim ne zaman neyi neden değiştirdi sorusu aylarca sonra cevaplanabilir hale gelir.

Yönlendirme haritası ne zaman yetersiz kalır? URL sayısı birkaç bini aştığında ve eşleştirme elle yapıldığında eksiklikler kaçınılmazdır. Kategori sayfalarının URL'leri tamamlanmış, ürün ya da içerik sayfalarının bir kısmı gözden kaçmış; bu durumda bir grup sayfa yönlendirilmeden yayına çıkar. Bu sayfalar tarama botları için kopuk noktalara dönüşür ve crawl bütçesinin bir bölümünü gereksiz yere tüketir. Büyük aktarımlarda yönlendirme haritasını kaynak sistemden otomatik oluşturmak, elle hazırlanan tablolardan tutarlı biçimde daha az hata üretir.

İç linkler genellikle göç projesinin en az tartışılan parçasıdır. URL'ler korundu, içerikler aktarıldı, yönlendirmeler tanımlandı; ama iç linklerin nereye işaret ettiği sistematik olarak gözden geçirilmedi. Eski sistemde bir sayfa, beş farklı içerik sayfasından doğrudan link alıyorsa bu ilişki yeni sistemde de kurulmuş olmalıdır. Yönlendirme bu boşluğu doldurmaz; 301 yönlendirme bir zincir ekler, doğrudan bağlantı kurmaz.

İç link yapısının aktarımında kritik olan, bağlantının hedefini değil amacını korumaktır. Eski sistemde bir kategori sayfası, alt sayfalarına bağlantı vererek hiyerarşiyi iç link düzeyinde de yansıtıyordu. Yeni sistemde o kategori sayfası yeniden oluşturuldu ama alt sayfa linkleri içerik editörü tarafından girilmedi ya da farklı bir içerik seçildi. Sonuç: hiyerarşi URL'de var, iç link yapısında yok.

Bu tutarsızlık kısa vadede görünmez. Ama site hiyerarşisi tıklama derinliğiyle ölçüldüğünde ortaya çıkar: üst kategori sayfasından üç tıklama ötede olması beklenen bir içerik sayfası, iç link yoksa beş veya altı tıklamaya uzamış olabilir. Tıklama derinliği ile URL derinliği arasındaki bu fark, hem kullanıcı deneyimi hem de tarama botlarının siteyi nasıl yorumladığı üzerinde doğrudan etkilidir. Aktarım sürecinde iç link haritası çıkarmak, yalnızca URL envanteri tutmak kadar önceliklidir.

Site hiyerarşisi kaç seviyeye indirgenmeli?

Eski sistemlerde zaman içinde derinleşen bir hiyerarşi görülür. Ana kategori, alt kategori, alt-alt kategori ve içerik sayfası şeklinde dört ya da beş seviyeye ulaşmış yapılar yaygındır. Modernizasyon sırasında "bunu sadeleştirelim" kararı çekici gelir. İki veya üç seviyeye indirgemek, navigasyonu sadeleştirir ve crawl bütçesinin daha verimli dağılmasını sağlar. Ama bu karar her durumda işe yaramaz.

Hiyerarşiyi düzleştirmek ne zaman mantıklıdır? İçerik kategorileri gerçekten üst üste biniyorsa ve kullanıcılar üçüncü seviye kategorilere doğrudan arama yaparak gelmiyor, yalnızca gezinerek ulaşıyorsa, sadeleştirme hem kullanıcı hem de mimari açıdan değer yaratır. Ne zaman gereksizdir? İçerik kategorileri birbirinden net biçimde ayrışıyorsa ve her seviye kendine özgü arama sorgularını karşılıyorsa, düzleştirme bu sayfaların işlevini ortadan kaldırır. Ne zaman ters etki yaratır? Üçüncü seviye kategori sayfaları dışarıdan bağlantı alıyorsa ve belirli bir konu kümesinin odak sayfası olarak çalışıyorsa, bu sayfaları kaldırmak hem mevcut yapıyı hem de konu otoritesini zayıflatır.

Karar, soyut bir "kaç seviye ideal?" sorusuna değil, somut bir "bu seviyedeki sayfalar kendi başına değer üretiyor mu?" sorusuna dayanmalıdır. Evet yanıtı korumanın, hayır yanıtı birleştirmenin sinyalidir. Cevap net değilse, mevcut sayfanın ne kadar bağımsız arama trafiği çektiğine bakılır; bu sayı karar için yeterli bir göstergedir.

Geçiş sonrası doğrulama sadece hata kontrolü değildir

Yayına alındıktan sonra yapılan doğrulama çalışması çoğu zaman teknik hata kontrolüne indirgenir: 404 sayfaları var mı, yönlendirmeler çalışıyor mu, meta etiketler yerinde mi? Bunlar gerekli kontroller olmakla birlikte, mimari doğrulama farklı sorular sorar.

Hiyerarşi seviyelerine göre tıklama derinliği beklendiği gibi dağılıyor mu? Ana sayfadan en derin içerik sayfasına kaç tıklama gerekiyor? Bu sayı eski sistemdeki değerle karşılaştırıldığında ne görülür? İç link yoğunluğu kategori sayfalarında mı, içerik sayfalarında mı birikmiş? Üst kategori sayfaları alt sayfalarına yeteri kadar link veriyor mu? Tarama botları yeni URL yapısını sistematik biçimde dolaşıyor mu, yoksa bazı dallar keşfedilmemiş kalıyor mu?

Bu sorular teknik hataları değil, mimari sağlığı ölçer. Geçişten sonraki ilk aylarda bu soruları yanıtlamak için veri toplamak, altı ay sonra anlaşılması güç bir yapısal sorunla karşı karşıya kalmaktan çok daha az maliyetlidir. Doğrulama sürecini teknik kontrol listesinin ötesine taşımak, modernizasyon projesinin gerçek çıktısını ölçmenin yoludur.

Legacy site modernizasyonu, eski sistemi kapatıp yeni sistemi açmakla bitmez. Asıl çalışma, URL mimarisini koruyarak ya da bilinçli biçimde değiştirerek, iç link yapısını yeniden kurarak ve hiyerarşiyi güçlendirerek yürütülen bir geçiş sürecidir. Teknik seçimler bu çalışmayı kolaylaştırabilir ya da zorlaştırabilir; ama mimari kararları tekniğe bırakmak, genellikle uzun süre fark edilmeyen yapısal hasarlara yol açar.

Modernizasyon projelerinde en sık rastlanan örüntü şudur: geçiş teknik olarak başarıyla tamamlanır, sistem stabil çalışır, ama altı ila on iki ay içinde organik trafikte açıklanamayan bir düşüş yaşanır. Sebep aranırken içerik kalitesine, algoritma güncellemelerine ya da rakip hareketlerine bakılır. Gerçek neden ise çoğu zaman geçiş sırasında sessizce bozulan iç link ağı ya da yanlış düzleştirilen hiyerarşidir. Mimari kararlara baştan dikkat etmek, bu arama sürecini gereksiz kılar.