Yeni Site İçin Hosting, SEO ve Performans Kontrol Listesi

Yeni Siteyi Yayına Almadan Önce Hosting Taraflı Bir Check‑list Neden Gerekli?

Yeni bir web sitesini yayına almak, sadece tasarım ve içerik tarafında işi bitirdiğiniz anlamına gelmez. Hosting altyapısında yaptığınız ayarlar da erişilebilirliği ve performansı etkiler. Arama motorlarının sitenizi nasıl taradığı, kullanıcılar için sayfaların ne kadar hızlı açıldığı, hatta kampanya dönemlerinde sitenin çöküp çökmediği; DNS’ten SSL’e, PHP sürümünden önbelleğe kadar onlarca küçük detaya bağlıdır.

DNS, sertifika ve yönlendirme hataları gibi sorunlar yayın öncesi yapılabilecek kontrollerle tespit edilebilir. Bu yazıda, yeni sitenizi yayına almadan hemen önce hosting tarafında üzerinden geçmeniz gereken SEO ve performans odaklı pratik bir kontrol listesini adım adım anlatacağız. DNS ayarlarından HTTP/HTTPS yönlendirmelerine, Core Web Vitals metriklerinden CDN ve log takibine kadar her önemli başlık için uygulanabilir maddeleri toparladık. Yazıyı bitirdiğinizde, elinizde doğrudan kullanabileceğiniz somut bir check‑list olacak.

1. DNS ve Alan Adı Katmanı

Her şeyin temeli DNS. Arama motorlarının ve kullanıcıların sitenizi bulabilmesi için DNS’in temiz, hızlı ve tutarlı çalışması gerekiyor. Yayına almadan önce şu maddeleri kontrol edin:

1.1. Doğru A/AAAA ve CNAME Kayıtları

İlk kontrol, alan adının doğru sunucuya çözülmesidir.

• A kaydı: Alan adınızın (örneğin example.com) doğru IPv4 adrese işaret ettiğinden emin olun.
• AAAA kaydı: IPv6 kullanıyorsanız, AAAA kaydının doğru IP’ye gittiğini kontrol edin.
• www kaydı: www.example.com için A/AAAA kayıtlarını doğru IP adreslerine veya CNAME kaydını uygun hedef alan adına yöneltin. DNS kaydı HTTP yönlendirmesi yapmaz; www’lu ve www’suz adresler arasındaki yönlendirmeyi web sunucusunda ya da uygulamada ayrıca tanımlayın.

DNS kavramlarına hâkim değilseniz, A, AAAA, CNAME, MX, TXT gibi kayıtları DNS kayıtlarının ne anlama geldiğini detaylı anlattığımız rehber üzerinden hızlıca gözden geçirmenizi öneririz.

1.2. TTL Değerleri ve Yayına Alma Stratejisi

Yeni siteyi yayına alırken DNS yayılımı kabus olmak zorunda değil.

• Yayına almadan önce TTL’i (örneğin 3600 → 300 saniye gibi) düşük bir değere indirin. Bunu genellikle 24‑48 saat önce planlayabilirsiniz; ancak geçişten önce eski TTL süresinin dolmasına zaman tanıyın.
• Cutover (yayına geçiş) tamamlandıktan ve her şey stabil olduktan sonra TTL’i yeniden daha yüksek ve mantıklı bir değere (ör. 3600‑7200) çekin.

Bu hazırlık, geçiş sırasında eski sunucuya giden isteklerin süresini azaltabilir; TTL’i düşürmek mevcut DNS önbelleklerini anında temizlemez.

1.3. NS ve Registrar Erişimi

Yeni siteniz için kimin DNS yönettiği net olmalı:

• Alan adınızın NS (nameserver) kayıtlarının, gerçekten kullanmak istediğiniz DNS sağlayıcısına işaret ettiğinden emin olun.
• NS değiştirdiyseniz, farklı çözümleyicilerden yanıtları gözlemleyin; birkaç saatlik gözlemi yayılımın tamamlandığının kanıtı saymayın. Geçiş süresince eski ve yeni DNS hizmetlerindeki gerekli kayıtları tutarlı tutun.
• Alan adı yönetim paneli erişimlerini (DNS, WHOIS e‑posta adresi, güvenlik kilidi vb.) şirket içinde netleştirin.

