Teknik denetim: ölçülmüş bir bulgu listesi

Sitenin bugünkü halini ölçüyoruz. Her bulgunun yanında nasıl ölçüldüğü ve ne yapılacağı yazıyor; "iyileştirilmeli" diyen bir rapor vermiyoruz.

Bu sayfa şu soruya cevap veriyorSitemde ne bozuk olduğunu önce bir öğrenmek istiyorum.

Denetim neyi çıkarır

Denetim bir görüş yazısı değil, bir ölçüm tutanağı. Sonunda elinizde kalan şey, her satırında şunlar yazan bir liste oluyor: hangi adres, ne sorun, hangi araçla ve hangi ayarla ölçüldü, ölçülen değer ne, eşik ne, ne yapılacak. Bu biçimin bir amacı var: aynı ölçümü üçüncü bir taraf tekrarlayıp doğrulayabilsin.

Bulgular gerekçeyle atlanmıyor. "Bu zaten böyle olmaz" ya da "bunun etkisi azdır" diyerek kapatılan maddeler, birikince sitenin genel durumunu belirleyen şey oluyor. Kapatılamayan bir madde varsa neden kapatılamadığı ve ne zaman kapatılacağı yazılıyor; listeden silinmiyor.

Core Web Vitals: üç sayı, üç ayrı sorun

Google'ın kullanıcı deneyimi için ölçtüğü üç metrik farklı şeylere bakıyor ve farklı çözümler gerektiriyor:

  • LCP (en büyük içeriğin görünme süresi). Sayfanın ana görselinin ya da başlığının ne zaman okunabilir hale geldiğini ölçüyor; iyi kabul edilen eşik 2,5 saniye. Yüksek çıkmasının en sık nedeni boyutlandırılmamış hero görseli ve sayfayı bloklayan dış kaynaklar.
  • INP (etkileşim yanıt süresi). Kullanıcı bir şeye dokunduğunda sayfanın ne kadar hızlı karşılık verdiğini ölçüyor; eşik 200 milisaniye. Sorunun kaynağı genellikle ana iş parçacığını uzun süre meşgul eden JavaScript.
  • CLS (düzen kayması). Yüklenme sırasında içeriğin yerinden kaymasını ölçüyor; eşik 0,1. Neredeyse her zaman aynı iki sebepten: ölçüsü verilmemiş görseller ve sonradan gelip içeriği aşağı iten reklam ya da duyuru alanları.

Denetimde bu üçü hem laboratuvar ölçümüyle hem gerçek kullanıcı verisiyle ele alınır. İkisinin ayrışması da bir bulgu: laboratuvar iyi, gerçek kullanıcı kötüyse sorun genellikle belirli bir cihaz ya da bağlantı grubunda.

Erişilebilirlik: sıfır ihlal ölçülebilir bir hedef

Erişilebilirlik denetimini axe-core ile, WCAG 2.1 A ve AA kural kümelerinin tamamını çalıştırarak yapıyoruz. Ölçüm tek sayfada ve tek genişlikte değil; her sayfa türünde ve hem mobil hem masaüstü genişlikte tekrarlanıyor, çünkü ihlallerin bir kısmı yalnızca belirli genişlikte ortaya çıkıyor.

En sık bulduğumuz ihlaller şunlar: küçük metinde yetersiz renk kontrastı (marka renginin açık zeminde yazı rengi olarak kullanılması), etiketi alanına bağlanmamış form alanları, görünmeyen klavye odak halkası, aynı sayfada tekrarlanan id değerleri, sıralaması atlayan başlık düzeyleri ve hiçbir bölgeye ait olmayan yüzen düğmeler.

Bunların hiçbiri "engelli kullanıcı için ekstra özen" kategorisinde değil. Etiketsiz bir form alanı otomatik doldurmayı bozuyor, görünmeyen odak halkası klavyeyle hızlı form dolduran herkesi yavaşlatıyor, düşük kontrast güneş altında telefona bakan müşterinin okuyamaması demek. Hedefi sıfır ihlal olarak koyuyoruz çünkü ölçülebilir ve ulaşılabilir; kendi dört markamızın ana sayfasında bugün ölçtüğümüz değer sıfır.

