Website Hosting Migration SEO Rehberi

TL;DR — Hosting migrasyonu, ziyaretçiler aynı URL’leri kullanmaya devam ederken web sitenizin arkasındaki mekanizmayı taşır. Önce yeni hostu oluşturup test edin, yayın öncesinde DNS yaşam süresini (TTL) düşürün, geçiş sırasında eski hostu çalışır durumda tutun ve her iki sistemin döndürdüklerini karşılaştırın. DNS’i, sertifikaları, durum kodlarını, içeriği, hızı ve tarayıcı erişimini izleyin. Eski hostu ancak günlükleri trafiğin sıfıra ulaştığını gösterdikten sonra kapatın.

Hosting migrasyonu nedir?

Hosting migrasyonu, insanların gördüğü URL’leri değiştirmeden bir web sitesinin nereden veya nasıl sunulduğunu değiştirir. Farklı bir hosting şirketine taşınmak buna bir örnektir. Bir içerik dağıtım ağı (CDN) eklemek veya değiştirmek, origin sunucusunu değiştirmek ya da DNS sağlayıcılarını değiştirmek aynı projenin parçası olabilir.

URL’nin aynı kalması belirleyici koşuldur. https://example.com/page/, taşıma öncesinde ve sonrasında https://example.com/page/ olarak kalmalıdır.

Google bunu URL değişikliği olmayan site taşıması olarak ele alır. Alan adı, protokol, host adı veya yol değişiyorsa bunun yerine tam site migrasyonları sürecini kullanın. Aynı anda iki migrasyon yapıyor olabilirsiniz.

Aynı URL’li bir taşıma SEO’yu neden etkileyebilir?

Hosting migrasyonu, sabit bir adresin arkasındaki her şeyi değiştirebilir. Arama motorları farklı bir yanıt kodu, daha yavaş sunucu, süresi dolmuş sertifika, güvenlik duvarı sorgusu, güncel olmayan önbelleğe alınmış sayfa, bozuk görsel, eksik başlık veya oluşturulmuş sayfayla karşılaşabilir.

En güvenli taşıma, altyapıyı değiştirirken gözlemlenebilir yanıtı korur. Kullanıcılar ve tarayıcılar, eski sistemden aldıkları başarılı sayfanın aynısını yeni sistemden almalıdır.

Temel adımlar nelerdir?

1. Siteyi yeni altyapıya kopyalayın veya yeni altyapıya bağlayın.
2. Herkese açık DNS’i değiştirmeden yeni origin’i ve CDN’i test edin.
3. Sonraki değişikliğin daha hızlı yayılması için DNS TTL’sini önceden düşürün.
4. Sertifikaları, önbelleğe almayı, güvenlik kurallarını ve tarayıcı erişimini doğrulayın.
5. Trafiği yeni altyapıya göndermek için DNS’i değiştirin.
6. DNS önbellekleri sona ererken her iki ortamı da çevrimiçi tutun.
7. Günlükleri, hataları, hızı, taramayı ve arama performansını izleyin.
8. Eski hostun günlükleri kalan trafik olmadığını gösterene kadar kapatmayın.

Google, hosting değişikliği dokümantasyonunda aynı hazırlık, geçiş, izleme ve kapatma sırasını önerir.

DNS TTL ne yapar?

DNS TTL, bir çözümleyicinin DNS yanıtını ne kadar süre önbelleğe alabileceğini belirler. Taşımadan önce daha düşük bir TTL, değişen kayıtların önbelleklerden daha erken çıkmasını sağlar. Her çözümleyicinin anında geçiş yapmasını sağlamaz; yayın sırasında düşürmek de eski değeri tutan önbellekler için çok geçtir.

Google, taşıma işleminden en az bir hafta önce TTL’yi birkaç saat gibi ihtiyatlı biçimde düşük bir değere indirmeyi önerir. Bunu evrensel bir sayı değil, örnek olarak ele alın; kesin değere DNS sağlayıcınız ve operasyonel gereklilikleriniz karar verir.

Yönlendirmelere ihtiyacınız var mı?

Gerçek bir hosting migrasyonunda SEO yönlendirmelerine gerek yoktur, çünkü herkese açık URL’ler değişmez. Yalnızca host değişikliği sırasında genel yönlendirmeler eklemek, altyapı sorununu çözmeden yeni hata türleri oluşturur.

Mevcut yönlendirmelerin yine de eskisi gibi davranması gerekir. Mevcut web sunucusunda, CMS’de, yük dengeleyicide veya CDN’de bulunabilecek eski kurallar da dahil olmak üzere bunları yeni yığında test edin.