1.4. DNSSEC ve Güvenlik

DNSSEC yanlış yapılandırıldığında, DNSSEC doğrulaması yapan çözümleyicileri kullanan ziyaretçiler siteye erişemeyebilir. Henüz DNSSEC kullanmıyorsanız, yayına alma günü yerine daha sakin bir dönemde planlayın. Kullanıyorsanız:

• DNSSEC kayıtlarının (DS, KSK/ZSK anahtarları) güncel ve doğru olduğundan emin olun.
• DNS sağlayıcısını değiştirirken, üst bölgedeki DS kaydının yeni sağlayıcının DNSSEC anahtarlarıyla uyumunu kontrol edin. Eski DS kaydını koşulsuz silmek yerine, DS ve anahtar geçişini sağlayıcıların DNSSEC taşıma prosedürüne ve önbellek sürelerine göre planlayın; uyumsuzluk doğrulama yapan ağlarda erişimi kesebilir.

2. HTTP, HTTPS ve Yönlendirmeler: SEO Otoritenizi Parçalamayın

HTTPS, güvenli veri aktarımı için temel bir gerekliliktir; ancak Google’da indekslenmenin veya tüm tarayıcılarda açılmanın mutlak önkoşulu değildir. Yeni siteyi yayına alırken güvenli erişim ve tutarlı URL kullanımı için HTTP/HTTPS tarafında şu adımları uygulayın.

2.1. SSL/TLS Sertifikası ve Zincir Kontrolü

• Canlı domaine (www ve www’suz varyasyonlar dahil) geçerli bir SSL/TLS sertifikası tanımlayın.
• Sunucunun site sertifikasını ve gerekli ara sertifikaları (intermediate) sunduğundan emin olun; eksik zincir bazı istemcilerde güven hatalarına yol açabilir. CSR, sertifika talebidir ve sunulan sertifika zincirinin parçası değildir.
• Let’s Encrypt kullanıyorsanız otomatik yenilemeyi cron/ACME client ile test edin.

2.2. HTTP → HTTPS 301 Yönlendirmesi

Yönlendirmeleri yanlış kurduğunuzda hem SEO otoritesini bölmüş hem de gereksiz redirect chain’ler ile performansı düşürmüş olursunuz.

• HTTP üzerinden erişilen herkese açık sayfaları, tek adımda kalıcı 301 yönlendirme ile seçtiğiniz kanonik HTTPS adreslerine yönlendirin; URL yolunu ve gerekli sorgu parametrelerini koruyun.
• Hem example.com hem de www.example.com için sonsuz döngü oluşmadığından emin olun.
• Yönlendirme zincirlerini test edin: ideal senaryo HTTP → HTTPS (maks. 1 redirect).

2.3. www / non‑www Kararı ve Canonical Tutarlılığı

