Web Sitesi Yayına Alınmadan Önce Test Süreci: Kalite Kontrol Listesi

Yayın öncesi test, yeni bir web sitesini ziyaretçiye açmadan önce her sayfayı, formu ve teknik ayarı planlı biçimde kontrol ettiğiniz kalite kontrol aşamasıdır. Bu yazıda 2012'den beri projelerde kullandığım kontrol listesini paylaşıyorum: tarayıcı ve cihaz testleri, formlar, hız, SEO etiketleri, 404 ve yönlendirmeler, analitik ve güvenlik. Amacım size bir teori değil, masanızın yanına koyabileceğiniz bir sıra vermek.

Web sitesinde yayın öncesi test süreci nedir?

Yayın öncesi test süreci, sitenin işlevini, görünümünü, hızını, arama motoru ayarlarını, ölçüm kodlarını ve güvenliğini canlıya almadan önce bir kontrol listesiyle doğruladığınız aşamadır. Amaç, hatayı ziyaretçi ve Google görmeden bulmaktır. Süreç bir test ortamında yürür ve her maddenin sahibi ile sonucu yazılı olarak kayda geçer.

Burada kritik nokta şudur: test, "bir göz atalım" demek değildir. Her maddenin net bir geçme ölçütü olmalıdır. Örneğin "form çalışıyor" yazmak yetmez; "form gönderildi, bildirim e-postası iki dakika içinde geldi, kayıt CRM'e düştü" yazarsınız. Böylece kimin neyi kontrol ettiği tartışma konusu olmaz.

Ayrıca test, tek kişilik bir iş de değildir. Tasarımcı görünümü, geliştirici işlevi, pazarlama ekibi ise ölçümü ve metinleri kontrol eder. Bu işi yıllardır yöneten biri olarak şunu söyleyebilirim: en pahalı hatalar genellikle kimsenin sahiplenmediği maddelerde çıkar. Bu yüzden listeyi dağıtırken her satıra bir isim yazıyorum.

Neden yayın öncesi testi atlamamalısınız?

Çünkü yayından sonra bulunan hata, test aşamasında bulunan hatadan çok daha pahalıya patlar. Bozuk bir iletişim formu, siz fark edene kadar gelen her talebi sessizce kaybeder. Canlıda kalan bir noindex etiketi ise sitenin arama sonuçlarında görünmesini tamamen durdurabilir.

Üstelik ilk izlenimi tekrar yaşatamazsınız. Reklam kampanyası başladığında ziyaretçi mobilde kayan bir menü ya da yüklenmeyen bir görselle karşılaşırsa, o tıklamanın parasını zaten ödemişsinizdir. Dolayısıyla test süreci bir maliyet kalemi değil, reklam ve SEO yatırımının sigortasıdır.

Sahada en sık gördüğüm senaryo şöyle ilerler: ekip siteyi cuma akşamı yayına alır, hafta sonu kimse bakmaz, pazartesi günü formların iki gündür e-posta göndermediği anlaşılır. Bu tablonun önüne geçmenin yolu basittir; yayın gününü hafta başına koyar ve testi bir gün önce bitirirsiniz. Böylece bir sorun çıkarsa ekip ortadadır.

Kısacası, yayın öncesi test sizi hem para kaybından hem de itibar kaybından korur. Sitenizi yenileyecekseniz bu aşamayı teklifte ayrı bir kalem olarak görmek istemeniz de yerinde bir taleptir; web tasarım hizmetimde test aşaması bu yüzden ayrı bir adım olarak yer alır.

Test ortamını nasıl kurmalısınız?

Test ortamı, canlı siteyle aynı sunucu ayarlarına, aynı PHP ya da Node sürümüne ve mümkünse gerçeğe yakın içeriğe sahip ayrı bir kopya olmalıdır. Genellikle bunu bir alt alan adında kurarım, örneğin test.alanadiniz.com gibi. Ancak bu kopyanın arama motorlarına kapalı olması şarttır.

