Production Deploy Sonrası Domain, DNS, HTTPS ve Canlıya Geçiş Süreci

Bir web sitesinin geliştirme süreci tamamlandığında iş bitmiş sayılmaz. Asıl kritik aşama, uygulamanın production ortama alınması, gerçek domain ile bağlanması ve kullanıcıların sorunsuz erişebileceği şekilde yayına açılmasıdır. Bu aşamada DNS kayıtları, SSL sertifikası, yönlendirmeler, önbellek davranışı ve temel canlı testleri doğru yönetilmezse çok iyi hazırlanmış bir site bile erişim, güvenlik veya SEO sorunları yaşayabilir.

Bu rehberde production deploy sonrası izlenmesi gereken süreci baştan sona anlatacağız. Hem kendi sunucusunu yöneten geliştiriciler hem de Pratikweb benzeri yönetilen altyapılar üzerinden yayın yapan kullanıcılar için anlaşılır, teknik ama uygulanabilir bir yol haritası sunacağız.

Production deploy sonrası genel akış nasıl ilerler?

Production yayına geçiş, sadece dosyaları sunucuya yüklemekten ibaret değildir. Uygulamanın production build'inin alınması, sunucu veya platform üzerinde ayağa kaldırılması, domainin bu yayına yönlendirilmesi, HTTPS sertifikasının üretilmesi ve son olarak canlı kontrollerin yapılması gerekir. Bu zincirin herhangi bir halkası eksik kalırsa kullanıcı siteyi açamayabilir, tarayıcı güvenlik uyarısı verebilir veya arama motorları yanlış URL'leri indeksleyebilir.

Genel olarak süreç şu sırayla ilerler: önce production ortamı hazırlanır, ardından domain DNS kayıtları doğru hedefe yönlendirilir, DNS çözümlemesinin tamamlanması beklenir, HTTPS sertifikası tanımlanır ve doğrulanır, yönlendirmeler ayarlanır, smoke test yapılır ve sonra canlı trafik resmen yeni siteye bırakılır. Bu sıralama önemlidir çünkü örneğin DNS doğru çözülmeden sertifika üretimi başarısız olabilir ya da yönlendirmeler netleşmeden canonical yapı bozulabilir.

Pratikweb gibi yönetilen yapılarda kullanıcı çoğu zaman hosting, reverse proxy, yayın altyapısı veya servis orkestrasyonu ile uğraşmaz. Ancak domain genellikle kullanıcıya ait olduğundan, DNS tarafında hangi kayıtların girileceğini doğru anlaması gerekir. Teknik ekip altyapıyı yönetirken müşteri ya da proje sahibi genellikle registrar panelinden domaini bağlama işini tamamlar.

Domain bağlama mantığı: domain kime ait, yayın altyapısı kimde?

Canlıya geçişte en çok karıştırılan konulardan biri, domain sahipliği ile yayın altyapısının aynı şey olmadığını fark etmemektir. Domain, yani alan adı, çoğunlukla müşteri tarafından bir domain kayıt firmasından satın alınır ve yönetilir. Web sitesinin çalıştığı sunucu, platform veya servis altyapısı ise çoğu durumda başka bir sağlayıcı tarafından barındırılır.

Bu ayrım önemlidir çünkü bir siteyi yayına almak için genellikle domain panelinde işlem yapılırken, web sitesinin sunulduğu ortamda da ilgili domainin tanımlanmış olması gerekir. Yani yalnızca DNS kaydı eklemek yeterli değildir. Hedef platformun da bu domain üzerinden gelen isteği kabul edecek şekilde yapılandırılmış olması gerekir.

Pratikweb bağlamında düşünüldüğünde, domain müşteriye ait olabilir ama sitenin yayını, barındırılması ve çalıştırılması servis sağlayıcı tarafından yürütülür. Böyle bir modelde kullanıcı, domain tarafında gerekli A kaydı, CNAME veya nameserver değişikliklerini yapar; altyapı tarafı ise gelen trafiği doğru projeye yönlendirir, sertifikayı üretir ve yayını güvenli hale getirir.

