Marka Değişiminde Alan Adı ve E-posta Taşıma

Marka değişiminde alan adını yenilemek, web adreslerini ve kurumsal e-posta kimliğini birlikte planlamayı gerektirir. Eksik yönlendirmeler müşterileri yanlış sayfalara götürebilir; hazırlanmamış posta hesapları ise iletilerin geri dönmesine neden olabilir. Düzenli bir geçiş planı bu riskleri azaltır, ancak arama sıralamalarının veya e-posta teslimatının hiç değişmeyeceğini garanti etmez.

Bu rehber; URL envanteri, 301 yönlendirmeleri, DNS ve HTTPS hazırlığı, Search Console bildirimi ve e-posta geçişini aynı çalışma planında birleştirir. Alan adı değişimi, kayıt kuruluşları arasında domain transferi veya hosting taşımasıyla aynı işlem değildir. DNS güncellemesi HTTP yönlendirmesi oluşturmaz, eski posta kutularını da yeni sisteme taşımaz.

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

Yeni marka için web ve e-posta adreslerini değiştirirken mevcut bağlantıları, müşteri iletişimini ve uygulama verilerini korumak gerekir. Arama motorlarının URL geçişini işlemesi ile posta servislerinin yeni gönderici kimliğini değerlendirmesi ayrı süreçlerdir.

Ö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.

Geçiş planında şu riskleri ele alın:

• Eksik, zincirli veya ilgisiz hedefe giden yönlendirmeler ve beklenmeyen 404 yanıtları
• Yeni URL’lerle uyuşmayan canonical, hreflang, sitemap veya Search Console ayarları
• Hatalı MX kayıtları ya da yeni alan adı için posta kabul etmeyen bir sunucu nedeniyle gelen postanın aksaması
• Gönderim altyapısıyla uyuşmayan SPF, etkinleştirilmemiş DKIM veya DMARC hizalama hataları nedeniyle teslimat sorunları
• Eski alan adının HTTPS, yönlendirme veya e-posta hizmetinin erken kapatılması

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şi için canlıya almadan önce hazırlık yapın. Ekiplerin aynı plan üzerinden çalışabilmesi için bir geçiş çalışma dosyası oluşturun.

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

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

• Site haritasındaki (sitemap.xml) URL’leri çıkarın; sitemap tüm adresleri içermeyebileceği için site taraması ve CMS URL listeleriyle envanteri tamamlayı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 harita eksik ve yanlış eşleşmeleri önlemek için daha da önemlidir.

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

Webhook veya ödeme dönüş URL’lerinin güncellenmemesi, kritik süreçlerin fark edilmeden bozulmasına yol açabilir. Bu listeyi çıkarıp ilgili sistem sahipleriyle birlikte güncelleme planı hazırlayın.

Ödeme bildirimlerini, webhook’ları ve API istemcilerini doğrudan yeni adreslerle yapılandırın; kimlik doğrulama, izin verilen dönüş adresleri, oturum çerezleri ve CORS kurallarını test edin. 301 yanıtından sonra bazı istemciler POST isteğini GET’e çevirebilir. 308 yöntemi korur, ancak her entegrasyonun yönlendirme izleyeceğini veya isteğin tekrarının güvenli olacağını varsaymayı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ı. Örneğin, hizmetlerin dağılımı şu şekilde olabilir:

• Domain bir registrarda, DNS ayrı bir DNS sağlayıcısında, web ve e‑posta aynı hosting sağlayıcısında
• Domain ve DNS aynı sağlayıcıda, 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 kayıtları da değişecekse, ilgili TTL değerlerini önceden düşürmek önbellekte eski yanıtların kalma süresini azaltmaya yardımcı olur; tek başına kesintisiz geçiş sağlamaz. Bu konuyu ayrıntılı anlattığımız sunucu taşıma için DNS TTL planlama 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’ın URL değişikliğiyle site taşıma rehberi, teknik olarak mümkünse sunucu tarafında kalıcı yönlendirme kullanılmasını önerir. Taşınan her sayfa doğrudan yeni karşılığına gitmeli; içerik, dahili bağlantılar ve canonical adresleri aynı hedefi göstermelidir.