Google Search Central, bir sayfanın arama sonuçlarından tamamen çıkmasını istiyorsanız robots.txt yerine noindex ya da parola koruması kullanmanızı önerir. Çünkü robots.txt yalnızca taramayı engeller; başka sitelerden link alan bir adres yine de dizine girebilir. Bu nedenle test ortamını en güvenli haliyle HTTP parola korumasının arkasına koyarım.

• Test ortamını parola ile koruyun; yalnızca robots.txt ile yetinmeyin.
• Canlı ile aynı sunucu yazılımı ve sürümlerini kullanın.
• Gerçek müşteri verisini test ortamına kopyalamayın; sahte ama gerçekçi veri kullanın.
• Ödeme altyapısını sağlayıcının test modunda çalıştırın.
• Test ortamındaki e-postaları gerçek müşterilere değil, ekibin adreslerine yönlendirin.

Son madde özellikle önemlidir. Test sırasında gerçek müşteri listesine yanlışlıkla bildirim göndermek, yayından önce yaşanabilecek en utanç verici hatalardan biridir.

Tarayıcı ve cihaz testlerini nasıl yaparsınız?

Tarayıcı ve cihaz testini ziyaretçilerinizin gerçekten kullandığı ortamlara göre planlarsınız. Eski sitenizin GA4 verisinde "Teknoloji" raporuna bakarak en çok kullanılan tarayıcıları ve ekran boyutlarını çıkarın. Böylece listeyi tahmine değil, veriye dayandırırsınız.

Genellikle şu kombinasyonları test ederim: Android telefonda Chrome, iPhone'da Safari, masaüstünde Chrome, Edge ve Firefox, ayrıca bir tablet. Özellikle iPhone Safari'yi atlamayın; bazı CSS ve form davranışları orada farklı çalışır. Tarayıcının geliştirici araçlarındaki mobil görünüm iyi bir başlangıçtır, ancak gerçek cihazın yerini tutmaz.

Her cihazda şunlara bakarsınız: menü açılıp kapanıyor mu, yazılar taşmadan okunuyor mu, düğmeler parmakla rahat tıklanıyor mu, yatay kaydırma çıkıyor mu? Mobil tarafı daha ayrıntılı ele almak isterseniz mobil uyumluluk testi rehberime göz atabilirsiniz; orada ölçütleri tek tek anlattım.

Ayrıca yazı boyutunu büyüten kullanıcıları unutmayın. Telefonunda sistem yazı boyutunu büyütmüş bir ziyaretçi, sizin göremediğiniz taşmalarla karşılaşabilir. Bu yüzden en az bir cihazda yazı boyutunu büyütüp ana sayfayı ve formu yeniden kontrol ederim.

Bir ipucu daha vereyim: testi ekran görüntüsüyle belgeleyin. Hatalı görünümü ekran görüntüsüyle ve cihaz bilgisiyle bildirmek, geliştiricinin sorunu yeniden üretmesini ciddi biçimde hızlandırır.

Formları ve dönüşüm akışlarını nasıl test edersiniz?

Formları uçtan uca test edersiniz: doldurma, doğrulama mesajları, gönderim, teşekkür sayfası, bildirim e-postası ve verinin düştüğü yer. Sadece "gönder" düğmesine basıp başarı mesajını görmek yetmez. Asıl soru, talebin doğru kişiye ulaşıp ulaşmadığıdır.

1. Formu eksik alanlarla göndermeyi deneyin; hata mesajının anlaşılır olduğunu kontrol edin.
2. Yanlış e-posta ve telefon biçimleriyle doğrulamayı test edin.
3. Formu doğru bilgilerle gönderin ve teşekkür sayfasının açıldığını görün.
4. Bildirim e-postasının hem size hem de otomatik yanıt açıksa ziyaretçiye geldiğini doğrulayın.
5. Kaydın CRM'de ya da panelde doğru alanlarla oluştuğunu kontrol edin.
6. Spam korumasının gerçek kullanıcıyı engellemediğinden emin olun.

