Edge A/B Testi SEO

TL;DR — Edge A/B testi, tarayıcıda veya kendi sunucunuzda değil, sitenizin önünde duran ağ olan CDN’nizde bir split test çalıştırmak demektir. Edge’deki küçük bir betik, her ziyaretçiye hangi sürümün gösterileceğine sayfa ona ulaşmadan önce karar verir. SEO açısından bu aslında iyi haber: Google bir JavaScript değişimi değil, gerçek HTML görür. Doğru yapılması gereken tek şey tutarlılıktır — Google’ın kullanıcılarınızdan farklı bir sürüm görmesine izin vermeyin ve testi sonsuza dek sürdürmeyin. Test etmek uygundur; Google’a kullanıcılardan farklı bir şey göstermek cloaking’dir ve kurallara aykırıdır.

Edge A/B testi nedir?

Edge A/B testi, her varyasyonu oluşturmak için origin uygulamasının her seferinde işleme yapmasını gerektirmek yerine, varyantları teslimat katmanında atar ve değiştirir. Evidence for this claim Cloudflare Workers can execute code and modify requests or responses at the network edge. Scope: Cloudflare Workers; other edge platforms have different runtimes and controls. Confidence: high · Verified: 2026-07-14 Cloudflare: Workers overview Google web sitesi testlerine izin verir; ancak cloaking’e karşı uyarır ve geçici, kontrollü deneyler önerir. Evidence for this claim Google permits website testing, warns against cloaking, and recommends appropriate canonicals or temporary redirects and limited test duration. Scope: Google Search guidance for website testing; it applies regardless of whether assignment occurs at the edge or origin. Confidence: high · Verified: 2026-07-14 Google: Website testing and Search

A/B testinde bazı ziyaretçilere sayfanın A sürümü, diğerlerine B sürümü gösterilir; böylece hangisinin daha iyi performans gösterdiğini ölçebilirsiniz. Edge A/B testinde ise hangi sürümün gösterileceğine ziyaretçinin tarayıcısında veya kendi web sunucunuzda değil, CDN’nizde (Cloudflare, Akamai, Fastly ya da edge’de çalışan Optimizely veya VWO gibi bir araçta) karar verilir.

Bir test üç yerde gerçekleştirilebilir ve SEO açısından aralarında büyük fark vardır:

1. İstemci tarafı — tarayıcıdaki JavaScript, sayfa yüklendikten sonra içeriği değiştirir. Kurulumu hızlıdır; ancak Google geç çalışan JavaScript’i her zaman beklemediği için değişikliği hiç görmeyebilir.
2. Origin sunucu tarafı — uygulama sunucunuz seçilen sürümü oluşturur ve gerçek HTML olarak gönderir.
3. Edge — CDN, istek sunucunuza ulaşmadan önce seçilen sürümü gerçek HTML olarak oluşturur veya yeniden yazar. SEO yararı sunucu tarafındakiyle aynıdır (Google gerçek HTML alır); üstelik daha hızlıdır ve kod dağıtımı gerektirmez.

Edge test için neden daha güvenli bir yerdir (SEO açısından)

En büyük kazanım şu: edge gerçek HTML gönderdiği için arama motorlarıyla kullanıcılar aynı tür sayfayı alır. Böylece Google’ın test edilen sürümü tamamen kaçırabildiği istemci tarafı testlerinin en büyük sorunu aşılmış olur.

Tek kural: Google’a kullanıcılardan farklı bir şey göstermeyin

Google A/B testlerini tamamen kabul eder — bunu kendi belgelerinde açıkça söyler. Kabul etmediği şey cloaking’dir: sıralamaları manipüle etmek için arama motorlarına gerçek kullanıcılara gösterdiğinizden farklı içerik sunmak. Güvenli bir edge testinde asıl mesele, Googlebot’un gerçek bir kullanıcının da alabileceği meşru ve tutarlı bir sayfa sürümünü görmesini sağlamaktır; özel bir “bot sürümü” değil.

Edge’de iki şey bu kuralı yanlışlıkla ihlal edebilir:

• Çerezler. Çoğu edge testi, ziyaretçiye atanan sürümü çerezle hatırlar. Googlebot genellikle çerezleri saklamaz; bu yüzden her ziyaretinde farklı bir sürüme rastgele yeniden atanabilir. Bu, sizin hile yapmaya çalıştığınız anlamına gelmez; yine de Google açısından dağınık görünebilir.
• İkinci bir URL’ye yönlendirmeler. Test ziyaretçileri biraz farklı bir URL’ye (örneğin ?variant=b) gönderirse Google bunu ayrı bir sayfa olarak değerlendirip her ikisini de dizine ekleyebilir.

İkisi de düzeltilebilir. Advanced sekmesinde bunun tam olarak nasıl yapılacağı, testin ne kadar süre güvenle çalıştırılabileceği ve “botlara normal sürümü ver” yaklaşımının akıllı bir kestirme mi yoksa bir tuzak mı olduğu anlatılıyor.

TL;DR — Edge A/B testi, varyant HTML’yi veya yönlendirmeleri origin isteği görmeden önce CDN worker katmanından sunar. Motorlar istemci tarafında yapılan bir JS değişimi yerine gerçek HTML aldığı için test için en güvenli yerdir; ancak edge’e özgü riskleri de vardır. İki deseni birbirinden ayırın: aynı URL’de HTML yeniden yazımı (risk: Googlebot genellikle çerez tutmaz; çerezle gruplama her taramada ona yeni, rastgele bir varyant gösterebilir) ve varyant URL’ye yönlendirme (risk: yinelenen içerik/canonical karmaşası). Çözümler: bot/çerezsiz trafiği deterministik hâle getirin, varyant URL’de kontrol URL’sini gösteren rel=canonical kullanın, test devam ederken 301 değil 302 kullanın ve kazananı bulur bulmaz testi kaldırın. Google’ın çizgisi “testing is fine, cloaking is not” — cloaking, “bir bot bir kez B varyantını gördü” meselesi değil, niyet ve asimetri meselesidir. Edge SEO’nun ne olduğunu burada yalnızca kısaca ele alıyorum — bu kümedeki genel edge SEO yazısı platform turunu ele alıyor; bu yazı teste özgü risklere odaklanıyor.