Tarama, indeksleme ve kırık adres

Sitenin her adresi istenir ve dönen durum kodu kaydedilir. Bu basit işlem şaşırtıcı miktarda sorun çıkarıyor: menüde duran ama 404 dönen bağlantılar, 500 veren alt uygulamalar, site haritasında listelenen ama var olmayan sayfalar, üç adımda çözülen yönlendirme zincirleri, hem www'li hem www'siz açılan ve birbirinin kopyası sayılan adresler.

Aynı tarama sırasında her sayfanın başlığı, açıklaması ve canonical değeri de toplanır. Çıkan tabloda tekrarlanan başlıklar, boş açıklamalar ve kendini göstermeyen canonical'lar tek bakışta görünür hale geliyor.

Görseller ayrıca isteniyor; sayfada src değeri olup sunucuda bulunmayan görsel, hem kullanıcıya boş kutu gösteriyor hem her ziyarette gereksiz bir 404 üretiyor.

Mobil uyum: taşma ölçülerek bulunur

"Mobilde iyi görünüyor" bir ölçüm değil. Sayfa 320, 360, 390, 768 ve 1440 piksel genişlikte açılıp gövdenin yatayda kayıp kaymadığı ölçülüyor; kayıyorsa hangi öğenin taşırdığı adıyla raporlanıyor. En sık suçlular geniş tablolar, uzun e-posta ve adres satırları, ve en uzun seçeneği kadar genişleyen açılır listeler.

Yanında iki şey daha ölçülüyor: dokunma hedeflerinin en az 44 piksel yüksekliğinde olması ve gövde metninin mobilde en az 16 piksel olması. Küçük yazı ve birbirine yapışık bağlantılar, hiçbir hata vermeden dönüşüm kaybettiren türden sorunlar.

Ölçümü yaparken sayfayı yavaş kaydırıyor ve görsellerin oturmasını bekliyoruz. Sabit bir süre verip ekran görüntüsü almak, henüz yüklenmemiş bir görsel yüzünden olmayan bir hatayı var göstermeye yol açıyor; bu yanlış pozitif, denetimin güvenilirliğini bozuyor.

Rapor nasıl geliyor

Rapor önceliklendirilmiş bir liste olarak geliyor. Her madde kendi satırında: etkisi, hangi adresleri etkilediği, nasıl ölçüldüğü, ölçülen değer ve eşiği, önerilen düzeltme. Aynı kusur kırk sayfada tekrarlıyorsa bu kırk iş değil, bir düzeltme olarak yazılıyor — denetim raporunun uzun görünmesi için madde çoğaltmıyoruz.

Denetim tek başına alınabiliyor; düzeltmeyi kendi ekibinizin yapması da, bizim yapmamız da mümkün. Düzeltme bize geçtiğinde her madde kapatıldıkça ölçüm tekrarlanıyor ve önce–sonra değeri raporda yan yana duruyor.

Süreç

Adımlar sırayla yürür; bir sonraki adım öncekinin çıktısı olmadan başlamaz.

  1. Tam tarama

    Her adres istenir; durum kodu, başlık, açıklama, canonical ve yönlendirme kaydedilir.

  2. Ölçüm

    Core Web Vitals, axe-core erişilebilirlik taraması ve beş genişlikte taşma ölçümü yapılır.

  3. Doğrulama

    Yapılandırılmış veri, robots.txt, sitemap ve güvenlik başlıkları denetlenir.

  4. Bulgu listesi

    Her madde ölçüsü, kanıtı ve önerilen düzeltmesiyle önceliklendirilir.

  5. Düzeltme ve yeniden ölçüm

    Kapanan her madde yeniden ölçülür; önce–sonra değeri raporda yan yana durur.

