SEO uyumlu URL yapısı nasıl olmalı?

SEO uyumlu bir URL kısa, okunur, küçük harfli, kelimeleri tireyle ayıran ve sayfanın konusunu açıkça anlatan bir adrestir. Bir kez yayına alındıktan sonra mümkün olduğunca değişmemelidir. Google URL'yi sıralama için küçük bir sinyal olarak kullanır; asıl önemi, kullanıcıya güven vermesi, taramayı kolaylaştırması ve yıllarca aynı kalabilmesidir.

URL konusunda en sık yapılan iki hata birbirinin tersidir. Bir yanda, kimsenin okuyamadığı parametreli ve rakamlı adresler; öbür yanda, “mükemmel URL” arayışıyla yayındaki çalışan adreslerin topluca değiştirilmesi. İkincisi çoğu zaman birincisinden daha pahalıya patlar. Bu yazıda yeni bir site veya yeni bir sayfa için hangi kuralların işe yaradığını, hangilerinin gereksiz titizlik olduğunu ve mevcut bir URL'ye ne zaman dokunmamak gerektiğini sırayla ele alıyoruz.

SEO açısından iyi bir URL hangi özelliklere sahip olmalıdır?

İyi bir URL sayfanın içeriğini bir bakışta anlatır, çok uzun değildir, rastgele rakam ve sembol içermez ve zaman içinde değişmeyecek şekilde seçilir. Ziyaretçi adresi okuyunca nereye geleceğini tahmin edebiliyorsa, arama motoru da sayfanın konusunu buradan destekleyici bir ipucu olarak alabiliyorsa URL işini yapmış demektir.

Pratikte bir URL'yi şu sorularla değerlendirebilirsiniz: Bu adresi telefonda birine okusam anlaşılır mı? Sayfanın başlığıyla çelişiyor mu? İki yıl sonra hâlâ doğru olur mu? Bu üç sorunun cevabı olumluysa teknik ayrıntıların çoğu zaten yerine oturur.

• —Okunur: gerçek kelimelerden oluşur, “?id=4821” gibi anlamsız parçalar taşımaz.
• —Kısa ama açıklayıcı: konuyu anlatan birkaç kelime yeter; başlığın tamamını URL'ye taşımak gerekmez.
• —Küçük harf ve tire: kelimeler tireyle ayrılır, büyük harf ve alt çizgiden kaçınılır.
• —Kalıcı: yılı, kampanya adını, fiyatı veya geçici bir durumu içermez.
• —Tutarlı: sitenin her yerinde aynı kalıp kullanılır; bir bölümde /hizmetler/, diğerinde /services/ gibi karışıklık olmaz.
• —Tek sürüm: aynı sayfaya hem sonunda eğik çizgi olan hem olmayan, hem www'li hem www'siz adreslerle ulaşılamaz.

URL'de neden küçük harf ve tire kullanılmalıdır?

URL'de küçük harf ve tire kullanılır, çünkü Google tireyi kelime ayırıcı olarak açıkça önerir, alt çizgiyi ise kelimeleri birleştiren bir karakter gibi ele alabilir. Büyük harf ise sunucuya bağlı olarak aynı sayfanın iki ayrı adresi gibi davranabilir ve yinelenen içerik sorunu doğurabilir.

Pek çok sunucuda /Hizmetler ile /hizmetler iki ayrı adres sayılabilir. Siz ikisini de aynı sayfaya çıkaracak şekilde kurmuş olsanız bile, başka bir site size büyük harfli sürümle link verebilir ve iki adres birlikte indekslenmeye çalışılabilir. Bunun en sağlam çözümü, tüm adresleri küçük harfle üretmek ve büyük harfli gelen istekleri küçük harfli sürüme 301 ile yönlendirmektir. Canonical etiketi de bu noktada ikinci bir güvence olarak işe yarar.

• —web-tasarim-fiyatlari doğru; web_tasarim_fiyatlari yerine tire tercih edilir.
• —web-tasarim-fiyatlari doğru; Web-Tasarim-Fiyatlari büyük harf nedeniyle risklidir.
• —Boşluk ve özel karakter (%20, &, +, parantez) URL'ye sokulmaz.
• —Kelime sayısı çoğunlukla üç ile beş arasında tutulur; uzun cümleler URL'yi okunmaz hâle getirir.

