Site Taşıma: Hosting Değişirken SEO ve AI Erişimi

Adresler aynı kaldığı sürece hosting değiştirmek Google sıralamasını kendiliğinden düşürmez; Google bu işi bir adres değişikliği değil, altyapı değişikliği olarak ele alır. Taşımada asıl risk erişimdir: yeni sunucunun güvenlik duvarı Googlebot'u ya da yapay zeka tarayıcılarını kapıda bırakabilir, e-posta kayıtları kaybolabilir, sertifika geç kurulabilir. Aşağıdaki sıra taşımadan önce çıkarılacak envanterle başlıyor, DNS geçiş penceresi ve yeni sunucunun yayından önce test edilmesiyle sürüyor, taşıma gününden sonraki 72 saatin saat saat izlenmesiyle bitiyor.

Hosting değişince Google sıralaması düşer mi?

Sayfa adresleri, içerik ve site yapısı aynı kaldıysa hosting değişikliği tek başına bir sıralama kaybı nedeni değildir. Google'ın hosting değişikliği belgesi bu durumu ayrı anlatıyor: hosting sağlayıcısını değiştirmek ya da bir CDN'e geçmek gibi, kullanıcının gördüğü URL'yi etkilemeyen taşımalar.

Aynı belge beklenen bir dalgalanmayı da yazıyor. Taşımadan hemen sonra Googlebot'un tarama hızında geçici bir düşüş görmek normaldir; ardından birkaç gün içinde tarama hızı kademeli olarak artar, taşımadan önceki seviyeyi aşabilir de.

Alarm, Googlebot'un yeni sunucuda ciddi bir sorunla karşılaşmasıdır: 5xx hataları, zaman aşımı, güvenlik katmanının bot isteklerini reddetmesi ya da yanlışlıkla taşınan bir noindex başlığı. Bu yüzden taşımadan sonra bir düşüş görülürse ilk bakılacak yer sunucunun markası değil, taşıma sırasında atlanmış olabilecek ayarlardır.

Site taşıma ile site yenileme aynı iş değil

Site taşıma (web site taşıma diye de aranır), aynı sitenin aynı adreslerle başka bir sunucuda yayına girmesidir; site yenileme ise tasarımın, altyapının ve çoğu zaman adreslerin de değiştiği iştir. Bu ayrım yapılacak işin listesini değiştirir. Yenilemede eski adresi yeni adrese bağlayan bir 301 yönlendirme haritası işin merkezindedir; adres değişmeyen bir taşımada böyle bir harita gerekmez.

E-ticarette iki iş birbirine karışabilir. Mağaza bir altyapıdan diğerine geçerken ürün adresleri de değişiyorsa bu artık hosting taşıması sayılmaz; o senaryo için ürün adresi eşleme tablosu ayrı bir hazırlık ister. Ayrımı tek soru yapar: taşımadan sonra herhangi bir sayfanın adres çubuğundaki metni değişecek mi? Cevap evetse bu yazı tek başına yetmez.

http'den https'e ya da www'lu sürümden www'suz sürüme geçmek de URL değişikliğidir. Bunu taşımayla aynı gün yapmayın; bir sorun çıktığında nedeni ayırt edemezsiniz.

Taşımadan önce envanter: sunucuda neler var?

Taşıma envanteri, eski sunucuda sitenin çalışmasını sağlayan her parçanın yazılı listesidir; yalnız dosyalar ve veritabanı değil, e-posta, sertifika, zamanlanmış görevler ve sunucu düzeyindeki kurallar da bu listeye girer. Görünmeyen parçalar eski sağlayıcıda sessizce çalıştığı için kolay unutulur.

Tablodaki yönlendirme ve başlık satırı, dosya kopyalanınca taşındı sanılabilecek bir kalemdir. Bu sitenin kendisi 3 Eylül 2026'da bir barındırma platformundan diğerine taşındığında, eski platformun kendiliğinden gönderdiği bir güvenlik başlığının (HSTS) yeni platformda kaybolduğu taşımadan sonra canlı ölçümle görüldü ve başlık yeni platformun kural dosyasına elle eklendi. Aynı geçişte eski platformun yönlendirme dosyasında kullanılan bir sözdiziminin yeni platformda geçersiz sayıldığı da ortaya çıktı. İkisi de dosya kopyalayarak değil, kuralları tek tek karşılaştırarak bulunabilecek farklardı.

