A/B testi, dönüşüm optimizasyonunun temel aracıdır; ancak test süreçleri fark edilmeden site mimarisini zedeleyebilir. Yeni URL'ler oluşur, kanonik sinyaller karışır, iç linkler birden fazla hedefe dağılır ve tarama bütçesi beklenmedik sayfalara akar. Test bittikten sonra bu izleri temizlemek, testi kurmaktan çok daha uzun sürebilir.

Mesele yalnızca teknik temizlik değil. Test süreci boyunca arama motorları siteyi taramaya devam eder ve hangi URL'nin otoriter olduğuna dair kararlar alır. Geçici varyant sayfaları uzun süre tarama önceliği alırsa, arama motorunun içerik hiyerarşisine dair çıkarımı yanlış yönde şekillenir ve bu durum test bittikten sonra da etkisini sürdürür.

Koruma önlemleri karmaşık araçlar gerektirmez. URL seçimi, kanonik yapılandırma ve iç link yönetimi üç temel adımı oluşturur; bu adımların her biri test kurulumu aşamasında alınabilir, sonradan düzeltmek yerine baştan doğru yapmak hem süreyi hem maliyeti azaltır.

A/B testi URL yapısını nasıl karmaşıklaştırır?

A/B testi genellikle üç biçimde uygulanır: aynı URL üzerinde JavaScript ile içerik değişimi, yeni bir varyant URL'si oluşturma veya geçici bir alt alan adı üzerinden servis etme. Her yöntemin URL mimarisine etkisi farklıdır ve bu farklılıklar test planlamasında çoğu zaman göz ardı edilir.

JavaScript tabanlı testlerde URL değişmez; tarayıcı aynı adreste farklı bir içerik görür. Arama motorunun gördüğü içerik ise tarama zamanına ve JavaScript işleme kapasitesine bağlıdır. Render edilmemiş HTML ile render sonrası içerik arasındaki fark, beklenmedik indeksleme kararlarına zemin hazırlar; özellikle test içeriği navigasyon veya başlık gibi kritik öğelere dokunuyorsa bu risk artar.

Varyant URL oluşturulduğunda tablo değişir. /urun ve /urun-v2 gibi iki URL varlığa dönüşür. İkisi de erişilebilirse arama motoru ikisini de tarayabilir, ikisini de dizine ekleyebilir ve link yetkisini ikisine bölebilir. Test birkaç hafta sürdüğünde bu ayrışma kalıcı iz bırakır.

Alt alan adı yaklaşımında farklı bir sorun ortaya çıkar. test.example.com gibi bir adres ayrı bir varlık olarak algılanır; orada biriken tarama sinyalleri ve bağlantı yetkisi ana alan adına taşınmaz. Test bittiğinde bu sinyaller boşa gider, üstelik temizlenmezse alt alan adı indeksli kalmaya devam eder.

Varyant sayfaları için kanonik etiket kararı

Kanonik etiket (canonical tag), arama motoruna hangi URL'nin otoriter kaynak olduğunu söyler. Varyant sayfasına orijinal URL'yi işaret eden bir kanonik eklemek, test süresince link yetkisinin bölünmesini önler. Yapı basittir: /urun-v2 sayfasının <head> bölümüne <link rel="canonical" href="/urun" /> eklenir.

Arama motoru varyant sayfayı taradığında kanonik sinyali görür ve otoriter URL'nin /urun olduğunu anlar. Link yetkisi orijinal sayfada birikmeye devam eder; varyant sayfasına dışarıdan bir bağlantı gelse bile kanonik sinyal bu yetkiyi orijinal URL'ye yönlendirir.

Kanonik tek başına yeterli değildir. Varyant URL'si iç linkler üzerinden güçlü biçimde destekleniyorsa kanonik sinyal zayıflayabilir. Arama motorları kanonik etiketi bir yönlendirme değil, bir öneri olarak ele alır; iç link yapısıyla tutarlılık sağlanmadan kanonik koymuş olmak yeterli değildir. İki sinyalin aynı yönü göstermesi gerekir.