Taşıma ne zaman tamamlanır?

Hosting taşıması, yeni altyapı amaçlanan yanıtları tutarlı biçimde sunduğunda ve eski altyapı artık gerçek kullanıcı veya tarayıcı trafiği almadığında tamamlanır. Google, eski sağlayıcının günlüklerini kontrol etmeyi ve trafiğin sıfıra ulaşmasından sonra kapatmayı açıkça önerir.

TL;DR — Aynı URL’li hosting, CDN veya DNS migrasyonunu yanıt eşliği ve trafik yönlendirme projesi olarak ele alın. Her host adını ve bağımlılığı envantere ekleyin, yayın öncesinde DNS TTL’sini düşürün, yeni origin’i ve edge’i yapılandırın, sertifikaları ve güvenlik kontrollerini doğrulayın, gerçekçi tarayıcı ve kullanıcı talebimini yük testine tabi tutun ve ham yanıtları oluşturulmuş yanıtlarla karşılaştırın. DNS yayılımı boyunca eski ve yeni altyapıyı birlikte çalıştırın. Her iki günlük akışını, DNS yanıtlarını, hataları, gecikmeyi, önbellek davranışını, tarama etkinliğini ve Search Console’u izleyin. Yalnızca önceden kararlaştırılmış bir altyapı hatası oluştuğunda önceki yönlendirmeyi geri yükleyerek geri alın.

Bunun gerçekten aynı URL’li bir migrasyon olup olmadığına karar verin

Aynı URL’li hosting migrasyonu, tam herkese açık URL dizesini değiştirmeden altyapıyı değiştirir. Şema, host adı, port, yol, sorgu işleme ve sondaki eğik çizgi davranışı sabit kalır.

Planlamadan önce projeyi sınıflandırın:

Bir proje yöneticisinin URL değişikliğini “sadece hosting” diye etiketlemesine izin vermeyin. Yayın planı, gerçekte gönderilen her migrasyon türünü içermelidir.

Altyapı envanterini oluşturun

Altyapı envanteri, sessiz bağımlılıkların yayın gününde sürprize dönüşmesini engeller. Şunları kaydedin:

• Varlıklar, görseller, API’ler, uluslararası hostlar ve eski takma adlar dahil tüm herkese açık host adları;
• A, AAAA, CNAME, NS, SOA, CAA, MX, TXT ve ilgili SRV kayıtları;
• Sertifika sağlayıcıları, doğrulama yöntemleri, Subject Alternative Name’ler ve sona erme tarihleri;
• Origin adresleri, portlar, sağlık kontrolleri, yük dengeleyiciler ve yük devretme davranışı;
• CDN önbellek anahtarları, önbellek kuralları, yönlendirmeler, dönüşümler, worker’lar ve temizleme yöntemleri;
• WAF, bot, hız sınırı, coğrafi, kimlik doğrulama ve IP izin/ret kuralları;
• Yanıt başlıkları, sıkıştırma, çerez davranışı ve güvenlik başlıkları;
• Günlük hedefleri, saklama, örnekleme, alanlar ve saat dilimleri;
• Search Console ve analiz doğrulama yöntemleri;
• Üçüncü taraf geri çağrıları, webhook’lar, ödeme akışları, feed’ler ve izin verilen IP’ler.

DNS incelemesi web dışı kayıtları da içermelidir. MX, SPF, DKIM, DMARC veya servis kayıtlarını bozmak sıralamaları doğrudan değiştirmeyebilir, ancak korumaya çalıştığınız işi bozabilir.

Yanıt eşliği için bir temel oluşturun

Yanıt eşliği, her ikisinin de 200 döndürdüğünü kontrol etmek değil, aynı istenen URL için eski ve yeni sistemleri karşılaştırmaktır.

Şablonlar ve davranışlar boyunca temsili bir küme yakalayın:

• durum ve yönlendirme zinciri;
• son URL ve protokol anlaşması;
• title, canonical, robots yönergeleri, hreflang ve yapılandırılmış veri;
• ham HTML ve tarayıcı tarafından oluşturulan ana içerik;
• Content-Type, Cache-Control, Vary, sıkıştırma ve güvenlik başlıkları;
• görseller, fontlar, JavaScript, CSS, PDF’ler ve medya varlıkları;
• çerezler ve oturum açılmış veya kişiselleştirilmiş varyantlar;
• mobil ve masaüstü davranışı;
• gecikme, ilk bayta kadar geçen süre ve hata oranı.

Eşleştirilmiş sayfa kontrolleri için Staging vs. Production SEO Diff aracını kullanın. Daha büyük envanteri tam bir tarayıcı ve betikli istek paketi kapsamalıdır.

