Bir web projesi başlangıcında herkes "önemli kararlar" aldığını düşünür. URL yapısı nasıl olacak, kategori hiyerarşisi kaç seviyeye inecek, hangi sayfalar indekslenecek, iç linkler nasıl planlanacak. Çoğu zaman bu kararlar sözlü mutabakat, yarım kalmış bir taslak belge ya da proje yöneticisinin belleğinde yaşar. Proje yayına girdiğinde ise yapısal sorunlar görünür olmaya başlar: URL'ler tutarsız, navigasyon karmaşık, bazı sayfalar iç linkten yoksun, bazı kategori sayfaları arama motorlarına yanlış sinyal gönderiyor.

Yapısal kontrol listesi bu sorunların hiçbirini kendi başına çözmez. Kararları sizin yerinize vermez, mimariyi otomatik olarak düzenlemez. Ama yapısal boşlukları görünür kılar ve proje boyunca hangi kararın henüz alınmadığını ya da alındı sanılıp uygulanmadığını ortaya çıkarır. Bu işlev küçük görünür; pratikte büyük bir fark yaratır.

Yapısal kontrol, proje yaşam döngüsünün üç farklı noktasında iş görür: planlama aşamasında karar rehberi, yayın öncesinde doğrulama aracı, yayın sonrasında ise denetim çerçevesi. Bu üçü aynı liste olmamalıdır. Her aşamanın farklı soruları, farklı sorumlulukları ve farklı öncelikleri vardır. Üçünü tek bir belgeye sıkıştırmak, her birini işlevsiz kılar.

Aşağıdaki bölümler, yapısal kontrol listesinin temel alanlarını ele alır. Her alan kendi içinde bağımsız bir karar kümesidir; ancak hepsi birlikte projenin yapısal bütünlüğünü oluşturur. Sıralama bir öncelik hiyerarşisi değil, proje akışındaki doğal ilerleyiştir.

Yapısal kontrol listesi, projenin her aşamasında farklı bir işlev görür

Planlama aşamasındaki kontrol listesi soru listesidir. Hangi sayfa tipleri gerekiyor, URL kalıpları nasıl olacak, navigasyonun kaç seviyesi olacak, hangi içerikler indekslenecek. Bu aşamada cevap verilmemiş sorular ilerleyen süreçte birer borç haline gelir. Bir soru erken sorulduğunda yanıtı ucuz ve esnektir; yayın sonrası aynı soru yanıtlanmak zorunda kalındığında yeniden yapılandırma gerektirebilir.

Yayın öncesi kontrol listesi doğrulama aracıdır. Planlama aşamasında alınan kararların uygulanıp uygulanmadığını, uygulama sırasında ortaya çıkan istisnaların kayıt altına alınıp alınmadığını kontrol eder. Bu noktada yapısal boşluklar henüz düzeltilebilir durumdadır. Yayın sonrasına bırakılan her düzeltme daha maliyetlidir: 301 yönlendirme planları, içerik migrasyonları, iç link revizyonları.

Yayın sonrası kontrol listesi ise süregelen bir denetim çerçevesidir. Sitenin büyüme biçimi, kontrol noktalarını değiştirir. Aylık on sayfa yayımlayan bir blog, yılda birkaç kez kapsamlı yapısal denetim yapmasa bile sürüklenmeye başlar. Kullanılmayan kategoriler birikmesi, tutarsız URL kalıplarının çoğalması bunun ilk belirtileridir. Denetim listesi bu sinyalleri erken yakalar.

Üç listeyi birbirinden ayrı tutmak pratik bir tercih değil, yapısal bir zorunluluktur. Planlama listesindeki bir soru yayın öncesinde anlamsız hale gelmiş olabilir; yayın sonrası denetimde ise bambaşka sorular öne çıkmış olabilir. Bunları ayrı belgeler olarak yönetmek, her birinin kendi bağlamında işlev görmesini sağlar.

URL ve klasörleme kararları baştan verilmezse sonradan düzeltmek maliyetlidir

