Alan Adı Yaşam Döngüsü ve Düşen Domain Yakalama

Alan Adı Yaşam Döngüsü Neden Bu Kadar Kritik?

Alan adınız web sitesi, e-posta, müşteri bağlantıları ve marka iletişiminin ortak adresidir. Sunucuyu taşımanız alan adı kaydını yenilemez; kayıt ücretini ödemeniz de DNS ve e-posta hizmetlerinin doğru yapılandırıldığını kanıtlamaz. Kaydı kaybettiğinizde eski adreslerden yönlendirme yapma ve o alan adına bağlı hizmetleri yönetme imkânınız da kaybolabilir. Yaşam döngüsünü bilmek, hangi aşamada yenileme veya kurtarma talep edebileceğinizi ayırt etmenize yardımcı olur.

Bu rehber kayıt, süre dolması, registry otomatik yenileme dönemi, redemption, son pending delete aşaması ve düşen domain yakalama süreçlerini açıklar. .com ve .net için belgelenmiş süreleri örnek alır; bunlar bütün uzantılar için ortak bir takvim değildir. Önce mevcut alan adınızı korumayı, sonra backorder ve açık artırmanın koşullarını değerlendirmeyi ele alacağız. Hiçbir takip veya yakalama hizmeti, yenilenebilir bir alan adını zamanında yenilemenin güvencesini sağlamaz.

Alan Adı Yaşam Döngüsü Temelleri

Kayıt sahibi (registrant) alan adının kayıt hakkını kullanan kişi veya kuruluştur. Registrar kaydı registry ile yöneten yetkili kayıt kuruluşu, registry ise uzantının kayıt veritabanını işleten operatördür. Hizmeti bir bayi üzerinden alabilirsiniz; müşteri panelini işleten sağlayıcı ile RDAP kaydında görünen registrar aynı kuruluş olmak zorunda değildir. gTLD kuralları ile .tr, .uk veya .de gibi ccTLD politikalarını birbirine karıştırmayın.

Aşağıdaki akış, yenilenmeyip registrar tarafından silinen sıradan bir .com/.net kaydı için temel modeli gösterir. Yenileme, geri yükleme veya silinmeden yapılan bir açık artırma sonucu kayıt sahibinin değişmesi bu akışı durdurabilir:

• Müsait: Registry kurallarına göre yeni kayıt yapılabilen ad; rezerve veya özel tahsisli adlar farklı olabilir.
• Kayıtlı: Kayıt süresi devam eder. .com/.net için toplam süre sınırını ve sağlayıcının sunduğu yıl seçeneklerini kontrol edin; çalışan site ayrıca DNS ve hosting gerektirir.
• Süresi dolmuş: Sağlayıcının yenileme son tarihi kaçmıştır; ad hemen yeni kayda açılmış sayılmaz.
• Auto-Renew Grace Period: .com/.net registry sistemi süre sonunda otomatik uzatma yapar; 45 günlük dönem registrar ile registry arasındaki işlem ve ücret kuralları içindir. Müşteriye 45 gün yenileme hakkı verildiği anlamına gelmez.
• Redemption Grace Period: Add Grace Period dışındaki silme talebiyle başlayan, bu uzantılarda 30 gün süren geri yükleme dönemi.
• Son Pending Delete: Redemption sonrası kurtarılmamış kaydın beş takvim günlük son silinme aşaması; bu aşamada geri yükleme yapılamaz.
• Drop: Kayıt veritabanından çıkarılan ad, ilgili tahsis kuralları izin veriyorsa yeniden kayda açılır. Başka bir başvuru sahibi onu hemen kaydedebilir.

“Expired” gibi panel etiketleri ile RDAP/EPP durum kodları aynı şey değildir. Özellikle pendingDelete kodu redemptionPeriod veya pendingRestore ile birlikte görünebilir. Birlikteyse kurtarma durumunu diğer kod belirler; yalnızca pendingDelete kelimesini görerek artık kurtarılamayacağı sonucuna varmayın. Sağlayıcıdan mevcut aşamayı, kesin son tarihi, ücreti ve gerekli işlemi yazılı olarak doğrulayın.

Kayıt ve Aktif Dönem: Yenilemeyi Unutmayın