Yeni origin’i hazırlayın

Origin hazırlığı içerik ve yapılandırma eşliğiyle başlar. Mevcut içeriği, şablonları, medyayı, robots kurallarını, yönlendirmeleri, hata işleme ve doğrulama dosyalarını kopyalayın. Yeni veritabanının güncel olmayan verilerle yayınlanmaması için yazmaları dondurun veya senkronize edin.

Origin’i kontrollü bir host adı, yerel hosts dosyası geçersiz kılması veya sağlayıcıya özgü önizleme mekanizması üzerinden doğrudan test edin. Sanal hostlar, uygulama yönlendirmesi, sertifikalar, canonical’lar ve mutlak bağlantılar buna bağlı olabileceğinden test üretimdeki Host başlığını korumalıdır.

Yeni origin, geçiş sonrası yükü de karşılayabilmelidir. Uygulamayı ve veritabanını ısıtın, bağlantı havuzlarını ve otomatik ölçeklemeyi doğrulayın, önbelleğe alınmamış talebi yük testine tabi tutun. CDN önbellek kaçırmaları, yayın sonrasında trafiği hemen origin’de yoğunlaştırabilir.

CDN’i ayrı bir sistem olarak yapılandırın

CDN migrasyonu coğrafyadan fazlasını değiştirir. Eski ve yeni edge davranışını açıkça karşılaştırın:

• sorgu dizeleri, çerezler, başlıklar ve cihaz varyantları dahil önbellek anahtarı bileşimi;
• önbelleğe alınabilir durum kodları ve dosya türleri;
• tarayıcı TTL’si, edge TTL’si, eski içerik sunma, yeniden doğrulama ve origin yalıtımı;
• yönlendirmeler, yeniden yazmalar, başlık dönüşümleri ve edge işlevleri;
• hesaplar, sepetler, arama ve kişiselleştirilmiş sayfalar için önbellek atlama kuralları;
• sıkıştırma ve görsel optimizasyonu;
• temizleme kapsamı ve yayılımı;
• WAF, bot yönetimi, hız sınırlama ve origin koruması.

Örneğin Cloudflare’ın güncel dokümantasyonu, varsayılan önbelleğe almasının origin Cache-Control başlıklarına uyabileceğini, ancak edge kurallarıyla geçersiz kılınabileceğini belirtir. Ayrıca yeni origin’den taze getirmeleri zorlamak için hedefli veya tam temizlemeler sunar. Kesin davranış sağlayıcıya özgüdür; eşdeğer etiketlerin eşdeğer sonuçlar verdiğini varsaymak yerine yapılandırmayı dışa aktarın ve karşılaştırın. Cloudflare’ın önbellek dokümantasyonuna bakın.

Önbellek eşliğini içerik eşliği olarak ele alın

Önbellek yapılandırması yanlış sayfayı doğru ve hızlı biçimde sunabilir. Anonim, kimliği doğrulanmış, yerelleştirilmiş, mobil ve sorgu dizesi varyantlarını test edin. Anlamlı bir çerezi veya başlığı dışarıda bırakan önbellek anahtarı kişiselleştirilmiş içeriği sızdırabilir. Her izleme parametresini içeren bir anahtar önbelleği parçalayabilir ve origin’i aşırı yükleyebilir.

Kritik varlıkları ve sayfaları yayın planına göre temizleyin veya önceden ısıtın. Origin’in sonuçta oluşan önbellek kaçırma fırtınası için test edildiği durumlar dışında yoğun trafikte her şeyi körlemesine temizlemeyin.

Kullanıcıdan edge’e ve edge’den origin’e TLS’yi doğrulayın

Bir CDN HTTPS’yi sonlandırdığında TLS doğrulamasının iki ayağı vardır: tarayıcıdan CDN’e ve CDN’den origin’e. Host adı kapsamını, eksiksiz sertifika zincirlerini, modern protokol desteğini, yenilemeyi ve sıkı origin doğrulamasını doğrulayın.

Yalnızca origin’e ait sertifikalar herkese açık biçimde güvenilir olmayabilir. Cloudflare, proxy devre dışı bırakılır veya duraklatılırsa Origin CA sertifikalarının tarayıcı güven hatalarına yol açabileceği konusunda uyarır. Bu, geri alma sırasında önemlidir: edge’e özel bir güven modelini kullanan origin’e yalnızca DNS üzerinden geri dönüş kullanıcılar için başarısız olabilir. Cloudflare Origin CA yönergelerine bakın.

