Hosting Değiştirirken SEO: DNS Geçişi ve TTL Planı

URL'leri değiştirmeden hosting değiştiriyorsanız SEO riskini taşıma planı belirler, adreslerin kendisi değil. Google'ın hosting değişikliği belgesine göre sıra şöyledir: yeni altyapıyı hazırlayıp test edin, DNS TTL değerini taşımadan en az bir hafta önce düşürün, Search Console doğrulamasının yeni kopyada çalıştığından emin olun, geçici engelleri kaldırın, DNS kayıtlarını güncelleyin ve eski sunucuyu trafik sıfıra inene kadar açık tutun.

Bu yazı site sahibi, geliştirici ve ajans çalışanı için hazırlandı. Önce taşıma öncesi hazırlığı, sonra yeni kopyayı canlıya almadan doğrulama adımlarını anlatır. Ardından geçiş günü adımlarını, ilk üç günlük izleme planını ve eski sunucuyu kapatma kararını verir.

Taşıma Öncesi: TTL Düşürme ve Eski Sunucuyu Açık Tutma

Hosting taşımasının en sakin ve en önemli kısmı geçiş gününden önceki haftadır. Bu dönemde yapılan hazırlık, geçiş gününde yaşanabilecek belirsizliği azaltır.

Aynı URL ile taşımanın anlamı

Google'ın hosting değişikliği belgesi (yeni sekmede açılır), kullanıcıya görünen URL'lerin değişmediği taşımaları ele alır: hosting sağlayıcısı değiştirmek ya da bir CDN'e geçmek gibi. Bu durumda adresler aynı kaldığı için eski ve yeni adres eşlemesi kurulacak bir şey yoktur; hedef, tarayıcıların ve kullanıcıların DNS değişikliğini fark etmeden aynı içeriğe ulaşmasıdır. Alan adı, protokol ya da yol yapısı da değişiyorsa durum başka bir taşıma türüne girer ve ayrı planlanmalıdır; arka plan için site taşıma sırasında backlink değerini koruma yazımıza bakabilirsiniz.

TTL nedir ve neden düşürülür?

TTL (time to live), bir DNS kaydının önbellekte ne kadar süre tutulacağını söyleyen değerdir. Google'ın belgesi, DNS ayarlarının genellikle internet servis sağlayıcıları tarafından belirtilen TTL değerine göre önbelleğe alındığını yazar. TTL yüksekse ve geçiş günü kaydı değiştirirseniz, bir kısım ziyaretçi ve tarayıcı bir süre eski sunucuya gitmeye devam eder. TTL düşükse yeni kayıt daha hızlı yayılır. Belge TTL'yi "birkaç saat gibi, muhafazakâr bir düşük değere" çekmeyi ve bunu taşımadan en az bir hafta önce yapmayı önerir. Bu önerinin mantığı şudur: önceki yüksek TTL değeri önbelleklerde bitene kadar düşük değer devreye girmez, dolayısıyla düşürme işlemini geçiş gününe bırakmak amaca hizmet etmez.

Önceki TTL değerini not alın

Düşürmeden önce mevcut TTL değerini kaydedin. Bu değer, eski önbelleklerin ne kadar süre eski kaydı tutabileceğinin üst sınırını verir. Örneğin eski değer bir günse, düşürme işleminden sonra en az o kadar süre beklemeden yeni düşük değerin her yerde geçerli olduğunu varsaymayın. Geçişten sonra TTL'yi yeniden yükseltmek de planın parçasıdır; sürekli düşük TTL, DNS sorgularını artırır.

Eski sunucuyu kapatma

Eski sunucu taşıma boyunca çalışır durumda kalmalıdır. Belge, eski altyapıyı yalnızca eski sağlayıcıya gelen trafik sıfıra indiğinde kapatabileceğinizi söyler. Bu nedenle eski hosting sözleşmesinin bitiş tarihini taşıma takviminize bağlayın; sözleşmenin hemen bitmesi gerekiyorsa uzatma ya da kısa süreli ek dönem isteyin. Aksi hâlde DNS önbelleğindeki ziyaretçiler boş bir adrese yönelir.

