Soft Ajans sitesinin teknik denetimini yaparken küçük ama sinsi bir sorun bulduk: eski adreslerin yönlendirildiği hedef, eğik çizgiyle biten bir adres yerine çift eğik çizgiyle (//) bitiyordu. Böyle bir hata ziyaretçinin gözüne hemen çarpmaz; yönlendirme denetimi sırasında yakaladık. Ama bir yönlendirmenin tek adımda, tek ve temiz hedefe gitmesi gerekir; fazladan bir karakter bile aynı sayfa için ikinci bir adres üretir.
Bu yazı bir “nasıl yapılır” rehberinden çok bir vaka anlatısıdır: sorunun ne olduğunu, Redirect ve RedirectMatch farkını, 380 kuralı nasıl dönüştürdüğümüzü ve düzeltmeyi yerel bir Apache sunucusunda nasıl test ettiğimizi gerçek örneklerle paylaşıyoruz. Yönlendirmenin temelini öğrenmek isterseniz önce 301 yönlendirme nedir ve yönlendirme zinciri nedir yazılarına bakabilirsiniz.
Sorun: Eski Adres Çift Eğik Çizgiyle Bitiyordu
Sitenin eski sürümünde yazılar kök dizinde, eğik çizgiyle biten adreslerde yayınlanıyordu (/ostim-web-tasarim/ gibi). Yeni sitede aynı yazılar /blog/ altına taşındı ve eski adreslerden yenilerine 301 yönlendirmesi tanımlandı. Kurallar .htaccess dosyasında şu biçimdeydi:
Redirect 301 /ostim-web-tasarim /blog/ostim-web-tasarim/Sorun, eski adresin sonuna eğik çizgi eklendiğinde ortaya çıkıyordu. Yerel bir Apache’de iki isteği denediğimizde şu sonucu aldık:
| İstek | Eski kuralla yönlendirme sonucu |
|---|---|
/ostim-web-tasarim (eğik çizgisiz) | /blog/ostim-web-tasarim/ (doğru) |
/ostim-web-tasarim/ (eğik çizgili) | /blog/ostim-web-tasarim// (çift eğik çizgi) |
Yani eski adresin en yaygın hâli, yani sonunda eğik çizgi olan adres, yanlış hedefe gidiyordu. Eski sitenin adresleri bu biçimde olduğu için, harici sitelerdeki eski linklerin ve arama motorunun hâlâ bildiği adreslerin de çoğunlukla bu biçimde olması beklenir.
Redirect Neden Böyle Davranır?
Apache’nin mod_alias modülündeki Redirect komutu, adresin tamamını değil başlangıcını (önekini) eşleştirir. Eşleşen önekten sonra gelen her şeyi, hedef adresin sonuna ekler. Apache belgelerindeki mantık budur: Redirect /eski /yeni tanımlıysa /eski/sayfa isteği /yeni/sayfa adresine gider.
Bizim kuralımızda hedefin kendisi zaten eğik çizgiyle bitiyordu (/blog/ostim-web-tasarim/). İstek /ostim-web-tasarim/ olunca, eşleşen önek /ostim-web-tasarim ve geriye kalan kısım / olur. Apache bu kalan / karakterini hedefin sonuna ekler ve sonuç /blog/ostim-web-tasarim// olur. Kural yanlış yazılmamıştı; komutun doğru çalıştığı ama bizim ihtiyacımızı karşılamadığı bir durumdu.
Bunun üç sonucu vardır:
- Çift eğik çizgili adres, arama motoru ve analiz araçları için ayrı bir adres gibi görünebilir.
- Sunucu çift eğik çizgili adresi açsa bile yönlendirmenin ilk adımda doğru hedefe gitmediği bir kalıp oluşur.
- Aynı mantıkla
/eski/baska-sayfagibi önek eşleşen her adres de yeni sitede olmayan bir adrese yönlenir.
Çözüm: RedirectMatch ile Tam Eşleşme
Çözüm, öneki değil adresin tamamını eşleştiren RedirectMatch komutunu kullanmaktır. Bu komut düzenli ifade (regex) kullanır:
RedirectMatch 301 ^/ostim-web-tasarim/?$ /blog/ostim-web-tasarim/Kuralın parçaları şunlardır:
^adresin başında eşleşmeyi başlatır./?sonundaki eğik çizginin olabileceğini ama zorunlu olmadığını söyler.$adresin orada bittiğini belirtir; böylece eşleşmeden sonra hiçbir şey eklenmez.
Sonuçta /ostim-web-tasarim ve /ostim-web-tasarim/ adreslerinin ikisi de tek adımda, tek eğik çizgili /blog/ostim-web-tasarim/ adresine gider. Hedefte fazladan karakter oluşmaz.
380 Kuralı Toplu Dönüştürmek
380 kuralı elle değiştirmek hata yapmaya açık bir iştir. Bunun yerine küçük bir betikle, her satırı aynı kalıpla dönüştürdük:
- Yedek aldık. Dönüştürmeden önce
.htaccessdosyasının tam bir kopyasını sakladık; karşılaştırma ve geri dönüş için. - Kalıpla dönüştürdük.
Redirect 301 /eski /yeni/biçimindeki her satırıRedirectMatch 301 ^/eski/?$ /yeni/biçimine çevirdik. Kaynak adresteki özel karakterler (nokta, tire gibi) ifadede anlam kazanabileceği için kaçış gerektiren adresleri ayrıca kontrol ettik. - Farkı gözle denetledik. Dosyanın değişmemesi gereken ilk satırlarını (HTTPS yönlendirmesi, güvenlik başlıkları) eski sürümle karşılaştırıp aynı olduklarını doğruladık. Değişiklik, 379 satır silinip 379 satır eklenmesi olarak göründü.
- İstisnayı ayırdık. Bir kuralın kaynak adresi yüzde işaretiyle kodlanmış (Türkçe karakter içeren eski bir adres) karakterler taşıyordu. Bu tür adreslerde regex eşleşmesi ayrıca test ister; bu tek satırı olduğu gibi bıraktık.
Böylece 380 kuraldan 379’u yeni biçime geçti; kalan bir kural bilerek eski biçimde duruyor.
Yerel Apache’de 758 İstekle Test
Yönlendirme kuralını canlıya göndermeden önce gerçek sunucu davranışıyla denemek gerekir; çünkü regex küçük bir hatayla yüzlerce adresi bozabilir. Bilgisayarımızdaki Apache’yi geçici bir yapılandırma dosyasıyla çalıştırdık, .htaccess dosyasını bir test klasörüne kopyaladık ve mod_alias, mod_rewrite gibi gerekli modülleri yükledik. Yerel testte HTTPS’e zorlayan kuralı kaldırdık; çünkü test http üzerinden yapılıyordu.
Test betiği şunları yaptı:
- Eski dosyadaki her kuralın kaynak ve hedef adresini okudu.
- Her kaynak için iki istek gönderdi: eğik çizgili ve eğik çizgisiz. 379 kural, her biri iki biçimde olduğundan toplam 758 istek yapıldı.
- Her yanıtın durum kodunun 301,
Locationbaşlığının ise beklenen tek eğik çizgili hedef olduğunu denetledi.
Sonuç: 758 isteğin tamamı tek adımda ve doğru hedefe yönlendi, sorunlu istek çıkmadı. Aynı testin birkaç örneği şöyleydi:
| İstek | Yeni sonuç |
|---|---|
/ostim-web-tasarim/ | 301 → /blog/ostim-web-tasarim/ |
/ostim-web-tasarim | 301 → /blog/ostim-web-tasarim/ |
/yenimahalle-web-tasarim/?a=1 | 301 → /blog/yenimahalle-web-tasarim/?a=1 (parametre korunur) |
/blog/ostim-web-tasarim/ | 200 (yeni adres, yönlendirme yok) |
Önemli bir ayrıntı: yerel Apache’yi kurmak sandığınızdan kolaydır. macOS’ta hazır gelen httpd ile birkaç satırlık bir yapılandırma dosyası yeterli oldu; canlı sunucuda deneme yapmak zorunda kalmadık.
Dikkat Edilmesi Gereken Yan Etkiler
Çözümün bir bedeli de olur; bunları bilerek karar vermek gerekir:
- Alt yollar artık yönlendirilmiyor. Eski
Redirectkomutu/eski/baskagibi alt yolları da yeni adrese taşıyordu.RedirectMatch ^/eski/?$yalnızca belirtilen adresi eşleştirdiği için/ostim-web-tasarim/xartık 404 döner. Eski sitede bu tür alt adresler yoksa sorun olmaz; varsa onlar için ayrı kural yazmanız gerekir. - Parametreler korunur. Sorgu parametreli adresler (
?a=1) yeni adrese taşınır; testimizde bunu doğruladık. - Büyük küçük harf duyarlıdır. Regex varsayılan olarak harf duyarlıdır; eski adresin farklı harf biçimleri ayrı kural isteyebilir.
- Tarayıcılar 301’i önbelleğe alır. Kuralı düzelttikten sonra eski sonucu hâlâ görüyorsanız tarayıcı önbelleğini temizleyin ya da gizli pencerede deneyin.
- Kontrol araçlarını güncelleyin. Yönetim panelimizdeki yönlendirme kontrolü yalnızca
Redirectsatırlarını okuyordu;RedirectMatchbiçimini de okuyacak şekilde güncelledik. Kuralları okuyan başka betikleriniz varsa onları da unutmayın.
Bu Vakadan Çıkardığımız Dersler
Sorunun kendisi küçüktü; asıl öğretici olan, neden bu kadar uzun süre fark edilmediğiydi.
- “Çalışıyor” tek bir testle anlaşılmaz. Yönlendirmeyi yalnızca bir biçimde (eğik çizgisiz) denerseniz doğru görünür. Her kaynağı hem eğik çizgili hem eğik çizgisiz denemek gerekir.
- Yönlendirme sonucu gözle değil betikle denetlenir. Yüzlerce kuralı tarayıcıda tek tek denemek mümkün değildir; durum kodunu ve
Locationbaşlığını karşılaştıran basit bir betik saatler yerine saniyeler alır. - Aynı denetim başka sorunları da çıkarır. Aynı teknik denetimde menü, alt bilgi ve CTA bağlantılarının sonunda eğik çizgi eksikti; her biri gereksiz bir 301 adımına yol açıyordu. Yönlendirmeleri incelerken iç bağlantıları da kontrol etmek mantıklıdır.
- Yeni kuralları baştan doğru biçimde yazın. Bundan sonra eklenecek her yönlendirme
RedirectMatch 301 ^/eski/?$ /yeni/kalıbıyla yazılıyor; böylece sorun yeniden oluşmuyor. - Değişiklikten önce yedek, sonra fark kontrolü. Büyük bir yapılandırma dosyasında toplu değişiklik yapıyorsanız eski sürümü saklayın ve yalnızca değişmesi gereken satırların değiştiğini doğrulayın.
Bu dersleri, site taşıma ya da yeniden yapılandırma planlayan herkesin 301 yönlendirme kontrol listesine eklemesini öneririz.
Kendi Sitenizde Aynı Sorunu Nasıl Kontrol Edersiniz?
Eski adreslerinizden birkaçını terminalden deneyin:
curl -sI https://www.siteniz.com/eski-adres/ | grep -i -E "^(HTTP|location)"Beklenen çıktı, tek bir 301 ve tek eğik çizgili bir location adresidir. Aşağıdakilerden biri varsa bakmanız gerekir:
locationadresinde//var.- Yönlendirme birden fazla adım sürüyor (
locationadresi de yeniden yönleniyor). - Eğik çizgili ve eğik çizgisiz biçimler farklı hedeflere gidiyor.
Ücretsiz bir tarama aracı ya da Search Console’daki “Sayfa dizine eklenmesi” raporu da yönlendirme sorunlarını gösterebilir. Site taşıma sırasında sonradan zincir yaratmamak için SEO denetimi sürecine yönlendirme testini mutlaka ekleyin. Teknik SEO denetimi desteği için SEO danışmanlığı sayfamıza bakabilirsiniz.
Sık Sorulan Sorular
Çift eğik çizgili yönlendirme SEO’ya zarar verir mi?
Etkisini bu sitede ölçmedik; ama gereksiz zincir ve aynı sayfa için ikinci bir adres üretmek, teknik SEO’da kaçınılması gereken bir durumdur. Düzeltmek, riski ortadan kaldırır ve maliyeti düşüktür.
Redirect ile RedirectMatch arasındaki fark nedir?
Redirect adres önekini eşleştirir ve eşleşmeden sonra gelen kısmı hedefe ekler. RedirectMatch düzenli ifadeyle çalışır; ^ ve $ ile adresin tamamını eşleştirebilir ve eşleşmeyen kalan kısmı eklemez.
Dönüştürme sonrası 301 yönlendirmeler eski sıralamayı korur mu?
Doğru yapılmış bir 301, eski adresin sinyallerinin yeni adrese aktarılmasına yardımcı olur; ancak sıralama her zaman aynı kalacak diye bir garanti yoktur. Yönlendirmeyi tek adımda, doğru hedefe yapmak bu aktarımın en temiz hâlini sağlar.
Her yönlendirmeyi Apache’de test etmek şart mı?
Yüzlerce kural içeren bir dosya için evet. Küçük bir betik ve yerel bir sunucu, canlıda yaşanabilecek toplu hatayı önler. Birkaç kurallı sitelerde curl ile elle denemek yeterli olabilir.
Nginx kullanıyorsam ne değişir?
Apache’deki Redirect yerine Nginx’te location ve return 301 ya da rewrite kullanılır. Eğik çizgiyle ilgili benzer tuzaklar orada da vardır; tam eşleşme için location = /eski biçimini düşünebilirsiniz.
Bu işlemi geri alabilir miyim?
Evet. Dönüştürmeden önce aldığımız yedek dosya, istediğimizde eski sürüme dönmemizi sağlar. Her büyük .htaccess değişikliğinden önce yedek almak iyi bir alışkanlıktır.