1. 301 Yönlendirme Stratejisi

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

• https://old.example/hakkimizda → https://new.example/hakkimizda
• https://old.example/urun/kirmizi-elma?ref=partner → https://new.example/urun/kirmizi-elma?ref=partner

Birebir karşılık yoksa, yalnızca eski içeriğin yerini gerçekten alan ilgili bir sayfaya yönlendirin. Aynı içerik tipinde olması tek başına yeterli değildir; genel bir kategoriye toplu yönlendirme yapmayın. Taşınmayan ve uygun karşılığı bulunmayan içerikler için 404 veya 410 yanıtı verin.

Örneklerdeki .example adresleri dokümantasyon için ayrılmıştır. Gerçek eşleştirmelerde yolun ve işlevsel sorgu parametrelerinin korunmasını test edin; parametreleri topluca silmek arama, kampanya veya ürün davranışını bozabilir. Yönlendirmelerde şu kontrolleri yapın:

• Kalıcı sunucu tarafı yönlendirme kullanın: Alan adı taşıması için 301 veya 308 tercih edin. 302 ve 307 geçici yönlendirmelerdir; JavaScript yönlendirmelerini sunucu tarafı yönlendirme mümkün olmadığında değerlendirin.
• 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: Her eski sayfanın tüm varyantlarını doğrudan o sayfanın yeni kanonik URL’sine yönlendirin; bütün siteyi tek sayfaya göndermeyin.

Yönlendirmeleri sunucu katmanında (Nginx/Apache/LiteSpeed) yapmak, tarayıcıda JavaScript çalışmasına bağlı kalmadan HTTP yönlendirmesi sağlamanın bir yoludur. 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 kalıcı yönlendirme ilkeleri, eski ve yeni alan adlarınıza ve URL eşleştirmelerinize uyarlanarak burada da kullanılabilir.

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

Alan adı geçişinde arama motorlarına tutarlı sinyaller vermek için şu öğeleri kontrol edin:

• Canonical etiketler: Yeni sitedeki her kanonik sayfanın <link rel="canonical"> etiketindeki href değeri, o sayfanın yeni domain’deki tam URL’sini göstermeli; tüm sayfaları ana sayfaya işaretlemeyin.
• 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. Canlıya geçerken yalnız yayımlanacak sayfalardaki geliştirme ortamına ait noindex talimatlarını ve tarama engellerini kaldırın; özel içerik korumalarını sürdürün; eski URL’lerdeki yönlendirmelerin taranmasını engellemeyin.
• Dahili bağlantılar ve hreflang: Site içi bağlantıları ve varsa çok dilli sayfaların hreflang referanslarını yeni URL’lere güncelleyin.

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 sitenin mülk sahipliğini aynı Google hesabıyla doğrulayın; geçiş sonrasında da doğrulama çalışmalı.
2. Yeni site açılıp eski URL’lerde yönlendirmeler etkinleştikten sonra eski sitenin alan adı düzeyindeki mülkünde Adres Değişikliği aracını çalıştırın ve ön kontrolleri tamamlayın.
3. Taşınan www ve diğer alt alan adlarını ayrıca değerlendirin; araç bir alan adı bildiriminden bütün alt alan adlarını otomatik taşımaz.
4. Yeni sitemap’i gönderin; eski ve yeni mülklerde indeksleme ve performansı izleyin.