Yanlış yönlendirilmiş kanonik zarar da verir. Orijinal sayfaya yanlışlıkla varyant URL'sini işaret eden kanonik eklenirse link yetkisi tersine akar. Test kurulumunu canlıya almadan önce her iki sayfanın kanonik değerini doğrulayın; hata küçük görünür ama test süresince birikerek büyür.

İç linkler, site içi yetki dağılımının ve hiyerarşik sinyalin taşındığı kanallardır. Test sırasında orijinal sayfaya işaret eden linklerin varyant URL'sine kaydırılması, otoriter sinyali orijinal sayfadan uzaklaştırır ve test bittiğinde geri dönüşü zorlaştırır.

Süresi kısa bir test için bu kayma önemsizdir. Uzun süreli testlerde ise, özellikle navigasyon menüsü veya ana sayfadan çıkan iç link varyant URL'sine yönlendirilmişse sorun büyür. Navigasyon linkleri sitedeki her sayfada tekrar eder; bu tekrar yetki akışına kümülatif katkı sağlar ve yanlış hedefe yönlenince bu katkı da yanlış yere akar.

Öneri nettir: iç linkleri orijinal URL'ye yönlendirmeyi sürdürün. Varyant sayfasının kullanıcıya sunulması JavaScript veya sunucu taraflı mantıkla yönetilebilir; HTML içindeki href değeri hep orijinal URL'yi işaret etmeli. Kullanıcı varyantı görür, arama motoru orijinal URL'yi güçlendirmeye devam eder.

Ekmek kırıntısı (breadcrumb) linkleri de bu kapsamda ele alınmalıdır. Kategori sayfasından ürün sayfasına, ana sayfadan kategoriye uzanan breadcrumb zinciri test sırasında değiştirilmemeli; değiştirilirse zincirin tüm katmanlarında yetki akışı sekteye uğrar ve hiyerarşi sinyali bozulur.

Crawl bütçesi ve tarama önceliği

Tarama bütçesi (crawl budget), arama motorlarının belirli bir süre içinde bir siteyi kaç sayfa tarayacağını ifade eder. Küçük siteler için bu bütçe genellikle sorun değildir. Binin üzerinde sayfası olan, sık güncellenen yapılarda varyant URL'lerinin eklenmesi tarama kaynaklarını geçici içeriklere yönlendirir ve orijinal sayfaların güncelleme sinyali geç gelebilir.

Varyant URL'lerini robots.txt ile taramadan dışlamak bir seçenektir. Arama motoru sayfayı görmez, indekslemez, otoriter karar vermez. Kanonik etiketle birlikte robots.txt engellemesi hem güvenli hem sade bir yapı kurar; ancak bu iki sinyalin birlikte çalışması gerekir, birinin eksikliği diğerinin işini zorlaştırır.

Tarama engellemesi tek başına indekslemeyi durdurmaz. Başka bir sayfadan link alan, kanonik etiketi olmayan bir URL, robots.txt engeline rağmen indekslenebilir; arama motoru URL'nin varlığını bağlantı üzerinden öğrenir ve linki takip etmeden sayfayı bilinen adres olarak kaydeder. Engelleme ve kanonik birlikte uygulanmadığında bu boşluk açık kalır.

Varyant sayfalarını site haritasından (sitemap) dışlamak da tarama yönetiminin bir parçasıdır. Sitemap, arama motoruna neyin öncelikli taranacağını söyleyen bir sinyal listesidir; geçici varyant URL'leri bu listeye girmemeli. Kanonik, robots.txt ve sitemap üçü birlikte tutarlı davranırsa tarama bütçesi gerçek içeriklere akar.

Test bitişinde mimari temizliği

Test bitti. Kazanan varyant belirlendi. Şimdi ne yapılacak? Geçici URL'lerin temizlenmesi bu aşamanın temel işidir ve çoğu zaman aceleyle geçilir; yanlış yapılan temizlik yeni sorunlar doğurur.

Varyant URL'si silinecekse önce bu URL'ye işaret eden iç linkleri güncelleyin. Silinmiş bir URL'ye kalan iç linkler 404 hataları üretir ve link yetkisini boşluğa gönderir. Silme işleminden önce iç link denetimi yapın, tüm dahili referanslar temizlendikten sonra sayfayı kaldırın; aksi hâlde 404 hataları sessizce birikir.