Aktif kayıt döneminde yenileme sorumlusunu ve ödeme yolunu belirleyin. Otomatik yenileme ayarının açık olması işlemin tamamlandığını göstermez: kart reddi, bakiye eksikliği veya eski iletişim bilgileri süreci aksatabilir. Fatura ve panelde başarılı yenilemeyi, yeni kayıt süresini ve hata bildirimlerini kontrol edin; yalnızca kamuya açık kayıtta ileri bir tarih görünmesine güvenmeyin.

Örneğin, teknik ekiple pazarlama ekibinin farklı e-posta adresleri kullandığı bir şirkette, bildirimleri kimin takip ettiği belirsizse yenileme hatırlatmaları gözden kaçabilir. Bu yüzden:

• Alan adı hesabında kurumun kontrolündeki, düzenli izlenen bir iletişim adresi kullanın. Kurtarma ve hatırlatma kanallarından en az biri yönetilen alan adından bağımsız çalışsın.
• Yenileme sorumlusu ve yedeği belli olsun; ortak takvimde örneğin son tarihten 30–60 gün önce kontrol hatırlatmaları oluşturun.
• Önemli adlarda, uzantı ve bütçe uygunsa birkaç yıllık kayıt tercih edin. Bu, yenileme sıklığını azaltır; süresiz sahiplik veya arama sıralaması avantajı sağlamaz.

Kayıt bilgilerinin yanında DNS yapılandırmasını da envanterde tutun. DNS kayıtları rehberi A, AAAA, CNAME, MX ve TXT gibi kayıtların görevlerini açıklar. Yetkili ad sunucularını, e-posta kayıtlarını ve hizmet sorumlularını bilmek; sağlayıcı değişiminde veya kesintide hangi katmana müdahale edeceğinizi netleştirir.

Süre Dolması ve Yenileme Hakkı: Son Tarihi Doğrulayın

Sağlayıcının yenileme son tarihi geçtiğinde kayıt süresi dolmuş kabul edilebilir; bu tarih registry’nin otomatik uzattığı kamuya açık bitiş tarihinden farklı görünebilir. Alan adı hemen silinmese de DNS yolu değişebilir veya kesilebilir. ICANN’in kapsam dahilindeki gTLD’ler için bildirim ve DNS kesintisi kuralları vardır; uygulanan müşteri süresini ve yenileme hakkını kendi sözleşmenizden doğrulayın.

• Web sitesi çalışmayabilir veya süre dolduğunu bildiren bir sayfaya gidebilir.
• MX kayıtlarına erişim veya doğru mail yönlendirmesi bozulursa e-posta teslimi aksar. Geçici hatalarda yeniden deneme, kalıcı hatalarda teslimin reddi mümkün olabilir.
• Registrar DNS yolunu değiştirebilir; bu, eski yetkili DNS sunucusunun fiziksel olarak kapanması demek değildir. Önbellekteki cevaplar bir süre farklı sonuçlar gösterebilir.

Registry Auto-Renew Grace Period ile müşterinin yenileme süresi farklıdır. .com/.net sisteminde kayıt, süresi dolduğu tarihten sonraki ilk gün otomatik uzatılır; ilgili registry dönemi 45 takvim günüdür. Registrar bu dönemde kaydı silerse otomatik uzatma ücretini geri alabilir. Bu işlem, hesabınızdaki otomatik ödeme ayarından ayrıdır ve faturanızın ödendiğini göstermez. Registrar, uygulanabilir politikalar ve sözleşmesi çerçevesinde daha erken bir müşteri son tarihi belirleyebilir.

• Normal ücretle yenileme imkânı ve varsa ek bedeller sağlayıcının güncel politikasına bağlıdır; 45 günü bekleme hakkı gibi kullanmayın.
• ICANN’in kapsam dahilindeki kuralları, kayıt silinmeden önce belirli DNS kesintisi ve yenilemeye izin verme yükümlülükleri getirir. Süreyi anlaşılmayan bir panel etiketinden çıkarmak yerine destekten teyit edin.
• Silinmemiş bir kayıt normal yeni kayıt işlemiyle alınamaz; ancak sağlayıcının şartlarına göre silinmeden önce açık artırmaya çıkarılabilir. Yenileme veya kayıt sahibinin değişmesi, halka açık drop gerçekleşmesini engelleyebilir.