Envanterin bir parçası da hesap listesidir: alan adı kaydı, DNS yönetimi, eski ve yeni barındırma hesabı kimin adına, şifreler kimde? Hesaplar işletme dışında birinin adınaysa taşımadan önce dijital varlık devir listesi ile bunu düzeltin.

WordPress ve cPanel sitelerinde taşıma nasıl yapılır?

WordPress site taşıma, dosyaların ve veritabanının yeni sunucuya kopyalanıp wp-config.php dosyasındaki veritabanı bağlantı bilgilerinin yeni sunucuya göre güncellenmesidir. Adres aynı kaldığı için veritabanındaki site adresini değiştirmeniz gerekmez. Bu ayrıntı önemlidir: sitenin adresini geçici bir test alan adına çevirip sonra geri çevirmek, WordPress'in serileştirilmiş veriyi sakladığı alanlarda hatalı arama-değiştir işlemine yol açabilir. Bir sonraki bölümdeki hosts dosyası yöntemi bu riski hiç doğurmaz.

Yeni sunucuda üç ayrıntıya bakın. PHP sürümü tema ve eklentilerle uyumlu olmalı. Önbellek eklentisi eski sunucunun yollarını tutuyor olabilir; taşımadan sonra önbelleği temizleyin. Yükleme ve bellek sınırları yeni pakette daha düşükse büyük veritabanı içe aktarımı yarıda kesilebilir; taşıma eklentileri de bu sınırlara tabidir.

cPanel site taşıma işinde panelin tam yedek özelliği dosyaları, veritabanlarını ve e-posta ayarlarını tek arşivde toplar. Bu arşivi yeni sunucuda geri yüklemek her pakette mümkün olmayabilir; paylaşımlı barındırmada geri yükleme yetkisi sizde değil sağlayıcıda olabilir. Taşıma tarihini belirlemeden önce yeni sağlayıcıya tam yedeği kimin geri yükleyeceğini, posta kutusu içeriklerinin arşive dahil olup olmadığını ve işlemin ne kadar süreceğini sorun. Cevabı yazılı alın.

Taşıma sırasında e-posta neden kesilir?

Taşımada e-postanın kesilmesine yol açan tipik hata, alan adının DNS yönetiminin yeni sağlayıcıya geçirilirken MX kaydının ve e-posta doğrulama kayıtlarının yeni DNS bölgesine aynen kopyalanmamasıdır. Site yeni sunucuda açılırken e-postalar sessizce eski sunucuya gitmeye devam edebilir. Bazen bunu ancak bir müşteri "e-postama dönmediniz" dediğinde fark edersiniz.

Önce e-postanın nerede barındığını netleştirin. E-posta ayrı bir posta hizmetindeyse web sitesini taşımak e-postayı etkilememeli; yalnız DNS bölgesindeki MX, SPF, DKIM ve DMARC kayıtlarının yeni DNS yönetimine birebir taşınması gerekir. E-posta eski hosting paketinin içindeyse durum farklıdır: posta kutuları da taşınacak demektir ve kutulardaki eski yazışmalar DNS değişikliğiyle kendiliğinden yeni sunucuya geçmez.

SPF kaydı ayrıca kontrol edilmeli. Site formlarınız e-postayı sunucunun kendisinden gönderiyorsa SPF kaydında eski sunucunun IP adresi yazıyor olabilir. O durumda yeni sunucudan giden form bildirimleri doğrulamadan geçemeyebilir. Taşımadan önce DNS bölgesinin tam dökümünü metin olarak alın ve geçişten sonra kayıt kayıt karşılaştırın.

DNS TTL düşürme ve geçiş penceresi

TTL (Time to Live), bir DNS kaydının internet servis sağlayıcılarının önbelleğinde ne kadar süre tutulacağını belirleyen değerdir. Google'ın hosting değişikliği belgesi, taşımadan en az bir hafta önce TTL değerini temkinli bir alt değere (örnek olarak birkaç saat) indirmeyi öneriyor; amaç, DNS değiştiğinde yeni adresin servis sağlayıcılara daha hızlı yayılması.

Pratikte bu bir takvim demektir. Taşıma gününden en az yedi gün önce A kaydının (ve varsa AAAA ile CNAME kayıtlarının) TTL değerini düşürürsünüz. Eski önbellekler eski TTL süresi dolunca yenilendiği için son gün düşürmek işe yaramaz. Taşıma günü kayıtları yeni sunucunun adresine çevirirsiniz. Birkaç gün sonra TTL'i eski değerine çekersiniz.

