Yurt İçi mi Yurt Dışı Hosting mi? SEO ve Hız Etkisi

Yurt içi mi yurt dışı hosting mi sorusu, hosting alacak hemen herkesin takıldığı ilk ikilemdir ve internette bu soruya verilen iki cevap da yanlıştır. Bir tarafta "sunucu konumu Google'ın sıralama faktörüdür, Türkiye'de barındırmazsanız üst sıralara çıkamazsınız" diyen satış odaklı yazılar, diğer tarafta "Google artık lokasyona bakmıyor, hiç fark etmez" diyen aynı derecede kestirme yazılar var. Gerçek ikisinin arasında ve ölçülebilir: lokasyon doğrudan bir sıralama sinyali değildir, ama lokasyonun ürettiği gecikme dolaylı olarak ölçülen bir sinyaldir ve bu gecikme milisaniye cinsinden hesaplanabilir.

Bu yazıda tartışmayı iddia düzeyinden çıkarıp ölçüm düzeyine taşıyacağız. Kendi sitenizin TTFB'sini terminalden nasıl ölçeceğinizi, ping ile TTFB'nin neden aynı şey olmadığını, ccTLD (.com.tr) ile sunucu konumunun Google için neden iki ayrı sinyal olduğunu, CDN'in bu farkın ne kadarını kapattığını ve çoğu Türkçe kaynağın hiç değinmediği KVKK / veri yeri boyutunu tek tek ele alacağız. Sonunda somut bir karar tablosu ile hangi site tipinin nerede barınması gerektiğini netleştireceğiz. Yıllardır gördüğüm en pahalı hata, bu kararın hız gerekçesiyle verilip destek ve fatura gerçekliğinin sonradan fark edilmesidir.

Sunucu Lokasyonu Google Sıralamasında Doğrudan Faktör mü#

Hayır, sunucu lokasyonu doğrudan bir sıralama faktörü değildir; ama sunucunun ürettiği yanıt süresi ölçülen bir sinyaldir. Bu ayrımı kaçırdığınız anda tartışmanın tamamı çığırından çıkıyor.

Google'ın coğrafi hedefleme mantığında bir sayfanın hangi ülkeye ait sayılacağı sırasıyla şu sinyallerden çıkarılır: ülke kodlu alan adı (.com.tr, .tr), Search Console'daki uluslararası hedefleme ayarı (yalnızca genel alan adları için geçerlidir), sayfadaki dil ve içerik, iletişim sayfasındaki adres ve telefon bilgisi, siteye link veren yerel kaynaklar ve en sonda sunucunun IP adresinin coğrafi kaydı. Sunucu IP'si bu listenin en zayıf halkasıdır çünkü bulut sağlayıcıları ve CDN'ler yüzünden IP-coğrafya eşleşmesi zaten güvenilirliğini büyük ölçüde yitirmiştir.

Buna karşılık hız tarafı doğrudan ölçülüyor. Google, gerçek Chrome kullanıcılarından toplanan alan verisiyle sayfa deneyimini değerlendiriyor ve bu verinin içinde LCP (Largest Contentful Paint) var. LCP'nin ilk bileşeni ise sunucunun ilk baytı gönderme süresi, yani TTFB. Sunucunuz Türkiye'deki kullanıcıya 40 ms yerine 260 ms'de cevap veriyorsa, bu 220 ms doğrudan LCP'ye eklenir ve LCP eşiğe yakınsa sizi eşiğin yanlış tarafına atar. Yani lokasyon "sıralama faktörü" değildir ama sıralama faktörünün girdisidir.

Özetle: .com.tr uzantınız varsa Google zaten sitenizi Türkiye'ye ait sayar, sunucu Almanya'da diye bu değişmez. Ama sunucu Kaliforniya'daysa TTFB'niz 180-250 ms artar ve bunu kimse görmezden gelemez.

TTFB Farkını Milisaniye Cinsinden Nasıl Ölçersiniz#

TTFB'yi ölçmenin en dürüst yolu tarayıcı eklentisi değil, curl'ün zamanlama değişkenleridir. Şu komutu kendi sitenize karşı çalıştırın:

curl -o /dev/null -s -w "dns:      %{time_namelookup}s\nconnect:  %{time_connect}s\ntls:      %{time_appconnect}s\nttfb:     %{time_starttransfer}s\ntoplam:   %{time_total}s\n" https://ornek-site.com/