Kopyalanacak ve kopyalanmayacaklar

Sitenin dosyalarını ve veritabanını yeni sunucuya taşıyın, ancak bununla yetinmeyin. E-posta ayarları (MX kayıtları ayrı bir DNS konusudur), zamanlanmış görevler, yeniden yazma kuralları, özel hata sayfaları, yönlendirmeler ve sunucu düzeyindeki başlıklar da taşınır. Bu kalemler çoğu zaman yeni ortamda varsayılan değerlerle gelir ve sessizce farklı davranır. Eski sunucudaki yapılandırma dosyalarını yan yana koyup karşılaştırın.

Örnek senaryo: paylaşımlı hostingten ayrı sunucuya geçen mağaza

Örnek senaryo: küçük bir e-ticaret sitesi, ziyaretçi arttığı için paylaşımlı hostingten ayrılmış bir sunucuya geçiyor. Sahibi önce mevcut TTL değerini not alıyor, ardından bir hafta önce düşük bir değere çekiyor. Eski sözleşmeyi bir ay uzatıyor. Yeni sunucuda siteyi kuruyor ama alan adı hâlâ eskiyi gösterdiği için testi kendi bilgisayarında yerel eşleme ile yapıyor. Böylece ziyaretçiler ve tarayıcılar yeni sunucuyu henüz görmüyor. Bu sıra, hazırlığın geçiş gününden ayrı bir iş olduğunu gösterir.

Taşımayı hızlandırmak için sunucu performansı da gündeme gelir. Yeni hostingin daha hızlı olması beklenen bir kazanımdır, ama bunun sonucu yeni ortamda ölçülmelidir; yanıt süresi ve önbellek tarafı için TTFB, önbellek ve CDN rehberine bakabilirsiniz.

Kopyayı Canlıya Almadan Doğrulama: Noindex, Robots ve SSL

Yeni sunucuda site çalışır durumdayken bile, herkese açılmadan önce üç alanı doğrulamanız gerekir. Google'ın belgesi bu aşamayı "test ortamı oluştur" başlığıyla anlatır.

Erişimi kısıtlı test ortamı

Belge, yeni altyapıda IP adresiyle erişimi kısıtlanmış bir test ortamı kurmayı önerir. Herkese açık test gerekiyorsa geçici bir ana bilgisayar adı kullanılabilir; bu durumda belgeye göre sayfalarınızın HTML'ine ya da HTTP başlıklarına noindex kuralı eklemelisiniz. Test kopyasının yanlışlıkla dizine girmesi başlı başına bir olaydır; ayrıntısı için Google'ın indekslemediği sayfa teşhisi yazısındaki mantığı tersten okuyabilirsiniz.

Taşıma başlarken engelleri kaldırma

Aynı belge hatırlatır: taşımaya başlamaya hazır olduğunuzda yeni kopyadaki bu tür engelleri, yani robots.txt Disallow kurallarını ve noindex etiketlerini kaldırmayı unutmayın. Test için konan engel, geçiş günü açık unutulursa canlı site aramadan kaybolur. Bu adımı geçiş günü kontrol listesinin başına koyun ve kaldırmayı elle değil, ortam ayarıyla yapın.

Googlebot'un yeni altyapıya erişimi

Belge iki doğrulama ister. İlki, URL Denetim Aracı ile Googlebot'un yeni altyapıya erişebildiğini kontrol etmektir. İkincisi, güvenlik duvarı ve DoS koruma ayarlarının Googlebot'un DNS'e ya da barındırma sağlayıcısının sunucularına erişimini engellemediğinden emin olmaktır. Yeni sağlayıcılar sıklıkla agresif varsayılan koruma kurallarıyla gelir; bu kurallar tarayıcıyı yanlışlıkla engelleyebilir. Eski sunucuda çalışan kural listesini yenisiyle karşılaştırın.

SSL sertifikası ve güvenli bağlantı

