Sunucu Taşıma (Migration) Nasıl Yapılır? Veri Kaybı Olmadan Site Taşımak

Sunucu taşıma (migration), bir web sitesinin dosyalarını, veritabanını, e-posta hesaplarını, DNS kayıtlarını ve uygulama ayarlarını mevcut sunucudan yeni sunucuya planlı şekilde aktarma işlemidir. Veri kaybı olmadan site taşımak için temel yöntem şudur: önce tam yedek alınır, yeni sunucu aynı veya daha güncel yazılım sürümleriyle hazırlanır, dosya ve veritabanı aktarılır, hosts dosyası veya geçici URL ile test yapılır, DNS yönlendirmesi düşük TTL ile değiştirilir ve taşıma sonrası loglar, formlar, ödeme akışları, e-posta teslimi ve SEO sinyalleri kontrol edilir.

Sunucu taşıma işlemi basit bir kopyala-yapıştır süreci değildir. Özellikle WordPress, WooCommerce, Laravel, özel PHP uygulamaları, yüksek trafikli haber siteleri veya kurumsal e-posta kullanan işletmeler için yanlış bir taşıma; sipariş kaybı, bozuk Türkçe karakterler, 500 hataları, SSL uyarıları, e-posta kesintisi ve arama motoru görünürlüğünde düşüş gibi sonuçlar doğurabilir. Bu nedenle migration planı, teknik kontrol listesi ve geri dönüş senaryosu ile yürütülmelidir.

Bu rehberde bir hosting veya sunucu değişikliğini 2026 SEO ve performans beklentilerine uygun şekilde nasıl yapacağınızı adım adım ele alacağız. Ayrıca cPanel, Plesk, VPS, bulut sunucu ve manuel taşıma gibi farklı senaryolara değinecek; DNS süresi, yedekleme kapsamı, veritabanı uyumluluğu, SSL kurulumu ve taşıma sonrası SEO kontrolleri için uygulanabilir öneriler paylaşacağız.

Sunucu Taşıma Ne Zaman Gerekir?

Bir web sitesini yeni sunucuya taşımak genellikle performans, güvenlik, maliyet veya ölçeklenebilirlik ihtiyacından doğar. Örneğin aylık 5.000 ziyaretçili bir kurumsal site paylaşımlı hosting ile sorunsuz çalışabilirken, günlük 20.000 ziyaretçi alan bir e-ticaret sitesinde CPU limiti, yavaş sorgular ve ödeme sayfasında zaman aşımı sorunları görülebilir. Bu noktada daha güçlü bir hosting paketi, VPS veya bulut altyapısı tercih edilir.

Sunucu taşıma ihtiyacını gösteren yaygın sinyaller şunlardır:

• Sayfa açılış süresinin 3 saniyenin üzerine çıkması ve Core Web Vitals metriklerinin bozulması.
• Hosting panelinde CPU, RAM, inode veya disk kullanım limitlerinin sık sık dolması.
• PHP, MySQL, MariaDB, Node.js veya ionCube gibi bileşenlerde güncel sürüm ihtiyacı.
• SSL yenileme, e-posta teslimi veya DNS yönetimi gibi konularda sık sorun yaşanması.
• Mevcut sağlayıcıda destek kalitesi, yedekleme veya güvenlik seviyesinin yetersiz kalması.
• Site trafiğinin kampanya, reklam veya sezon dönemlerinde aniden artması.

Eğer siteniz büyüyor ve mevcut paket sınırlarına yaklaşıyorsa, son anda kriz anında taşıma yapmak yerine kontrollü bir migration planı oluşturmak çok daha güvenlidir. İhtiyacınıza göre web hosting paketleri, VPS sunucu çözümleri veya kurumsal hosting seçeneklerini karşılaştırarak doğru altyapıyı seçebilirsiniz.

Taşıma Öncesi Hazırlık: En Kritik Aşama

Veri kaybı yaşanan taşıma projelerinin büyük bölümü aktarım sırasında değil, hazırlık eksikliği yüzünden başarısız olur. Taşıma başlamadan önce mevcut sitenin envanteri çıkarılmalı, hangi verilerin taşınacağı ve hangi servislerin kesintiye hassas olduğu netleştirilmelidir.

1. Site Envanteri Çıkarın