Adres Değişikliği aracının güncel koşullarını uygulayın. Yalnız hosting değişimi, aynı alan adında HTTP→HTTPS veya yol değişikliği için bu aracı kullanmayın. Aracın 180 günlük sinyal süresi, 301 yönlendirmelerini 180 gün sonunda kaldırma talimatı değildir. 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, önbelleğe alınan DNS yanıtlarının ne kadar süre yeniden kullanılabileceğini belirtir; değişikliğin internet genelinde tamamlanma süresini tek başına belirlemez. Önerdiğimiz yaklaşım:

1. DNS hedefleri değişecekse, ilgili A/AAAA, MX ve diğer kritik kayıtların TTL değerlerini örneğin 300 saniyeye düşürün. Bunu mevcut TTL süresi dolacak kadar önceden planlayın; 24‑48 saatlik hazırlık aralığı mevcut TTL daha uzunsa yeterli olmayabilir.
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. Yeni domain’in kayıtları eski domain’inkilerden ayrıdır; eski kayıt adlarını değiştirerek alan adı taşıması yapmayın. Yeni site hazır olduğunda eski URL’lerden yeni URL’lere yönlendirmeleri etkinleştirin. Aynı anda sunucu da değişiyorsa, yalnızca gerekli DNS hedeflerini güncelleyin; eski domain’in yönlendirme ve e‑posta için gerekli kayıtlarını koruyun.

TTL, bütün internet için bir bitiş saati değildir. Daha önce önbelleğe alınmış yanıtlar eski sürelerini korur; olumsuz DNS yanıtlarının önbelleği ve bazı çözümleyicilerin eski yanıt sunması da süreyi etkileyebilir. Eski ve yeni hedefleri geçiş boyunca çalışır tutun. Normal bir CNAME kaydını aynı adda MX/TXT gibi kayıtlarla birleştirmeyin; kök alan adı için sağlayıcının desteklediği A/AAAA veya ayrı flattening davranışını doğrulayın.

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:

• Yeni ve eski HTTPS adları için geçerli sertifika ve doğru sanal sunucu yapılandırmasını hazırlayın; www varyantlarını ve DNS önbellekleri nedeniyle trafik alabilecek tüm eski uçları kapsayın. TLS bağlantısı kurulmadan HTTPS yönlendirmesi alınamaz.
• ACME istemcinizin sertifika sağlayıcısını, doğrulama yöntemini ve yenilemeyi kontrol edin. Desteklenen DNS-01 doğrulaması web DNS hedefini değiştirmeden sertifika almayı sağlayabilir; her AutoSSL yapılandırmasının aynı yöntemi sunduğunu varsaymayın.
• HSTS eski alan adına HTTPS bağlantısını zorlar. Geçerli eski HTTPS hizmeti korunduğunda alan adı geçişi yapılabilir; HSTS’yi kaldırmak sertifika hatalarını güvenilir biçimde aşan bir kestirme değildir.

SSL tarafındaki uyumsuzluklar, “Not Secure” uyarıları ve karışık içerik (mixed content) problemleri geçiş sonrasında ortaya çıkabilecek 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ı

Yeni siteyi önce erişimi korunan bir önizleme ortamında hazırlayın. Test kopyasının gerçek müşterilere e-posta göndermesini, ödeme almasını veya üretim webhook’larını tetiklemesini engelleyin. Önizleme alan adındaki başarı, gerçek yeni alan adının sertifika ve oturum davranışının doğru olduğunu tek başına kanıtlamaz.

1. İçerik ve gerekli marka ayarlarını örneğin new-brand.staging.example üzerinde hazırlayın; mümkünse CMS ve büyük tasarım değişikliklerini ayrı zamanda yapın.
2. Gerçek yeni alan adında HTTPS, giriş, formlar ve entegrasyonları kontrollü test edin. Son veri eşitlemesi, kısa yazma duraklatması veya sürekli eşitleme kararını uygulamanın veri modeline göre verin.
3. Yeni alan adının gerekli DNS hedeflerini hazırlayıp kanonik sayfaları herkese açık 200 yanıtıyla erişilebilir kıldığınızda üretime özgü URL, canonical ve iç bağlantıları doğrulayın; yalnız yayımlanacak sayfalardan staging’e ait indeksleme engellerini kaldırın.
4. Eski alan adının trafik alabilecek her ucunda doğrudan 301 yönlendirmelerini etkinleştirin. Eski alan adının web DNS hedefi de değişecekse önbellekte kalan uçları çalışır tutun; ardından web ve posta testlerini tekrarlayın.

