Production Öncesi Teknik Release Checklist

Bir web sitesini yayına almak yalnızca dosyaları sunucuya taşımaktan ibaret değildir. Production öncesinde yapılan teknik kontroller, yayına çıktıktan sonra yaşanabilecek trafik kaybını, güvenlik açıklarını, kullanıcı deneyimi sorunlarını ve veri kayıplarını ciddi ölçüde azaltır. Özellikle ajanslar, geliştiriciler ve site yöneticileri için sistemli bir release checklist kullanmak, süreci kişisel hafızaya değil standart bir kalite kontrol akışına bağlar.

Bu rehberde production öncesi mutlaka gözden geçirilmesi gereken teknik başlıkları tek tek ele alacağız. Amaç, DNS'ten HTTPS'e, SEO ayarlarından loglamaya, formlardan yedeklemeye kadar canlıya geçiş öncesi kritik noktaları tek bir pratik kontrol listesi içinde toplamaktır.

1. DNS, Domain ve Sunucu Erişimi Kontrolleri

Production yayını öncesinde ilk kontrol edilmesi gereken alan, domain ve DNS yapılandırmasıdır. Çünkü en iyi hazırlanmış site bile yanlış A kaydı, hatalı CNAME veya eksik nameserver yönlendirmesi yüzünden erişilemez hale gelebilir. Özellikle domain farklı bir sağlayıcıda, barındırma farklı bir sistemdeyse geçiş öncesi kayıtların net şekilde doğrulanması gerekir.

Canlıya alınacak domainin doğru sunucuya işaret ettiğinden emin olun. A, AAAA, CNAME, MX ve gerekiyorsa TXT kayıtları kontrol edilmeli, TTL değerleri geçiş stratejisine göre planlanmalıdır. Staging ve production ortamları aynı kaynaklara yanlışlıkla bağlanmamalı, özellikle www ve non-www versiyonlarının davranışı önceden belirlenmelidir.

Yayın öncesi temel DNS kontrolleri şunlardır:

• Domain aktif mi ve süresi yeterli mi?
• Nameserver ayarları doğru sağlayıcıyı gösteriyor mu?
• A veya CNAME kayıtları production sunucusuna doğru gidiyor mu?
• www alt alan adı doğru çalışıyor mu?
• Gerekli e-posta kayıtları, varsa MX ve SPF yapılandırmaları korunuyor mu?
• Eski sunucudan yeni sunucuya geçişte TTL düşürüldü mü?

Ayrıca doğrudan IP üzerinden test yapıldıysa, gerçek domain ile davranışın da ayrı test edilmesi gerekir. Çünkü cookie, SSL, canonical ve yönlendirme kurguları çoğu zaman domain seviyesinde devreye girer. Sunucuya erişim, dosya izinleri, deploy kullanıcısı ve CI/CD yetkileri de bu aşamada yeniden gözden geçirilmelidir.

2. HTTPS, SSL Sertifikası ve Güvenli Bağlantı Yapılandırması

Production ortamında HTTPS artık bir tercih değil temel gerekliliktir. Güvenlik, kullanıcı güveni, tarayıcı uyumluluğu ve SEO açısından SSL yapılandırmasının eksiksiz olması gerekir. Hatalı sertifika zinciri, mixed content sorunları veya eksik redirect kurgusu yayına çıkınca ciddi güven kaybı yaratabilir.

SSL sertifikasının doğru domainler için tanımlandığını kontrol edin. Ana domain, www alt alan adı ve gerekiyorsa kullanılan diğer subdomainler kapsama dahil olmalıdır. Sertifika süresi, otomatik yenileme mekanizması ve sunucunun TLS yapılandırması da test edilmelidir.

Bu aşamada şu maddeler kontrol edilmelidir:

• HTTP istekleri eksiksiz şekilde HTTPS'e yönleniyor mu?
• Tarayıcıda güvenli bağlantı uyarısı çıkıyor mu?
• Mixed content, yani HTTP üzerinden yüklenen görsel, script veya CSS dosyası var mı?
• Sertifika zinciri tam mı?
• HSTS kullanılacaksa doğru yapılandırıldı mı?
• CDN veya reverse proxy arkasında SSL sonlandırması doğru çalışıyor mu?