Edge’de test yapmanın gerçekten farklı olduğu noktalar

Bir edge worker, yanıtı ziyaretçiye yakın bir noktada yönlendirebilir veya dönüştürebilir; bu, atamanın nerede yapıldığını değiştirir, temel deney mantığını değil. Evidence for this claim Cloudflare Workers can execute code and modify requests or responses at the network edge. Scope: Cloudflare Workers; other edge platforms have different runtimes and controls. Confidence: high · Verified: 2026-07-14 Cloudflare: Workers overview Arama açısından güvenlik, arama tarayıcılarını önemli ölçüde farklı içerikle hedeflemekten değil, meşru test varyantlarını tutarlı biçimde sunmaktan geçer. Evidence for this claim Google permits website testing, warns against cloaking, and recommends appropriate canonicals or temporary redirects and limited test duration. Scope: Google Search guidance for website testing; it applies regardless of whether assignment occurs at the edge or origin. Confidence: high · Verified: 2026-07-14 Google: Website testing and Search

Edge A/B testi, edge SEO’nun bir kullanım alanıdır: gruplama ve HTML yeniden yazma işlemlerini (veya yönlendirmeyi), istek origin’e ulaşmadan önce bir CDN worker’ında — Cloudflare Workers, Akamai EdgeWorkers/EdgeKV, Fastly Compute ya da Optimizely ve VWO’nun edge/sunucu tarafı entegrasyonlarında — gerçekleştirirsiniz. SearchPilot edge SEO’yu “any SEO changes that are made after the HTML is created by your CMS or origin server before it is served to the user,” şeklinde tanımlar ve bizim için kritik noktayı şöyle belirtir: “They appear to all users and googlebot as server side HTML changes, so there are no risks or downsides from an indexation point of view.” Temel avantaj budur: edge, origin tarafındaki gibi gerçek HTML sunduğu için motorlar gerçek HTML alır; dolayısıyla test için güvenli bir yerdir.

Edge güvenliyse bu yazı neden var? Çünkü testin yapıldığı yer güvenlidir; SEO’ya özgü tuzaklar edge’de gruplamanın nasıl yapıldığında ortaya çıkar. Bunların ikisi neredeyse yalnızca bu desene özgüdür ve genel “A/B testi ve SEO” yazıları çoğu zaman ikisini de yüzeysel geçer.

Google’ın gerçek tutumu: test uygundur, cloaking değildir

Bunu açıkça söyleyelim; SEO testleriyle ilgili korkuların yarısı yersiz. Google A/B ve çok değişkenli testleri açıkça destekler ve bunlar için en iyi uygulamaları yayımlar. Çizdiği sınır cloaking’dir; spam politikası bunu “presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” diye tanımlar. Burada manipülasyon niyetine ve kullanıcılarla motorlar arasındaki asimetriye dikkat edin — “bir botun herhangi bir zamanda bir varyant görmüş olması” meselesine değil. Optimizely de kendi müşterilerine aynı şeyi şu şekilde aktarır: “Google encourages constructive testing and does not view the ethical use of testing tools such as Optimize to constitute cloaking.”

Google’ın test belgesinde verdiği pratik sınır son derece nettir: “Don’t show one set of URLs to Googlebot, and a different set to humans.” Edge testiniz bu kurala uyuyorsa — botlar da dahil olmak üzere herkes aynı meşru varyantlara erişebiliyor ve bunlar tutarlı biçimde sunuluyorsa — politikanın doğru tarafındasınız.

İki edge-test deseni (ve bunların farklı riskleri)

Bunları zihninizde birbirinden ayırın; çünkü farklı biçimde bozulur ve farklı biçimde düzeltilir.

Desen 1 — edge’de aynı URL’nin HTML’sini yeniden yazma

Worker URL’yi aynı tutar (/product/123) ve başlığı, CTA’yı ya da fiyat gösterim biçimini değiştirir; HTML Rewriter yanıtı akış sırasında yeniden yazar. Bu, Cloudflare Workers’ın “A/B testing with same-URL direct access” modelidir; belgelerinde yeni bir ziyaretçi için “Choose a group and set the cookie (50/50 split)” denir.

Edge’e özgü risk: çerezler. Google bunu doğrudan belirtir: “Googlebot generally doesn’t support cookies. This means it will only see the content version that’s accessible to users with browsers that don’t accept cookies.” Neredeyse tüm edge uygulamaları, geri dönen bir insan kullanıcının aynı grupta kalması için grubu çerezde saklar (Akamai’nin EdgeKV örneğinde de aynısı yapılır: “Client bucket selection will be persistent via a cookie value to ensure a client is locked to the same URL on subsequent visits”). Ancak Googlebot bu çereği taşımaz; dolayısıyla her taramada rastgele seçime yeniden girip önceki taramadan farklı bir gruba düşebilir. Bu aldatıcı cloaking değildir; ancak Google’ın aynı URL’nin zaman içinde değişken ve tutarsız bir sürümünü dizine ekleyebileceği anlamına gelir. Bu, klasik “botlara bilerek başka bir şey gösteriyoruz” sorununun daha ince, edge’e özgü kuzenidir ve bu yazının yazılma nedenini açıklayan en önemli noktadır.

