Mirror ve Giriş Adreslerini Yönetme Workflow’u: Operatörler İçin Pratik Rehber

Bu rehber kimler için, neyi çözer?

“Mirror” (alternatif alan adı/URL) ve “giriş adresi” yönetimi, özellikle yeni kumar siteleri ve mevcut markalar için erişim sürekliliği, kullanıcı deneyimi ve marka güveni açısından kritik bir operasyon alanıdır. Bu içerik; ürün, pazarlama, müşteri destek, IT/DevOps ve uyum ekiplerinin birlikte uygulayabileceği pratik bir workflow sunar.

Önemli not: Bu rehber genel bilgilendirme amaçlıdır. Operasyonlarınızı yürütürken lisans koşullarınıza, tedarikçi sözleşmelerinize ve faaliyet gösterdiğiniz pazardaki düzenlemelere uygun hareket etmeniz gerekir. ABD pazarında düzenlemeler eyalete göre değişebileceğinden, süreçlerinizi hukuk/uyum ekibinizle birlikte netleştirmeniz önemlidir.

Mirror ve giriş adresi: Operatör açısından net tanımlar

Mirror nedir?

Operatörün resmi olarak sahip olduğu veya yönettiği, ana siteyle aynı hizmeti sunan alternatif bir alan adı/URL’dir. Teknik olarak aynı altyapıya yönlendirebilir (reverse proxy/CDN) ya da ayrı bir dağıtım katmanı üzerinden çalışabilir.

Giriş adresi nedir?

Kullanıcının siteye erişmek için kullandığı “güncel URL”dir. Zaman içinde alan adı değişebilir; bu değişim, kullanıcıların doğru adrese yönlendirilmesini ve bilgilendirilmesini gerektirir.

Neden değişiklik olur?

• Marka/ürün kararları: Yeni domain stratejisi, yeniden markalama, yeni ülke/eyalet sayfaları.
• Operasyonel ihtiyaçlar: CDN değişimi, SSL/TLS sertifika yönetimi, altyapı taşıma.
• Risk azaltma: Eski alan adlarının karışıklık yaratması, yönlendirme hataları, kötü kullanıcı deneyimi.

Workflow’un hedefleri (başarı kriterleri)

• Erişim sürekliliği: Kullanıcıların kesinti yaşamadan doğru adrese ulaşması.
• Tek bir “resmi kaynak” mesajı: Kullanıcıların hangi adresin güncel olduğunu kolayca doğrulayabilmesi.
• İletişim tutarlılığı: Destek ekibinden sosyal medya paylaşımlarına kadar aynı bilginin kullanılması.
• Güvenlik hijyeni: HTTPS, sertifika sürekliliği, DNS ve yönlendirme ayarlarının düzenli denetlenmesi.
• Ölçülebilirlik: Hataları hızlı yakalayıp düzeltmek için izleme ve raporlama.

Rol ve sorumluluk matrisi (RACI yaklaşımı)

Giriş adresi değişikliği “tek ekip işi” değildir. Aşağıdaki tablo başlangıç için örnek bir paylaşım sunar.

Adım adım giriş adresi güncelleme süreci (uçtan uca)

1) Planlama: Envanter ve “tek kaynak” yaklaşımı

• Resmi domain envanteri: Tüm aktif alan adları, alt alan adları (www, m, api vb.), uygulama derin linkleri ve kısaltılmış linkler tek listede tutulmalı.
• Tek kaynak sayfası: Kurum içi wiki ve kurum dışı “güncel adres” bilgilendirme sayfası oluşturun. (Kullanıcılar için sade, tarihli bir duyuru alanı.)
• Değişiklik türünü netleştirin: Kalıcı geçiş mi (301), geçici yönlendirme mi (302)? Teknik seçimin pazarlama ve SEO etkilerini ekiplere anlatın.

2) Teknik hazırlık: DNS, CDN ve sertifika kontrol listesi

