Alan Adı Değiştirirken SEO Kaybetmemek

Alan Adı Değiştirirken Neden SEO Kaybı Yaşanıyor?

Alan adını değiştirmek, marka tarafında taze bir başlangıç gibi görünse de arama motoru gözünde bu, adres değişikliği anlamına gelir. Yıllar içinde biriktirdiğiniz backlink otoritesi, kullanıcı davranışı sinyalleri, tıklanma oranları ve sayfa otoritesi eski alan adınıza yazılıdır. Geçişi doğru planlamazsanız, arama motoru bu sinyalleri yeni alan adınıza tam olarak aktaramaz ve sıralama kaybı yaşarsınız.

DCHost tarafında gördüğümüz en tipik hata, “Zaten aynı içerik, Google anlar.” yaklaşımı. İçerik aynı olsa bile, URL adresi değiştiği anda Google bunu yeni bir sayfa gibi ele alır. Eğer doğru 301 yönlendirmeler kurulmamışsa, DNS geçişi bilinçli yapılmamışsa ve e-posta kayıtları (MX, SPF, DKIM, DMARC) güncellenmemişse; hem SEO tarafında düşüş, hem de kullanıcı tarafında kesinti yaşanır.

Bu yazıda, DCHost’ta sıkça uyguladığımız “kontrollü alan adı geçişi” yaklaşımını, adım adım bir 301 yönlendirme, DNS ve e-posta taşıma planı olarak anlatacağım. Amacımız şu: Alan adını değiştirirken mümkün olan en az SEO kaybı ile, tercihen hiç kayıp yaşamadan, trafiği yeni domain’e temiz şekilde taşımak.

Geçiş Öncesi Planlama: Envanter, Zamanlama ve Test Ortamı

Başarılı bir alan adı geçişinin %70’i hazırlıktan gelir. Teknik detaylara girmeden önce, “Neyi taşıyoruz?” sorusuna net cevap vermek gerekiyor.

1. URL envanteri çıkarma

İlk adım, mevcut alan adınızdaki tüm önemli URL’leri listelemek:

• SEO trafiği alan tüm sayfalar (kategori, ürün, blog yazıları, landing sayfalar)
• Önemli kampanya / reklam URL’leri
• Eski ama hâlâ backlink alan sayfalar (redirect’li olanlar dahil)

Bunu yapmak için:

• Google Analytics veya diğer analitik aracınızdan en çok trafik alan landing sayfalarını dışa aktarın.
• Google Search Console’dan performans raporunda yer alan URL’leri indirin.
• Sunucu loglarını veya erişim loglarını kullanarak sık ziyaret edilen URL’leri çıkarın.

Bu liste, 301 yönlendirme haritanızın temelini oluşturacak.

2. Yeni URL yapısını netleştirmek

Alan adı değiştirirken genellikle iki senaryo görürüz:

• Sadece alan adı değişiyor: example.com → yeniad.com, URL yolları aynı kalıyor.
• Alan adı + URL yapısı değişiyor: /blog/ yerine /yazi/, /urun/ yerine /shop/ vb.

SEO açısından en güvenli yaklaşım, mümkün olduğu kadar aynı URL yapısını korumaktır. Aynı yapıyı korursanız, 301 haritanız basitleşir. Eğer yapıyı da değiştirecekseniz, her eski URL için birebir yeni URL eşleşmesini netleştirmeniz şart.

URL mimarisi hakkında daha derin bir karar sürecindeyseniz, özellikle blog, mağaza ve dil yapıları için subdomain mi alt dizin mi tercih etmeniz gerektiğini anlattığımız rehbere göz atmanız faydalı olacaktır.

3. Zamanlama ve düşük trafik penceresi

Alan adı geçişini, sitenizin trafik olarak en sakin olduğu zaman aralığına denk getirmeniz riskinizi azaltır. Örneğin B2B bir SaaS iseniz hafta içi gündüz yoğun, hafta sonu sakin olabilirsiniz; B2C e-ticaret iseniz tam tersi.

Genelde şu yaklaşımı öneriyoruz:

• Hazırlıkları hafta içi gündüz yapın (ekip ulaşılabilir olsun).
• Asıl DNS ve 301 geçişini gece geç saatlerde veya trafiğin en düşük olduğu zaman diliminde uygulayın.
• Geçiş sonrası ilk 24 saati, ekibin “nöbet”te olduğu bir zaman dilimine denk getirin.