Her nadir kullanılan varlık veya bölgesel host da dahil olmak üzere tüm herkese açık host adlarını test edin. Geçerli bir apex sertifikası, her alt alan adının kapsandığını kanıtlamaz.

Taşımadan önce DNS TTL’sini düşürün

TTL planlaması geçişten önce başlar. Google, taşımadan en az bir hafta önce ilgili TTL’nin birkaç saat gibi ihtiyatlı biçimde düşük bir değere indirilmesini önerir. DNS sağlayıcısı farklı asgari değerler dayatabilir; proxy’li kayıtların sabit değerleri de olabilir.

Cloudflare’ın TTL dokümantasyonu, temel dengeyi açıklar: daha uzun değerler önbellek kullanımını artırırken daha kısa değerler kayıt değişikliklerinin daha erken etkili olmasını sağlar. Başlangıç TTL’sini kaydedin ve yeni altyapı kararlı olduktan sonra geri yüklenmesini planlayın.

DNS değişiklikleri dağıtık sistemler arasında atomik olmayabilir. Geçiş sırasında mümkün olduğunca az şeyi değiştirin, yanıtları birkaç herkese açık çözümleyiciden doğrulayın ve önbelleğe alınmış yanıtlar geçerli kaldığı sürece eski hedefi kullanılabilir tutun.

Tarayıcı erişimini ve güvenlik kontrollerini doğrulayın

Güvenlik eşliği kural sayısının eşliği değildir. Başka bir sağlayıcıdan kopyalanan WAF tarayıcıları sorgulayabilir veya engelleyebilir, sorgu parametrelerini kaldırabilir, yanıtları yeniden yazabilir ya da yüksek hacimli taramayı farklı biçimde hız sınırlayabilir.

Google’ın hosting rehberi, güvenlik duvarlarının ve hizmet reddi saldırısı korumasının Googlebot’un DNS veya hosting sunucularını engellememesini sağlamayı söyler. Googlebot’u yalnızca user-agent dizesine güvenerek değil, Google’ın belgelenmiş doğrulama yöntemlerini kullanarak doğrulayın.

Hem sıradan tarayıcı davranışını hem de meşru ani yükleri test edin. Sahte user-agent’lar için korumayı devre dışı bırakan geniş izin listelerinden kaçının. Engellenen istekleri origin hatalarından ayırabilmek için güvenlik günlüklerini koruyun.

İkili çalışmayı planlayın

İkili çalıştırma, yayılım sırasında hem eski hem de yeni altyapının doğru üretim yanıtları sunabilmesi demektir. Eski ortam, siteyi etkileyen içerik veya veri değişikliklerini almaya devam etmelidir. Aksi halde önbelleğe alınmış DNS yanıtlarıyla yönlendirilen kullanıcılar güncel olmayan envanterler, bozuk oturumlar veya eski sayfalar görebilir.

Bir senkronizasyon stratejisi seçin:

• her iki yığının paylaştığı tek bir okuma/yazma veritabanı;
• anlaşılmış gecikme ve çakışma politikasıyla çoğaltılmış veri;
• geçiş sırasında kontrollü içerik dondurma;
• siparişler, formlar veya kullanıcı yazmaları için tek yönlü olay çoğaltma.

Oturum durumu, yüklemeler, önbellek geçersizleştirmeleri ve arka plan işleri için de aynı kararı verin. Durumları ayrışıyorsa “her iki sunucu açık” bir ikili çalışma planı değildir.

Geçişi gerçekleştirin

Hosting geçişi bilinçli olarak sıkıcı olmalıdır:

1. İlgisiz dağıtımları durdurun ve değişiklik penceresini doğrulayın.
2. Son eşlik, sertifika, kapasite ve yedekleme kontrollerini çalıştırın.
3. Yeni üretim yolundaki geçici tarama veya erişim engellerini kaldırın.
4. Yalnızca planlanan DNS veya CDN yönlendirme kayıtlarını değiştirin.
5. Birden çok çözümleyiciden beklenen yanıtları doğrulayın.
6. Korunan sayfaları herkese açık rota üzerinden kullanıcı ve tarayıcı olarak isteyin.
7. Edge’den, yeni originden ve eski originden günlüklerin geldiğini doğrulayın.
8. Hataları, gecikmeyi, önbellek kaçırmalarını, origin yükünü ve dönüşümleri izleyin.

Yalnızca host değişikliği için Google’ın Change of Address aracını kullanmayın. Herkese açık URL değişmediği için bildirilecek bir adres değişikliği yoktur.

Taşımayı kanıtlayan delilleri izleyin