Özellikle harici scriptler, font dosyaları, iframe'ler ve eski medya URL'leri mixed content sorununun en sık kaynağıdır. Production öncesi birden fazla sayfa türünde manuel test yapmak önemlidir. Ana sayfa temiz görünüyor olsa bile blog yazılarında, ürün sayfalarında veya eski içeriklerde güvenlik hataları ortaya çıkabilir.

3. Redirect, Canonical ve URL Standardizasyonu

Yayına çıkmadan önce URL yapısının standartlaştırılması, hem SEO hem kullanıcı deneyimi açısından kritik bir adımdır. Arama motorları aynı içeriğe birden fazla URL üzerinden erişebiliyorsa otorite bölünebilir. Kullanıcı tarafında ise kırık bağlantılar, zincir yönlendirmeler ve gereksiz 302 kullanımları sorun yaratabilir.

Öncelikle sitenin tek bir ana versiyonunu belirleyin. www veya non-www, trailing slash kullanımı, HTTP'den HTTPS'e geçiş ve varsa eski URL yapılarından yeni düzene geçiş net şekilde tanımlanmalıdır. Tüm kalıcı yönlendirmelerde mümkün olduğunca 301 tercih edilmeli, gereksiz redirect chain yapılarından kaçınılmalıdır.

Production öncesi yönlendirme ve URL kontrol listesi:

Kontrol	Beklenen Durum
HTTP > HTTPS	301 ile tek adım yönlendirme
www > non-www veya tersi	Tek kanonik versiyon
Eski URL'ler	İlgili yeni sayfaya 301
404 olmuş taşınan içerikler	En yakın alakalı içeriğe yönlendirme
Geçici sayfalar	Gerekiyorsa 302, aksi halde 301
URL parametreli kopyalar	Canonical ile temizlenmiş

Canonical etiketleri her sayfada bilinçli kullanılmalıdır. Self-referencing canonical çoğu sayfada iyi bir standarttır. Filtreleme, sıralama, kampanya parametreleri ve pagination gibi durumlarda canonical mantığı mutlaka test edilmelidir. Yanlış canonical kullanımı, dizine alınmasını istediğiniz sayfaların arama sonuçlarından düşmesine neden olabilir.

Ayrıca hreflang kullanılan çok dilli yapılarda canonical ile hreflang çakışmamasına dikkat edin. Eğer site Türkçe tek dilde yayınlanıyorsa, en azından URL standardizasyonunun temiz olması büyük avantaj sağlar. Özellikle staging URL'lerinin canonical içinde yanlışlıkla production'a taşınması sık yapılan ciddi hatalardan biridir.

4. Robots.txt, Sitemap ve İndekslenebilirlik Ayarları

Bir sitenin yayına alınmasından sonra arama motorlarının neyi tarayacağı ve neyi dizine ekleyeceği büyük ölçüde bu katmanda belirlenir. Geliştirme sürecinde kullanılan geçici engellemelerin production'a yanlışlıkla taşınması, organik görünürlüğü sıfıra kadar indirebilir. Bu nedenle robots.txt ve index ayarları yayından hemen önce özel olarak kontrol edilmelidir.

İlk olarak robots.txt dosyasının production için uygun olup olmadığını test edin. Staging aşamasında kullanılan

gibi tam engelleyici kurallar canlıda kalmamalıdır. Aynı şekilde meta robots etiketlerinde kullanılan sayfalar varsa bunların gerçekten index dışı kalması gereken sayfalar olduğundan emin olun.

Kontrol edilmesi gereken başlıca maddeler:

• robots.txt erişilebilir mi?
• Geliştirme dönemine ait tam engel kuralları kaldırıldı mı?
• XML sitemap doğru URL'yi işaret ediyor mu?
• Sitemap yalnızca indexlenmesi gereken sayfaları mı içeriyor?
• 200 dönmeyen, canonical ile başka sayfaya işaret eden veya noindex olan URL'ler sitemap'e girmiş mi?
• Search Console için sitemap yolu hazır mı?

XML sitemap üretimi otomatikse güncel içerik tiplerini kapsadığından emin olun. Blog, hizmet, kategori, ürün veya statik sayfalar için hangi URL'lerin sitemap'e gireceği net olmalıdır. Çok sayfalı projelerde sitemap index yapısı kullanmak faydalı olabilir.

Bir diğer kritik konu da taranabilirlik ile render edilebilirlik arasındaki farktır. Sayfa kaynakta boş geliyor ve içerik tamamen istemci tarafında geç yükleniyorsa, arama motorlarının ana içeriği gerçekten görebildiğini test etmek gerekir. Sadece taranabiliyor olması, içeriğin doğru algılandığı anlamına gelmez.

5. Metadata, Structured Data ve Sayfa Bazlı SEO Kontrolleri

Production öncesi teknik checklist'in en görünür başlıklarından biri metadata katmanıdır. Çünkü title, meta description, Open Graph, Twitter kartları ve structured data gibi alanlar hem arama görünürlüğünü hem de paylaşım deneyimini doğrudan etkiler. Şablon düzeyinde doğru kurulum yapılmış olsa bile sayfa bazlı boşluklar veya tekrarlar bulunabilir.

Her önemli sayfada benzersiz ve amaca uygun title ile meta description kullanıldığını kontrol edin. Ana sayfa, hizmet sayfaları, kategori sayfaları, blog yazıları ve iletişim gibi kritik URL'ler öncelikli olarak incelenmelidir. Çok uzun title kullanımı, eksik description veya aynı meta verinin tüm siteye yayılması kalite sorununa yol açar.

Bu bölümde aşağıdaki öğeler test edilmelidir:

• Her sayfada tek ve anlamlı bir title var mı?
• Meta description alanları dolu ve sayfaya özgü mü?
• H1 yapısı doğru mu, birden fazla H1 gereksiz kullanılmış mı?
• Open Graph title, description ve image alanları mevcut mu?
• Sosyal paylaşım görselleri doğru boyutlarda mı?
• Favicons ve app icons doğru yükleniyor mu?

Structured data tarafında ise gereksiz şema kullanımından kaçınılmalı, gerçekten sayfanın tipine uygun yapılandırmalar tercih edilmelidir. Örneğin blog sayfalarında BlogPosting, kurumsal sayfalarda Organization, sık sorulan sorularda FAQPage, ürün sayfalarında Product şeması kullanılabilir. Ancak eksik alanlarla veya yanıltıcı içeriklerle oluşturulan yapılandırılmış veri, fayda yerine sorun yaratabilir.

Production öncesi yapılandırılmış veri kontrolünde şu yaklaşım güvenlidir:

• Her şema türü sayfa amacıyla uyumlu olmalı.
• Zorunlu alanlar eksiksiz olmalı.
• Görsel URL'leri erişilebilir olmalı.
• Tarih, yazar ve başlık gibi alanlar içerikle tutarlı olmalı.
• Test araçlarıyla doğrulama yapılmalı.

6. Performans, Core Web Vitals ve Frontend Optimizasyonu

Yayın öncesinde yalnızca sayfanın açılması yeterli değildir, hızlı ve kararlı açılması gerekir. Performans sorunları hem kullanıcıyı hem dönüşümü hem de SEO'yu etkiler. Özellikle mobil kullanıcı oranı yüksek sitelerde ağır görseller, bloklayıcı scriptler ve gereksiz üçüncü taraf yükleri ciddi kayıplara neden olabilir.

İlk adım olarak ana şablonları performans testinden geçirin. Ana sayfa, içerik sayfası, listeleme sayfası, ürün veya hizmet detay sayfası gibi farklı şablonlarda yüklenme davranışı aynı değildir. Tek bir sayfayı test edip tüm siteyi sağlıklı kabul etmek yanıltıcı olur.