Sertifikanın yeni sunucuda önceden hazır olması, geçiş anında kullanıcıya güvenlik uyarısı çıkmasını önler. Sertifikayı geçişten önce kurup tüm alan adı varyantlarını (www'li ve www'siz) kapsadığını doğrulayın. Yönlendirme zincirinin değişmediğinden emin olmak için www, https ve eğik çizgi kuralları da yeniden test edilmelidir; bu standartlaştırma için www ve www'siz sürüm, https ve eğik çizgi standardizasyonu yazısına bakın.

Search Console doğrulamasını koruma

Belge, HTML dosyası yöntemiyle doğrulama yaptıysanız mevcut doğrulama dosyasını yeni kopyaya da eklemenizi söyler. Meta etiketi ya da Google Analytics ile doğruladıysanız, yeni içerik yönetim sistemi kopyasında bunların bulunduğundan emin olun. Doğrulamanın kopmaması, taşımanın izlenebilmesi için temel koşuldur.

Karşılaştırma kontrol listesi

• Yeni kopyada ana sayfa, bir kategori, bir makale ve bir ürün sayfası eski sunucudakiyle aynı içerik ve başlıklarla açılıyor mu?
• HTTP durum kodları aynı mı (200, 301, 404)? Kod anlamları için HTTP durum kodları rehberine bakın.
• robots.txt ve sitemap dosyası yeni sunucuda doğru ve canlı alan adını gösteriyor mu?
• Geçici noindex ve Disallow kuralları geçiş gününe kadar kaldırılacak olarak işaretlendi mi?
• SSL sertifikası tüm varyantları kapsıyor mu?
• Güvenlik duvarı ve DoS koruması Googlebot'u engellemiyor mu?
• Search Console doğrulama yöntemi yeni kopyada çalışıyor mu?
• E-posta ve form gönderimi yeni sunucuda test edildi mi?

Gizli farklar nerede çıkar?

Aynı kodun iki sunucuda farklı davranması sık görülen bir durumdur. Sunucu yazılımı sürümü, PHP ya da benzeri çalışma ortamı sürümü, dosya izinleri ve karakter kodlaması gibi ayarlar farklıysa sayfalar aynı görünüp yanıt başlıkları farklı olabilir. Bu yüzden iki sunucudan aynı URL listesini isteyip yanıt kodları ve başlıkları karşılaştıran basit bir betik, elle gezmekten daha güvenilirdir. Karşılaştırmayı en az en çok trafik alan ve en çok bağlantı alan sayfalar için yapın.

DNS Geçiş Günü Adımları

Geçiş günü ana plan, hazırlık ve doğrulama bölümlerinde tamamlanan işlerin son adımını atmaktır. Gün içinde yeni bir karar vermek zorunda kalmamanız gerekir.

Zamanlama

Geçişi ziyaretçi sayısının düşük olduğu saatlere koyun ve ekibin izleme yapabileceği bir zamanı seçin. Belge belirli bir gün ya da saat önermez; bu nedenle site trafik verinize bakıp kendi düşük trafikli aralığınızı bulun. Aynı gün içinde başka büyük bir değişiklik (tasarım, eklenti güncellemesi, kampanya) yapmayın. Çok değişiklik aynı anda yapılırsa sorun çıktığında nedenini ayırmak zorlaşır.

Adım sırası

1. Önceki TTL değerinin gerçekten düşürüldüğünü ve bir haftadan uzun süredir geçerli olduğunu doğrulayın.
2. Yeni kopyadaki geçici noindex ve robots.txt Disallow kurallarını kaldırın.
3. Son bir veri senkronizasyonu yapın: sipariş, form ve yorum gibi geçişten önce eski sunucuya yazılan verileri yeni sunucuya taşıyın.
4. DNS kayıtlarını yeni hosting sağlayıcısını gösterecek şekilde güncelleyin. Belgenin ifadesi de budur.
5. Alan adı yayılımını herkese açık DNS araçlarıyla farklı konumlardan kontrol edin.
6. Canlı alan adında ana sayfa, kategori, makale ve ürün sayfalarını açın; yanıt kodlarını ve başlıkları kontrol edin.
7. Search Console'da URL Denetimi canlı testini çalıştırın.
8. Eski ve yeni sunucunun erişim kayıtlarını izlemeye başlayın.