Altyapı izleme, eski ve yeni trafiği ayırmalıdır. Bir dağıtım işareti kullanın ve mevsimselliğin önemli olduğu durumlarda haftanın aynı zamanındaki temel değerle karşılaştırın.

Şunları izleyin:

• DNS yanıtları ve çözümleyici yayılımı;
• kullanıcı ve doğrulanmış tarayıcıya göre eski host ve yeni host istekleri;
• edge ve origin durum kodu dağılımı;
• TLS, bağlantı, zaman aşımı ve uygulama hataları;
• gecikme yüzdelikleri ve önbelleğe alınmamış origin yanıt süresi;
• önbellek isabet oranı ve origin istek hacmi;
• Googlebot istekleri, Crawl Stats, Page Indexing ve temsili URL Inspection;
• bölgeler ve ağlar genelinde sentetik kontroller;
• analizler, dönüşümler ve kritik işletme işlemleri.

Google, hosting değişikliğinden hemen sonra Googlebot tarama hızındaki geçici düşüşün normal olabileceğini ve sonraki birkaç gün içinde artış gelebileceğini söyler. Her kararı yalnızca bu beklenen örüntüye değil, erişilebilirlik ve hata kanıtına dayandırın.

Yayın öncesinde geri almayı tanımlayın

Geri alma, yönlendirmeyi bilinen iyi bir altyapı durumuna döndürür. “DNS’i geri alacağız” şeklindeki belirsiz bir vaat değildir. Şunları belgeleyin:

• geri yüklenecek tam kayıtlar, rotalar ve yapılandırmalar;
• geri dönüşü kimin yetkilendirip gerçekleştirebileceği;
• değişen içerik, oturumlar, formlar, siparişler ve yüklemelerin nasıl uzlaştırılacağı;
• eski sertifikaların ve bağımlılıkların geçerliliğini koruyup korumadığı;
• her iki rota için önbellek temizleme adımları;
• geri almayı tetikleyen hata eşikleri;
• güvenli azami karar süresi.

Geri alma tetikleyicileri gözlemlenebilir olmalıdır: süregelen erişilebilirlik hataları, önemli dönüşüm bozulması, yaygın yanlış içerik, sertifika hataları, tarayıcı engelleri veya pencere içinde düzeltilemeyen kapasite çöküşü. Tek başına geçici tarama hızı dalgalanması geri alma tetikleyicisi değildir.

Eski altyapıyı takvimden değil günlüklerden emekliye ayırın

Eski hostun emekliye ayrılması, günlükler kullanıcıların ve tarayıcıların artık ona ulaşmadığını ve tüm bağımlı hizmetlerin taşındığını gösterdikten sonra gerçekleşir. Google, eski hostun trafiği sıfıra ulaştıktan sonra kapatılmasını önerir.

Yapılandırma dışa aktarımlarını, günlükleri ve geri alma varlıklarını işletme gerekliliklerine göre saklayın. Kararlılık kanıtlandıktan sonra DNS TTL’sini amaçlanan sabit durum değerine geri yükleyin. Geçici güvenlik duvarı istisnalarını ve yinelenen zamanlanmış işleri kaldırın; böylece migrasyon kalıcı bir bakım karmaşası bırakmaz.

AI özeti

• Bir hosting migrasyonu, herkese açık URL’ler aynı kalırken sunucuları, CDN’i, origin’i veya DNS’i değiştirir.
• URL değişiklikleri daha geniş site taşıma sürecini gerektirir. Gerçek bir yalnızca host taşımasında yeni yönlendirme haritası veya Change of Address gönderimi gerekmez.
• Yayın öncesinde DNS, TLS, origin, CDN, WAF, önbellek, günlükler, doğrulama, varlıklar ve işletme bağımlılıklarını envantere ekleyin.
• Geçişten önce DNS TTL’sini düşürün, eski değeri kaydedin ve yeni yol kararlı olduktan sonra geri yükleyin.
• Eski ve yeni ham yanıtları, oluşturulmuş sayfaları, başlıkları, varlıkları, yönlendirmeleri, durum kodlarını, gecikmeyi ve işletme davranışını karşılaştırın.
• Tarayıcıdan edge’e ve edge’den origin’e TLS’yi, ayrıca her geri alma yolundaki sertifikaları doğrulayın.
• Ortamları ikili çalıştırın ve önbelleğe alınmış DNS yanıtları artık eski yığına trafik göndermeyene kadar yazmaları senkronize edin.
• Her iki günlük akışını, DNS yanıtlarını, hataları, origin yükünü, önbellek davranışını, doğrulanmış tarayıcı erişimini, Search Console’u ve dönüşümleri izleyin.
• Eski hostu yalnızca günlükleri trafiğin sıfıra ulaştığını gösterdiğinde emekliye ayırın.

