Google Analytics ve Üçüncü Parti Script Çakışması Hataları Yüzünden Rastgele Bozulan Web Uygulamaları

WordPress’te Üçüncü Parti Script Çakışması: Gerçek Bir Hata Analizi

Web projelerinde teşhisi en zor sorunlardan biri, sürekli tekrarlanmayan hatalardır. Bir işlem birkaç kez sorunsuz çalışırken daha sonra aynı kullanıcıda veya aynı sayfada başarısız olabilir.

Bu yazıda, bir WordPress sitesinde hem Bookly rezervasyon sistemi hem de İngilizce seviye tespit sınavı formunda karşılaştığım gerçek bir vakayı anlatıyorum. Sorunu araştırırken tarayıcı konsolu, Network kayıtları, güvenlik katmanları ve sayfada çalışan üçüncü taraf scriptleri birlikte inceledim.

Yaptığım izolasyon testlerinde Google Analytics, Google Ads ve diğer üçüncü taraf izleme kodlarının devre dışı bırakıldığı durumda sorun tekrarlanmadı. Ancak bu vaka, bu servislerin genel olarak form sistemlerini bozduğu anlamına gelmez. Burada anlattığım sonuç yalnızca incelediğim sistemde yaptığım testlere dayanmaktadır.

Karşılaştığım Hata Mesajı

We faced problems while connecting to the server or receiving data from the server. Please wait for a few seconds and try again.

If the problem persists, then check your internet connectivity. If all other sites open fine, then please contact the administrator of this website with the following information.

TextStatus: abort
HTTP Error: undefined

Sorunun Ortak Belirtileri

Rezervasyon formu ile seviye tespit sınavında benzer belirtiler ortaya çıkıyordu:

• Form bazen çalışıyor, bazen gönderim aşamasında tamamlanmıyordu.
• Yükleme göstergesi ekranda kalabiliyordu.
• Uygulama tarafında problemi doğrudan açıklayan belirgin bir hata kaydı göremiyordum.
• Tarayıcı konsolunda her seferinde açık bir JavaScript hatası oluşmuyordu.
• Bazı ağ isteklerinde abort sonucu görülüyordu.
• İnceleme sırasında HTTP Error: undefined ve bazı isteklerde 499 yanıtlarıyla karşılaştım.

Bu belirtiler nedeniyle yalnızca WordPress/PHP tarafına odaklanmak yerine tarayıcıdaki ağ trafiğini, güvenlik katmanlarını ve üçüncü taraf kaynakları birlikte incelemeye başladım.

Tarayıcı Kayıtlarında Ne Gördüm?

İnceleme sırasında karşılaştığım kayıtlar arasında şunlar bulunuyordu:

• Failed to load resource: 499 (Request has been forbidden by antivirus)
• Refused to execute script because its MIME type is image/png
• TextStatus: abort
• HTTP Error: undefined

Bu kayıtların hepsini tek bir kök nedene bağlamak doğru olmaz. Örneğin MIME type uyarısı yanlış içerik türüyle sunulan bir kaynağa işaret ederken, Request has been forbidden by antivirus mesajı istemci tarafındaki bir güvenlik katmanının ilgili isteğe müdahale etmiş olabileceğini gösteriyordu.

TextStatus: abort ise ilgili AJAX isteğinin tamamlanmadan iptal edildiğini gösteren önemli bir ipucuydu. Ancak yalnızca bu kayıt, isteğin neden iptal edildiğini tek başına kanıtlamıyordu.

Neden İki Farklı Formda Benzer Sorun Görüldü?

Bookly rezervasyon sistemi ile seviye tespit formu farklı işlevlere sahip olsa da her ikisi de kullanıcı etkileşimi sonrasında tarayıcı ile sunucu arasında veri alışverişi gerçekleştiriyordu.

Bu nedenle ortak sayfa bileşenleri, güvenlik yazılımları, tarayıcı eklentileri, optimizasyon işlemleri veya üçüncü taraf scriptleri iki sistemi de etkileyebilecek ortak değişkenler arasındaydı.

Buradaki önemli ders, aynı anda iki farklı eklentide benzer hata görüldüğünde iki eklentinin de ayrı ayrı bozuk olduğunu varsaymak yerine ortak bağımlılıkları ve sayfa ortamını araştırmak oldu.

Üçüncü Parti Scriptleri Neden Test Ettim?

Sayfada form sistemlerinin dışında çeşitli ölçüm ve analiz kodları da çalışıyordu. İnceleme sırasında kontrol ettiğim bileşenler arasında:

• Google Analytics,
• Google Ads ölçüm/dönüşüm kodları,
• Microsoft Clarity

gibi üçüncü taraf kaynaklar bulunuyordu.

Bu servislerin kendilerinin hatalı olduğunu varsaymadım. Sorunun kaynağını daraltabilmek için sayfadaki dış bağımlılıkları kontrollü biçimde devre dışı bırakarak karşılaştırmalı test yaptım.

