Türk bir şirket, Almanya veya İngiltere pazarına açılırken aslında tanıdık bir zemine basar: Latin alfabesi, tek lehçe kabul edilen bir yazı dili, oturmuş bir ccTLD ekosistemi. Körfez pazarına (Suudi Arabistan, Birleşik Arap Emirlikleri, Katar) girmek istendiğinde bu zemin tamamen değişir. Yazı yönü tersine döner, resmi yazı dili ile günlük konuşulan lehçe birbirinden ayrışır, alan adı seçenekleri yerel ticari sicil şartlarına bağlanır.
Bu fark, teknik SEO kararlarının sırasını da değiştirir. Almanya örneğinde önce alan adı, sonra içerik yerelleştirmesi konuşulabilirken, Arapça pazarda önce hangi lehçe ve hangi ülkenin hedeflendiği belirlenmeden ne alan adı ne URL yapısı ne de hreflang kararı sağlıklı verilebilir. Bir e-ticaret veya B2B hizmet şirketinin Türkçe içeriğini Arapça pazara taşırken karşılaştığı kararlar, bu belirleme noktasından başlayarak sırayla ilerler ve her karar bir sonrakinin parametrelerini kilitler.
Hangi Arapça? Fusha mı, Körfez lehçesi mi: hedef pazar kararı nereden başlar
Arapça, tek bir yazı dili değil. Modern Standart Arapça (Fusha) resmi belgelerde, haber sitelerinde ve arama motorlarının indekslediği yazılı içeriğin büyük kısmında kullanılırken, günlük konuşma ve sosyal medya etkileşimi ülkeden ülkeye değişen lehçelerle (Suudi lehçesi, Emirat lehçesi, Katar lehçesi) yürür. SEO içeriği için pratik karar genellikle Fusha'dır; kullanıcılar arama sorgularını da büyük ölçüde bu yazı diliyle yazar, teknik sayfa içeriği, ürün açıklamaları ve blog yazıları buna göre üretilir.
Lehçe farkı asıl olarak reklam metni, sosyal medya paylaşımı ve müşteri hizmetleri iletişiminde belirleyici olur; bu kanallarda hedef ülkenin lehçesine yakın bir ton, dönüşüm oranını gözle görülür şekilde etkileyebilir. Ama site içeriğinin omurgasını oluşturan sayfalar için Fusha, birden fazla Körfez ülkesine aynı anda hitap edebilen ortak paydadır; yerelleştirme lehçe katmanında kampanya metnine iner. Şirketin tek bir Körfez ülkesine mi (örneğin yalnızca BAE) yoksa bölgenin tamamına mı hitap edeceği, bir sonraki tüm kararları (alan adından hreflang kümesine kadar) doğrudan şekillendirir.
Lehçe kararını gözden kaçıranların yaptığı yaygın hata şudur: Fusha ile başlayıp süreci kolaylaştırmak için birleştirme yaparlar, ancak yerelleştirme aşamasında kampanya metinleri için ayrı tercümanla çalışmak zorunda kalırlar. Bu bölünme baştan planlanmazsa hem süreç hem bütçe zorlaşır; yazılı içerik teslim takvimi ile kampanya metni tercüme süreci birbiriyle çakışınca pazara giriş tarihleri beklenmedik biçimde kayar.
Alan adı kararı: .com altında alt dizin mi, yoksa yerel ccTLD mi
.de veya .co.uk gibi Avrupa ccTLD'lerinde alan adı satın almak genellikle sadece bir kayıt işlemidir. Körfez ccTLD'lerinde durum farklı işler: .sa alan adı almak Suudi Arabistan'da ticari sicil kaydı ister, .ae için Birleşik Arap Emirlikleri'nde yerel bir ticaret lisansı veya yerel sponsor gerekir. Türkiye merkezli bir şirket için bu şart, yerel bir tüzel kişilik kurmadan ccTLD almayı fiilen imkânsız hale getirir.
Bu yüzden pazara giriş aşamasında en yaygın ve gerçekçi tercih, mevcut .com alan adı altında bir Arapça alt dizin (/ar/ veya /ar-ae/) açmaktır; ccTLD ile gTLD kararı Körfez sicil şartlarıyla burada tersine döner. Bu yaklaşım hem yatırım riskini düşürür hem de pazarın gerçekten talep ürettiğini görmeden yerel şirket kurma yüküne girmez. Talep somutlaştıkça, yerel tüzel kişilik kurulup .ae veya .sa alan adına geçiş ayrı bir proje olarak ele alınabilir; bu geçiş kendi başına bir URL taşıma operasyonu gerektirir ve redirect ile hreflang geçiş mantığının aynı disiplinini ister.
Alt dizin tercihi aynı zamanda içerik otoritesini birleştirir. Türkçe sürümün kurduğu backlink birikimi, ayrı bir ccTLD'ye geçildiğinde sıfırlanır; alt dizin yapısında ise bu birikim Arapça sayfaları da besler. Körfez pazarında yeni olan bir şirket için bu fark ihmal edilecek kadar küçük değildir.
URL yapısı ve dil kodu: ar mı, ar-SA mı, ar-AE mi
tr ile tr-TR arasındaki farkı belirleyen mantık burada da geçerli, ama Arapça'da bölge kodu seçimi çok daha belirleyici bir rol üstlenir. Tek bir Arapça içerik seti tüm Körfez ülkelerine hitap edecekse, sade ar kodu doğru tercihtir; bu, "genel Arapça, bölgeden bağımsız" anlamına gelir ve içerik gerçekten ülkeler arası farklılaşmıyorsa yeterlidir.
Ama fiyatlandırma, kargo süresi, ödeme yöntemi veya yasal metin ülkeye göre değişiyorsa (ki Körfez pazarında bu genellikle kaçınılmazdır), her ülke için ayrı bölge kodu gerekir: BAE için ar-AE, Suudi Arabistan için ar-SA, Katar için ar-QA. URL yapısı da bu kararı yansıtmalı; /ar-ae/ ve /ar-sa/ gibi ayrı alt dizinler, ilerideki içerik farklılaşmasına zaten hazır bir iskelet kurar. Tek bir /ar/ dizini ile başlayıp sonradan ülke bazlı ayrıma geçmek, mevcut URL'lerin taşınmasını gerektireceğinden, bu kararı en başta vermek daha az maliyetlidir.
Karar ertelenmesi pahalıya gelir. Yüzlerce ürün sayfası /ar/ altında yayınlandıktan sonra /ar-sa/ ve /ar-ae/ yapısına geçmek, hem yeniden yönlendirme yükümlülüğü hem de hreflang kümesinin baştan kurulması anlamına gelir. Yapı kararını gelir modeliyle birlikte değerlendirin: tek para birimi mi, iki para birimi mi?
RTL teknik altyapı: render katmanında ne değişir
URL yapısı ve dil kodu belirlendikten sonra sırada teknik render katmanı vardır: Arapça sayfalarda <html dir="rtl" lang="ar"> özniteliği zorunludur ve bu, yalnızca metnin yönünü değil, sayfadaki tüm düzenin (menü, breadcrumb, form alanları, ikon yönleri) aynasını çevirir. RTL dillerin teknik SEO'ya getirdiği farkları ele alan yazıda anlatılan CSS mantıksal özellikler (margin-inline-start gibi fiziksel yön yerine akış yönüne göre çalışan özellikler), bu aşamada devreye girmesi gereken altyapıdır.
Bu adımın gözden kaçtığı en yaygın senaryo, mevcut Türkçe/İngilizce şablonun CSS'inin fiziksel yön (margin-left, padding-right) üzerine kurulu olması ve Arapça sürüm eklenince düzenin yarım yamalak tersine dönmesidir. Metin sağdan sola akar ama buton hizalaması, ikon yönü ve form etiketleri solda kalır. Bu tutarsızlık kullanıcı deneyimini bozduğu gibi, Google'ın sayfayı düşük kaliteli bir uyarlama olarak değerlendirmesine de zemin hazırlar.
RTL dönüşümünü şablon geliştirme aşamasında değil, içerik giriş sürecinde fark etmek çok daha pahalıya gelir. Mevcut şablonun CSS'ini fiziksel yön özellikleri için tarayın: kaç adet margin-left, padding-right gibi değer kullanılıyor? Onlu rakamlarda kalan sayı, dönüşümün birkaç saatlik iş olduğunu gösterir. Yüzü aşkın değer varsa şablon yeniden yazmayı düşünmek gerekir.
Çeviri mi yerelleştirme mi: ödeme, kargo, para birimi, kültürel referans
Çeviri ile yerelleştirme arasındaki ayrımın Körfez pazarında somutlaştığı yer tam olarak burasıdır. Ürün açıklamasını Arapçaya çevirmek görece yönetilebilir bir adımdır; ama ödeme sayfasında yerel kartla ödeme seçeneğinin (örneğin Suudi Arabistan'da mada) görünmemesi, para biriminin hâlâ TL veya USD olarak kalması, kargo süresinin Türkiye'den gönderim varsayımıyla hesaplanması, çevirinin kalitesinden bağımsız olarak dönüşümü doğrudan düşürür.
Kültürel takvim de ayrı bir yerelleştirme kalemidir: Ramazan ve Kurban Bayramı tarihleri hicri takvime göre kaydığından, kampanya planlaması Türkiye'deki miladi takvim alışkanlığıyla değil, hedef pazarın dini ve resmi tatil takvimiyle hizalanmalıdır. Görsel seçimi de benzer bir hassasiyet ister; Türkçe sürümde kullanılan bir görsel, kıyafet veya sahne seçimi açısından Körfez pazarında doğrudan kullanılamayabilir. Bu kalemlerin hepsi çeviri bütçesinin dışında, ayrı bir yerelleştirme bütçesi ve süreç gerektirir.
Ödeme entegrasyonu genellikle en uzun süreyi alan kalemdir. Yerel ödeme altyapılarına bağlanmak için başvuru süreçleri, teknik entegrasyon ve ülke bazında test aşamaları birkaç hafta alabilir. Bu süre, içerik üretim takviminden bağımsız planlanmalıdır; aksi hâlde Arapça sayfalar hazır ama ödeme akışı eksik olarak yayına gidebilir.
Hreflang kümesi Türkçe ile Arapça arasında nasıl kurulur
Teknik kurulum, hreflang'ın temel çalışma mantığından farklı değildir; fark, kod setinin seçimindedir. Tek bölgeye hitap eden bir kurulumda tr ve ar karşılıklı referans verir; ülke bazlı ayrışma varsa tr, ar-AE ve ar-SA üçlüsü birbirine karşılıklı işaret eder, her biri kendine self-canonical verir. x-default değeri genellikle Türkçe sürüme (şirketin ana pazarı) veya coğrafi konumdan bağımsız genel bir Arapça sürüme atanır; bu seçim, ziyaretçinin hangi dil sürümüne "varsayılan" olarak yönlendirileceğini belirler.
Karşılıklı referansın eksik kalması, çok dilli sitelerde zaten en sık görülen hatadır. Arapça ile Türkçe arasında bu ilişki kurulurken, iki dilin şablonlarının farklı geliştirme ekipleri veya farklı zaman dilimlerinde çalışılması, senkronizasyonu daha da kırılgan hale getirir. Yayına almadan önce her iki dildeki sayfanın kaynak kodunu açıp karşılıklı referansı elle doğrulamak, bu aşamada atlanmaması gereken adımdır.
Hreflang kümesini sitemap üzerinden taşıyorsanız, Türkçe ve Arapça sürümlerin sitemap içinde ayrı <xhtml:link> girişleriyle karşılıklı gösterildiğini kontrol edin. Sitemap yöntemi, şablon seviyesinde yapılan değişikliklerin anında tüm sürümlere yansıması yerine merkezi bir kontrol noktası sağlar; yüzlerce ürün sayfası olan kataloglarda bu avantajı göz ardı etmemek gerekir.
Arama sinyalleri Körfez pazarında farklı çalışır mı
Google, Körfez ülkelerinde kullanıcıların ağırlıklı olarak mobil cihazlardan ve zaman zaman düşük-orta bant hızlarıyla arama yaptığını bilir; bu, sayfa hızı ve Core Web Vitals'in Arapça sürümlerde de görmezden gelinmemesi gerektiği anlamına gelir. RTL düzende tablolar ve ızgara yapıları LTR sürümlere kıyasla farklı genişlik hesaplamaları gerektirebilir; Cumulative Layout Shift skoru beklenmedik şekilde yükselebilir.
Backlink profili açısından da bir fark var. Türkçe sürüm için kazanılan bağlantılar, Arapça sayfaları doğrudan desteklemez; bu nedenle Körfez pazarında görünürlük için yalnızca teknik kuruluma güvenmek, sonuç üretmeyi yavaşlatır. Bölgesel Arapça yayınlardan veya endüstri dizinlerinden bağlantı kazanmak ayrı bir süreç gerektirir ve çoğu zaman marka içeriği oluşturmaktan daha fazla zaman alır.
Arama niyeti de bu pazarda farklı biçimlenebilir. Türkçe sürümdeki ürün sayfasına gelen sorgu kümesi ile Körfez'deki kullanıcının aynı ürün için kullandığı sorgular, kelime öbeği düzeyinde örtüşebilir ama niyet derinliği ve karar aşaması farklı olabilir. Arapça anahtar kelime araştırmasını mevcut Türkçe içerik haritasından üretmek yerine, hedef pazarın SERP görünümünü ayrıca incelemek gerekir. Alışveriş ve B2B hizmet kategorilerinde özellikle belirgin olan bu fark, hangi sayfanın önce üretileceğini ve hangi sorgu kümesine odaklanılacağını doğrudan etkiler. Türkçe sürümde yüksek dönüşüm getiren bir sayfa, Körfez'de henüz hiç aranmayan bir sorguya karşılık geliyor olabilir; bunun tersi de geçerlidir.
Google Search Console'da Arapça sürüm için ayrı bir mülk tanımlamak da ihmal edilmemesi gereken bir adımdır. Alt dizin yapısında bu genellikle otomatik izleme kapsamında kalır; ama ülke bazında ayrıştırılmış hreflang hataları ve performans verisine erişmek için GSC uluslararası hedefleme raporunu düzenli takip etmek gerekir. Sorunların erken tespiti burada mümkün olur.
Yayın öncesi kontrol: hangi sıra izlenir
Bu kararların hepsi birbirine bağlı olduğundan, sıra önemlidir. Önce hedef pazar (tek ülke mi, bölgenin tamamı mı) ve buna bağlı lehçe/kod kararı belirlenir. Ardından alan adı yapısı (alt dizin mi, ileride ccTLD mi) seçilir; bu iki karar birlikte URL yapısını (dil ve bölge kodlarının URL'de nasıl göründüğünü) şekillendirir. RTL teknik altyapı bu URL yapısı üzerine kurulur, çünkü şablon seviyesinde yapılacak değişiklikler URL kararından sonra ortaya çıkan sayfa sayısına bağlıdır.
Yerelleştirme çalışması (ödeme, kargo, kültürel takvim, görsel) bu teknik iskelet üzerine oturur; iskelet sağlam değilse yerelleştirme yatırımı da kısa ömürlü olur. Hreflang kümesi en son kurulur, çünkü hangi URL'lerin ve hangi kodların birbirine referans vereceği, önceki tüm kararların tamamlanmasını gerektirir. Yayına almadan önce her dildeki sayfanın RTL görünümü, ödeme akışı ve hreflang karşılıklı referansı elle test edilmeli; bu üç kontrol, Türkçe içeriğin Arapça pazara sağlıklı taşındığını doğrulayan en pratik son adımdır.
Türk şirketlerin çoğu için Körfez pazarına açılma kararı, Avrupa pazarına açılmaktan daha yüksek bir ilk yatırım eşiği taşır. RTL altyapı, lehçe/kod kararı ve yerel ödeme entegrasyonu tek başına bile ciddi bir mühendislik yüküdür. Ama bu yükün büyük kısmı bir kereliğine kurulan altyapıdır; doğru sırayla ilerleyen bir kurulum, sonraki her yeni Körfez ülkesi eklendiğinde yeniden sıfırlanmaz, yalnızca genişletilir.