Resmî dokümantasyon

Google

• Web hosting’inizi ve SEO’yu değiştirme, aynı URL’li hazırlık, DNS geçişi, izleme ve kapatma sürecini açıklar.
• URL değişiklikleriyle site taşımaları, şema, host adı veya yol da değiştiğinde geçerlidir.
• Googlebot’u doğrulama, ters/ileri DNS ve yayımlanmış IP doğrulamasını belgeler.
• Crawl Stats raporu, Googlebot isteklerini ve host kullanılabilirliğini izlemeye yardımcı olur.

Altyapı referansları

• Cloudflare DNS TTL, TTL’yi ve yayılım dengelerini açıklar.
• Cloudflare önbelleği, edge önbelleğe almayı, önbellek kurallarını ve temizlemeyi belgeler.
• Cloudflare Origin CA, edge’den origin’e sertifikaları ve tarayıcı güveni sınırlamasını belgeler.

Kaynaktan alıntılar

• “This guide is only for migrations that don’t affect the user-visible URL.” Google Search Central. Jump to the hosting guide
• Paraphrase: Google recommends reducing DNS TTL ahead of the move, ensuring firewalls still admit verified Googlebot traffic, expecting a temporary crawl-rate dip, and keeping the old host available until its traffic has ended. TTL guidance, firewall guidance, crawl-rate guidance, and shutdown guidance.

Hosting migrasyonu kontrol listesi

Kapsam ve temel değer

• Herkese açık hiçbir URL’nin değişmeyeceği doğrulandı.
• Her web, varlık, API ve bölgesel host adı envantere alındı.
• DNS, CDN, WAF, önbellek, yönlendirme, TLS ve origin yapılandırmaları dışa aktarıldı.
• Temsili ham ve oluşturulmuş yanıt temelleri kaydedildi.
• Trafik, hata, gecikme, tarama, dizine eklenme ve dönüşüm temelleri kaydedildi.

Yeni altyapı

• Mevcut içerik, medya, yönlendirmeler, robots kuralları ve doğrulama dosyaları senkronize edildi.
• Host başlığı yönlendirmesi ve her herkese açık host adı test edildi.
• Tarayıcıdan edge’e ve edge’den origin’e sertifikalar doğrulandı.
• Önbellek anahtarları, atlamalar, TTL’ler, çerezler, dönüşümler ve temizleme davranışı eşleştirildi.
• WAF, bot, hız sınırı ve origin erişimi davranışı eşleştirildi.
• Önbellek kaçırmaları, uygulama bağımlılıkları ve veritabanı kapasitesi yük testine tabi tutuldu.
• Edge, origin, uygulama ve güvenlik günlüklerinin saklandığı ve aranabildiği doğrulandı.

DNS ve yayın

• İlgili TTL’ler taşıma öncesinde düşürüldü ve başlangıç değerleri kaydedildi.
• Web dışı kayıtlar, DNSSEC, doğrulama ve servis bağımlılıkları korundu.
• Tam yönlendirme değişikliği ve geri alma komutları belgelendi.
• Eski ve yeni altyapı bir veri senkronizasyon planıyla canlı tutuldu.
• Her geçici üretim yolu tarama veya erişim engeli kaldırıldı.
• DNS yanıtları birden çok bağımsız çözümleyici üzerinden doğrulandı.

Yayın sonrası

• Üretimde durum, içerik, başlıklar, oluşturma, varlıklar ve yönlendirmeler karşılaştırıldı.
• Kullanıcıların ve doğrulanmış tarayıcıların sorgulanmadığı veya engellenmediği doğrulandı.
• Eski/yeni günlükler, hatalar, gecikme, önbellek kaçırmaları, origin yükü ve dönüşümler izlendi.
• Crawl Stats, Page Indexing ve temsili URL Inspection sonuçları kontrol edildi.
• Sabit durum TTL’si yalnızca kararlılık kanıtlandıktan sonra geri yüklendi.
• Eski host yalnızca trafiği sıfıra ulaştıktan sonra emekliye ayrıldı.

Beş katmanlı eşlik çerçevesi

Migrasyon durum modeli

Hazır, yeni yığının eşlik ve yük testlerini geçtiği anlamına gelir. Geçiş, DNS yanıtlarının ve isteklerin bölündüğü anlamına gelir. Kararlılaşma, eski yığın kullanılabilir kalırken yeni yığının trafiğin neredeyse tamamını sunduğu anlamına gelir. Tamamlandı, eski host trafiğinin sıfıra ulaştığı ve tüm bağımlılıkların emekliye ayrıldığı veya devredildiği anlamına gelir.