Üçüncü taraf scriptlerin davranışı; kullanıcı izinleri, tarayıcı gizlilik ayarları, reklam/izleme engelleyiciler, istemci güvenlik yazılımları, ağ koşulları ve yapılandırmaya göre değişebilir. Bu nedenle aynı hata her kullanıcıda veya her testte tekrarlanmayabilir.

Sorunu Nasıl İzole Ettim?

Burada benim için en faydalı yöntem, aynı anda birçok ayarı değiştirmek yerine değişkenleri kontrollü biçimde azaltmak oldu.

1. Hatanın oluştuğu senaryoyu tekrar etmeye çalıştım.
2. Tarayıcının Console ve Network kayıtlarını inceledim.
3. Sayfadaki üçüncü taraf scriptleri ve ortak bileşenleri listeledim.
4. Test ortamında üçüncü taraf kodlarını kontrollü biçimde devre dışı bıraktım.
5. Formları aynı senaryolarla tekrar tekrar test ettim.
6. Google Analytics ve Google Ads dahil bazı ölçüm kodlarının bulunmadığı testlerde sorunun tekrarlanmadığını gözlemledim.
7. Ardından gerekli scriptleri kontrollü biçimde yeniden devreye aldım ve sistemi tekrar test ettim.

Bu testler, incelediğim vakada üçüncü taraf scriptlerin veya bunlara müdahale eden istemci/güvenlik katmanlarının araştırılması gereken önemli değişkenler olduğunu gösterdi.

Ancak elimdeki kayıtlar Google Analytics, Google Ads veya Microsoft Clarity’nin tek başına doğrudan kök neden olduğunu kanıtlamadığı için bunu genel bir sonuç olarak sunmuyorum.

Güvenlik Katmanı Neden Önemliydi?

Özellikle şu kayıt dikkat çekiciydi:

Request has been forbidden by antivirus

Bu nedenle hata analizinde yalnızca WordPress eklentilerine değil, istemci tarafındaki güvenlik yazılımlarına ve tarayıcı ortamına da bakmak gerekiyordu.

Burada önemli bir güvenlik notu var: antivirüs, güvenlik duvarı veya WordPress güvenlik eklentilerini sırf test amacıyla kontrolsüz biçimde kapatmayı önermiyorum. Böyle bir bileşenin etkisinden şüpheleniliyorsa mümkünse güvenli bir test ortamında, ilgili loglar ve izin/engelleme kayıtları üzerinden inceleme yapılmalıdır.

Benzer Sorunlarda Kullandığım Kontrol Listesi

Bir form bazen çalışıyor, bazen başarısız oluyorsa şu sırayla ilerlemek benim için daha sağlıklı:

1. Problemin tekrar üretilebildiği senaryoyu belirlemek.
2. WordPress/PHP loglarıyla birlikte tarayıcı Console kayıtlarını kontrol etmek.
3. Network sekmesinde başarısız, iptal edilmiş veya engellenmiş istekleri incelemek.
4. Aynı sayfada çalışan üçüncü taraf scriptleri listelemek.
5. Tarayıcı eklentileri, reklam engelleyiciler ve istemci güvenlik yazılımlarının etkisini değerlendirmek.
6. Test ortamında değişkenleri tek tek izole etmek.
7. WordPress eklentileri, tema ve ilgili bileşenlerin sürümlerini kontrol etmek.
8. Her değişiklikten sonra aynı test senaryosunu tekrar uygulamak.

Temel prensibim: Ölçüm ve reklam kodları, rezervasyon veya form gibi sitenin temel işlevlerinin çalışmasını engellememelidir. Böyle bir çakışma görülüyorsa ölçüm altyapısını uygulamanın temel işlevinden bağımsızlaştıracak yapı araştırılmalıdır.

Sıkça Sorulan Sorular

Sonuç

Bu vakadan çıkardığım en önemli sonuç, aralıklı çalışan web hatalarında yalnızca uygulamanın kendisine odaklanmamak gerektiği oldu.

Form veya AJAX işlemi bazen çalışıyor bazen başarısız oluyorsa; backend kayıtlarının yanında tarayıcı Network trafiği, üçüncü taraf scriptler, güvenlik katmanları ve istemci ortamı da birlikte incelenmeli.

Bu vakada üçüncü taraf ölçüm kodlarını izole ettiğim testlerde sorun tekrarlanmadı. Ancak mevcut kayıtlar belirli bir servisin tek başına kök neden olduğunu kesin olarak kanıtlamadığı için sonucu bu sınırlar içinde değerlendiriyorum.

Gerçek teknik vaka analizlerimde temel yaklaşımım aynı: önce gözlemle, sonra değişkenleri izole et, sonucu tekrar test ederek doğrula.

Tunçer ŞEN