Bir sitenin kod tabanı yıllarca tek bir varsayımla yazılır: metin soldan sağa akar, margin ve padding değerleri sol veya sağ tarafa göre sabitlenir, ikon ve ok yönleri hep aynı tarafa bakar. Arapça, Farsça veya Urduca gibi sağdan sola yazılan bir dil eklendiğinde bu varsayımın üzerine kurulu her karar aynı anda test edilir. Sorun genellikle görsel bir bozulmayla fark edilir; ama görünürdeki karışıklığın altında, tarama ve indekslemeye kadar uzanan daha derin bir katman vardır.
RTL (right-to-left) dil eklemek, mevcut çok dilli yapıya bir dil daha eklemekten farklıdır. LTR diller arasında geçiş yaparken (örneğin Türkçe'den İngilizce'ye) sayfa iskeleti aynı kalır, sadece metin değişir. RTL bir dil eklendiğinde ise iskeletin kendisi yön değiştirmek zorundadır: navigasyon sırası, form alan hizası, ikon yönü, hatta sayı ve tarih gösterimi bidi (bidirectional text) algoritmasının kurallarına tabi olur. Bu farkın teknik SEO'ya nasıl yansıdığı, çoğu ekip yalnızca canlıya çıktıktan sonra öğrenir.
dir="rtl" özniteliği tam olarak neyi değiştiriyor?
dir özniteliği, tarayıcıya blok düzeyindeki içeriğin akış yönünü söyler; bu bir CSS özelliği değil, HTML semantiğidir ve CSS'in direction özelliğinden önce devreye girer. <html lang="ar" dir="rtl"> yazıldığında tarayıcı, o belge içindeki blok elemanların (paragraf, liste, tablo hücresi) iç akışını sağdan sola çevirir. Bu, sadece metnin görsel hizasını değil, tarayıcının erişilebilirlik ağacında elemanları hangi sırayla okuduğunu da etkiler; ekran okuyucular ve arama motoru erişilebilirlik değerlendirmeleri bu sırayı kullanır.
dir özniteliği eksik bırakılıp yalnızca CSS ile direction: rtl uygulanan sayfalarda görsel düzeltme çalışır, ama semantik katman eksik kalır. Bu, tarayıcı uzantıları veya çeviri araçlarının sayfayı yanlış yorumlamasına yol açabilir; ayrıca form elemanlarının otomatik doldurma davranışı ve klavye giriş yönü, tarayıcının dir özniteliğine bakarak karar verdiği bir alandır, CSS bu kararı değiştirmez. Google'ın kendisi dir özniteliğini bir sıralama sinyali olarak kullanmaz, ama sayfanın gerçek kullanıcı deneyimi kalitesini etkileyen her bozulma (yanlış hizalanmış form, ters dönmüş navigasyon oku, üst üste binen metin kutuları) dolaylı olarak Core Web Vitals'a giren düzen kaymalarına (layout shift) dönüşebilir.
HTML lang ve dir arasındaki ilişki nasıl kurulur?
lang özniteliği dili tanımlar, dir özniteliği yönü tanımlar; ikisi birbirinin yerine geçmez ve biri doğru olduğunda diğeri otomatik doğru olmaz. lang="ar" yazılmış bir sayfada dir unutulursa tarayıcı varsayılan olarak LTR uygular ve Arapça metin görsel olarak yanlış akar; tersine dir="rtl" yazılıp lang eksik bırakılırsa arama motoru dil tespitini içerik analizine bırakır, bu da URL yapısından türeyen dil sinyalinin bütünlüğünü bozar.
Bir diğer sık atlanan nokta, sayfa içindeki karma dil bloklarıdır. Arapça bir makale içinde İngilizce bir marka adı veya URL geçtiğinde, bu parçaya <span lang="en" dir="ltr"> uygulanmazsa bidi algoritması metni beklenmedik şekilde yeniden sıralayabilir; parantez, tırnak işareti ve noktalama karakterleri özellikle bu karışıklıktan etkilenir. Küçük bir markup eksikliği, kullanıcı arayüzünde metnin okunaksız hale gelmesine yol açar ve bu, sayfanın içerik kalitesi algısını görsel olarak düşürür.
Arapça, Farsça ve Urduca arasındaki bidi farkları nereden gelir?
Üç dil de sağdan sola yazılır, ama aynı teknik muameleyi görmez. Arapça ve Farsça Arap alfabesini paylaşır, Urduca da Arap alfabesinin genişletilmiş bir biçimini (çoğunlukla Nastaliq yazı stili) kullanır; ancak Farsça'nın kendi harfleri (پ, چ, ژ, گ) ve Urduca'nın ek karakterleri Unicode'da farklı kod bloklarına denk gelebilir, bu da yanlış font-family tanımlanmış sayfalarda bazı karakterlerin kutu içinde görünmesine (tofu karakterleri) neden olur.
Sayı gösterimi üçü arasında ayrışan bir diğer noktadır: klasik Arapça metinlerde Batı Arap rakamları (0-9) sıkça kullanılırken, Farsça'da Doğu Arap rakamları (۰-۹) yaygındır ve bu rakamlar bidi algoritmasında LTR bir ada gibi davranır, yani rakam grubu kendi içinde soldan sağa okunur ama çevresindeki metin sağdan sola akar. Urduca'da ise bölgeye göre hem Batı hem Doğu Arap rakamları görülebilir. Bu karışık akış, tarih, fiyat ve telefon numarası gibi alanlarda şablon seviyesinde test edilmeden bırakılırsa, kullanıcıya anlamsız bir sayı dizisi gösterebilir.
Nastaliq yazı stili Urduca için ayrı bir performans meselesi de yaratır: bu stili doğru render eden web fontları genellikle standart Arapça fontlardan daha büyük dosya boyutuna sahiptir ve karakterler arası bağlantı (ligature) hesaplaması tarayıcıda ek render süresi gerektirir. Font yükleme stratejisi burada gözden kaçırılırsa, Urduca sayfa varyantı diğer dil sürümlerinden ölçülebilir şekilde daha yavaş açılır; bu fark dil sayısı arttıkça performans yönetimi tartışmasının RTL'e özel bir uzantısıdır.
CSS'te mantıksal özellikler ile fiziksel yön nasıl ayrışır?
margin-left, padding-right, text-align: left gibi fiziksel CSS özellikleri RTL sayfada anlamını korumaz; sol her zaman sol olarak render edilir, dil yönü değişmiş olsa bile. Bu yüzden RTL desteği eklenen bir site iki seçenekle karşılaşır: her bileşen için ayrı bir [dir="rtl"] override seti yazmak, veya margin-inline-start, padding-inline-end, text-align: start gibi mantıksal (logical) özelliklere geçmek. İkinci yol daha sürdürülebilirdir çünkü tarayıcı, dir özniteliğine bakarak "start" ve "end" değerlerini otomatik olarak doğru fiziksel tarafa çevirir.
Bu geçiş yapılmadan sadece belirli sınıflara [dir="rtl"] seçicisiyle ayrı stil eklemek, her yeni bileşende bu istisnanın da eklenmesini gerektirir; zamanla stil dosyası büyür ve bir noktada RTL override'ı unutulan bileşen görsel olarak bozuk render edilir. Bu bozulma bir sıralama sinyali değildir, ama sayfanın kullanılabilirlik kalitesini düşürür ve dolaylı olarak kullanıcı sinyallerine (hemen çıkma, sayfada kalma süresi) yansır.
RTL dil eklenince hreflang kümesi nasıl genişler?
Hreflang etiketinin temel mantığı RTL dilde de değişmez; her dil sürümü kendi karşılıklarına referans verir ve x-default belirlenir. Ama dil kodu seçiminde ekstra bir dikkat gerekir: Arapça için bölgesel varyantlar (ar-SA, ar-EG, ar-AE) içerik ve para birimi farkı taşıyorsa ayrı hreflang girdileri gerekir; Körfez pazarına taşırken bu kod kararı lehçe kararından sonra gelir, tek bir genel ar kodu bu ayrımı kapsamaz. Dil kodu ile bölge kodu arasındaki farkı ele alan karar mantığı burada aynı şekilde uygulanır: tek Arapça sürüm varsa ar yeterlidir, bölgeye özgü içerik ve fiyatlandırma varsa bölge kodu eklenmelidir.
Farsça'da benzer bir ayrım İran (fa-IR) ve Afganistan'daki Farsça (fa-AF, genellikle Dari olarak adlandırılır) arasında ortaya çıkabilir; ikisi yazı sistemini paylaşsa da kelime dağarcığı ve bazı yazım kuralları farklıdır. Urduca'da ise Pakistan (ur-PK) ve Hindistan'daki Urduca konuşan nüfus arasında bölgesel içerik farkı olabilir. Bu üç dilin hepsinde hreflang kümesi genişlerken, her yeni girdinin karşılıklı referans (return tag) kuralına uyması ve x-default'un hangi sürümü işaret ettiğinin yeniden değerlendirilmesi gerekir; RTL dil eklenmesi çoğu zaman x-default kararının da gözden geçirilmesini gerektiren bir eşik olur.
Googlebot RTL sayfaları nasıl tarıyor, hangi hatalar indekslemeyi bozar?
Googlebot'un tarama ve indeksleme mantığı dil yönünden bağımsızdır; HTML'i parse eder, metni çıkarır ve dil tespitini içerik analizi ile lang özniteliğinin bir kombinasyonuyla yapar. Sorun, RTL sayfalarda daha sık görülen belirli hata kalıplarından kaynaklanır. Birincisi, sunucu taraflı render sürecinde dir özniteliğinin JavaScript ile sayfa yüklendikten sonra eklenmesidir; JavaScript ile render edilen çok dilli içeriğin genel gecikme riski burada yön özniteliğine de sirayet eder, Googlebot ilk HTML'i aldığında dir henüz yoksa, render kuyruğuna girene kadar sayfa yönü belirsiz kalır.
İkincisi, RTL sayfalarda metin yönü karışıklığından kaynaklanan görünmez karakterlerdir. Bazı CMS'ler bidi kontrolü için Unicode kontrol karakterleri (RLM, LRM, RLE, PDF gibi) ekler; bu karakterler doğru kullanıldığında görsel akışı düzeltir, ama yanlış yerleştirildiğinde metin içine gömülü, görünmeyen ama arama motoru tarafından okunan garip karakter dizileri oluşturabilir. Bu durum içerik kalitesi analizinde gürültü üretir ve nadir durumlarda metnin anlamsal bütünlüğünü bozduğu için içerik zayıf olarak değerlendirilebilir.
Üçüncüsü, RTL ve LTR sürümler arasında canonical veya hreflang zincirinin bozulmasıdır; bu genellikle RTL sürüm ayrı bir CMS şablonu veya ayrı bir geliştirme ekibi tarafından üretildiğinde ortaya çıkar. Aynı içeriğin farklı dillerde duplicate işaretlenmesi sorunu, RTL sürümlerde daha sık görülür çünkü şablon farkı büyük olduğunda içerik benzerliği ölçümü metnin kendisinden çok markup gürültüsüyle karışabilir.
Karma dil sitede sık yapılan teknik hatalar
LTR ana dille başlayıp sonradan RTL dil ekleyen sitelerde tekrar eden birkaç hata kalıbı vardır. İlki, RTL sayfanın header ve footer'ını LTR şablondan doğrudan kopyalayıp yalnızca metni çevirmektir; menü sırası, logo konumu ve arama kutusu hizası fiziksel CSS'e bağlıysa görsel olarak ters akar ama düzen yanlış kalır. İkincisi, form doğrulama mesajlarının ve hata metinlerinin RTL şablona hiç taşınmamasıdır; bu alanlar genellikle JavaScript içinde sabit metin olarak tutulur ve çeviri sürecinin dışında kalır.
Üçüncü hata, sitemap ve robots.txt'te dil öneki mantığının RTL dil için test edilmemesidir; URL yapısı Latin alfabesi dışı slug üretiyorsa (örneğin Arapça karakterlerle URL) yüzde kodlama (percent-encoding) sitemap dosyasında doğru işlenmemişse URL'ler geçersiz hale gelir. Teknik SEO denetim listesinin RTL dil eklenen bir projede yeniden çalıştırılması, bu üç hatanın erken yakalanmasını sağlar; RTL desteği tek seferlik bir görsel düzeltme değil, mevcut denetim rutininin yön farkına göre yeniden kalibre edilmesi gereken bir eşiktir.
Dördüncü ve daha az fark edilen hata, arama kutusu ve otomatik tamamlama bileşenlerinin klavye giriş yönünü yönetmemesidir; kullanıcı Arapça karakter yazarken imleç yanlış yöne hareket ediyorsa, bu deneyim sorunu teknik bir SEO hatası değildir ama kullanıcının aramayı tamamlamadan sayfadan ayrılmasına yol açar, bu da davranışsal sinyalleri dolaylı olarak etkiler.
RTL dil eklemek, çok dilli bir sitenin en görünür ama en az test edilen eşiklerinden biridir. Görsel bozulma genellikle ilk fark edilen belirtidir, ama altında dil özniteliği tutarlılığı, hreflang kümesinin doğru genişlemesi ve tarama sürecinin render gecikmesinden etkilenmemesi gibi daha kalıcı kararlar yatar. Bu kararlar bir kere doğru kurulduğunda, sonraki her RTL dil eklemesi (Arapça'dan sonra Farsça, Farsça'dan sonra Urduca) aynı iskelet üzerine oturur ve tekrar eden hata riski azalır.
Pratikte en sağlıklı yaklaşım, RTL desteğini tek bir dilin özel durumu gibi değil, sitenin genel mimarisinin bir yön parametresi gibi ele almaktır. Mantıksal CSS özellikleri, doğru lang/dir eşleşmesi ve bidi'ye duyarlı bileşen testleri bir kere kurulduğunda, yeni bir RTL dil eklemek büyük bir yeniden yapılanma değil, mevcut sistemin bir uzantısı haline gelir.