Canlıya geçmeden önce netleştirilmesi gerekenler

Canlı geçiş öncesinde şu soruların yanıtı kesin olmalıdır:

• Ana domain hangisi olacak:
  Copy

  example.com
  mu,
  Copy

  www.example.com
  mu?
• DNS hangi panelden yönetiliyor?
• Site IP adresine mi, load balancer'a mı, platform hostname'ine mi bağlanacak?
• SSL sertifikası otomatik mi üretilecek, manuel mi yüklenecek?
• E-posta hizmeti aynı domain üzerinden çalışıyor mu?
• Eski siteden yeni siteye yönlendirme gerekecek mi?

Bu bilgiler net değilse, geçiş sırasında kesinti yaşanması çok olasıdır. Özellikle e-posta için mevcut MX kayıtlarının yanlışlıkla silinmesi sık görülen bir hatadır.

DNS kayıtlarının yapılandırılması: A, AAAA, CNAME ve diğer kayıtlar

DNS, bir domain adını teknik hedefe çeviren dağıtık bir çözümleme sistemidir. Kullanıcı tarayıcıya alan adını yazar, DNS ise bu alan adının hangi IP'ye veya hangi hedef hostname'e gitmesi gerektiğini söyler. Bu nedenle production deploy sonrası ilk pratik adımlardan biri, doğru DNS kayıtlarını oluşturmaktır.

En yaygın kayıt türü A kaydıdır. A kaydı, bir domaini IPv4 adresine yönlendirir. Eğer sunucunuzun sabit bir IPv4 adresi varsa,

için A kaydı girilir. IPv6 kullanılıyorsa AAAA kaydı da eklenebilir. Eğer platform size doğrudan IP değil de bir hedef alan adı veriyorsa, özellikle alt alan adı için CNAME kaydı kullanılır.

Sık kullanılan DNS kayıtları

Kayıt Türü	Ne İşe Yarar	Örnek Kullanım
A	Domaini IPv4 adresine yönlendirir	Copy example.com -> 203.0.113.10
AAAA	Domaini IPv6 adresine yönlendirir	Copy example.com -> 2001:db8::10
CNAME	Bir alan adını başka bir alan adına yönlendirir	Copy www -> app.hostplatform.com
MX	E-posta sunucularını tanımlar	Google Workspace, Microsoft 365
TXT	Doğrulama, SPF, DKIM gibi metinsel kayıtlar	SSL, mail, servis doğrulama
NS	Domainin hangi DNS sunucularında yönetildiğini belirler	Cloudflare, registrar DNS

Apex domain olarak da bilinen kök domain için bazı sağlayıcılarda doğrudan CNAME kullanılamaz. Bu durumda ya A kaydı gerekir ya da DNS sağlayıcınız ALIAS, ANAME veya CNAME flattening benzeri bir özellik sunar. Kullanılan servis bu detayı net şekilde dokümante etmelidir.

ve kök domain için ayrı kayıtlar gerektiği unutulmamalıdır. Sadece için kayıt ekleyip 'u boş bırakırsanız, kullanıcıların bir kısmı siteye erişebilirken diğerleri hata alır. Aynı şekilde sadece çalışıyor ama çıplak domain çalışmıyorsa hem kullanıcı deneyimi hem SEO açısından gereksiz parçalanma oluşur.

TTL değeri neden önemlidir?

TTL, yani time to live, DNS kaydının ara sunucularda ne kadar süre önbellekte tutulacağını belirler. Geçiş öncesi planlı çalışıyorsanız, DNS değişikliğinden birkaç saat veya bir gün önce TTL değerini düşürmek mantıklı olabilir. Böylece değişiklik yapıldığında eski kayıtların cache'te uzun süre kalma olasılığı azalır.

Ancak TTL değeri düşük olsa bile internetin her noktasında değişiklik aynı anda görünmez. DNS propagation denen süreç, farklı resolver'ların güncel kaydı farklı hızlarda alması nedeniyle zamana yayılır. Bu yüzden değişiklik sonrası bazı kullanıcılarda yeni site açılırken bazılarında eski IP çözülmeye devam edebilir.