Performans checklist'i için temel başlıklar şunlardır:

• Görseller optimize edildi mi, modern formatlar kullanılıyor mu?
• Lazy loading gerekli alanlarda aktif mi?
• CSS ve JS dosyaları gereksiz yere büyük mü?
• Render-blocking kaynaklar azaltıldı mı?
• Font yüklemesi optimize edildi mi?
• Cache policy ve compression aktif mi?
• CDN gerekiyorsa yapılandırıldı mı?

Ayrıca üçüncü taraf scriptler ayrı bir dikkat alanıdır. Chat widget, harita, reklam, analytics, A/B test araçları ve izleme kodları toplam yükü ciddi biçimde artırabilir. Production öncesinde gerçekten gerekli olmayan scriptleri kaldırmak, teknik optimizasyon kadar önemli bir karardır.

Aşağıdaki metriklere özellikle odaklanın:

• LCP: Ana içeriğin hızlı görünmesi
• CLS: Sayfa açılırken elemanların kaymaması
• INP veya etkileşim gecikmesi: Buton, menü ve form etkileşimlerinin akıcı olması
• TTFB: Sunucu yanıt süresinin makul seviyede kalması

7. Responsive Design, Accessibility ve Kullanıcı Deneyimi Testleri

Bir site masaüstünde düzgün görünse bile production için hazır sayılmaz. Farklı ekran boyutları, cihaz türleri ve erişilebilirlik ihtiyaçları canlı ortamdaki gerçek kullanımın temelini oluşturur. Bu nedenle responsive tasarım ile accessibility testleri release checklist içinde mutlaka yer almalıdır.

Responsive tarafta yalnızca ekranın küçülmesini değil, içerik düzeninin gerçekten kullanılabilir kalmasını test edin. Menü açılıyor mu, tablolar taşma yapıyor mu, CTA butonları görünür mü, formlar mobilde rahat dolduruluyor mu gibi sorular doğrudan dönüşüm performansını etkiler. Özellikle hero alanları, kart yapıları, slider'lar ve popup bileşenleri mobil cihazlarda ayrıca incelenmelidir.

Erişilebilirlik kontrolünde temel maddeler şunlardır:

• Renk kontrastı yeterli mi?
• Form alanlarının label yapısı doğru mu?
• Klavye ile gezinme mümkün mü?
• Focus durumları görünür mü?
• Görsellere anlamlı alt metin eklenmiş mi?
• Buton ve link metinleri açıklayıcı mı?
• Başlık hiyerarşisi mantıklı mı?

Accessibility yalnızca yasal veya etik bir konu değildir, aynı zamanda kullanılabilirlik kalitesinin de göstergesidir. Ekran okuyucu kullanıcıları düşünülerek kurulan yapı çoğu zaman genel kullanıcı deneyimini de iyileştirir. Özellikle açılır menüler, modallar ve hata mesajları erişilebilirlik açısından sık hata yapılan alanlardır.

Mobil testlerde gerçek cihazlarla kontrol yapmak çok değerlidir. Emülatörler faydalıdır ancak gerçek dokunmatik davranış, klavye açılması, viewport hesaplaması ve performans hissi ancak gerçek cihaz testlerinde netleşir. En azından iPhone, Android ve yaygın masaüstü tarayıcı kombinasyonlarında temel sayfalar gözden geçirilmelidir.

8. Formlar, Dönüşüm Akışları ve Veri Doğrulama

Production'a alınan birçok sitede en kritik hata, kullanıcı form göndermeye çalıştığında ortaya çıkar. Tasarım doğru görünse de e-posta teslimatı bozuk olabilir, doğrulama çalışmayabilir veya form başarı mesajı yanlış akışa bağlanmış olabilir. Bu yüzden tüm dönüşüm noktaları gerçek senaryolarla test edilmelidir.