Projeyi “DNS değişti” noktasında tamamlandı diye adlandırmayın. Bu geçişin başlangıcıdır, migrasyonun sonu değil.

Hangi migrasyon planı uygulanır?

Yaygın hosting migrasyonu hataları

Bazı bölgeler hâlâ eski hosta ulaşıyor

Olası neden: önbelleğe alınmış DNS yanıtları, çözümleyici davranışı veya tutarlı biçimde değiştirilmeyen kayıtlar. Çözüm: yetkili yanıtları birkaç herkese açık çözümleyiciyle karşılaştırın, eski hostun güncel içeriği sunmasını sağlayın ve tekrar tekrar değişiklik yapmak yerine TTL’leri inceleyin.

Googlebot istekleri yayından sonra düşüyor

Olası neden: normal kısa vadeli tarama hızı ayarlaması, güvenlik duvarı sorgusu, DNS hatası, gecikme veya sunucu hataları. Çözüm: Crawl Stats’ı ve doğrulanmış bot erişim günlüklerini kontrol edin. Google’ın belgelenmiş kısa vadeli düşüşü gerçek erişim hatalarını görmezden gelmek için gerekçe değildir.

Sayfalar hızlı ama güncel olmayan içerik gösteriyor

Olası neden: edge TTL’si, önbellek anahtarı, temizleme hatası veya ayrışmış veri kaynağı. Çözüm: Age, Cache-Control, Vary ve sağlayıcının önbellek durumu başlıklarını inceleyin; anlamlı varyantları test edin; dar kapsamlı temizleyin; ardından origin’i ve edge’i ayrı ayrı doğrulayın.

Site CDN üzerinden çalışıyor ama atlandığında başarısız oluyor

Olası neden: origin sertifikası güveni, Host başlığı yönlendirmesi, güvenlik duvarı izin listeleri veya eksik doğrudan origin bağımlılığı. Çözüm: amaçlanan edge’den orig ine yolu ve belgelenmiş geri alma yolunu doğrulayın. Planlanmamış bir atlama testini geçirmek için özel origin’i açığa çıkarmayın.

HTML çalışırken varlıklar başarısız oluyor

Olası neden: eksik varlık host adları, CORS, sertifikalar, mutlak URL’ler, önbellek kuralları, hotlink koruması veya origin izinleri. Çözüm: fontlar, görseller, CSS, JavaScript, PDF’ler ve medya dahil varlık envanterini tarayın ve tarayıcıda test edin.

Origin yükü hemen artıyor

Olası neden: soğuk önbellekler, değişmiş önbellek anahtarı, atlanan önbellek, eksik yalıtım veya doğrudan orig ine ulaşan bot trafiği. Çözüm: amaçlanan önbellek kurallarını geri yükleyin, yüksek değerli nesneleri dikkatle ısıtın ve kapasite ekleyin. Süregelen hatalar kararlaştırılmış eşiği aşarsa geri alın.

Aynı URL’li altyapı taşıması için araçlar

• DNS Checker, birkaç herkese açık çözümleyici üzerinden yaygın kayıt türlerini karşılaştırır. Yayılım sırasında kullanın, ancak sonucu yetkili bölgeyle de karşılaştırın.
• HTTP Header Checker, CDN parmak izleri, sıkıştırma, güvenlik ve önbellek kontrolleri dahil yönlendirmeler boyunca başlıkları gösterir.
• Staging vs. Production SEO Diff, durum, canonical’lar, yönergeler, seçili başlıklar, schema ve içerik bakımından eşleşen URL’leri karşılaştırır.
• Bulk HTTP Status Code Checker, temsili bir URL kümesinde durumu, yönlendirmeleri, hedefi ve gecikmeyi kontrol eder.
• Google Index Checker, gözlemlenebilir tarama ve dizine eklenme engellerini kontrol eder, ardından Google’ın kendi görünümü için Search Console’a yönlendirir.
• Sunucu ve edge günlükleri, trafiğin nereye gittiğini, hangi yanıtı aldığını ve eski altyapının ne zaman gerçekten kullanılmadığını kanıtlar.
• Sentetik izleme, herkese açık kullanılabilirliği ve kritik işlemleri birkaç ağdan ve bölgeden test eder.

Hosting migrasyonunun işe yaradığını kanıtlayın

DNS yayılımı ve eski hostun boşalma testi