DNS resolution ve propagation süreci nasıl çalışır?

DNS kaydını girdikten sonra en sık gelen soru şudur: Neden ben kaydı ekledim ama site hemen açılmadı? Bunun sebebi DNS resolution sürecinin katmanlı olmasıdır. Tarayıcı, işletim sistemi, modem, ISS DNS önbelleği ve global resolver'lar devreye girer. Her katman güncel kaydı farklı anda görür.

Resolution, alan adının DNS sunucularında sorgulanıp nihai IP veya hedefe çözümlenmesidir. Propagation ise bu güncellenmiş sonucun internete yayılma sürecidir. Teknik olarak authoritative DNS sunucunuz güncelse bile, dünyanın farklı yerlerindeki resolver'lar bir süre daha eski cevabı döndürebilir.

DNS doğrulamak için kullanılabilecek yöntemler

Canlı geçişte tahmine göre hareket edilmemelidir. DNS'in gerçekten doğru çözümlendiği araçlarla kontrol edilmelidir.

• Copy

  dig example.com
• Copy

  dig www.example.com
• Copy

  nslookup example.com
• Copy

  ping
  yalnızca temel IP görünürlüğü için
• çevrim içi global DNS checker araçları
• tarayıcı geliştirici araçları ve farklı ağlardan test

Buradaki amaç sadece kayıt var mı diye bakmak değil, beklenen hedefe çözülüyor mu sorusunu doğrulamaktır. Örneğin

CNAME kaydı platform hostname'ine gitmeli, apex domain A kaydı doğru IP'yi dönmelidir. Yanlış bir IP'ye çözülme varsa site ya açılmaz ya da başka projeye düşebilir.

DNS kaynaklı tipik problemler

DNS tarafında yaşanan hatalar genellikle şu başlıklarda toplanır:

• yanlış IP girilmesi
• Copy

  www
  kaydının unutulması
• apex ve
  Copy

  www
  için farklı sistemlerin hedeflenmesi
• nameserver değişmiş ama kayıtların yeni DNS sağlayıcısında oluşturulmamış olması
• proxy veya CDN katmanının yanlış aktif edilmesi
• mail kayıtlarının web değişikliği sırasında silinmesi

Bu yüzden DNS panelinde değişiklik yapmadan önce mevcut kayıtların ekran görüntüsü veya yedeği alınmalıdır. Özellikle çalışan bir domain üzerinde işlem yapılıyorsa geri dönüş planı hazır olmalıdır.

HTTPS certificate issuance: SSL sertifikası üretimi ve doğrulama

DNS doğru çalışmaya başladığında sıradaki temel adım HTTPS sertifikasının aktif edilmesidir. Modern web'de HTTPS artık opsiyonel değil, zorunlu kabul edilir. Tarayıcı güveni, veri şifreleme, SEO sinyalleri ve birçok üçüncü parti entegrasyon için geçerli bir SSL sertifikası gerekir.

Sertifika üretimi çoğu modern platformda otomatik yapılır. Genellikle Let's Encrypt benzeri bir servis kullanılır ve alan adının gerçekten sizin uygulamanıza yönlendiği doğrulanınca sertifika issue edilir. Ancak bunun çalışabilmesi için domainin ilgili platforma çözülmesi ve platformun da bu domaini kendi sisteminde tanımış olması gerekir.

Eğer sertifika üretimi manuel yapılıyorsa süreç daha uzundur. CSR oluşturulur, alan adı doğrulaması yapılır, sertifika ve ara sertifikalar yüklenir. Yönetilen yapılarda ise kullanıcıdan beklenen iş çoğunlukla sadece domaini doğru yönlendirmek ve gerekirse doğrulama kaydı eklemektir.

Sertifika neden üretilmeyebilir?

Aşağıdaki nedenler sertifika üretimini engelleyebilir:

• DNS hâlâ yanlış hedefe çözülüyor olabilir.
• Domain platforma eklenmemiş olabilir.
• Copy

  www
  ve apex için ayrı doğrulama gerekiyordur.
