URL Çevirisi SEO: TR/EN Sitede Slug Nasıl Yapılır

URL çevirisi SEO açısından kolay görünür ama ayrıntıda dağılır: bir sayfanın adresindeki kelimeleri hedef dile uyarlamak, adres yapısını iki dilde tutarlı kılmak ve bu eşleşmeyi arama motoruna doğru bildirmek birlikte yürütülmesi gereken üç ayrı iştir. Bu yazı, hem Türkçe hem İngilizce yayın yapan bir sitede slug çevirisinin ne zaman işe yaradığını, hangi biçimlendirme kurallarının gerektiğini ve eski bir adres değiştiğinde hangi adımların izlenmesi gerektiğini anlatır.

Yazı çok dilli site sahibine, içerik editörüne ve çeviri ekibine yöneliktir. Dayanak olarak Google Search Central'ın URL yapısı, yerelleştirilmiş sürümler, çok bölgeli siteler ve yönlendirme belgeleri kullanıldı. Örnek siteler kurgusaldır ve rakam içermez.

Slug Çevirmenin Faydası ve Sınırı

Slug, adresin sayfayı anlatan son parçasıdır. Çok dilli bir sitede asıl soru, bu parçanın sayfanın diline göre mi yoksa tek bir dilde mi yazılacağıdır. Google'ın URL yapısı belgesi (yeni sekmede açılır) bu konuda açık bir yönlendirme yapar: adreste hedef kitlenin dilindeki kelimeleri, gerekiyorsa transliterasyonla yazılmış hâllerini kullanın. Belgenin örnekleri arasında Almanca ve Japonca kelimeler bulunur. Belge, İngilizce kelimelerin Türkçe sitelerde tercih edilip edilmeyeceği konusuna girmez; yani "İngilizce slug daha iyi" ya da "yerel slug sıralamayı yükseltir" biçiminde bir sonuç çıkarmak belgeyle desteklenmez.

Çevirinin gerçekçi faydaları

Yerelleştirilmiş slug'ın somut faydaları sıralama vaadinden çok kullanıcı deneyimi ve ekip düzeniyle ilgilidir:

• Okunurluk: Türkçe okuyan biri adreste kendi dilinde bir ifade görür; bağlantıyı mesajlaşma uygulamasında paylaşırken sayfanın konusunu adresten anlayabilir.
• Tutarlılık: Başlık Türkçe, adres İngilizce olduğunda editörler ve müşteri destek ekipleri iki ayrı terimi aklında tutmak zorunda kalır. Eşleşen dil, iç yazışmayı kolaylaştırır.
• Dil ayrımının görünürlüğü: Dil klasörü ve yerel slug birlikte olduğunda, günlük ya da raporda bir adresin hangi dil sürümüne ait olduğu bakar bakmaz anlaşılır.
• Güven algısı: Adres, başlık ve içerik aynı dilde olduğunda sayfa daha bütünlüklü görünür. Bu, ölçülmüş bir sıralama etkisi değil, genel bir kullanıcı deneyimi gözlemidir.

Çevirinin sınırları

Slug çevirisi bazı işleri yapmaz, ve bu sınırı bilmek gereksiz beklenti yaratmamak için önemlidir. Birincisi, slug sayfanın dilini arama motoruna bildirmenin yolu değildir. Google'ın yerelleştirilmiş sürümler belgesi (yeni sekmede açılır), sayfa dilini tespit etmek için hreflang ya da HTML lang niteliğini kullanmadığını söyler. Dolayısıyla adresin dilini değiştirmek, iki sürümü eşleştirme işini görmez; eşleştirme için ayrı bir işaretleme gerekir. Bu konunun ayrıntısı hreflang etiketlerini denetleme rehberinde anlatılıyor.

İkincisi, mevcut ve iyi çalışan bir adresi yalnızca "daha yerel olsun" diye değiştirmek risklidir. Adres değişince eski adrese gelen bağlantılar, yer imleri ve dış kaynaklardaki atıflar yönlendirmeye bağımlı hâle gelir. Üçüncüsü, çeviri sırasında anlam kayabilir; bir kelimenin birebir karşılığı sektörde kullanılan terim olmayabilir. Bu yüzden slug çevirisi, kelimeyi sözlükten almak yerine, o dilde sayfanın konusunu en doğal biçimde anlatan ifadeyi seçmektir.

