Bir alan adını yeni hostinge taşırken DNS paneline doğru IP’yi yazmak çoğu zaman gerekli ilk adımdır; fakat tek başına sitenin açılacağını veya ziyaretçinin başka URL’ye gideceğini garanti etmez. DNS, alan adının hangi sunucuya çözüleceğini belirler. HTTP 301 ve 302 ise web sunucusunun tarayıcıya “başka adrese git” yanıtıdır. Bu rehberde iki işlemi ayırıp alan adı bağlamayı, www tercihlerini, e-posta kayıtlarını ve hata teşhisini uygulanabilir sırayla anlatıyoruz. Örneklerdeki example.com ve 192.0.2.10 yalnızca dokümantasyon amaçlıdır; kendi sağlayıcınızın gerçek hedefini kullanın.
DNS yönlendirme nedir?
“DNS yönlendirme” gündelik dilde iki farklı işi ifade eder. Birincisi alan adının DNS kayıtlarını değiştirerek onu yeni bir IP’ye veya hizmet adına bağlamaktır. Bu işlemden sonra tarayıcının adres çubuğunda aynı alan adı kalabilir. İkincisi eski URL’den yeni URL’ye HTTP yanıtıyla ziyaretçiyi taşımaktır; adres çubuğu değişir. DNS sisteminde genel amaçlı bir “URL’yi 301 yap” kaydı bulunmaz. Kayıt sağlayıcısı “URL forwarding” özelliği sunuyorsa arka planda HTTP yanıtı veren ayrı bir hizmet çalıştırır.
Bu ayrımı baştan yapmak yanlış panelde saatlerce çözüm aramayı önler. Amaç example.com adresini yeni sunucuda açmaksa DNS ve hosting tarafındaki sanal site ayarına bakın. Amaç old.example.com ziyaretçisini new.example.com adresine taşımaksa her iki adın çözümlenmesini, HTTPS’ini ve HTTP yönlendirmesini birlikte kurun. Taşınan içerik için SEO kararını da bu ikinci senaryoda verirsiniz.
Tarayıcı bir alan adını nasıl bulur?
Kullanıcı adresi yazdığında cihaz veya ağdaki çözümleyici önce önbelleğe bakabilir. Yanıt yoksa DNS hiyerarşisi üzerinden yetkili sunucunun kayıtlarını bulur. A kaydı IPv4, AAAA kaydı IPv6 adresi verebilir; CNAME ise bir adı başka bir ada bağlar ve son hedefin yine bir adres kaydına ulaşması gerekir. Çözümleyici adresi döndürdükten sonra tarayıcı hedefe ağ bağlantısı kurar, HTTPS el sıkışması yapar ve HTTP isteği gönderir. Sayfanın içeriği bu sonraki aşamalarda belirlenir.
Bu akış yüzünden “DNS doğru görünüyor ama site açılmıyor” şaşırtıcı değildir. IP doğru olsa bile hosting paneli alan adını tanımayabilir, güvenlik duvarı bağlantıyı engelleyebilir, sertifika alan adını kapsamayabilir veya uygulama hata verebilir. Teşhis sırasında her katmanı sırayla kontrol edin; tek bir DNS sorgusundan bütün site sağlığı sonucu çıkarmayın.
İşe başlamadan önce kayıt envanteri çıkarın
Alan adının kayıt şirketi, DNS hizmeti ve hosting şirketi aynı firma olmak zorunda değildir. Kayıt şirketindeki nameserver bilgisi hangi DNS sağlayıcısının yetkili olduğunu gösterir. Eski panelde kayıt değiştirip hiçbir sonuç görmüyorsanız önce yetkili nameserver’ı kontrol edin. Yeni sağlayıcıya nameserver devredecekseniz mevcut bölgenin A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC ve doğrulama kayıtlarını dışarı aktarın veya güvenli biçimde belgeleyin.
Özellikle e-posta kayıtları gözden kaçabilir. Web sitesini taşırken MX kaydını silerseniz gelen posta etkilenebilir. SPF, DKIM ve DMARC kayıtlarını kaybetmek gönderim doğrulamasını bozabilir. Üçüncü taraf servislerin TXT doğrulama kayıtları da önemlidir. Kopyalama sırasında bilinmeyen kayıtları rastgele silmek yerine sağlayıcı belgelerinden işlevini doğrulayın. Değişiklikten önce eski kayıtları ve geri alma yolunu bilmek, kesinti süresini kısaltır.
A, AAAA, CNAME ve NS ne zaman kullanılır?
A kaydı bir ad için IPv4 adresi belirtir. Hosting şirketi “kök alan adını şu IPv4’e yöneltin” diyorsa verilen IP ile A kaydı açın. AAAA kaydı aynı işi IPv6 için yapar; yalnızca sağlayıcı IPv6 uç noktasını gerçekten hizmete açtıysa ekleyin. Yanlış veya eski AAAA kaydı, bazı ziyaretçilerde sitenin çalışıp bazılarında hata vermesine neden olabilir. İki kaydı da gerçek hizmetin sunduğu adreslerle karşılaştırın.
CNAME kaydı alt alan adını başka bir ada işaret etmek için yaygındır; örneğin www.example.com için sağlayıcının verdiği target.host.example adı kullanılabilir. CNAME bir web yönlendirmesi değildir: tarayıcı adres çubuğunda www adresini tutabilir. Aynı ad üzerinde diğer kayıt türleriyle birlikte CNAME kullanımı DNS kurallarına takılabilir. Kök alan adına CNAME gereksiniminde sağlayıcınızın apex desteği veya CNAME flattening özelliğini ayrıca kontrol edin; her DNS panelinde aynı biçimde çalışmaz.
NS kayıtları ve kayıt şirketindeki nameserver seçimi yetkili DNS hizmetini belirler. Nameserver değiştirmek, A kaydını değiştirmekten daha geniş bir taşıma işlemidir; tüm bölge kayıtlarının yeni tarafta hazır olması gerekir. Sadece web sunucusunun IP’si değişiyorsa ve DNS sağlayıcısı aynı kalacaksa çoğu durumda nameserver’ı değiştirmeye gerek yoktur. Hosting talimatında “NS değiştir” yazsa bile e-posta ve diğer hizmetlerin etkisini önce değerlendirin.
Alan adını yeni hostinge bağlama adımları
- Hedefi doğrulayın: Hosting panelinden alan adı için verilmiş IPv4, IPv6 veya CNAME hedefini alın. Dokümandaki örneği gerçek IP sanmayın.
- DNS yetkisini bulun: Kayıt şirketindeki nameserver’ları ve mevcut DNS bölgesini karşılaştırın. Kaydı yetkili bölgede düzenleyin.
- Mevcut kayıtları yedekleyin: Kök, www, e-posta ve doğrulama kayıtlarını kaydedin. Aynı adda çakışan eski A veya AAAA kayıtlarını tespit edin.
- Web kayıtlarını oluşturun: Sağlayıcının talimatına göre kök ad için A/AAAA veya desteklenen apex hedefini, www için uygun A ya da CNAME’i girin.
- Hostingde alan adını ekleyin: Panelde siteye alan adını bağlayın. DNS doğru olsa bile sunucu isteği doğru projeye eşlemelidir.
- HTTPS’i tamamlayın: Sertifika hem kök hem www için kullanılacaksa ikisini de kapsamalıdır. HTTP’den HTTPS’e geçişi test edin.
- Yanıtları karşılaştırın: Yetkili DNS yanıtı, farklı çözümleyiciler, HTTP durumu ve gerçek sayfa içeriğini ayrı kontrol edin.
Örnek bir kayıt planı şöyle olabilir: kök ad example.com A 192.0.2.10; www adı www.example.com CNAME example.com. Bu değerler canlı bir site kurmaz. Gerçek IP, barındırma hizmetinin doğruladığı adres olmalıdır. CNAME yerine sağlayıcının özel hedef adını veriyorsa onu kullanın. DNS panelindeki @ işareti genellikle bölge kökünü temsil eder; bazı paneller tam alan adı ister. Kaydetmeden önce panelin gösterdiği son adı okuyun; yanlışlıkla example.com.example.com oluşturmayın.
DNS TTL ve “yayılma” beklentisi
TTL, bir DNS yanıtının önbellekte ne kadar süre tutulabileceğini söyler. Kayıt değişmeden önceki yüksek TTL nedeniyle bazı çözümleyiciler eski yanıtı geçerli saymaya devam edebilir. Bu durum her kullanıcıya sabit bir “24 saat” bekleme süresi olduğu anlamına gelmez. Süre önceki TTL’ye, çözümleyicinin önbelleğine ve nameserver değişiminde delegasyon kayıtlarına bağlıdır. Tek ekrandaki sonuç, internetin tamamında yeni değerin görüldüğünü kanıtlamaz.
Planlı taşımalarda eski kaydın TTL’sini önceden düşürmek yararlı olabilir; ancak bunu değişiklikten hemen önce yapmak eski yanıtın hâlihazırdaki önbelleğini silmez. Yeni hostingi hazırlayıp iki sunucuyu geçiş boyunca erişilebilir tutmak daha güvenilir bir stratejidir. Geçiş tamamlanınca TTL’yi yeniden yükseltmek sorgu yükünü azaltabilir. Kritik hizmetlerde e-posta ve üçüncü taraf doğrulama kayıtlarını da yeni bölgede test edin.
DNS kaydı ile HTTP yönlendirmesi arasındaki fark
DNS kaydı yalnızca “bu ada hangi ağ hedefine bağlanayım?” sorusunu yanıtlar. HTTP yönlendirmesi ise isteği alan sunucunun Location başlığı ve 3xx durum koduyla “şu URL’ye yeni istek gönder” demesidir. Kullanıcı old.example.com/page açtığında DNS onu eski alan adının hizmetine ulaştırmalı; hizmet de örneğin https://new.example.com/page yanıtını verebilmelidir. Tarayıcı yeni adrese tekrar DNS sorgusu yapabilir. Bu nedenle eski alan adının çalışır DNS ve HTTPS yapılandırmasını hemen kaldırmayın.
Kalıcı taşınmada genellikle 301 ya da 308; geçici taşıma veya testte 302 ya da 307 seçilir. Google’ın yönlendirme belgeleri, kalıcı sunucu yönlendirmesini yeni hedefin kanonik sinyali olarak ele alır. Geçici yönlendirme aynı anlama gelmez. Durum kodunu yalnızca “çalışıyor” diye seçmeyin; içerik gerçekten kalıcı mı taşındı, eski URL ileride geri gelecek mi, bunu belirleyin. Form ve API gibi yöntem koruması gerektiren uçlarda 307/308 farkını ayrıca değerlendirin.
www, kök alan adı ve HTTPS tercihi
example.com ile www.example.com teknik olarak ayrı ana bilgisayar adlarıdır. İkisi için de DNS kaydı ve HTTPS sertifikası gereklidir; birini tercih edecekseniz diğerinden seçilene yönlendirme kurun. Örneğin www sürümünü esas alıyorsanız https://example.com/path isteği https://www.example.com/path adresine tek kalıcı yönlendirmeyle gidebilir. Tersini de seçebilirsiniz. Önemli olan tek bir tercih ve tutarlı iç bağlantılar, site haritası ve canonical adreslerdir.
HTTP’den HTTPS’e ve www’den köke iki ayrı kural kurmak bazen iki aşamalı yönlendirme zinciri oluşturur. Mümkünse kaynağın her varyantını doğrudan son HTTPS hedefe götürün. Sertifikayı yalnızca yeni hedefe kurup eski HTTPS adını unutursanız tarayıcı yönlendirmeyi görmeden sertifika hatası verebilir. Dolayısıyla önce her iki kaynak adının TLS kapsamasını doğrulayın. Alan adı taşıma işlemlerinde bu adım özellikle önemlidir.
Yönlendirmeyi nerede kurmalısınız?
HTTP yönlendirmesi web sunucusunda, uygulamada, barındırma panelinde veya CDN kuralında yapılabilir. Tek bir katman seçmek teşhisi kolaylaştırır. Cloudflare kullanıyorsanız Single Redirects gibi özellikler URL dönüşümü sağlar; bu kuralların çalışması için ilgili DNS kaydının Cloudflare üzerinden proxied olması gerektiğini belge açıklar. DNS-only bir kayıt için aynı kuralın çalışacağını varsaymayın. Hosting panelindeki “redirect” işlevinin 301 mi 302 mi döndürdüğünü ve yol/sorgu bilgisini koruyup korumadığını test edin.
Eski alan adından yeniye taşırken bütün istekleri yeni ana sayfaya göndermek okuyucuların aradıkları içeriği kaybetmesine yol açabilir. Eşdeğer sayfa varsa yol eşlemesini koruyun; yoksa en yakın ilgili hedefi belirleyin. Yönlendirme kuralını uygulamadan önce kaynak ve hedef URL örnekleri için bir tablo hazırlayın. Ürün, blog, kategori ve dosya yollarını ayrı sınayın. Parametrelerin korunması gerekiyorsa bunu ayrıca tanımlayın; gereksiz takip parametrelerini körlemesine taşımak zorunda değilsiniz.
DNS ve HTTP nasıl test edilir?
Önce DNS yanıtını kontrol edin. Linux ve macOS’ta dig example.com A, dig www.example.com CNAME ve dig example.com MX yararlıdır. Windows PowerShell’de Resolve-DnsName example.com -Type A kullanabilirsiniz. Bir yanıtın hangi çözümleyiciden geldiğini bilmek önemlidir; yerel önbellek farklı sonuç gösterebilir. Yetkili nameserver’a doğrudan sorgu yaparak yeni bölgedeki değeri ve genel çözümleyicideki önbelleği ayırabilirsiniz.
dig example.com NS
dig example.com A
dig www.example.com CNAME
dig example.com MX
curl -I https://example.com/old-pageBu komutlarda example.com yerine kendi alan adınızı yazın. curl -I HTTP başlıklarını gösterir; 301 veya 302 kodunu ve Location hedefini okuyun. Windows’ta PowerShell curl takma adı farklı davranabiliyorsa curl.exe -I kullanın. -L seçeneğiyle zinciri takip edebilirsiniz, ancak başlangıç ve son URL’yi ayrı kaydetmek hata teşhisini kolaylaştırır. Tarayıcı geliştirici araçlarının Ağ sekmesi de her ara yanıtı gösterebilir.
Sonuçları dört soruya bölün: Yetkili DNS doğru kaydı veriyor mu? İstemcinin kullandığı çözümleyici yeni kaydı görüyor mu? HTTPS bağlantısında sertifika doğru mu? HTTP yanıtı beklenen durum kodu, Location ve içerikle geliyor mu? İlk iki soru DNS katmanını, son ikisi web katmanını denetler. Bu ayrım destek talebi açarken de işe yarar; “site açılmıyor” yerine hangi aşamanın başarısız olduğunu belirtirsiniz.
Yaygın hatalar ve çözümleri
DNS güncellendi, eski site açılıyor
Önce yetkili nameserver ve ilgili A/AAAA kayıtlarını doğrulayın. Yeni kayıt yetkili sunucuda doğruysa eski yanıt büyük olasılıkla çözümleyici önbelleğindedir. Fakat eski sayfa yeni IP’de de açılabilir: hosting paneli yanlış proje veya varsayılan siteyi sunuyor olabilir. Sadece “DNS yayılmasını bekleyin” demek yerine HTTP yanıtının hangi sunucudan geldiğini ve alan adının hosting hesabına eklenip eklenmediğini kontrol edin.
www çalışıyor, kök alan adı çalışmıyor
www için CNAME olup kök için A/AAAA veya sağlayıcının desteklediği apex kaydı olmayabilir. İki adın DNS yanıtını ayrı sorgulayın. İkisi de çözümleniyorsa hosting bağlamasını ve sertifikayı karşılaştırın. Bir ad çalıştığı için diğerinin otomatik çalışacağını varsaymayın. Son adımı, tercih ettiğiniz sürüme kalıcı HTTP yönlendirmesi olarak kurun.
Site açılıyor, e-posta gelmiyor
Nameserver değişimi sırasında MX ve ilgili TXT kayıtları aktarılmamış olabilir. Eski ve yeni bölgeleri karşılaştırın. MX hedefinin kendisinin çözümlendiğini, SPF/DKIM/DMARC kayıtlarının sağlayıcının beklediği biçimde olduğunu kontrol edin. Web sitesi ile e-posta farklı sağlayıcılarda kalabilir; web IP’sini değiştirmek MX kaydını otomatik taşımaz.
Yönlendirme döngüsü veya sertifika uyarısı var
CDN, hosting ve uygulama aynı URL için zıt yönlerde kurallar uyguluyor olabilir. Her katmandaki yönlendirmeyi listeleyin ve tek bir nihai adres seçin. Sertifika uyarısında tarayıcı HTTP kuralına ulaşmadan TLS aşamasında durabilir; kaynak alan adının sertifikasını doğrulayın. Güvenlik uyarısını geçerek siteyi açmak çözüm değildir.
SEO açısından alan adı taşıma kontrolü
Kalıcı bir alan adı değişiminde her önemli eski URL’nin yeni sitedeki karşılığına sunucu tarafı yönlendirme vermesi gerekir. İç bağlantıları, canonical etiketlerini ve XML site haritasını yeni adreslere göre güncelleyin. Site haritası gönderme rehberi yeni URL’leri Search Console’da izleme adımlarını açıklar. Canonical etiketi tek başına ziyaretçiyi taşımaz; canonical URL rehberi ile bu farkı ayrıca inceleyebilirsiniz.
Yönlendirme sonrası eski ve yeni alan adlarında örnek URL’leri manuel test edin. Ana sayfa, derin bir yazı, kategori ve görsel dosyası farklı kurallara takılabilir. Gereksiz çoklu atlamaları ve 404’e giden hedefleri düzeltin. Google’ın dizin güncellemesi DNS TTL ile aynı süreye bağlı değildir; arama sonuçlarının yenilenmesi tarama ve işleme döngüsüne bağlıdır. Bu nedenle taşımanın başarısını yalnızca ilk gün arama görünümüne göre yargılamayın.
Yayına almadan önce kısa kontrol listesi
- Alan adının kayıt şirketi ve yetkili nameserver’ı belli.
- Eski DNS bölgesinin web, posta ve doğrulama kayıtları yedeklendi.
- Yeni hostingde kök ve www adları doğru projeye bağlandı.
- A, AAAA ve CNAME hedefleri sağlayıcının verdiği gerçek değerlerle eşleşiyor.
- Eski veya yanlış IPv6 kaydı bırakılmadı.
- HTTPS sertifikası kullanılacak tüm kaynak ve hedef adlarını kapsıyor.
- 301/302 seçimi taşınmanın kalıcılığına uygun ve Location doğru.
- Örnek derin URL’lerde zincir, döngü ve 404 bulunmuyor.
- MX, SPF, DKIM ve DMARC kayıtları taşıma sonrası doğrulandı.
- Yeni canonical ve site haritası URL’leri son adresleri gösteriyor.
Bu listeyi taşıma öncesi ve sonrası ayrı kez uygulayın. Özellikle DNS değişiminin geri alınması gerektiğinde hangi kaydı hangi değere döndüreceğinizi önceden yazın. Nameserver devri yapıyorsanız yalnızca tek A kaydını geri almak yeterli olmayabilir. DNS panelindeki kayıt zamanı ve TTL ile HTTP test zamanlarını not etmek, önbellek kaynaklı karışıklığı azaltır. Büyük sitelerde birkaç örnek sayfa yerine otomatik URL listesi denetimi de yapılmalıdır.
Sık sorulan sorular
DNS kaydı değişince tarayıcı adresi değişir mi?
Genellikle hayır. DNS, adı IP’ye veya başka bir DNS adına çözer. Tarayıcıya yeni URL’ye gitmesini söyleyen mekanizma HTTP 3xx yanıtıdır. Bir kayıt şirketinin “domain forwarding” ürününde adres değişiyorsa sağlayıcı sizin için HTTP yönlendirme hizmeti çalıştırıyor demektir; bu davranış DNS kaydının doğal sonucu değildir.
Nameserver değiştirmeden hosting değiştirebilir miyim?
Evet. DNS bölgeniz mevcut sağlayıcıda kalabilir; yalnızca web için gereken A, AAAA veya CNAME kayıtlarını yeni hosting hedefine güncellersiniz. Nameserver değiştirmek zorunda olduğunuz durumlar da vardır, ancak kararı hizmet sağlayıcının gerçek gereksinimi ve diğer kayıtların taşınma maliyetine göre verin.
301 yönlendirme için eski alan adını tutmalı mıyım?
Eski URL’lere gelen isteklerin yönlendirme yanıtını alabilmesi için eski alan adının çözümlenmesi ve onu karşılayan hizmetin çalışması gerekir. HTTPS kullanılan eski ad için geçerli sertifika da gerekir. Eski alan adını ve yönlendirme altyapısını hemen kaldırmak, mevcut bağlantıları ve kullanıcı erişimini bozabilir.
DNS değişikliği neden herkeste aynı anda görünmüyor?
Çözümleyiciler önceki yanıtı TTL boyunca önbellekte tutabilir. Nameserver değişiminde delegasyon katmanı da devrededir. Farklı ağlarda farklı zamanlarda yeni kayıt görülmesi bu yüzden mümkündür. Yetkili DNS yanıtını ayrı sorgulayıp yerel çözümleyiciyle karşılaştırın; her aksaklığı belirsiz bir “yayılma” süresine bağlamayın.
Sonuç ve kaynaklar
Alan adı bağlama işlemi DNS kayıtlarıyla başlar, hosting eşlemesi ve HTTPS doğrulamasıyla tamamlanır. URL taşımak istiyorsanız buna ayrıca HTTP yönlendirmesi eklenir. Önce hedef davranışı tarif edin; ardından yetkili DNS, web sunucusu ve tarayıcı yanıtını katman katman test edin. E-posta kayıtlarını ve eski alan adının çalışır durumunu taşıma planına dahil etmek, görünmeyen kesintileri önler.
