Hosting Değiştirince SEO Sıralaması Düşer mi?

Hosting değişikliği neden gündeme gelir?

Bir web sitesi sahibi genelde üç sebepten hosting değiştirmeyi düşünür: mevcut sağlayıcı yavaş kalmıştır, destek yetersizdir ya da yenileme fiyatı beklenmedik şekilde artmıştır. Bu noktada akla gelen ilk endişelerden biri neredeyse her zaman aynıdır: "Yıllardır emek verdiğim Google sıralamam bu taşımadan zarar görür mü?" Bu endişe anlaşılırdır çünkü sıralama, bir sitenin en değerli ve en görünmez varlığıdır — kaybedildiğinde nedeni çoğu zaman net değildir. Bu yazıda önce Google'ın hosting değişikliğini gerçekte nasıl algıladığına, sonra sıralamayı asıl etkileyen teknik faktörlere, sık karşılaşılan efsanelere ve son olarak sıfır kayıpla taşımanın adım adım kurallarına, hazırlık kontrol listesine ve taşıma sonrası izleme sürecine bakacağız.

Konu internette o kadar çok çelişkili tavsiyeyle anlatılıyor ki, bazı site sahipleri "hosting değiştirmek riskli, elden geldiğince aynı firmada kal" gibi genel geçer bir korkuyla hareket ediyor. Bu korku, on yıl önce daha haklı bir gerekçeye dayanıyordu: eski dönemde taşıma süreçleri genelde manuel, gözetimsiz ve dokümansız yürütülüyor, bu da yukarıda sayılan hataların çok daha sık yaşanmasına yol açıyordu. Bugün taşıma araçları, otomatik yedekleme sistemleri ve DNS yönetim panelleri çok daha olgun; doğru süreçle çalışıldığında risk neredeyse sıfıra iner. Bu yazının amacı korkuyu ortadan kaldırmak değil, riski gerçekte nereden geldiğini göstererek onu yönetilebilir hale getirmektir.

Google, sitenizin nerede barındığını nasıl anlar?

Google'ın tarama robotu (Googlebot) bir sayfayı ziyaret ettiğinde alan adınızın hangi IP adresine yönlendirdiğine bakar, sayfayı indirir ve içeriği işler. Bu işlemin arka planda hangi şirketin sunucusunda, hangi ülkede veya hangi barındırma panelinde gerçekleştiği, sıralama algoritması için doğrudan bir sinyal değildir. Google'ın önemsediği, sonuçta ortaya çıkan deneyimdir: sayfa hızlı mı açılıyor, içerik arananı karşılıyor mu, site güvenli (HTTPS) mi, mobilde düzgün görünüyor mu. Dolayısıyla "hangi hosting firmasındayım" sorusunun kendisi bir sıralama faktörü değildir; asıl soru "bu değişiklik sonucunda site nasıl bir performans sergiliyor" sorusudur.

Paylaşımlı IP, özel IP ve "kötü komşu" efsanesi

Paylaşımlı (shared) hostingde birden fazla site aynı IP adresini kullanır. Bu durum uzun yıllar boyunca "aynı IP'deki bir site spam gönderirse benim sıralamam da düşer mi?" sorusunu doğurdu. Google, kendi yetkilileri aracılığıyla bu konuyu defalarca netleştirdi: modern arama algoritması alan adı bazında değerlendirme yapar, sadece IP paylaşımına bakarak bir siteyi cezalandırmaz. Bunun tek pratik istisnası, paylaşılan IP'nin e-posta gönderiminde kara listeye (blacklist) girmesidir — bu durum SEO'yu değil, giden e-postaların spam klasörüne düşme ihtimalini etkiler. Kaliteli bir hosting sağlayıcısı, paylaşımlı IP'lerin itibarını (reputation) düzenli izleyerek bu riski zaten en aza indirir.

Sunucu konumu (coğrafi konum) etkisi

Sunucunuzun fiziksel olarak hangi ülkede durduğu, hedef kitlenizle aynı ülkede değilse küçük bir gecikme (latency) farkı yaratabilir; bu da dolaylı olarak hız sinyallerine yansır. Ancak bu etki, bir CDN (içerik dağıtım ağı) kullanıldığında büyük ölçüde ortadan kalkar — CDN, statik içeriği ziyaretçiye coğrafi olarak en yakın sunucudan sunar. Türkiye'deki ziyaretçi kitlesine hizmet veren bir site için sunucunun Türkiye'de veya yakın bir Avrupa lokasyonunda olması genelde yeterlidir; bu, hosting seçerken performans açısından bakılması gereken bir noktadır, ama alan adı/URL aynı kaldığı sürece taşımanın kendisiyle ilgili bir SEO riski oluşturmaz.

SEO'yu asıl etkileyen faktörler

Hosting değişikliği sırasında sıralamayı etkileme potansiyeli olan beş teknik faktör vardır. Bunların hiçbiri "hosting değişti" diye otomatik devreye girmez — sadece taşıma kötü yönetilirse bir risk haline gelir.

Kesinti süresi ve Google'ın hoşgörüsü