Tipik bir çıktı şöyle görünür:

dns:      0.021s
connect:  0.058s
tls:      0.129s
ttfb:     0.212s
toplam:   0.246s

Bu satırları okumayı bilmek işin tamamıdır:

• time_namelookup DNS çözümlemesidir, sunucu konumuyla ilgisi yoktur; DNS sağlayıcınızın anycast ağıyla ilgilidir.
• time_connect TCP el sıkışmasıdır ve doğrudan mesafeyle orantılıdır. Tek yönlü gecikmenin iki katıdır.
• time_appconnect TLS el sıkışmasının bittiği andır. TLS 1.3'te bir tur daha ekler, yani mesafenin bedeli burada ikinci kez ödenir.
• time_starttransfer TTFB'dir: bağlantı + TLS + sunucunun sayfayı üretme süresi.

Kritik nokta şu: sunucunun uygulama tarafında harcadığı süreyi görmek için time_starttransfer eksi time_appconnect yapmalısınız. Yukarıdaki örnekte bu 0.083 s, yani PHP+veritabanı 83 ms sürmüş; kalan 129 ms ağ mesafesidir. Lokasyon tartışmasında konuşulan tam olarak bu 129 ms'dir.

Aynı ölçümü aynı anda hem yurt içi hem yurt dışı bir sunucudan yapıp karşılaştırmak istiyorsanız, ikisine de aynı statik dosyayı koyup şu döngüyü çalıştırın:

for host in tr-sunucu.example.com de-sunucu.example.com; do
  echo -n "$host -> "
  curl -o /dev/null -s -w "%{time_connect} / %{time_starttransfer}\n" "https://$host/olcum.txt"
done

Statik dosya kullanmanın nedeni uygulama süresini denklemden çıkarmaktır; böylece kalan fark saf ağ mesafesidir. Ölçümü günün farklı saatlerinde en az 10 kez tekrarlayın, tek ölçüm istatistik değildir. TTFB'nin sunucu tarafı bileşenini düşürmenin yollarını ttfb nedir nasıl düşürülür yazısında ayrıntılı ele alıyoruz.

Gerçekçi mesafe-gecikme aralıkları#

Aşağıdaki değerler Türkiye'deki bir ev bağlantısından ölçülen tipik gidiş-dönüş sürelerinin (RTT) yaklaşık aralıklarıdır. Kesin sayı değil, büyüklük mertebesi olarak okuyun:

Tablodaki "TLS dahil" sütunu neden RTT'nin yaklaşık üç katı? Çünkü TCP el sıkışması bir tur, TLS el sıkışması bir-iki tur, ilk baytın gelmesi bir tur daha ister. Mesafenin bedelini tek seferde değil, her turda yeniden ödersiniz. HTTP/2 ve bağlantı yeniden kullanımı sonraki istekleri kurtarır ama ilk isteği, yani tam da LCP'yi belirleyen isteği kurtarmaz.

Ping, TTFB ve Core Web Vitals Arasındaki Fark#

Ping ile TTFB'yi karıştırmak bu konudaki en yaygın ölçüm hatasıdır. ping ICMP paketiyle sadece ağ gidiş-dönüş süresini ölçer; sunucunun web sunucusu çalışıyor mu, PHP ne kadar sürüyor, veritabanı yavaş mı, hiçbirini bilmez. Bir sunucuya ping 20 ms olabilirken TTFB 3 saniye olabilir; tam tersi de mümkündür.

ping -c 10 ornek-site.com
mtr --report --report-cycles 20 ornek-site.com

mtr çıktısı bir adım öteye gider: paketin hangi ara noktada gecikme veya kayıp yaşadığını gösterir. Türkiye'den Avrupa'ya çıkan trafiğin bazı operatörlerde nasıl dolambaçlı yollar izlediğini burada net görürsünüz — aynı Frankfurt sunucusuna bir operatörden 45 ms, diğerinden 90 ms olabilir. Ağ tanılamayı derinlemesine anlatan ping traceroute mtr ile ağ tanılama yazısı bu çıktıları okumayı adım adım gösterir.

Core Web Vitals tarafında ise şu zincir işler:

1. Kullanıcı adresi yazar → DNS çözümlenir.
2. TCP + TLS kurulur → mesafe burada ödenir.
3. Sunucu HTML'in ilk baytını gönderir → TTFB tamamlanır.
4. Tarayıcı HTML'i ayrıştırır, CSS ve fontu indirir.
5. En büyük görsel/metin bloğu boyanır → LCP tamamlanır.

TTFB, LCP'nin içindedir. LCP eşiği 2,5 saniyedir. Türkiye'den ölçülen TTFB'niz 250 ms yerine 600 ms ise, LCP bütçenizin dörtte birini daha sayfa çizilmeye başlamadan harcamışsınız demektir. Mobil kullanıcıda bu bütçe zaten dar olduğu için lokasyon farkı en çok mobilde canınızı yakar.

Buradaki incelik şudur: eğer TTFB'niz zaten 1,2 saniyeyse sorununuz lokasyon değil, uygulamanızdır. 130 ms'lik ağ farkını tartışmadan önce eklenti şişkinliğini, önbelleksiz WordPress kurulumunu, indekssiz sorguları çözün. Site neden yavaş açılıyor yazısındaki teşhis sırası tam olarak bu önceliği kurar.

ccTLD ile Sunucu Konumu Ayrı Sinyallerdir#

Sunucu konumu ile alan adı uzantısı Google için iki bağımsız sinyaldir ve birbirinin yerine geçmez. Bu, Türkçe kaynaklarda en sık karıştırılan konudur.

Dört kombinasyonu ayrı ayrı düşünelim:

Yani .com.tr uzantınız varsa sunucunuz nerede olursa olsun Google sitenizi Türkiye'ye ait kabul eder. Bu, "yurt dışı sunucu ülke hedeflemesini bozar" iddiasını doğrudan çürütür. Buna karşılık genel bir .com kullanıyor ve yalnızca Türkiye'ye satış yapıyorsanız, coğrafi hedeflemeyi sunucu IP'sine bırakmak yerine Search Console'dan açıkça belirtmek ve iletişim/adres bilgisi, Türkçe içerik, hreflang gibi güçlü sinyalleri kullanmak gerekir.

Uzantı seçimi başlı başına bir karardır; .com ile .com.tr arasındaki farkı com mu com.tr mi yazısında ayrıntılı karşılaştırıyoruz.

CDN Lokasyon Farkını Ne Kadar Kapatır#

CDN, statik dosyalardaki mesafeyi neredeyse tamamen kapatır; dinamik HTML'deki mesafeyi ise kısmen kapatır. Bu ayrım kararınızı doğrudan etkiler.

Bir CDN önüne aldığınızda görsel, CSS, JS gibi dosyalar kullanıcının şehrine en yakın kenar sunucudan servis edilir; bu dosyalar için sunucunuzun Virginia'da olması hiçbir şey ifade etmez. Ama kullanıcı giriş yaptığında, sepete ürün eklediğinde, form gönderdiğinde üretilen HTML önbelleklenemez ve isteği kaynak sunucuya kadar gitmek zorundadır. Yani:

• Statik ağırlıklı kurumsal tanıtım sitesi: CDN farkı büyük ölçüde kapatır.
• Blog ve haber sitesi: tam sayfa önbellek kullanılabiliyorsa fark büyük ölçüde kapanır.
• Üyelikli e-ticaret, panel, rezervasyon sistemi: her isteğin kaynak sunucuya gitmesi gerektiği için fark kapanmaz.

Modern CDN'lerin bir avantajı daha vardır: kullanıcıyla CDN arasındaki TLS el sıkışması yakın kenar sunucuda yapılır, CDN ile kaynak sunucu arasında ise bağlantı zaten açık tutulur. Bu, mesafenin turlarını çoğaltan tekrarları azaltır. Yine de "CDN kullanıyorum, sunucu nerede olsa olur" cümlesi yalnızca statik ve tam-sayfa-önbelleklenebilir siteler için doğrudur. CDN kurulumu ve önbellek davranışı için cloudflare dns ve cdn yazısına bakabilirsiniz.

KVKK ve Veri Yeri: Teknik Değil Hukuki Bir Karar#