Hangi sayfada çevirmeli, hangisinde sabit bırakmalı?

Her adres parçası aynı muameleyi gerektirmez. Aşağıdaki tablo, kurgusal bir hizmet sitesi üzerinden pratik bir ayrım önerir.

Kurgusal örnek: iki dilli bir ajans sitesinde "sosyal medya yönetimi" hizmeti Türkçede yaygın bir ifadedir; İngilizce karşılığı sayfada "social media management" olarak geçer. Slug'lar da bu ifadelerin sade hâli olabilir. Aynı sitede kendi paket adı "Başlangıç Paketi" ise bu bir marka ürün adıdır; adres Türkçe ve İngilizce sayfada farklı kelimelerden oluşabilir ama sayfa içinde aynı paketin adı olarak geçtiğinden iki dilde tutarlı kalmasına dikkat edilir.

Türkçe Karakter, Tire ve Kısa Slug Kuralları

Slug'ı çevirdikten sonra ikinci karar, bu kelimelerin adreste nasıl yazılacağıdır. Burada üç ayrı konu var: Türkçe karakterlerin işlenişi, kelime ayırıcılar ve uzunluk.

Türkçe karakterler: iki yol

Google'ın URL yapısı belgesi, ASCII aralığı dışındaki karakterlerin yüzde kodlamayla yazılması gerektiğini söyler ve bunu gemüse sözcüğünün gem%C3%BCse biçimine dönüşmesiyle örneklendirir. Belge UTF-8'i adıyla anmaz; o yüzden kodlamanın bu özel tabloya bağlı ayrıntısını belgeye mal etmeyelim. Önemli olan sonuçtur: Türkçe karakterli bir slug, adres çubuğunda okunur görünse bile kopyalandığında kodlu bir yazıya dönüşebilir.

Bu nedenle iki yaygın yol vardır:

1. Transliterasyon: ç, ğ, ı, ö, ş, ü harfleri karşılık gelen ASCII harflerine çevrilir. Belge "gerekirse transliterasyonla yazılmış kelimeler" ifadesini kullandığı için bu yol belgeyle uyumludur.
2. Karakterleri koruma: Slug Türkçe karakterlerle yazılır, sistem ve sunucu bunu yüzde kodlamayla taşır. Bu yolda sitemap, hreflang ve iç bağlantılarda aynı kodlamanın tutarlı kullanıldığını denetlemek gerekir.

Hangisini seçerseniz seçin, kural tek olmalıdır. Yarısı karakterli, yarısı ASCII slug'lardan oluşan bir site hem editörler hem de yönlendirme listeleri için gereksiz iş çıkarır. Bu yazının genel önerisi, bakım kolaylığı nedeniyle transliterasyondur; bu bir editoryal tercihtir, Google'ın zorunluluğu değildir.

Genel bilgi notu: Türkçedeki ı ve i harfleri ASCII'ye çevrildiğinde aynı harfe dönüşür, bu da nadiren iki farklı kelimenin aynı slug'a düşmesine yol açabilir. Çakışma çıkarsa kelimelerden birini değiştirin ya da adrese ayırt edici ikinci bir kelime ekleyin. Yeni sayfa eklerken mevcut slug listesine bakmak bu sorunu en başta yakalar.

Tire, alt çizgi ve büyük harf

Google'ın belgesi kelimeleri ayırmak için tire kullanmayı, alt çizgiye tercih etmeyi söyler; ayrıca kelimeleri bitişik yazmaktan kaçınmayı önerir, yoksa "greendress" gibi okunması zor bir yapı ortaya çıkar. Belge ayrıca adreslerin büyük küçük harfe duyarlı olduğunu, Google'ın /APPLE ile /apple adreslerini ayrı URL olarak ele aldığını yazar. Sunucunuz farklı harf büyüklüğünü aynı sayfaya çözüyorsa, tüm metni aynı harf büyüklüğüne çevirmeyi önerir. Pratik sonuç: slug'ları tamamen küçük harfle yazın ve büyük harfli bir varyant açılırsa onu kalıcı yönlendirmeyle tek biçime bağlayın.