Alan adını korumak istiyorsanız uygunluğu doğrulayıp yenilemeyi mümkün olduğunca erken tamamlayın. Sonrasında yeni kayıt süresini, DNS yolunu, HTTPS’i ve e-postayı ayrı ayrı kontrol edin; önbellekler yüzünden hizmetler aynı anda toparlanmayabilir. Alan adı süresi dolduğunda izlenecek yol rehberi bu kurtarma kararlarını daha ayrıntılı ele alır.

Redemption: Silme Talebinden Sonra Geri Yükleme

Redemption, müşteri yenileme süresi biter bitmez kendiliğinden başlayan zorunlu bir sonraki adım değildir. .com/.net’te, ilk kayıt sonrası Add Grace Period dışında registrarın silme talebi registry tarafından başarıyla işlendiğinde kayıt redemptionPeriod durumuna girer ve geri yüklenmezse 30 takvim günü tutulur. ICANN ERRP, sponsorlu gTLD registry’leri hariç gTLD’lerde silmeyi izleyen 30 günlük RGP ister; Add Grace Period içindeki silmeler istisnadır. ccTLD ve özel tahsis kurallarını ayrıca inceleyin.

Redemption döneminin temel özellikleri:

• RDAP veya sağlayıcı panelinde redemptionPeriod kodunu kontrol edin. pendingRestore, geri yükleme talebinin işlemde olduğunu gösterir; tamamlandığı anlamına gelmez.
• Geri yüklemeyi, kaydı silen registrar üzerinden kayıt sahibi talep eder. Yenileme ve restore ücretlerinin toplamını, son tarihi ve işlem için gereken doğrulamayı öğrenin.
• Bu dönemde .com/.net kaydı registry zone dosyasında yer almaz. Eski DNS cevaplarının süresi doldukça normal site ve e-posta erişimi kesilir.
• Geri yükleme işleminin tamamlandığını ve DNS/hizmetlerin geri geldiğini doğrulayın. Talep açılması veya ödeme makbuzu tek başına teknik başarı kanıtı değildir.

Varsayımsal olarak, bir şirketin ana alan adını yenilemeyi unutup redemption’a girdiğini düşünün. Geri yükleme maliyeti normal yenilemeden yüksek olabilir; buna karşılık alan adı üzerindeki müşteri bağlantıları, e-posta ve hizmet bağımlılıkları kaybın maliyetini büyütebilir. Karar verirken yalnızca geçmiş backlink sayısına değil, şu somut etkilere bakın:

• Alan adı hangi marka, müşteri, oturum açma veya e-posta süreçlerinde kullanılıyor?
• Geri yükleme uygunluğu, toplam ücret ve kalan süre doğrulandı mı?
• Kurtarılamazsa yeni adla iletişim, DNS, uygulama ve e-posta geçişi nasıl yapılacak?

Kritik bir alan adı hâlâ geri yüklenebiliyorsa bunu değerlendirmek, düşmesini bekleyip yeniden almaya çalışmaktan genellikle daha kontrollüdür. Yine de işlem tamamlanana kadar hizmetlerin kesintisiz kalacağını varsaymayın. Son aşamaya geçilirse eski kayıt sahibi olmanız yeni kayıtta öncelik veya başarı garantisi sağlamaz.

Son Pending Delete Aşaması: Geri Yükleme Sona Erer

Redemption süresi içinde geçerli bir restore talebi başlatılmazsa .com/.net kaydı son Pending Delete dönemine geçer. Süresinde başlatılmış pendingRestore işlemini ayrı izleyin; bu durum son silinme aşaması değildir. Burada kastedilen, redemptionPeriod veya pendingRestore ile birlikte görünen kod değil, geri yükleme olanağı sona ermiş son aşamadır. Durumu registrar ile doğrulayın:

• .com/.net’in bu son aşaması beş takvim günüdür; genel bir “5–7 gün” kuralını bütün uzantılara uygulamayın.
• Bu aşamada registrarın yenileme veya geri yükleme isteğiyle kaydı kurtarması mümkün değildir.
• Backorder talebinin kabul süresini, desteklenen uzantıyı ve koşullarını kontrol edebilirsiniz; talep açılması kayıt hakkı kazandırmaz.

Sürenin ardından ad registry veritabanından çıkarılır ve ilgili kurallar izin veriyorsa yeniden kaydedilebilir. Sadece bitiş tarihine süreler ekleyerek kesin düşme saniyesi hesaplamayın; müşteri yenileme son tarihi, gerçek silme olayı ve registry’nin işleme düzeni ayrı unsurlardır. Rezerve veya özel tahsisli adlar olağan halka açık kayıt akışından farklı davranabilir.

Bu noktada devreye drop catching ve backorder stratejileri girer.

Düşen Domain Nedir, Neden Bu Kadar Popüler?

Dar anlamıyla “düşen domain”, eski kaydı silinmiş ve yeniden kayıt için serbest bırakılmış addır. Süresi dolmuş fakat silinmemiş bir alan adı ise hâlâ yenilemeye, geri yüklemeye veya sağlayıcının açık artırma sürecine konu olabilir. Bir pazaryerinin “expired” etiketi, adın yeni kayıt için müsait olduğunu kanıtlamaz.

Düşen domainlerin bu kadar talep görmesinin birkaç temel nedeni var:

• Kullanışlı isim: Projeye uygun, akılda kalıcı bir ad ilgi çekebilir; eski sahibinin marka hakkını veya içeriğini devralmış olmazsınız.
• Geçmiş bağlantılar: Önceki URL’lere gelen ilgili bağlantılar incelenebilir; bağlantı sayısı, alan adı yaşı veya üçüncü taraf puanları gelecekteki sıralamayı garanti etmez.
• Marka varyasyonları: Benzer adları koruma ihtiyacını maliyet ve hukuki riskle birlikte değerlendirin.
• Geçmiş kitle: Önceki ziyaretçiler yeni projeyi eski işletmeyle karıştırabilir. Kimliği açıkça belirtin; başka bir markanın tanınırlığından yanıltıcı biçimde yararlanmayın.

Elbette burada dikkat edilmesi gereken pek çok risk var: spam geçmişi, manuel ceza, kötü link profili gibi. Bunlara da backorder stratejilerini anlatırken değineceğiz.

Drop Catching ve Backorder Nedir?

Drop catching, registry yeni kayıt kabul etmeye başladığında alan adını kaydetmeyi denemektir. EPP kullanan registry’lerde registrar, yeni domain oluşturma isteğini bu protokol üzerinden gönderir. Başarı registry’nin kabul ettiği kayıt sonucuna ve geçerli tahsis kurallarına bağlıdır; sorgunun hızlı görünmesi veya bir sağlayıcının çok sayıda bağlantısı olması tek başına başarı kanıtı değildir.

Backorder, bir sağlayıcıya belirli alan adı için kayıt denemesi yapma talebidir. Siparişin hangi tarihe kadar verilebildiği, hangi TLD’leri kapsadığı ve yakalama sonrası atama veya açık artırma yöntemi hizmete göre değişir. Genel iş akışı şöyledir:

• Sağlayıcı alan adının kayıt durumunu ve kendi kabul koşullarını izler.
• Uygun ad için kayıt açılışına yönelik otomatik denemeler planlayabilir; bu işlem kesin bir düşme saati veya müşteriye sıra hakkı vermez.
• Başarılı olursa ücret, ödeme ve varsa açık artırma kurallarını uygular. Başarısızlıkta ücret iadesi, kredi veya ücret alınmaması ancak sözleşmede belirtilen koşullara göre değerlendirilir.

Burada iki önemli nokta var:

1. Backorder, adı sizin alacağınızı garanti etmez. Başka bir registrar kaydı alabilir; alan adı yenilenebilir, restore edilebilir veya silinmeden el değiştirebilir.
2. Sağlayıcı adı yakalasa bile birden fazla talep varsa açık artırma gerekebilir. Bazı açık artırmalar yalnızca talep sahipleriyle sınırlı değildir; kimlerin katılabildiğini ve toplam maliyeti önceden okuyun.