Yeni siteyi yayına almadan tek bir kanonik ana domain belirleyin (ör. https://www.example.com veya https://example.com). Ardından:

• Diğer varyasyonu (www’lu ya da www’suz) ana domaine 301 yönlendirin.
• Uygulama tarafında base URL, site URL ayarlarını kanonik domainle eşleştirin.
• SEO eklentisi veya framework üzerinden output edilen <link rel="canonical"> etiketlerini kontrol edin.

2.4. HTTP Durum Kodları: 200, 301, 404 ve 5xx

Yeni siteye geçişte kritik sayfaların yanlış HTTP kodlarıyla dönmesi, tarama ve kullanıcı deneyimi sorunlarına yol açabilir.

• Ana sayfa, kategori/ürün/blog sayfaları gibi temel URL’lerin 200 OK döndüğünü kontrol edin.
• Eski URL’lerden yeni yapıya geçiyorsanız, eski önemli URL’leri 404 yerine 301 ile yeni eşdeğer sayfalarına yönlendirin. Eşdeğeri olmayan kaldırılmış sayfalar için 404 veya 410 döndürün; bunları topluca ana sayfaya yönlendirmeyin.
• Sunucu tarafında 500, 502, 503 gibi 5xx hatalarının loglarda birikmediğinden emin olun.

HTTP kodlarının SEO ve hosting tarafında ne ifade ettiğini daha derin anlamak için HTTP durum kodları rehberimizi mutlaka inceleyin.

3. Sunucu Lokasyonu, Kaynaklar ve Kapasite Planlama

Performans ve SEO sadece yazılımdan ibaret değil; fiziksel altyapının da ciddi etkisi var. Özellikle kullanıcı kitleniz belli bir ülkede yoğunlaşmışsa, sunucu lokasyonu ve donanım kapasitesi kritik hale geliyor.

3.1. Sunucu Lokasyonu ve Hedef Kitle

Sunucunun bulunduğu ülke, özellikle ilk byte’a kadar olan süreyi (TTFB) ve gecikmeyi etkiler. Hedef kitleniz ağırlıklı olarak Türkiye’deyse, trafiği gereksiz yere yurtdışına göndermek istemezsiniz.

• Öncelikle hedef ülke(ler)i ve dilleri netleştirin.
• Sunucu lokasyonunu, ana kitlenize ağ olarak en yakın veri merkezinden seçin.
• Çok bölgeli stratejiler, CDN ve geo‑routing gibi daha gelişmiş senaryoları, trafik hacmi arttıkça planlayın.

Bu konuyu detaylı merak ediyorsanız, sunucu lokasyonunun SEO etkilerini anlattığımız rehbere de göz atabilirsiniz.

3.2. CPU, RAM ve Trafik Kapasitesi

Yeni projelerde sık yapılan hata, ya gereğinden fazla kaynakla maliyeti şişirmek ya da tam tersi, minimum kaynakla boğulan bir altyapı kurmak.

• Beklenen aylık ziyaretçi sayısı, eşzamanlı kullanıcı ve sayfa türlerini (blog, e‑ticaret, SaaS) kabaca tahmin edin.
• Uygulamanızın (WordPress, Laravel, Node.js vs.) tipik CPU ve RAM ihtiyacını not alın.
• İlk fazda biraz esnek ama mantıklı bir üst sınırla başlayın; kısa sürede tüketiyorsanız ölçekleyin.

Bu hesaplamayı daha net yapmak için hazırladığımız yeni web sitesi için CPU, RAM ve trafik ihtiyacını hesaplama rehberi üzerinden kendi senaryonuza uygun örnekleri inceleyebilirsiniz.

3.3. Hosting Türü Seçimi: Paylaşımlı, VPS, Dedicated, Colocation

Yeni bir site için her zaman devasa sunuculara gerek yok. Ancak yanlış tipte bir hostingle başlamak da uzun vadede sorun çıkarabilir.

• Paylaşımlı hosting: Küçük bloglar, kurumsal tanıtım siteleri ve ilk aşama projeler için genellikle yeterli.
• VPS: Daha esnek kaynak, özel yazılım gereksinimi, artan trafik ve özelleştirilmiş güvenlik ihtiyacı olan projeler için ideal.
• Dedicated / Colocation: Yüksek trafik, regülasyon gereksinimleri veya özel donanım ihtiyacı olan büyük projelerde mantıklı.

Proje büyüdükçe kaynak artırımı veya farklı bir hosting modeline geçiş gerekebilir; plan seçerken yükseltme seçeneklerini ve taşıma gereksinimlerini değerlendirin. Önemli olan, yayına girerken ihtiyaçlarınızı gerçekçi belirlemek ve büyüme sinyallerini yakından izlemek.

4. Core Web Vitals, TTFB ve Sunucu Tarafı Performans Ayarları

Google’ın güncel Core Web Vitals metrikleri LCP, INP ve CLS’dir. Bu metrikler sıralama sistemlerinde kullanılır; iyi puanlar üst sıraları garanti etmez. Bunların önemli bir bölümü front‑end tarafında ele alınırken, TTFB, sunucu yanıt süresi ve arka uç performansı hosting kaynakları, ağ koşulları ve uygulama tasarımından etkilenir.

4.1. TTFB’yi (Time To First Byte) Düşürmek

• PHP-FPM, Node.js veya kullandığınız uygulama sunucusunun işçi (worker) sayıları ve timeout ayarlarını gözden geçirin.
• Veritabanı sorgularını optimize edin; yavaş sorguları loglayıp indeksleri kontrol edin.
• Dinamik sayfalar için mümkün olduğu yerde tam sayfa önbellekleme (full page cache) kullanın.

Özellikle WordPress ve PHP sitelerde TTFB problemi yaşıyorsanız, yüksek TTFB sorununu çözmeye odaklanan rehberimiz size nokta atışı fikirler verecektir.

4.2. Core Web Vitals İçin Sunucu Tarafı İyileştirmeler

Core Web Vitals sadece front‑end işi değildir. Sunucu yanıtını hızlandırmak özellikle LCP iyileştirmelerini destekleyebilir; ancak INP gibi etkileşim metrikleri için tarayıcı tarafındaki işi de ayrıca incelemek gerekir.

• HTTP/2 ve mümkünse HTTP/3 desteği sağlayın; çoklu isteklerdeki etkisini gerçek sayfa yüklemeleriyle ölçün.
• Sunucu tarafında gzip veya Brotli sıkıştırma etkin olsun.
• İçeriği değiştiğinde URL’si de değişen, sürümlenmiş statik dosyalar (CSS, JS, font, görsel) için uzun süreli cache-control başlıkları tanımlayın.
• Dinamik içerikte kullanıcıya özel olmayan sayfaları uygun sürelerle tam sayfa önbelleğe alın; kişisel içerikleri, sepet ve ödeme yanıtlarını paylaşılan önbelleğin dışında tutun. Kısa TTL, kişisel yanıtların başka kullanıcılara sunulmasını önlemez.

Bu metrikleri hosting tarafında nasıl iyileştirebileceğinizi detaylı anlattığımız Core Web Vitals ve hosting altyapısı rehberi, yayına alma öncesi mutlaka göz atmanız gereken kaynaklardan biri.

4.3. PHP, Veritabanı ve Önbellek Ayarları

Yeni siteyi canlıya almadan önce aşağıdaki teknik ayarları gözden geçirin:

• PHP sürümü: Uygulamanız ve eklentilerinizle uyumlu, halen desteklenen güncel bir PHP 8.x sürümünü kullanın ve güvenlik güncellemelerini uygulayın.
• OPcache: Aktif ve doğru yapılandırılmış olduğundan emin olun (bellek, max_accelerated_files, revalidate_freq vb.).
• MySQL/MariaDB: innodb_buffer_pool_size ve bağlantı sınırlarını kullanılabilir belleğe ve ölçülen iş yüküne göre ayarlayın. Sorgu önbelleğini ortak bir ayar olarak ele almayın: MySQL 8.0.3’te sorgu önbelleği parametreleri kaldırılmıştır. MariaDB’de bu özellik derleme desteğine bağlıdır; query_cache_type ve query_cache_size ile yönetilir ve varsayılan olarak devre dışıdır. Yüksek işlem hacimli, çok çekirdekli iş yüklerinde iyi ölçeklenmediğinden genel bir hızlandırma adımı olarak etkinleştirmeyin.
• Nesne önbelleği: WordPress veya benzeri CMS kullanıyorsanız, uygulamanızın desteklediği ve ölçümlerde fayda sağladığı durumlarda Redis/Memcached ile kalıcı nesne önbelleği kurgulayın.

5. Önbellekleme, CDN ve Medya Yönetimi

Yeni bir site genelde ilk günden “çok trafik almayacak” diye düşünülür; ama en beklenmedik anda küçük bir kampanya, sosyal medya paylaşımı veya haber yayınıyla bir anda yük artabilir. Doğru önbellek ve CDN stratejisi, bu anlarda origin yükünü azaltarak sitenizin erişilebilir kalmasına yardımcı olabilir.

5.1. Sunucu Tarafı Önbellekleme

• Herkese açık statik dosyalarda, örneğin bir saatlik tazelik için cache-control: public, max-age=3600 kullanılabilir. Süreyi güncelleme sıklığına göre seçin; uzun sürelerde dosya URL’lerini sürümleyin.
• Dinamik sayfalar için tam sayfa cache (Nginx FastCGI cache, LiteSpeed Cache vb.) etkinleştirin.
• Giriş yapmış kullanıcılar, sepet sayfası, ödeme adımı gibi dinamik alanların cache dışında kaldığından emin olun.

5.2. CDN ile Statik İçeriği Uç Noktalara Taşımak

CDN, özellikle uluslararası ziyaretçi alıyorsanız içerik teslimini hızlandırabilir ve origin trafiğini azaltabilir. Toplam maliyet etkisi ise CDN ücretlerine, önbellek isabet oranına ve trafik dağılımına bağlıdır.

• Görseller, CSS, JS gibi statik içerikleri CDN üzerinden dağıtmayı planlayın.
• Origin sunucunuzdaki cache-control başlıkları ile CDN önbelleğini tutarlı yönetin.
• Önemli tasarım/güncelleme yayınlarında CDN cache’lerini kademeli veya seçici temizleyin.

Bu kavrama yabancıysanız, önce CDN nedir ve web siteniz için avantajları nelerdir sorusuna yanıt verdiğimiz yazıya göz atmanız iyi bir başlangıç olur.

5.3. Görsel Optimizasyonu ve Modern Formatlar

Ağır görseller yeni sitelerin en sık görülen performans sorunlarından biri. Yayına almadan önce:

• Görselleri boyutlandırın; 4000×3000 piksel fotoğrafı 300×300 kutuda göstermeyin.
• Uygun yerlerde WebP/AVIF gibi modern formatları devreye alın.
• Tembel yüklemeyi ilk ekranın dışında kalan görsel ve iframe’lerde kullanın; ilk ekranda görünen, özellikle LCP adayı görsellerin yüklenmesini geciktirmeyin.

CDN ve sunucu tarafında WebP/AVIF sunumunu SEO uyumlu yapmak için WebP/AVIF’i kırmadan sunma rehberimiz üzerinden pratik kurallara göz atabilirsiniz.

6. Loglar, İzleme ve Hataları Erken Yakalamak

Yeni siteyi yayına aldığınız gün, her şey düzgün görünse bile perde arkasında 4xx ve 5xx hataları birikiyor olabilir. Bunları fark etmenin en iyi yolu, erişim ve hata loglarını düzenli takip etmek ve basit izleme (monitoring) araçları kurmaktır.

6.1. Web Sunucu Loglarını Okuma Alışkanlığı Edinin

• Apache ya da Nginx access ve error log’larını nerede bulacağınızı bilin.
• 404 hatalarını filtreleyerek, eksik dosya veya kırık linkleri tespit edin.
• 5xx hatalarını analiz ederek, uygulama ya da veritabanı tarafında sıkışma olup olmadığını kontrol edin.

Bu konuda pratik yapmak için, Apache ve Nginx ile 4xx–5xx hatalarını teşhis etmeyi anlattığımız log okuma rehberi iyi bir başlangıç noktasıdır.

6.2. Temel İzleme (Monitoring) ve Alarm Kurulumu

Yeni siteyi canlıya aldıktan sonra tamamen “kaderine bırakmak” risklidir. Minimum seviyede de olsa şu izleme adımlarını kurun:

• Uptime monitörü ile sitenin dışarıdan 7/24 erişilebilirliğini takip edin.
• Sunucu CPU, RAM, disk ve ağ kullanımı için basit grafikler ve eşikler belirleyin.
• Belirli bir 5xx oranının üzerine çıkıldığında size e‑posta ya da bildirim gönderecek alarm kuralları tanımlayın.

7. SEO Dostu Yayına Alma Senaryoları: Staging’den Canlıya

Çoğu ekip geliştirmeyi staging veya alt alan adı üzerinde yapıp, sonra canlı domaine taşır. Bu süreçte SEO tarafında sık yapılan hatalar vardır: yanlış robots.txt, unutulmuş noindex etiketleri, bozuk yönlendirmeler gibi.

7.1. Staging Ortamını Doğru İzole Etmek

• Staging alan adını (ör. staging.example.com veya dev.example.com) temel kimlik doğrulama (HTTP auth) ile koruyun. Dosya ve veritabanını canlı ortamdan ayrı tutun; hassas verileri kaldırın veya anonimleştirin. Canlı e-posta, ödeme ve webhook entegrasyonlarını devre dışı bırakın.
• Staging’de Disallow: / içeren robots.txt taramayı sınırlayabilir; erişim kontrolü sağlamaz ve URL’nin dizine girmesini tek başına önlemez. Noindex kullanılacaksa tarayıcının bunu okuyabilmesi gerekir; robots.txt ile engellenen sayfada bu mümkün olmaz. Canlıya geçerken robots.txt kurallarını güncelleyin.
• Staging ortamına işaret eden sabit URL, iç link veya resim yolu kalmadığını kontrol edin.

7.2. Noindex ve Nofollow Kontrolleri

Geliştirme sürecinde bazen “şimdilik dizine eklenmesin” diye noindex eklenir ve yayına alırken unutulur. Canlı geçiş öncesi:

• Dizine eklenmesini istediğiniz ana sayfa, kategori, ürün ve blog yazılarında <meta name="robots" content="noindex"> veya başka bir robots meta etiketiyle noindex verilmediğini kontrol edin. HTTP yanıtındaki X-Robots-Tag başlığında da noindex bulunmamalıdır.
• SEO eklentisi kullanıyorsanız, global ayarlarda site genelini noindex’e çeken bir seçenek olmadığından emin olun.
• Geliştirmeden kalmış, istemeden uygulanmış site geneli nofollow direktiflerini ve iç bağlantılardaki nofollow değerlerini ayrıca inceleyin; bunları canlı sitenin bağlantı politikasına göre düzeltin. Bu incelemeyi noindex kontrolünün yerine koymayın.

7.3. DNS, SSL, E‑posta ve SEO için İlk 30 Günlük Plan

Yeni domain ve yeni site kombinasyonlarında, sadece yayına alma anı değil, ilk 30 gün de kritik. DNS, SSL, e‑posta ve temel SEO ayarlarını daha sistematik yönetmek için hazırladığımız yeni alan adı sonrası 30 günlük kontrol listesini kendi projeniz için bir zaman çizelgesi gibi kullanabilirsiniz.

8. Pratik Bir Yayına Alma Akışı

Örnek bir yayına alma akışını somut adımlarla özetleyelim. Aşağıdaki adımlar, hem SEO sinyallerini korumanıza hem de olası performans sorunlarını yayına geçmeden önce belirlemenize yardımcı olabilir.

8.1. Planlama Aşaması

• Hedef ülke ve dil(ler)i netleştirip buna uygun sunucu lokasyonu ve hosting türünü (paylaşımlı, VPS, dedicated) seçin.
• Beklenen trafik ve büyüme planına göre başlangıç CPU, RAM ve disk kapasitesini kabaca hesaplayın.
• DNS’i seçtiğiniz yetkili DNS platformunda sade ve anlaşılır şekilde kurgulayın.

8.2. Teknik Kurulum

• Sunucu yönetimi sizdeyse güncel ve desteklenen bir Linux dağıtımı ve web sunucusu (Nginx, Apache veya LiteSpeed) kurun. Paylaşımlı veya yönetilen hosting’de bu bileşenlerin uygunluğunu plan özelliklerinden doğrulayın.
• PHP, veritabanı ve gerekli diğer servisleri (Redis, queue, search) ihtiyaca ve planın izin verdiği yönetim kapsamına göre yapılandırın.
• SSL sertifikasını alan adına tanımlayıp, HTTP → HTTPS 301 yönlendirmesini yapılandırın.

8.3. Uygulama Yayına Hazırlığı

• Staging’den canlıya taşınan veritabanı ve dosyalar için son senkronizasyonu yapın. Mevcut bir canlı siteyi güncelliyorsanız önce yedek alın; staging kopyasını canlıdaki yeni sipariş, kullanıcı ve içerik kayıtlarının üzerine yazmayın. Geçiş sırasında yazma işlemlerini durdurun veya yeni kayıtları koruyacak bir aktarım planı uygulayın.
• Otomatik yedeklemeyi kurun ve yayından önce en az bir geri yüklemeyi test edin. Geri dönüşü başlatacak koşulları, sorumlusunu ve adımlarını belgeleyin; yedekten sonra oluşan sipariş ve diğer kayıtları nasıl koruyacağınızı veya uzlaştıracağınızı planlayın. DNS önbellekleri ziyaretçileri eski sunucuya yöneltebildiği sürece eski uç noktayı erişilebilir tutun; DNS’i geri çevirmenin tüm ziyaretçileri anında geri taşıyacağını varsaymayın.
• Uygulama config dosyalarında base URL, CDN URL, veritabanı erişimleri gibi canlı ayarları güncelleyin.
• Uygulamaya uygun önbellek katmanlarını (OPcache, tam sayfa cache, nesne cache) aktif edip test edin. Tam sayfa önbelleğinde kişiselleştirilmiş yanıtların diğer kullanıcılara sunulmadığını doğrulayın; sepet, ödeme ve hesap sayfalarını ortak önbelleğin dışında tutun.

8.4. DNS Cutover ve Son Testler

• TTL’leri önceden düşürüp önceki TTL süresinin dolmasını bekledikten sonra A kayıtlarını yeni sunucunun IPv4 adresine yönlendirin. AAAA kayıtlarını yalnızca yeni sunucuda IPv6 üzerinden HTTP/HTTPS erişimi doğrulanmışsa güncelleyin; çalışmayan IPv6 adresine işaret eden kayıt bırakmayın.
• Farklı ağlardan (mobil şebeke, farklı ISP’ler) sitenin doğru sunucuya gittiğini kontrol edin.
• En önemli 20‑30 URL için manuel tarayıcı testi ve dev tools ile TTFB, toplam yüklenme süresi ve hataları gözlemleyin.

8.5. İzleme ve İnce Ayar

• İlk günlerde logları sık sık kontrol ederek 404 ve 5xx anomalilerini yakalayın.
• Kaynak kullanımını gözleyip gerekirse CPU/RAM artırımı veya önbellek ayarlarında iyileştirme yapın.
• Google Search Console ve analitik araçlar üzerinden tarama ve hız raporlarını takip edin.

Sonuç: Yayına Alma Gününü Stres Değil Avantaja Çevirin

Yeni bir web sitesini yayına almak çoğu ekip için stresli bir dönemdir; ama aslında doğru planlandığında önemli bir avantaj noktasıdır. Rekabet halihazırda sertken, hızlı açılan, hatasız yönlendirilmiş ve temiz DNS/SSL yapılandırmasına sahip bir siteyle başlamak size ciddi bir başlangıç ivmesi kazandırır. Hosting tarafında hazırladığımız bu SEO ve performans kontrol listesi, yayına alma gününde “acaba unuttuğumuz bir şey var mı?” endişesini minimuma indirmeniz için tasarlandı.

Özetle; DNS kayıtlarını hazırlayın, SSL ve HTTP katmanını doğrulayın, ardından yönlendirmeleri devreye alıp test edin. Sonrasında sunucu kaynakları, Core Web Vitals ve önbellek stratejilerini gözden geçirin. Log, izleme ve alarm katmanları sorunları erken fark etmenize, bazı kapasite ve performans belirtilerini kesintiye dönüşmeden yakalamanıza yardımcı olur. DCHost olarak, ister paylaşımlı hosting isterseniz VPS, dedicated veya colocation altyapısı kullanıyor olun, bu kontrol listesini kendinize uyarlayarak yayına alma süreçlerinizi çok daha öngörülebilir ve sağlıklı hale getirebilirsiniz.