E-posta tarafında sık yaşanan sorun, sunucudan giden bildirimlerin spam klasörüne düşmesidir. Sorunun kaynağı genellikle SPF, DKIM ve DMARC kayıtlarının eksik olmasıdır. Bu konuyu kurumsal e-posta altyapısı yazımda ayrıntılı anlattım. Form tasarımının kendisini ise randevu ve teklif formu yazısında ele aldım; burada yalnızca testine odaklanıyorum.

Sayfa hızını yayın öncesinde nasıl ölçersiniz?

Hızı yayından önce laboratuvar araçlarıyla ölçersiniz, çünkü henüz gerçek kullanıcı verisi yoktur. Lighthouse ve PageSpeed Insights bu aşamanın temel araçlarıdır. Ancak test ortamı parola korumalıysa PageSpeed Insights sayfaya erişemez; bu durumda Chrome'daki Lighthouse'u kullanırsınız.

Hedef değerler için Google'ın web.dev üzerinde yayımladığı Core Web Vitals eşiklerini esas alırım: LCP için 2,5 saniye, INP için 200 milisaniye, CLS için 0,1 ve altı "iyi" kabul edilir. Yine de laboratuvar puanı ile gerçek kullanıcı deneyimi aynı şey değildir. Bu yüzden yayından sonra da ölçmeye devam edersiniz.

Yayın öncesinde en sık yakaladığım hız sorunları şunlardır: sıkıştırmadan yüklenen büyük görseller, gereksiz yere yüklenen yazı tipi ağırlıkları ve her sayfada çalışan ama yalnızca bir sayfada gereken eklentiler. Görsel boyutlarını hızlıca küçültmek için resim küçültme aracımı kullanabilirsiniz.

Lighthouse raporunu yorumlamayı bilmiyorsanız Lighthouse ile performans testi yazıma bakın. Hızın sıralamaya etkisini merak ediyorsanız da site hızı ve SEO yazısı iyi bir tamamlayıcıdır.

SEO etiketlerini yayın öncesi testte nasıl kontrol edersiniz?

SEO etiketlerini her şablon türü için ayrı ayrı kontrol edersiniz: ana sayfa, hizmet sayfası, ürün sayfası, blog yazısı ve kategori. Her şablonda title, meta description, canonical, H1, robots meta etiketi ve hreflang varsa onun doğru üretildiğine bakarsınız.

Yayın öncesi test sırasında en çok dikkat ettiğim madde robots meta etiketidir. Test ortamında noindex kullanmak doğru bir karardır; ancak aynı ayar canlıya taşınırsa site arama sonuçlarından çekilir. Dolayısıyla yayın gününün ilk kontrolü, canlı sayfaların kaynağında noindex olup olmadığıdır.

Kontrol etmeniz gereken diğer noktalar şunlardır:

• Her sayfada tek ve benzersiz bir H1 olmalı.
• Title ve description boş ya da tekrar eden olmamalı.
• Canonical adresi test alan adını değil, canlı alan adını göstermeli.
• Yapısal veri varsa Google'ın Zengin Sonuç Testi'nden hatasız geçmeli.
• Görsellerde anlamlı alt metin bulunmalı.

Başlık ve açıklamanın arama sonucunda nasıl görüneceğini Google SERP önizleme aracında deneyebilirsiniz. Yazım kuralları için meta title ve description rehberim hazır.

404 hatalarını ve kırık linkleri nasıl bulursunuz?

Kırık linkleri bir tarama aracıyla bulursunuz. Screaming Frog gibi bir tarayıcı, test sitesini baştan sona gezip 404 dönen adresleri, kırık görselleri ve yanlış iç linkleri listeler. Parola korumalı ortamlarda bu araçlara kimlik bilgisini girmeniz gerekir.

Taramada özellikle şu durumlara bakarım: menüdeki ve alt bilgideki linkler, eski alan adına ya da test adresine giden sabit linkler ve içerik taşınırken bozulan görsel yolları. Test adresine giden bir link canlıya kaçarsa ziyaretçi parola ekranıyla karşılaşır; bu da güveni hemen sarsar.

