Teknik SEO Kontrol Listesi 2026: Tarama ve Site Mimarisi

Bir kurumsal web sitesi yenileme projesinde ilk toplantıda karar verilen şey şuydu: yeni site, eski sitenin organik trafiğinin altına düşmeyecek. Müşteri tarafı bu maddeyi sözleşmeye koymak istedi, biz de kabul ettik. Sorun şu ki proje kapsamı önce sadece tasarım ve içerik yönetim sistemi değişikliğiydi; teknik SEO ayrı bir iş kalemi olarak bile yazılmamıştı.

Kısıt nettir: bütçe sabit, takvim sekiz hafta, ekip tasarıma odaklanmak istiyor. Teknik SEO'yu sonradan eklemek yerine mimari kararların içine gömmeye karar verdik. Bu yazı o kararların hangilerinin işe yaradığını, hangilerinin bedelini sonradan ödediğimizi anlatıyor.

Tarama bütçesini proje başında konuştuk, sonda değil

Tarama bütçesi, arama motoru botlarının bir sitede belirli bir zaman diliminde gezebileceği sayfa sayısının pratik sınırıdır. Küçük bir kurumsal site için bu konu genelde önemsiz sayılır, ama sitede ürün kataloğu, filtre parametreleri ve çok dilli yapı varsa binlerce gereksiz URL ortaya çıkabilir.

Biz bu projede filtre kombinasyonlarının (renk, beden, fiyat aralığı) ayrı URL'ler üretip üretmeyeceğini ilk haftada netleştirdik. Karar şuydu: filtreler query string ile çalışacak, robots.txt üzerinden belirli parametre desenleri taramadan hariç tutulacak. Bu kararı sona bırakmış olsaydık geliştirme ekibi filtre mantığını baştan yazmak zorunda kalırdı.

Kontrol ettiğimiz üç nokta

Birinci nokta robots.txt dosyasının gerçekten istenen dizinleri engelleyip engellemediğiydi; test ortamında canlıymış gibi davranıp davranmadığını ayrıca kontrol ettik. İkinci nokta XML sitemap'in yalnızca indekslenmesi istenen URL'leri içermesiydi, çünkü sitemap'e girip de noindex etiketi taşıyan sayfa bırakmak kendi içinde çelişki yaratıyor. Üçüncü ve en değerli kontrol, sunucu log kayıtlarının proje ortasında bir kez incelenmesiydi; botların gerçekten hangi sayfalara gittiğini bu sayede gördük.

Log analizi burada en çok işe yarayan adımdı. Botların ürün detay sayfalarına değil, filtre sonucu üretilen boş kategori sayfalarına zaman harcadığını gördük ve bu sayfaları canonical etiketiyle ana kategoriye yönlendirdik.

İndeksleme hataları canlıya çıkışta değil, ikinci haftada ortaya çıktı

Site yayına alındığında indeksleme tarafında görünürde bir sorun yoktu. Google Search Console'da indekslenen sayfa sayısı makul görünüyordu. Asıl sorun ikinci haftada, yeni CMS'in otomatik ürettiği etiket sayfalarının (tag pages) binlerce ince içerikli URL olarak indekse girmeye başlamasıyla çıktı.

Burada yaptığımız hata şuydu: canonical etiketlerini şablon seviyesinde değil sayfa seviyesinde ayarlamıştık. Yeni bir etiket sayfası oluştuğunda canonical otomatik olarak kendi URL'ine işaret ediyordu, oysa bu sayfaların çoğunun ana kategori sayfasına canonical vermesi gerekiyordu. Düzeltme üç gün sürdü, ama indeksten temizlenme süreci üç haftaya yayıldı çünkü Google'ın yeniden tarayıp canonical değişikliğini işlemesi zaman alıyor.

Bugün aynı projeyi yapsak, canonical mantığını şablon seviyesinde, içerik tipine göre otomatik kural olarak baştan yazardık. Sayfa sayfa müdahale etmek ölçek büyüdüğünde sürdürülebilir değil.

Site mimarisi kararı: derinlik mi, genişlik mi

Bu soru projede en çok tartıştığımız konuydu. Mevcut site ürünleri dört seviye derinlikte tutuyordu: ana sayfa, kategori, alt kategori, ürün. Yeni mimaride bunu üç seviyeye indirip tüm ürünlere ana kategoriden en fazla iki tıklamayla ulaşılmasını sağladık.