4. Test ortamı (staging) kurmak

Eğer mümkünse, yeni alan adınızı önce bir staging ortamında ayağa kaldırıp tüm URL’lerin çalıştığından, tema / eklentilerin sorun çıkarmadığından emin olun. DCHost üzerindeki VPS veya paylaşımlı hosting hizmetleriyle, canlı ortamı kopyalayıp staging için ayrı bir alt alan adı veya ayrı bir domain üzerinde test ortamı oluşturmak oldukça pratik.

301 Yönlendirme Stratejisi: Eski URL’den Yenisini Kaybetmeden Taşımak

SEO kaybını asgariye indirmenin kalbi 301 yönlendirmelerdir. 301, “Bu sayfa kalıcı olarak taşındı.” sinyalini verir ve arama motoruna, eski URL’nin otoritesinin yeni URL’ye aktarılması gerektiğini söyler.

1. 301 vs 302 vs 410: Hangisi ne zaman?

• 301 (Moved Permanently): Kalıcı taşımalar için kullanılır. Alan adı değişiminde neredeyse her zaman 301 tercih etmelisiniz.
• 302 (Found / Temporary): Geçici yönlendirmelerde kullanılır. Alan adı geçişinde kullanmanız, sinyallerin tam taşınmasını geciktirir.
• 410 (Gone): Artık var olmayacak, yeni karşılığı olmayan sayfalar için tercih edilebilir.

Genel kural: Eski sitedeki her anlamlı sayfanın, mümkünse birebir karşılığı olan yeni bir URL’si olmalı ve bu geçiş 301 ile yapılmalı.

2. Birebir URL eşleştirme (mapping) tablosu

Hazırladığınız URL envanterinden yola çıkarak, bir eski → yeni URL tablosu hazırlayın. Örnek sütunlar:

• Eski URL (https://eskiad.com/blog/wordpress-seo-rehberi)
• Yeni URL (https://yeniad.com/blog/wordpress-seo-rehberi)
• Not (Tam eşleşme / Yakın içerik / Artık yok)

Artık karşılığı olmayan sayfalar için:

• En yakın kategoriye 301 yönlendirme yapabilir, ya da
• Gerçekten gereksizse 410 ile arama motoruna “bu içerik kaldırıldı” bilgisini verebilirsiniz.

Ne olursa olsun, “her şeyi ana sayfaya yönlendirme” hatasından kaçının. Bu, hem kullanıcı deneyimi açısından kötü, hem de arama motoru için spam sinyali gibi algılanabilir.

3. www / non-www ve http / https tutarlılığı

Alan adı değiştirirken, zaten var olan www / non-www ve http / https stratejinizi de gözden geçirin:

• Eski alan adı: http://example.com → https://www.example.com
• Yeni alan adı: https://www.yeniad.com

Bu durumda şu üç katmanlı yönlendirme zincirini istemiyoruz:

1. http://example.com → https://example.com
2. https://example.com → https://www.example.com
3. https://www.example.com → https://www.yeniad.com

Arama motoru için en ideali, tek adımda 301 yapmaktır:

• http ve https, www ve non-www dâhil tüm eski varyantlar → doğrudan yeni nihai URL

Yani, zincirli 301’leri (redirect chain) temizleyip, her şeyi bir hamlede yeni adrese yönlendirecek kuralları yazın.

4. Sunucu tarafında 301 kurulumu: Apache / Nginx / uygulama

Kullandığınız platforma göre 301’leri farklı katmanlarda kurabilirsiniz:

• Apache (.htaccess): Eski domain için vhost içinde RewriteRule ile alan adı bazlı 301.
• Nginx: server_name eskiad.com; return 301 https://yeniad.com$request_uri; gibi bir direktif.
• Uygulama içi (WordPress, Laravel vb.): Çoğu durumda sunucu taraflı 301 daha performanslı ve sağlıklıdır. Uygulama içi yönlendirmeleri sadece özel durumlar için kullanın.

Eğer WordPress üzerinde çoklu site veya domain mapping kullanıyorsanız, WordPress Multisite ve domain mapping üzerine hazırladığımız rehber, 301 senaryolarınızı planlarken size ciddi fikir verecektir.

5. Canonical ve hreflang etkileşimi

Alan adı değiştirirken sık yapılan hatalardan biri de canonical etiketlerini unutmak. Yeni sitede:

• Tüm sayfaların rel=’canonical’ etiketi yeni alan adına işaret etmeli.
• Eski alan adını canonical olarak bırakmayın, aksi halde sinyaller karışır.

Eğer çok dilli bir siteniz ve hreflang yapınız varsa, hreflang etiketlerindeki tüm URL’leri de yeni alan adına göre güncelleyin. Çok dilli yapı ve ccTLD / alt dizin / alt alan stratejileri için hreflang’i doğru kurmanın sırlarını anlattığımız rehberi mutlaka gözden geçirin.

DNS ve TTL Planı: Yayılımı Yönetmek ve Kesintiyi Sıfıra Yaklaştırmak

Alan adı değiştirirken sadece web trafiğini değil, tüm DNS altyapınızı düşünmeniz gerekiyor. A, AAAA, CNAME, MX, TXT gibi kayıtların tamamının doğru, tutarlı ve zamana yayılmış bir şekilde güncellenmesi şart.

1. Mevcut DNS kayıtlarını analiz etmek

Önce mevcut alan adınızın tüm DNS kayıtlarını çıkarın:

• A / AAAA (web sunucunuzun IP adresleri)
• CNAME (alt alan adları, CDN, third-party servisler)
• MX (e-posta sunucuları)
• TXT (SPF, doğrulama kayıtları, üçüncü taraf servisler)
• SRV / CAA gibi özel kayıtlar

Bu kayıtların ne işe yaradığını tam olarak bilmiyorsanız, DNS kayıtları A’dan Z’ye anlattığımız rehberimizi mutlaka okuyun. Alan adı geçişinde yapılacak küçük bir TXT veya MX hatası, hem SEO’yu hem e-posta teslimini ciddi şekilde etkileyebilir.

2. TTL stratejisi: Zero-downtime’a mümkün olduğunca yaklaşmak

DNS geçişleri sırasında en kritik konu TTL (Time To Live) değeridir. TTL, bir DNS kaydının resolver’lar tarafından ne kadar süre cache’leneceğini belirler. Yüksek TTL, normalde performans için iyidir; ancak geçiş zamanı değişikliklerin geç yayılmasına neden olur.

DCHost’ta alan adı veya sunucu taşıma yaparken genellikle şu stratejiyi uyguluyoruz:

1. T-48 saat: Eski alan adındaki A / AAAA / MX gibi kritik kayıtların TTL değerlerini düşür (örneğin 3600sn → 300sn).
2. T-0 anında: IP veya hedef değişimini yap; düşük TTL sayesinde, çoğu resolver 5–10 dakika içinde yeni kaydı görür.
3. T+48 saat: Her şey stabil olduğunda TTL’leri yeniden makul bir seviyeye (3600–14400sn gibi) çek.

DNS yayılımını hızlandırma ve kesintiyi minimuma indirmek için daha detaylı bir yol haritası isterseniz, Zero-downtime taşıma için TTL stratejilerini anlattığımız makaleye mutlaka göz atın.

3. Eski ve yeni alan adının DNS yapılarını senkron tutmak

Alan adı değişimi genelde şöyle görülür:

• Eski alan adı: esas trafik, esas DNS.
• Yeni alan adı: yavaş yavaş devreye alınan yeni yapı.

Oysa en sağlıklısı, geçiş sırasında her iki alan adının da aynı hedefe bakmasıdır:

• Hem eski, hem yeni alan adı; aynı web sunucusu IP’sine (A/AAAA) yönelsin.
• Hem eski, hem yeni alan adındaki MX kayıtları; aynı e-posta altyapısını göstersin.

Böylece 301’ler, uygulama katmanında tutarlı çalışır; DNS tarafında bölünme yaşamazsınız.

E-posta Taşıma Planı: MX, SPF, DKIM, DMARC ve Testler

SEO odaklı alan adı değişimlerinde çoğu zaman e-posta tarafı ikinci plana atılıyor. Sonra da “Alan adı geçtikten sonra mailler spam’e düşmeye başladı.” şikâyeti geliyor. Çünkü gönderen alan adınız değiştiğinde, SPF, DKIM, DMARC ve rDNS zincirini baştan ele almak gerekir.

1. MX kayıtlarını planlamak

Yeni alan adınızda e-posta kullanacaksanız şu adımları izleyin:

• Yeni alan adı için MX kayıtlarını, kullanacağınız e-posta sunucularına yönlendirin.
• Eski alan adındaki MX kayıtlarını hemen silmeyin; bir süre ikisini de paralel çalıştırmanız, kaçak trafiği yakalamanızı sağlar.
• E-posta istemcilerinizde (Outlook, mobil, webmail vb.) yeni e-posta adreslerini ([email protected] gibi) aynı anda tanımlayın.

Eğer kendi e-posta sunucunuzu bir VPS üzerinde yönetiyorsanız, e-posta geçişinden önce ve sonra IP itibarını ve teslim edilebilirliği takip etmek için e-posta itibarını kurtarma rehberimize mutlaka göz atın.

2. SPF, DKIM, DMARC kayıtlarını güncellemek

Gönderen alan adınız değiştiği için, yeni domain’de baştan SPF, DKIM, DMARC yapılandırması yapmalısınız:

• SPF: Hangi sunucuların yeni alan adı adına mail göndermeye yetkili olduğunu tanımlayın.
• DKIM: E-posta imzalama anahtarını yeni alan adınız için oluşturup DNS’e public key olarak ekleyin.
• DMARC: dmarc.yeniad.com rapor kutusunu oluşturun, politikayı önce p=none ile başlayıp zamanla sıkılaştırın.

Bu üçlünün nasıl birlikte çalıştığını ve teknik kurulum adımlarını, SPF, DKIM, DMARC ve rDNS ile e-posta teslim edilebilirliğini artırma rehberimizde adım adım anlattık. Alan adı değiştirirken bu rehberi referans almak, spam kutusu riskini ciddi şekilde azaltır.

3. Gönderici adı (From:) ve imzaları güncellemek

Teknik kayıtlar kadar, kullanıcı tarafındaki görünüm de önemli:

• CRM, helpdesk, bülten aracı gibi tüm sistemlerde gönderen adresinizi yeni alan adına güncelleyin (no-reply@, info@ vb.).
• E-posta imzalarındaki site linklerini ve alan adını düzeltin.
• Önemli müşterilere, alan adı değişikliğini açıklayan kısa bir bilgilendirme maili gönderin.

4. E-posta geçiş testleri

Alan adı geçişi öncesi ve sonrası mutlaka şu testleri yapın:

• Yeni alan adından Gmail, Outlook gibi popüler sağlayıcılara test mail atın, spam kutusuna düşüp düşmediğini kontrol edin.
• Mail header’larını inceleyerek SPF, DKIM ve DMARC sonuçlarını kontrol edin (pass / fail).
• Farklı istemcilerden (mobil, masaüstü) gönderim ve alımı test edin.

SEO Sinyallerini Koruma: Analytics, Search Console ve İç Bağlantılar

Alan adı değişikliği, sadece teknik taşıma değil; SEO sinyallerinin yeniden adreslenmesi sürecidir. Arama motorlarına bu değişimi düzgün bildirmezseniz, 301 yönlendirmeleriniz doğru olsa bile toparlanma süreniz uzar.

1. Google Search Console’da adres değişikliği

Hem eski, hem yeni alan adınızı Google Search Console’a mülk (property) olarak ekleyin. Ardından:

• Eski alan adı mülkünden “Adres değişikliği” aracını kullanarak yeni alan adını işaret edin.
• Yeni alan adınız için XML sitemap’leri ekleyin ve “İndeksleme isteği” gönderin.

Bu işlem, Google’a “Bu site yeni adrese taşındı, sinyalleri buraya devret.” demenin resmi yoludur.

2. Analytics ve hedefler

Google Analytics veya benzeri analitik aracınızda:

• Yeni alan adını, aynı ölçüm kimliği (Measurement ID) ile takip etmeye devam edin.
• Hedefler (Goals) veya dönüşümler (Conversions) alanında, URL tabanlı tanımlar yaptıysanız yeni URL yapısına göre güncelleyin.
• Filtre veya hostname bazlı raporlarınız varsa, yeni domain’i de kapsadığından emin olun.

3. İç bağlantıları güncellemek

301 yönlendirmeler iç linkler için de çalışır; ancak uzun vadede iç bağlantıları doğrudan yeni alan adına güncellemek daha sağlıklıdır. Özellikle:

• Menü ve footer linkleri
• Blog yazılarındaki dahili linkler
• Ürün sayfalarından diğer ürünlere / kategorilere giden linkler

Bu adımı belli bir süreye yayabilirsiniz; ancak en azından global navigasyondaki linkleri geçiş anında güncellemek iyi bir pratiktir.

4. Dış bağlantıları (backlink) güncellemek

301 yönlendirmeler sayesinde, eski alan adınıza verilen linklerin otoritesi büyük ölçüde yeni domaine akar. Yine de kritik kaynaklarda link güncellemek faydalıdır:

• Sizin kontrolünüzdeki diğer sitelerde (şirketler, projeler, kişisel siteler) linkleri manuel olarak düzeltin.
• Önemli iş ortaklarınıza, alan adı değişikliğini duyurup linklerini güncellemelerini rica edin.
• Sosyal medya profillerinizde, dizinlerde, Google Business profilinizde URL’yi güncelleyin.

DCHost ile Örnek Taşıma Senaryosu: Adım Adım Zaman Çizelgesi

DCHost tarafında sıkça uyguladığımız tipik bir alan adı değişikliği senaryosunu, zaman çizelgesi üzerinden özetleyelim. Bu senaryoda:

• Eski domain: eskiad.com
• Yeni domain: yeniad.com
• Site: WordPress + WooCommerce, DCHost VPS üzerinde çalışıyor.

T-7 gün: Hazırlık

• Tüm önemli URL’lerin envanterini çıkarıyoruz (Analytics + Search Console + loglar).
• Eski → yeni URL mapping tablosunu hazırlıyoruz.
• Yeni alan adı yeniad.com, DCHost’ta aynı VPS’e işaret ediyor; staging ortamında tüm sayfalar test ediliyor.
• DNS sağlayıcı üzerinde mevcut kayıtlar ve TTL değerleri not alınıyor.
• Alan adı güvenliği (Registrar Lock, 2FA, Whois gizliliği, DNSSEC) gibi konular, yeni alan adı için de kontrol ediliyor. Bu aşamada alan adı güvenliği rehberimizdeki adımları referans almak çok faydalı.

T-48 saat: TTL düşürme ve DNS hazırlığı

• eskiad.com üzerindeki A / AAAA / MX gibi kritik kayıtların TTL’leri 300 saniyeye çekiliyor.
• yeniad.com üzerinde, eskiad.com ile tamamen aynı DNS kayıt yapısı oluşturuluyor (sadece alan adları farklı).
• SSL sertifikaları, hem eski hem yeni alan adını kapsayacak şekilde ayarlanıyor (gerekirse SAN veya ayrı sertifikalar).

T-0: Geçiş anı

• Nginx / Apache konfigürasyonunda, eskiad.com için gelen tüm istekler, mapping tablosuna göre yeniad.com’daki birebir URL’lere 301 ile yönlendiriliyor.
• WordPress içinde site URL ayarları yeniad.com olarak güncelleniyor.
• Menü, footer ve sabit linklerdeki dahili URL’ler mümkün olan ölçüde yeni domain’e göre güncelleniyor.
• Google Search Console’da adres değişikliği bildirimi yapılıyor; yeni sitemap’ler gönderiliyor.
• Analytics tarafında yeni domain’in düzgün izlenip izlenmediği kontrol ediliyor.

T+24 saat: İzleme

• Sunucu loglarından 404 hataları taranıyor; mapping tablosunda eksik kalan URL’ler tespit edilip ek 301 kuralları yazılıyor.
• Arama sonuçlarından tıklanan ve hataya düşen sayfalar olup olmadığı kontrol ediliyor.
• E-posta gönderimlerinde SPF / DKIM / DMARC sonuçları test ediliyor; spam / inbox oranları gözlemleniyor.

T+7 gün: Stabilizasyon

• Eski alan adındaki içerik tamamen 301 ile yeni adrese yönleniyor, eski sitede direkt içerik gösterimi bırakılmıyor.
• TTL değerleri, tekrar makul seviyelere yükseltiliyor (performans ve dayanıklılık için).
• Backlink’lerin önemli bir kısmı manuel olarak güncellenmiş oluyor.

Alan Adı Transferi ve Barındırma Tarafını Unutmamak

Alan adı değişimi çoğu zaman alan adı transferi veya hosting taşıma süreciyle birlikte yürütülüyor. Eğer domain’i başka bir registrardan DCHost’a transfer ediyorsanız, mutlaka:

• EPP kodu, transfer kilidi, Whois bilgileri ve olası ek güvenlik önlemlerini baştan planlayın.
• Transfer süresince DNS’in nereden yönetileceğini netleştirin (eski mi, yeni mi, ara bir DNS mi?).

Bu konularda adım adım ilerlemek için alan adı transferi rehberimize göz atabilirsiniz. Eğer alan adını değiştirirken aynı anda hosting altyapınızı da yenilemeyi düşünüyorsanız, DCHost’un paylaşımlı hosting, VPS, fiziksel sunucu ve colocation çözümleri ile geçişi tek merkezden yönetmek işleri ciddi anlamda sadeleştirir.

Hızlı Kontrol Listesi: Alan Adı Değiştirirken SEO Kaybetmemek İçin

Toparlamak için, alan adı değişiminde kendinize şu soruları sorabileceğiniz bir kontrol listesi bırakalım:

• Tüm önemli URL’lerin envanterini çıkardım mı?
• Eski → yeni URL mapping tablom eksiksiz mi?
• 301 yönlendirmeler zincirsiz, tek adımda çalışıyor mu?
• Canonical etiketleri yeni alan adına işaret ediyor mu?
• hreflang, sitemap ve robots.txt dosyaları yeni domain için güncel mi?
• DNS kayıtlarını (A, AAAA, CNAME, MX, TXT, CAA) yeni domain için doğru kurdum mu?
• TTL değerlerini geçişten önce düşürdüm, sonra tekrar yükselttim mi?
• MX, SPF, DKIM, DMARC kayıtları yeni alan adı için doğru çalışıyor mu?
• Google Search Console’da adres değişikliğini bildirdim mi?
• Analytics tarafında yeni domain sorunsuz takip ediliyor mu?
• İç bağlantılarımı ve en kritik dış bağlantıları güncelledim mi?
• Geçiş sonrası 404 loglarını takip edip eksik 301’leri tamamladım mı?

Sonuç: Doğru Planla Alan Adı Değişimi Korkulacak Bir İş Değil

Alan adı değişikliği, plansız yapıldığında can yakar; ama iyi bir 301 stratejisi, bilinçli DNS / TTL planı ve temiz bir e-posta taşıma akışıyla aslında son derece kontrollü yönetilebilen bir süreçtir. Önemli olan, bunu “sadece domain değiştirdik” diye görmemek; SEO, e-posta, marka ve kullanıcı deneyimini birlikte ele almaktır.

DCHost’ta her gün benzer geçişler yaparken gördüğümüz şey şu: Aceleye getirilen, “nasılsa Google anlar” diye düşünülen taşımalarda kaybedilen trafiği geri toplamak, baştan düzgün bir plan yapmaktan çok daha maliyetli oluyor. Öte yandan, yukarıda anlattığımız adımları izleyip, özellikle 301 haritanızı ve DNS / e-posta yapılandırmanızı titizlikle hazırladığınızda; çoğu projede geçişten 1–2 hafta sonra trafiğin büyük kısmı yeni domain’e sağlıklı şekilde taşınmış oluyor.

Eğer alan adı değişikliği, aynı zamanda altyapınızı da yenilemek için bir fırsatsa; DCHost’un paylaşımlı hosting, NVMe VPS, fiziksel sunucu ve colocation çözümleriyle hem performans tarafında kazanç sağlayabilir, hem de geçiş sürecini tek elden ve sakin bir şekilde yönetebilirsiniz. Bir sonraki alan adı projenizde, bu yazıdaki kontrol listesini yanınıza alıp adım adım ilerleyin; SEO tarafında “keşke” deme ihtimaliniz ciddi şekilde azalacaktır.