URL yapısı nasıl kurulmalı

URL yapısı iki ayrı durumda karar gerektirir: sıfırdan kurulan bir sayfanın adresini seçerken ve mevcut bir sayfanın adresini değiştirmeyi düşünürken. Birincisi risksizdir, çünkü doğru fırsat bir kere gelir ve bedeli yoktur. İkincisi risklidir, çünkü Google’ın kendi dokümantasyonu ve John Mueller’ın tarihli açıklamaları URL değiştirmenin en iyi senaryoda bile bir kazanç değil, geçici düşüş ve en az bir yıllık sinyal aktarım süreci olduğunu söylüyor. Biçim kuralları (kelime ayırma, karakter, parametre) her iki durumda da aynıdır; karar farkı, mevcut bir URL’yi değiştirmenin maliyetini göze almaya değip değmeyeceğidir. Aşağıda önce iyi/kötü URL’yi ayıran somut ölçütler, sonra URL uzunluğu ve anahtar kelime hakkındaki yaygın varsayımın dürüst cevabı, sonra da değiştirme kararının karar tablosu ve ilk kurulumun dört adımı sırayla ele alınıyor.

İyi bir URL yapısı neyi sağlar, kötü bir URL yapısı nasıl görünür

İyi bir URL okunabilir bir kelime taşır; kötü bir URL bir kimlik numarası veya parametre yığınıdır. Google Search Central’ın URL yapısı sayfası tam bu ayrımı kendi örneğiyle veriyor: .../wiki/Aviation gibi bir URL insan için anlamlıdır, index.php?topic=42&area=3a5ebc944f1daa6f gibi bir URL ise hem insana hem makineye hiçbir şey söylemez (K-152).

Bu ayrım beş somut ölçütte tablo haline gelir.

Ölçüt	İyi	Kötü
Anahtar kelime varlığı	/blog/url-yapisi-nasil-kurulmali/	/blog/makale-id-4471/
Kelime ayırma	/seo-denetimi-nasil-yapilir/	/seo_denetimi_nasil_yapilir/
Büyük/küçük harf tutarlılığı	/urun/kirmizi-tisort/	/Urun/Kirmizi-Tisort/
Gereksiz parametre	/urunler/ayakkabi/	/urunler/ayakkabi/?ref=anasayfa&session=a8f3c71b
Anlam yoğunluğu (rastgele karakter yığını)	/blog/url-yapisi-nasil-kurulmali/	index.php?topic=42&area=3a5ebc944f1daa6f

Son satır URL’nin kaç karakter olduğunu değil, taşıdığı bilgiyi ölçüyor. URL’nin toplam uzunluğunun kendisinin sıralamayla ilgisi yoktur; bu ayrı bir sorudur ve dürüst cevabı aşağıda yer alıyor.

TR SERP’te bu beş ölçütü bir arada veren bir kaynak taranmadı. Cenuta.com, ihs.com.tr ve timsahajans.com.tr’de doğrudan WebFetch ile yapılan taramada (5 Ekim 2026) üçü de dağınık iyi/kötü örnek veriyor ama sistematik bir tablo yok; üçünde de Google’ın resmi kaynağına link bulunmuyor. Altı ek TR kaynağın (seoegitim.com, befagency.com, juniortoexpert.com, orbita.com.tr, blog.vps.com.tr, gezginajans.com) WebSearch taramasında da aynı eksiklik tekrarlandı: hepsi “kısa, tire, küçük harf, anahtar kelime” dört maddesini kaynaksız aktarıyor.

Kelimeler nasıl ayrılır, hangi karakterler URL’ye hiç girmez

Kelime ayırmak için tire kullanılır, alt çizgi kullanılmaz; bu bir öneridir. Reserved karakterleri percent-encode etmek ise bir zorunluluktur. Google bu iki katmanı ayrı ayrı yazıyor: “We recommend using hyphens (-) instead of underscores (_) in your URLs” önerisi bir tavsiyedir, çünkü arama motorları tireyi kelime ayracı olarak okur, alt çizgiyi okumaz (K-152).