DNS kaydı değişince e-posta ve alt alanlar

Alan adının A kaydını değiştirmek e-postayı doğrudan etkilemez, çünkü e-posta MX kayıtlarıyla yönlenir. Ancak bazı DNS panellerinde kayıtlar toplu yeniden oluşturulur ve MX, SPF, DKIM gibi kayıtlar kazara silinebilir. Geçişten önce mevcut DNS bölgesinin tam dökümünü alın ve geçişten sonra karşılaştırın. Alt alan adlarını (blog, mağaza, destek, API) tek tek listeleyin; her biri aynı sunucuda mı yoksa ayrı bir hizmette mi duruyor, açıkça yazın. Alan adının DNS yönetimini barındırma sağlayıcısına taşıyorsanız bu iş iki katmanlıdır: hem sunucu hem DNS sağlayıcısı değişir. Bu durumda önce yalnızca birini değiştirin; aynı gün iki katmanı birlikte değiştirmek sorun çıktığında nedeni ayırmayı zorlaştırır.

CDN ya da güvenlik katmanı ekleniyorsa

Google'ın belgesi hosting değişikliği kapsamına CDN'e geçişi de alır. CDN kullanıyorsanız önbelleğin geçiş sonrası temizlenmesi gerekir; aksi halde eski içerik ya da eski sunucudan alınan yanıtlar bir süre sunulabilir. CDN ve güvenlik duvarının bot filtreleme kurallarını da gözden geçirin: tarayıcıları meşru bot olarak tanıyıp tanımadığını, kural değişikliğinden sonra test edin. Belge Googlebot'un DNS'e ve barındırma sunucularına erişimini engellemeyecek ayarları ister; aynı ilke ek katmanlar için de geçerlidir.

Yazma işlemleri için veri çakışması

DNS geçişi anlık olmadığı için bir süre iki sunucu aynı anda trafik alabilir. Sipariş, üyelik ve form gibi yazma işlemleri olan sitelerde bu, verinin iki yere dağılması riski taşır. Geçiş sırasında kısa bir bakım penceresi koymak, eski sunucuyu salt okunur yapmak ya da veritabanını yeni sunucuya bağlamak gibi önlemleri önceden belirleyin. Belgede bu konu için bir öneri yok, çünkü yazma işlemlerinin düzeni siteye özgüdür. Seçtiğiniz yöntemi ekip içinde yazılı hâle getirin.

Geçiş günü karar kuralı

Kural basittir: DNS değişikliğinden sonraki ilk saatlerde canlı alan adı hata veriyorsa kaydı eski sunucuya geri döndürmek, hatayı yerinde çözmeye çalışmaktan daha güvenlidir, çünkü eski sunucu zaten açıktır. Geri dönüş yalnızca düşük TTL sayesinde hızlıdır; bu, TTL'yi önceden düşürmenin ikinci faydasıdır. Hata küçükse ve yeni sunucuda hızla düzeltilebiliyorsa yerinde düzeltin; kritik sayfaların bir bölümü 5xx dönüyorsa geri dönün.

İlk 72 Saat İzleme: Hata Kodu, Tarama ve Hız

Geçişten sonraki ilk günler, planın başarısını gösteren dönemdir. Burada amaç rakam avlamak değil, tutarsızlığı erken yakalamaktır.

Trafiğin eskiden yeniye kayışı

Google'ın belgesi, eski sunucuların günlüğünde trafiğin düştüğünü, yeni sunucularda buna karşılık gelen bir artış olduğunu görmeyi bekler. Her iki sunucunun erişim günlüklerini birlikte izleyin. Eski sunucudaki trafik yavaş yavaş azalırken yenisi artıyorsa DNS yayılımı normal ilerliyordur. Eski sunucuda trafik beklenenden uzun süre yüksek kalıyorsa bu, önbellekteki kayıtların hâlâ eski adrese işaret ettiğini ya da TTL'nin düşürülmediğini gösterebilir.

Sunucu hata kodları