• CDN veya proxy katmanı doğrulama isteğini bozuyor olabilir.
• DNS propagation henüz tamamlanmamıştır.
• Rate limit nedeniyle kısa sürede çok sık sertifika denemesi yapılmıştır.

Bu aşamada sabırlı olmak kadar sistematik kontrol de önemlidir. Önce DNS doğrulanmalı, sonra platformda domain bağlı mı bakılmalı, ardından sertifika logları veya panel uyarıları incelenmelidir.

HTTPS sonrası kontrol edilmesi gerekenler

Sadece kilit simgesini görmek yeterli değildir. Canlıya geçmeden şu kontroller yapılmalıdır:

• Copy

  https://example.com
  açılıyor mu?
• Copy

  https://www.example.com
  açılıyor mu?
• Sertifika doğru domain adlarını kapsıyor mu?
• Sertifika süresi ve issuer bilgisi doğru mu?
• Mixed content hatası var mı?
• HTTP'den HTTPS'ye yönlendirme çalışıyor mu?

Özellikle mixed content sorunu, yani HTTPS sayfada HTTP ile çağrılan görsel, script veya font dosyaları, sayfanın güvenli görünmesini bozabilir. Bu yüzden asset URL'leri de production geçişte gözden geçirilmelidir.

Redirects: www, non-www, HTTP ve eski URL yönlendirmeleri

Canlıya geçişte yönlendirmeler yalnızca kullanıcı konforu için değil, SEO bütünlüğü için de kritik önemdedir. Aynı içeriğin hem HTTP hem HTTPS, hem

hem de versiyonlarında açılması kopya içerik ve otorite bölünmesi sorunlarına yol açabilir. Bu nedenle tek bir canonical sürüm seçilmeli ve diğer tüm varyasyonlar kalıcı yönlendirme ile ona taşınmalıdır.

En yaygın tercih ya

ya da şeklinde tek sürüm belirlemektir. Hangi yapı seçilirse seçilsin, diğer versiyonlar 301 redirect ile ana sürüme gitmelidir. Ayrıca geçici yönlendirme yerine kalıcı yönlendirme kullanılması arama motorlarına net sinyal verir.

Yönlendirme matrisi örneği

Gelen URL	Gitmesi Gereken URL
Copy http://example.com	Copy https://example.com
Copy http://www.example.com	Copy https://example.com
Copy https://www.example.com	Copy https://example.com
eski sayfa URL'leri	yeni karşılık gelen URL'ler

Eski siteden yeni siteye geçiliyorsa URL yapısındaki değişiklikler de ayrıca planlanmalıdır. Örneğin eski sitede

olan yapı yeni sitede ise uygun redirect tanımlanmalıdır. Aksi halde kullanıcılar 404 alır, arama motorunda geçmişten gelen değer kaybedilir.

Redirect testinde dikkat edilmesi gerekenler

Yönlendirme kurgusunda en kritik konu zincir ve döngü hatalarıdır. Bir URL önce HTTP'den HTTPS'ye, sonra

'den apex'e, sonra trailing slash kuralına giriyorsa gereksiz çok adımlı redirect oluşabilir. Bu hem performansı düşürür hem bot taramasını verimsiz hale getirir.

İdeal senaryoda her varyasyon tek adımda canonical URL'ye ulaşmalıdır. Yani kullanıcı hangi sürümü yazarsa yazsın, mümkün olan en kısa yoldan tek nihai adrese gitmelidir. Bunu geliştirici araçlarında network sekmesinden veya komut satırıyla header inceleyerek doğrulamak gerekir.

Smoke test: canlıya çıkmadan önce yapılacak temel kontroller

Smoke test, sistemin en kritik fonksiyonlarının temel seviyede çalıştığını hızlıca doğrulayan test setidir. Amaç tüm detayları test etmek değil, sitenin canlı trafik almaya uygun olup olmadığını anlamaktır. Bu aşama atlanırsa fark edilmesi kolay ama etkisi büyük hatalar doğrudan kullanıcıya yansır.

