Marka Değişiminde Alan Adı Taşıma: SEO ve E‑Postayı Korumak

Marka değiştirirken alan adını yenilemek, sadece tasarım ve logo güncellemesi yapmakla kıyaslanamayacak kadar kritik bir adımdır. Eski domain’inizde yıllarca biriken otorite, backlink’ler, Google’daki görünürlük ve e‑posta itibarınızın tamamı bu hamleden doğrudan etkilenir. Yanlış kurgulanmış bir geçiş, aylarca süren organik trafik kaybına, müşterilerin size ulaşamamasına ve e‑postalarınızın spam klasörüne düşmesine neden olabilir. Doğru planlanmış bir geçiş ise, yeni markanızı öne çıkarırken eski domain’de biriktirdiğiniz değeri mümkün olan en yüksek oranda korur.

Bu yazıda, eski domain’den yeni domain’e geçerken SEO ve e‑postayı nasıl koruyabileceğinizi; DNS, 301 yönlendirmeleri, Search Console ayarları, MX/SPF/DKIM güncellemeleri ve pratik kesinti yönetimiyle birlikte adım adım anlatacağım. DCHost tarafında onlarca alan adı ve e‑posta geçişi yönettik; sahada sık gördüğümüz hataları ve işe yarayan kontrol listelerini bu rehbere sıkıştırmaya çalıştım. Amacımız, hem pazarlama hem de teknik ekiplerin aynı sayfada buluşabileceği, uygulanabilir bir yol haritası sunmak.

Marka Değişimi ve Alan Adı Taşımanın Taşıdığı Riskler

Alan adı değiştirmek, arama motorları ve e‑posta servisleri açısından yeni bir kimlik edinmek anlamına gelir. Bu yüzden teknik tarafta yapılan her hata, doğrudan gelir ve itibar kaybı olarak geri döner.

Özellikle şu iki alan kritik:

• SEO: Yıllar içinde kazanılmış organik sıralamalar, backlink profili ve sayfa otoritesi.
• E‑posta: Kurumsal e‑posta adreslerinizin kesintisiz çalışması ve spam filtrelerindeki itibarınız.

Şu risklerle çok sık karşılaşıyoruz:

• Eksik veya hatalı 301 yönlendirmeleri nedeniyle trafik kaybı ve 404 patlaması
• Google Search Console’da adres değişikliğinin bildirilmemesi
• MX ve SPF kayıtları güncellenmeden DNS cutover yapılması sonucu e‑posta kesintisi
• Yeni domain’de SPF/DKIM/DMARC tanımlanmaması nedeniyle spam oranlarının artması
• Eski domain’in tamamen kapanması veya park sayfasına dönmesi sonucu backlink değerinin boşa gitmesi

Alan adı değiştirirken SEO kaybını en aza indirmek için daha önce paylaştığımız alan adı değiştirirken SEO kaybetmemek üzerine detaylı rehber, bu yazıyla birlikte okunursa eksik parçalar çok daha net tamamlanacaktır.

Geçiş Öncesi Planlama: Envanter ve Yol Haritası

Sağlıklı bir domain geçişinin %70’i, canlıya almadan önce yaptığınız hazırlıktır. Biz DCHost tarafında, herkesin aynı doküman üzerinde konuşabildiği bir geçiş çalışma dosyası oluşturmayı standart hale getiriyoruz.

1. Tüm URL’lerin Envanterini Çıkarın

Önce mevcut sitenizin bir fotoğrafını çekmelisiniz:

• Site haritasından (sitemap.xml) tüm URL’leri çıkarın.
• Log’lardan ve analitik araçlarından en çok trafik alan sayfaları listeleyin.
• Özel kampanya, landing page, PDF, dosya indirme URL’lerini ayrıca işaretleyin.

Hedefiniz, eski URL → yeni URL eşleşmesini netleştirmektir. İdeal senaryoda URL yapınız çok değişmez; yani /hakkimizda sayfanız yeni domain’de de /hakkimizda olarak kalır. URL yapısı kökten değişiyorsa, bu haritanın önemi 2 kat artar.