URL yapısı, bir web projesinin en erken kilitlenmesi gereken kararlarından biridir. Yayın sonrası URL değişikliği 301 yönlendirme planı gerektirir; bu plan doğru kurulmadığında bağlantı değeri ve arama motoru sinyalleri zarar görür. Dolayısıyla URL kararları planlama listesinin en başına yerleşmelidir.

Kontrol listesinde URL için yanıtlanması gereken temel sorular şunlardır: Her sayfa tipi için URL kalıbı belirlendi mi? Blog yazıları, kategori sayfaları, ürün sayfaları, statik sayfalar ayrı ayrı ele alındı mı? URL yapısı hiyerarşik mi, düz mı, karma mı? Bu tercih bilinçli mi yoksa rastlantısal mı? Özel karakterler, Türkçe harfler, tarih damgaları nasıl ele alınıyor?

Klasörleme kararları da benzer bir titizlik gerektirir. /blog/kategori-adi/yazi-basligi/ yapısı mı, /yazi-basligi/ düz yapısı mı, /kategori-adi/yazi-basligi/ ara düzey mi? Her seçeneğin farklı bir yapısal mantığı ve farklı bir büyüme maliyeti vardır. Kontrol listesi bu kararın alındığını ve uygulandığını doğrulamalıdır — mevcut URL'lerin ayrıca örnek olarak belgelenmesiyle birlikte.

Yayın öncesi aşamada ise URL tutarlılığı elle kontrol edilmelidir. Otomatik araçlar kalıp hatalarını yakalayabilir; ama mantıksal tutarsızlıkları — örneğin bazı blog yazılarının farklı bir hiyerarşide oluşturulmuş olmasını — çoğunlukla kaçırır. Bu kontrol, birkaç saatlik bir incelemeyle önlenebilecek aylık bakım maliyetini engeller.

Navigasyon yapısı kontrol listesinin en çok atlanan bölümüdür

Projelerde navigasyon çoğunlukla tasarım sürecinin son aşamalarında şekillenir. Sayfa içerikleri oturmuş, görsel kimlik netleşmiş, geliştirme ortamı kurulmuştur. Navigasyon ise bu noktada "ne eklenecek?" sorusuyla değil, "ne gösterilmeli?" sorusuyla ele alınır. Bu gecikmeli yaklaşım navigasyonu estetik bir karar haline getirir; oysa navigasyon öncelikle yapısal bir karardır.

Kontrol listesinde navigasyon için sorulması gereken sorular birkaç katmanda düşünülmelidir. Ana menü: kaç öğe var, hangi sayfa tiplerine işaret ediyor, hiyerarşi var mı, mobilede nasıl çalışıyor? Footer menü: ana menüyle çakışma var mı, yalnızca yasal sayfaları mı kapsıyor, yardımcı bağlantılar var mı? Navigasyon menüsü bu üç katmanın birbirleriyle tutarlılığını gerektirir. Birinin güncellenmesi diğerini etkiliyorsa bu bağımlılık belgelenmeli, kontrol listesine yansıtılmalıdır.

Breadcrumb katmanı ayrıca ele alınmalıdır. Breadcrumb yalnızca bir yol göstergesi değil, aynı zamanda yapısal hiyerarşinin kullanıcıya yansımasıdır. Breadcrumb'ın hangi sayfa tiplerinde göründüğü, URL yapısıyla uyumlu olup olmadığı ve şema işaretlemesinin eklenip eklenmediği kontrol listesinde yer almalıdır.

Yayın öncesi aşamada navigasyon kontrolü masaüstü ve mobil olarak ayrı yapılmalıdır. Masaüstünde mantıklı görünen bir yedi öğeli menü, mobilede kullanılamaz hale gelebilir. Kontrol bu iki bağlamda bağımsız değerlendirme gerektirir.

İç linkleme planı sayfalar yayına girmeden önce çizilmelidir