• DNS kayıtları: A/AAAA/CNAME hedefleri, TTL değerleri ve geri dönüş planı belirlenmeli.
• TLS/HTTPS: Yeni domain için sertifika çıkarma/yenileme, ara sertifika zinciri ve otomatik yenileme kurgusu kontrol edilmeli. (Örn. ACME tabanlı otomasyon yaklaşımı.)
• HSTS ve yönlendirme zinciri: Ziyaretçi önce HTTP’ye düşüp sonra HTTPS’ye mi gidiyor, yoksa doğrudan HTTPS mi? Gereksiz zincirler performansı ve izlemeyi zorlaştırır.
• Uygulama bağımlılıkları: API domainleri, statik varlık alan adları, ödeme/kimlik doğrulama sağlayıcı geri dönüş URL’leri gibi kritik noktalar haritalanmalı.

Teknik ekipler için genel referans olarak ICANN’in alan adı ekosistemi açıklamaları incelenebilir: https://www.icann.org/

3) Ön prod testleri: “Kırılma” noktalarını yakalayın

• Yönlendirme testleri: Eski domain → yeni domain tek adımda gidiyor mu? UTM parametreleri korunuyor mu?
• Kritik akışlar: Kayıt/oturum açma, e-posta doğrulama linkleri, şifre sıfırlama, ödeme sayfaları, canlı destek açılışı.
• Mobil uygulama: WebView/derin link davranışı; kullanıcı tarayıcıya düşüyor mu?
• Analitik ve etiketleme: Ölçüm kodları yeni domain altında doğru çalışıyor mu?

4) Canlıya alma: Kontrollü yayın ve geri dönüş planı

• Yayın penceresi: Trafiğin görece düşük olduğu zaman aralığı seçin, ekipleri hazır bulundurun.
• Aşamalı geçiş: Mümkünse %10 → %50 → %100 gibi kademeli yönlendirme (CDN kuralı veya load balancer ile) uygulayın.
• Geri dönüş (rollback): DNS ve yönlendirme kurallarını önceki hâline döndürme adımları, sorumlu kişiler ve maksimum geri dönüş süresi net olmalı.

5) Kullanıcı bildirimleri: Net, kısa ve doğrulanabilir mesajlar

Kullanıcıların en çok ihtiyaç duyduğu şey “Nereye gideceğim ve bunun resmi olduğundan nasıl emin olacağım?” sorusunun yanıtıdır. Bildirim planını çok kanallı düşünün:

• Site içi banner: Eski domain üzerinde kısa bir banner + yeni adres bağlantısı.
• Yardım merkezi duyurusu: “Güncel giriş adresi” sayfası; tarih, saat, kısa açıklama.
• E-posta/CRM: Daha önce izin vermiş kullanıcılara bilgilendirme; konu satırı sade olmalı, link sayısı minimal tutulmalı.
• Sosyal medya: Sabitlenmiş (pinned) paylaşım ve profil link güncellemesi.
• Uygulama içi mesaj: Uygulama kullanıcıları için tek dokunuşla güncel adrese yönlendirme.

İpucu: Mesajlarda “resmi adres listesi”nin bulunduğu tek bir doğrulama sayfasına yönlendirin. Böylece destek yükü azalır ve tutarlılık artar.

6) Destek ekibi hazırlığı: Makrolar, SSS ve örnek cevaplar

Değişiklikten önce destek ekibine aşağıdakileri hazır verin:

• 1 paragraf açıklama: Neden değişti, kullanıcı ne yapmalı?
• Doğru linkler: Güncel giriş adresi ve yardım merkezi duyurusu.
• Sık sorular: “Tarayıcı hata veriyor”, “Eski link çalışmıyor”, “Uygulama açılmıyor” gibi.
• Kanıt adımı: Kullanıcıya, tarayıcı adres çubuğunda alan adını ve HTTPS kilit simgesini kontrol etmesini hatırlatan nötr bir yönerge.

Mirror yönetimi için operasyon standardı (SOP önerisi)

Mirror envanteri ve yaşam döngüsü

Mirror’lar “aç-kapat” varlıklar gibi yönetilmemeli; yaşam döngüsü olmalı:

1. Talep: Neden gerekli? Hangi süre için? Hangi kullanıcı grupları?
2. Onay: Ürün + Uyum + IT birlikte.
3. Kurulum: DNS/CDN/TLS + yönlendirme kuralları + izleme.
4. Duyuru: Resmi doğrulama sayfasında yayın.
5. İzleme: Hata oranları, dönüşüm hunisi, destek ticket hacmi.
6. Emeklilik: Eski mirror kapatılacaksa kullanıcılar önceden bilgilendirilmeli; 301 ile kalıcı yönlendirme düşünülmeli.