Türkçe karakterli URL mi, ASCII URL mi tercih edilmeli?

Çoğu durumda URL'yi Türkçe karakterlerden arındırıp ASCII yazmak daha güvenli bir tercihtir: ş yerine s, ı yerine i, ğ yerine g, ö yerine o, ü yerine u, ç yerine c. Google Türkçe karakterli URL'leri işleyebilir, ancak bu karakterler paylaşım sırasında kodlanır ve adres uzayıp bozulabilir.

Türkçe karakterli bir URL tarayıcının adres çubuğunda düzgün görünebilir; ama WhatsApp'a, e-postaya veya bir forum gönderisine yapıştırıldığında “%C5%9F” gibi yüzde kodlarına dönüşebilir. Bazı e-posta istemcileri veya eski sistemler bu uzun adresi satır sonunda keser ve bağlantı çalışmaz. ASCII adreslerde bu risk yoktur. Ayrıca raporlama araçlarında, log dosyalarında ve spreadsheet'lerde ASCII adresleri okumak ve karşılaştırmak çok daha kolaydır.

Karar verirken şu çerçeve işe yarar: Yeni kuruluyorsanız ve ekibiniz tutarlılığı koruyabilecekse ASCII seçin. Zaten Türkçe karakterli URL'leriniz varsa ve bunlar iyi çalışıyorsa, yalnızca “daha doğru olur” diye topluca dönüştürmeyin; çünkü her dönüşüm bir yönlendirme ve bir risktir. En önemlisi, bu kararı bir kez verip her yerde aynı uygulamaktır. Aynı sitede bir sayfa “hizmetlerimiz”, bir diğeri “hizmetlerımız” gibi karışık yazılmışsa kullanıcı da arama motoru da yanlış adrese gelebilir.

• —Yeni site: URL'leri ASCII ve küçük harf olarak standartlaştırın, başlıkta ve içerikte Türkçe karakterleri normal şekilde kullanın.
• —Mevcut site, sorunsuz çalışan Türkçe karakterli URL'ler: gerekçesiz toplu değişiklik yapmayın.
• —Mevcut site, kodlama hataları veya kırık bağlantı varsa: ilgili adresleri ASCII karşılığına taşıyın ve 301 yönlendirmesi ekleyin.
• —Slug üreten sistemde (CMS) Türkçe karakter dönüşüm kuralını test edin; ı/İ harfinde sık hata çıkar.

URL'de klasör derinliği ne kadar olmalıdır?

Klasör derinliği, sitenin gerçek hiyerarşisini yansıtacak kadar olmalı, ama gereksiz yere uzatılmamalıdır. Çoğu kurumsal site için bir veya iki seviye yeterlidir. Derinlik tek başına bir sıralama etkeni değildir; asıl mesele, önemli sayfaların ana sayfadan birkaç tıklamayla ulaşılabilir ve iç linklerle desteklenmiş olmasıdır.

Birçok kişi “URL ne kadar kısaysa o kadar iyi” der ve bütün sayfaları kök dizine koyar. Küçük bir sitede bu işe yarar; ancak yüzlerce sayfası olan bir sitede mantıklı bir klasör yapısı hem sizin içerik yönetiminizi hem de raporlamayı kolaylaştırır. Örneğin /blog/ altındaki tüm yazılar tek bir kalıpta toplandığında Search Console'da blog performansını ayrı izleyebilirsiniz. Öte yandan /hizmetler/web-tasarim/kocaeli/gebze/kurumsal-site gibi dört beş seviyeli adresler hem okunmaz hem de sitenizin içeriği o kadar derin olmadığı için yapay görünür.

• —Ana hizmet ve para sayfaları: mümkün olduğunca kök dizine yakın, kısa adreslerle.
• —Blog yazıları: tek bir önek altında (örneğin /blog/yazi-adi) toplanır.
• —Kategori klasörü: yalnızca gerçekten kalıcı ve birkaç sayfayı kapsayan bir yapı varsa eklenir.
• —Derinlik sınırı: üç seviyeyi geçen adresleri gözden geçirin; çoğu zaman bir seviye gereksizdir.
• —Hiyerarşi ve iç link: URL'deki yapı, sitedeki menü ve breadcrumb yapısıyla uyumlu olmalıdır.