İç linkleme çoğu projede reaktif biçimde yönetilir: bir sayfa yayıma girince, editör diğer yazıları tarar ve mantıklı gördüğü yerlere link ekler. Bu yaklaşım işe yarar — ama yapısal değildir. Bağlantı ağı zamanla merkezi sayfalara aşırı yığılırken bazı sayfalar hiçbir iç linkten yararlanamaz hale gelir.

Yapısal kontrol listesinde iç linkleme için sorulması gereken birkaç temel soru vardır. Her sayfa tipi için minimum ve maksimum iç link sayısı belirlenmiş mi? Hub sayfalar tanımlanmış mı? İç linkleme için hub sayfa yöntemi, bağlantı değerini merkezi sayfalara yönlendirmenin en sistematik yoludur; bu yöntemin uygulanması planlama aşamasında kararlaştırılmalıdır. Hangi sayfaların birbirine link verdiği bir matris ya da basit bir liste olarak belgelenmiş mi?

Yayın öncesi kontrol, her yeni sayfa için en az üç iç linkin doğrulanmasını içermelidir: sayfanın aldığı en az bir iç link (gelen), sayfanın verdiği en az iki iç link (giden) ve bu linklerin anchor metinlerinin doğal ve açıklayıcı olması. Bu üç kontrol noktası, iç link ağının eşit büyüme yerine yapısal mantıkla büyümesini sağlar.

Yayın sonrası denetimde ise bağlantısız sayfaların tespit edilmesi önceliklidir. Hiçbir iç linkten yararlanamayan sayfalar, arama motorları için erişilmesi güç içerikler olarak kalır. Bu tespit, içerik denetimi araçlarıyla düzenli aralıklarla yapılabilir.

Sayfa tipi kararları yapısal tutarlılığı doğrudan etkiler

Bir proje büyüdükçe kaç farklı sayfa tipi ortaya çıktığı genellikle fark edilmez. Başlangıçta üç beş sayfa tipiyle açılan bir site, zamanla on beşe, yirmiye ulaşabilir. Her yeni sayfa tipi kendi URL kalıbını, kendi navigasyon davranışını, kendi şema işaretlemesini ve kendi iç linkleme mantığını gerektirir. Bu kararlar alınmadan oluşturulan sayfalar, yapısal tutarsızlık biriktirir.

Kontrol listesinde sayfa tipleri için yanıtlanması gereken sorular şunlardır: Sitenin kaç farklı sayfa tipi var? Her sayfa tipi için şablon belgelenmiş mi? Bilgi mimarisi perspektifinden değerlendirildiğinde, sayfa tiplerinin her birinin farklı kullanıcı amacına hizmet etmesi gerekir; iki sayfa tipi aynı amacı kapsıyorsa biri gereksizdir. Hangi sayfa tiplerinin indeksleneceği, hangilerinin noindex alacağı kararlaştırıldı mı?

Yayın öncesi aşamada her sayfa tipi için en az bir örnek sayfanın çapraz kontrolü yapılmalıdır. Bu kontrol şunları içermelidir: başlık etiketi ve meta açıklama formatı doğru mu, şema işaretlemesi eklenmiş ve geçerli mi, canonical URL doğru gösteriyor mu, Open Graph etiketleri tam mı? Bu dört nokta her sayfa tipi için tekrarlanabilir biçimde belgelenmişse, yeni sayfalar aynı kalite düzeyinde çıkmaya devam eder.

Pratikte en çok atlanan kontrol, yeni oluşturulan sayfa tiplerinin var olan şablonlara göre değerlendirilip değerlendirilmediğidir. Bir sayfa "farklı görünüyor" diye yeni bir tip olarak tanımlanabilir; oysa aslında mevcut bir tipin varyasyonudur. Kontrol listesi bu ayrımı sormak için bir fırsat sunar.

Mobil uyumluluk kontrolü teknik değil yapısal bir değerlendirmedir