Kısa ve tanımlayıcı slug

Belge, uzun kimlik numaraları yerine okunabilir kelimelerin tercih edilmesini ve gereksiz parametrelerin kısaltılmasını söyler. Uzunluk için belgede sayısal bir sınır geçmez; bu yüzden aşağıdaki kurallar editoryal tavsiyedir:

• Slug'ı başlığın tam kopyası yapmayın; ana konuyu taşıyan üç ila beş kelimeyle yetinmek çoğu zaman yeterlidir.
• "ve", "ile", "için" gibi bağlaçları ve yıl, tarih gibi eskiyen ifadeleri çıkarın. Yıl içeren slug, içerik güncellendiğinde yanıltıcı kalır.
• Kategori klasörü zaten konuyu söylüyorsa slug'da tekrarlamayın.
• Her dil için ayrı bir kısa ifade seçin; birebir çeviri uzun çıkıyorsa o dilin doğal kısa ifadesine geçin.

Bu yazıdaki kuralların genel bir slug temizliği yönü de var; tek dilli bir sitede slug nasıl sadeleştirilir sorusunun cevabı için URL yapısı ve slug optimizasyonu yazısına bakabilirsiniz. Burada odak, bu kuralların iki dilli bir site için nasıl eşleştirileceğidir.

Kategori, etiket ve arşiv adresleri

Makale slug'ları kadar kategori, etiket ve arşiv sayfalarının adresleri de çevrilmelidir. Bu sayfalar sıklıkla unutulur, çünkü şablon üretir ve editör görmez. Sonuçta Türkçe bir makale, İngilizce bir kategori klasörünün altında durabilir ve adres iki dil karışımı bir yapı gösterir. Yayın öncesinde adresin tüm parçalarını soldan sağa okuyun: dil klasörü, kategori, sayfa slug'ı. Hepsi aynı dilde değilse tutarsızlık vardır. Belge bu karışım için ayrı bir kural yazmaz; bu bir okunurluk ve bakım tavsiyesidir.

Sayfalama ve filtre parametreleri de aynı disiplinden geçer. Google'ın belgesi gereksiz parametrelerin kırpılmasını söyler; dil bilgisini parametre olarak taşımak ise çok bölgeli siteler için önerilmez. Filtre parametrelerinin adı ve değeri için de tek bir dil kuralı seçmek, iki dilli yönlendirme listelerini sade tutar.

TR/EN Eşleşmesi: Canonical, Hreflang ve Rota Tablosu

Slug'ları çevirmek, iki sayfanın birbirinin karşılığı olduğunu arama motoruna kendiliğinden anlatmaz. Bu eşleşmenin üç parçası vardır: dil sürümlerini ayıran adres yapısı, hreflang işaretlemesi ve her sürümün kendi kanonik adresi.

Dil sürümleri için adres yapısı

Google'ın çok bölgeli siteler belgesi (yeni sekmede açılır) dört seçeneği karşılaştırır: ülke alan adı (örneğin example.de), gTLD üzerinde alt alan adı (de.example.com), gTLD üzerinde alt klasör (example.com/de/) ve URL parametreleri. Belgeye göre alt klasör kurulumu kolaydır ve aynı sunucuda bakımı düşüktür; dezavantajı kullanıcıların adresten coğrafi hedeflemeyi her zaman anlayamamasıdır. URL parametreleri ise önerilmez, çünkü bu yapıda segmentasyon zordur.

Türkçe ve İngilizce sürüm yayınlayan bir site için /tr/ ve /en/ gibi dil klasörleri bu seçeneklerden biridir. Belge, dil seçiminin çerez, tarayıcı ayarı ya da IP analiziyle değil, her dil sürümüne ayrı URL verilerek yapılmasını önerir. Google'a göre IP konum analizi zordur ve genel olarak güvenilir değildir. Ayrıca Googlebot çoğunlukla ABD'den tarar ve Accept-Language göndermez; bu yüzden dile göre dinamik içerik değiştiren bir kurulumda botun bazı sürümleri hiç görmemesi mümkündür.

Otomatik yönlendirme tuzağı