Bir smoke test listesi hem teknik kontrolleri hem kullanıcı akışlarını kapsamalıdır. Özellikle production ortamı, staging'den farklı değişkenlere, gerçek entegrasyonlara ve gerçek domain davranışına sahip olduğu için son kontrol çok değerlidir.

Örnek smoke test checklist'i

• Ana sayfa açılıyor mu?
• Mobil ve masaüstü görünüm temel olarak düzgün mü?
• Menü ve temel sayfalar çalışıyor mu?
• İletişim formu gönderiliyor mu?
• Giriş yapılabiliyorsa login akışı çalışıyor mu?
• Kritik butonlar doğru sayfalara gidiyor mu?
• 404 sayfası düzgün dönüyor mu?
• favicon, logo, görseller ve fontlar yükleniyor mu?
• analytics, tag manager veya piksel entegrasyonları aktif mi?
• robots.txt ve sitemap.xml doğru mu?

E-ticaret veya daha karmaşık platformlarda buna ürün detay, sepet, ödeme öncesi akış, kullanıcı kaydı, şifre sıfırlama ve e-posta tetiklemeleri de eklenmelidir. Site türü ne kadar karmaşıksa smoke test de o kadar senaryolu hale gelmelidir.

Teknik smoke test kontrolleri

Kullanıcı odaklı akışların yanında teknik başlıklar da kontrol edilmelidir:

• Sunucu 200, 301, 404 gibi durum kodlarını doğru dönüyor mu?
• Console'da ciddi JavaScript hatası var mı?
• API istekleri production endpoint'lerine gidiyor mu?
• CORS veya cookie sorunları var mı?
• Cache temizliği sonrası da site açılıyor mu?
• CDN cache yanlış içerik sunuyor mu?
• Performans temel seviyede kabul edilebilir mi?

Smoke test sırasında ekran görüntüsü almak ve bulguları bir kontrol listesinde işaretlemek iyi pratiktir. Böylece yayına alma kararı sezgisel değil, doğrulanmış adımlara göre verilir.

Canlıya geçiş stratejisi: risksiz launch nasıl planlanır?

Canlıya geçiş sadece teknik bir işlem değil, aynı zamanda operasyonel bir geçiştir. Trafiğin düşük olduğu saatleri seçmek, ekipte sorumlu kişileri belirlemek ve geri dönüş planı hazırlamak gerekir. Özellikle mevcut çalışan bir sitenin yerine yeni sürüm geçiyorsa, geri alma senaryosu en az ileri alma kadar önemlidir.

İyi bir launch planı, hangi saatte DNS değişeceğini, sertifika kontrolünün kim tarafından yapılacağını, smoke test'i kimin tamamlayacağını ve sorun çıkarsa eski sisteme nasıl dönüleceğini içerir. Bu plan yazılı değilse, geçiş sırasında herkes farklı varsayımla hareket eder ve çözüm süresi uzar.

Aşamalı canlı geçiş yaklaşımı

Mümkünse canlıya geçiş tek bir büyük sıçrama yerine kontrollü yapılmalıdır. Önce production sistem hazır hale getirilir, sonra domain bağlantısı yapılır, ardından temel kontroller tamamlanır ve ancak ondan sonra resmi duyuru veya trafik yönlendirmesi yapılır. Bazı durumlarda önce sınırlı kullanıcı grubuna test açmak da faydalıdır.

Kurumsal projelerde şu yaklaşım güvenli sonuç verir:

1. Production build ve ortam değişkenleri doğrulanır.
2. Domain hedefi ve DNS planı kesinleştirilir.
3. DNS değişikliği uygulanır.
4. Resolution farklı ağlardan doğrulanır.
5. SSL sertifikası aktifleşir.
6. Redirect kuralları test edilir.
7. Smoke test tamamlanır.
8. İzleme ve log takibi başlatılır.
9. Resmi canlıya geçiş onayı verilir.

Bu sıralama küçük projelerde bile işleri temiz tutar. Özellikle ekipli çalışmalarda kimin hangi adımı onayladığı netleşmiş olur.

Yönetilen altyapılarda süreç neden daha kolaydır?