Zorunlu katman farklıdır. Reserved karakterler (boşluk, ?, #, & gibi) IETF STD 66 standardına göre percent-encode edilmelidir; aksi halde Google URL’yi güvenilir biçimde ayrıştıramaz. Büyük/küçük harf tutarlılığı da teknik bir zorunluluktur, öneri değildir: “URLs are case sensitive” (K-152), yani /Apple ve /apple Google için iki farklı URL’dir. Bir sitede aynı sayfaya hem büyük hem küçük harfli adresten erişilebiliyorsa, bu tek sayfa iki ayrı URL olarak indekslenebilir.

Üçüncü bir sınır fragment (#) ile ilgilidir. Google, sayfa içeriğini değiştirmek için fragment kullanılmasını desteklemiyor (“Don’t use fragments to change the content of a page, as Google Search generally doesn’t support URL fragments”, K-152). Bir sekme veya filtre durumu URL’de görünmesi gerekiyorsa path segmenti veya query parametresi kullanılır, fragment kullanılmaz.

Tire kullanmamak bir hata değildir, Google’ın önerisine uymamaktır; sonucu okunabilirlik kaybıdır. Percent-encoding’i atlamak ise teknik bir hatadır; sonucu Google’ın URL’yi hiç doğru işleyememesidir. Bu iki katman karıştırıldığında, ekip zorunlu bir düzeltmeyi “istersek yaparız” tercihi gibi ele alabilir.

URL uzunluğu ve içindeki anahtar kelime sıralamayı gerçekten etkiler mi

Hayır. URL uzunluğu bir sıralama faktörü değildir. John Mueller, 4 Şubat 2020’de bir CMS’in otomatik ürettiği uzun URL’ler hakkındaki soruya Twitter’da şöyle yanıt verdi: “We use URLs as identifiers; it doesn’t matter how long they are.” (K-156). Google URL’yi bir kimlik olarak kullanıyor, metrik olarak değil.

Mueller bir nüansı da ekledi: uzunluk yalnızca canonicalization kararında, yani iki URL’den hangisinin temsilci sayılacağına karar verirken (örneğin /home/ ile /home/index.html arasında), hafif bir sinyal olabiliyor. Bunun sıralamayla hiçbir ilgisi yok; biri hangi adresin “kanonik” sayılacağını belirlerken kullanılan ikincil bir ipucu, diğeri sayfanın arama sonucundaki konumu. İkisi ayrı sorulardır.

Anahtar kelime içeren bir URL’nin okunabilirlik veya tıklama tercihi sağlayabileceği makul bir çıkarımdır; ama bunun doğrudan bir sıralama faktörü olduğuna dair kaynaklı bir Google ifadesi bankada yok. Bu cümle bir gözlem değil bir çıkarımdır ve olgu gibi yazılmaz.

Sektörde yaygın olan “kısa URL daha iyi sıralanır” varsayımı bu açıklamayla doğrudan çürütülüyor. TR taramasında (cenuta.com, ihs.com.tr, timsahajans.com.tr ve altı aggregate kaynak, 5 Ekim 2026) hiçbir kaynak bu çürütmeyi yazmıyor; tam tersine hepsi dolaylı olarak kısalığı bir avantaj gibi sunuyor.

Filtre, sıralama ve oturum parametreleri olan URL’ler nasıl kurulmalı

Parametreli URL’lerde biçim ?key=value’dur; aynı anahtarı tekrarlamak yerine değerler virgülle birleştirilir. Google’ın e-ticaret URL yapısı rehberi bunu örnekle veriyor: ?type=candy,sweet doğru, ?type=candy&type=sweet yanlış (K-153). Bu kural e-ticaret dışındaki kategori ve filtre URL’leri için de geçerlidir.

Geçici veya oturuma özel parametreler iç linklerde hiç kullanılmamalı. Google’ın kendi ifadesi: “Avoid internally linking to temporary parameters, such as session-IDs, tracking codes, user-relative values” (K-153). ?session=a8f3c71b gibi bir adres bir ziyaretçi için anlamlıdır ama arama motoru için yüzlerce ayrı, boş URL üretir.

Ürün veya içerik varyantları iki yoldan tanımlanabilir: path segmenti (/t-shirt/green) veya query parametresi (/t-shirt?color=green). Parametre kullanılıyorsa Google’ın kuralı açık: “If you use optional query parameters to identify variants, use the URL with the query parameter omitted as the canonical URL” (K-153). Yani /t-shirt?color=green varsa, canonical etiketi /t-shirt’e işaret etmelidir. Bu kuralın sessizce ihlal edildiği, kanonik etiketin fark edilmeden yanlış bir URL’ye işaret etmesiyle aynı hata ailesindendir; Google kanonik seçimini tek bir sinyale değil 301, rel=canonical ve sitemap’in birlikte oluşturduğu sinyal setine dayandırır, bu sinyallerin birbiriyle çelişmesi sessiz bir hatadır.

Parametre yönetimi için elle bir araca güvenme seçeneği artık yok. Google Search Console’un URL Parametreleri aracı 26 Nisan 2022’de tamamen kapatıldı; gerekçe, Google’ın sistemlerinin hangi parametrelerin faydalı olduğunu kendiliğinden tahmin edebilmesi ve aracın yapılandırmalarının yalnızca yaklaşık %1’inin gerçekten kullanışlı olmasıydı (K-99). Bugün elle parametre yapılandırması yerine öncelik, URL’yi en baştan temiz tasarlamak ve gerektiğinde canonical etiketiyle yönlendirmektir.

Mevcut bir URL’yi değiştirmenin maliyeti nedir

Maliyet var ve küçük değil; en iyi senaryoda bile bir kazanç yok, yalnızca eski duruma geri dönüş var. John Mueller, 16 Ağustos 2018’de bir webmasterin uluslararası URL yapısını değiştirme sorusuna Reddit’te şöyle yanıt verdi: “I’d avoid changing URLs unless you have a really good reason to do so, and you’re sure that they’ll remain like that in the long run.” (K-154). “Gerçek bir sebep” ifadesi kilit noktadır; estetik veya kısalık tercihi tek başına yeterli sayılmıyor.

Mueller bunu 26 Ekim 2022’de Twitter’da daha açık bir cümleyle tekrarladı: “Tweaking URLs on their own results in temporary drops, technical nightmares, and if you’re lucky, it’ll end up in the same place.” (K-155). “İyi ihtimalle eski yerinize dönersiniz” cümlesi önemli; URL değiştirmek bir yükseliş vaadi değil, en iyi durumda nötr bir sonuçtur.

Google’ın resmi site taşıma rehberi de aynı uyarıyı dokümantasyon diliyle veriyor: “With any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site… This is normal.” Süre için somut bir ölçek veriyor: “a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer.” (K-157).

Bu dalgalanmanın altında yatan neden anlıktan uzaktır. Aynı rehber, yönlendirmelerin “generally at least 1 year” canlı tutulmasını öneriyor, çünkü “this timeframe allows Google to transfer all signals to the new URLs” (K-138). URL değiştirme kararının asıl riski sinyalin kaybolması değil, ne kadar sürede ve hangi koşulda aktarılacağının belirsizliğidir; 301 yönlendirmesinin sinyali ne kadar sürede ve hangi koşulda taşıdığı, yönlendirme zincirinin bu süreci nasıl zayıflattığıyla birlikte ayrı bir mekanizma sorusudur. URL değiştirme kararı tek seferlik bir işlem değildir; en az bir yıl sürecek bir sinyal aktarım sürecini başlatma kararıdır ve maliyetin bir parçası da bu süredir.

URL değiştirmek gerçekten gerekiyorsa hangi adımlar izlenir

Gerçek bir sebep varsa değiştirin; estetik tercih veya trend varsa değiştirmeyin. Aşağıdaki karar tablosu bu ayrımı somutlaştırıyor.

Sebep	Karar
Dil veya marka değişikliği	Değiştir
Yapı yanlış veya kırık (örneğin kategori hiyerarşisi tamamen bozuk)	Değiştir
Platform taşıma (CMS değişimi)	Değiştir
Estetik veya kısalık tercihi	Değiştirme
Sektördeki bir trende uyma isteği	Değiştirme
“Daha SEO dostu görünsün” hissi, somut bir kusur olmadan	Değiştirme

Değiştirmeye karar verildiğinde sıra önemlidir.

1. Tüm eski URL’lerin envanterini çıkarın; her biri için birebir eşleşen yeni bir URL belirleyin.
2. Her eski URL’yi doğrudan nihai hedefe 301 ile yönlendirin, zincir oluşturmayın. Google zincirde 10 sekmeye kadar takip ediyor ama kendi tavsiyesi zinciri 3’ün altında, kesinlikle 5’in altında tutmaktır (K-138).
3. Sitemap ve canonical etiketlerini yeni URL’lere güncelleyin; eski adresler hem sitemap’te hem canonical etikette kalırsa Google’a çelişen sinyal gönderilir.
4. Yönlendirmeyi en az bir yıl canlı tutun, kaldırma tarihini takvime not düşün (K-138).
5. Değişiklik sonrası Search Console’un Sayfa Dizine Ekleme raporunu eski ve yeni URL’ler için ayrı ayrı kontrol edin. Eski URL’lerin “Page with redirect” kategorisine düştüğünü, yeni URL’lerin “Page is indexed” durumuna geçtiğini doğrulayın (K-151). Orta boy bir sitede bu geçişin tamamlanması Google’a göre birkaç hafta sürer (K-157); bu pencere boyunca sıralamada görülen dalgalanma normaldir. Pencere kapandıktan sonra hâlâ düşüş varsa, sorun büyük olasılıkla yönlendirme kurulumunda teknik bir hatadır, beklenen bir sinyal kaybı değildir.

Bu beş adım dil değişikliği, marka değişikliği veya platform taşıma senaryolarının hepsinde aynı şekilde işler; değişen yalnızca envanterin büyüklüğü ve yeni URL eşleştirme kuralıdır, sıra aynı kalır.

Yeni bir sayfa için URL ilk kurulumda nasıl planlanır

Bir URL’yi ilk seferde doğru kurmak, yukarıdaki maliyetten tamamen kaçınmanın tek yoludur. Yeni bir sayfa için dört adım yeterlidir.

1. Sayfanın ana varlığını veya ana sorgusunu belirleyin. URL bu varlığı taşımalı, sayfanın tüm içeriğini özetlemeye çalışmamalı.
2. 3-5 kelimelik, tire ile ayrılmış, küçük harf bir slug yazın; “ve”, “ile”, “bir” gibi durma kelimelerini çıkarın (K-152).
3. Dizin derinliğini, yani URL’nin kaç kategori seviyesi taşıdığını, ilke olarak 1-2 seviyede tutun; kategori hiyerarşisinin kendisi site mimarisine bağlı, ayrı bir karar konusudur.
4. Yayınlamadan önce self-referencing canonical’ı (sayfanın kendi URL’sine işaret ettiğini) ve sitemap’teki adresin bu URL’yle birebir eşleştiğini kontrol edin.

Kendi sitemiz bu dört adımla kuruldu. technoradical.com/blog/ altındaki yazıların URL’leri yayınlandığı günden bu yana hiçbiri değiştirilmedi; bu, yukarıda anlatılan maliyetin hiçbirinin bizim tarafımızdan ödenmediği anlamına geliyor. Bu gözlem tek bir siteye ve kısa bir geçmişe dayanıyor, genel bir kural olarak sunulmuyor.

Sitede birkaç düzine sayfa birikince, hangi URL’lerin tire veya büyük/küçük harf kuralını ihlal ettiğini ya da hangi parametreli adreslerin duplicate içerik ürettiğini elle tek tek taramak pratik kalmıyor. Sitedeki tüm URL’leri tek seferde tarayan bir teknik denetim, hangi kaydın önce düzeltileceğine karar vermeyi bu noktada hızlandırıyor.