Googlebot bir siteye ulaşamadığında bunu tek seferde ceza sebebi saymaz; birkaç dakikalık veya birkaç saatlik erişilemezlik genelde geçici bir sunucu hatası olarak yorumlanır ve tarama daha sonra tekrarlanır. Ancak kesinti günler sürerse ya da tekrarlı hale gelirse, Google siteyi güvenilmez bulup tarama sıklığını azaltabilir, ağır vakalarda sayfaları geçici olarak sonuçlardan çıkarabilir. Pratik eşik şudur: birkaç saatin altındaki kesintiler risksiz, gün aşan kesintiler risklidir.

Burada önemli bir ayrım var: Googlebot'un siteyi tarayamaması ile ziyaretçinin siteyi görememesi aynı şey değildir ama ikisi de aynı kesintinin sonucudur. Sunucunuz 500 (sunucu hatası) veya bağlantı zaman aşımı döndürüyorsa Google bunu "geçici" olarak sınıflandırır ve sabırlıdır; ancak sunucu 404 (bulunamadı) döndürüyorsa bu çok daha ciddi bir sinyaldir çünkü Google "bu sayfa artık yok" sonucuna varıp onu dizinden çıkarma sürecini başlatabilir. Bu yüzden taşıma sırasında geçici olarak devre dışı kalan bir sayfa, mümkünse 404 yerine 503 (hizmet geçici olarak kullanılamıyor) durum kodu döndürmelidir — bu, Google'a "az sonra geri döneceğim" mesajını verir.

URL ve site yapısı değişiklikleri