Belgenin en pratik uyarılarından biri, kullanıcıyı varsayılan dil ya da konuma göre otomatik olarak başka bir sürüme yönlendirmekten kaçınmaktır. Bu yönlendirmeler hem kullanıcıların hem arama motorlarının sitenin tüm sürümlerini görmesini engelleyebilir. Önerilen yaklaşım, kullanıcının sürümü kendisinin seçebileceği görünür bir dil bağlantısı sunmaktır. Tarayıcı dili İngilizce olan biri Türkçe sayfaya ulaştığında, "Bu sayfanın İngilizce sürümü" gibi bir bağlantı görmesi yeterlidir.

Hreflang ile eşleştirme

Yerelleştirilmiş sürümler belgesi, hreflang için üç yöntem sayar: HTML'de link etiketleri, HTTP üstbilgisi ve XML sitemap. Belgeye göre üçü Google açısından eşdeğerdir; hepsini birlikte kullanmanın ek bir faydası yoktur. Kurallar şunlardır:

• Sayfalar birbirine karşılıklı bağlanmalıdır; iki sayfa birbirini göstermiyorsa işaretlemeler yok sayılır.
• Her sürüm kendisini de listelemelidir.
• Alternatif adresler protokolü de içeren tam adres olmalıdır; göreli yollar uygun değildir.
• Yalnızca ISO 639-1 dil kodları ve ISO 3166-1 Alpha 2 bölge kodları desteklenir; ülke kodu tek başına yazılamaz.
• Eşleşmeyen dil için yedek olarak x-default kullanılabilir; belgeye göre bu, dil seçici ya da otomatik yönlendiren ana sayfalar için uygundur.

Hreflang'ın doğrulanması, hata türleri ve denetim sırası için yukarıda bağlantısı verilen hreflang rehberi daha ayrıntılıdır. Slug çevirisi bağlamında şunu hatırlamak yeterli: adres kelimeleri değiştiğinde hreflang'daki tam adresler de değişmek zorundadır. Yarım kalmış bir güncelleme, karşılıklı bağlantıyı kırar ve işaretleme yok sayılır.

Canonical ile ilişki

Google'ın yerelleştirilmiş sürümler belgesi, çevrilmiş sayfaların ancak ana içeriği çevrilmemişse yinelenen sayılacağını söyler. Yani tam çevrilmiş bir İngilizce sayfa, Türkçe sayfanın kopyası değildir. Hreflang ile canonical'ın birlikte nasıl davrandığı bu belgede ayrıntılı anlatılmaz, o yüzden uygulama şeklini kanıtsız bir kurala bağlamıyoruz. Ekiplerin yaygın tercihi her dil sürümünün kendi adresini canonical olarak göstermesidir; bu editoryal bir uygulama olarak anlatılır, belgenin zorunluluğu değildir. Yaygın canonical hataları ve nasıl bulunacağı için canonical etiketi hataları ve denetimi yazısı kullanılabilir.

Menü, breadcrumb ve dil değiştirici

Slug çevirisi yalnızca adres çubuğunu ilgilendirmez; sayfanın diğer parçalarıyla da uyumlu olmalıdır. Menü bağlantı metni, breadcrumb, sayfa başlığı ve adres aynı konu ifadesini taşıdığında okuyucu nerede olduğunu kolay anlar. Dil değiştirici ise en sık bozulan parçadır: çoğu şablon dil düğmesini karşı dilin ana sayfasına bağlar. Oysa Google'ın çok bölgeli siteler belgesi, kullanıcının sürümü kendisinin seçebilmesi için dil sürümlerine bağlantı vermeyi önerir; sayfa düzeyinde doğrudan karşılığa gitmek bu amaca daha iyi hizmet eder. Bu yüzden dil değiştirici, rota tablosundaki eşleşmeyi okumalı ve kullanıcıyı aynı konunun öbür dildeki adresine götürmelidir. Karşılığı henüz yayımlanmamış bir sayfada ise düğmeyi gizlemek, kırık ya da ilgisiz bir adrese göndermekten iyidir.

Kurgusal örnek: Türkçe bir rehber sayfasında dil düğmesi İngilizce ana sayfaya gidiyor. Okuyucu aynı rehberin İngilizcesini bulmak için menüde yeniden gezinmek zorunda kalıyor. Düğme rota tablosundaki karşılığa bağlandığında bu adım ortadan kalkar. Aynı mantık sitemap için de geçerlidir: her iki dilin adresleri ayrı girdiler olarak bulunur ve slug değiştiğinde ikisi birlikte güncellenir.