Desen 2 — edge yönlendirmesiyle varyant URL’ye gitme

Burada worker, /product/123 adresine gelen isteği farklı bir URL’ye — /product/123?v=b veya /product/123-b — 302 ile yönlendirir. Artık motorların keşfedip bağımsız olarak dizine ekleyebileceği gerçekten farklı bir URL’niz vardır.

Edge’e özgü risk: yinelenen içerik ve canonical karmaşası. Google varyant URL’yi ayrı bir sayfa olarak dizine eklerse sinyalleri bölmüş ve muhtemelen yinelenen içerik oluşturmuş olursunuz.

Desen 1’i düzeltmek: arama tarayıcılarını deterministik hâle getirin

Çözüm “botu tespit edip testi gizlemek” değildir. Çözüm, çerezsiz isteklerin rastgele seçim yapmasına izin vermemektir. İnsanları çerezle gruplamakta serbestsiniz; ancak çerez içermeyen her istek için — Googlebot da buna dahildir — varyantı deterministik biçimde belirleyin: URL’yi hash’leyin, kararlı bir anahtara sabitleyin veya her seferinde kontrol sürümünü sunun. Amaç, çerezsiz her istemciye aynı URL için her zaman aynı varyantı vermektir; böylece Google yazı tura yerine her taramada tek ve sabit bir sayfa görür.