Bir sayfanın Google nezdindeki "sıralama değeri" o sayfanın tam adresine (URL'sine) bağlıdır. Taşıma sırasında sayfa adresleri değişir ve eskisinden yenisine yönlendirme (301 redirect) kurulmazsa, o adreste birikmiş yıllar süren sıralama değeri sıfırlanır ve yeni adres sıfırdan başlar. Alan adınız ve URL yapınız (örneğin /hakkimizda gibi adresler) taşıma sonrası aynı kalıyorsa bu risk ortadan kalkar — çoğu hosting taşımasında durum tam olarak budur.

Karışıklığın büyük kısmı şu ikisinin birbirine karıştırılmasından kaynaklanır: "hosting sağlayıcı değiştirmek" ile "web sitesi yenilemek/URL yapısını değiştirmek" iki farklı projedir. Birçok işletme bu ikisini aynı anda yapmayı tercih eder (yeni sağlayıcıya geçerken siteyi de yeniliyorum mantığıyla), ama bu iki değişikliği aynı anda yapmak, bir sorun çıktığında hangi değişikliğin sebep olduğunu ayırt etmeyi zorlaştırır. Mümkünse önce hosting taşımasını tamamlayıp birkaç hafta stabil çalıştığını doğrulamak, URL/tasarım yenilemesini ayrı bir proje olarak daha sonra planlamak çok daha güvenli bir yaklaşımdır.

Sunucu hızı ve Core Web Vitals

Google 2021'den beri sayfa deneyimini (Core Web Vitals: yükleme hızı, etkileşim gecikmesi, görsel kararlılık) doğrudan bir sıralama sinyali olarak kullanıyor. Yeni sunucu eskisinden yavaşsa bu sinyaller kötüleşir ve sıralamayı olumsuz etkileyebilir; yeni sunucu daha hızlıysa (örneğin NVMe SSD disk ve LiteSpeed sunucuya geçiliyorsa) sinyaller iyileşir ve sıralama zamanla olumlu etkilenebilir. Bu yüzden doğru planlanmış bir taşıma, risk değil fırsat olarak görülmelidir.

SSL sertifikası sürekliliği

HTTPS, 2014'ten beri bilinen bir sıralama faktörüdür. Taşıma sırasında SSL sertifikası unutulur ve site kısa süreliğine HTTP'ye (kilitsiz) düşerse, hem ziyaretçi tarayıcısında uyarı görür hem de Google bu durumu fark edebilir. İyi bir taşıma sürecinde yeni sunucuda SSL, yönlendirme değişmeden önce kurulup test edilir. Ayrıca sertifikanın hangi alan adları için geçerli olduğu (örneğin hem siteniz.com hem www.siteniz.com için mi) de taşıma sonrası mutlaka doğrulanmalıdır; bu ayrımın atlanması, ziyaretçilerin bir kısmının güvenlik uyarısı görmesine yol açabilir.

E-posta sürekliliği

Doğrudan bir sıralama faktörü olmasa da, taşıma sırasında kurumsal e-postalar kesintiye uğrarsa müşteri iletişimi ve marka güveni zedelenir — bu da dolaylı yoldan trafiğe ve davranışsal sinyallere yansır. Hosting taşımasında e-posta hesaplarının da dosyalarla birlikte eksiksiz taşındığından emin olunmalıdır. Özellikle SPF, DKIM ve DMARC gibi e-posta kimlik doğrulama kayıtlarının yeni sunucuda doğru şekilde yeniden oluşturulması gerekir; bu kayıtlar eksik veya hatalı taşınırsa gönderdiğiniz e-postalar alıcı tarafında spam klasörüne düşmeye başlayabilir — bu durum SEO'yu etkilemez ama işletmenin müşteri iletişimini doğrudan zedeler.

Hangi durumlarda gerçekten SEO kaybı yaşanır?

Yukarıdaki faktörleri birleştirdiğimizde, sıralama kaybının gerçekleştiği tipik senaryolar şöyle özetlenebilir (bunlar gerçek bir vakaya değil, sektörde sık görülen örüntülere aittir):

• Senaryo 1 — Sessiz kapatma: Eski site, yeni site tam olarak çalıştığı doğrulanmadan kapatılır; bir kısım sayfa günlerce 404 veya 500 hatası verir.
• Senaryo 2 — Unutulan yönlendirme: Site taşınırken URL yapısı da (örneğin yeni bir içerik yönetim sistemine geçilerek) değiştirilir ama eski adreslerden yenilerine 301 yönlendirmesi kurulmaz.
• Senaryo 3 — Yavaş sunucuya geçiş: Daha ucuz ama zayıf kapasiteli bir pakete geçilir, sayfa yükleme süresi belirgin şekilde artar.
• Senaryo 4 — DNS karmaşası: İsim sunucuları (nameserver) ve DNS kayıtları yanlış girilir, site saatlerce hem ziyaretçiler hem Googlebot için erişilemez kalır.
• Senaryo 5 — robots.txt/noindex kazası: Yeni sunucuda test amaçlı konan "Disallow: /" veya "noindex" etiketi, yayına geçerken kaldırılmayı unutulur.

Bu beş senaryonun her biri aslında önlenebilir niteliktedir. Sessiz kapatma, "müşteri onayı" adımının atlanmasıyla; unutulan yönlendirme, URL eşleştirme tablosunun hazırlanmamasıyla; yavaş sunucuya geçiş, taşıma öncesi bir hız testi yapılmamasıyla; DNS karmaşası, TTL planlamasının atlanmasıyla; robots.txt kazası ise yayın öncesi kontrol listesinin uygulanmamasıyla doğrudan ilişkilidir. Başka bir deyişle, bu beş senaryonun hepsi aynı kök nedene, yani eksik planlamaya bağlanır — teknik olarak hiçbiri kaçınılmaz değildir.

Görüldüğü gibi bu beş senaryonun ortak paydası hosting firması değişikliği değil, sürecin yönetim hatasıdır. Aynı senaryolar aynı sağlayıcıda kalıp yanlış bir güncelleme yapıldığında da yaşanabilir — örneğin bir eklenti güncellemesi sitenizi geçici olarak 500 hatası verdirebilir ya da bir tema değişikliği farkında olmadan sayfa adreslerini değiştirebilir. Bu da gösteriyor ki asıl güvence, "hangi sağlayıcıda olduğunuz" değil, "değişiklikleri ne kadar planlı ve kontrollü yaptığınızdır."

Hosting ve SEO hakkında yaygın 6 efsane

Bu konuda internette dolaşan pek çok yanlış bilgi var. En sık karşılaşılan altı efsaneyi ve gerçek durumu aşağıda sıraladık:

Efsane 1: "Hosting değiştirmek Google'da sıfırdan başlamak demektir"

Gerçek: Alan adınız ve URL yapınız aynı kaldığı sürece biriken sıralama değeri korunur. Sıfırlanma riski sadece alan adı da değişirse ve yönlendirme kurulmazsa ortaya çıkar. Bu efsanenin yaygınlığı, geçmişte kötü yönetilen birkaç taşımanın hikâyesinin abartılarak yayılmasından kaynaklanır; oysa aynı kişiler genelde sorunun asıl sebebinin (yönlendirme eksikliği) farkında olmadan hikâyeyi "hosting değiştirmek riskliymiş" şeklinde özetler.

Efsane 2: "Ucuz hosting her zaman SEO'ya zarar verir"

Gerçek: Fiyat değil, performans önemlidir. Ucuz bir paket yeterli hızda çalışıyorsa sorun yoktur; pahalı bir paket yanlış yapılandırılmışsa yine de yavaş olabilir. Burada bakılması gereken somut ölçüt fiyat etiketi değil, gerçek bir hız testi aracıyla ölçülen yükleme süresi ve sunucu yanıt zamanıdır (TTFB — time to first byte).

Efsane 3: "Sunucu ülkesi mutlaka hedef ülkeyle aynı olmalı, yoksa sıralama düşer"

Gerçek: CDN kullanıldığında bu etki büyük ölçüde ortadan kalkar; sunucu konumu, birebir bir sıralama cezası değil, dolaylı bir hız faktörüdür. Yerel bir hedef kitleniz varsa yerel sunucu elbette avantajlıdır, ama global bir kitleye hitap ediyorsanız iyi yapılandırılmış bir CDN, tek bir coğrafi konumdaki sunucudan çok daha tutarlı bir deneyim sunabilir.

Efsane 4: "Taşıma sırasında birkaç saatlik kesinti sıralamayı kalıcı olarak düşürür"

Gerçek: Google, kısa süreli kesintilere karşı toleranslıdır; kalıcı hasar genelde ancak günler süren erişilemezlik ya da tekrarlı kesintilerde ortaya çıkar. Tek seferlik, birkaç saatlik bir kesinti genelde bir sonraki tarama döngüsünde fark edilmeden geçer.

Efsane 5: "Aynı IP'yi paylaştığım bir site cezalandırılırsa ben de cezalandırılırım"

Gerçek: Google alan adı bazında değerlendirme yapar. Paylaşımlı IP'nin tek somut riski e-posta itibarıdır, arama sıralamasıyla ilgili değildir. Yine de kaliteli bir sağlayıcı, paylaşımlı IP'lerdeki kötüye kullanımı (spam, kötü amaçlı yazılım) izleyip hızlıca müdahale ederek bu riski zaten sizin adınıza yönetir.

Efsane 6: "301 yönlendirmesi sıralama değerinin bir kısmını her zaman kaybettirir"

Gerçek: Google, 301 yönlendirmesinin artık PageRank/sıralama değerini düşürmediğini resmen açıkladı; doğru kurulmuş bir 301 yönlendirmesi büyük ölçüde eşdeğer kabul edilir. Eski dönemde (2016 öncesi) bu yönlendirme türünde küçük bir değer kaybı olduğu biliniyordu, ancak Google bu davranışı güncelleyerek 301'i 302 (geçici yönlendirme) ile neredeyse eşdeğer sinyal gücüne getirdi. Yine de yönlendirme zincirlerinin (A adresinden B'ye, B'den C'ye art arda yönlendirme) mümkün olduğunca kısa tutulması, hem hız hem netlik açısından önerilir.