Varyant URL kazanan olduysa iki seçenek vardır: birincisi, eski URL'den 301 yönlendirmesiyle varyant URL'ye geçilir; ikincisi, orijinal URL içeriği güncellenir, varyant URL'si kaldırılır ve 301 ile orijinal URL'ye yönlendirilir. İkinci yol daha temiz bir mimari bırakır çünkü URL yapısı değişmez, hiyerarşideki konum korunur ve tarama motoru için tanıdık bir adres sürer.

301 yönlendirme kullanılacaksa zincire dikkat edin. Art arda yapılan testlerde her seferinde yeni yönlendirmeler eklenirse zincir uzar ve her ek atlama yetki aktarımını azaltır. Her test sonrasında temizliği tamamlamak, bir sonraki testin sağlıklı bir mimari üzerinde başlamasını sağlar.

Mimariye zarar vermeden test kurmak

En temiz yaklaşım, yeni URL oluşturmayan test yöntemleridir. Sunucu taraflı (server-side) testlerde kullanıcı segmentasyonu sunucuda yapılır ve her segment için farklı HTML üretilir. Arama motoru tarama yaptığında tek bir URL, tek bir içerik görür; URL yapısı değişmez, kanonik sinyal sorun çıkarmaz, iç link hedefleri sabit kalır.

Segmentasyon çerezi veya istek başlığı arama motoru botuna uygulanmadığı sürece sunucu taraflı test mimari açısından şeffaftır. Bot her zaman aynı içeriği görür ve hiyerarşi sinyali tutarlı kalır. Uzun süreli testlerde bile orijinal URL'nin tarama geçmişi kesintisiz birikir.

İstemci taraflı JavaScript testlerinde render gecikmesi göz önünde tutulmalıdır. Arama motoru JavaScript işlenmeden önce sayfayı taramaya başlarsa, test uygulanmamış sürümü görür. Navigasyon, başlık veya URL yapısına dokunan değişiklikler JavaScript ile yönetilirse bu belirsizlik kalır; bu tür testler için sunucu taraflı yöntem daha güvenlidir.

Çok sayıda varyant aynı anda canlıya alındığında, yani üçten fazla varyant URL oluşturulduğunda tarama bütçesi etkisi belirginleşir. Her varyant URL için ek bir tarama döngüsü harcanır ve test süresi uzadıkça döngüler birikir. Kademeli varyant yönetimi tercih edilmeli; bir varyant kapatılmadan yenisi açılmamalı. Her ek URL hem tarama hem indeksleme yükü getirir ve bu yük gerçek sayfalara gidebilecek kaynağı tüketir.

Test kurulumu için bir kontrol listesi tutmak tekrarlayan hataları önler. Kontrol listesi şu dört soruyu kapsar: yeni URL açılıyor mu, açılıyorsa kanonik ve robots.txt hazır mı; iç link hedefleri orijinal URL'de mi kalıyor; varyant sitemap'e girdi mi; test bitişinde hangi adımlar izlenecek? Bu dört soru baştan yanıtlanırsa test süreci boyunca mimari izleme yükü azalır.

A/B testi ile mimari koruma birbiriyle çelişmez. Test süreci doğru yapılandırıldığında sona erdiğinde mimari tam olarak başladığı noktada kalır; kanonik karışıklık, yetim URL, tarama israfı kalmaz ve kazanan varyant temiz bir yapının üzerine oturur.

Belirleyici olan test kurulumu aşamasındaki üç karardır: yeni URL açılıp açılmayacağı, kanonik etiketin nereye işaret edeceği ve iç link hedeflerinin değiştirilip değiştirilmeyeceği. Bu üç sorunun yanıtı önceden netleştirilirse test boyunca mimari izleme yükü de azalır ve test bitişindeki temizlik tahmin edilebilir bir sürece dönüşür.

Geçici bir sayfa kalıcı iz bırakabilir. Varyant sayfaları haftalarca indekslenmiş, iç linklerle desteklenmiş, crawl bütçesinden pay almışsa test bittikten sonra temizlemek için harcanan efor testi tasarlamak için harcanan eforu aşabilir. Test planlaması URL kararıyla başlarsa bu maliyet önceden sıfırlanır.