Son Güncelleme: 12 dk okuma

www ve www'siz Sürüm, HTTPS ve Eğik Çizgi: Tek URL

www ve www'siz Sürüm, HTTPS ve Eğik Çizgi: Tek URL

Aynı sayfa birden fazla adresten açılabiliyorsa, sitenizde fark etmeden dört beş kopya adres dolaşıyor olabilir. www ve www'siz sürüm, HTTP ve HTTPS, eğik çizgili ve çizgisiz yol: bunların her biri sunucu tarafında ayrı bir giriş kapısı olabilir. Bu yazıda tek sürümü nasıl seçeceğinizi, sunucuda tek adımlı 301 ile nasıl bağlayacağınızı ve sonucu nasıl kanıtlayacağınızı anlatıyoruz.

Aynı Sayfanın Dört URL Varyantı

Bir sayfanın adresi tek görünse de çoğu sitede aynı içeriğe şu eksenlerde farklı yollar vardır:

  • Protokol: http:// ve https:// sürümleri.
  • Alt alan adı: www'li ve www'siz sürümler.
  • Yol sonu: eğik çizgiyle biten ve bitmeyen sürümler.
  • Harf boyu ve dosya adı: büyük/küçük harf farkı ve "index.php" gibi ek yollar.

Eksenler birbiriyle çarpıldığı için sayı hızla büyür: yalnız protokol ve alt alan adı bile dört ana sayfa adresi üretir, yol sonu eklendiğinde sekiz ayrı adres olur. Hepsi aynı sayfayı gösteriyorsa kullanıcı fark etmez; ama tarayıcı robotlar, analitik raporu ve bağlantı veren siteler her birini ayrı adres olarak görebilir.

Bu yazı yalnız alan adı düzeyini ve yol sonunu ele alır. Etiket çelişkileri canonical etiketi denetimi yazısında, zincir ve döngü yönlendirme zinciri rehberinde anlatılıyor. Burada sorulan soru daha dar: hangi sürüm tek hedef olacak ve bunu nasıl kanıtlarız?

Google Hangi Sürümü Tercih Eder: Tutarlılık Esastır

Google'ın yinelenen URL'leri birleştirme belgesi (yeni sekmede açılır), tercih ettiğiniz sürümü belirtmezseniz Google'ın hangisinin kullanıcıya gösterilecek en uygun sürüm olduğuna kendisinin karar vereceğini söylüyor. Aynı belge, bir kanonik tercihin kural değil ipucu olduğunu da hatırlatıyor. Yani seçiminizi ne kadar net ve çelişkisiz bildirirseniz, sonuç o kadar öngörülebilir olur.

Belge www ile www'siz arasında bir üstünlük ilan etmiyor ve bu soruda bir sıralama avantajı vaat etmiyor. Dolayısıyla "www daha iyidir" ya da "www'siz daha iyidir" gibi mutlak bir hüküm verilemez. Belgedeki iki net öneri şunlardır: tek bir adres seçmek ve diğer varyantlardan kalıcı yönlendirmeyle ona göndermek. Yönlendirme bu belgede kanonik olması gereken hedefe dair güçlü bir sinyal olarak anılıyor.

HTTP ve HTTPS için belge daha belirgin: Google genellikle HTTPS'yi kanonik olarak tercih ediyor. Bunu desteklemek için HTTP'den HTTPS'ye yönlendirme, HTTP sayfasından HTTPS'ye kanonik link veya HSTS kullanılabiliyor. Geçersiz sertifika ve HTTPS'den HTTP'ye yönlendirme ise tercihi HTTP'ye doğru iter; HSTS bu durumda tercihi tek başına düzeltmez.

Özet olarak yazının geri kalanı tek bir ilkeye dayanıyor: tercihi bir kez seçin, sonra her sinyalin (yönlendirme, kanonik, sitemap, iç link) aynı yönü göstermesini sağlayın.

www ve www'siz Sürüm: Karar Verirken Bakılacaklar