Önce kendi kritik alan adlarınızın yenileme ve kurtarma işlerini tamamlayın. Yeni ad edinme hedefini ayrı bir bütçe, marka kontrolü ve kullanım planıyla değerlendirin. Birden fazla servise talep verirken her birinin ödeme taahhüdünü ve iptal koşulunu bilmeniz gerekir; genel bir merkezi backorder sırası yoktur.

Kendi Alan Adınızın Düşme Riskini Azaltın

Koruma planı, tek bir otomatik ödeme seçeneğinden daha fazlasını gerektirir. Sorumluluklar, erişim yedeği ve başarısız yenileme uyarıları birlikte çalışmalıdır. Şu kontrolleri düzenli olarak yapın:

• Otomatik yenileme: Uzantı ve sağlayıcı destekliyorsa açın; kart/bakiye durumunu ve başarılı işlem sonucunu doğrulayın.
• İletişim ve yetki: Kayıt sahibini doğru tutun; izlenen bildirim adresi, bağımsız kurtarma kanalı ve yetkili yedek sorumlu belirleyin.
• Kayıt süresi: Önemli adlarda birkaç yıllık kayıt yenileme sıklığını azaltabilir. Uzun kayıt süresini SEO veya güven puanı satın almak gibi değerlendirmeyin.
• Hesap güvenliği: Güçlü benzersiz parola, 2FA, kurtarma kodları ve sınırlı kullanıcı yetkileri kullanın. Registrar transfer kilidi yararlıdır; yenileme veya silinmeyi her durumda engellemez.

Alan adı güvenliği rehberi transfer kilidi, DNSSEC, kayıt verilerinin gizliliği ve hesap korumasını ele alır. DNSSEC, veri gizliliği ve redaksiyon ayarları yenileme takibinin, kayıt sahibi doğrulamasının veya hesap güvenliğinin yerine geçmez.

Düşen Domain Peşinde Koşmadan Önce: Strateji ve Filtreler

Başkalarının bıraktığı adları değerlendirirken önce yeni projenin ihtiyacını tanımlayın. Sadece yüksek geçmiş trafik veya üçüncü taraf SEO puanı görüldüğü için alım yapmayın. Bir adı edinmeden önce şu sorulara açık cevap verin:

• Bu domain marka stratejimle uyuşuyor mu?
• SEO açısından gerçekten artı değer katacak mı, yoksa risk mi taşıyor?
• Bu ismi alırsam, ilgili diğer TLD’leri de uzun vadede toplamak mantıklı mı?

Uluslararası projelerde ad seçimini hedef dil, kullanıcı ve işletim planıyla birlikte değerlendirin. Uluslararası SEO ve alan adı stratejisi rehberi ccTLD, gTLD, alt alan adı ve alt dizin seçeneklerini karşılaştırır. Düşen bir adın geçmişte başka ülkede kullanılmış olması, yeni sitenizin o pazarda sıralama elde edeceğinin kanıtı değildir.

Backorder Verilecek Domain Nasıl Seçilir?

Elinizde potansiyel bir liste var diyelim. Hangi domain için backorder vermeye değeceğini belirlemek için şu filtreleri kullanabilirsiniz:

1. Marka ve Hukuki Risk Analizi

• Domain, tescilli bir marka adını açıkça içeriyor mu?
• İleride olası bir marka ihlali davası riski var mı?
• Önceki sahibi tanınan bir şirket mi, kullanıcılar hâlâ o alanı onlarla özdeşleştiriyor olabilir mi?

Örneğin, çok bilinen bir markanın .net veya .org varyasyonunun düşmesi ilk bakışta cazip görünebilir; fakat uzun vadede hukuki riskleri ciddi olabilir.

2. SEO ve Backlink Profili Analizi

• Alan adının geçmişinde spam içerik veya PBN (özel blog ağı) geçmişi var mı?
• Backlink’lerin kalitesi ve çeşitliliği nasıl?
• Önemli sayfalara verilen linkler hâlâ canlı mı, yoksa 404 mü dönüyor?