Teknik Denetim çalışmasında neyi ölçüyoruz

Teknik Denetim çalışmasında neyi ölçüyoruz
ÖlçütNasıl ölçüyoruz
Erişilebilirlik ihlali axe-core, WCAG 2.1 AA, mobil + masaüstü
Yatay taşma (320–1440 px) Beş genişlikte scrollWidth ölçümü
Ana sayfa ağırlığı (mobil) Gerçek ağ yanıtları, 390 px
İstek sayısı Aynı ölçüm
canonical / Open Graph / JSON-LD Sayfa kaynağı denetimi

Kendi markalarımızda, 1 Ekim 2026 ölçümü

Kendi markalarımızın ana sayfalarında 1 Ekim 2026 tarihinde ölçülen değerler
Site Ana sayfa İstek axe ihlali
webteknogaraj.com 0,94 MB 39 0
webteknoservis.com 1,30 MB 62 1
kavservis.com.tr 2,20 MB 94 0
digiwss.com 0,86 MB 29 1
  • Dört sitede de her sayfada canonical, Open Graph ve JSON-LD var.
  • Dört sitede de 320, 360, 390, 768 ve 1440 pikselde yatay taşma yok.

Ağırlık ve istek sayısı içerik eklendikçe değişir; bu yüzden tabloda tarih var. Sayılar sizin ölçümünüzle birebir tutmayabilir — ölçümü biz de düzenli tekrarlıyoruz ve iki ölçüm çeliştiğinde kötü olanı yazıyoruz.

Ölçüm yöntemi: Chrome, axe-core 4.13.0 (WCAG 2.1 A + AA + best-practice kural kümesi), ana sayfa, 390 piksel mobil görünüm, görseller oturana kadar beklenerek. Müşteri verisi kullanmıyoruz; ölçülen siteler kendi markalarımız. Aynı ölçümü siz de tekrarlayabilirsiniz.

Sık sorulan sorular

Denetim ne kadar sürüyor?

Site büyüklüğüne bağlı. Birkaç yüz adresli bir sitede tarama ve ölçümler birkaç gün, bulgu listesinin yazılması ve önceliklendirilmesi onu takip ediyor. Tarih vermeden önce sitenin adres sayısını ölçüyoruz; görmeden süre söylemek yanlış bir beklenti kuruyor.

Düzeltmeyi kendi ekibim yapabilir mi?

Evet. Rapor bunun için yazılıyor: her maddede hangi dosyada ne değişeceği ve değişikliğin nasıl doğrulanacağı yer alıyor. Kendi ekibiniz kapattıkça ölçümü tekrarlayıp doğrulamamızı da isteyebilirsiniz; bu durumda iş düzeltme değil doğrulama olarak yürüyor.

Lighthouse puanı 90 çıkıyor, denetime gerek var mı?

Lighthouse tek sayfaya bakıyor ve erişilebilirlik tarafında kuralların yalnızca bir bölümünü çalıştırıyor; yüksek puan "ihlal yok" demek değil. Kendi ölçümlerimizde Lighthouse'un iyi puan verdiği sayfalarda axe-core ile onlarca ihlal bulduğumuz oldu. Ayrıca Lighthouse tarama, indeksleme, kırık adres ve taşma konularını hiç ölçmüyor.

Rapordaki maddelerin hepsi kapatılmak zorunda mı?

Kapatılmasını bekliyoruz ve kapatılmayanın gerekçesini raporda bırakıyoruz. Bir madde iş kararı gerektiriyorsa (örneğin bir alt uygulamanın kaldırılması) bunu karar maddesi olarak işaretliyoruz. Yapmadığımız şey, maddeyi "önemsiz" diyerek listeden silmek.

Teknik Denetim için konuşalım

Adresinizi gönderin; ölçüm sonucunu ve ne yapılması gerektiğini paylaşalım. Kapsam netleştikten sonra teklif veriyoruz.