Sunucu lokasyonu kararının en sık atlanan boyutu hız değil, kişisel verinin nerede işlendiğidir. Türkçe kaynakların neredeyse tamamı bu başlığı hiç açmadan konuyu kapatıyor.

KVKK açısından önemli olan sunucunun bulunduğu ülkedir çünkü kişisel verinin yurt dışındaki bir sunucuda tutulması "yurt dışına aktarım" sayılır ve kendi kural setine tabidir. Sitenizde üyelik varsa, sipariş alıyorsanız, iletişim formundan ad-soyad-telefon topluyorsanız, hatta ziyaretçi IP'lerini log tutuyorsanız kişisel veri işliyorsunuz demektir.

Pratikte şunlara dikkat edin:

• Aydınlatma metninde veri yerini belirtin. Verinin yurt dışında barındığını yazmadan yurt dışında barındırmak, metniniz ile gerçeğinizin uyuşmaması demektir.
• Aktarımın hukuki dayanağını netleştirin. Yurt dışına aktarım için açık rıza veya mevzuatın öngördüğü diğer mekanizmalar gerekir; bunu bir avukatla kurgulamak gerekir, bu yazı hukuki görüş değildir.
• Veri işleyenlerinizi listeleyin. Hosting sağlayıcınız bir veri işleyendir. Yedeklerin nerede tutulduğu da bu listeye girer; sunucu Türkiye'de ama yedekler başka kıtada olabilir.
• Kamu ihalesi ve regüle sektörler. Belirli kurumlarla çalışıyorsanız sözleşmeleriniz verinin Türkiye'de kalmasını şart koşabilir; bu durumda teknik tartışma zaten biter.

Bu konudaki uçtan uca kontrol listesini kvkk web sitesi uyumu yazısında bulabilirsiniz. Özetle: hız farkı 100 ms, uyum riski ise para cezasıdır; iki maddeyi aynı kefeye koymayın.

Destek, Ödeme ve Operasyon Farkı#

Teknik tabloların göstermediği ama gerçek hayatta en çok canınızı yakan farklar operasyoneldir. Yıllardır gördüğüm tablo şu:

• Destek saat dilimi ve dil. Sitesi gece 02:00'de düşen bir e-ticaretin, İngilizce ticket açıp 9 saat sonra "could you please provide more details" cevabı alması gerçek bir maliyettir. Yurt içi sağlayıcıda aynı sorun telefonla 15 dakikada konuşulabilir.
• Fatura ve muhasebe. Yurt dışı sağlayıcının kesip gönderdiği fatura Türkiye'de gider yazılırken ek yükümlülük doğurabilir; kurumsal muhasebe bunu her ay yaşamak istemez.
• Ödeme yöntemi. Yurt dışı sağlayıcıların çoğu yalnızca kartla çalışır; kartın limiti dolduğu için otomatik yenilenmeyen bir hosting yüzünden sitenin kapandığını çok gördüm. Havale/EFT ile ödeyebilmek küçük ama gerçek bir avantajdır.
• Yasal tebligat ve içerik kaldırma. Türkiye'deki bir mahkeme kararı yurt içi sağlayıcı üzerinden hızlı işler; yurt dışında süreç uzar ve bazen alan adı seviyesinde sonuçlanır.
• Ağ tarafı. Yurt içi sunucu, Türkiye'deki operatörlere doğrudan bağlanır; yurt dışı çıkışlarda operatöre göre değişen dolambaçlı rotalar (bkz. yukarıdaki mtr çıktısı) hız farkını tablo değerlerinin üstüne çıkarabilir.

Buna karşılık yurt dışı tarafın gerçek avantajları da vardır: ağır DDoS koruma kapasitesi, çok geniş IP havuzu, belirli özel donanımların (yüksek çekirdek sayılı GPU makineler gibi) daha kolay bulunması ve global kitleye hitap eden projelerde coğrafi tarafsızlık.

Hangi Durumda Yurt İçi, Hangi Durumda Yurt Dışı#

Karar tablosu şu şekildedir:

Kararsız kaldığınız durumda pratik kural şudur: kullanıcılarınızın çoğunluğu nerede yaşıyorsa sunucu oraya yakın olsun. Bu cümle, bütün teorik tartışmanın pratikteki tek özetidir. E-ticaret özelinde paket ve altyapı seçimini e-ticaret için hosting seçimi yazısında ayrıntılandırıyoruz.