Google'ın HTTP durum kodlarına dair belgesine göre 5xx ve 429 sunucu hataları Google tarayıcılarının taramayı geçici olarak yavaşlatmasına yol açar. 500 hatasında Google siteye ait tarama hızını düşürür ve düşüşün ölçüsü etkilenen tekil URL sayısıyla orantılıdır. Sunucu yeniden 2xx yanıt vermeye başladığında tarama hızı kademeli olarak artar. Aynı belgede 429 kodunun sunucunun aşırı yüklendiği sinyali olarak ele alındığı yazılıdır. Bu bilgiler yeni sunucunun kapasitesinin geçişte neden önemli olduğunu gösterir: yeni sunucu ilk günlerde yoğun bir tarama dalgasına hazır olmalıdır. Daha fazla ayrıntı için HTTP durum kodlarının Google tarayıcılarını nasıl etkilediğini (yeni sekmede açılır) anlatan belgeye bakabilirsiniz.

Kalıcı sunucu hatası ve dizinden düşme

Aynı belge, dizinde zaten bulunan URL'lerin korunduğunu ama sunucu hatası döndürmeye devam ederlerse zamanla dizinden düşürüldüğünü söyler. 502 ve 503 için dizinleme hattının kalıcı olarak sunucu hatası döndüren URL'leri kaldırdığını yazar. "Kalıcı" kelimesinin kaç gün anlamına geldiğine dair bir süre belgede yoktur. Bu nedenle bir sunucu hatasını "birkaç gün bekleyelim" diye bırakmayın; nedeni öncelikle çözün. DNS ve ağ hatalarına gelince, bu belge ilgili bölümlerin içeriğini sunmaz, yalnızca ayrı bir belgeye bağlantı verir; o konuda bu sayfadan çıkarım yapmayın.

Tarama hızı ve Search Console

Taşıma belgesi, geçişin hemen ardından Googlebot'un tarama hızında geçici bir düşüş görmenin normal olduğunu, ardından sonraki günlerde istikrarlı bir artış izlenebileceğini ve bu artışın taşıma öncesi düzeyi aşabileceğini söyler. Search Console'da tarama istatistikleri ile dizin kapsamı grafiklerini izleyin. Kısa süreli düşüşü panik nedeni yapmayın, ama düşüşün sürmesi ya da hata sayısının artması bir inceleme işaretidir.

Hız ve yanıt süresi

Yeni sunucuda yanıt süresi eskisinden kötüyse bu tarama hızını ve kullanıcı deneyimini etkileyebilir. İlk günlerde ana sayfa ve çekirdek şablonlar için yanıt süresini ölçün, önbellek katmanının çalıştığını doğrulayın. Eski değerleri taşıma öncesinde kaydettiyseniz karşılaştırma yapmak kolay olur. Bu ölçümleri taşıma öncesi ve sonrası aynı araçla, aynı koşullarda alın.

Sorun çıkarsa kimi aramalı, neyi geri almalı?

İzleme döneminde bir sorun bulduğunuzda kararı vermek için önceden bir sorumlu belirleyin. Sunucu tarafı sorunları barındırma sağlayıcısı, içerik ve yapılandırma sorunları geliştirici, arama görünürlüğüyle ilgili bulgular SEO sorumlusu çözer. Herkes aynı anda müdahale ederse hangi değişikliğin neyi düzelttiği bilinmez. Her müdahaleyi zaman damgasıyla bir günlüğe yazın. Geri alınabilir değişiklikleri (DNS kaydı, yapılandırma ayarı) önce, geri alınamayanları (veritabanı değişikliği) en son deneyin. Bir sorun yalnızca belirli alt dizinde ya da belirli şablonda görülüyorsa, DNS geri dönüşü yerine o şablonun sunucu ayarını düzeltmek daha az kesintiye yol açar.

Raporlama: yönetime ne söylenir?

Ajans ya da iç ekip olarak yönetime sunduğunuz taşıma raporu üç soruyu yanıtlamalıdır: geçiş planlandığı gibi mi gitti, hangi ölçüler normal sınırlar içinde, hangi ölçü hâlâ izleniyor. Sıralama ya da trafik sonucu vaat etmeyin. Belgelere göre tarama hızında geçici düşüş normaldir; raporda bunu önceden yazmak, düşüşü gören kişinin panik yapmasını engeller.