URL'de tarih, ID veya sayı kullanmak doğru mudur?

Çoğu içerik için URL'de tarih ve rastgele ID kullanmamak daha doğrudur. Tarih, içerik güncellendiğinde adresin eskimiş görünmesine yol açar; ID ise ziyaretçiye ve arama motoruna konu hakkında bir şey söylemez. Haber gibi zamana bağlı içerikte tarih anlamlı olabilir, ama kalıcı rehber içeriklerde sorun yaratır.

Örneğin /blog/2023/05/seo-rehberi adresindeki yazıyı 2026'da güncellediğinizde adres hâlâ 2023 der. Kullanıcı bunu eski bir içerik olarak algılayabilir; adresi güncellemek istediğinizde ise yönlendirme gerektirir. Aynı yazı /blog/seo-rehberi olsaydı, içerik defalarca güncellense de URL aynı kalırdı. ID'li adreslerde de benzer bir sorun vardır: /urun/4821 yerine /urun/ahsap-calisma-masasi gibi adres, hem okunurluk hem de paylaşım güveni açısından daha iyidir.

Dikkat edilecek istisna: e-ticaret veya içerik yönetim sisteminiz ID'yi zorunlu kılıyorsa, ID'yi kelimeyle birlikte tutan bir yapı seçilebilir; örneğin /urun/ahsap-calisma-masasi-4821. Bu durumda kelime kısmı değişse bile ID'ye göre doğru sayfaya yönlendirme yapılabilir. Yine de mümkünse kelime tabanlı adres tercih edilmelidir.

URL parametreleri SEO'yu nasıl etkiler?

Parametreli URL'ler (?sirala=fiyat&renk=siyah gibi) aynı içeriği çok sayıda farklı adresle sunabilir; bu da tarama bütçesini boşa harcar ve yinelenen içerik riskini artırır. Filtre ve sıralama parametreleri için canonical, uygun robots kuralları ve dikkatli iç linkleme gerekir. İçeriği gerçekten değiştiren sayfalama ise ayrı yönetilmelidir.

Parametreleri üç gruba ayırmak işi kolaylaştırır. İlk grup içeriği belirleyen parametrelerdir (ürün kategorisi gibi); mümkünse bunları yola taşıyın. İkinci grup sıralama ve filtre parametreleridir; bunlar çoğu zaman ayrı bir sayfa olarak indekslenmesi gerekmeyen varyasyonlardır. Üçüncü grup izleme parametreleridir (utm_ gibi); bunlar canonical ile asıl sayfaya işaret etmelidir ve sitenin kendi iç linklerinde kullanılmamalıdır.

• —Kategori ve ürün sayfaları gibi kalıcı içerik için parametre değil, okunur yol kullanın.
• —Sıralama ve filtre varyasyonlarının kendi canonical'ı olsun; asıl sayfaya işaret etsin.
• —İç linklerde utm_ gibi izleme parametrelerini kullanmayın; raporlamayı bozar.
• —Sonsuz kombinasyon üreten filtreleri robots.txt veya meta robots ile kontrol altına alın, ama önemli sayfaları yanlışlıkla engellemeyin.
• —Search Console'daki “Sayfalar” raporunda parametreli adreslerin indekslenip indekslenmediğini düzenli kontrol edin.

Çok dilli sitelerde dil klasörleri nasıl kurulmalıdır?

Çok dilli sitelerde en sağlam yöntem, her dil için ayrı bir klasör kullanmaktır: Türkçe kök dizinde, İngilizce /en/ altında gibi. Dil, URL'den okunabilmeli ve her sayfa karşılığıyla hreflang aracılığıyla eşlenmelidir. Dili çerezle, IP'yle veya tarayıcı ayarıyla değiştirip aynı adreste farklı içerik göstermek, tarayıcılar için sorun yaratır.

Örnek: /web-tasarim-fiyatlari/ Türkçe sürüm, /en/web-design-pricing/ İngilizce sürüm olabilir. İngilizce adreste de İngilizce kelimeler kullanılması hem kullanıcıya hem arama motoruna dili belli eder. Her iki sürüm birbirini hreflang ile göstermeli ve her biri kendi canonical'ına sahip olmalıdır. Aksi hâlde Google iki sürümü birbirinin kopyası sanabilir.