Taşımaya Karar Verdiyseniz İzlenecek Sıra#

Lokasyon değiştirmek, dosyaları kopyalayıp DNS çevirmekten ibaret değildir. Sıra şudur:

1. Önce ölçün. Taşımadan önce mevcut TTFB'yi yukarıdaki curl komutuyla en az bir hafta boyunca günde birkaç kez kaydedin. Taşıdıktan sonra karşılaştıracak veriniz olmazsa "daha hızlı oldu" hissi ölçüm sayılmaz.
2. TTL'i düşürün. Taşımadan 24-48 saat önce ilgili A kaydının TTL değerini 300 saniyeye indirin ki geçiş anında propagasyon sizi bekletmesin.
3. Yeni sunucuda siteyi hosts dosyasıyla test edin. DNS'i çevirmeden önce kendi makinenizde hosts kaydı ekleyerek siteyi yeni IP üzerinden açın; PHP sürümü, veritabanı bağlantısı, yazma izinleri burada patlar.
4. E-postayı ayrı düşünün. MX kayıtları web sunucusuyla birlikte hareket etmek zorunda değildir; posta kutularını taşımadan A kaydını çevirirseniz gelen postalar eski sunucuda birikir.
5. SSL'i önceden hazırlayın. Yeni sunucuda sertifika, DNS çevrilmeden önce doğrulanabiliyorsa doğrulayın; aksi halde geçiş anında tarayıcı uyarısı alırsınız.
6. Eski sunucuyu hemen kapatmayın. En az 7-10 gün açık bırakın; geç propagasyon yapan çözümleyiciler ve bazı kurumsal ağlar hâlâ eski IP'ye gelir.

Bu adımların dosya ve veritabanı tarafını web sitesi taşıma yazısında komut düzeyinde anlatıyoruz.

Sıkça Sorulan Sorular#

Sunucum yurt dışındaysa Google'da Türkiye'de üst sıralara çıkamaz mıyım#

Çıkabilirsiniz. Sunucu konumu Google için en zayıf coğrafi sinyaldir ve .com.tr gibi bir ülke kodlu alan adınız varsa tamamen gölgede kalır. Sıralamanızı belirleyen şey içeriğinizin sorguya uygunluğu, sitenizin otoritesi ve sayfa deneyimidir. Yurt dışı sunucunun tek gerçek riski, ürettiği ek gecikmenin LCP'nizi eşiğin yanlış tarafına itmesidir; bu da ölçülüp yönetilebilir bir risktir.

TTFB kaç milisaniye olmalı#

Sunucu tarafında 200 milisaniyenin altı iyi, 500 milisaniyenin üstü ise düzeltilmesi gereken bir seviyedir. Ancak bu sayıyı tek başına değil, bileşenlerine ayırarak okumalısınız: curl çıktısındaki time_appconnect değerini time_starttransfer değerinden çıkarınca kalan süre sizin uygulamanızın süresidir. Ağ mesafesi 120 ms iken uygulama 400 ms harcıyorsa lokasyonu tartışmanın anlamı yoktur, önce uygulamayı hızlandırmalısınız.

Yurt dışı hosting dezavantajı sadece hız mı#

Hayır, çoğu zaman hız en küçük dezavantajdır. Destek dili ve saat dilimi, ödeme yöntemi kısıtları, faturanın Türkiye muhasebesinde yarattığı ek yük, yasal tebligat süreçlerinin uzaması ve kişisel verinin yurt dışına aktarımının doğurduğu yükümlülükler pratikte daha çok can yakar. Bir gecelik kesintide İngilizce ticket ile ilerlemek zorunda kalmak, 120 milisaniyelik gecikmeden kat kat pahalıya mal olabilir.

CDN kullanırsam sunucu konumu tamamen önemsiz hale gelir mi#

Hayır, yalnızca statik dosyalar ve tam sayfa önbelleklenebilen içerik için önemsizleşir. Kullanıcıya özel üretilen her HTML — sepet, üyelik paneli, arama sonucu, form gönderimi — kaynak sunucuya kadar gitmek zorundadır ve o istekte mesafenin bedeli tam olarak ödenir. Üyelikli e-ticaret gibi dinamik ağırlıklı projelerde CDN faydalıdır ama lokasyon kararını ortadan kaldırmaz.