Blue-green deployment yaklaşımı kontrollü bir geçişe yardımcı olabilir. Yine de veri yazımları ve alan adı değişikliğinin etkileri ayrıca çözülmelidir; blue-green kullanımı tek başına sıfır kesinti veya kolay geri dönüş garantisi değildir.

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

E‑posta geçişinde MX kayıtları tek başına yeterli değildir: sunucu yeni domain için posta kabul etmeli, posta kutuları veya alias’lar hazırlanmalıdır. Outlook/Thunderbird ayarları, mobil cihazlar ve SPF/DKIM/DMARC yapılandırmaları da geçiş planına dahil edilmelidir.

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:

• Yalnız alan adı değişiyorsa: Yeni domain’i mevcut posta hizmetinde doğrulayın ve tüm alıcıları ya da alias’ları hazırlayın. Sağlayıcı aynı MX hedeflerini isteyebilir; MX sunucu adının yeni markayla eşleşmesi gerekmez. mail.new.example gibi yeni bağlantı adı seçilirse DNS, hizmet yapılandırması ve TLS ayrıca hazırlanmalıdır.
• Posta sağlayıcısı da değişiyorsa: Hesapları ve kimlik doğrulamayı kurun; eski iletiler, klasörler, takvim ve kişiler için desteklenen veri taşıma yöntemini belirleyin. İlk kopyalamayı ve yeni alıcılara teslimat testlerini tamamladıktan sonra gerekli MX değişimini yapın. DNS önbellekleri nedeniyle eski hizmete ulaşan yeni iletileri geçiş boyunca eşitleyin; yeni yönlendirmeyi ve eski sistemde kalan iletileri doğruladıktan sonra son fark eşitlemesini tamamlayın. Eski hizmeti ve eşitlemeyi ancak bu kontrollerden sonra kapatın. DNS geçmiş postayı taşımaz.

MX hedefi bir IP adresi veya normal CNAME alias’ı değil, posta sunucusuna çözülen uygun bir host adı olmalıdır. Sağlayıcının verdiği MX hedeflerini kullanın.

MX değişimini yapmadan önce yeni alan adı için mail sunucusunu ve test mailbox’larını hazırlayın. Bağlantılarda kullanılan sunucu adları için geçerli TLS sertifikalarını doğrulayın. Gönderim IP’sinin PTR kaydı bir sunucu adına çözülmeli; bu adın A/AAAA kaydı da aynı IP’ye dönmelidir. Yalnızca e‑posta adresinin domain’i değişti diye PTR kaydının değişmesi gerekmez. 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: MAIL FROM ve gerektiğinde HELO kimliği için kullanılan alan adlarında yetkili gönderim hizmetlerini kapsayan tek bir SPF politikası yayımlayın. SPF doğrudan görünen From adresini doğrulamaz; sağlayıcının verdiği kayıtları tüm göndericilerle birlikte kontrol edin.
• DKIM: Sağlayıcının belirttiği selector kaydını yayımlayın ve yeni domain için giden ileti imzalamayı etkinleştirin. DNS’e açık anahtar eklemek tek başına iletileri imzalamaz.
• DMARC: Başarılı SPF veya DKIM kimliklerinden en az biri görünen From domain’iyle politikanın istediği şekilde hizalanmalıdır. Yeni bir kurulumda p=none ile raporları değerlendirmek mümkün olsa da bu politika karantina veya ret istemez. Çalışan bir yaptırım politikasını gerekçesiz zayıflatmayın; tüm meşru göndericileri doğrulayarak ilerleyin.

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. Yeni domain için gereken kayıtları ve imzalama ayarlarını kullandığınız posta hizmetinin güncel yönergeleriyle doğrulayın; eski kayıtları körlemesine kopyalamayın.