İlk adım, web sitesinin teknik haritasını oluşturmaktır. Kullanılan CMS veya framework, PHP sürümü, veritabanı türü, disk boyutu, e-posta hesapları, cron görevleri, DNS kayıtları, SSL sertifikası, özel yönlendirmeler ve üçüncü taraf entegrasyonlar not edilmelidir. Örneğin bir WordPress sitesinde sadece wp-content klasörünü taşımak yeterli değildir; .htaccess kuralları, wp-config.php ayarları, veritabanı tablo ön ekleri, cache eklentileri ve medya dosyaları da kontrol edilmelidir.

Bir e-ticaret sitesinde ise ödeme altyapısı, kargo entegrasyonu, stok senkronizasyonu, ERP bağlantısı, SMTP servisi ve webhook URL adresleri ayrıca incelenmelidir. Taşıma sonrası sipariş gelmiyorsa sorun çoğu zaman dosya aktarımında değil, unutulan bir API IP kısıtlamasında veya eski sunucuya tanımlı güvenlik kuralında çıkar.

2. Tam Yedek Alın ve Doğrulayın

Sunucu taşıma işleminde yedek almak tek başına yeterli değildir; yedeğin geri yüklenebilir olduğu da doğrulanmalıdır. Tam yedek şu bileşenleri kapsamalıdır:

• Web sitesi dosyaları: public_html, uygulama klasörleri, upload dizinleri, tema ve eklenti dosyaları.
• Veritabanları: MySQL, MariaDB, PostgreSQL veya uygulamanın kullandığı diğer veritabanları.
• E-posta verileri: posta kutuları, yönlendirmeler, filtreler, autoresponder ayarları.
• DNS kayıtları: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC kayıtları.
• Konfigürasyonlar: .htaccess, nginx.conf, php.ini, cron job, environment dosyaları.
• SSL sertifikaları ve özel güvenlik kuralları.

Pratik bir yaklaşım olarak taşıma öncesi en az iki kopya yedek alın: biri mevcut sunucuda, diğeri farklı bir lokasyonda saklansın. Büyük sitelerde dosya yedeği için rsync, veritabanı için mysqldump veya panel yedekleme araçları kullanılabilir. 10 GB üzeri veritabanlarında tek parça dump yerine sıkıştırılmış ve bölünmüş yedekler daha güvenli olabilir.

3. DNS TTL Değerini Önceden Düşürün

DNS değişikliğinin hızlı yayılması için TTL değerini taşıma işleminden 24 saat önce düşürmek iyi bir uygulamadır. Örneğin TTL değeri 14400 saniye ise bazı kullanıcılar eski sunucuya saatlerce gitmeye devam edebilir. Taşımadan önce TTL değerini 300 saniyeye çekmek, DNS geçişini daha kontrollü hale getirir. Taşıma tamamlandıktan ve her şey doğrulandıktan sonra TTL yeniden 3600 veya 14400 saniyeye çıkarılabilir.

Alan adınızın DNS yönetimini düzenli yapmak, migration başarısını doğrudan etkiler. Alan adı ve DNS yapılandırması için domain sorgulama ve alan adı yönetimi rehberlerini inceleyebilirsiniz.

Sunucu Taşıma Yöntemleri Karşılaştırması

Her site için en doğru taşıma yöntemi aynı değildir. Küçük bir kurumsal site panel üzerinden kolayca taşınabilirken, yüksek trafikli bir e-ticaret sitesinde kademeli senkronizasyon ve bakım modu gerekebilir.

Yeni altyapıyı seçerken sadece disk alanına bakmak yanıltıcıdır. PHP worker sayısı, CPU çekirdeği, RAM, NVMe disk, yedekleme sıklığı, veri merkezi konumu, LiteSpeed veya Nginx desteği, WAF ve DDoS koruması gibi kriterler de performansı belirler. Bu nedenle ihtiyaç analizi yapmadan en ucuz pakete geçmek, kısa sürede yeniden taşıma ihtiyacı doğurabilir.

Adım Adım Sunucu Taşıma Nasıl Yapılır?

Adım 1: Yeni Sunucuyu Hazırlayın