2. Teknik SEO, Analitik ve Entegrasyon Envanteri

Alan adı geçişi sadece web sayfalarından ibaret değildir. Şu öğeleri tek tek not alın:

• Google Analytics / Matomo / diğer analitik kodları
• Google Search Console, Bing Webmaster, Yandex/Webmaster vs. hesapları
• Tag Manager container’ları
• Harici servis entegrasyonları: ödeme sağlayıcıları, CRM, e‑posta pazarlama araçları
• API callback URL’leri, webhook adresleri

Birçok projede, webhook veya ödeme dönüş URL’lerinin güncellenmemesi yüzünden kritik süreçlerin sessizce bozulduğunu gördük. Bu listeyi çıkarıp ilgili sistem sahipleriyle birlikte güncelleme planı hazırlayın.

3. DNS ve Hosting Tarafındaki Hazırlık

Alan adınızın nerede kayıtlı olduğu, DNS’leri nereden yönettiğiniz ve sitenizin hangi sunucuda barındığı net olmalı. DCHost üzerinde barınan projelerde genelde şu senaryoları görüyoruz:

• Domain başka bir registrarda, DNS DCHost’ta, web ve e‑posta da DCHost altyapısında
• Domain ve DNS DCHost’ta, web başka sunucuda, e‑posta ise harici bir serviste

Hangi kaydın nereden yönetildiğini netleştirmeden geçiş planı yapmayın. DNS tarafında TTL değerlerini planlı olarak düşürmek, sıfıra yakın kesinti için kritik. Bu konuyu ayrıntılı anlattığımız Zero‑downtime taşıma için TTL stratejileri rehberi, DNS yayılım sürecini pratik örneklerle açıklıyor.

SEO’yu Korumak İçin Eski Domain’den Yeni Domain’e Geçiş Adımları

Google tarafında mesaj çok nettir: Alan adınızı değiştirirken, mümkün olan her yerde 301 kalıcı yönlendirme kullanın ve yeni domain’i bir devam filmi gibi konumlandırın, bambaşka bir site gibi değil.

1. 301 Yönlendirme Stratejisi

İdeal strateji, 1:1 URL taşımasıdır:

• https://eski‑domain.com/hakkimizda → https://yeni‑domain.com/hakkimizda
• https://eski‑domain.com/urun/kirmizi‑elma → https://yeni‑domain.com/urun/kirmizi‑elma

Bu mümkün değilse, en azından aynı içerik tipine yönlendiren mantıklı gruplar oluşturun (ürün → ürün kategorisi, blog yazısı → ilgili blog kategori sayfası gibi). Dikkat etmeniz gerekenler:

• 301 dışında yönlendirme kullanmayın: 302, 307 veya JavaScript ile yönlendirme SEO değer transferini zayıflatır.
• Yönlendirme zincirlerinden kaçının: Eski → Orta domain → Yeni gibi 2+ adımlı zincirler yerine doğrudan Eski → Yeni yapın.
• WWW ve non‑WWW, HTTP ve HTTPS varyantlarını kapsayın: Tüm varyantların tek bir kanonik URL’ye 301 ile toplandığından emin olun.

Yönlendirmeleri sunucu katmanında (Nginx/Apache/LiteSpeed) yapmak her zaman daha sağlıklıdır. Hosting tarafındaki yönlendirme kurallarını nasıl kurgulayacağınızı merak ediyorsanız, HTTP→HTTPS özelindeki HTTP’den HTTPS’e geçiş ve 301 yönlendirme rehberinde anlattığımız mantık, domain geçişi için de aynen geçerlidir.

2. Canonical, Sitemap ve robots.txt Güncellemeleri

Alan adı geçişinde arama motorlarına net sinyaller vermek için şu üçlü hayati önem taşır:

• Canonical etiketler: Tüm sayfalarda <link rel="canonical"> değeriniz yeni domain’i göstermeli.
• Sitemap.xml: Site haritanız sadece yeni domain URL’lerini içermeli ve Search Console’a yeniden gönderilmeli.
• robots.txt: robots.txt içindeki sitemap satırı da yeni domain’e güncellenmeli.