Geçiş penceresi için sitenizin en az ziyaret aldığı saatleri seçin, ama gece yarısı tek başınıza değişiklik yapmayın. DNS yayılırken bazı ziyaretçiler eski sunucuya, bazıları yeni sunucuya gider. Bu birkaç saatlik dönemde iki sunucu da çalışır durumda kalmalı ve eski sunucuda içerik değişikliği yapılmamalı. Örneğin bir emlak ofisinde pencere sırasında eski sunucuya eklenen ilan yeni sunucuda olmaz; içerik girişini dondurmak takvimin parçasıdır.

Yeni sunucuyu yayından önce hosts dosyasıyla test etmek

Hosts dosyası, bilgisayarınızın bir alan adını DNS'e sormadan önce baktığı yerel bir listedir; buraya alan adınızı yeni sunucunun IP adresiyle yazdığınızda yalnız sizin bilgisayarınız siteyi yeni sunucudan açar, dünyanın geri kalanı eski sunucuyu görmeye devam eder. macOS ve Linux'ta dosya /etc/hosts yolundadır; Windows'ta sistem klasörü altındaki drivers/etc/hosts dosyasıdır ve yönetici yetkisiyle düzenlenir.

Komut satırı tercih ediyorsanız curl aynı işi dosya düzenlemeden yapar: curl -I --resolve siteniz.com:443:YENİ_IP https://siteniz.com/ komutu isteği yeni sunucuya gönderir ve yanıt başlıklarını gösterir. Burada üç şeye bakın: durum kodu 200 mü, sertifika hatası var mı, x-robots-tag gibi beklenmeyen bir başlık dönüyor mu.

Google'ın belgesi testin kapsamını da sayıyor: sayfalar, görseller, formlar ve PDF gibi indirmeler tek tek açılmalı. Buna kendi akışlarınızı ekleyin. Bir diş kliniğinin sitesinde randevu formunu gerçekten gönderin ve bildirimin doğru kutuya düştüğünü görün. Bir e-ticaret sitesinde sepete ürün ekleyip ödeme sayfasına kadar gidin.

Belge ayrıca geçici bir alt alan adıyla (örnek olarak beta.example.com) herkese açık test yapmaya izin veriyor, ama o durumda test sitesinin dizine girmemesi için sayfalara noindex eklenmesini söylüyor. Bu noindex kuralının asıl siteye taşınmaması gerekir. Test için konan engel yayına taşınırsa Google sayfaları dizinden çıkarmaya başlayabilir; kontrol listesinde bu satır bu yüzden ayrı durur.

Taşıma sonrası robots.txt ve güvenlik duvarı botları engelliyor mu?

Yeni sunucuda arama motoru ve yapay zeka tarayıcılarının erişimini bozabilecek iki ayrı katman vardır: robots.txt dosyası ve sunucunun önündeki güvenlik duvarı veya bot koruması. İlki tarayıcıya "girme" der ve uyulmasını bekler; ikincisi isteği doğrudan reddeder. robots.txt her şeye izin verirken güvenlik duvarının bir yapay zeka tarayıcısına 403 döndürmesi mümkündür, ve bu durum ilk bakışta görünmez.

Google'ın belgesi bu konuda açık bir uyarı içeriyor: güvenlik duvarı yapılandırmanızı ve hizmet reddi (DoS) korumanızı kontrol edin, Googlebot'un DNS'e veya hosting sağlayıcısının sunucularına ulaşmasını engellemediğinden emin olun. Yeni sağlayıcılar varsayılan olarak bot koruması açık gelebilir ve bu koruma bilinmeyen kullanıcı aracılarını şüpheli sayabilir.

Yapay zeka arama tarafında OpenAI'ın tarayıcı belgesi, ChatGPT arama sonuçlarında görünmek için OAI-SearchBot'a robots.txt içinde izin verilmesini ve yayımlanan IP aralıklarından gelen isteklere izin verilmesini öneriyor. Aynı belgeye göre robots.txt güncellemesinin sistemlerine yansıması yaklaşık 24 saat sürebilir.