Teknik uygulama notları (genel)

• Yönlendirme stratejisi: Eski URL yapısı korunabiliyorsa bire bir yönlendirme; korunamıyorsa en yakın eşleşen kategori/landing.
• Canonical ve site haritaları: Arama motorları açısından tek “asıl” adresi işaretlemek için canonical yaklaşımı ve sitemap güncellemeleri planlanmalı.
• Durum sayfası: Erişim sorunlarında kullanıcıların bakabileceği sade bir durum sayfası, destek yükünü düşürebilir.

HTTPS ve sertifika otomasyonu hakkında genel bilgi için Let’s Encrypt dokümantasyonu incelenebilir: https://letsencrypt.org/

Kullanıcı güveni için “doğrulanabilirlik” tasarımı

Giriş adresi değişikliklerinde en büyük risk, kullanıcıların hangi adresin güncel olduğunu karıştırmasıdır. Bu nedenle tasarımınızı doğrulanabilirlik üzerine kurun:

• Tek doğrulama sayfası: “Güncel giriş adresleri” listesi (tarih damgalı).
• Tutarlı dil: Tüm kanallarda aynı cümle ve aynı link.
• Minimum yönlendirme: Zincirleri azaltın; kullanıcı tek adımda hedefe gitsin.
• Alan adı görseli: Destek makrolarında, kullanıcıya “adres çubuğundaki alan adını kontrol et” gibi basit hatırlatmalar.

İzleme ve ölçüm: Ne takip edilmeli?

Canlıya alımdan sonraki ilk 24–72 saat için bir “war room” yaklaşımı işinizi kolaylaştırır. Aşağıdaki metrikler pratik başlangıç setidir:

• HTTP durum kodları: 301/302 oranı, 404/5xx artışı.
• Sayfa yükleme hataları: DNS çözümleme sorunları, TLS el sıkışma hataları (log bazlı).
• Giriş/oturum açma başarı oranı: Ani düşüş var mı?
• Destek hacmi: “Giriş adresi” konulu ticket artışı.
• Kaynak/kanal performansı: E-posta tıklamaları, uygulama içi mesaj CTR gibi.

Olay sonrası değerlendirme (postmortem)

• Ne planlandı, ne oldu?
• En çok hangi kullanıcı grubu etkilendi?
• Hangi izleme alarmı eksikti?
• Bir sonraki değişiklikte neyi standartlaştırıyoruz?

Operatörler için hızlı kontrol listesi

• Envanter: Tüm resmi domain/mirror listesi güncel.
• Tek doğrulama sayfası: Dışarıdan erişilebilir, tarihli duyuru var.
• DNS/TLS: Kayıtlar ve sertifikalar canlıdan önce test edildi.
• Yönlendirme: Zincir yok (mümkünse tek adım), UTM korunuyor.
• Kritik akış testi: Kayıt, giriş, doğrulama e-postaları, şifre sıfırlama, ödeme akışları kontrol edildi.
• İletişim: Banner + yardım merkezi + CRM + sosyal medya metinleri hazır ve onaylı.
• Destek: Makrolar, SSS ve eskalasyon hattı hazır.
• İzleme: 404/5xx ve giriş başarısı için alarm kuralları var.
• Geri dönüş: Rollback adımları yazılı ve sorumlular belli.

Sonuç: Erişim sürekliliği “süreç” işidir

Mirror yönetimi ve giriş adresi güncelleme, tek seferlik teknik bir değişiklikten ziyade, operasyon + iletişim + ölçüm bileşimidir. Net bir envanter, tek doğrulama kaynağı, disiplinli yönlendirme stratejisi ve hazırlıklı destek ekibiyle hem erişim sürekliliğini güçlendirebilir hem de kullanıcıların doğru adrese güvenle ulaşmasını kolaylaştırabilirsiniz.

Eğer içerik ekibiniz aynı zamanda yeni kumar siteleri için rehber/inceleme sayfaları yayımlıyorsa, giriş adresi değişikliklerinin bu sayfalarda da hızlı ve tutarlı şekilde güncellenmesini sağlayacak bir yayın kontrol adımı eklemek faydalı olur.