3. Geçişte Eski Adresleri Korumak: Forwarding / Alias

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

• ad.soyad@old.example → ad.soyad@new.example

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 adresleri aynı posta kutusuna alias veya tek yönlü yönlendirmeyle bağlayın; eski domain’in MX kayıtlarını ve posta kabulünü koruyun. İki yönlü döngü oluşturmayın.
• Harici yönlendirmede SPF veya DMARC hizalaması bozulabilir; iletiyi değiştirmek DKIM imzasını da geçersiz kılabilir. Dış alıcılarda gerçek teslimatı ve başlık sonuçlarını test edin; SRS veya ARC’yi evrensel teslimat garantisi saymayın.
• Kullanıcıların gönderim adreslerini planlı olarak değiştirin; eski domain hâlâ gönderiyorsa gerekli kimlik doğrulama kayıtlarını koruyun. İmza, iletişim sayfaları ve şablonları güncelleyin; otomatik yanıt kullanılacaksa spam, döngü ve gereksiz yanıt üretimini sınırlandırın.

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ı

Çalışanların e-posta istemcileri de geçiş planına dahildir. Outlook, Apple Mail ve mobil uygulamalarda bağlantı ve gönderici ayarları değişecekse şu kontrolleri hazırlayın:

• Tüm istemcilerde SMTP TLS sertifikasının bağlantıda kullanılan sunucu adıyla uyumunu kontrol edin. Bu adın, e‑posta adresinizdeki yeni domain ile aynı olması gerekmez.
• POP3/IMAP bağlantı host adları (örneğin mail.new.example) 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 “Yeni domain aktif oldu, eskisiyle işimiz bitti” diye düşünmek, hem SEO hem güvenlik açısından risklidir.

1. Yönlendirme, E-posta ve Tescil Sürelerini Ayrı Planlayın

Google genel olarak yönlendirmeleri mümkün olduğunca uzun, en az bir yıl korumayı önerir; kullanıcılar için süresiz korumak yararlı olabilir. E-posta alımını ve alan adı tescilini ne kadar sürdüreceğinizi eski müşteri yazışmaları, kayıtlı hesaplar ve marka taklidi riskine göre ayrıca belirleyin. 12–24 aylık bir takvim otomatik kapatma tarihi değildir. Eski adreslerin yaşamaya devam etmesinin nedenleri:

• Yıllar içinde alınmış backlink’lerin bir kısmı uzun süre güncellenmeyebilir.
• 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

Eski ve yeni alan adının hesap güvenliğini ve yenilemesini birlikte yönetin:

• Yetkisiz kayıt kuruluşu transferlerine karşı uygun transfer kilidini kullanın; bu kilit hesap güvenliğinin veya bütün DNS değişikliklerinin yerine geçmez.
• Eski ve yeni alan adlarının DNSSEC durumunu kontrol edin. Nameserver veya DNS sağlayıcısı da değişiyorsa DS, DNSKEY ve imzalama zincirini sağlayıcının geçiş yöntemine göre koordine edin; uyumsuz eski DS kayıtları doğrulayan çözümleyicilerde SERVFAIL üretebilir. Her geçişte DNSSEC’yi körlemesine açıp kapatmayın.
• Registrar ve DNS hesaplarını 2FA, güncel kurtarma bilgileri ve izlenen yenileme ödemeleriyle koruyun.

Bu başlıkları çok daha detaylı ele aldığımız alan adı güvenliği rehberi, özellikle geçiş döneminde domain’lerinizin teknik güvenliğini güçlendirmek 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 sorunları yakalamak için yakından izleme yapın; izlemeyi trafik ve indeksleme durumu istikrara kavuşana kadar sürdürün.