Günlük kontrol rutini

İlk üç günde her gün aynı küçük listeyi çalıştırın: canlı ana sayfanın kaynağında noindex yok, robots.txt tüm siteyi engellemiyor, sunucu hata oranı normal, yanıt süresi kabul edilebilir, iki sunucunun trafik dengesi beklendiği gibi. Sonuçları kısa bir tabloya yazın. Düzenli ve kısa bir rutin, dağınık ve sürekli bakmaktan daha hızlı sorun yakalar.

Eski Sunucuyu Kapatma Kararı

Eski sunucuyu kapatmak geri dönüşü zorlaştıran son adımdır, bu yüzden bir tarihe değil bir kanıta dayanmalıdır.

Belgenin ölçütü: trafik sıfıra inmiş olmalı

Google'ın belgesi, eski sağlayıcıya gelen trafik sıfıra indiğinde eski hosting altyapısını kapatabileceğinizi söyler. Belge sabit bir bekleme süresi vermez; karar, eski sunucunun günlüğündeki gerçek trafiğe bağlıdır. Bu bilgi bir takvim tarihini değil, bir gözlemi esas alır. Eski sunucuda yalnızca tarayıcı ve izleme araçlarına ait nadir istekler görünüyorsa, onları da tek tek inceleyip alt sistemlerin hâlâ eski adresi kullanıp kullanmadığını anlayın.

Kapatmadan önce kontroller

• Eski sunucuya gelen insan trafiği sıfıra indi mi, kalan istekler kimden geliyor?
• E-posta, ödeme geri çağrısı, API ve zamanlanmış görevler hâlâ eski sunucuya mı bağlanıyor?
• Eski sunucudaki tüm dosya ve veritabanı için tam yedek alındı mı?
• Eski sunucudaki sertifika ve yönlendirme kuralları yeni sunucuda karşılandı mı?
• TTL değeri normal seviyeye geri çekildi mi?
• Eski alt alan adları ve ek alan adları yeni sunucuya taşındı mı?

Karar kuralı

Eski sunucuyu şu üç koşul birlikte sağlandığında kapatın: erişim kaydında trafik sıfır ya da yalnızca bilinen otomatik istekler kalmış; en az bir tam izleme döngüsü boyunca (örneğin bir hafta) yeni sunucuda sorun görülmemiş; yedek doğrulanmış. Belge "bir hafta" gibi bir süre vermez; bu süre yalnızca kendi izleme döngünüze göre koyduğunuz bir iç güvenlik payıdır. Üç koşuldan biri eksikse kapatmayı erteleyin; fazladan birkaç gün hosting ücreti, hatalı bir kapatmanın bedelinden küçüktür.

Taşıma sonrası temizlik

Kapatmanın ardından TTL değerini normale döndürün, geçici test kayıtlarını silin, yeni sunucuda yedekleme ve izleme düzenini devreye alın. Taşımanın ardından birkaç hafta boyunca Search Console'daki dizin kapsamı ve tarama istatistiklerini haftalık izleyin. Sonuçlarınızı bir belgeye yazın: hangi adımın ne kadar sürdüğü ve nerede sürpriz çıktığı bir sonraki taşıma için değerli bir kayıttır. Google belgelerindeki öneriler ve arayüz adları değişebilir; uygulamadan önce güncel sayfaya bakın.

Taşıma bittikten sonra eski sunucudaki yedeği hemen silmeyin. Kısa süre erişilebilir bir arşiv olarak saklamak, fark edilmemiş bir dosya, e-posta kutusu ya da özel yapılandırma çıktığında kurtarma imkânı verir. Yedeğin nerede durduğunu, kimin erişebildiğini ve ne zaman silineceğini belgeye yazın. Kişisel veri içeren yedeklerin saklama süresinin kuruluşunuzun veri politikasına uyduğundan emin olun.

Taşıma planını tek sayfada toplamak

Sık Sorulan Sorular

Hosting değiştirirken TTL ne zaman düşürülmeli?