Kendi sunucunuzu yönettiğiniz senaryoda DNS, reverse proxy, SSL otomasyonu, log takibi, güvenlik başlıkları ve uptime yönetimi gibi birçok teknik detayı ayrı ayrı çözmeniz gerekir. Bu esneklik sağlar ama hataya açıklığı da artırır. Özellikle web yayın süreçlerine sık girmeyen işletmeler için bu yapı operasyonel yük oluşturur.

Pratikweb benzeri yönetilen çözümlerde ise domain müşteriye ait olsa bile yayın altyapısı servis sağlayıcı tarafından işletilir. Böylece kullanıcı ağırlıklı olarak domain panelindeki gerekli DNS kayıtlarını girmekle ilgilenir. Platform tarafı ise sitenin çalıştırılması, barındırılması, çoğu durumda sertifika süreçleri ve teknik yayın tarafını üstlenir.

Bu modelin önemli avantajı, teknik karmaşıklığın azaltılmasıdır. Ayrıca ihtiyaç büyüdükçe yalnızca tanıtım sitesi değil, e-ticaret, ilan veya özel servis birleşimlerinden oluşan daha gelişmiş yapılar da aynı yaklaşım içinde yayınlanabilir. Domain bağlama mantığı benzer kalırken arka plandaki servis yapısı daha esnek şekilde ölçeklenebilir.

Sık yapılan hatalar ve en iyi uygulamalar

Canlıya geçişte sorunların büyük bölümü ileri seviye teknik zorluklardan değil, temel eksiklerden kaynaklanır. Yanlış DNS kaydı, unutulan

, hatalı redirect, eksik sertifika veya test yapılmadan yayına çıkmak en yaygın örneklerdir. Bu nedenle iyi uygulamalar listesi, karmaşık bilgiden daha değerlidir.

Aşağıdaki prensipler çoğu projede güvenli sonuç verir:

• Geçişten önce mevcut DNS kayıtlarını yedekleyin.
• Canonical domain kararını en başta verin.
• Copy

  www
  , apex, HTTP ve HTTPS varyasyonlarını tek tek test edin.
• Sertifika aktif olmadan siteyi resmen duyurmayın.
• TTL düşürme planını geçişten önce yapın.
• Mail kayıtlarını web değişikliği sırasında koruyun.
• Smoke test'i yazılı checklist ile uygulayın.
• Gerekirse rollback planı hazırlayın.
• Search Console ve analytics tarafını canlıya geçişten sonra doğrulayın.

Özellikle SEO açısından robots.txt, sitemap.xml, canonical etiketleri, noindex ayarları ve redirect kuralları launch sonrası ilk kontrolde ele alınmalıdır. Staging ortamında kullanılan geçici engellemelerin production'a taşınması çok ciddi görünürlük kaybına neden olabilir.

Sonuç: doğru yayın süreci, sorunsuz ilk izlenim demektir

Production deploy sonrası domain bağlama ve canlıya geçiş süreci, web sitesinin dış dünyayla ilk gerçek temasıdır. Bu aşamayı planlı yürütmek, yalnızca sitenin açılmasını sağlamakla kalmaz; güven, hız, erişilebilirlik ve SEO performansını da doğrudan etkiler. Doğru DNS kayıtları, sağlıklı resolution, geçerli HTTPS sertifikası, temiz yönlendirmeler ve disiplinli smoke test birlikte çalıştığında launch süreci çok daha güvenli hale gelir.

Eğer teknik detaylarla uğraşmak istemiyor ama sitenizin profesyonel biçimde yayına alınmasını istiyorsanız, yönetilen bir yapıdan destek almak önemli avantaj sağlar. Özellikle domain sizde kalsa bile yayın altyapısının uzman ekip tarafından yönetilmesi, hata riskini azaltır ve büyüme aşamasında daha esnek ilerlemenize yardımcı olur. Canlıya geçmeden önce adımları kontrol listesi halinde uygulayın, gerekiyorsa teknik ekiple eş zamanlı ilerleyin ve ilk gün deneyimini şansa bırakmayın.