Türkiye lokasyonlu hosting her zaman daha mı hızlıdır#

Hayır. Konum yalnızca ağ mesafesini belirler; sunucunun diski, üzerindeki hesap yoğunluğu, PHP sürümü, önbellek yapılandırması ve veritabanı performansı toplam süreyi çok daha fazla etkiler. Aşırı yüklenmiş bir yurt içi paylaşımlı sunucu, iyi yapılandırılmış bir Frankfurt sunucusundan rahatlıkla yavaş olabilir. Konumu ancak diğer değişkenler eşitken karşılaştırmak anlamlıdır.

Sunucumun gerçekte nerede olduğunu nasıl doğrularım#

En pratik yöntem gecikme ölçümüdür çünkü IP coğrafya veritabanları yanılabilir ama fizik yanılmaz. Türkiye'den ping ile ölçtüğünüz gidiş-dönüş süresi 25 milisaniyenin altındaysa sunucu büyük olasılıkla Türkiye'dedir; 40-70 milisaniye aralığı Orta Avrupa'ya, 110 milisaniyenin üstü Kuzey Amerika'ya işaret eder. mtr çıktısındaki son atlamaların ters DNS adları da genellikle şehir kodu içerir ve konumu doğrular.

Alan adı uzantım com ise sunucuyu Türkiye'ye almak SEO'ya yardım eder mi#

Çok sınırlı biçimde yardım eder ve tek başına yeterli değildir. Genel bir .com alan adında coğrafi hedeflemeyi Search Console'daki uluslararası hedefleme ayarı, sayfa dili, iletişim bilgisi ve yerel bağlantılar belirler; sunucu IP'si bu sinyallerin en zayıfıdır. Sunucuyu Türkiye'ye almanın asıl kazancı hedefleme değil, TTFB'nin düşmesidir.

Yedeklerimin de Türkiye'de olması gerekir mi#

Kişisel veri işliyorsanız evet, yedekler de aynı değerlendirmeye tabidir. Yedek, üretim veritabanının birebir kopyasıdır; sunucunuz Türkiye'de olsa bile yedekler başka bir kıtadaki nesne depolamaya gidiyorsa kişisel veri yurt dışına aktarılıyor demektir. Sağlayıcınıza yedeklerin fiziksel olarak nerede tutulduğunu açıkça sorun ve aldığınız cevabı aydınlatma metninizle tutarlı hale getirin.

Kapanış#

Yurt içi mi yurt dışı hosting mi sorusunun cevabı ideolojik değil, ölçümseldir. Sunucu konumu Google'ın doğrudan sıralama faktörü değildir; ccTLD ve içerik sinyalleri coğrafi hedeflemede çok daha baskındır. Ama konumun ürettiği 100-400 milisaniyelik gecikme TTFB üzerinden LCP'ye eklenir ve bu ölçülen bir sinyaldir. Kararı verirken önce kendi TTFB'nizi curl ile bileşenlerine ayırın: ağ mesafesi mi baskın, uygulamanız mı? Çoğu sitede sorun uygulamadadır ve lokasyon tartışması gereksiz yere yapılır. Ağ mesafesi gerçekten baskınsa ve kullanıcılarınızın çoğu Türkiye'deyse, cevap nettir. Buna hız dışındaki üç kalemi de ekleyin: destek dili ve saati, ödeme/fatura pratikliği, kişisel verinin yurt dışına aktarım yükümlülüğü. Bu üç kalem çoğu Türk projesinde milisaniyelerden daha belirleyicidir.

Sitenizin bugünkü konumundan memnun değilseniz ve taşınmayı düşünüyorsanız, paylaşımlı tarafta hosting paketleri, kendi kaynaklarınızı ayırmak istediğinizde VDS sunucu seçenekleri ve global kitleye hitap eden projeler için yurt dışı lokasyonlu sunucular ihtiyacınıza göre farklı cevaplar verir. Taşıma işini kendiniz yapmak istemiyorsanız site taşıma hizmeti dosya, veritabanı, e-posta ve DNS geçişini kesintisiz yürütecek şekilde bu işi üstlenir; siz yalnızca yukarıdaki ölçümleri taşımadan önce ve sonra alıp farkı kendi verinizle görürsünüz.