Öte yandan 404 sayfasının kendisini de test edersiniz. Olmayan bir adres yazdığınızda sayfa gerçekten 404 durum kodu dönmeli, 200 değil. Google Search Central, içeriği olmayan ama 200 dönen sayfaları "soft 404" olarak işaretler ve bunları sorun olarak raporlar. Ayrıca iyi bir 404 sayfası ziyaretçiye arama kutusu ve ana kategorilere link sunar.

Kısacası, kırık link kontrolü tek seferlik bir iş değildir. Yayından sonra Search Console'daki sayfa dizine ekleme raporunu da düzenli izlersiniz; nasıl okunacağını Search Console rehberimde anlattım.

Yönlendirmeleri yayından önce nasıl doğrularsınız?

Site yenileniyorsa eski adreslerin yeni karşılıklarına kalıcı olarak, yani 301 ile yönlendirilmesi gerekir. Yönlendirmeleri yayından önce bir tabloda eşler, sonra her satırı tek tek test edersiniz. Google Search Central, kalıcı taşımalarda sunucu taraflı kalıcı yönlendirmeyi önerir.

Test ederken üç şeye bakarım. Birincisi, durum kodu gerçekten 301 mi? İkincisi, yönlendirme zinciri var mı; yani A adresi B'ye, B de C'ye mi gidiyor? Üçüncüsü, yönlendirme doğru sayfaya mı gidiyor, yoksa her şeyi ana sayfaya mı atıyor? Her şeyi ana sayfaya göndermek kolaydır, ancak hem ziyaretçiyi hem de Google'ı yanıltır.

Tek tek kontrol için yönlendirme denetleyici aracımı kullanabilirsiniz. Adres sayısı yüzlerle ölçülüyorsa listeyi bir tarama aracına verip toplu kontrol etmek daha mantıklıdır.

Ayrıca HTTP'den HTTPS'e ve www'lu adresten www'suz adrese (ya da tersi) tek adımda yönlendirme yapıldığını doğrulayın. Taşıma sürecinin tamamını ise SEO migration kontrol listemde ele aldım; bu yazıda yalnızca test adımına odaklanıyorum.

Analitiği ve dönüşüm takibini nasıl test edersiniz?

Analitiği, olayların gerçekten doğru isim ve parametrelerle geldiğini görerek test edersiniz. GA4'ün DebugView ekranı bu iş için tasarlanmıştır; Google Tag Manager'ın önizleme moduyla birlikte kullandığınızda her tıklamanın hangi etiketi tetiklediğini canlı izlersiniz.

Kontrol listemde şu maddeler yer alır:

• GA4 sayfa görüntülemeleri her şablonda tek sefer mi geliyor?
• Form gönderimi, telefon tıklaması ve WhatsApp tıklaması olay olarak düşüyor mu?
• Google Ads dönüşüm etiketi teşekkür sayfasında tetikleniyor mu?
• Çerez onay bandı, onay verilmeden önce etiketleri durduruyor mu?
• UTM parametreli bir adresle gelince kaynak doğru görünüyor mu?

Son madde için UTM oluşturucu aracımla bir test linki hazırlayıp DebugView'da kaynağı kontrol edebilirsiniz. Bir uyarı ekleyeyim: test ortamındaki trafiği canlı mülke karıştırmayın. Ya ayrı bir test mülkü kullanın ya da iç trafiği filtreleyin.

Hangi dönüşümleri izleyeceğinize henüz karar vermediyseniz önce dönüşüm hedefi yazımı okumanızı öneririm. Ölçmediğiniz hedefi test de edemezsiniz.

Güvenlik kontrolleri nelerdir?

Yayın öncesi güvenlik kontrolü, sitenin temel açıklarını canlıya taşımadığınızdan emin olmaktır. Kapsamlı bir sızma testi büyük projelerde ayrı bir iş kalemidir; ancak her site için yapılması gereken asgari kontroller vardır.