Google'ın hosting değişikliği belgesi, TTL değerini birkaç saat gibi muhafazakâr bir düşük değere çekmeyi ve bunu taşımadan en az bir hafta önce yapmayı önerir. Sebep, DNS ayarlarının genellikle belirtilen TTL değerine göre önbelleğe alınmasıdır. Düşürme işlemini geçiş gününe bırakırsanız eski önbellekler dolana kadar etkisi görünmez.

Hosting değişikliği sıralamayı düşürür mü?

Google'ın belgeleri bir sıralama sonucu vaat etmez ve sıralamaya etkisini bir sayıyla anlatmaz. Belge, geçişten sonra Googlebot'un tarama hızında geçici bir düşüş görmenin normal olduğunu, ardından istikrarlı bir artış izlenebileceğini söyler. Planlı bir geçişte amaç, kesinti ve engel olmadan geçmektir.

Eski sunucuyu ne zaman kapatabilirim?

Belgeye göre eski sağlayıcıya gelen trafik sıfıra indiğinde. Belge sabit bir gün sayısı vermez. Kapatmadan önce eski sunucudaki kalan istekleri inceleyin, yedeği doğrulayın ve e-posta, ödeme ve zamanlanmış görevlerin yeni sunucuya bağlandığını kontrol edin.

Geçişten sonra Googlebot'un tarama hızı düşerse ne yapmalıyım?

Google'ın belgesine göre geçişten hemen sonra tarama hızında geçici bir düşüş normaldir ve ardından birkaç gün içinde istikrarlı bir artış beklenir. Düşüş sürüyorsa ya da sunucu hataları artıyorsa 5xx ve 429 yanıtlarını, güvenlik duvarı kurallarını ve sunucu kapasitesini kontrol edin.

Test kopyasını yeni sunucuda nasıl korurum?

Google'ın belgesi, erişimi IP adresiyle kısıtlanmış bir test ortamı önerir. Herkese açık bir geçici ana bilgisayar adı kullanıyorsanız sayfalara noindex kuralı ekleyin. Taşımaya başlarken bu engelleri, yani noindex etiketlerini ve robots.txt Disallow kurallarını kaldırmayı unutmayın.

URL'ler değişmiyorsa yönlendirme gerekir mi?

Google'ın hosting değişikliği belgesi URL'lerin değişmediği taşımaları ele alır ve adımlar arasında eski ve yeni adres eşlemesi yoktur; asıl adım DNS kayıtlarını yeni sağlayıcıya yöneltmektir. Alan adı, protokol ya da yol yapısı değişiyorsa durum farklıdır ve ayrı bir taşıma planı gerekir.

İlgili rehberler: Web Sitesi Yenileme SEO Kontrol Listesi: Trafik Kaybetmeden Geçiş, WordPress Etiket ve Arşiv Sayfaları: Noindex Kararı, Test Ortamı Google'da İndekslendi: Kaldırma ve Önleme.

Sonuç

URL'ler değişmeden hosting taşımak, doğru sırayla yapıldığında yönetilebilir bir iştir. Google'ın belgesine göre TTL'yi taşımadan en az bir hafta önce düşük bir değere çekin, yeni kopyayı erişimi kısıtlı bir ortamda doğrulayın, Googlebot'un yeni altyapıya ulaşabildiğini URL Denetim Aracıyla kontrol edin, geçici noindex ve Disallow kurallarını geçiş başlarken kaldırın, sonra DNS kayıtlarını güncelleyin. Geçişten sonra iki sunucunun günlüğünü, sunucu hata kodlarını ve tarama istatistiklerini izleyin; tarama hızında kısa süreli düşüş normal sayılır. Eski sunucuyu bir takvim tarihine göre değil, eski sağlayıcıya gelen trafik sıfıra indiğinde kapatın. Hiçbir adım belirli bir sıralama sonucunu garanti etmez; amaç, tarayıcı ve ziyaretçi için kesintisiz bir geçiş yapmaktır.

Taşıma sonrası bağlantı profilinizi güçlendirmeyi düşünüyorsanız, Akua Adforce'ta backlink paketlerini inceleyebilirsiniz; kapsam ve koşullar ilgili ürün sayfasında yazılıdır.