Rota tablosu: tek doğruluk kaynağı

Slug çevirisi arttıkça, hangi Türkçe adresin hangi İngilizce adresle eşleştiğini bir tabloda tutmak şarttır. Bu tablo çeviri ekibi, geliştirici ve SEO sorumlusu için ortak başvuru olur. Kurgusal örnek bir tablo şöyle olabilir:

Tablodaki ilk sütun dilden bağımsız bir konu kimliğidir. İki dilli içeriği tek bir kimlik altında tutmak, sonradan "bu sayfanın İngilizcesi hangisiydi" aramasını ortadan kaldırır. Ayrıca iki dilli içerik üretirken tek bir brief ile iki bağımsız metin yazmak istiyorsanız, süreç ayrıntıları çok dilli makale yazım siparişi yazısında anlatılıyor.

Eski Slug Değişince 301 ve İç Link Güncellemesi

Bir sayfanın slug'ını değiştirmek, aslında yeni bir adres açmak ve eski adresi yeni adrese bağlamaktır. Bu işin ciddi bir bedeli olabilir; bu yüzden önce değiştirmenin gerçekten gerekli olup olmadığını sormak gerekir.

Değiştirmeli miyim?

Aşağıdaki durumlarda değişiklik makuldür: slug yanlış yazılmışsa, sayfanın konusu tamamen değiştiyse, İngilizce ve Türkçe sürümlerde karışık dil kullanılmışsa ya da site genelinde yeni bir adres kuralı uygulanıyorsa. Yalnızca "bir kelime daha iyi olurdu" gerekçesiyle çalışan bir adresi değiştirmek çoğunlukla gereksiz risktir; kazanım belirsizken yönlendirme yönetimi kalıcı bir iş yükü ekler.

Kalıcı yönlendirme doğru araç

Google'ın yönlendirmeler belgesi (yeni sekmede açılır) kalıcı yönlendirmeler olarak HTTP 301 ve 308'i, sıfır saniyelik meta yenilemeyi ve JavaScript konum değişikliğini sayar. Belgeye göre kalıcı yönlendirme kanonik sinyal işlevi görür ve yönlendirmenin hedefi arama sonuçlarında gösterilir. Geçici yönlendirmeler (302, 303, 307) kanonik sinyali taşımaz; kaynak sayfa çoğunlukla sonuçlarda kalır. Yöntem tercihi şöyledir: sunucu tarafı yönlendirme en güvenilir olandır, meta yenileme yedek çözümdür, JavaScript ise yalnızca başka seçenek yoksa kullanılır, çünkü işleme başarısız olabilir ve Google yönlendirmeyi hiç göremeyebilir.

Belge, yönlendirmenin ne kadar süre tutulacağına dair bir süre vermez ve yönlendirme zincirlerini ele almaz. Bu iki konuda şu pratik yaklaşım genel bilgi olarak önerilir: yönlendirmeyi, eski adrese gelen bağlantıların önemini kaybettiği güne kadar değil, mümkün olduğunca uzun tutun ve her eski adresi yeni adrese tek adımda bağlayın. Bu bir editoryal tavsiyedir.

Dil çifti kuralları

İki dilli sitede yönlendirme yaparken dil sınırını koruyun:

• Eski Türkçe adres yeni Türkçe adrese, eski İngilizce adres yeni İngilizce adrese gitmelidir. Türkçe adresi İngilizce sayfaya yönlendirmek kullanıcıyı dil değiştirmeye zorlar.
• Her iki dilde de slug değişiyorsa iki yönlendirmeyi aynı yayında devreye alın; yarım bırakılan bir çift, hreflang karşılıklılığını bozar.
• Yönlendirme kaynağı ve hedefi ayrı ayrı sınayın; hedef sayfanın 200 döndürdüğünü doğrulayın.

Değişiklik sırası

Bir slug değişimi için izlenebilecek sıra şöyledir:

1. Rota tablosunda eski ve yeni adresi yazın; kaç iç bağlantının eski adrese gittiğini sayın.
2. Yeni adresi yayına alın ve sayfanın 200 döndürdüğünü doğrulayın.
3. Eski adresten yeni adrese kalıcı sunucu yönlendirmesi ekleyin.
4. Sitedeki iç bağlantıları, menüleri, breadcrumb'ları ve sitemap'i yeni adresle güncelleyin; yönlendirmeye güvenerek eski bağlantıyı bırakmayın, çünkü her iç bağlantı gereksiz bir ek istek üretir.
5. Hreflang işaretlemesindeki ve canonical etiketindeki adresi yeni adrese çevirin; karşı dil sayfasının işaretlemesini de güncelleyin.
6. Güncellemeden sonra tarama aracıyla eski adrese giden iç bağlantı kalmadığını kontrol edin.

Bu sıradaki dördüncü adım sık atlanır. Yönlendirme çalıştığı için sorun görünmez; ama iç bağlantıların eski adreste kalması, hem sayfa yükleme sırasını uzatır hem de sinyalleri dağıtır. İç bağlantıyı doğrudan yeni adrese vermek en temiz sonuçtur.

Kurgusal örnek: bir sitede "iletisim-bilgileri" slug'ı "iletisim" olarak sadeleştiriliyor. Türkçe sürümde yönlendirme eklendi ama İngilizce sürümde "contact-details" adresi unutuldu. Sonuçta hreflang'daki Türkçe adres yeni, İngilizce sayfanın karşılığı ise eski adresi gösteriyor. Bu tutarsızlığı yakalamak için rota tablosundaki durum sütunu işe yarar: iki satırın da "tamamlandı" olması gerekir.

Kontrol Listesi ve Yaygın Hatalar

Aşağıdaki liste, yeni bir iki dilli sayfa yayımlarken ya da mevcut slug'ları gözden geçirirken kullanılabilir.

Yayın öncesi kontrol listesi

1. Slug sayfanın o dildeki ana konusunu anlatıyor mu, ve küçük harf, tire ve ASCII kuralına uyuyor mu?
2. Karşı dil sürümünün adresi rota tablosuna yazıldı mı?
3. Hreflang işaretlemesi her iki sayfada da tam adresle, karşılıklı ve kendi kendine referanslı olarak eklendi mi?
4. Her sürümün canonical etiketi kendi dilindeki adresi gösteriyor mu?
5. Sitemap'te her iki adres de bulunuyor mu?
6. Dil değiştirme bağlantısı karşı dilin doğrudan karşılığına gidiyor mu, yoksa ana sayfaya mı?
7. Kullanıcı ya da bot, tarayıcı dili ya da IP'ye göre otomatik başka sürüme atılmıyor mu?
8. Başka bir sayfa adres değiştirdiyse eski adresten yeni adrese kalıcı yönlendirme var mı ve iç bağlantılar güncel mi?

Yaygın hatalar

• Yalnızca slug'ı çevirip hreflang'ı unutmak: Adres Türkçe olabilir ama arama motoruna iki sayfanın eşleştiği başka bir yolla bildirilmedikçe bu bağ kurulmaz.
• Dil klasörü yerine parametre kullanmak: Google belgesi URL parametrelerini coğrafi hedefleme için önermez.
• Otomatik dil yönlendirmesi: Kullanıcıların ve botların tüm sürümlere ulaşmasını engelleyebilir.
• Slug'ı yılla etiketlemek: İçerik güncellendiğinde adres eskir; sonra değiştirmek yönlendirme borcu doğurur.
• Karışık karakter politikası: Yarısı Türkçe karakterli, yarısı ASCII slug'lardan oluşan yapı, yönlendirme ve hreflang listelerinde hataya açıktır.
• Büyük harfli varyantları açık bırakmak: Google /APPLE ve /apple'ı ayrı sayar; sunucu ikisini de aynı sayfaya çözerse yinelenen adres oluşur.
• Yönlendirmeyi karşı dile yapmak: Türkçe eski adresi İngilizce yeni adrese bağlamak kullanıcıyı sürpriz bir dile taşır.
• İç bağlantıları eski adreste bırakmak: Yönlendirme çalışsa da gereksiz istek ve sinyal dağınıklığı yaratır.
• Yalnızca boilerplate'i çevirmek: Google'ın belgesi, ana içerik tek dilde kalırken yalnızca menü ve altbilgiyi çevirmenin kötü deneyim doğurabileceğini söyler. Adres çevrilmiş ama içerik çevrilmemişse sayfa yanlış bir vaat verir.