Yeni sunucuda işletim sistemi, web sunucusu, PHP sürümü, veritabanı servisi ve gerekli modüller kurulmalıdır. WordPress için PHP 8.2 veya 8.3, güncel MariaDB, OPcache ve uygun memory_limit değeri önerilir. Laravel gibi frameworklerde Composer, cron, queue worker ve storage izinleri ayrıca ayarlanmalıdır. Eski sunucuda çalışan PHP eklentileri yeni sunucuda yoksa site taşındıktan sonra beyaz ekran veya 500 hatası görülebilir.

Güvenlik tarafında SSH port politikası, güçlü parolalar, firewall, malware taraması ve otomatik güncellemeler yapılandırılmalıdır. Taşıma öncesi yeni sunucu boşken güvenlik temelini kurmak, sonradan müdahale etmekten daha kolaydır. SSL ihtiyacınız varsa SSL sertifikası kurulumu konusunu taşıma planına mutlaka ekleyin.

Adım 2: Dosyaları Aktarın

Dosya aktarımı için site boyutuna göre FTP, SFTP, SSH, rsync veya panel yedekleme kullanılabilir. Küçük sitelerde sıkıştırılmış arşiv oluşturup yeni sunucuda açmak yeterlidir. Büyük sitelerde ise rsync ile ilk kopya alınıp DNS değişiminden hemen önce ikinci kez senkronizasyon yapılması önerilir. Bu yöntem, özellikle upload klasörü sürekli değişen sitelerde zaman kazandırır.

Dosya aktarımından sonra izinleri kontrol edin. Genel olarak klasörler 755, dosyalar 644 izinleriyle çalışır; ancak her uygulamanın ihtiyacı farklı olabilir. wp-config.php, .env veya benzeri hassas dosyalar herkes tarafından okunabilir olmamalıdır. Ayrıca gizli dosyaların, yani .htaccess ve .user.ini gibi dosyaların kopyalandığından emin olun.

Adım 3: Veritabanını Taşıyın

Veritabanı aktarımı, veri kaybını önlemenin en hassas bölümüdür. Önce eski sunucudan dump alınır, ardından yeni sunucuda veritabanı ve kullanıcı oluşturulur. Karakter seti mümkünse utf8mb4 olarak ayarlanmalıdır. Türkçe karakterlerin bozulmaması için export ve import sırasında aynı collation yapısı korunmalıdır.

WooCommerce veya üyelik sistemi gibi anlık veri üreten sitelerde taşıma sırasında bakım modu kullanılabilir. Aksi halde DNS yayılımı esnasında bazı kullanıcılar eski sunucuya, bazıları yeni sunucuya veri yazabilir. Bu da sipariş, yorum, form kaydı veya üyelik bilgilerinde tutarsızlık yaratır. Kritik sitelerde son veritabanı dump işlemi, bakım modu açıldıktan sonra alınmalıdır.

Adım 4: Konfigürasyon Dosyalarını Güncelleyin

Veritabanı adı, kullanıcı adı, parola, host bilgisi ve dosya yolları yeni sunucuya göre düzenlenmelidir. WordPress için wp-config.php, Laravel için .env, özel uygulamalar için config.php veya benzeri dosyalar kontrol edilir. Eski sunucuya ait mutlak dosya yolları, IP adresleri, SMTP ayarları veya cache dizinleri kalırsa site görünürde açılabilir ancak arka planda hata üretir.

Ayrıca PHP memory_limit, upload_max_filesize, post_max_size ve max_execution_time değerleri uygulamanızın ihtiyacına göre ayarlanmalıdır. Örneğin 200 MB ürün görseli yükleyen bir yönetim panelinde upload limiti 32 MB kalırsa taşıma başarılı olsa bile operasyon devam edemez.

Adım 5: DNS Değiştirmeden Önce Test Edin

En güvenli taşıma pratiği, DNS değiştirmeden önce yeni sunucuda siteyi test etmektir. Bunun için bilgisayarınızdaki hosts dosyasına alan adınızı yeni sunucu IP adresiyle eşleyebilirsiniz. Böylece ziyaretçiler hala eski sunucuyu görürken siz gerçek alan adıyla yeni sunucuyu test edersiniz.

Test listesi şu kontrolleri içermelidir:

• Ana sayfa, kategori, ürün, blog ve iletişim sayfaları açılıyor mu?
• Form gönderimi, üye girişi, şifre sıfırlama ve ödeme akışı çalışıyor mu?
• Görseller, CSS ve JavaScript dosyaları eksiksiz yükleniyor mu?
• Yönetim paneli hata vermeden açılıyor mu?
• SSL sertifikası doğru alan adı için kurulmuş mu?
• 404, 500, mixed content veya yönlendirme döngüsü hatası var mı?
• robots.txt, sitemap.xml ve canonical etiketleri doğru mu?

Adım 6: SSL Sertifikasını Kurun

Modern web sitelerinde SSL sadece güvenlik değil, SEO ve kullanıcı güveni açısından da zorunludur. Yeni sunucuda SSL kurulmadan DNS değişirse kullanıcılar güvenli değil uyarısı görebilir. Bu nedenle DNS geçişinden hemen önce veya geçişle eş zamanlı olarak SSL sertifikası hazırlanmalıdır. Let’s Encrypt gibi ücretsiz sertifikalar birçok site için yeterli olabilir; ödeme alan kurumsal projelerde ise doğrulama seviyesi daha yüksek SSL seçenekleri tercih edilebilir.

SSL sonrası HTTP adreslerinin HTTPS’e 301 ile yönlendiğinden, mixed content hatası olmadığından ve site haritasında HTTPS URL’lerinin yer aldığından emin olun. SSL ürünleri ve kurulum seçenekleri için SSL sertifikaları sayfasına göz atabilirsiniz.

Adım 7: DNS Kayıtlarını Değiştirin

Testler başarıyla tamamlandıktan sonra DNS tarafında A kaydı yeni sunucu IP adresine yönlendirilir. Eğer e-posta hizmeti aynı sunucuda taşınıyorsa MX, SPF, DKIM ve DMARC kayıtları da güncellenmelidir. E-posta farklı bir sağlayıcıda kalacaksa MX kayıtlarına dokunmamak gerekir. En sık yapılan hatalardan biri, sadece web sitesini taşımak isterken e-posta kayıtlarını yanlışlıkla değiştirmek ve mail trafiğini kesmektir.

DNS yayılımı genellikle birkaç dakika ile 24 saat arasında tamamlanır. TTL önceden düşürüldüyse çoğu kullanıcı kısa sürede yeni sunucuya ulaşır. Bu süreçte eski sunucuyu hemen kapatmayın. En az 48 saat, mümkünse 72 saat erişilebilir halde tutmak güvenli bir uygulamadır.

Adım 8: Son Senkronizasyonu ve Log Kontrolünü Yapın

DNS değişikliğinden sonra eski sunucuya yazılmış yeni veri olup olmadığı kontrol edilmelidir. Özellikle siparişler, iletişim formları, kullanıcı kayıtları ve yorumlar karşılaştırılmalıdır. Web sunucusu access log ve error log dosyaları, hangi IP’lerin hangi sunucuya istek gönderdiğini anlamaya yardımcı olur.

Taşıma sonrası ilk 24 saat içinde 500 hataları, 404 artışı, yavaş sorgular, CPU sıçramaları ve e-posta kuyrukları takip edilmelidir. Bu kontroller yapılmazsa site çalışıyor gibi görünür ancak arka planda dönüşüm kaybı yaşanabilir.

Veri Kaybı Olmadan Site Taşımak İçin Profesyonel Kontrol Listesi

Aşağıdaki kontrol listesi, pratikte en çok sorun çıkaran noktaları kapsar. Taşıma öncesi ve sonrası bu listeyi işaretlemek, migration riskini ciddi ölçüde azaltır.

• Taşıma zamanı düşük trafik saatlerine planlandı.
• Tam dosya, veritabanı, e-posta ve DNS yedeği alındı.
• Yedeğin açılabilir ve geri yüklenebilir olduğu test edildi.
• DNS TTL değeri en az 24 saat önce düşürüldü.
• Yeni sunucuda PHP, veritabanı ve gerekli modüller hazırlandı.
• Dosyalar eksiksiz aktarıldı ve izinler kontrol edildi.
• Veritabanı karakter seti ve collation uyumu doğrulandı.
• Config dosyaları yeni sunucu bilgilerine göre güncellendi.
• Hosts dosyası ile canlıya almadan test yapıldı.
• SSL kuruldu, HTTPS yönlendirmeleri kontrol edildi.
• DNS A, AAAA, MX, TXT kayıtları doğru şekilde güncellendi.
• Eski sunucu en az 48 saat aktif tutuldu.
• Google Search Console, Analytics ve log kayıtları izlendi.