DA/DR gibi üçüncü taraf puanları satın alma kararının veya Google sıralamasının garantisi değildir. Eski içerikleri ve bağlantıların gerçek hedeflerini inceleyin; tek bir araç tüm geçmişi ortaya koyamaz. Google’ın expired domain abuse politikası, süresi dolmuş bir adı ağırlıkla sıralamayı manipüle etmek için alıp kullanıcıya az ya da hiç değer vermeyen içerikle kullanmayı spam olarak tanımlar. Yaş ve backlink için alakasız, düşük değerli bir site kurmayın.

3. Teknik Geçmiş ve Kullanım Senaryoları

• Eski içerik, hizmet ve hedef kitle yeni kullanım amacınızla ilişkili mi? Arşivlerin eksik olabileceğini hesaba katın.
• E-posta veya güvenlik blok listelerinde görünen kayıtları araştırın; temiz bir sonuç geçmişin tamamının sorunsuz olduğunu kanıtlamaz.
• Alan adı üzerinde önceki işletmeye ait marka, içerik veya kullanıcı hesabı hakları bulunduğunu varsaymayın. Yeni projede kimliği ve iletişim kanallarını açıkça ayırın.

Örneğin geçmişte başka dilde ve başka konuda kullanılan bir adı Türkçe bir mağazaya dönüştürmek, eski arama performansının aynen taşınacağı anlamına gelmez. Eski URL’lerin içeriğini, bağlantıların neden verildiğini ve yeni sayfanın kullanıcının ihtiyacını karşılayıp karşılamadığını değerlendirin; geçmişte indekslenmiş olmak tek başına yeni içerik için avantaj taahhüdü değildir.

Backorder Süreci Adım Adım Nasıl İşler?

Genel hatlarıyla tipik bir backorder sürecini şu şekilde özetleyebiliriz:

1. Durumu doğrulayın: gTLD’lerde RDAP, varsa WHOIS ve sağlayıcı panelini kullanın; bütün durum kodlarını ve registrarın son tarihini okuyun.
2. Süreç türünü ayırın: Silinmeden yapılan expired/pre-release açık artırması ile silinme sonrası backorder aynı işlem değildir.
3. Koşulları okuyun: TLD desteği, son talep saati, ücret, iade, iptal ve açık artırma katılım kurallarını karşılaştırın.
4. Denemeyi izleyin: Talep kabulü veya “yakalandı” bildirimiyle yetinmeyin; ödemenin, kayıt sahibinin ve hesabınıza atamanın tamamlandığını doğrulayın.
5. Başarısızlığı planlayın: Alan adı başka birine giderse yenileme/restore hakkınız geri gelmez. Alternatif ad ve kesintiden etkilenen hizmetler için planınız hazır olsun.

Pre-release açık artırmasında kayıt, halka açık drop gerçekleşmeden başka bir kayıt sahibine atanabilir; bu, zorunlu olarak registrar değişikliği demek değildir. Eski sahibin yenileme hakkı sürüyorsa ve yenileme kabul edilirse satış iptal edilebilir; hangi tarihte bu hakkın bittiği sağlayıcı politikasına bağlıdır. .com/.net’in 45 günlük registry dönemini açık artırma takvimi veya size ayrılmış yenileme süresi gibi yorumlamayın.

Düşen Domaini Aldıktan Sonra Nelere Dikkat Etmelisiniz?

Alan adı gerçekten hesabınıza geçtiğinde kayıt sahibi bilgilerini, yenileme tarihini ve erişim yetkilerini kontrol edin. Yeni kaydı eski sahibin içerik, marka veya e-posta hesaplarının devri gibi görmeyin. Kullanıma açmadan önce hedef hizmetler için şu hazırlıkları tamamlayın:

• DNS ve DNSSEC: Yeni yetkili ad sunucularını ve yalnızca kullanılan A/AAAA, CNAME, MX/TXT kayıtlarını hazırlayın. DNSSEC kullanıyorsanız parent DS ile aktif imzalama anahtarlarının uyumunu doğrulayın.
• HTTPS ve uygulama: Kullanılacak her hostname için sertifika ve sunucu yönlendirmesini doğrulayın. Geçici sayfa tek başına arama performansı sağlamaz.
• Eski URL’ler: İlgili gerçek karşılığı olan sayfaları doğru hedefe 301 yönlendirin. Karşılığı olmayan eski sayfalarda 404 veya 410 kullanın; tüm adresleri alakasız ana sayfaya yönlendirmeyin.
• E-posta: Mail gönderilecekse yetkili servisler için SPF/DKIM/DMARC yapılandırmasını ve gelen mail yolunu test edin. Kullanılmayan mail hizmeti için rastgele MX oluşturmayın.