Mobil uyumluluk çoğunlukla teknik bir kontrol olarak ele alınır: sayfa hızlı mı yükleniyor, görseller uygun boyutlarda mı, font okunabilir mi. Bunların hepsi geçerli kontrol noktalarıdır. Ama yapısal kontrol listesinin ilgilendiği mobil sorunlar farklıdır: navigasyon öğelerinin sayısı mobil ekranda yönetilebilir mi, breadcrumb zinciri kısa ekranlarda anlamlı mı, sayfa hiyerarşisi küçük ekranda da okunabilir mi?

Menü öğeleri yapısal bir kısıttır. Masaüstünde sekiz öğeli bir ana menü görsel olarak çalışabilir; mobilin dokunmatik yüzeyi ve dar ekranı bu sayıyı sorunlu kılar. Mobil menü bu kısıta göre tasarlandığında, ana menüden farklı bir hiyerarşi ve farklı bir önceliklendirme gerektirebilir. Kontrol listesi bu soruyu menü tasarımı sürecinde sormalıdır: bu menü, mobil kısıta göre mi tasarlandı, yoksa masaüstü için tasarlanıp mobileiçin mi uyarlandı?

Breadcrumb uzunluğu da mobilede yapısal bir sorun olabilir. Üç seviyeli bir hiyerarşi masaüstünde okunabilir; mobilin tek sıralı breadcrumb gösterimi bu derinliği kaldırmayabilir. Kontrol listesi, breadcrumb'ın kaç seviyeye kadar gösterileceğini ve bu sınırın nerede kesildiğini belgelemelidir.

Yayın öncesi mobil kontrolün yapısal boyutu şu soruyu içerir: Kullanıcı mobilden ana navigasyona, kategori sayfasına ve içerik sayfasına erişmek istediğinde kaç tıklama gerekiyor? Bu sayı masaüstüyle karşılaştırıldığında nasıl? Yapısal kontrol, bu sorunun yanıtını belgeleyerek kabul edilebilir bir eşik tanımlamalıdır.

Kontrol listesi işlevini ancak düzenli gözden geçirmeyle korur

Bir kontrol listesi oluşturulup bir kez kullanıldıktan sonra çekmeceye kaldırılırsa, iki yıl sonra aynı listeyi açıp kullanmak mümkün olmayabilir. Site büyümüş, yeni sayfa tipleri eklenmiş, navigasyon yeniden düzenlenmiş, bazı URL kalıpları değişmiş olabilir. Kontrol listesi ise eski kararları doğrulamaya devam eder; bu çelişki fark edilmeden bir süre devam edebilir.

Site haritası planlaması gibi kontrol listesi de yaşayan bir belgedir. Sitenin büyüme biçimi değiştikçe kontrol noktaları da güncellenmeli, kullanılmayan maddeler çıkarılmalı, yeni yapısal kararlar eklenmelidir. Pratikte bu güncellemeyi yapmak için doğal bir an vardır: her büyük içerik bloğunun yayıma girmesi ya da her navigasyon revizyonu. Bu anlar değerlendirilmezse kontrol listesi kısa sürede güvenilirliğini yitirir.

Kontrol listesinin ne sıklıkla gözden geçirileceği, sitenin büyüme hızına bağlıdır. Hızlı büyüyen bir blog için üç ayda bir, daha yavaş ölçeklenen kurumsal bir site için altı ayda bir yeterli olabilir. Önemli olan gözden geçirme sıklığından çok, gözden geçirmenin gerçekten yapısal sorular sormasıdır: eski kararlar hâlâ geçerli mi, yeni yapısal borç birikti mi, bir sonraki büyüme adımı bu kararlardan hangisini değiştirecek?

Yapısal kontrol listesi mükemmel bir proje garantisi değildir. Her projenin kendi bağlamı, kısıtları ve istisnaları vardır. Ama sistematik biçimde uygulanan bir liste, yapısal sorunların rastlantısal keşfedilmesini önler. Sorun erken görünür hale geldiğinde çözme maliyeti düşer, kararlar baskı altında değil düşünceli biçimde alınır. Bu fark küçük değildir.