Bir site sahibi için düzgün açılırken arama tarayıcısı boş sayfa görebilir, klavye kullanan biri formu tamamlayamayabilir veya sertifikanın süresi dolmak üzere olabilir. Bunlar farklı sistemlerin sorunlarıdır; tek puan hepsini açıklayamaz.
Kesin bir soruyla başlayın: hedef müşterimiz sayfayı bulabiliyor, teklifi anlayabiliyor ve önemli işlemi güvenle tamamlayabiliyor mu? Tam denetim bu sorunun bazı bölümlerine kanıt sağlar. İş bağlamını yorumlamak ve yolculuğu baştan sona denemek yine insan değerlendirmesi gerektirir.
Bu denetimin kapsamı
Neler ölçülebilir
- Kullanılabilir güvenlik modülleri, sınırlı SEO ve AI içerik örneklemesi, herkese açık entegrasyon sinyalleri, statik erişilebilirlik ve seçilen cihaz için performans ölçümleri.
- Her motorun döndürdüğü hedef, ölçüm kapsamı ve kanıtlarla birlikte bulgular ve olumlu kontroller.
Neleri kanıtlamaz
- Otomatik sonuç kapsamlı penetrasyon testi, eksiksiz erişilebilirlik değerlendirmesi veya arama görünürlüğü garantisi değildir.
- Çalışmanın tamamlanması, bazı ölçümlerin kısmi veya kullanılamaz olmasını dışlamaz; kapsamı ayrıca okuyun.
Denetimler, güvenlik modülleri ve tarama hakları bağlı pakete ve kalan kullanıma göre değişir. Güncel fiyatlandırmayı kontrol edin; korumalı testler uygun hedef yetkilendirmesi de gerektirir.
1. Taramayı seçmeden önce soruyu belirleyin
Önemli sayfaları ve kullanıcı yolculuğunu tanımlayın. Abonelik sunan bir işletmede ürün açılış sayfası, fiyatlandırma, kayıt ve destek iyi bir başlangıçtır. Mağaza için kategori, ürün, sepet ve ödeme öncelikli olabilir. Tam alan adını, ortamı ve cihazı kaydedin.
Hedefin kime ait olduğunu ve hangi testlere izin verildiğini netleştirin. Herkese açık gözlem ile aktif güvenlik testi aynı etkiye sahip değildir. OWASP Web Security Testing Guide daha geniş bir test çerçevesi sunar; otomatik denetim bunun bir bölümünü kapsar. Hesap içi işlemleri ve veri değiştiren senaryoları ayrı, kontrollü bir incelemede ele alın.
2. Altı denetim alanını anlayın
| Alan | Yararlı soru | Kapsam sınırı |
|---|---|---|
| Güvenlik | Hangi açık ayarlar veya servisler araştırılmalı? | Seçilen modüller ve yetkilendirme kapsamı belirler. |
| SEO | Tarayıcı örneklenen içeriği bulup anlayabiliyor mu? | Sınırlı HTML taraması indekslemeyi kanıtlamaz. |
| AI görünürlüğü | İçerik açık, erişilebilir ve kaynağı belirli mi? | Hazırlık, canlı AI atıf ölçümü değildir. |
| Entegrasyonlar | Hangi herkese açık entegrasyon izleri var? | Betik bulunması olay teslimini kanıtlamaz. |
| Erişilebilirlik | Statik işaretlemede hangi engeller saptanabiliyor? | Klavye ve yardımcı teknoloji testleri gerekir. |
| Performans | Yüklemeyi veya etkileşimi ne geciktiriyor? | Laboratuvar ile saha verisi farklı soruları yanıtlar. |
Alanları birlikte değerlendirin. Üçüncü taraf bir bileşen performansı, erişilebilirliği ve veri toplamayı aynı anda etkileyebilir. Üç bağımsız iş açmak yerine ortak nedeni düzeltin.
3. Bulguları kanıt ve etkiye göre sıralayın
Aşağıdaki öncelikler örnek değerlendirmelerdir; motorun her durumda aynı kritiklik etiketini vereceği anlamına gelmez. Sorumlu atamadan önce etkilenen sayfayı, gözlenen değeri, beklenen davranışı ve yeniden üretme adımlarını kaydedin.
| Örnek gözlem | Bağlama göre öncelik | İstenecek kanıt |
|---|---|---|
| Açık sayfada gerçek gizli anahtar | Kullanılabiliyorsa kritik; hemen sınırlandırın | Maskelenmiş konum, yayılma kapsamı ve anahtar sahibi |
| Satış sayfasında yanlışlıkla noindex | Müşteri kazanımı için yüksek | Yanıt metaverisi ve indeksleme amacı |
| Zorunlu form alanında kullanılabilir etiket yok | Temel işlemi engelliyorsa yüksek | İşaretleme ve elle etkileşim testi |
| Kullanılmayan sosyal önizleme metaverisi | Düşük veya bilgi | İlgili paylaşım yüzeyi ve mevcut önizleme |
Kritiklik tek başına iş önceliği değildir. Her ödeme işlemindeki küçük sorun, kullanılmayan bir test sayfasındaki ağır görünen uyarıdan önce gelebilir.
4. Bulguyu uygulanabilir bir düzeltmeye çevirin
- Yeniden üretin: bildirilen cihaz veya tarayıcı koşullarıyla aynı URL ve yanıtı inceleyin.
- Kaynağı bulun: uygulama, barındırma, CDN ve üçüncü taraf davranışını ayırın.
- Tutarlı ve dar bir düzeltme yapın: aynı şablonu kullanan sayfalar da iyileşsin.
- Kabul koşulunu yazın: sorunun çözüldüğünü gösterecek gözlenebilir durumu belirtin.
- Sorumlu atayın: kişiyi, etkilenen sayfaları ve yayın zamanını ekleyin.
Varsayımsal boş fiyat sayfasında “SEO’yu iyileştir” ölçülebilir bir iş değildir. “Özel API yollarını korurken açık paket içeriğini render işlemine erişilebilir kıl; paket tablosunun göründüğünü doğrula” test edilebilir. Google JavaScript rehberi, ilk yanıt ile oluşturulan içeriğin neden farklılaşabileceğini açıklar.
5. Önce düzeltmeyi, sonra kullanıcı yolculuğunu test edin
İlk kontrolü karşılaştırılabilir koşullarda tekrarlayın ve yeni kanıtı eski sonucun yanına yazın. Masaüstü ana sayfa ile mobil ödeme testini karşılaştırıp farkı regresyon saymayın. Bir bağımlılık çalışmadıysa siteyi değerlendirmeden önce eksik ölçümü yeniden deneyin.
- İlgili URL kabul koşulunu karşılıyor mu?
- Aynı değişen şablondaki başka sayfa çalışıyor mu?
- Temel işlem klavye ve dar ekranda tamamlanabiliyor mu?
- Hata, doğrulama ve yüklenme durumları doğru mu?
- Kalan elle incelemeler ve bilinçli kapsam dışı alanlar kayıtlı mı?
W3C başlangıç erişilebilirlik kontrolleri elle test için iyi bir başlangıçtır. Temiz otomatik sonuç bu çalışmanın yerini tutmaz.
6. Rahatlatıcı ama yanıltıcı sonuçlardan kaçının
complete: true iş akışının tamamlandığını belirtir; her koşulun ölçüldüğü veya geçtiği anlamına gelmez. Kapsamı, kullanılamayan sağlayıcıları, atlanan modülleri ve örneklenen URL’leri okuyun. “Uygulanamaz” ile “geçti” farklıdır; alınamayan sayfa iyi yapılandırma kanıtı sunamaz.
Yalnız bileşik puanı yükseltmeye çalışmayın. Yararlı bir özelliği kaldırmak performans puanını artırırken ürünü bozabilir. Yapısal veri eklemek sıralama garantisi değildir; AI hazırlık puanı da asistanların sizi kaç kez kaynak gösterdiğini söylemez. Puanı önceliklendirme yardımcısı olarak kullanın ve değişikliği haklı kılan gözlemleri saklayın.
7. Tekrarlanabilir bir inceleme düzeni kurun
Önemli yayınlardan önce kritik şablonların başlangıç durumunu kaydedin. Barındırma, izin, gezinme, kimlik doğrulama veya şablon değişiminde ilgili denetimleri ve yolculukları tekrarlayın. Aynı hedef ve ayarlar, sonucun değişiklik hakkında anlamlı olmasını sağlar.
Devir notunda dört şey bulunsun: doğrulanmış kusurlar, doğrulanmış düzeltmeler, yapılamayan ölçümler ve elle takip. Teknik ölçümlerle birlikte başarılı müşteri işlemlerini izleyin. Web Vitals rehberi, deneyim metriklerini genel kalite puanından ayırmaya yardımcı olur.
İş açısından önemli tek bir açık sayfayla başlayın. Kapsamı okuyun, en etkili kanıtlı sorunu çözün ve kontrolü tekrarlayın. Asistan bağlantıları için MCP kurulum rehberini, güncel haklar için fiyatlandırmayı kullanın.
Sık sorulan sorular
Tam denetim bütün sayfaları test eder mi?
Hayır. Tarama sınırı, erişilebilir içerik, seçilen modüller, yetkilendirme ve sağlayıcı durumu gerçek kapsamı belirler. Sonuçtaki URL’leri ve kapsamı okuyun.
Yüksek toplam puan sitenin güvenli olduğunu kanıtlar mı?
Hayır. Puan yalnız ölçüm üreten kontrolleri özetler. Test edilmemiş açıkları, bozuk hesap içi yolculukları veya elle bulunabilen erişilebilirlik engellerini dışlayamaz.
Her bilgi seviyesi bulgu düzeltilmeli mi?
Şart değil. Önce gözlemin siteniz için bir kusur olup olmadığını belirleyin. Kabul edilen davranışı kaydedin; aynı uyarı önemli işlerden sürekli dikkat çalmasın.
Kaynaklar ve ileri okuma
- OWASP Web Güvenliği Test Rehberiowasp.org
- Google: JavaScript SEO temelleridevelopers.google.com
- W3C: başlangıç erişilebilirlik kontrolleriwww.w3.org
- web.dev: Web Vitalsweb.dev
Sitelemetry ekibi tarafından, ürünün denetim kapsamı ve bağlantılı birincil kaynaklarla karşılaştırılarak hazırlanmıştır. Açıkça belirtilen gözlemlenmiş vakalar dışında örnekler açıklama amaçlıdır.