Bu altı efsanenin ortak noktası, hepsinin "hosting/teknik bir detay otomatik olarak sıralamayı etkiler" varsayımına dayanmasıdır. Oysa Google'ın resmi kaynakları ve sektör deneyimleri, bu detayların ancak kullanıcı deneyimini kötüleştirdiği ölçüde dolaylı bir etkisi olduğunu gösteriyor. Bu da yazının başındaki kısa cevaba geri dönüyor: önemli olan sunucunun kimin olduğu değil, o sunucu üzerinden sunulan deneyimin kalitesidir.

Hosting türüne göre taşıma riski karşılaştırması

Sahip olduğunuz hosting türü, taşımanın karmaşıklığını ve dolayısıyla riskini etkiler. Aşağıdaki tablo genel bir karşılaştırma sunar:

Hosting türü	Taşıma karmaşıklığı	Tipik risk noktası
Paylaşımlı web hosting (tek site)	Düşük	Genelde dosya + veritabanı kopyalamaktan ibarettir, DNS değişikliği tek adımdır.
Paylaşımlı hosting (çoklu alt alan adı/e-posta)	Orta	Tüm alt alan adlarının ve MX kayıtlarının eksiksiz taşınması gerekir.
VDS / özel sunucu	Orta-yüksek	Sunucu yapılandırması (PHP sürümü, modüller, güvenlik duvarı kuralları) elle yeniden kurulmalıdır.
E-ticaret (stok, sipariş, ödeme entegrasyonu)	Yüksek	Canlı sipariş verisi kaybedilmemeli, ödeme sağlayıcı entegrasyonları yeniden test edilmelidir.
Bayi (reseller) hosting	Yüksek	Birden fazla müşteri hesabı aynı anda ve sırayla, her biri için ayrı onay alınarak taşınmalıdır.

Kendi durumunuz bu tablodaki hangi satıra yakınsa, taşıma öncesi hazırlık süreniz de o ölçüde uzun tutulmalıdır. Basit bir kurumsal site birkaç saatte taşınırken, canlı sipariş alan bir e-ticaret sitesi için birkaç günlük bir test ve doğrulama süreci ayırmak daha sağlıklıdır.

Büyük ve çok sayfalı sitelerde taşıma stratejisi

Birkaç sayfalık bir kurumsal site ile binlerce ürün/sayfa barındıran bir e-ticaret veya haber sitesini taşımak aynı hassasiyeti gerektirmez. Yüzlerce veya binlerce sayfası olan bir sitede dikkat edilmesi gereken ek noktalar şunlardır: Kademeli tarama izni: Taşıma sonrası Googlebot'un tüm siteyi yeniden taraması zaman alır; bu süreçte sunucu kaynaklarının ani tarama yüküne hazır olması (yeterli işlemci/bellek) önemlidir, aksi halde yavaşlama yaşanıp taramanın kendisi olumsuz etkilenebilir. Öncelikli sayfaları belirleme: En çok trafik alan ilk 50-100 sayfa taşıma sonrası ilk kontrol edilecek liste olarak ayrılmalı, bu sayfalarda herhangi bir 404/500 hatası anında fark edilmelidir. Sitemap parçalama: Çok büyük sitelerde tek bir sitemap.xml yerine kategoriye göre bölünmüş birden fazla sitemap dosyası, Google'ın taramayı önceliklendirmesine yardımcı olur. Aşamalı geçiş: Mümkünse önce sitenin bir bölümü (örneğin blog alt alan adı) taşınıp birkaç gün izlenir, sorun çıkmazsa geri kalan bölüm taşınır — bu, riski tek seferde almak yerine küçük parçalara bölerek yönetmenin bir yoludur.