Mevcut bir siteyi bu ada taşıyacaksanız DNS TTL ve taşıma planlama rehberi hazırlık adımlarını açıklar. Kontrolünüzdeki kayıtların TTL’sini önceden azaltmak geçişi kolaylaştırabilir; parent delegasyon ve negatif önbellek sürelerini sizin TTL ayarınız değiştirmez. DNS, HTTPS, içerik, e-posta ve eski URL yönlendirmelerini birlikte test edin; kesintisizlik garantisi vermeyin.

Mevcut Alan Adınızı Başka Bir Registrara Taşırken Dikkat

Alan adını edinmek, hemen başka bir registrara aktarabileceğiniz anlamına gelmez. Aynı sağlayıcı içinde hesap veya kayıt sahibi değişikliği ile registrarlar arası transferi ayırın. Transfer uygunluğunu, geçerli kilitleri, doğrulama yöntemlerini ve kalan kayıt süresini başlamadan kontrol edin:

• gTLD transferi ilk kayıt veya önceki registrar transferinden sonraki 60 gün içinde politika kapsamında engellenebilir. Kayıt sahibi değişikliği de ayrı bir 60 günlük transfer kilidi doğurabilir; varsa önceden sunulan vazgeçme seçeneğinin koşullarını doğrulayın.
• AuthInfo/EPP kodunu güvenli biçimde alın; yetkili transfer onayını tamamlayın ve kaldırılabilir transfer kilidini uygun şekilde yönetin. Kişisel iletişim bilgilerinin kamuya açık WHOIS’te yayımlanması şart değildir; gTLD kayıt bilgisi için RDAP temel sorgu yoludur.
• Sıradan .com/.net transferi genellikle kayıt süresine bir yıl ekler; toplam on yıl sınırı ve otomatik uzatma dönemindeki iptal/mahsup kuralları nedeniyle her işlem iki ayrı ek yıl kazandırmaz. Yenileme ücretlerinin nasıl işleneceğini iki sağlayıcıdan da öğrenin.

Alan adı transferi rehberi AuthInfo, kilitler ve DNS/e-posta sürekliliği için ek açıklamalar sunar. Redemption’daki alan adını normal transferle kurtarmaya çalışmayın; önce mevcut registrar üzerinden restore gerekir. Kayıt transferi DNS veya hosting hizmetini kendiliğinden taşımadığından, eski hizmetin ne zaman kapatılacağını ayrıca planlayın.

Düşen Domainle SEO Taşımak: Efsaneler ve Gerçekler

Bir alan adının geçmişi otomatik sıralama hakkı vermez; geçmiş sinyallerin tamamının her durumda sıfırlandığını da varsaymayın. Yeni içeriğin niteliği, konu ilişkisi, erişilebilirlik ve bağlantıların gerçek bağlamı önemlidir. Alan adı satın almayı, kullanıcılara faydalı bir site kurma ve düzgün teknik geçiş planından ayrı bir SEO kısayolu gibi ele almayın.

İncelenebilecek Yararlı Unsurlar

• Projenizle ilişkili, hâlâ erişilen eski URL’ler ve bunlara verilen doğal bağlantılar.
• Yeni kullanımla uyumlu, açık ve yanıltıcı olmayan bir alan adı.
• Yasal kullanım hakkına sahip olduğunuz içerik ve anlamlı sayfa eşlemeleri; sadece yaş veya eski indeks kaydı değil.

Olası Eksiler

• Eski spam içeriği, bağlantı manipülasyonu veya arama motoru işlemleri nedeniyle ek inceleme gerekebilir.
• Alakasız niş veya dildeki geçmiş, yeni projenizin aynı ziyaretçiye hitap edeceği anlamına gelmez.
• Alakasız toplu yönlendirmeler kullanıcıyı yanıltabilir ve soft 404 olarak değerlendirilebilir. Kullanıcıya değer vermeden eski adın sinyallerini kullanmaya çalışmak spam riski taşır.