• SSL sertifikası geçerli mi ve tüm sayfalar HTTPS ile açılıyor mu?
• Karışık içerik uyarısı, yani HTTPS sayfada HTTP ile yüklenen dosya var mı?
• Yönetim paneli varsayılan adreste mi, güçlü parola ve iki adımlı doğrulama açık mı?
• Hata ayıklama modu kapalı mı; hata mesajları sunucu yolunu ya da veritabanı bilgisini gösteriyor mu?
• Yedek dosyaları, .env ya da .git klasörü tarayıcıdan erişilebilir durumda mı?
• Formlarda spam ve kötü niyetli girdiye karşı koruma var mı?

Web uygulaması riskleri için OWASP Top 10 listesi iyi bir referanstır. Örneğin enjeksiyon ve hatalı erişim kontrolü bu listenin kalıcı başlıkları arasındadır. Dolayısıyla formlarınız veritabanına yazıyorsa geliştiricinize bu başlıklara karşı nasıl önlem aldığını sormanız yerinde olur.

Bir de pratik not düşeyim: yayından önce yönetici hesaplarını gözden geçirin. Ekipler test sürecinde açtıkları geçici hesapları çoğu zaman unutur ve bu hesaplar yıllarca açık kalır. Güçlü parola üretmek için şifre oluşturucu aracımı kullanabilirsiniz.

Ödeme ve sipariş senaryolarını nasıl test edersiniz?

Ödeme alan bir sitede test kapsamı genişler, çünkü burada hata doğrudan para kaybı demektir. Bu yüzden ödeme sağlayıcınızın test modunu açar ve sağlayıcının verdiği test kartlarıyla başarılı, reddedilen ve yarıda kalan ödemeleri tek tek denersiniz. Her senaryoda siparişin panelde doğru durumla göründüğünü kontrol edersiniz.

Bunun yanında şu soruların cevabını ararım: stok sıfıra düştüğünde ürün satışa kapanıyor mu, kargo ücreti doğru hesaplanıyor mu, indirim kodu tutarı doğru düşüyor mu, müşteri sipariş onay e-postasını alıyor mu? Ayrıca fatura ya da muhasebe entegrasyonu varsa test siparişinin oraya gerçek kayıt olarak düşmediğinden emin olursunuz. Aksi halde test siparişleri resmi kayıtlara karışır.

Son adım olarak test modunu kapatıp gerçek kartla küçük tutarlı bir sipariş verir, ardından iade akışını çalıştırırsınız. Böylece canlı ortamda para giriş ve çıkışının ikisinin de çalıştığını görürsünüz. E-ticaret projelerinde bu kontrolü e-ticaret danışmanlığı kapsamında da yürütüyorum.

İçerik ve yazım kontrolü neden ayrı bir adımdır?

Çünkü teknik ekip çoğunlukla işlevi test eder, metni okumaz. Sonuç olarak yazım hatası, eski fiyat, yanlış telefon numarası ya da "lorem ipsum" ile kalmış bir kutu yayına çıkabilir. Bu tür hatalar teknik olarak küçük görünse de güveni doğrudan etkiler.

İçerik kontrolünü bu yüzden işi en iyi bilen kişiye veririm: işletme sahibine ya da satış ekibine. Onlar fiyatın, adresin, çalışma saatlerinin ve hizmet kapsamının güncel olup olmadığını bir bakışta anlar. Öte yandan yasal metinlerin, yani gizlilik politikası, çerez politikası ve KVKK aydınlatma metninin de yerinde ve güncel olduğunu kontrol edersiniz.

Okunabilirlik tarafında uzun paragrafları ve anlaşılmayan cümleleri ayıklamak için okunabilirlik analizi aracımı kullanabilirsiniz. Böylece metin hem ziyaretçiye hem de arama motoruna daha net bir mesaj verir.