Site haritaları ve robots.txt dosyalarının SEO tarafında doğru kullanımını adım adım anlattığımız robots.txt ve sitemap.xml kurulum rehberi de burada işinize yarayacaktır.

3. Google Search Console ve Diğer Araçlar

Google, alan adı değişimlerinde Search Console üzerinden Adres Değişikliği Aracı kullanmanızı tavsiye ediyor. Yapmanız gerekenler:

1. Eski ve yeni domain’i Search Console’da doğrulayın (mümkünse domain property olarak).
2. Eski domain property’si içinden “Adres değişikliği” adımlarını izleyin.
3. Google’a, eski domain’inizin kalıcı olarak yeni domain’e taşındığını bildirin.

Ayrıca:

• Analytics, reklam platformları ve diğer izleme araçlarınızda domain adı ve hedef URL’leri güncelleyin.
• Önemli backlink kaynaklarınızla (kataloglar, partner siteler) iletişime geçip doğrudan linki yeni domain’e çevirtmeye çalışın.

DNS, SSL ve Barındırma Tarafı: Sıfıra Yakın Kesinti Mümkün mü?

Alan adı taşıma operasyonlarında çoğu zaman asıl stres, “Geçiş anında site ve e‑postalar çalışacak mı?” sorusundan gelir. DNS ve hosting tarafını doğru kurgularsanız, bu kaygıyı büyük ölçüde azaltabilirsiniz.

1. DNS TTL ve Yayılım Yönetimi

DNS kayıtlarınızın TTL (Time to Live) değeri, değişikliğin internet genelinde ne kadar sürede yayılacağını belirler. Önerdiğimiz yaklaşım:

1. Geçişten 24‑48 saat önce, A/AAAA, MX ve kritik kayıtların TTL değerlerini 300 saniye (veya daha düşük) seviyesine çekin.
2. Yeni domain için gerekli A/AAAA, CNAME, MX, TXT vb. kayıtları önceden hazırlayın (mümkünse staging ortamda test edin).
3. Geçiş anında sadece hedef IP veya host değerlerini değiştirin; kayıt isimlerini değil.

DNS yayılımının neden bazen 24 saati bulduğunu ve pratikte nasıl hızlandırabileceğinizi detaylı anlattığımız DNS yayılım süresi rehberi, geçişi zamanlarken size gerçekçi bir çerçeve sunacaktır.

2. SSL / HTTPS ve HSTS Ayarları

Yeni domain’iniz için mutlaka geçişten önce SSL sertifikası hazırlayın. Dikkat etmeniz gereken noktalar:

• Eski ve yeni domain aynı sunucuda ise, sanal host yapılandırmanızda her iki domain için de HTTPS vhost tanımlayın.
• Let’s Encrypt kullanıyorsanız ACME istemcinizin (örneğin cPanel AutoSSL veya acme.sh) yeni domain’i de kapsadığından emin olun.
• HSTS (HTTP Strict Transport Security) kullanıyorsanız, eski domain’de çok uzun max-age değerleri tanımlamadan önce geçiş planınızı netleştirin. Aksi halde tarayıcılar eski domain’i zorunlu olarak HTTPS üzerinden açmaya çalışmaya devam eder.

SSL tarafındaki uyumsuzluklar, “Not Secure” uyarıları ve karışık içerik (mixed content) problemleri geçiş sonrasında sık gördüğümüz hatalar arasında. Bunları barındırma tarafında nasıl çözeceğinizi anlattığımız SSL sertifika hataları rehberini de mutlaka gözden geçirin.

3. Sunucu Mimarisi: Staging ve Blue‑Green Yaklaşımı

İmkânınız varsa, yeni domain’i önce staging (önizleme) ortamında ayağa kaldırıp tüm yönlendirme ve SSL senaryolarını burada test edin. DCHost üzerinde sık kullandığımız yaklaşım:

• Yeni domain’i geçici bir alt alan adıyla (örneğin yeni‑marka.staging.sirket.com) hazırlamak
• Tüm içerik, tasarım ve SEO ayarlarını staging üzerinde tamamlamak
• Kesinti anında sadece DNS kayıtlarını yeni domain’e çevirerek canlıya almak

Daha gelişmiş senaryolarda, blue‑green deployment ile sıfır kesinti güncelleme yaklaşımını da domain geçişiyle birleştiriyoruz. Böylece hem uygulama versiyon değişimi hem de domain değişimi kontrollü bir şekilde yapılabiliyor.

E‑Postayı Korumak: MX, SPF, DKIM ve Kullanıcı Tarafı

Marka değişimlerinde teknik ekip genellikle web sitesine odaklanır, e‑posta ise “nasılsa çalışır” diye düşünülür. Teoride MX kayıtlarını doğru taşırsanız evet, çalışır; pratikte ise Outlook/Thunderbird ayarları, mobil cihazlar, SPF/DKIM/DMARC gibi başlıklar yüzünden işler karışabilir.

1. MX Kayıtları ve Geçiş Stratejisi

Şu sorulara net cevabınız olmalı:

• E‑posta sunucunuz nerede? DCHost üzerinde mi, başka bir sağlayıcıda mı?
• Alan adı değiştiğinde e‑posta sunucusu da değişecek mi, yoksa sadece alan adı mı?

Temel senaryolar:

• Sadece alan adı değişiyor, e‑posta sunucusu aynı kalıyor: MX kayıtlarını yeni domain için de aynı mail sunucusuna (örneğin mail.yeni‑domain.com → aynı IP) yönlendirin.
• Hem alan adı hem e‑posta altyapısı değişiyor: Önce yeni e‑posta altyapısını hazır edin, test edin; ardından MX switch işlemini planlayın.

MX değişimini yapmadan önce yeni alan adı için mail sunucusunu, SSL sertifikasını, reverse DNS’ini ve test mailbox’larını mutlaka hazırlayın. E‑posta altyapısını taşırken kesinti yaşamamak için adım adım anlattığımız e‑posta altyapısını taşırken kesinti yaşamamak rehberi burada çok işinize yarayacaktır.

2. SPF, DKIM ve DMARC Güncellemeleri

Yeni domain ile e‑posta göndermeye başlarken teslim edilebilirliği (deliverability) korumak için kimlik doğrulama kayıtlarını eksiksiz kurmanız şart:

• SPF: Yeni domain’in DNS’ine, e‑postaları hangi sunucuların gönderebileceğini belirten SPF kaydı ekleyin.
• DKIM: Mail sunucusunda yeni domain için DKIM anahtarı üretin ve ilgili TXT kaydını DNS’e ekleyin.
• DMARC: Raporlama ve politika yönetimi için temel bir DMARC kaydı tanımlayın (p=none ile başlayıp raporları incelemek akıllıca olur).

Bu üçlüyü sıfırdan nasıl kuracağınızı ve hosting/VPS ortamında hangi ayarlara dikkat etmeniz gerektiğini detaylı bir şekilde SPF, DKIM ve DMARC kurulum rehberinde anlattık. Alan adı geçişinde o yazıdaki adımları yeni domain için tekrar uygulamanız gerekir.

3. Geçişte Çift Teslim (Forwarding / Alias) Senaryoları

Marka değişimiyle birlikte e‑posta adresleriniz genelde şu şekilde evrilir:

• ad.soyad@eski‑domain.com → ad.soyad@yeni‑domain.com

Müşterilerinizin alışkanlığını bir anda değiştirmek zor olacağı için geçiş döneminde iki domain’i paralel kullanmak pratik bir çözümdür. Önerdiğimiz yaklaşım:

• Eski domain’deki tüm adresleri, yeni domain’deki karşılıklarına forward/alias yapın.
• Kullanıcılarınızın gönderim adresini (From) yeni domain’e taşıyın; ancak eski domain adreslerine gelen maillerin de bir süre düşmeye devam etmesini sağlayın.
• E‑posta imzalarınızda ve otomatik yanıtlarınızda “Yeni e‑posta adresimiz …” bilgisini belirtin.