SEO Kaybı Yaşamamak İçin Migration Sonrası Kontroller

Sunucu taşıma, URL yapısı değişmediği sürece teorik olarak SEO kaybı yaratmamalıdır. Ancak pratikte yavaşlık, 404 hataları, yanlış robots.txt, eksik SSL veya yönlendirme hataları sıralamaları etkileyebilir. Bu nedenle taşıma sonrası SEO kontrolü teknik migration kadar önemlidir.

URL ve Yönlendirme Kontrolü

Site taşırken URL yapısını değiştirmiyorsanız 301 yönlendirme ihtiyacı minimumdur. Ancak aynı anda alan adı, permalink yapısı veya klasör yapısı değişiyorsa eski URL’ler yeni karşılıklarına 301 ile yönlendirilmelidir. 302 geçici yönlendirme, SEO sinyallerinin kalıcı aktarımı için uygun değildir. Örneğin eski /urun/abc sayfası yeni /magaza/abc adresine taşındıysa birebir yönlendirme yapılmalıdır; tüm eski URL’leri ana sayfaya yönlendirmek kullanıcı deneyimini ve SEO performansını olumsuz etkiler.

Robots.txt ve Sitemap Kontrolü

Test sırasında arama motorlarını engellemek için robots.txt içinde Disallow kullanıldıysa canlıya alınca kaldırılmalıdır. Bu hata, taşıma sonrası indeks kaybının en klasik nedenlerinden biridir. Sitemap dosyasında yeni HTTPS URL’leri yer almalı, Google Search Console üzerinden yeniden gönderilmelidir.

Performans ve Core Web Vitals

Yeni sunucu daha güçlü olsa bile yanlış cache ayarı performansı düşürebilir. LiteSpeed Cache, Redis, OPcache, CDN ve görsel optimizasyonu doğru yapılandırılmalıdır. Taşıma sonrası ilk hafta PageSpeed Insights, Chrome UX Report ve sunucu logları izlenerek LCP, INP ve CLS metriklerinde bozulma olup olmadığı kontrol edilmelidir. Hosting performansını iyileştirmek için WordPress hız optimizasyonu içeriklerinden yararlanabilirsiniz.

E-Posta Taşıma Sırasında Dikkat Edilecekler

Birçok site taşımasında web dosyaları sorunsuz aktarılırken e-posta tarafı gözden kaçırılır. Eğer e-postalar mevcut sunucuda tutuluyorsa posta kutuları, kullanıcı parolaları, yönlendirmeler ve filtreler taşınmalıdır. IMAP senkronizasyonu, eski kutudaki mailleri yeni kutuya aktarmak için güvenilir bir yöntemdir.

DNS tarafında MX kaydı mail sunucusunu, SPF gönderim yetkisini, DKIM imzalamayı, DMARC ise alan adı politikasını belirler. Bu kayıtlar yanlış yapılandırılırsa e-postalar spam klasörüne düşebilir veya tamamen reddedilebilir. Taşıma sonrası Gmail, Outlook ve kurumsal mail hesaplarına test gönderimi yapılmalı; mail header bilgileri kontrol edilmelidir.

Sık Yapılan Sunucu Taşıma Hataları

Başarılı migration projelerinde ortak nokta, basit hataların önceden önlenmesidir. Aşağıdaki hatalar en sık karşılaşılan problemlerdir:

• Yedek almadan veya yedeği test etmeden taşıma yapmak.
• DNS TTL değerini düşürmeden IP değiştirmek.
• Eski sunucuyu DNS yayılımı bitmeden kapatmak.
• Veritabanı karakter setini yanlış aktarmak ve Türkçe karakterleri bozmak.
• .htaccess veya nginx yönlendirme kurallarını unutmak.
• SSL kurmadan HTTPS trafiğini yeni sunucuya yönlendirmek.
• E-posta MX ve TXT kayıtlarını yanlış güncellemek.
• Cache eklentisini eski sunucu yoluyla bırakmak.
• Taşıma sonrası Search Console ve log takibi yapmamak.