1. SEO ve Trafik İzleme

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

• Geçiş öncesi seviyeye göre eski ve yeni domain’in toplam organik trafiği
• Ö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, trafik eğilimini tarama ve yönlendirme hatalarıyla birlikte değerlendirmektir; toparlanma için sabit bir süre varsaymayın. Özellikle ilk haftalarda yukarıdaki metrikleri 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 doğru hedefe yönlendirilmeyen veya 404 dönen 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.
• Yeni bir gönderim IP’sine de geçiyorsanız, IP ısıtma ihtiyacını ayrıca değerlendirin; gönderim hacmini teslimat sonuçlarını izleyerek kademeli artırın.

Web yönlendirmeleri e-posta itibarını taşımaz. Yeni gönderici domain’inin itibarını ayrıca izleyin; özellikle toplu gönderimde hacmi alıcı geri bildirimleri ve SMTP sonuçlarına göre kontrollü artırın. SPF/DKIM/DMARC başarısı da gelen kutusuna yerleşme garantisi değildir.

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 gönderim hacmi ve itibar takibi hakkında pratik ipuçları bulabilirsiniz; IP’ye yönelik adımları yalnızca alan adı değişti diye bire bir uygulamayın.

4. Geri Adım (Rollback) Planı

Geçişten önce geri adım planını ve bu planı devreye sokma ölçütlerini belirleyin. Kaba bir kontrol listesi:

• Önceki DNS kayıtlarını saklayın; DNS değişiklikleri tek başına alan adı geçişini geri almaz. Yönlendirmeleri ve uygulama ayarlarını geri alma adımlarını da belgeleyin.
• Eski domain’in içerik ve yapılandırma yedeklerini elinizin altında tutun.
• Ciddi işlev kaybında geri dönüş kararını kimin vereceğini ve geçiş sonrası oluşan sipariş, kullanıcı kaydı ve e‑postaların nasıl korunacağını önceden belirleyin. Trafik düşüşünde önce nedeni araştırın; eski domain’e dönmeyi otomatik çözüm saymayın.

Tarayıcılar kalıcı yönlendirmeleri, DNS çözümleyicileri de eski hedefleri önbellekte tutabilir. Ters yönlendirmeyi aniden açmak döngü oluşturabilir; geri dönüş, veri tutarlılığı ve Search Console bildiriminin durumunu birlikte ele alan ayrı bir uygulama planı gerektirir.

Geri adım planında sorumluların ve karar ölçütlerinin açık olması, sorun anında ekibin koordineli hareket etmesini sağlar.

Geçiş Planını Uygulamaya Hazırlayın

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’deki 301 yönlendirmelerini mümkün olduğunca uzun, genel olarak en az bir yıl koruyun; 12‑24 aylık bir planı otomatik kapatma tarihi olarak görmeyin. Alan adının tescilini sürdürme kararını ise eski bağlantılar, e‑posta kullanımı ve marka taklidi riskleri açısından ayrıca değerlendirin; yönlendirmeler tek başına bu güvenlik risklerini gidermez.

Altyapı seçeneklerini değerlendirirken, örneğin DCHost’un dedicated sunucu sayfasını incelerken, projenizin kapasite, yedekleme ve geçiş gereksinimlerini yazılı bir listeye dönüştürün. Kurumsal web siteniz, e‑ticaret projeniz veya SaaS uygulamanız için staging, DNS cutover, e‑posta geçişi ve log takibinin sorumlularını belirleyin; seçilen planın kapsamını ve ayrıca gerekecek geçiş desteğini hizmet sağlayıcıyla yazılı olarak netleştirin. Mevcut sitenizin durumunu ve hedeflerinizi netleştiren bir planlama, yeni markaya geçişte arama görünürlüğü ve müşteri erişimiyle ilgili riskleri azaltmaya yardımcı olur.