Bu kararın bedeli, kategori sayfalarının daha kalabalık hale gelmesiydi; bir kategori sayfasında filtrelerle gezinme zorunluluğu arttı. Kazancı ise iç link dağılımının daha az sayfaya, daha güçlü şekilde yoğunlaşmasıydı. Derin mimaride link değeri (link equity, bir sayfanın aldığı iç ve dış bağlantılardan kazandığı değer) dört seviyeye yayılıp her katmanda zayıflıyordu.

Mimari değişikliğinde kontrol ettiklerimiz

Eski URL yapısından yeni yapıya 301 yönlendirme haritasını eksiksiz çıkarmak ilk işimizdi; bu projede 1.200'ün üzerinde URL için tek tek eşleşme listesi hazırlandı. Breadcrumb (sayfanın site içindeki konumunu gösteren gezinme izi) yapısının yeni hiyerarşiyle tutarlı kalması ve şema işaretlemesiyle eşleşmesi ayrı bir kontrol maddesiydi. Son olarak iç linklerin, özellikle blog yazılarından ürün sayfalarına verilen linklerin, yeni URL'lere güncellenmesi gerekiyordu.

301 yönlendirme haritasını hazırlamak tahmin ettiğimizden fazla sürdü, çünkü eski sitede bazı ürünler birden fazla kategoriye aynı anda bağlıydı ve her biri farklı bir URL üretiyordu. Bu karmaşayı yeni mimaride tek bir kanonik URL'e indirmek hem geliştirme hem içerik ekibinin ortak kararıydı.

Mobil render ve JavaScript taraması gözden kaçan ikinci problem oldu

Yeni ön yüz bir JavaScript çerçevesi üzerine kuruldu ve içerik büyük ölçüde istemci tarafında (kullanıcının tarayıcısında) render ediliyordu. Google'ın modern botları JavaScript'i işleyebiliyor, ama bu işlem her zaman anında ve hatasız olmuyor; render kuyruğunda gecikme olabiliyor.

Search Console'daki URL denetleme aracıyla birkaç kritik sayfayı kontrol ettiğimizde, botun gördüğü render edilmiş HTML ile kullanıcının gördüğü sayfa arasında fark olduğunu fark ettik. Ürün açıklamaları bazı sayfalarda geç yükleniyor, bot bu içeriği göremeden tarama tamamlanıyordu.

Çözüm olarak kritik içerik (ürün adı, açıklama, fiyat) için sunucu tarafı render (server-side rendering) kullandık, ikincil içerikleri (yorumlar, önerilen ürünler) istemci tarafında bıraktık. Bu projelerde biz bu tip hibrit render kararlarını web tasarım ve geliştirme sürecinin bir parçası olarak en baştan planlamayı tercih ediyoruz. Sonradan eklemek, mimariyi kısmen yeniden yazmak anlamına geliyor.

Yapısal veri ve sayfa hızı ayrı iki konu olarak ele alındı

Şema işaretlemesi (structured data, arama motorlarına sayfa içeriğinin anlamını açıklayan kod) ürün, breadcrumb ve organizasyon tipleri için eklendi. Burada dikkat ettiğimiz nokta, şemada beyan edilen bilginin sayfada görünen bilgiyle birebir örtüşmesiydi; fiyat veya stok durumu şemada bir, sayfada başka görünürse bu tutarsızlık güven sorunu yaratıyor.

Sayfa hızı tarafında ise görsel optimizasyonu ve font yükleme stratejisi öncelik oldu. Büyük ürün görselleri için modern format dönüşümü ve tembel yükleme (lazy loading, ekranda görünmeyen içeriğin kullanıcı o kısma gelene kadar yüklenmemesi) uyguladık. Bu iki konuyu ayrı ele almamızın sebebi ikisinin de farklı ekipleri ilgilendirmesiydi: yapısal veri içerik ve geliştirme ekibinin, hız optimizasyonu ise tamamen geliştirme ekibinin sorumluluğundaydı.

Projenin tamamında teknik SEO'yu ayrı bir faz değil, mimari kararların bir parçası olarak ele almak toplam süreyi kısalttı ama ilk planlamayı zorlaştırdı. Benzer kapsamdaki projelerde teknik gereksinimleri tasarım onayından önce netleştirmek, şu an standart hale getirdiğimiz bir pratik. Benzer ölçekteki çalışmaları portfolyomuzda inceleyebilirsiniz.

Sitenizde benzer bir yenileme veya teknik SEO denetimi planlıyorsanız, mevcut mimarinizi ve tarama verinizi birlikte değerlendirip size özel bir yol haritası çıkarabiliriz. Proje detaylarınızı paylaşarak teklif alabilirsiniz.