Bu süreci planlarken “Alan adı taşırken e‑posta kesintisini önlemek” başlıklı ayrıntılı rehberimizi mutlaka okuyun; DNS ve MX tarafındaki geçiş sırasını somut örneklerle ele aldık.

4. Kullanıcı İletişimi ve İstemci Ayarları

Teknik taraf kusursuz bile olsa, çalışanların e‑posta istemcileri (Outlook, Apple Mail, mobil uygulamalar) doğru güncellenmezse yine “e‑posta çalışmıyor” şikayetleri alırsınız. İyi bir planlama için:

• Tüm istemcilerde giden sunucu kimliği (SMTP TLS sertifikası) yeni domain’le uyumlu mu, kontrol edin.
• POP3/IMAP bağlantı host adları (örneğin mail.yeni‑domain.com) ve portları için kısa bir dokümantasyon hazırlayın.
• Kullanıcılara küçük bir kontrol listesi gönderin: test maili atma, spam klasörünü kontrol etme, mobil cihazları güncelleme vb.

Güvenlik ve Alan Adı Koruması: Eski Domain’i Asla Hemen Bırakmayın

Marka değişiminde en sık yapılan hatalardan biri, “Yeni domain aktif oldu, eskisiyle işimiz bitti” diye düşünmektir. Bu, hem SEO hem güvenlik açısından risklidir.

1. Eski Domain’i En Az 12‑24 Ay Aktif Tutun

Eski domain’inizi en az 1‑2 yıl daha yenileyip 301 yönlendirmeleri çalışır halde tutmanızı öneriyoruz. Neden?

• Yıllar içinde alınmış backlink’lerin bir kısmı asla güncellenmeyecek.
• Kullanıcılar yer imlerinde (bookmark) eski domain’i tutmaya devam edecek.
• Eski kampanya linkleri, PDF’ler, offline materyaller (katalog, kartvizit vb.) uzun süre yaşayacak.

Eski domain’in süresi dolup düşerse ve bir başkası tarafından alınırsa, hem itibar riski hem de phishing saldırılarına açık bir kapı bırakmış olursunuz.

2. Registrar Lock, DNSSEC ve Erişim Güvenliği

Hem eski hem yeni alan adınızı taşıma sürecinde daha da kritik hale gelen bir konu da alan adı güvenliğidir. Aşağıdaki adımları standart hale getirmenizi öneririz:

• Domain panelinizde transfer kilidi (Registrar Lock) aktif olsun.
• Mümkünse DNSSEC etkinleştirerek DNS sahteciliği riskini azaltın.
• Alan adı ve DNS panellerinizde iki faktörlü kimlik doğrulama (2FA) etkin olsun.

Bu başlıkları çok daha detaylı ele aldığımız alan adı güvenliği rehberi, özellikle geçiş döneminde domain’lerinizi hukuken ve teknik olarak korumak için iyi bir kontrol listesi sunuyor.

Geçiş Sonrası İzleme, Hata Tespiti ve Geri Adım Planı

Domain değişikliği, DNS kayıtlarını güncellediğiniz ve 301’leri tanımladığınız gün bitmez; aslında asıl iş ondan sonra başlar. İlk 30 gün, sorun yakalamak için en kritik dönemdir.

1. SEO ve Trafik İzleme

Geçişten hemen sonra şu metrikleri yakından izleyin:

• Organik trafik (eski vs. yeni domain karşılaştırması)
• Önemli anahtar kelimelerdeki sıralama değişimleri
• Search Console’da tarama hataları (404, 5xx) ve yönlendirme sorunları

Alan adı değişikliğinde kısa süreli dalgalanmalar normaldir. Önemli olan, sürekli aşağı giden bir trend mi, yoksa birkaç hafta içinde toparlanan bir eğri mi gördüğünüzdür. Özellikle ilk haftalarda Search Console’daki “Kapsam” ve “Sayfa deneyimi” raporlarını sık sık kontrol edin.

2. 404 Hataları ve Kırık Linkler