İletişim formu, teklif formu, üyelik formu, bülten aboneliği, ödeme öncesi adımlar veya demo talebi gibi tüm akışlar tek tek kontrol edilmelidir. Sadece ön yüz davranışını değil, arka planda verinin nereye düştüğünü de doğrulamak gerekir. Form gönderildiğinde CRM, e-posta kutusu, veritabanı veya webhook gibi hedeflerin tamamı çalışıyor olmalıdır.

Form kontrollerinde şu maddeler önemlidir:

• Zorunlu alanlar doğru çalışıyor mu?
• Hatalı girişlerde anlamlı hata mesajı veriliyor mu?
• Başarılı gönderimde kullanıcı net geri bildirim alıyor mu?
• Çift tıklama veya tekrar gönderim önleniyor mu?
• Spam koruması aktif mi?
• E-posta bildirimleri doğru adrese gidiyor mu?
• KVKK, gizlilik ve onay kutuları gerekiyorsa kayıt altına alınıyor mu?

Ayrıca form güvenliği de unutulmamalıdır. Sunucu tarafı doğrulama, rate limiting, CSRF koruması ve bot önleme mekanizmaları özellikle kamuya açık formlarda gereklidir. Eğer dosya yükleme özelliği varsa izin verilen formatlar, boyut limitleri ve güvenlik filtreleri ayrıca test edilmelidir.

Dönüşüm akışlarını tekil form testleriyle sınırlamayın. Teşekkür sayfası, yönlendirme sonrası analytics event'i, e-posta otomasyonu ve satış ekibine bildirim zinciri de birlikte çalışmalıdır. Aksi halde form çalışıyor görünür ama iş akışı kırık kalır.

9. Analytics, Search Console, Logging ve Operasyonel İzleme

Production sonrası ne olduğunu görmeyen ekipler, sorunları genellikle kullanıcı şikayet ettiğinde fark eder. Bu nedenle canlıya çıkmadan önce ölçümleme ve izleme altyapısının hazır olması gerekir. Analytics ve Search Console görünürlük sağlarken, logging ve hata izleme teknik tarafta erken uyarı sistemi işlevi görür.

Öncelikle analytics kurulumunun doğru property ve doğru ortamda çalıştığını doğrulayın. Staging trafiklerinin production verisini kirletmemesi önemlidir. Sayfa görüntüleme dışında form gönderimi, telefon tıklaması, CTA etkileşimi veya satın alma adımları gibi kritik event'ler de test edilmelidir.

Bu bölüm için checklist:

• Analytics kodu production'da doğru yüklendi mi?
• Consent mode veya çerez yönetimi gerekiyorsa düzgün çalışıyor mu?
• Önemli event'ler tetikleniyor mu?
• Search Console mülkü doğrulandı mı?
• Sitemap Search Console'a gönderilmeye hazır mı?
• Sunucu ve uygulama logları tutuluyor mu?
• 4xx ve 5xx hataları izlenebiliyor mu?
• Uptime takibi ve alarm sistemi kurulu mu?

Logging tarafında yalnızca hata kaydetmek yeterli değildir, anlamlı bağlam da gerekir. İstek yolu, kullanıcı ajanı, hata türü, timestamp ve gerekiyorsa request ID gibi alanlar teşhis süresini ciddi biçimde kısaltır. Özellikle form hataları, API time-out sorunları ve beklenmeyen redirect davranışları loglar üzerinden hızlı tespit edilir.

Search Console için de production öncesi hazırlık yapmak büyük avantaj sağlar. Domain property veya URL prefix property seçimi, doğrulama yöntemi ve ilk sitemap gönderimi planlı şekilde ilerlemelidir. Site yayına çıkar çıkmaz performans ve kapsama raporlarını izlemeye başlamak, erken SEO sorunlarını yakalamayı kolaylaştırır.

10. Backup, Error Pages ve Son Yayın Onayı

Yayına almadan önce her ekip kendine şu soruyu sormalıdır: Bir şey ters giderse ne kadar hızlı geri dönebiliriz? Teknik release sürecinin olgunluğu, yalnızca sorunsuz yayına çıkmakla değil, sorun durumunda kontrollü geri dönüş yapabilmekle ölçülür. Bu nedenle backup, rollback ve hata sayfası kurgusu checklist'in son ama en kritik bölümüdür.

