Siteniz hem siteadi.com hem www.siteadi.com yazıldığında açılıyor ve ilk bakışta bu iyi bir şey gibi görünüyor: ziyaretçi hangisini yazarsa yazsın siteye ulaşıyor. Sonra bir SEO aracı taraması yapıyorsunuz ve "yinelenen içerik" uyarısı alıyorsunuz; ya da bir gün www'lu adreste tarayıcı kırmızı bir "Bağlantınız gizli değil" ekranı gösteriyor, www'suzda ise hiçbir sorun görünmüyor. Bu iki belirti aynı kökten gelir: sunucunuz aynı siteyi iki farklı adresten sunuyor ve hangisinin asıl adres olduğunu kimseye söylemiyor.
Bu yazıda önce www ve www'suz adreslerin aynı anda açılmasının teknik olarak ne anlama geldiğini, SEO ve SSL tarafında somut olarak neye mal olduğunu anlatacağım. Ardından tek adrese kalıcı yönlendirmeyi Apache .htaccess, Nginx sunucu bloğu ve hosting panelleri üzerinden ayrı ayrı kuracağız. Sonra Türkçe kaynaklarda neredeyse hiç değinilmeyen iki tuzağa geleceğiz: aynı yönlendirmeyi hem sunucuda hem WordPress ayarında yapınca oluşan sonsuz döngü, ve site Cloudflare arkasındayken kuralın nereye yazılması gerektiği. Sonunda da yönlendirmeyi doğru kurup kurmadığınızı komut satırından nasıl doğrulayacağınızı göstereceğim.
İki Adres Aynı Anda Neden Açılıyor#
Bunun sebebi bir hata değil, iki ayrı DNS kaydının aynı sunucuyu göstermesidir. siteadi.com ile www.siteadi.com teknik olarak iki farklı ana bilgisayar adıdır; ikincisi, birincisinin altında tanımlanmış bir alt alan adıdır. Tıpkı blog.siteadi.com gibi. Hosting hesabınız açıldığında panel ikisi için de kayıt oluşturur ve ikisini de aynı belge köküne yönlendirir.
DNS bölgenizde tipik olarak şunu görürsünüz:
siteadi.com. 3600 IN A 203.0.113.10
www.siteadi.com. 3600 IN CNAME siteadi.com.
Burada www kaydı, kök alan adına takma ad (CNAME) olarak bağlanmıştır; bazı yapılandırmalarda ikisi de doğrudan A kaydıdır ve aynı IP'yi gösterir. Sunucu tarafında ise Apache ya da Nginx her iki adı da aynı siteye eşler. Sonuç: iki kapı, tek ev. Kayıt türlerinin ne anlama geldiğine hâkim değilseniz A kaydı nedir yazısı temeli kurar.
Sorun kapıların iki tane olması değil, hiçbirinin "asıl kapı burası" dememesidir. Yönlendirme kurulmadığında sunucu iki adres için de 200 OK ve aynı içeriği döner. Yani internet açısından ortada birbirinin kopyası iki site vardır.
Aynı Anda Açılmasının Somut Zararları#
Bu durumun "sadece estetik" bir mesele olmadığını dört başlıkta görelim.
Yinelenen içerik ve bölünmüş bağlantı değeri. Arama motorları iki adresi iki ayrı URL olarak görür. Ana sayfanıza verilen dış bağlantıların bir kısmı www'lu, bir kısmı www'suz adrese gelir ve biriken otorite ikiye bölünür. Arama motoru genelde birini seçip diğerini eler ama bu seçimi sizin yerinize yapar; sizin istediğiniz sürümü seçmeyebilir. Search Console'da aynı sayfanın "Yinelenen, gönderilen URL kanonik olarak seçilmedi" uyarısıyla listelenmesinin en yaygın sebeplerinden biri budur.
SSL sertifikası kapsamı. Türkçe kaynaklarda en çok atlanan nokta bu. Bir SSL sertifikası belirli ana bilgisayar adları için düzenlenir. Sertifikanız yalnızca siteadi.com için alınmışsa, ziyaretçi https://www.siteadi.com yazdığında tarayıcı sertifikadaki isimle adresin uyuşmadığını görür ve tam sayfa güvenlik uyarısı basar:
NET::ERR_CERT_COMMON_NAME_INVALID
Bu sunucunun www.siteadi.com olduğu doğrulanamadı.
Burada kritik ayrıntı şudur: yönlendirme bu uyarıyı kendi başına çözmez. Tarayıcı önce TLS el sıkışmasını yapar, sertifikayı doğrular; yönlendirme yanıtını ancak bu adımdan sonra görür. Yani sertifika www'lu adı kapsamıyorsa, ziyaretçi yönlendirmeye ulaşamadan uyarı ekranında kalır. Doğru sıra: önce sertifikanın her iki adı da kapsadığından emin olun, sonra yönlendirmeyi kurun. Ücretsiz sertifikaların çoğu iki adı birden kapsayacak şekilde düzenlenebilir; panelde sertifika oluştururken listede hem siteadi.com hem www.siteadi.com seçili olmalıdır.
Çerez ve oturum karışıklığı. Kullanıcı www'suz adreste giriş yapıp bir bağlantıyla www'lu adrese geçtiğinde oturumu düşebilir, sepeti boşalabilir. Aynı şekilde analitik araçları aynı ziyaretçiyi iki farklı oturum sayar ve raporlarınız gerçeği yansıtmaz.
Önbellek ve CDN karmaşası. Önünüzde bir CDN varsa aynı sayfanın iki kopyası ayrı ayrı önbelleklenir; hem gereksiz maliyet hem de bir tarafta güncellenip diğerinde eski kalan içerik demektir.
Hangi Sürümü Seçmeli#
Kısa cevap: teknik olarak ikisi de doğrudur, önemli olan birini seçip ona sadık kalmaktır. Yine de iki tarafın pratik farkları vardır:
| Kriter | www'suz (siteadi.com) | www'lu (www.siteadi.com) |
|---|---|---|
| Görsel sadelik | Daha kısa, kartvizitte iyi durur | Daha uzun |
| CNAME esnekliği | Kök alan adına CNAME yazılamaz | CNAME yazılabilir, CDN'e kolay taşınır |
| Çerez kapsamı | Çerezler tüm alt alan adlarına yayılabilir | Çerez sadece www'da kalır |
| DNS taşıma kolaylığı | A kaydı ile IP'ye sabitlenir | Sağlayıcı değişince tek kayıt güncellenir |
| Uygulama | Küçük ve orta ölçekli siteler | Çok sayıda alt alan adı olan yapılar |
Zaten yayında olan ve arama sonuçlarında yer alan bir siteniz varsa, şu an arama motorlarında hangi sürüm görünüyorsa onu seçin. Sürüm değiştirmek geçici bir sıralama dalgalanması yaratır; sebepsiz yere yapmayın. Yeni bir site kuruyorsanız ve kararsızsanız, alt alan adı planınız yoksa www'suz sürüm çoğu durumda yeterlidir. Tercihin uzun tartışmasını www mu www'suz mu yazısında ayrıca ele aldım; bu yazının konusu tercih değil, tercihi uygulamak.
Apache: .htaccess ile Kalıcı Yönlendirme#
Paylaşımlı hostinglerin büyük çoğunluğu Apache tabanlıdır, dolayısıyla çözüm public_html/.htaccess dosyasına yazılacak birkaç satırdır. Dosya yoksa oluşturun; kuralı dosyanın en üstüne, WordPress'in kendi blokunun öncesine koyun.
www'suzdan www'luya yönlendirme (www'lu sürümü seçtiyseniz):
RewriteEngine On
RewriteCond %{HTTP_HOST} ^siteadi\.com$ [NC]
RewriteRule ^(.*)$ https://www.siteadi.com/$1 [L,R=301]
www'ludan www'suza yönlendirme (www'suz sürümü seçtiyseniz):
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.siteadi\.com$ [NC]
RewriteRule ^(.*)$ https://siteadi.com/$1 [L,R=301]
Satırların anlamı sırasıyla şudur: yeniden yazma motorunu aç, gelen isteğin ana bilgisayar adı şuysa, isteği tüm yol bilgisiyle birlikte ($1) hedef adrese kalıcı olarak (R=301) gönder ve başka kural işleme (L).
Dört ayrıntı üzerinde durmakta fayda var:
$1olmadan yazmayın.RewriteRule ^(.*)$ https://siteadi.com/ [R=301]şeklinde yazarsanız sitenin tüm alt sayfaları ana sayfaya yönlenir.www.siteadi.com/urunler/masaadresine gelen ziyaretçi ana sayfada bulur kendini; SEO açısından bu, sayfayı kaybetmekle aynı şeydir.- Nokta öncesindeki ters eğik çizgiyi atlamayın.
^www\.siteadi\.com$içindeki\.gerçek nokta anlamına gelir;.tek başına "herhangi bir karakter" demektir. [NC]büyük/küçük harf duyarsız eşleştirme yapar;WWW.SiteAdi.comyazan ziyaretçi de yakalanır.- 301 kullanın, 302 değil. 301 kalıcı taşımadır ve arama motoruna "bağlantı değerini hedefe aktar" der; 302 geçicidir ve aktarmaz. İkisi arasındaki farkı ve yanlış seçimin sonuçlarını 301 mi 302 mi yönlendirme yazısında anlattım.
Hem www hem HTTPS zorlamasını tek adımda yapmak istiyorsanız kuralları birleştirin. Ayrı ayrı iki yönlendirme yazarsanız ziyaretçi http://www.siteadi.com adresinden geldiğinde iki ardışık 301 yaşar; çalışır ama gereksiz bir tur atar:
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ https://siteadi.com/$1 [L,R=301]
Bu blok "HTTPS değilse veya www ile başlıyorsa, doğrudan HTTPS'li ve www'suz adrese git" der ve her durumda tek adımda hedefe ulaştırır.
Nginx: Ayrı Sunucu Bloğu ile Yönlendirme#
Nginx .htaccess dosyasını hiç okumaz; kural sunucu yapılandırmasına yazılır. Doğru yöntem, yönlendirilecek ad için ayrı bir sunucu bloğu açmaktır — if kullanmak Nginx'te önerilmez ve gereksizdir.
# www'lu adresi yakalayıp www'suza gönderen blok
server {
listen 80;
listen 443 ssl;
server_name www.siteadi.com;
ssl_certificate /etc/letsencrypt/live/siteadi.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/siteadi.com/privkey.pem;
return 301 https://siteadi.com$request_uri;
}
# Asıl site
server {
listen 443 ssl;
server_name siteadi.com;
root /var/www/siteadi.com;
index index.html index.php;
}
Buradaki $request_uri değişkeni, Apache'deki $1 ile aynı işi görür: yolu ve sorgu dizesini korur. Yönlendirme bloğunun da SSL sertifikası tanımlaması şarttır, çünkü tarayıcı https://www.siteadi.com adresine bağlanırken önce sertifikayı doğrular; blokta sertifika yoksa yönlendirmeye ulaşamadan hata alır. Bu, yazının başında SSL kapsamı için anlattığımız kuralın Nginx tarafındaki karşılığıdır.
Değişikliği kaydettikten sonra mutlaka doğrulayıp yeniden yükleyin:
nginx -t
systemctl reload nginx
nginx -t çıktısı syntax is ok ve test is successful demiyorsa reload etmeyin; hatalı yapılandırmayla yeniden başlatma denemesi siteyi tamamen kapatabilir.
WordPress ve Panel Ayarları: Sonsuz Döngü Tuzağı#
Şimdi Türkçe kaynaklarda neredeyse hiç anlatılmayan asıl tuzağa geliyoruz: aynı yönlendirmeyi iki katmanda birden kurmak.
WordPress kullanıyorsanız Ayarlar → Genel ekranında iki alan vardır: "WordPress Adresi (URL)" ve "Site Adresi (URL)". WordPress, ziyaretçi bu adreslerden farklı bir adla geldiğinde kendi başına yönlendirme yapar. Yani WordPress'te adresi https://siteadi.com olarak ayarladıysanız, www'lu adresle gelen istek zaten www'suza yönlenir.
Sorun şu senaryoda çıkar: WordPress ayarı https://www.siteadi.com iken .htaccess kuralınız www'suza yönlendiriyorsa, ikisi birbirine ters çalışır. Sunucu isteği www'suza gönderir, WordPress "benim adresim www'lu" deyip geri www'luya gönderir, sunucu tekrar www'suza… Tarayıcı belli bir tur sayısından sonra pes eder ve şu hatayı verir:
ERR_TOO_MANY_REDIRECTS
Bu sayfa çalışmıyor — siteadi.com sizi çok fazla kez yönlendirdi.
Aynı döngü şu üçlüde de oluşur: hosting panelindeki "Yönlendirmeler" aracı, .htaccess, ve CMS ayarı. Üçüne birden kural yazarsanız hangisinin ne yaptığını izlemek imkânsızlaşır.
Kural nettir: yönlendirmeyi tek bir katmanda kurun ve diğer katmanlardaki adres ayarlarını o hedefle aynı yapın. Pratikte doğru kurulum şudur:
- Bir hedef seçin — diyelim
https://siteadi.com. - Sunucu katmanında (
.htaccessya da Nginx) yönlendirmeyi bu hedefe kurun. - WordPress → Ayarlar → Genel'de her iki alanı da tam olarak
https://siteadi.comyazın (sonda eğik çizgi olmadan). - Panelin "Yönlendirmeler" bölümünde bu alan adı için tanımlı eski bir kural varsa silin.
- Tarayıcı önbelleğini temizleyip gizli sekmede test edin.
Zaten döngüye girdiyseniz ve yönetim paneline de giremiyorsanız, wp-config.php dosyasına geçici olarak şu iki satırı ekleyerek veritabanı ayarını ezebilirsiniz:
define('WP_HOME', 'https://siteadi.com');
define('WP_SITEURL', 'https://siteadi.com');
Panele girip ayarları düzelttikten sonra bu satırları kaldırın; kalıcı bırakmak ileride adres değiştirmenizi zorlaştırır.
Cloudflare Arkasında Yönlendirme Nereye Yazılır#
Siteniz Cloudflare gibi bir vekil katmanının arkasındaysa iki ek dikkat noktası vardır.
Birincisi: DNS kaydı proxy'li mi? Cloudflare panelinde kayıtların yanındaki bulut turuncu ise trafik Cloudflare üzerinden geçer, gri ise doğrudan sunucunuza gider. Yönlendirmenin çalışması için hem kök alan adı hem www kaydının aynı modda olması gerekir. Biri turuncu diğeri gri ise, iki adres farklı yollardan gelir ve kimi tarayıcıda yönlendirme çalışırken kimisinde çalışmaz.
İkincisi: kuralı sunucuda mı, kenar katmanında mı yazacaksınız? İkisi de çalışır ama karıştırmayın. Kenar katmanında bir yönlendirme kuralı tanımlarsanız istek sunucunuza hiç ulaşmadan yönlenir; bu daha hızlıdır ve sunucunuza yük bindirmez. Sunucuda yazarsanız istek önce Cloudflare'a, oradan sunucunuza gider, sunucu 301 döner, Cloudflare bunu ziyaretçiye iletir. Tercihiniz ne olursa olsun ikisini aynı anda tanımlamayın — yukarıdaki döngü senaryosunun aynısı burada da geçerlidir.
Üçüncü bir tuzak SSL modudur. Cloudflare'ın SSL ayarı "Flexible" konumundayken Cloudflare ile sunucunuz arasındaki bağlantı HTTPS değildir; sunucunuzdaki "HTTPS değilse HTTPS'e yönlendir" kuralı her istekte tetiklenir, Cloudflare tekrar HTTP olarak gönderir ve yine ERR_TOO_MANY_REDIRECTS alırsınız. Sunucunuzda geçerli bir sertifika varsa SSL modunu "Full (strict)" yapın; bu hem döngüyü çözer hem de trafiğin tamamını şifreler.
Yönlendirmeyi Doğrulama#
Tarayıcıda "açılıyor" demek yeterli değildir, çünkü tarayıcı 301 yanıtlarını önbelleğe alır ve yanlış kurduğunuz bir kuralı size doğruymuş gibi gösterebilir. Doğru test komut satırından yapılır:
curl -I https://www.siteadi.com
Beklenen çıktı:
HTTP/2 301
location: https://siteadi.com/
Bir de iç sayfa ile test edin; asıl hata orada ortaya çıkar:
curl -I https://www.siteadi.com/urunler/masa
location satırı https://siteadi.com/urunler/masa göstermelidir. Sadece https://siteadi.com/ gösteriyorsa kuralınızda $1 veya $request_uri eksiktir ve bütün iç sayfalarınız ana sayfaya düşüyordur.
Zincirin tamamını görmek için:
curl -sIL http://www.siteadi.com | grep -E "HTTP/|location"
İdeal çıktı tek bir 301 ve ardından 200'dür. Arada iki üç 301 görüyorsanız kuralları birleştirerek zinciri kısaltabilirsiniz; her ek adım hem gecikme ekler hem de mobil bağlantılarda hissedilir.
Kontrol listesi olarak şunları geçin:
| Test | Beklenen |
|---|---|
http://siteadi.com | Tek adımda https://siteadi.com |
http://www.siteadi.com | Tek adımda seçtiğiniz hedef |
https://www.siteadi.com | 301, sertifika uyarısı yok |
| İç sayfa yönlendirmesi | Yol korunuyor |
| Yönetim paneli | Döngüye girmiyor |
| Sitemap içindeki URL'ler | Hedef sürümle aynı |
Son madde önemlidir: site haritanız ve iç bağlantılarınız hâlâ eski sürümü gösteriyorsa, arama motoru her taramada gereksiz bir yönlendirme adımı yaşar. Yönlendirmeyi kurduktan sonra veritabanındaki eski adresleri de güncellemek gerekir.
Sıkça Sorulan Sorular#
www'lu mu www'suz mu tercih etmeliyim#
İkisi de teknik olarak doğrudur; belirleyici olan tutarlılıktır. Zaten yayında olan ve arama sonuçlarında görünen bir siteniz varsa şu an hangi sürüm indeksleniyorsa onu koruyun, çünkü sürüm değiştirmek geçici sıralama dalgalanmasına yol açar. Yeni bir site kuruyorsanız ve çok sayıda alt alan adı planınız yoksa www'suz sürüm daha kısa ve yaygındır. Büyük ölçekli, CDN ve alt alan adı ayrımı gereken yapılarda www'lu sürüm DNS esnekliği açısından avantaj sağlar.
Her iki adresin de açılması SEO'ya gerçekten zarar verir mi#
Evet, çünkü arama motoru aynı içeriği iki ayrı URL'de görür ve dış bağlantılardan gelen otorite iki adres arasında bölünür. Arama motoru sonunda birini asıl sürüm olarak seçer ama bu seçimi sizin adınıza yapar ve sizin istediğiniz sürüm olmayabilir. Ayrıca tarama bütçeniz aynı sayfaları iki kez taramakla harcanır. Kalıcı yönlendirme kurduğunuzda bu belirsizliğin tamamı ortadan kalkar ve tüm sinyaller tek adreste toplanır.
Yönlendirme kurdum ama hâlâ iki adres de açılıyor#
Büyük ihtimalle tarayıcı önbelleği yanıltıyor; gizli sekmede veya curl -I komutuyla test edin. Kural hâlâ çalışmıyorsa sırayla şunlara bakın: .htaccess dosyası doğru dizinde mi (public_html kökü), sunucu Apache mi yoksa .htaccess okumayan Nginx mi, kuraldaki alan adı yazımı doğru mu, ve kural WordPress'in kendi blokunun üstünde mi. Panelde tanımlı çakışan eski bir yönlendirme kuralı varsa onu da silmeniz gerekir.
ERR_TOO_MANY_REDIRECTS hatası neden çıkıyor#
Bu hata, iki katmanın birbirine ters yönlendirme yapmasından kaynaklanır. En yaygın senaryo, sunucudaki kuralın www'suza, CMS ayarının ise www'lu adrese işaret etmesidir; istek iki taraf arasında sonsuza dek gidip gelir ve tarayıcı pes eder. İkinci yaygın senaryo, Cloudflare SSL modunun Flexible olması ve sunucunun HTTPS zorlaması ile çakışmasıdır. Çözüm, yönlendirmeyi tek bir katmanda tutmak ve diğer katmanlardaki adres ayarlarını aynı hedefle eşitlemektir.
SSL sertifikam iki adresi de kapsamalı mı#
Evet, kapsamalıdır. Tarayıcı önce TLS bağlantısını kurup sertifikayı doğrular, yönlendirme yanıtını ancak ondan sonra görebilir; dolayısıyla sertifika www'lu adı kapsamıyorsa ziyaretçi yönlendirmeye ulaşmadan güvenlik uyarısı ekranında kalır. Sertifika oluştururken listede hem kök alan adı hem www seçili olmalıdır. Ücretsiz otomatik sertifika kullanan panellerin çoğu bunu varsayılan olarak yapar, ancak sertifikayı elle oluşturduysanız kontrol etmeniz gerekir.
Yönlendirmeyi hosting panelinden mi htaccess ile mi yapmalıyım#
Sonuç açısından ikisi de aynıdır, çünkü panelin yönlendirme aracı da arka planda aynı .htaccess dosyasına kural yazar. Panel arayüzü acemi kullanıcı için daha güvenlidir; elle yazmak ise kuralı HTTPS zorlamasıyla birleştirip tek adıma indirmenize izin verir. Önemli olan ikisini birden kullanmamaktır: panelden bir kural tanımlayıp ayrıca elle de yazarsanız çakışma ve döngü riski doğar. Bir yöntem seçin, diğerinde bu alan adı için tanımlı kural bırakmayın.
İç sayfalarım yönlendirmeden sonra ana sayfaya düşüyor#
Kuralınızda yol değişkeni eksiktir. Apache tarafında hedef adresin sonunda $1, Nginx tarafında $request_uri bulunmalıdır; bunlar istenen yolu ve sorgu dizesini hedefe taşır. Bu değişken olmadan sunucu her isteği kök adrese gönderir, yani sitenizin bütün alt sayfaları ana sayfaya düşer. Arama motoru açısından bu, o sayfaları kaldırmakla neredeyse aynı etkiyi yaratır, dolayısıyla kuralı kurduktan sonra mutlaka bir iç sayfa ile test edin.
Yönlendirme kurduktan sonra arama sıralamam düşer mi#
Kalıcı yönlendirme doğru kurulduğunda kalıcı bir düşüş beklenmez; 301 yanıtı bağlantı değerini hedef adrese aktarır. Geçiş döneminde birkaç hafta boyunca küçük dalgalanmalar görebilirsiniz, bu normaldir ve arama motorunun yeni adresi yeniden değerlendirmesiyle ilgilidir. Süreci hızlandırmak için site haritanızı yeni sürümle güncelleyip yeniden gönderin, iç bağlantılarınızı ve kanonik etiketlerinizi de hedef sürüme çevirin. Asıl risk yönlendirme kurmak değil, tüm iç sayfaları ana sayfaya yönlendiren hatalı bir kural yazmaktır.
Kapanış#
Sitenizin hem www'lu hem www'suz açılması bir arıza değil, eksik bir karardır: sunucu iki kapıyı da açık bırakmış, hangisinin asıl kapı olduğunu kimse söylememiştir. Çözüm üç adımdan ibarettir — bir hedef seçin, sertifikanın her iki adı da kapsadığından emin olun, yönlendirmeyi tek bir katmanda 301 olarak kurun. Sonra curl -I ile hem ana sayfayı hem bir iç sayfayı test edin; iç sayfada yolun korunduğunu görmeden işi bitmiş saymayın. Aynı kuralı hem sunucuda hem CMS ayarında hem de kenar katmanında tekrar etmek, bu konuda karşılaşacağınız hataların neredeyse tamamının kaynağıdır.
DNS kayıtlarını, yönlendirmeleri ve sertifikayı tek panelden yönetmek işi belirgin biçimde kolaylaştırır; alan adınızı ve barındırmanızı aynı yerde toplamak isterseniz alan adı kaydı ve web hosting tarafına bakabilirsiniz. Sertifikanın hem kök hem www adını kapsayacak şekilde kurulup süresi dolmadan kendini yenilemesini istiyorsanız SSL sertifikası sayfası bu işi üstlenir. Siteyi başka bir sağlayıcıdan taşıyorsanız ve DNS, yönlendirme, sertifika üçlüsünü kesintisiz kurmak istiyorsanız site taşıma hizmeti taşımanın bu tarafını da kapsar.