Büyük içerikli sitelerde bir diğer pratik önlem, taşıma sonrası ilk günlerde sunucu günlük kayıtlarının (log dosyaları) düzenli izlenmesidir. Bu kayıtlar, Googlebot'un hangi sayfaları ne sıklıkla taradığını ve herhangi bir sayfada hata alıp almadığını gösterir; büyük bir sitede bu veri, Search Console'daki özet raporlardan çok daha erken ve ayrıntılı bir uyarı sağlar.

Taşıma öncesi hazırlık: kontrol listesi

Asıl taşıma sürecine başlamadan önce, aşağıdaki hazırlık kontrol listesinin tamamlanmış olması gerekir:

• Mevcut sitenin tam bir yedeği (dosyalar + veritabanı) alınıp güvenli bir yerde saklanıyor mu?
• Tüm alan adı ve alt alan adı listesi (ana site, blog, mağaza, panel gibi) çıkarıldı mı?
• Mevcut DNS kayıtlarının tam bir dökümü (A, MX, TXT, CNAME) alındı mı?
• Kurumsal e-posta hesaplarının listesi ve şifreleri güvenli şekilde not edildi mi?
• SSL sertifikası bilgisi (kendi aldığınız bir sertifika mı, yoksa sağlayıcı mı veriyor) belirlendi mi?
• Üçüncü taraf entegrasyonlar (ödeme sağlayıcı, canlı destek, kargo takip gibi) listelendi mi?
• Taşıma için uygun, düşük trafikli bir zaman aralığı belirlendi mi?
• Taşıma sonrası kontrol edilecek öncelikli sayfaların listesi hazırlandı mı?

Bu sekiz maddenin tamamı işaretlenmeden asıl taşımaya başlanmaması, sürecin en kritik güvenlik önlemidir — çoğu "sürpriz" sorun, aslında bu hazırlık aşamasında atlanan bir maddeden kaynaklanır. Bu listeyi bir kontrol tablosuna (checklist) dönüştürüp taşımadan sorumlu kişiyle (kendiniz, iç ekibiniz veya yeni sağlayıcınız) paylaşmanız, sorumluluğun net şekilde dağıtılmasını ve hiçbir maddenin "birinin yaptığını sandığı ama kimsenin yapmadığı" bir boşlukta kalmasını önler.

Doğru taşımanın adımları

Hazırlık tamamlandıktan sonra, sıfır kesintili ve SEO açısından risksiz bir taşıma sırayla şu adımları izler:

1. Envanter çıkarma: Mevcut sitenin tüm dosyaları, veritabanı, e-posta hesapları ve DNS kayıtları listelenir. Bu adım hazırlık kontrol listesiyle birebir örtüşür ve atlanırsa sonraki tüm adımlar sağlıksız bir zemine oturur.
2. Yeni sunucuda hazırlık: Site, geçici bir test adresinde (örneğin IP adresi veya alt alan adı üzerinden) birebir kopyalanır. Bu aşamada gerçek ziyaretçiler hâlâ eski siteyi görmeye devam eder, hiçbir kesinti yaşanmaz.
3. İşlevsellik testi: Formlar, ödeme sayfaları, veritabanı bağlantıları, e-posta gönderimi yeni sunucuda tek tek test edilir. Bu, taşımanın en çok zaman ayrılması gereken adımıdır çünkü gözden kaçan tek bir form, canlıya geçtikten sonra fark edilirse müşteri kaybına yol açabilir.
4. SSL kurulumu: Yeni sunucuda SSL sertifikası kurulur ve HTTPS'in sorunsuz çalıştığı doğrulanır. Karışık içerik (mixed content) uyarısı verip vermediği de bu aşamada kontrol edilmelidir.
5. DNS TTL süresinin düşürülmesi: Yönlendirme değişikliğinden birkaç gün önce DNS kayıtlarının TTL (yaşam süresi) değeri düşürülür ki değişiklik hızlı yayılsın.
6. Müşteri onayı: Yeni sunucudaki kopya, siz kontrol edip onaylayana kadar canlıya alınmaz. Bu adım, sürecin tek "insan kontrol noktasıdır" ve atlanmaması gereken en önemli güvenlik kemeridir.
7. Yönlendirme değişikliği: Alan adı DNS ayarları yeni sunucuyu gösterecek şekilde güncellenir.
8. Geçiş penceresinin izlenmesi: DNS değişikliğinin yayılma süresi boyunca (genelde birkaç saat) her iki sunucu da izlenir; bu sürede gelen talepler her iki tarafta da karşılanabilir olmalıdır.
9. Eski sunucunun kapatılması: Yeni sunucunun tam olarak çalıştığı en az birkaç gün doğrulandıktan sonra eski hesap kapatılır.
10. Son kontrol: Search Console, Analytics ve hız testleriyle taşımanın sorunsuz tamamlandığı teyit edilir.

