Site yapısı değişikliğinden sonra toplu yönlendirme haritası

Siteyi yeniden tasarladınız, kategori yapısı değişti ve şimdi Search Console günde birkaç yüz 404 hatası gösteriyor. Bugün yönlendirme haritası oluşturmaya başlamazsanız, geçen her gün eski bağlantıların değerinin ve gelen trafiğin bir kısmı kaybolur. İyi haber şu ki bu iş bir kez yapılır ve bir daha gerekmez; yeter ki doğru yöntemle ilerleyin.

Önce eski adres listesini gerçek verilerden oluşturun

Çoğu ekip bu adımı hafızadan yapar ve sonra trafiğin neden geri gelmediğine şaşırır. Gerçekten ziyaret edilmiş adresler üç yerde kayıtlıdır: web sunucusu erişim logu, Search Console performans raporu ve harici backlinkler. Üçünü de çıkarın ve bir CSV dosyasına dökün.

Sunucu logundan yalnızca eski başarılı istekleri ayırın. Web sunucusu Nginx ise:

awk '{print $7}' /var/log/nginx/access.log \
  | grep -E '^/(blog|products|category)/' \
  | sort | uniq -c | sort -rn | head -500

Bu komutun çıktısında ilk sütun ziyaret sayısı, ikinci sütun ise yoldur. İkinci sütunu alın, başına alan adını ekleyin ve listeye ekleyin. Search Console için Performance raporunun Pages bölümünden aralığı 16 aya ayarlayın ve CSV çıktısını indirin. "Adres" sütunu tam da ihtiyacınız olan şeydir.

Az söylenen bir nokta: query parametreli adresleri ayrı tutun. /product?id=42 adresini sabit bir sayfaya yönlendirmek neredeyse her zaman yanlıştır, çünkü o parametre ileride başka bir anlam kazanabilir.

Bire bir eşleme, her şeyi ana sayfaya yönlendirme değil

Her şeyi / adresine yönlendirme cazibesi vardır. Bu teknik olarak işe yarar ama SEO açısından felakettir. Google, ana sayfaya toplu yönlendirmeyi soft 404 olarak yorumlar ve bağlantı değerini aktarmaz. Her eski adres, konu olarak kendisine en yakın eşdeğerine gitmelidir.

Bunun için iki sütunlu bir tablo oluşturun: kaynak ve hedef. Kaynak, alan adı olmadan tam yol olmalı; hedef ise nihai ve kanonik adres olmalıdır. Bir sayfanın eşdeğeri yoksa, ana sayfaya değil, en yakın üst kategoriye yönlendirin.

410 kodu, gerçekten artık var olmayan ve bir eşdeğeri olmasını istemediğiniz sayfalar içindir. 404'ten farkı, Google'a bu kaldırmanın kasıtlı ve kalıcı olduğunu söylemesidir, bu yüzden dizinden daha hızlı çıkar. Ancak o sayfanın değerli backlinkleri varsa 410 yanlıştır; 301 vermelisiniz.

Haritayı nerede uygulamalı: web sunucusu mu uygulama mı

Yönlendirmeleri uygulamak için iki ana yer vardır ve aralarındaki seçim hız ile bakımı etkiler. Kural sayısı birkaç yüzün altındaysa ve yapı sabitse, web sunucusu katmanı doğru seçimdir. Kurallar veritabanından geliyorsa veya içerik yöneticisi SSH erişimi olmadan bunları düzenlemek zorundaysa, uygulama katmanı daha mantıklıdır.

Nginx'te kuralları server bloğuna yazın. Tek bir desenin toplu yönlendirmesi için, if zincirinden daha hızlı olan map kullanın:

map $uri $redirect_target {
    /old-blog/post-1    /blog/new-post-1;
    /old-blog/post-2    /blog/new-post-2;
    /category/php       /categories/php-hosting;
    default             "";
}

server {
    listen 443 ssl;
    server_name example.com;

    if ($redirect_target) {
        return 301 $redirect_target;
    }
}

Apache'de bunun karşılığı .htaccess dosyasıdır:

Redirect 301 /old-blog/post-1 /blog/new-post-1
RedirectMatch 301 ^/category/php/?$ /categories/php-hosting

Bu yöntemin maliyeti: eklenen her kural, her istekte ek bir karşılaştırmadır. Birkaç bin kuralla gecikme hissedilir hale gelir. Pratik çözüm, yüksek trafikli kuralları dosyanın üstüne koymak ve nadir kuralları RewriteMap ile ayrı bir dosyada tutmaktır. Linux hosting üzerinde çalışıyorsanız, .htaccess dosyasına binlerce satır eklemeden önce destek ekibiyle dosya boyutu sınırı ve işlem yükü hakkında görüşün.

Uygulamadan önce toplu test edin

Haritayı canlı siteye test etmeden uygulamak, siteyi birkaç saat erişilemez hale getiren hatanın ta kendisidir. Önce bir staging ortamında veya Host başlığını değiştirerek test edin. En basit yol, kaynak listesi üzerinde curl ile test etmektir:

while read -r src dst; do
  code=$(curl -s -o /dev/null -w "%{http_code}" -I "https://example.com$src")
  loc=$(curl -s -o /dev/null -w "%{redirect_url}" -I "https://example.com$src")
  echo "$src -> $code -> $loc"
done < redirects.txt

Doğru çıktı şuna benzer:

/old-blog/post-1 -> 301 -> https://example.com/blog/new-post-1

301 yerine 200 görürseniz, kural uygulanmamış demektir. 302 görürseniz, bir yerde yanlış kod yazılmış demektir. Bir 301 zinciri görürseniz, hedefin kendisi de yönlendiriliyor demektir ve kaldırılması gereken tam da budur.

İşte burada hata yapıyorlar

Gerçekten gördüğüm en yaygın hata: HTTP'den HTTPS'e yönlendirme ile yeni yapı yönlendirmesi aynı anda ve sıralama olmadan uygulanıyor ve döngü oluşturuyor. Belirtisi, tarayıcının ERR_TOO_MANY_REDIRECTS mesajı vermesi ve curl'ün -L ile 20 atlamadan sonra durmasıdır. Nedeni genellikle HTTPS kuralının yapı kuralından sonra gelmesi ve ikinci yönlendirmenin hedefinin tekrar HTTP sürümüne işaret etmesidir. Doğru sıra şudur: önce HTTP'den HTTPS'e, sonra yapı. Bu adımı döngü olmadan geçmek için kuralları yazmadan önce hosting'e SSL kurulumu ve yönlendirme döngüsü olmadan HTTPS zorlama rehberini okuyun.

Daha az görülen ama daha acı verici ikinci hata: hâlâ site haritasında (sitemap) olan adresleri yönlendirmek. Sonuç, Google'ın her gün aynı adresleri taraması, 301 alması ve tarama bütçesinin boşa gitmesidir. Haritayı uyguladıktan sonra sitemap'i de güncelleyin.

Uygulamadan sonra neleri izlemeli

Yönlendirme haritası canlı bir dosyadır, tamamlanmış bir iş değil. Uygulamadan sonraki ilk iki hafta boyunca Search Console'daki Pages raporunu günlük kontrol edin. 404 adreslerin sayısı arttıysa, haritanın bir kısmını atlamışsınız demektir. "Page with redirect" sayısı arttı ama trafik geri gelmediyse, hedeflerin doğru konu eşdeğeri yok demektir.

Ölçmeye değer bir sayı: yönlendirilen istekler için sunucu yanıt süresi. Bu isteklerin TTFB'si birkaç yüz milisaniyeyi aşarsa, muhtemelen .htaccess içinde çok fazla kural biriktirmişsinizdir veya sunucunun daha fazla kaynağa ihtiyacı vardır. Yüksek trafikli siteler için özel sunucuya geçmek ve yönlendirmeyi Apache yerine Nginx katmanında uygulamak, tam da bu sayıda belirgin bir fark yaratır.

Yönlendirmelerin doğru çalıştığını ve DNS ile ağ yolunda sorun olmadığını kontrol etmek için DNS ve ağ kontrol aracını kullanın. Nihai uygulamadan önce başlıkların davranışını gerçek ortamda görmek istiyorsanız, ücretsiz webmaster araçları staging kurmaktan daha hızlı bir seçenektir.

Sık sorulan sorular

Yönlendirme haritasında 301 ile 302 yönlendirme arasındaki fark nedir?

301 kodu kalıcı taşıma anlamına gelir ve bağlantı değerini hedefe aktarır. 302 kodu geçici taşıma anlamına gelir ve Google kaynak adresi dizinde tutar. Yapı değişikliği için her zaman 301 verin. 302 yalnızca bakım veya A/B testi gibi geçici durumlar için kullanılır.

Yanlışlıkla 302 verdiyseniz ve sonradan 301'e çevirirseniz, sorun yok; sadece o ana kadar bağlantı değerinin aktarılmadığını bilin.

Tüm eski adresleri yönlendirmeli miyim?

Hayır. Yalnızca ziyaret veya backlink almış adresler yönlendirmeye değerdir. Ziyaretsiz adresleri 404 olarak bırakabilir veya 410 verebilirsiniz. Binlerce değersiz adresi yönlendirmek, kural dosyasını yalnızca ağırlaştırır ve bakımını zorlaştırır.

Yönlendirmelerin döngüye girdiğini nasıl anlarım?

curl -sIL https://example.com/old-path ile başlık zincirini görün. İki veya üçten fazla atlama görürseniz ya da tarayıcı ERR_TOO_MANY_REDIRECTS verirse, döngünüz var demektir. Nedeni neredeyse her zaman HTTP/HTTPS ve yapı kurallarının yanlış sıralamasıdır.

Yönlendirme haritasını Nginx'te mi yoksa .htaccess'te mi yazmalıyım?

Sunucu üzerinde tam kontrolünüz varsa Nginx daha iyi bir seçimdir çünkü kurallar bellekte tutulur ve her istekte dosya okunmaz. Paylaşımlı hostingdeyseniz ve Nginx yapılandırmasına erişiminiz yoksa, .htaccess tek seçenektir. Her iki durumda da kaynak ve hedef listesini yapılandırmadan ayrı tutun ki sonraki geçiş kolay olsun.