Eski alan adını kaybettiyseniz, kontrolünüz olmayan sunucudan 301 veremezsiniz. Yeni sitenin iç bağlantılarını, canonical adreslerini ve sitemap’ini hazırlayın; etkileyebildiğiniz dış bağlantıları güncelleyin. Eski adın kontrolünü koruyor veya geri alıyorsanız eşdeğer URL’lere yönlendirme uygulayıp iki tarafı test edin. Alan adı değişikliği ve SEO geçişi rehberi bu planı ayrıntılandırır; sıralamanın hiç değişmeyeceği garanti edilemez.

Alan Adı ve Altyapı Sorumluluklarını Netleştirin

Alan adı kaydı ile VPS, hosting ve DNS hizmetleri farklı sorumluluklar içerir. Aynı sağlayıcıdan alınmaları her işlemin otomatik veya aynı ücret kapsamında olduğu anlamına gelmez. DCHost ya da başka bir sağlayıcıyla çalışırken yenileme, restore, DNS, sertifika ve taşıma işlerinden kimin sorumlu olduğunu önceden netleştirin.

• Birincil alan adınız için doğrulanmış yenileme yöntemi, hata uyarısı ve bağımsız kurtarma kanalı kurun.
• DNS, hosting, HTTPS ve e-posta ayarlarını envantere alın; değişiklik ve kurtarma sonrasında hizmetleri ayrı ayrı test edin.
• Gereken marka varyasyonları için kapsam ve bütçe belirleyin; kullanılmayan adları bırakmadan önce eski e-posta ve hesap kurtarma bağımlılıklarını kaldırın.
• Yeni alan adı alımını hak kontrolü, geçmiş incelemesi ve toplam maliyet sınırı bulunan bir süreç olarak yönetin.

Alan adının kaydı ile altında çalışan altyapıyı birlikte planlayın. VPS veya dedicated sunucu seçimi, uygulama yükü ve işletim ihtiyacına göre yapılmalıdır; bir domain yakalamak belirli sunucu kapasitesi gerektirdiği anlamına gelmez. Yönetim, yedekleme ve güvenlik hizmetlerinin kapsamını sağlayıcı sözleşmesinden doğrulayın.

Yenileme, Kurtarma ve Yeni Kayıt İçin Yol Haritası

Önce kayıt sahibi, registrar, durum kodları ve gerçek müşteri son tarihini belirleyin. Registry auto-renew dönemini ödeme başarısı veya size ayrılmış ek süre saymayın. Silme talebiyle başlayan redemption’da uygun restore yolunu değerlendirin; son pending delete aşamasındaysa geri yükleme yerine alternatif ad ve varsa backorder planı gerekir. Silinmeden yapılan açık artırmaları halka açık drop’tan ayırın.

Buradan sonra atabileceğiniz somut adımlar şunlar olabilir:

• Kendi adlarınızda yenileme ayarı, ödeme yöntemi, bildirimler ve sorumluları kontrol edin; tamamlanan işlemi doğrulayın.
• Kritik ad redemption’daysa mevcut sağlayıcıdan kesin son tarih, toplam ücret ve gerekli doğrulamayı öğrenin.
• Backorder için TLD desteği, katılım ve ödeme kurallarını okuyun; bütçe sınırı ve başarısızlık planı belirleyin.
• Edindiğiniz adlarda kayıt sahibi/hesap atamasını ve DNS, HTTPS, e-posta, içerik ve yönlendirme hazırlığını doğrulayın.

Doğru karar, yalnızca “kaç gün kaldı” hesabına dayanmaz; hangi politika altında hangi işlemin hâlâ yapılabildiğini bilmenizi gerektirir. Yenileme ve kurtarma için sağlayıcınızdan somut durum bilgisi isteyin, sonuçları kaydedin ve sorumlu kişiyi belirleyin. Böylece sürenin dolması, açık artırma veya kayıt başarısızlığı karşısında izleyebileceğiniz bir planınız olur.