Kontrolün kısa yolu, aynı sayfayı farklı kullanıcı aracılarıyla isteyip yanıtları karşılaştırmaktır. Tarayıcı kimliğiyle 200 dönen sayfa GPTBot, OAI-SearchBot, ClaudeBot veya PerplexityBot kimliğiyle 403 ya da bir doğrulama sayfası dönüyorsa engel güvenlik katmanındadır. Bu testi elle yapmak için AI botu doğrulama adımları komutları ve yanıtların nasıl okunacağını veriyor; komut satırı kullanmak istemiyorsanız AI bot erişim testi aynı karşılaştırmayı tarayıcıdan yapıyor. Kullanıcı aracısı testinin bir sınırı var: güvenlik katmanı isteği IP adresine göre de değerlendirebilir, bu yüzden kesin kanıt sunucu erişim kayıtlarındadır.

Search Console'da ne kontrol edilir, ne yapılmaz?

Adresler değişmiyorsa Search Console'daki "Adres değişikliği" aracı kullanılmaz. Google'ın URL değişikliği olan taşıma belgesi bu aracın yalnız bir alan adından veya alt alan adından diğerine geçerken gerektiğini yazıyor; örnek olarak example.com'dan example.net'e geçişi veriyor. Aynı alan adında sunucu değiştirmek bu tanıma girmez.

Search Console'da yapılacak ilk iş doğrulamanın taşımadan sonra da çalışacağından emin olmaktır. Mülkü HTML dosyasıyla doğruladıysanız o dosya yeni sunucuya kopyalanmalı; meta etiketiyle doğruladıysanız etiket yeni sunucudaki şablonda bulunmalı. DNS kaydıyla doğrulama yapılan mülklerde TXT kaydının yeni DNS bölgesine taşınması gerekir. Doğrulama düşerse taşımanın en kritik günlerinde raporlara erişemezsiniz.

Taşıma günü ve sonrasında üç rapora bakılır. URL denetimi aracındaki canlı test, Googlebot'un sayfayı yeni sunucudan alıp alamadığını gösterir. Ayarlar altındaki tarama istatistikleri raporu yanıt kodlarının ve ortalama yanıt süresinin değişimini gösterir; Sayfa dizine ekleme raporu ise birkaç gün içinde "sunucu hatası" veya "engellendi" türü yeni bir artış olup olmadığını gösterir. Raporlar gecikmeli güncellenebilir; ilk saatlerde canlı test daha güvenilir göstergedir.

Hosting değişince hız ve sunucu konumu nasıl ölçülür?

Hız değişimi, taşımadan önce ve sonra aynı sayfaların aynı araçla ve aynı koşulda ölçülmesiyle anlaşılır; tek bir ölçüm veya farklı sayfaların karşılaştırılması bir şey söylemez. Taşımadan bir hafta önce ana sayfa, en çok ziyaret alan hizmet sayfası, bir ürün veya ilan sayfası ve iletişim sayfası için ölçüm alın. Sunucu yanıt süresini (TTFB) ayrıca not edin, çünkü hosting değişikliğinin doğrudan etkilediği değer odur. Ölçümlerin hangi sırayla yapılacağı ve hangisinin satışla ilişkilendirilebileceği için site hızı ölçüm sırası ayrıntılı bir yöntem veriyor.

Taşımada sorulan bir başka soru, sunucunun hangi ülkede olduğudur. Google'ın çok bölgeli siteler belgesi sunucu konumunu, sunucunun IP adresi üzerinden okunan ve sitenin hedef kitlesine dair sinyallerden biri olarak sayıyor; aynı belge, bazı sitelerin CDN kullandığı veya altyapısı daha iyi bir ülkede barındırıldığı için bunun kesin bir sinyal olmadığını da yazıyor. Ülke kodlu alan adı (ccTLD) ise belgede güçlü sinyal olarak geçiyor.

Türkiye'deki müşterilere hizmet veren bir sitenin yurt dışındaki bir sunucuya taşınması, belgeye göre hedeflemeyi tek başına belirlemez; ama Türkiye'den gelen ziyaretçinin yanıt süresini değiştirebilir. Kararı bu yüzden Türkiye'den, taşımadan önce ve sonra yapılan ölçüme göre verin.

Taşıma gününden sonraki ilk 72 saat: saat saat bakılacaklar

Taşımanın büyük kısmı DNS değiştikten sonraki üç günde doğrulanır. Aşağıdaki takvim, hangi saatte neye bakılacağını sıralıyor; saatler kesin kural değil, bir kontrol sırası önerisidir. Her satırdaki kontrol tamamlanmadan eski sunucu kapatılmaz.