• Çalıştırılacak test: Yetkili DNS’yi ve birkaç herkese açık çözümleyiciyi sorgulayın, ardından eski ve yeni altyapıdaki istek hacmini grafikleyin.
• Beklenen sonuç: Herkese açık yanıtlar amaçlanan rotada birleşirken eski host trafiği sıfıra iner.
• Başarısızlık yorumu: Tutarsız kayıtlar, önbelleğe alınmış yanıtlar veya izlenmeyen host adları hâlâ trafiği başka yere yönlendiriyor.
• İzleme penceresi: Geçişten önceki en uzun ilgili TTL’den itibaren ve eski host günlükleri sıfırda kalana kadar.
• Geri alma tetikleyicisi: Önemli bölgeler yeni hizmeti çözemiyor veya ulaşamıyor ve sorun kurtarma penceresinde düzeltilemiyor.

Yanıt eşliği testi

• Test to run: Compare the baseline with production using the Staging vs. Production SEO Diff, a crawler, and rendered browser tests.
• Expected result: Intended status, canonicals, robots rules, content, structured data, internal links, assets, and headers are preserved.
• Failure interpretation: The new origin, edge, or application configuration has changed a search-visible response despite stable URLs.
• Monitoring window: Immediately before and after cutover, then after each launch fix.
• Rollback trigger: A site-wide indexability, canonical, content, or asset failure affects protected templates and cannot be hot-fixed safely.

Tarayıcı erişimi ve kapasite testi

• Çalıştırılacak test: Doğrulanmış tarayıcı günlüklerini, Search Console Crawl Stats’ı, origin gecikmesini, hata oranlarını ve önbelleğe alınmamış yük testi sonuçlarını inceleyin.
• Beklenen sonuç: Doğrulanmış tarayıcılar sorgu olmadan başarılı yanıt alır; origin de yerleşik kapasite sınırları içinde kalır.
• Başarısızlık yorumu: WAF, DNS, TLS, hız sınırlama veya origin kapasitesi güvenilir taramayı engelliyor.
• İzleme penceresi: Yayın boyunca ve tarama hızının kararlılaşmasının ilk birkaç gününde sürekli.
• Geri alma tetikleyicisi: Süregelen tarayıcı ve kullanıcı hataları onaylanan hata veya kullanılabilirlik eşiğini aşıyor.

Önbellek güvenliği testi

• Çalıştırılacak test: Önbellek anahtarlarını ve yanıt başlıklarını incelerken anonim, kimliği doğrulanmış, yerelleştirilmiş, mobil ve sorgu varyantlarını isteyin.
• Beklenen sonuç: Herkese açık içerik tasarlandığı gibi önbelleğe alınır; özel veya kişiselleştirilmiş yanıtlar paylaşılmaz; anlamlı varyantlar ayrı kalır.
• Başarısızlık yorumu: Önbellek anahtarı veya atlama kuralları yanlış içerik sunabilir ya da origin’i aşırı yükleyebilir.
• İzleme penceresi: Yayından önce, geçişten hemen sonra ve her önbellek kuralı veya temizleme değişikliğinden sonra.
• Geri alma tetikleyicisi: Kişiselleştirilmiş veri açığa çıkıyor, yaygın güncel olmayan içerik sunuluyor veya origin kaçırma oranını taşıyamıyor.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• Başarılı Olmak İçin Bir Web Sitesi Migrasyonu Kontrol Listesinden Fazlasını Gerektirir, daha geniş migrasyon sürecini, temelleri, hazırlık ortamını ve izlemeyi kapsar.
• SEO için yönlendirmeler, altyapı taşımasında korunması gereken eski yönlendirme davranışını açıklar.

Bu sitedeki ilgili rehberler

• Site Migrasyonları, migrasyon sınıflandırmasını ve evrensel süreci kapsar.
• Web Sitesi Migrasyonu Kontrol Listesi, aşamalara dayalı proje kontrol listesini sağlar.
• HTTP Durum Kodları, korumanız ve izlemeniz gereken yanıt katmanını açıklar.

Sektörden

• Google: Hosting’inizi değiştirme
• Google: Googlebot’u doğrulama
• Cloudflare: DNS TTL
• Cloudflare: DNS kayıtlarını yönetme
• Cloudflare: Önbellek dokümantasyonu
• Cloudflare: Origin CA
• Bing: IndexNow

Kendinizi test edin: Website Hosting Migration SEO

Aynı URL’li bir altyapı taşımasını sınıflandırma, yayınlama ve doğrulama hakkında beş soru. Her biri için bir yanıt seçin, sonra kontrol edin.

Değişiklik günlüğü