Cloudflare bunun için kullanılabilir bir mekanizma belgeliyor: “Enable Passthrough to allow direct access to control and test routes.” Passthrough, botların, QA ekiplerinin ve paydaşların her çerezsiz istekte yeniden rastgeleleştirilmek yerine /control/* veya /test/* yollarına tutarlı biçimde ulaşmasını sağlar. Bu, botlara özel bir kod yolu icat etmeden tarayıcılara tutarlı bir varyant sunmanın resmî olarak belgelenmiş aracıdır.

SearchPilot bu sorunu gruplamayı farklı bir düzeyde yaparak tamamen ortadan kaldırır: “When doing SEO A/B testing, there is only one version of the page. We are not showing different versions of the same page to users or Google. This isn’t cloaking and doesn’t create any duplicate versions of the same page.” Sayfaları deterministik biçimde böler (belirli bir sayfa herkese her zaman aynı varyantı gösterir); kullanıcıları rastgele bölmek yerine sayfaları böler. Bu, Cloudflare’ın çerezli 50/50 örneğindeki gruplama felsefesinin tersidir ve her ikisine de “edge A/B testi” denilse de SEO risk profilleri gerçekten farklıdır. Kendi ifadeleriyle: “There is only one Googlebot. You also can’t make two versions of a single page because it would cause problems like duplicate content.”

Desen 2’yi düzeltmek: canonical + yönlendirme disiplini

Test kendi URL’sinde çalışıyorsa Google’ın test belgesindeki üç kural doğrudan uygulanır:

• Varyantın canonical’ını kontrol URL’sine yönlendirin. Google: “you can use the rel=“canonical” link attribute on all of your alternate URLs to indicate that the original URL is the preferred version.” Her varyant URL’sinin canonical’ı kontrol URL’sini gösterir.
• Test sürerken 301 değil 302 kullanın. Google: “use a 302 (temporary) redirect, not a 301 (permanent) redirect.” 302, Google’a taşımanın geçici olduğunu ve orijinali dizinde tutması gerektiğini; 301 ise taşımanın kalıcı olduğunu bildirir. 301’i ancak kazananı seçip ona bağlandıktan sonra kullanın.
• Test bittiğinde kaldırın. Google: “Once you’ve concluded the test, update your site with the desired content variation(s) and remove all elements of the test as soon as possible… we may interpret this as an attempt to deceive search engines and take action accordingly.”

Canonical konusunda dürüst bir uyarı: bu bir talimat değil, ipucudur. Varyantın içeriği kontrol sürümünden büyük ölçüde farklıysa Google canonical’ı göz ardı edip her ikisini de dizine ekleyebilir — Desen 2’nin aynı URL’de yeniden yazımdan daha riskli olmasının nedeni tam olarak budur. Bu yüzden büyük yapısal değişiklikleri kullanıcı başına varyant URL’si yerine sayfa bölme olarak ele almak daha iyidir.

Crawl budget: çok değişkenli testlerde çarpan etkisi

Tek bir A/B testi, tarayıcının görebileceği bir ek durum oluşturur. Çok değişkenli test ise durumları çarpar: ikişer varyanta sahip üç bağımsız değişken, gruplamanız URL başına yapışkan ve deterministik değilse tarayıcının teorik olarak karşılaşabileceği sekiz farklı kombinasyona kadar üretir. Deterministik olmayan gruplama, tek bir URL’yi sürekli değişen durumlar kümesine dönüştürür; taranabilir her farklı durum crawl budget harcar. Bu bileşik permütasyon açısı, test ve SEO üzerine yazıların çoğunda neredeyse hiç ele alınmaz; deterministik ve yapışkan gruplamanın yalnızca cloaking açısından değil, tarama verimliliği açısından da neden önemli olduğunu açıklar. (CDN’ler ve crawl budget üzerine Google’ın 2024 tarihli “Crawling December” rehberi doğru arka plan okumasıdır; bu kümedeki genel edge SEO yazısı ona yönlendirir.)

”Botlara yalnızca kontrol varyantını sunmak” — kestirme mi, tuzak mı?

Bu konuda dikkatli olmak gerekir; tavsiyenin yarısı doğrudur. Arama tarayıcılarına kararlı bir kontrol sürümü sunmak, o sürüm gerçekten herhangi bir kullanıcının her zaman almasını isteyeceğiniz ve Google’ın dizine eklemesini uygun bulacağınız sürümse uygundur — hatta iyidir. Güvenlik tutarlılık ve meşruiyetten gelir; bot tespitinden değil.

“Bot yolu” gerçek kullanıcıların gördüğünden farklı bir gerçekliği arama motorlarına göstermek için özel olarak oluşturulduğu anda cloaking’e dönüşür — Google’ın kuralı kelimesi kelimesine şöyledir: “Don’t show one set of URLs to Googlebot, and a different set to humans.” Bu nedenle doğru çerçeve şudur: tarayıcılara, herhangi bir kullanıcının her zaman görmesinden memnun olacağınız aynı deterministik varyantı sunun; incelemeden kaçmak için botlara özel bir yol oluşturmayın. Botları “testten dışlamak” için UA bilgisine bakmak, yalnızca tek bir gerçek sürümü standartlaştırdığınız için güvenli olabilir; genel bir teknik olarak güvenli değildir.

Edge testini ne kadar süreyle çalıştırabilirsiniz?

Google bir gün sayısı vermez. Test öğelerini, siz hiç kazanan ilan etmeden “test” sessizce sitenin kalıcı durumuna dönüşecek kadar uzun süre yerinde bırakmaya karşı uyarır — bu, “remove all elements of the test as soon as possible” ifadesinde tekrar edilen noktadır. Google’dan John Mueller bu konuya değinmiştir: art arda yeni deneyler çalıştırmak sorun değildir; ancak tek bir testi süresiz çalıştırıp fiilî kalıcı sayfa hâline getirmek, bunun artık gerçek bir test olmadığı izlenimini vermeye başlar. (Buradaki Mueller açıklamaları, bir Google Webmaster Central Hangout’uyla ilgili sektör haberleri üzerinden aktarılmıştır; birinci taraf Google belgesine dayanmıyor, bu nedenle ifadeyi parafraz olarak değerlendirin.) Mueller ayrıca site göçü sırasında A/B testi çalıştırmanın Google’ın göçü temiz biçimde tanıması için ihtiyaç duyduğu yönlendirme sinyallerini bulanıklaştırdığını belirtmiştir; bu ikisini aynı anda yürütmekten kaçının.

Optimizely, Google’ın yaklaşımını müşterilerine aktarırken buna şu pratik kuralı ekler: “If you are running an experiment for an unnecessarily long time, Google may interpret this as an attempt to deceive search engines and take action accordingly.” Kazananı yayına almayla ilgili olarak da Optimizely, 301 yönlendirmesinin “a small loss of link equity (around 10%)” taşıdığını tahmin eder — bu Optimizely’nin verdiği bir rakam ve pratik kuraldır; Google tarafından doğrulanmış bir sayı değildir, dolayısıyla öyle değerlendirin.

Bing’in rehberi daha sınırlı — varsayılan olarak Google’ı izleyin

Bing’in Google’ınki kadar ayrıntılı bir edge/CDN A/B testi sayfası yok. Elinde bulunan genel cloaking standardı, içeriğin maddi açıdan eşdeğer olmasına dayanır: “as long as you make a good faith effort to return the same content to all visitors, with the only difference being the content is rendered on the server for bots and on the client for real users, this is acceptable and not considered cloaking” Ayrıca “for significant structural changes, we recommend hosting each version on separate URLs, or split URL testing,” der ve varyant URL’lerin hızlı görülmesi için IndexNow’u önerir. Bing’in standardı Google’ınkiyle uyumlu olduğundan, ihtiyatlı varsayılan olarak her iki motor için Google’ın canonical/302/süre kurallarını uygulayın.

Bu yazı burada nereye oturuyor?

Bu yazı, aynı kümedeki genel edge SEO makalesinin teste odaklanan tamamlayıcısıdır — platform turu (hangi worker’ların bulunduğu ve edge’de başka neler yapabileceğiniz) o makalenin konusudur; bu yazı yalnızca split-test risklerine odaklanır. Desen 2’deki canonical ve yinelenen içerik mekanikleri, canonicalization ve duplicate content üzerine derinlemesine incelemelerle aynı fikirlere dayanır; crawl-budget boyutu da sitedeki crawling ve crawl-budget içerikleriyle bağlantılıdır — bunların tümü sitenin başka yerlerindedir.

AI özeti

Advanced sürümünün kısa özeti:

• Edge A/B testi, varyant HTML’yi veya yönlendirmeleri origin’den önce sunmak üzere CDN worker katmanında (Cloudflare Workers, Akamai EdgeWorkers, Fastly Compute, Optimizely/VWO edge) split testleri çalıştırır. Motorlar gerçek HTML alır; bu nedenle test için güvenli bir yerdir — istemci tarafında JS değişimi yapan testlerden çok daha güvenlidir.
• Google’ın tutumu: test uygundur; cloaking değildir. Cloaking, manipülasyon niyeti ve kullanıcılarla botlar arasındaki asimetri ile tanımlanır; “bir botun B varyantını görmesiyle” değil.
• İki desen, iki risk. (1) Aynı URL’de HTML yeniden yazımı: Googlebot genellikle çerez tutmaz; çerezle gruplama her taramada onu farklı bir varyanta yeniden rastgele atayabilir → dizine eklenen içerik tutarsızlaşır. (2) Varyant URL’ye yönlendirme: yinelenen içerik/canonical karmaşası.
• Çözümler. Bot/çerezsiz trafiği deterministik hâle getirin (URL başına her zaman aynı varyant; Cloudflare’ın “passthrough” deseni bir modeldir). Her varyant URL’sinde kontrol URL’sine işaret eden rel=canonical kullanın. Test devam ederken 301 değil 302 kullanın. Kazananı bulur bulmaz testi kaldırın.
• Sayfa bölme ve kullanıcı bölme. SearchPilot tarzı deterministik sayfa bölme, çerez sorununu tamamen ortadan kaldırır; kullanıcı başına rastgele çerez gruplaması (Cloudflare/Akamai örnekleri) deterministik bir yedekleme gerektirir.
• Crawl budget, çok değişkenli testlerde bileşik etki gösterir — gruplama yapışkan ve URL başına deterministik değilse çok sayıda bağımsız değişken taranabilir durumların sayısını çarpar.
• “Botlara kontrol sürümünü sunmak”, ancak kontrol sürümü gerçekten dizine eklenmesini istediğiniz sürümse güvenlidir — güvenlik bot tespitinden değil, tutarlılık ve meşruiyetten gelir.
• Süre: sabit bir sınır yoktur; ancak testi kalıcı duruma dönüştürmeyin ve göç sırasında çalıştırmaktan kaçının. Bing rehberi daha sınırlıdır — varsayılan olarak Google’ın kurallarını alın.

Hangi edge-test desenini çalıştırıyorsunuz ve çözümünüz ne?

Edge-test SEO sorunlarının çoğu iki soruya dayanır: test URL’yi değiştiriyor mu ve tarayıcının alacağı varyant deterministik mi? Size uygulanacak çözümü bulmak için bu akışı izleyin.

Resmî belgeler

Arama motorları ve platform sağlayıcılarından birincil kaynak niteliğinde rehberler.

Google

• A/B testing best practices for search — bu yazının dayandığı canonical/302/süre/çerez rehberi.
• Spam policies — Cloaking — cloaking’in tanımı (manipülasyon niyeti + asimetri).

Bing / Microsoft

• A/B Test for Better Search Engine Performance with IndexNow and Microsoft Clarity — Bing’in (sınırlı) A/B testi notu; yapısal değişiklikler için ayrı URL’ler ve bunların görülmesi için IndexNow.
• bingbot Series: JavaScript, Dynamic Rendering, and Cloaking. Oh My! — Bing’in “iyi niyetli, maddi olarak eşdeğer içerik” cloaking standardı.

CDN / test platformu sağlayıcıları

• Cloudflare Workers — A/B testing with same-URL direct access — çerezli 50/50 örneği ve tutarlı varyant erişimi için “passthrough” deseni.
• Akamai — Building an A/B Test with EdgeWorkers and EdgeKV — edge’de çerezle kilitlenen gruplama (belgede SEO, bot veya tarayıcılarla ilgili hiçbir çerçeve yoktur).
• Optimizely — A/B Testing and Search Engine Optimization — Google’ın kurallarını kendi müşterilerine aktaran sağlayıcı rehberi.

Kaynaktan alıntılar

Google, Bing ve platform sağlayıcılarının kayda geçmiş ifadeleri. Her Google/Bing/Cloudflare bağlantısı, kaynak sayfadaki alıntı bölümüne doğrudan gider.

Google — A/B testi için en iyi uygulamalar

• “Don’t show one set of URLs to Googlebot, and a different set to humans.” Alıntıya git
• “Googlebot generally doesn’t support cookies. This means it will only see the content version that’s accessible to users with browsers that don’t accept cookies.” — edge testi için kilit alıntı. Alıntıya git
• “you can use the rel=“canonical” link attribute on all of your alternate URLs to indicate that the original URL is the preferred version.” Alıntıya git
• “use a 302 (temporary) redirect, not a 301 (permanent) redirect.” Alıntıya git
• “Once you’ve concluded the test, update your site with the desired content variation(s) and remove all elements of the test as soon as possible… we may interpret this as an attempt to deceive search engines and take action accordingly.” Alıntıya git

Google — cloaking (spam politikası)

• “Cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” Alıntıya git

Bing / Microsoft

• “as long as you make a good faith effort to return the same content to all visitors, with the only difference being the content is rendered on the server for bots and on the client for real users, this is acceptable and not considered cloaking.” Alıntıya git
• “If you’re creating significant structural changes, we recommend hosting each version on separate URLs, or split URL testing.” Alıntıya git

Cloudflare Workers — aynı URL örneği

• “Enable Passthrough to allow direct access to control and test routes.” — tarayıcılara, QA ekiplerine ve paydaşlara rastgele çerez seçimi yerine tutarlı bir varyant sunmanın belgelenmiş yolu. Alıntıya git

Akamai — EdgeKV örneği

• “Client bucket selection will be persistent via a cookie value to ensure a client is locked to the same URL on subsequent visits.” (Akamai’nin belgesi tamamen dönüşüm mühendisliğine odaklanır; SEO, bot veya tarayıcı bağlamı içermediğini belirtmek gerekir. SEO perspektifini sizin eklemeniz gerekir.)

Optimizely — müşterilerine yönelik sağlayıcı rehberi

• “Google encourages constructive testing and does not view the ethical use of testing tools such as Optimize to constitute cloaking.”
• “If Google determines that the variation of your page is substantially different from the original in scope and content, then they may construe this change as cloaking.” (Bunlar Optimizely’nin kendi müşterilerine, Google politikasına ilişkin yorumunu aktaran açıklamalarıdır; bağımsız bir otorite değil, sağlayıcı rehberi olarak değerlendirilmelidir. Sıkça alıntılanan “~10% link-equity loss on a 301” ifadesi de Google tarafından doğrulanmış bir rakam değil, Optimizely’nin pratik kuralıdır.)

SearchPilot — sayfa bölme yöntemi

• “When doing SEO A/B testing, there is only one version of the page. We are not showing different versions of the same page to users or Google. This isn’t cloaking and doesn’t create any duplicate versions of the same page.” (SearchPilot, kendi sayfa bölme yaklaşımını anlatan sunucu tarafı/edge test sağlayıcısıdır; burada rastgele çerez gruplamasına yöntemsel bir karşıtlık olarak alıntılanmıştır.)

Edge A/B testi SEO kontrol listesi

Dizine eklenmiş sayfalara dokunan bir edge testini yayına almadan önce şu kontrol listesini çalıştırın:

• Hangi deseni çalıştırdığınızı biliyorsunuz: aynı URL’de HTML yeniden yazımı veya varyant URL’ye yönlendirme.
• Çerezsiz istekler deterministiktir. Googlebot (genellikle çerez tutmaz) URL başına her zaman aynı varyanta çözülür; her seferinde yeni bir rastgele seçim yapılmaz.
• Bu bir varyant URL ise her varyantta kontrol URL’sini gösteren bir rel=canonical bulunur.
• Test sırasında yönlendirme 301 değil 302’dir. (301 yalnızca testten sonra kazanan için kullanılır.)
• Tarayıcıların gördüğü varyant, dizine eklemekten memnun olacağınız meşru ve temsili bir sürümdür; deneyi gizlemek için oluşturulmuş botlara özel bir yol değildir.
• İncelemeyi atlatmak için botlara gerçek kullanıcılardan farklı bir şey göstermek üzere UA tabanlı tespit yapmıyorsunuz.
• Çok değişkenli testte gruplama URL başına yapışkan/deterministiktir; taranabilir sayfa durumlarını çarpmaz.
• Tanımlı bir son vardır: kazananın seçileceği bir nokta ve tüm test iskeletini hızla kaldırma planı (test fiilî kalıcı sayfa olarak sürdürülmez).
• Test bir site göçüyle çakışmıyordur (yönlendirme sinyallerini bulanıklaştırır).
• CDN’in WAF / bot kuralları, test worker’ı çalışmadan önce Googlebot’u sessizce engellemiyor veya başka yöne yönlendirmiyor.
• URL Inspection / log’larda, Googlebot’un gerçekte hangi varyantı aldığını doğruladınız.

Zihinsel modeller

1. Test uygundur; cloaking değildir. Google A/B ve çok değişkenli testleri teşvik eder. Risk testin kendisi değil; botlara ve kullanıcılara (manipülasyon niyetiyle) farklı muamele etmek veya testi fiilî kalıcı site hâline gelene kadar sürdürmektir. Her kararı bu ilkeye dayandırın.

2. İki desen, iki çözüm.

• Aynı URL’de HTML yeniden yazımı → risk tutarsız taramalardır (çerez gruplaması + çerezleri görmeyen Googlebot). Çözüm: çerezsiz trafik için deterministik varyant.
• Varyant URL’ye yönlendirme → risk yinelenen içerik / canonical karmaşasıdır. Çözüm: kontrol URL’sine canonical + test sürerken 302.

3. Sizi güvende tutan bot tespiti değil, tutarlılık ve meşruiyettir. Tarayıcılara kararlı bir kontrol sürümü sunmak, bunu zaten dizine eklemek isteyeceğiniz meşru bir sürüm olduğu için uygundur. Güvenlik botu tespit etme eyleminden değil, tutarlılıktan gelir. İçeriği gizlemek için oluşturulmuş botlara özel bir yol cloaking’in tanımıdır.

4. Sayfa bölme ve kullanıcı bölme. Deterministik sayfa bölme (sayfa başına herkese aynı varyant) çerez sorununu tamamen ortadan kaldırır. Kullanıcı başına rastgele çerez gruplaması, tarayıcılar için deterministik bir geri dönüş gerektirir. Her ikisine de “edge A/B testing” denir; ancak risk profilleri çok farklıdır.

5. Taranabilir durum = crawl budget. Bir URL’nin taranabileceği her farklı durum bütçeden pay tüketir. Bir A/B testi bir durum ekler; gruplama URL başına yapışkan ve deterministik değilse çok değişkenli test bu durumları çarpar.

6. İstemci tarafı < origin sunucu tarafı ≈ edge (SEO görünürlüğü için). İstemci tarafı JS değişimleri arama motorları tarafından tamamen kaçırılabilir. Origin sunucu tarafı ve edge gerçek HTML sunar; edge bunu yalnızca daha hızlı ve origin’e ulaşmadan önce yapar, karşılığında yukarıdaki çerez ve yönlendirme tuzaklarını getirir.

Edge A/B testi — hızlı başvuru

İki desen

Test sırasında yönlendirme kuralları

“Botlara kontrol sürümünü sunmak” — güvenli mi?

• Güvenli: kontrol sürümü gerçekten temsili ve zaten dizine eklemek isteyeceğiniz sürümdür; önemli olan tutarlılıktır.
• Güvenli değil: kullanıcılardan farklı bir gerçekliği motorlara göstermek için oluşturulmuş botlara özel yol → cloaking.

Hızlı bilgiler

• Googlebot genellikle çerez tutmaz → yalnızca çerezle gruplama botlar için güvenilir değildir.
• Canonical bir ipucudur, talimat değil → büyük yapısal varyantların her iki URL’si de yine dizine eklenebilir.
• Sabit bir süre sınırı yoktur; ancak testi kalıcı duruma dönüştürmeyin ve göç sırasında çalıştırmayın.
• Bing için edge A/B testine ayrılmış özel bir sayfa yoktur — varsayılan olarak Google’ın kurallarını alın.
• Optimizely’nin ~10% link-equity loss on a 301 ifadesi bir sağlayıcı kuralıdır, Google’ın rakamı değildir.

Edge testleriyle ilgili mitler ve kaçınılacak hatalar

En sık karşılaşılan tuzaklar — düzeltilmeye değer, sık tekrarlanan mitlerin bazıları şunlar:

• “Test etmek doğası gereği risklidir / kurallara aykırıdır.” Hayır. Google yapıcı A/B ve çok değişkenli testleri teşvik eder. Risk test etme eyleminde değil, uygulamadadır.
• “Botları testten tamamen çıkarırsam güvendeyim.” Yalnızca kısmen doğru. Botlara kararlı bir kontrol sürümü sunmak, kontrol sürümü gerçekten zaten dizine eklemek isteyeceğiniz sürümse uygundur. “İncelemeyi atlatmak için bot tespiti” amacıyla kurulmuşsa, ders kitabındaki cloaking örneğine dönüşür — motorlara gerçek kullanıcıların gördüğünden farklı bir gerçeklik sunar.
• “Çerez gruplaması uygundur — reklam teknolojisi A/B testlerini hep böyle yapar.” SEO için değil. Googlebot genellikle çerez tutmadığından, insanlar için kurulmuş yalnızca çerez tabanlı mantık deterministik bir geri dönüş eklemezseniz tarayıcılarda öngörülemez davranır.
• “Test sırasında kazanana 301, 302 ile temelde aynıdır.” Hayır. 302 geçici olduğunu (orijinali dizine eklemeye devam et) söyler; 301 ise kalıcı olduğunu bildirir. 301’i yalnızca kazanana bağlandıktan sonra kullanın.
• “Canonical etiketi Google’ın varyant URL’yi dizine eklememesini garanti eder.” Hayır. Canonical bir ipucudur. İçerik büyük ölçüde farklıysa Google bunu yok sayıp ikisini de dizine ekleyebilir; büyük yapısal değişiklikler bu yüzden kullanıcı başına varyant URL’sinde değil, sayfa bölmede olmalıdır.
• “Edge, origin sunucu tarafı ve istemci tarafı test aynı SEO riskini taşır.” Hayır. İstemci tarafı JS değişimleri motorlarca tamamen kaçırılabilir; edge ve origin gerçek HTML sunar. Ayrıca edge’in yalnızca istemci tarafı testlerinde bulunmayan kendi riskleri (çerezleri görmeyen botlar, varyant URL yönlendirmeleri, CDN önbelleklemesi ve WAF etkileşimleri) vardır.
• “Aylarca çalışan edge testi ‘hâlâ test’ olduğu sürece uygundur.” Risklidir. Kazanan ilan edilmeden fiilî kalıcı sayfaya dönüşen test, Google’ın aldatma girişimi olarak yorumlanabileceği konusunda uyardığı durumdur. Testi sonuçlandırın, kazananı seçin ve iskeleti kaldırın.
• “CDN sağlayıcısının A/B test belgeleri SEO açısını kapsar.” Genellikle hayır — örneğin Akamai’nin resmî EdgeKV A/B örneğinde SEO, bot veya tarayıcı çerçevesi yoktur. SEO perspektifini siz getirirsiniz; platform belgelerinde bu perspektif bulunmaz.

Tarayıcının gerçekte aldığı varyantı görün

Buradaki amaç, Googlebot’un genel davranışına uygun olarak çerezsiz bir isteğin tutarlı bir varyanta çözülmesini sağlamaktır. Edge’in çerez yokken ne sunduğunu şöyle kontrol edebilirsiniz:

Çerezsiz istemciyle getirme (shell / curl)

# No cookie sent — this is closest to how Googlebot hits you.
# Run it a few times: the variant should be the SAME every time (deterministic),
# not a fresh 50/50 roll.
for i in 1 2 3; do
  curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
    https://example.com/product/123 | grep -o 'data-variant="[^"]*"'
done

# Show the response headers too — look for Set-Cookie (bucketing),
# Vary, and any redirect (302 good / 301 bad while testing).
curl -sI -A "Googlebot" https://example.com/product/123

Varyant URL’sine yönlendirmeyi ve durum kodunu görme (shell)

# -L follows redirects; -w prints the chain of status codes.
# A live test should show 302, never 301.
curl -sIL -o /dev/null \
  -w "%{http_code} -> %{redirect_url}\n" \
  https://example.com/product/123

Sunulan varyantı ve canonical’ı DevTools konsolunda kontrol etme (bookmarklet uyumlu)

Test edilen sayfada tarayıcı konsoluna yapıştırın — veya (javascript: + gövde) olarak kaydedip herhangi bir sayfayı tek tıklamayla kontrol edebileceğiniz bir bookmarklet oluşturun:

// What variant am I seeing, and does the page canonical to the control?
(() => {
  const variant = document.querySelector('[data-variant]')?.dataset.variant
    ?? 'no data-variant attr found';
  const canonical = document.querySelector('link[rel="canonical"]')?.href
    ?? 'no canonical';
  const hasCookie = /(?:^|; )ab_bucket=/.test(document.cookie);
  console.log({ url: location.href, variant, canonical, hasCookie });
})();

Deterministik gruplamayı doğrulama (edge log’larında regex)

Worker’ınız her istek için atanan grubu günlüğe kaydediyorsa, bu komut çerezsiz istekleri ve bunlara atanan grubu çekerek aynı URL’nin her zaman aynı varyanta eşlendiğini doğrulamanıza yardımcı olur:

# Match log lines with no ab_bucket cookie, capture URL + assigned variant.
# Group by URL: every URL should show ONE variant, not a mix.
grep -vE 'ab_bucket=' edge.log \
  | grep -oE '"(GET|HEAD) [^"]+".*variant=[AB]' \
  | sort | uniq -c | sort -rn

Çerezsiz isteklerde herhangi bir URL hem variant=A hem de variant=B olarak görünüyorsa gruplamanız tarayıcılar için deterministik değildir — Googlebot değişken bir hedefi dizine eklemeden önce bunu düzeltin.

Edge testlerini çalıştırma ve kontrol etme araçları

• Cloudflare Workers — aynı URL’de HTML Rewriter ile yeniden yazımlar ve tutarlı kontrol/test erişimi için belgelenmiş “passthrough” deseni.
• Akamai EdgeWorkers + EdgeKV — edge’de çerezle kilitlenmiş atamayla gruplama (SEO korumalarını siz eklemelisiniz; belgelerinde yok).
• Fastly Compute — aynı yeniden yazma/yönlendirme desenleri için edge compute.
• Optimizely / VWO (edge / sunucu tarafı entegrasyonları) — istemci tarafı yerine edge’de çalışabilen ticari deney platformları.
• SearchPilot — deterministik sayfa bölmeye dayalı sunucu tarafı/edge SEO A/B testi (herkese sayfa başına tek varyant); çerez sorununu ortadan kaldırır.
• Google Search Console — URL Inspection — Googlebot’un test edilen URL’yi nasıl tarayıp oluşturduğunu ve hangi varyantı gördüğünü kontrol edin.
• Sunucu log dosyası analizi — gerçek arama tarayıcılarının hangi varyantı ne sıklıkta aldığını ve çerezsiz isteklerin tutarlı biçimde sonuçlanıp sonuçlanmadığını gösteren temel gerçeklik kaynağı.
• curl / DevTools konsolu — çerezsiz varyantı, canonical’ı ve yönlendirme durumunu hızlıca elle kontrol etmek için (Scripts sekmesine bakın).
• IndexNow — URL bölmeli test yapıyorsanız varyant URL’lerinin hızlıca keşfedilmesini sağlamak için Bing/Yandex push protokolü (yapısal değişiklikler için Bing’in önerdiği yol).

Arama tarayıcılarında deterministiklik için edge gruplamasını denetleyin

Review this edge A/B test implementation. First classify it as:
A. Same-URL HTML rewriting, or
B. Redirect to a separate variant URL.

Then trace assignment for: a normal first visit, a returning visitor with a cookie,
Googlebot without a cookie across repeated crawls, and a request whose cache key is reused.
Return:
1. Every source of randomness or unstable assignment
2. Whether the same URL can show a crawler different indexable versions over time
3. Whether cache keys mix control and variant responses
4. For redirected variants, the redirect status and canonical relationship
5. User-agent branches that show bots content users cannot receive
6. A deterministic replacement and a repeat-request test plan
7. The cleanup required when the test ends

Do not assume crawlers retain cookies. Do not call a test safe merely because bots receive
the control; verify that control is genuinely available to users and is the intended
indexable version. Do not invent CDN settings or experiment data.

Worker/middleware code, routes, cache configuration, and test design:
[PASTE INPUT]

Önerilen bir varyant URL testini inceleyin

Check this edge redirect test for temporary-test hygiene. Verify that the variant URL
canonicalizes to the control, the redirect is temporary, internal links and sitemaps do
not multiply the test URLs, crawler assignment is stable, and an end date/winner-removal
plan exists. Return pass/fail per condition and the smallest safe correction.

Inputs:
[PASTE REDIRECT RULES, HEAD OUTPUT, CANONICALS, AND TEST WINDOW]

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• The Beginner’s Guide to Technical SEO — edge testinin aşmaması gereken cloaking sınırı da dâhil olmak üzere, test ve taranabilirliğin büyük resimdeki yeri.

Konuşmalarım

• How Search Works (SlideShare) — tarama, oluşturma, dizine ekleme ve sıralama süreçlerine ilişkin anlatımım; çerezleri görmeyen/çerezsiz taramanın neden böyle davrandığını anlamak için yararlı bir arka plan. (Sabit uyarım geçerlidir: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Sektörden

• A/B testing best practices for search (Google Search Central) — canonical, 302, süre ve çerezler/Googlebot satırı için yetkili kaynak.
• Cloudflare Workers — A/B testing with same-URL direct access — çerezli 50/50 örneği ve tutarlı erişim için “passthrough” deseni.
• Building an A/B Test with EdgeWorkers and EdgeKV (Akamai) — edge’de çerezle kilitlenen gruplama (belgede SEO çerçevesi yok).
• A/B Testing and Search Engine Optimization (Optimizely) — Google kurallarını aktaran sağlayıcı rehberi; 301’de yaklaşık %10 link equity kaybı kuralının kaynağı.
• What is SEO A/B testing? (SearchPilot) — sayfa bölme ve kullanıcı bölme yöntemleri ile “tek bir Googlebot vardır” gerekçesi.
• SEO and SEO testing on the edge (SearchPilot) — edge değişikliklerinin kullanıcılara ve Googlebot’a sunucu tarafı HTML olarak görünmesinin nedeni.
• A/B Test for Better Search Engine Performance with IndexNow and Microsoft Clarity (Bing Webmaster Blog) — Bing’in A/B test notu ve IndexNow rehberi.

Kendinizi test edin: Edge A/B testinde SEO

Edge’de SEO sorunlarına yol açmadan split test çalıştırma üzerine beş kısa soru. Her biri için bir yanıt seçin, ardından kontrol edin.

Değişiklik günlüğü