Bu on adımın her biri basittir ama sırası önemlidir — özellikle "müşteri onayı" ve "eski sunucunun kapatılması" adımları atlanırsa geri dönüşü zor durumlar ortaya çıkabilir.

Taşıma sırasında sık yapılan hatalar

Aşağıdaki tablo, en sık karşılaşılan taşıma hatalarını, neden riskli olduklarını ve doğru yaklaşımı bir arada özetliyor:

Hata	Neden riskli	Doğru yaklaşım
Taşımayı yoğun trafik saatinde yapmak	Olası bir aksaklık en çok ziyaretçiyi etkiler	Trafiğin en düşük olduğu gece saatleri tercih edilir
TTL'i düşürmeden yönlendirmeyi değiştirmek	Yayılma süresi 24-48 saate kadar uzayabilir	TTL, değişiklikten 1-2 gün önce 300 saniyeye çekilir
Test amaçlı "noindex"i unutmak	Site aramalardan tamamen düşebilir	Yayına almadan önce kontrol listesiyle mutlaka doğrulanır
MX kayıtlarını atlamak	Kurumsal e-postalar aniden gelmemeye başlar	E-posta, dosyalarla birlikte taşıma planına dahil edilir
Karakter kodlamasını kontrol etmemek	Türkçe karakterler bozulabilir	Veritabanı UTF-8 kodlamasıyla dışa/içe aktarılır
Eski sunucuyu hemen kapatmak	Sorun çıkarsa geri dönüş imkânı kalmaz	En az birkaç gün, tercihen 1-2 hafta beklenir
SSL kurulumunu son güne bırakmak	Kısa süreli güvenlik uyarısı riski	SSL, yönlendirmeden önce kurulup test edilir
Taşıma sonrası kontrolü atlamak	Sorun fark edilmeden büyür	Search Console + hız testi standart adım haline getirilir

DNS ve TTL yönetimi

DNS (Domain Name System), alan adınızı sunucunuzun IP adresine bağlayan sistemdir. Her DNS kaydının bir TTL (Time To Live) değeri vardır — bu, tarayıcıların ve internet servis sağlayıcılarının o kaydı ne kadar süreyle önbellekte tutacağını belirler. Varsayılan TTL genelde 3.600 saniye (1 saat) ile 86.400 saniye (24 saat) arasındadır. Bir taşıma planlıyorsanız, değişiklikten 24-48 saat önce TTL değerini 300 saniyeye (5 dakika) düşürmeniz önerilir; böylece asıl yönlendirme değişikliği yapıldığında bu değişiklik dünya genelinde çok daha hızlı yayılır ve "bazı ziyaretçiler eski siteyi, bazıları yeni siteyi görüyor" karışıklığı kısalır. Yönlendirme tamamen tamamlanıp birkaç gün stabil kaldıktan sonra TTL değeri tekrar normale (1 saat veya üzeri) çekilebilir.

Burada iki farklı değişiklik türünü ayırt etmek gerekir. Eğer yalnızca alan adınızın gösterdiği A kaydı (IP adresi) değişiyorsa, bu genelde birkaç saat içinde yayılır. Ama isim sunucularının (nameserver) kendisi değişiyorsa — örneğin alan adı kayıt kuruluşunuzdaki NS kayıtları yeni sağlayıcının isim sunucularını gösterecek şekilde güncelleniyorsa — bu değişikliğin dünya genelinde tam olarak yayılması 24-48 saate kadar sürebilir, çünkü NS kayıtlarının kendi TTL değeri genelde daha yüksek ve sizin kontrolünüzde değildir. Bu yüzden nameserver değişikliği yapılacaksa, geçiş penceresinin daha uzun tutulması ve her iki sunucunun da bu süre boyunca ayakta tutulması gerekir. Değişikliğin ne kadar yayıldığını dünya genelinde farklı noktalardan kontrol etmek için genel DNS yayılım kontrol araçları (örneğin "DNS propagation checker" araması ile bulunabilecek ücretsiz servisler) kullanılabilir.

Bir diğer sık karıştırılan konu, DNS kayıtlarını değiştirmenin alan adının kendisini değiştirmekle aynı şey olmadığıdır. DNS ayarları, alan adınızın hangi sunucuya işaret ettiğini belirler; alan adının mülkiyeti veya kayıt kuruluşu (registrar) bundan bağımsızdır. Yani hosting sağlayıcınızı değiştirmek için alan adınızı başka bir kayıt kuruluşuna taşımanıza gerek yoktur — sadece DNS kayıtlarınızın yeni sunucuyu göstermesi yeterlidir.

Google Search Console'da yapılması gerekenler

Alan adınız ve URL yapınız değişmeden sadece hosting sağlayıcısı değişiyorsa, Search Console'da hiçbir işlem yapmanıza gerek yoktur — Google için görünen adres aynıdır. Ancak şu durumlarda ek adımlar gerekir:

• Alan adı da değişiyorsa: Search Console'daki "Adres Değişikliği" (Change of Address) aracı kullanılmalı ve eski alan adından yeni alan adına 301 yönlendirmesi kurulmalıdır. Bu araç, Google'a "bu site artık şu adreste" bilgisini doğrudan iletir ve geçiş sürecini hızlandırır.
• URL yapısı değişiyorsa (örneğin farklı bir CMS'e geçiliyorsa): tüm eski adresler için tek tek 301 yönlendirmesi hazırlanmalı, güncel sitemap.xml yeniden gönderilmeli. Yüzlerce sayfası olan bir sitede bu eşleştirmenin bir tabloda (eski URL → yeni URL) çıkarılması, hiçbir sayfanın atlanmadığından emin olmanın en güvenli yoludur.
• Taşıma sonrası: "Kapsam" (Coverage) raporu birkaç gün takip edilerek ani bir hata artışı olup olmadığı kontrol edilmelidir. Özellikle "Sunucu hatası (5xx)" ve "Bulunamadı (404)" kategorilerindeki ani yükselişler, taşımada bir sorun olduğunun en erken sinyalidir.
• Performans raporu: Taşıma öncesi ve sonrası tıklama/gösterim sayıları karşılaştırılarak organik trafikte beklenmedik bir sapma olup olmadığı izlenmelidir.

Taşıma sonrası izleme ve doğrulama

Taşıma tamamlandıktan sonra ilk 1-2 hafta düzenli olarak şu kontroller yapılmalıdır:

• Google Search Console — Kapsam raporu: Taranan ve dizine eklenen sayfa sayısında ani bir düşüş olup olmadığı izlenir.
• Google Analytics (veya benzeri): Organik trafik grafiğinde taşıma tarihine denk gelen anormal bir kırılma olup olmadığı kontrol edilir.
• PageSpeed Insights / Core Web Vitals: Yeni sunucudaki hız puanı eski sunucununkiyle karşılaştırılır.
• Manuel gezinme: Sitenin en çok trafik alan 10-15 sayfası tarayıcıdan elle açılıp doğru yüklendiği teyit edilir.
• Uptime izleme: Yeni sunucunun kararlılığı bir izleme aracıyla en az birkaç hafta takip edilir.
• E-posta teslimat testi: Kurumsal e-posta hesaplarından test maili gönderilip alındığı, spam klasörüne düşmediği doğrulanır.
• Form ve entegrasyon testi: İletişim formları, ödeme sayfaları ve üçüncü taraf entegrasyonları (canlı destek, CRM, ödeme sağlayıcı) yeniden test edilir.

Bu kontroller sonunda bir sorun görülmüyorsa taşıma başarılı sayılır ve endişeye gerek yoktur; sıralamalarda kısa vadeli küçük dalgalanmalar normaldir ve genelde birkaç hafta içinde stabilize olur. Burada gerçekçi bir beklenti yönetimi önemlidir: Google'ın yeni sunucu hızını tam olarak "öğrenip" sıralama sinyallerine yansıtması bazen birkaç haftayı bulabilir; taşımadan üç dört gün sonra hâlâ eski trafiği görüyor olmak paniğe sebep olmamalıdır. Bu dönemde günlük değil haftalık karşılaştırma yapmak, kısa vadeli gürültüyü gerçek bir sorundan ayırt etmenin en pratik yoludur.

Hosting sağlayıcınızı seçerken taşıma kolaylığına nasıl bakılır?

Bir sonraki taşımanın da sorunsuz geçmesini istiyorsanız, yeni sağlayıcıyı seçerken şu noktalara dikkat etmek gelecekteki riskleri azaltır:

• Ücretsiz taşıma desteği sunuyor mu? Sağlayıcının kendi ekibi taşımayı üstleniyorsa insan hatası riski büyük ölçüde azalır.
• Standart yedekleme sıklığı nedir? Günlük otomatik yedekleme, taşıma sırasında veya sonrasında bir sorun çıkarsa geri dönüş imkânı sağlar.
• Panel erişimi (cPanel/Plesk) veriyor mu? Kendi dosyalarınıza ve veritabanınıza tam erişiminiz olması, ileride başka bir sağlayıcıya geçmeyi de kolaylaştırır — "vendor lock-in" riskinden kaçının.
• Destek kanalı ne kadar hızlı yanıt veriyor? Taşıma sırasında ortaya çıkan bir sorunun hızlı çözülmesi, kesinti süresini doğrudan kısaltır.
• Sunucu izleme ve uyarı sistemi var mı? Sağlayıcının 7/24 sunucu izlemesi, bir sorun sizin fark etmenizden önce tespit edilip müdahale edilmesini sağlar.
• Kurulum ve taşıma süreciyle ilgili yazılı bir taahhüt sunuyor mu? "Ücretsiz taşıma yapıyoruz" demekle "kesinti yaşanmayacağını yazılı olarak taahhüt ediyoruz" demek arasında ciddi bir fark vardır; ikincisi sağlayıcının sürece ne kadar hazırlıklı olduğunun bir göstergesidir.

Bu kriterlerin çoğu, aslında yalnızca ilk taşımanız için değil, ileride ihtiyaç duyabileceğiniz her türlü değişiklik (paket yükseltme, ek alan adı ekleme, sunucu bakımı) için de geçerlidir. İyi bir sağlayıcıyla çalışmak, taşımayı bir kerelik bir kriz değil, standart ve öngörülebilir bir hizmet talebi haline getirir.

Taşımanın SEO için bir fırsata dönüştüğü durumlar

Doğru planlanmış bir hosting taşıması aslında sıralamayı iyileştirme fırsatıdır:

• Hız kazancı: NVMe SSD disk ve modern sunucu yazılımına geçiş, sayfa yükleme süresini belirgin şekilde kısaltabilir — bu doğrudan Core Web Vitals'a yansır.
• Güncel PHP/veritabanı sürümleri: Eski sunucularda kalan güncel olmayan yazılım sürümleri hem güvenlik hem performans riski taşır; taşıma bu güncellemeyi yapmak için doğal bir fırsattır.
• Temiz bir başlangıç: Taşıma sırasında kullanılmayan eklenti, ölü sayfa ve gereksiz yönlendirme zincirlerinin temizlenmesi site sağlığını iyileştirir.
• SSL/güvenlik iyileştirmesi: Yeni sunucuda daha güncel güvenlik önlemleri (güvenlik duvarı, kötü amaçlı yazılım taraması) devreye alınabilir.
• Modern görsel/kod optimizasyonu: Yeni sunucularda genelde daha güncel sıkıştırma ve önbellekleme teknolojileri (HTTP/2, Brotli sıkıştırma gibi) hazır gelir, bu da ek bir müdahale gerektirmeden hız kazandırır.

Nitekim bazı işletmeler hosting taşımasını bilinçli olarak "hız sıfırlama" fırsatı olarak kullanır: yıllar içinde birikmiş eklenti kalıntıları, kullanılmayan temalar ve şişmiş veritabanı tabloları eski sunucuda kalır, yeni sunucuda yalnızca gerçekten kullanılan dosyalar taşınır. Bu "temiz taşıma" yaklaşımı, taşıma sonrası hız testlerinde genelde gözle görülür bir iyileşme sağlar.

Bu yazıda geçen teknik terimler

DNS (Domain Name System)

Alan adınızı sunucunuzun IP adresine çeviren, internetin adres defteri gibi çalışan sistem.

TTL (Time To Live)

Bir DNS kaydının tarayıcılar ve servis sağlayıcılar tarafından ne kadar süre önbellekte tutulacağını belirten değer.

301 yönlendirme (redirect)

Bir adresin kalıcı olarak başka bir adrese taşındığını tarayıcılara ve arama motorlarına bildiren yönlendirme türü.

Core Web Vitals

Google'ın sayfa deneyimini ölçmek için kullandığı üç temel metrik: yükleme hızı, etkileşim gecikmesi ve görsel kararlılık.

MX kaydı

Bir alan adına gelen e-postaların hangi sunucuya yönlendirileceğini belirten DNS kaydı türü.

Search Console

Google'ın, site sahiplerine sitelerinin arama sonuçlarındaki durumunu gösteren ücretsiz aracı.

CDN (İçerik Dağıtım Ağı)

Statik içeriği ziyaretçiye coğrafi olarak en yakın sunucudan sunarak hızı artıran sunucu ağı.

LivHosting'de taşıma nasıl işliyor?

Mevcut hosting bilgilerinizi bizimle paylaştığınızda, siteniz sunucumuzda hazırlanır ve tarafınıza kontrol için gönderilir. Siz onayladıktan sonra yönlendirmeyi değiştiririz — bu noktaya kadar eski siteniz yayında kalmaya devam eder, kesinti yaşanmaz. DNS TTL yönetimini, SSL kurulumunu ve e-posta taşımasını yukarıda anlatılan adımlara birebir uyarak biz üstleniriz; taşıma sonrası Search Console ve hız kontrolünü de sizinle birlikte teyit ederiz.

Özetle: hosting değiştirmek, doğru planlandığında SEO sıralamanız için bir tehdit değil, sitenizi hızlandırıp temizleme fırsatıdır. Riskin kaynağı sağlayıcı değişikliği değil, sürecin nasıl yönetildiğidir — kesintiyi sıfıra indirin, URL'leri koruyun, SSL ve e-postayı kesintisiz taşıyın, DNS'i planlı değiştirin ve taşıma sonrası birkaç hafta izleyin. Bu beş kuralı uygulayan bir taşımada sıralama kaybı yaşama ihtimali yok denecek kadar azdır.

Son olarak şunu vurgulamakta fayda var: bu yazıda anlatılan adımların büyük kısmı, aslında iyi bir hosting sağlayıcısının zaten standart olarak sunması gereken hizmetlerdir. Taşımayı kendi başınıza, adım adım bu rehberi takip ederek de yapabilirsiniz; ama teknik detaylarla uğraşmak istemiyorsanız, deneyimli bir ekibin bu süreci sizin adınıza, yukarıdaki kontrol listesine birebir uyarak yürütmesi hem zaman kazandırır hem de insan hatası riskini ortadan kaldırır.