Google'ın belgesi eski hostingin ne zaman kapatılacağını tek bir ölçüte bağlıyor: eski sağlayıcının sunucu kayıtlarında trafik sıfıra indiğinde. Takvime tarih yazmak yerine kayıtlara bakın. Kapatmadan önce son bir tam yedek alın.

Bu takvimdeki işler iki erişim düzeyine ayrılır. TTL'i düşürmek, siteyi hosts dosyasıyla gezmek, formu göndermek, e-postayı denemek ve farklı kimliklerle istek atmak bir DNS paneli ve bir tarayıcıyla yapılır. Veritabanını taşımak, güvenlik duvarında bot isteklerine kural yazmak ve eski platformun yönlendirme ile başlık kurallarını yeni platformun sözdizimine çevirmek ise sunucu yapılandırmasına erişim ister. İkinci gruptaki işlerin taşıma gününden önce kime verildiği yazılı olmalıdır; aksi hâlde 1-3. saatte bir bot engeli görüldüğünde kuralı değiştirebilecek kişi aranmaya başlanır. Bakım hizmeti aldığınız biri varsa taşımanın kimin sorumluluğunda olduğu web sitesi bakım sözleşmesi içinde yazılı olmalı. Sıfırdan bir site kurduruyorsanız alan adı, DNS, sertifika ve robots.txt kurulumunun teslim kapsamında olup olmadığını kurumsal web sitesi hizmeti kapsamıyla karşılaştırarak sorabilirsiniz.

Sıkça Sorulan Sorular

Hosting değiştirmek Google sıralamasını düşürür mü?

Sayfa adresleri, içerik ve site yapısı aynı kaldıysa hosting değiştirmek tek başına sıralama düşüşü nedeni değildir; Google bu durumu URL değişmeyen bir altyapı taşıması olarak ele alır. Taşımadan hemen sonra tarama hızında geçici düşüş normaldir. Kalıcı sorunun olası kaynakları Googlebot'un yeni sunucuda 5xx hatası alması, güvenlik duvarına takılması veya test sırasında konan bir noindex kuralının yayına taşınmasıdır.

Sunucu değiştirirken Search Console'da Adres değişikliği aracı kullanılmalı mı?

Hayır. Google'ın belgesine göre Adres değişikliği aracı yalnız bir alan adından veya alt alan adından diğerine geçerken gerekir, örneğin example.com'dan example.net'e. Aynı alan adında yalnız sunucu değişiyorsa bu araç kullanılmaz. Bunun yerine doğrulamanın yeni sunucuda çalıştığı, URL denetimi canlı testiyle Googlebot erişimi ve tarama istatistikleri kontrol edilir.

DNS değişikliği ne kadar sürede yayılır?

Süre DNS kayıtlarının TTL değerine ve servis sağlayıcıların önbelleğine bağlıdır, sabit bir rakam yoktur. Google, yayılmayı hızlandırmak için TTL değerini taşımadan en az bir hafta önce temkinli bir alt değere, örnek olarak birkaç saate indirmeyi öneriyor. Yayılma sürerken eski sunucu, erişim kayıtlarında trafik sıfıra inene kadar açık tutulmalıdır.

Site taşıdıktan sonra e-postalar neden gelmiyor?

İlk bakılacak neden, DNS yönetimi yeni sağlayıcıya geçirilirken MX kaydının ve SPF, DKIM, DMARC kayıtlarının yeni DNS bölgesine aynen kopyalanmamasıdır. E-posta eski hosting paketinin içindeyse posta kutuları ayrıca taşınmalıdır; eski yazışmalar DNS değişikliğiyle kendiliğinden yeni sunucuya geçmez. DNS bölgesinin taşıma öncesi dökümüyle karşılaştırma ve dış bir adresten test bu sorunu erken gösterir.

Yeni sunucunun yapay zeka botlarını engelleyip engellemediğini nasıl anlarım?

Aynı sayfayı normal tarayıcı kimliğiyle ve GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot gibi tarayıcı kimlikleriyle isteyip yanıt kodlarını karşılaştırırsınız. Tarayıcıya 200 dönen sayfa bot kimliğine 403 veya doğrulama sayfası dönüyorsa engel robots.txt'te değil, güvenlik duvarı ya da bot koruma katmanındadır. Güvenlik katmanı IP adresine de bakabildiği için kesin kanıt sunucu erişim kayıtlarındadır. OpenAI'ın belgesine göre robots.txt değişikliğinin sistemlerine yansıması yaklaşık 24 saat sürebilir.