Blog ve kategori yapısı URL'de nasıl kurgulanmalıdır?

Blog için en sade yapı /blog/yazi-adi biçimidir. Kategori adını URL'ye eklemek yalnızca kategoriler kalıcı olduğunda anlamlıdır; çünkü bir yazının kategorisi değişirse adresi de değişmek zorunda kalır. Çoğu site için tek bir /blog/ öneki ve yazı başına sabit bir slug en az sorun çıkaran çözümdür.

Kategori sayfalarının kendisi ise (örneğin /blog/kategori/seo/) faydalı olabilir; çünkü ilgili yazıları bir arada toplar ve iç link yapısını güçlendirir. Bunun için her yazının adresine kategori eklemek gerekmez. Kategori sayfalarının da özgün giriş metni ve düzgün başlığı olmalı; yalnızca yazı listesinden ibaret ince sayfalar değer katmaz. Etiket (tag) sayfaları ise genellikle az sayıda yazı içerdiğinden ve kategori sayfalarıyla çakıştığından indekslenmemelidir ya da hiç açılmamalıdır.

• —Blog yazısı: /blog/yazi-adi gibi tek seviyeli ve sabit.
• —Kategori arşivi: indekslenebilir, özgün giriş metni olan ayrı bir sayfa.
• —Etiket ve yazar arşivleri: çoğu zaman noindex veya kapalı tutulur.
• —Sayfalama: /blog/sayfa/2/ gibi tutarlı bir kalıp; her sayfanın kendi canonical'ı olur.
• —Yazı yeniden kategorilenirse adres değişmez; yalnızca iç linkler ve kategori sayfası güncellenir.

URL neden değişmemeli, değiştirmek gerektiğinde ne yapılmalı?

Bir URL değiştiğinde eski adres ona gelen bağlantıları, indeksteki yerini ve kullanıcıların yer imlerini kaybeder. Bu yüzden URL'ler mümkün olduğunca kalıcı tutulmalıdır. Değişiklik kaçınılmazsa eski adresten yenisine bire bir 301 yönlendirmesi kurulmalı, iç linkler, sitemap ve canonical güncellenmelidir.

Yönlendirme doğru kurulduğunda Google eski adresin sinyallerini yeni adrese taşıyabilir; ama bu süreçte geçici dalgalanma görülebilir ve yönlendirme ilişkisinin tamamen oturması zaman alır. Yönlendirme zincirleri (A'dan B'ye, B'den C'ye) gereksiz gecikme ve kayıp riski yaratır; eski adresi doğrudan son adrese yönlendirmek en temizidir. Yönlendirmeyi hiç eklemezseniz eski adres 404 verir ve oradan gelen değer boşa gider.

• —Değişiklik gerekçesi yazılı olsun: “daha güzel durur” bir gerekçe değildir; “aynı sayfaya iki adres var” veya “URL yanlış bilgi veriyor” gerekçedir.
• —Eski ve yeni adreslerin eşleme tablosunu çıkarın.
• —301 yönlendirmesini sayfa yayına çıkmadan önce test edin.
• —İç linkleri, sitemap'i ve canonical etiketlerini yeni adrese çevirin; yönlendirmeye güvenip eski iç linkleri bırakmayın.
• —Değişiklikten sonra haftalarca Search Console'da indeksleme ve tarama hatalarını izleyin.

Mevcut URL'leri değiştirmek ne zaman riskli, ne zaman gereklidir?

Sorunsuz çalışan ve trafik alan URL'leri yalnızca estetik nedenlerle değiştirmek genellikle riskli ve gereksizdir. URL'yi değiştirmek ancak mevcut yapı gerçek bir sorun yaratıyorsa, örneğin yinelenen adresler, yanlış bilgi, kırık kodlama veya yönetilemeyen parametreler varsa anlamlıdır. Her değişiklik geçici bir dalgalanma riski taşır.