Çeviri ekibi için kısa not

Slug çevirisi bir metin işi gibi görünür ama bir yapı işidir. Çevirmenden adresi çevirmesini istiyorsanız, ona önce kuralı verin: küçük harf, tire, ASCII, üç ila beş kelime, yıl yok. Sonra çeviri çıktısını rota tablosuna yazdırın ve geliştiriciye teslim etmeden bir editörün onayından geçirin. Bu küçük disiplin, yayından sonra yönlendirme düzeltmek zorunda kalmanın çok önünde bir koruma sağlar.

Sıkça Sorulan Sorular

Slug'ı İngilizceye çevirmek Türkçe sitede sıralamayı artırır mı?

Bunu garanti eden bir belge yok. Google'ın URL yapısı belgesi, adreste hedef kitlenin dilindeki kelimelerin kullanılmasını ve gerekirse transliterasyonu önerir; sıralama vaadi vermez. Slug'ın işi sayfayı okunur ve tutarlı kılmaktır, sıralamayı tek başına taşımaz.

Türkçe karakterli slug kullanmak sorun çıkarır mı?

Google'a göre ASCII dışı karakterler yüzde kodlamayla yazılmalıdır; belgede gemüse sözcüğünün gem%C3%BCse biçiminde gösterilmesi buna örnektir. Karakterli adres mümkündür ama paylaşım, kopyalama ve günlük okuma sırasında kodlu görünüme dönebilir. Çoğu ekip bu yüzden karakterleri ASCII karşılığına çevirmeyi seçer.

TR ve EN sayfaları için hreflang yazmak yeterli mi, slug'ı da çevirmeli miyim?

İkisi farklı işler görür. Hreflang, iki adresin birbirinin dil karşılığı olduğunu bildirir; slug çevirisi ise okuyucuya adreste dilini tanıtır. Slug'ı çevirmeden hreflang kurabilirsiniz, ama çevirdiğiniz her çift için karşılıklı hreflang işaretlemesini de güncel tutmanız gerekir.

Slug değişince eski adres için hangi yönlendirme kullanılır?

Değişiklik kalıcıysa sunucu tarafında 301 ya da 308 gibi kalıcı bir yönlendirme kullanın. Google'ın belgesine göre kalıcı yönlendirme kanonik sinyali taşır ve hedef adres sonuçlarda gösterilir. JavaScript yönlendirmesi son çare olarak sayılır, çünkü işleme başarısız olabilir.

Kullanıcıyı tarayıcı diline göre otomatik EN sayfasına yönlendirmek doğru mu?

Google'ın çok bölgeli site belgesi, kullanıcıyı varsayılan dil ya da konuma göre otomatik yönlendirmekten kaçınmayı söyler; çünkü bu, kullanıcıların ve arama motorlarının tüm sürümlere ulaşmasını engelleyebilir. Bunun yerine dil sürümüne giden görünür bir bağlantı verin.

Sonuç

Yerelleştirilmiş slug, doğru uygulandığında okunur ve tutarlı bir adres düzeni sağlar; ama tek başına sıralama vaat etmez ve hreflang'ın yerini almaz. Üç şeyi birlikte tutmak gerekir: hedef dilde kısa, küçük harfli, tire ayraçlı bir slug; dil sürümlerini birbirine bağlayan karşılıklı ve tam adresli işaretleme; ve adres değiştiğinde kalıcı yönlendirme ile güncellenmiş iç bağlantılar. Belgenin söylemediği yerlerde, örneğin yönlendirme süresi ve zincirleri konusunda, genel bilgi ile editoryal tercihi birbirinden ayırın.

İki dilli bir sitede bu kuralları içeriğe de taşımak istiyorsanız, Akua Adforce'ta SEO içerik yazımı hizmetini inceleyebilirsiniz; kapsam ve koşullar ilgili ürün sayfasında yazılıdır. Bu yazıdaki öneriler genel teknik rehberdir ve belirli bir sıralama, tarama ya da dizinleme sonucu garanti etmez.