Belge bir sürüm üstünlüğü vermediğine göre karar, sitenin kendi koşullarına göre verilir. Kararda işe yarayan sorular şunlardır:

  • Mevcut durum: Hangi sürüm zaten yaygın? Dışarıdan alınan bağlantıların çoğu, e-posta imzaları ve basılı materyaller hangisini kullanıyor? Mevcut ağırlığa uymak, en az yönlendirme demektir.
  • Altyapı: Kök alan adını (www'siz) bir CDN veya DNS sağlayıcısına yönlendirmek bazı kurulumlarda ek yapılandırma gerektirebilir. Hosting ve DNS ekibinin sınırlarını kontrol edin.
  • Alt alan adları: Çerezlerin ve oturumların alt alan adlarıyla nasıl paylaşıldığı, www tercihini etkileyebilir; bunu uygulama ekibiyle teyit edin.
  • Marka kullanımı: Reklamlarda ve kartvizitlerde adres nasıl yazılıyor? Görünen biçim ile asıl adres uyumlu olsun.

Seçim yapıldığında Search Console tarafında da küçük bir ayar gerekir. Alan adı mülkü (domain property) seçeneği protokol ve alt alan adı sürümlerini tek mülkte topladığı için geçişi izlemek kolaylaşır. Bunun yerine URL önekli mülk kullanıyorsanız, Google'ın site taşıma belgesinin (yeni sekmede açılır) önerdiği gibi tüm sürümleri ayrı ayrı doğrulayın. Aynı alan adı içinde www ile www'siz arasında geçiş için adres değişikliği aracı gerekmediğini de aynı belge belirtiyor. Alan adı taşımayı da içeren daha geniş bir geçiş yapıyorsanız harici bağlantıların korunması için site taşımada backlink değerini koruma yazısındaki adımlar da geçerlidir.

Örnek senaryo: küçük bir yayıncı sitesi, dışarıdan gelen bağlantıların büyük çoğunluğunun www'siz adrese işaret ettiğini görüyor. Karar basit: www'siz sürümü hedef seçip www'yi ona yönlendirmek. Karşıt seçimi yapmak da mümkündü; önemli olan seçimin yazıya dökülmesi ve sonra değişmemesidir.

HTTPS Geçişi ve Karışık İçerik Kontrolü

HTTPS'ye geçiş yönlendirmeden önce başlar: geçerli bir sertifikanın hem tercih edilen hem de yönlendirilecek sürümlerde çalıştığından emin olun. web.dev'in HTTPS'yi etkinleştirme rehberi (yeni sekmede açılır), HTTP'den HTTPS'ye yönlendirmenin HTTPS çalıştıktan sonra yapılmasını ve HTTPS sürümünün kanonik olduğunu arama motorlarına ve tarayıcılara bildirmek için 301 kullanılmasını öneriyor.

Geçişin en sık atlanan kısmı karışık içeriktir. HTTPS sayfa içinde HTTP kaynaklar yüklüyorsa tarayıcı uyarı verebilir veya o kaynakları engelleyebilir. Kontrol listesi kısadır:

  1. Görseller, stil dosyaları ve betikler HTTPS adresten mi yükleniyor?
  2. İç linkler göreceli veya tercih edilen HTTPS adresi mi kullanıyor?
  3. Gömülü ögeler (video, harita, form) HTTPS destekliyor mu?
  4. Sitemap ve kanonik etiketler HTTPS adresi mi gösteriyor?
  5. İçerik güvenlik politikası veya yönlendirme kuralları eski HTTP adresine bağlı kalmış mı?

Bu liste bir kez yapılıp bırakılacak bir iş değildir. Yeni eklenen bir üçüncü taraf betik, bir tema güncellemesi veya editörün eski bir görseli yapıştırması karışık içeriği geri getirebilir. Tarayıcının geliştirici konsolu karışık içerik uyarılarını gösterir ve sayfa şablonu başına bir kez bakmak çoğu sorunu yakalar.

Eğik Çizgi Kuralı: Klasör, Dosya ve Kök Adres

Eğik çizgi, kök adreste ve yol sonunda farklı davranır. Kök adreste "https://example.com" ile "https://example.com/" aynı istektir; tarayıcılar yol kısmını her durumda "/" olarak gönderir, yani burada tutarsızlık yaratacak bir şey yoktur. Yol sonunda ise durum değişir: "/hizmetler" ile "/hizmetler/" teknik olarak iki ayrı adres sayılabilir ve sunucu her ikisini de aynı sayfayla yanıtlıyorsa kopya oluşur. Bu bilgi HTTP'nin genel işleyişinden gelir; resmi belgelerde ayrıca bir tercih önerilmiyor.

Gelenek şudur: klasör benzeri sayfalar (içeriğin bir alt bölümü) çizgiyle biter, dosya benzeri adresler (örneğin "sayfa.html") bitmez. Birçok içerik yönetim sistemi bu kuralı kendi permalink ayarıyla yönetir. Seçimde sizin sisteminizin varsayılanı ağır basar; sistemin ürettiği iç linkler zaten bir biçimi kullanıyorsa, karşıt yönü seçmek her bağlantıda yönlendirme demektir.

Kural şöyle işler: tek biçim seçilir, diğer biçim 301 ile ona gider ve iç linklerde yalnız seçilen biçim bulunur. Bu iç link tutarlılığı, yönlendirmeye güvenmekten önemlidir; çünkü her tıklamada yönlendirme çalıştırmak gereksiz bir ek istektir. Dosyaya benzeyen adreslere (görseller, PDF'ler, sitemap.xml) eğik çizgi eklemeyin; bunlar için kural koyarken istisna listesi bırakın.

Büyük Küçük Harf ve index.php Gibi Varyantlar

Google'ın URL yapısı belgesi, adres yollarının büyük/küçük harfe duyarlı ele alındığını belirtiyor ve sunucunuz farklı harf boylarını aynı sayfaya götürüyorsa tümünü tek bir harf boyuna çevirmenizi öneriyor. Alan adı kısmı ise harf boyundan etkilenmez; yol kısmında "/Hizmetler" ile "/hizmetler" ayrı kabul edilebilir. Çözüm olarak tek bir biçim (çoğunlukla küçük harf) seçilir ve büyük harfli istek 301 ile ona gönderilir.

Dosya adı varyantları da aynı mantıkla çözülür. Ana sayfa "/index.php" veya "/index.html" adresinden de açılıyorsa, bunlar köke ("/") yönlendirilmelidir. Aynı şekilde "/anasayfa" ya da "/home" gibi eski ana sayfa yolları da tek hedefe gitmelidir. Dikkat edilecek nokta, yönlendirmeyi uygulama düzeyinde değil sunucu düzeyinde yazmaktır; uygulama düzeyinde yazılan kural bazı isteklerde devreye girmeyebilir.

Üç kontrolle bu bölümü bitirebilirsiniz:

  • Sitenin ana yolları büyük harfle istendiğinde 301 dönüyor mu?
  • "/index.php" ve benzeri dosya adları köke gidiyor mu?
  • Çift eğik çizgi ("//") veya sonda nokta gibi bozuk girişler temiz adrese dönüyor mu?

Slug yazımı ve klasör düzeni bu yazının konusu değildir, bu yazı yalnız alan adı ve yol sonu standardını ele alır. Filtre parametrelerinin yarattığı kopyalar için ise filtre URL'leri yazısı geçerlidir.

Sunucu Düzeyinde Tek Adımlı 301 Kuralı

Üç ayrı kural yazmak (önce HTTP'yi HTTPS'ye, sonra www'siz'i www'ye, sonra çizgiyi eklemek) yönlendirme zinciri üretir: kullanıcı iki veya üç sıçramayla hedefe ulaşır. Doğru tasarım, hangi varyant gelirse gelsin tek hamlede nihai adrese gitmektir. Site taşıma belgesi de zincirden kaçınmayı ve doğrudan son hedefe yönlendirmeyi öneriyor.

Mantık şöyle kurulur: nihai adres tanımlanır (örneğin https, www'siz, yol sonunda çizgi yok). İstek tam olarak bu adres biçiminde değilse tek bir 301 ile bu adrese gönderilir. Kural tek bir koşullar kümesi olarak yazılır, adım adım ilerleyen ayrı kurallar olarak değil. Apache için genel bir kalıp şöyle düşünülebilir:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

nginx tarafında da prensip aynıdır: tercih edilmeyen adresleri dinleyen ayrı bir sunucu bloğu, tüm istekleri "return 301" ile hedef adrese ve istek yoluna gönderir. Dikkat: 443 portunda tercih edilmeyen sürüm için de geçerli bir sertifika gerekir; aksi halde tarayıcı yönlendirmeyi görmeden sertifika hatası verir. Bu örnekler genel bir kalıptır, belirli bir hosting ayarının vaadi değildir; arkada bir CDN, ters proxy veya yük dengeleyici varsa HTTPS tespiti farklı çalışır. Kuralı yayından önce test ortamında deneyin.

301 ile 308 kalıcı taşımayı bildirir, 302 ve 307 gibi geçici kodlar ise hedefi kanonik yapmaz. Bu geçişte kalıcı kod kullanın. Yönlendirmenin değer aktarımına dair mutlak bir hüküm vermiyoruz; yapacağınız şey tek bir tercih edilen hedefe tutarlı yönlendirmektir.

HSTS Ne Zaman ve Nasıl Eklenir

HSTS, tarayıcıya siteyi yalnız HTTPS ile açmasını söyleyen bir yanıt başlığıdır; tarayıcı bir kez kaydettikten sonra HTTP adresi yazılsa bile ağa çıkmadan HTTPS'ye döner. Bu bir yönlendirme yerine geçmez, onun üstüne eklenen bir güvenlik katmanıdır. Google'ın belgesi de HSTS'yi HTTPS tercihini pekiştiren yöntemlerden biri olarak sayıyor.

web.dev'in rehberi iki uyarı veriyor: site işletimi yeterince sağlam olduğundan emin olmadan HSTS'yi açmayın ve max-age değerini düşük başlatıp güvenle kullandıkça kademeli artırın. Nedeni basit: HSTS kaydeden bir tarayıcı, sertifikanız bozulduğunda siteye HTTP üzerinden de ulaşamaz. Örneğin süresi dolmuş bir sertifika, kullanıcıları "devam et" seçeneği olmadan engelleyebilir.

Güvenli bir sıra şöyle olabilir:

  1. HTTPS ve karışık içerik denetimini tamamlayın, sertifika yenileme sürecini otomatikleştirin.
  2. Başlığı küçük bir max-age ile (örneğin birkaç dakika) ekleyin ve izleyin.
  3. Sorun çıkmazsa değeri gün, hafta ve ay ölçeğinde artırın.
  4. İyice oturduktan sonra yaygın örneklerde görülen bir yıllık değere (31536000 saniye) ulaşın.

includeSubDomains yönergesi korumayı bütün alt alan adlarına yayar; HTTPS desteklemeyen tek bir alt alan adı bile bozulabilir, bu yüzden önce alt alan adlarının listesini çıkarın. Preload listesine başvuru ise ayrı ve geri alınması daha zor bir karardır; bu yazı onu önermiyor, yalnız uyarıyla anıyor.

Yönlendirme tek başına işi bitirmez; çünkü robotlar adresleri başka yollardan da öğrenir. Google'ın belgesi kanonik seçiminde yönlendirmeyi, kanonik etiketi ve site haritasını birlikte sayıyor. Kanonik etiket güçlü bir sinyal, site haritası ise daha zayıf bir sinyal olarak tarif ediliyor. Bu sinyallerden biri farklı sürümü gösterirse Google'ın seçimi sizin tercihinizden ayrılabilir.

Hizalama listesi şöyledir:

  • Canonical: Her sayfa kendi nihai adresini, mutlak URL olarak ve tercih edilen protokol ile alt alan adıyla göstermelidir.
  • Sitemap: Yalnız nihai adresler bulunmalı; yönlendirilen veya HTTP'li kayıt kalmamalıdır. Kontrol adımları sitemap denetimi yazısında var.
  • İç linkler: Menü, içerik ve altbilgi bağlantıları nihai adresi kullanmalıdır.
  • Hreflang ve dil linkleri: Varsa bunlar da aynı protokol ve alt alan adı ile yazılmalıdır.
  • Search Console: Tercih edilen sürümün yeni sürümde izlendiğinden emin olun.

Yönlendirilen adreslere gereksiz tarama istekleri ayrıca tarama yükü yaratır. Büyük sitelerde bu, tarama bütçesi konusuyla da kesişir; ayrıntısı tarama bütçesi optimizasyonu yazısında. Küçük sitelerde ise asıl kazanç, raporların tek adres üzerinden okunabilmesidir.

Yönlendirmeyi Test Etme ve İzleme

Kuralı yazmak işin yarısıdır; kanıt ikinci yarıdır. Testi birkaç somut adımda yapabilirsiniz. İlk adım, her varyant için yanıt kodunu ve hedefi görmek: http+www, http+www'siz, https+www, https+www'siz ve çizgili/çizgisiz yol için ayrı ayrı. Beklenen sonuç, nihai adres dışındaki her varyant için tek bir 301 ve nihai adres için 200'dür.

İkinci adım zincir kontrolüdür: bir isteğin kaç sıçramada bittiğine bakın. İkiden fazla sıçrama varsa kuralları birleştirin. Üçüncü adım Search Console'da denetimdir: URL denetimi aracıyla seçili sayfalara bakıp, sizin bildirdiğiniz kanonik ile Google'ın seçtiği kanoniğin aynı olup olmadığını karşılaştırın. Farklıysa çelişen bir sinyal vardır; yönlendirme, canonical, sitemap ve iç linkleri sırayla tarayın.

Düzenli izleme için hafif bir rutin yeter:

  1. Ay başında tüm varyantları örnek bir sayfada elle test edin.
  2. Site motoru, tema veya CDN değiştiğinde aynı testi tekrarlayın.
  3. Sitemap ve iç linklerde nihai olmayan adres çıkıyor mu, taramayla kontrol edin.
  4. Sertifika bitiş tarihini takvime ekleyin; HSTS açıksa bu, kritik bir tarihtir.

Yönlendirmeleri koruma süresi için Google'ın site taşıma belgesi, mümkün olduğunca ve genellikle en az bir yıl tavsiyesinde bulunuyor. Bu süreyi bir üst sınır değil, alt sınır olarak okuyun.

Örnek Şablon: URL Varyantı, Hedef ve Doğrulama Tablosu

Sürüm standardınızı belgeleyen örnek bir tablo aşağıda. Değerler örnek değerlerdir ve example.com sahte bir alan adıdır; kendi alan adınız ve kararınızla doldurun. Örnekte hedef sürüm https, www'siz ve yol sonunda çizgisizdir.

İstenen adres (örnek)Beklenen yanıtHedefDoğrulama
http://example.com/hizmetler301https://example.com/hizmetlerTek sıçrama, zincir yok
http://www.example.com/hizmetler301https://example.com/hizmetlerTek sıçrama
https://www.example.com/hizmetler301https://example.com/hizmetlerSertifika www için de geçerli
https://example.com/hizmetler/301https://example.com/hizmetlerİç linkler çizgisiz biçimde
https://example.com/Hizmetler301https://example.com/hizmetlerHarf boyu tek biçime iner
https://example.com/hizmetler200KendisiCanonical kendini gösterir, sitemap'te var

Örnek senaryo olarak küçük bir mağaza sitesini düşünün: ekip tabloyu üç ana sayfa türü için dolduruyor ve altı satırlık testi yönlendirme değişikliğinden önce ve sonra çalıştırıyor. İlk çalıştırmada www'li HTTPS adresinin iki sıçramayla hedefe ulaştığını görüyor, kuralları birleştiriyor; ikinci çalıştırmada tek sıçrama alıyor. Tablonun değeri, değişikliğin kanıtının yazılı kalmasıdır.

Sıkça Sorulan Sorular

www ve www'siz sürüm SEO için fark yaratır mı?

Resmi belgelerde bir sürümün diğerinden üstün olduğuna dair ifade yok; önemli olan tek bir sürüm seçip tutarlı kullanmaktır. Seçilmeyen sürümü 301 ile yönlendirin ve canonical, sitemap ile iç linklerin aynı sürümü göstermesini sağlayın. Sıralama avantajı vaat edilmez.

www'siz siteyi www'ye nasıl yönlendiririm?

Sunucu düzeyinde tek bir kalıcı 301 kuralı yazın; www'siz her istek, aynı yol ve parametrelerle www sürümüne gitsin. HTTP'den HTTPS'ye geçişi de aynı kuralda birleştirip zincir oluşmasını önleyin. Ardından canonical, sitemap ve iç linkleri www adresine güncelleyin, tüm varyantları test edin.

HTTP'den HTTPS'ye yönlendirme nasıl yapılır?

Önce geçerli sertifikayı ve karışık içerik kontrolünü tamamlayın, sonra tüm HTTP isteklerini tercih edilen HTTPS adrese tek adımda 301 ile yönlendirin. Canonical, sitemap ve iç linkler de HTTPS adresi göstermelidir. Kuralı yayından önce test ortamında deneyin ve zincir olmadığını doğrulayın.

URL sonunda eğik çizgi olmalı mı?

Kök adreste fark yoktur; yol sonunda ise eğik çizgili ve çizgisiz sürümler teknik olarak ayrı URL sayılabilir. Birini seçin, diğerini 301 ile yönlendirin ve iç linklerde yalnız seçtiğiniz biçimi kullanın. Hangi biçimin seçildiği değil, tutarlı uygulanması önemlidir.

HSTS nedir ve açmak güvenli mi?

HSTS, tarayıcıyı siteyi yalnız HTTPS ile açmaya zorlayan bir yanıt başlığıdır. Sertifika sorunu olduğunda siteye erişimi tamamen engelleyebildiği için önce HTTPS'nin sağlam çalıştığından emin olun, küçük bir max-age ile başlayın ve değeri izleyerek kademeli artırın.

Hangi URL sürümünün indekslendiğini nasıl görürüm?

Search Console'da URL denetimi aracıyla adresi inceleyin ve sayfa indeksleme raporuna bakın. Orada sizin bildirdiğiniz kanonik ile Google'ın seçtiği kanoniği karşılaştırabilirsiniz. İkisi farklıysa yönlendirme, canonical etiketi, sitemap ve iç linklerde çelişen bir sinyal olup olmadığını kontrol edin.

Sonuç ve Sonraki Adım

Tek sürüm kararı küçük görünür ama raporların, bağlantıların ve taramanın ortak zeminini belirler. Önce hedef sürümü yazılı olarak seçmek, sonra sunucuda tek adımlı bir 301 kuralı kurmak, canonical, sitemap ve iç linkleri aynı sürüme hizalamak ve tablodaki testi çalıştırmak gerekir. HSTS ancak HTTPS düzgün çalıştıktan sonra, küçük bir değerle eklenir.

Bu standartla yazılacak yeni sayfalar için içerik düşünüyorsanız içerik siparişi sayfasına bakabilirsiniz: ürün seçilir, sepet ve ödeme tamamlanır, satıcı onaylar, teslimat bildirilir ve sorun çıkarsa itiraz süreci devreye girer. Yine de önce kendi alan adınız için tabloyu doldurun; hangi adresin hedef olduğu belli değilse sipariş edilen içerik de yanlış varyanta bağlanabilir.

0 Yorumlar

Bu yazı için henüz yorum yapılmamış.

Yorum Yaz

Yorum yapabilmek için giriş yapmalısınız. Giriş Yap