Son olarak telefon ve e-posta linklerini tek tek tıklayın. Telefon numarasını tel: linkiyle vermek mobilde arama başlatır; ancak numara hatalı yazılmışsa ziyaretçi yanlış kişiyi arar. Bu küçük detay, sahada gördüğüm en can sıkıcı hatalardandır.

Erişilebilirlik testini yayın öncesinde nasıl yaparsınız?

Erişilebilirlik testini otomatik araçla başlatır, elle kontrolle tamamlarsınız. Lighthouse'un erişilebilirlik bölümü ve tarayıcı eklentisi olarak çalışan axe gibi araçlar renk kontrastı, eksik alt metin ve etiketlenmemiş form alanları gibi sorunları hızla yakalar.

Ancak otomatik araçlar her şeyi yakalamaz. Bu yüzden siteyi bir kez de yalnızca klavyeyle gezerim: Tab tuşuyla menü açılıyor mu, odak çerçevesi görünüyor mu, form Enter ile gönderiliyor mu? Bu basit test bile çoğu projede birkaç önemli sorunu ortaya çıkarır.

W3C'nin yayımladığı WCAG 2.2 yönergeleri bu alanda temel referanstır. Avrupa'ya satış yapan işletmeler için erişilebilirlik artık yalnızca iyi niyet meselesi değildir; Avrupa Erişilebilirlik Yasası bazı dijital hizmetler için yükümlülük getirir. Bu nedenle yurt dışına satış yapıyorsanız bu maddeyi listenin sonuna bırakmayın.

Yayın öncesi kalite kontrol listesi tablosunda neler yer alır?

Aşağıdaki tablo, projelerde kullandığım kontrol listesinin özetidir. Her satır bir alanı, neyi kontrol ettiğinizi, hangi araçla baktığınızı ve geçme ölçütünü gösterir. Kendi projenize göre satır ekleyebilir ya da çıkarabilirsiniz.

Bu tabloyu paylaşılan bir tabloya taşıyıp her satıra sorumlu ve tarih sütunu eklemenizi öneririm. Böylece yayın toplantısında "buna kim baktı?" sorusunun cevabı herkesin önünde durur.

Yayın günü hangi kontrolleri tekrarlamalısınız?

Yayın günü, test ortamında geçen her şeyin canlıda da geçtiğini hızlıca doğrularsınız. Çünkü taşıma sırasında ayarlar değişebilir: ortam değişkenleri, e-posta ayarları, önbellek ve robots dosyası en sık bozulan kalemlerdir.

1. Canlı sayfaların kaynağında noindex olmadığını kontrol edin.
2. robots.txt dosyasının tüm siteyi engellemediğini doğrulayın.
3. Her formdan bir test gönderimi yapın.
4. GA4 gerçek zamanlı raporda kendi ziyaretinizi görün.
5. Birkaç eski adresin yeni sayfalara 301 ile gittiğini deneyin.
6. XML site haritasını Search Console'a gönderin.

Site haritası yoksa ya da eski kalmışsa XML sitemap oluşturucu aracıyla hazırlayabilirsiniz. robots.txt için de robots.txt oluşturucuyu kullanabilirsiniz; ancak canlıda son hali mutlaka elle okuyun.

Yayından sonraki ilk haftalarda neyi izleyeceğiniz ise ayrı bir konudur. Test sürecinin görevi siteyi temiz bir başlangıçla açmaktır; sonrasındaki ölçüm düzenini ayrıca kurmanız gerekir.

Test sürecinde ekipler en sık hangi hataları kaçırır?

Sahada en sık kaçırılan hatalar, kimsenin "benim işim" demediği ara noktalarda çıkar. Kendi projelerimde ve devraldığım sitelerde tekrar tekrar gördüğüm başlıklar şunlardır:

• Canlıya taşınan noindex etiketi ya da tüm siteyi engelleyen robots.txt.
• Test alan adını gösteren canonical ve iç linkler.
• Bildirim e-postası gitmeyen ya da spam klasörüne düşen formlar.
• İki kez tetiklenen dönüşüm etiketi ve bu yüzden şişen reklam raporları.
• Mobilde görünmeyen ya da tıklanamayan iletişim düğmesi.
• Silinmeyi bekleyen test hesapları ve açık yedek dosyaları.