Öncelikle dosya ve veritabanı yedekleme stratejisi net olmalıdır. Otomatik backup sıklığı, saklama süresi ve geri yükleme prosedürü belgelendirilmelidir. Sadece yedek alınıyor olması yeterli değildir, gerektiğinde gerçekten restore edilebildiği de doğrulanmalıdır.

Son aşamada şu maddeler tek tek işaretlenmelidir:

• Production öncesi güncel backup alındı mı?
• Rollback planı yazılı ve uygulanabilir mi?
• 404 ve 500 hata sayfaları tasarlandı mı?
• Hata sayfaları kullanıcıyı yönlendirecek bağlantılar içeriyor mu?
• Sunucu bakım modu gerekiyorsa kontrollü kullanılabiliyor mu?
• Kritik erişim bilgileri güvenli şekilde saklanıyor mu?
• Yayın sonrası kontrol edecek sorumlu ekip net mi?

Error page tasarımı teknik kadar iletişimsel bir konudur. Kullanıcıya yalnızca hata göstermek yerine ana sayfaya dönüş, arama yapma veya iletişime geçme seçenekleri sunmak gerekir. Özellikle 404 sayfası, yanlış yönlendirilmiş veya silinmiş URL trafiğini tamamen kaybetmemek için fırsata dönüştürülebilir.

Son yayın onayında mümkünse aşağıdaki mini akışı kullanın:

1. Ana sayfa ve kritik sayfalar canlı domainde açılıyor mu?
2. HTTPS, canonical, metadata ve index ayarları tekrar kontrol edildi mi?
3. Formlar ve dönüşüm event'leri gerçek veriyle test edildi mi?
4. Analytics, Search Console ve loglar veri toplamaya başladı mı?
5. Yedek ve rollback planı teyit edildi mi?

Pratik Kullanım İçin Kısa Teknik Release Checklist

Aşağıdaki listeyi production öncesi hızlı kontrol dokümanı olarak kullanabilirsiniz:

• DNS kayıtları ve domain yönlendirmeleri doğru
• SSL aktif, HTTP > HTTPS yönlendirmesi tamam
• www ve non-www standardı net
• Redirect kuralları 301 mantığıyla test edildi
• Canonical etiketleri doğru
• robots.txt production için uygun
• XML sitemap erişilebilir ve temiz
• Title, description, H1 ve OG alanları kontrol edildi
• Structured data doğrulandı
• Performans testleri yapıldı
• Mobil uyumluluk ve responsive kontroller tamam
• Accessibility temel gereksinimleri sağlandı
• Formlar uçtan uca test edildi
• Analytics ve event ölçümleri çalışıyor
• Search Console mülkü hazır
• Logging, uptime ve hata takibi açık
• Backup alındı, rollback planı hazır
• 404 ve 500 sayfaları çalışıyor

Sonuç

Production öncesi teknik kontroller, yayına çıkış sürecini yalnızca daha güvenli hale getirmez, aynı zamanda SEO görünürlüğünü, kullanıcı deneyimini ve operasyonel sürdürülebilirliği de korur. Özellikle geliştiriciler, ajanslar ve site yöneticileri için yazılı bir release checklist kullanmak, ekip bağımlılığını azaltır ve tekrar edilebilir kalite standardı oluşturur.

Eğer web sitesi yayın süreçlerinizi daha sistemli hale getirmek, teknik yükü azaltmak ve büyüdükçe geliştirilebilir bir yapı üzerinde ilerlemek istiyorsanız, yayın öncesi checklist yaklaşımını standart operasyonunuzun parçası haline getirin. Hazır web sitesi, yönetim paneli, yayın altyapısı ve geliştirilebilir dijital çözüm ihtiyaçlarında süreç odaklı hareket etmek, canlıya geçişte fark yaratan en önemli unsurlardan biridir.