Özellikle canlı satış yapan sitelerde taşıma işlemi hafta içi mesai yoğunluğunda değil, trafik ve sipariş hacminin en düşük olduğu zaman aralığında yapılmalıdır. Büyük e-ticaret projelerinde 15-30 dakikalık bakım penceresi planlamak, arka planda oluşabilecek veri tutarsızlıklarını önler.

Ne Zaman Profesyonel Migration Desteği Almalısınız?

Basit bir tanıtım sitesini manuel olarak taşımak mümkün olabilir; ancak bazı durumlarda profesyonel destek almak daha düşük maliyetli ve daha güvenlidir. Aylık yüksek ciro üreten e-ticaret siteleri, çok sayıda e-posta hesabı olan şirketler, özel yazılım kullanan portallar, yüksek trafikli medya siteleri ve regülasyona tabi veri barındıran işletmeler bu gruba girer.

Profesyonel taşıma desteğinde süreç genellikle ön analiz, yedekleme, test ortamı kurulumu, aktarım, DNS geçişi, doğrulama ve izleme adımlarından oluşur. Böylece sadece dosyalar değil, iş sürekliliği de taşınmış olur. Hostragons altyapısına geçmeyi planlıyorsanız ihtiyaçlarınıza uygun hosting, domain ve SSL seçeneklerini birlikte değerlendirmek için Hostragons hosting çözümleri sayfasını inceleyebilirsiniz.

Sonuç: Planlı Sunucu Taşıma Kesintiyi ve Veri Kaybını Önler

Sunucu taşıma, doğru planlandığında korkulacak bir işlem değildir. Başarının anahtarı; tam yedek, doğru sunucu hazırlığı, DNS TTL planı, test ortamı, SSL kurulumu, e-posta kontrolleri ve taşıma sonrası izleme adımlarını atlamamaktır. Özellikle veritabanı sürekli değişen sitelerde son senkronizasyon ve bakım modu kritik rol oynar.

Kısacası veri kaybı olmadan site taşımak için acele etmeyin, her adımı doğrulayın ve eski sunucuyu hemen kapatmayın. Altyapınızı yenilemek, daha hızlı ve güvenli bir web deneyimi sunmak istiyorsanız Hostragons üzerindeki hosting, domain ve SSL çözümlerini inceleyebilir; ihtiyaçlarınıza uygun geçiş planını sakin ve kontrollü şekilde oluşturabilirsiniz.

Sıkça Sorulan Sorular

Sunucu taşıma ne kadar sürer?

Süre site boyutuna ve karmaşıklığa göre değişir. Küçük bir WordPress sitesi 30-60 dakikada taşınabilirken, büyük e-ticaret veya çok e-postalı kurumsal projelerde hazırlık, test ve DNS yayılımı dahil süreç 1-3 gün sürebilir.

Sunucu taşıma sırasında sitem kapanır mı?

Doğru planlama yapılırsa kesinti birkaç dakikaya indirilebilir veya kullanıcılar kesinti hissetmeyebilir. Bunun için DNS TTL önceden düşürülmeli, yeni sunucu canlıya alınmadan test edilmeli ve eski sunucu DNS yayılımı tamamlanana kadar açık tutulmalıdır.

Veri kaybı olmaması için en önemli adım nedir?

En önemli adım doğrulanmış tam yedektir. Dosyalar, veritabanı, e-posta ve DNS kayıtları yedeklenmeli; özellikle sipariş veya üyelik verisi üreten sitelerde son veritabanı yedeği bakım modu açıldıktan sonra alınmalıdır.

Sunucu taşıma SEO sıralamalarını etkiler mi?

URL yapısı korunur, site hızlı çalışır, SSL ve yönlendirmeler doğru yapılırsa sunucu taşıma tek başına SEO kaybına neden olmaz. Ancak 404 hataları, yanlış robots.txt, yavaş sunucu veya hatalı 301 yönlendirmeleri sıralamaları olumsuz etkileyebilir.

E-posta hesapları da sunucu taşıma ile taşınır mı?

Eğer e-postalar eski hosting üzerinde barınıyorsa ayrıca taşınmalıdır. Posta kutuları, yönlendirmeler, filtreler ve MX, SPF, DKIM, DMARC kayıtları kontrol edilmelidir. E-posta farklı bir sağlayıcıda kalacaksa MX kayıtları değiştirilmemelidir.