Dikkat ederseniz bu listede zor teknik problemler yok. Hepsi basit ama gözden kaçan kontroller. Bu yüzden deneyimli bir ekip bile kontrol listesi olmadan çalışmamalıdır; hafıza, yorgun bir yayın akşamında en güvenilmez araçtır.

Özellikle çift tetiklenen dönüşüm etiketi pahalı bir hatadır. Google Ads akıllı teklif stratejileri dönüşüm verisiyle öğrenir; dolayısıyla yanlış veri, bütçenin yanlış yere akmasına yol açar. Reklam hesabınızın bu açıdan kontrolünü Google Ads yönetimi kapsamında da yapıyorum.

Test süreci ne kadar sürmeli ve kim yapmalı?

Süre sitenin büyüklüğüne ve işlevine göre değişir. Saha tecrübeme dayalı başlangıç aralığı şöyledir, garanti değildir: 10 ila 20 sayfalık bir kurumsal site için bir ila üç iş günü, formu ve üye alanı olan orta ölçekli bir site için bir hafta civarı, e-ticaret sitesi içinse ödeme ve stok senaryoları nedeniyle daha uzun bir süre ayırırım.

Kimin yapacağı sorusuna gelince, en sağlıklı yapı üç katmandır. Geliştirici kendi işini test eder, proje yöneticisi kontrol listesini yürütür, işletme sahibi ise içeriği ve iş akışını onaylar. Böylece her katman bir öncekinin gözden kaçırdığını yakalar.

Küçük bir işletmeyseniz ve ayrı bir test ekibiniz yoksa yine de bir kural koyun: siteyi yapan kişi tek başına onay vermesin. Kendi yaptığınız işteki hatayı görmek zordur. Taze bir gözün on beş dakikalık kontrolü bile ciddi fark yaratır.

Sitenizin yayına hazırlık aşamasında dışarıdan bir kontrol isterseniz iletişim sayfasından bana ulaşabilirsiniz. Yeni siteyle birlikte arama görünürlüğünü de planlıyorsanız SEO danışmanlığı sayfasında nasıl çalıştığımı anlattım.

Sonuç: Yayın öncesi test nasıl alışkanlığa dönüşür?

Yayın öncesi test, bir kez yapılıp unutulan bir aşama değil, her güncellemede tekrar eden bir alışkanlık olmalıdır. Yeni bir sayfa şablonu, yeni bir form ya da yeni bir eklenti eklediğinizde listenin ilgili bölümünü tekrar çalıştırırsınız.

Bir noktanın altını ayrıca çizmek istiyorum: kontrol listesi ekibi yavaşlatmak için değil, ekibin aklını boşaltmak için vardır. Liste elinizdeyken "acaba bir şeyi unuttum mu?" kaygısıyla uğraşmazsınız; enerjinizi gerçekten düşünmeyi gerektiren sorunlara ayırırsınız. Üstelik yeni katılan bir ekip arkadaşı da aynı listeyle ilk gününden itibaren aynı kalitede çalışır.

Öte yandan listeyi fazla şişirmekten de kaçının. Yüzlerce maddelik bir liste bir süre sonra kimsenin okumadığı bir belgeye dönüşür. Benim tercihim, her alan için en fazla on madde tutmak ve nadiren işe yarayan maddeleri ayrı bir "büyük proje" ekine taşımaktır. Böylece günlük kullanımdaki liste kısa ve uygulanabilir kalır.

Benim önerim şu: bu yazıdaki tabloyu kendi şablonunuza dönüştürün, her projede kopyalayın ve her yayından sonra kaçırdığınız bir şey olduysa listeye yeni bir satır ekleyin. Böylece liste zamanla sizin sitenize özgü bir kalite belgesine dönüşür. Kısacası, iyi bir kontrol listesi deneyimin yazıya geçmiş halidir.