Log analizi ve 404 takip araçlarıyla, eski domain’e gelen ama yeni domain’de karşılığı olmayan URL’leri tespit edin. Bu URL’ler için:

• Yeni domain’de denk gelen bir sayfa varsa, ekstra 301 kuralı ekleyin.
• Hiçbir anlamlı karşılığı yoksa, 410 (Gone) yanıtı vermeyi düşünebilirsiniz; ama bu kararı dikkatli verin.

Web sunucu loglarından 4xx/5xx hatalarını okumaya alışkın değilseniz, Apache ve Nginx loglarıyla 4xx/5xx hatalarını teşhis rehberi size pratik bir başlangıç sağlayacaktır.

3. E‑Posta Teslim Edilebilirliği ve Spam Şikayetleri

Yeni domain ile e‑posta göndermeye başladıktan sonra:

• Önemli alıcılarda (Gmail, Outlook, kurumsal müşteriler) maillerin spam’a düşüp düşmediğini düzenli test edin.
• Olası şikayetleri (örneğin “mail gelmiyor”, “geç geliyor”) tek tek log’lardan inceleyin.
• Gerekirse IP ısıtma stratejileriyle yavaş yavaş hacmi arttırın.

E‑posta itibarınızı bozmadan teslim edilebilirliği nasıl yöneteceğinizi ayrıntılarıyla anlattığımız IP ısıtma ve e‑posta itibarı yönetimi rehberinde; yeni domain için de bire bir uygulayabileceğiniz pek çok pratik ipucu bulacaksınız.

4. Geri Adım (Rollback) Planı

Her projede olmasını önerdiğimiz ama çoğu zaman atlanan bir başlık da geri adım planıdır. Kaba bir kontrol listesi:

• DNS’te eski domain’e hızlı dönüş için gerekli kayıt şablonlarını saklayın.
• Eski domain’in içerik ve yapılandırma yedeklerini elinizin altında tutun.
• Çok ciddi bir sorun veya dramatik bir trafik kaybı durumunda, belirli bir süre için eski domain’i tekrar aktif etme senaryosunu önceden konuşun.

Gerçek hayatta, iyi hazırlanmış projelerde tam rollback ihtiyacı çok seyrek olur. Ama böyle bir planın varlığı, ekibin daha rahat hareket etmesini sağlar.

Özet ve DCHost ile Sonraki Adımlar

Marka değişiminde alan adı taşıma, sadece “domain’i yeniledik” deyip geçilecek kadar basit bir işlem değil; işin içinde SEO, DNS, SSL, e‑posta, güvenlik ve kullanıcı alışkanlıkları iç içe geçmiş durumda. Sağlam bir envanter çalışması, doğru kurgulanmış 301 yönlendirmeleri, Search Console bildirimleri, planlı DNS/TTL stratejisi ve eksiksiz SPF/DKIM/DMARC ayarlarıyla bu süreci büyük oranda kontrollü hale getirebilirsiniz. Eski domain’i aceleyle kapatmak yerine, en az 12‑24 ay boyunca 301 yönlendirmeleriyle canlı tutmak da hem SEO hem güvenlik açısından ciddi bir sigorta görevi görür.

DCHost ekibi olarak; domain, DNS, hosting, VPS, dedicated sunucu ve colocation altyapılarımız üzerinde onlarca alan adı ve e‑posta geçişini sorunsuz şekilde yönettik. Benzer bir marka değişimi sürecine hazırlanıyorsanız, kurumsal web siteniz, e‑ticaret projeniz veya SaaS uygulamanız için ihtiyacınıza uygun bir mimariyi birlikte planlayabilir; staging ortamından DNS cutover anına, e‑posta geçişinden log takibine kadar tüm adımları sizinle birlikte kontrol listesi üzerinden ilerletebiliriz. Mevcut sitenizin durumunu ve hedeflerinizi netleştirerek başlanmış iyi bir planlama, yeni markanızla arama sonuçlarında ve müşterilerinizin gözünde kesintisiz devam etmenin en güçlü aracı olacaktır.