Karar vermeden önce şu soruyu sorun: Bu değişiklik ölçülebilir bir sorunu çözüyor mu? Çözüyorsa, etkilenen sayfaların trafiğini ve linklerini çıkarın, değişikliği aşamalı yapın ve her aşamada ölçün. Çözmüyorsa mevcut adresi koruyup yeni içeriklerde doğru kalıbı uygulamak çok daha az riskli bir yoldur. Yani ideal bir kuralı eski sayfalara geriye dönük uygulamak zorunda değilsiniz; yeni sayfalarda kuralı uygulamak ve eskileri yalnızca gerçekten bozuk olanlarda düzeltmek çoğu site için en mantıklı yaklaşımdır.

• —Değiştirmeye değer: aynı sayfaya birden fazla adres, kodlama hatası içeren adresler, kontrolsüz parametre çoğalması, yanlış bilgi veren adresler.
• —Dokunmamak daha iyi: sorunsuz çalışan, trafik alan, link almış, yalnızca “biraz uzun” olan adresler.
• —Büyük taşımalarda (domain veya CMS değişikliği): URL değişikliğini tasarım değişikliğiyle aynı anda yapmak yerine mümkünse ayrı aşamalara bölün.

İyi ve kötü URL örnekleri nasıl karşılaştırılır?

İyi ve kötü URL'yi ayıran şey, adresin okunur, kısa, kalıcı ve tutarlı olup olmadığıdır. Aşağıdaki karşılaştırma mantığı, kendi sitenizdeki adresleri bir tablo gibi değerlendirmek için kullanılabilir: sol tarafta tipik hatalı kalıp, sağ tarafta önerilen düzen ve nedeni.

• —Hatalı: /index.php?id=482&cat=3 — Önerilen: /web-tasarim-fiyatlari — Neden: okunur, kalıcı, parametresiz.
• —Hatalı: /Blog/SEO_Rehberi_2023 — Önerilen: /blog/seo-rehberi — Neden: küçük harf, tire, yıl yok.
• —Hatalı: /blog/2023/05/12/seo-rehberi — Önerilen: /blog/seo-rehberi — Neden: tarih eskir, adres gereksiz uzar.
• —Hatalı: /hizmetler/web/tasarim/kocaeli/kurumsal — Önerilen: /kocaeli-web-tasarim — Neden: derinlik sığ, ana kelime net.
• —Hatalı: /urun/4821 — Önerilen: /urun/ahsap-calisma-masasi — Neden: konu adrese yansır.
• —Hatalı: /kurumsal-web-sitesi-yaptirmak-isteyen-firmalar-icin-rehber — Önerilen: /kurumsal-web-sitesi-rehberi — Neden: gereksiz uzun, ana konu kaybolur.
• —Hatalı: /Şirketimiz/Hakkımızda — Önerilen: /hakkimizda — Neden: ASCII, tek seviye, küçük harf.

Bu örnekleri bir kontrol listesi gibi kullanabilirsiniz. Sitenizdeki en çok trafik alan 20 sayfayı bir tabloya yazın ve her adres için “okunur mu, kısa mı, kalıcı mı, tutarlı mı?” sorularını işaretleyin. Büyük bir yeniden yazım yerine, yalnızca gerçekten sorun çıkaran birkaç adresi düzeltmek çoğu zaman yeterlidir.

URL yapısı için uygulama kontrol listesi nedir?

URL kontrol listesi beş adımdan oluşur: kurallarınızı yazıya dökün, yeni sayfalarda uygulayın, mevcut adresleri denetleyin, yalnızca gerçekten bozuk olanları 301 ile düzeltin ve değişiklikleri Search Console ile izleyin. Böylece URL yapısı bir kez karar verilen ve ekip içinde paylaşılan bir standart hâline gelir.

• —Standart: küçük harf, tire, ASCII (kararınızsa), kısa, kalıcı, tek seviyeli ana sayfalar.
• —Sürüm tekliği: www/www'siz, http/https ve eğik çizgi varyasyonları tek sürüme 301 verir.
• —Dil klasörleri: Türkçe kök, İngilizce /en/; hreflang ve canonical karşılıklı doğru.
• —Parametreler: filtre ve izleme parametrelerinin canonical ve iç link politikası belirlenmiş.
• —Eşleme: değişen her URL için eski-yeni tablosu ve 301 hazır.
• —Sitemap: yalnızca indekslenmesini istediğiniz, canonical, 200 dönen adresleri içerir.
• —İzleme: değişiklik sonrası Search Console'da kapsam ve tarama hataları haftalık kontrol edilir.