Yönlendirme Zinciri (Redirect Chain) Hatası Nedir? Tespit ve Düzeltme Rehberi

Yönlendirme zinciri (redirect chain) hatası nedir?

Yönlendirme zinciri, bir adresin son hedefe doğrudan gitmek yerine arada bir veya daha fazla başka adrese uğradığı yönlendirme dizisidir. Örneğin A adresi B'ye, B de C'ye gidiyorsa iki atlamalı bir zincir vardır. Zincir uzadığında ziyaretçi bekler, arama motoru botu da gereksiz istek harcar.

2012'den beri teknik SEO denetimi yapıyorum ve yönlendirme zinciri, neredeyse her eski sitede karşıma çıkan sessiz sorunlardan biri. Site çalışıyor, sayfalar açılıyor, kimse bir hata görmüyor. Ancak arka planda her tıklama iki, üç, bazen beş sunucu yanıtından geçiyor. Bu yazıda zincirin nasıl oluştuğunu, döngüden farkını, Googlebot'un resmi atlama sınırını, hıza ve taramaya etkisini ve adım adım düzeltme yöntemini anlatıyorum.

Hemen kendi adresinizi kontrol etmek isterseniz yönlendirme denetleyici aracımıza bir adres girin. Araç her atlamayı durum koduyla birlikte sırayla gösterir.

Yönlendirme zinciri nasıl oluşur?

Yönlendirme zinciri çoğu zaman tek bir hatalı karardan değil, yıllar içinde üst üste binen küçük değişikliklerden doğar. Her değişiklik kendi içinde mantıklıdır; sorun, eski kuralların yeni kurallarla birleşmesidir. Bu yüzden zinciri kimse bilerek kurmaz, site büyüdükçe kendiliğinden birikir.

Üstelik ekip değiştikçe kuralların neden yazıldığı da unutulur. Yeni gelen geliştirici eski kuralı silmeye cesaret edemez ve üzerine yenisini ekler. Böylece her yıl zincire bir halka daha katılır.

Denetimlerde en sık gördüğüm senaryolar şunlar:

• Protokol ve alan adı katmanı: http adresi önce https'e, ardından www'suz sürüme gider. Aynı işi tek kural yapabilirdi.
• Sondaki eğik çizgi: Sunucu adresin sonuna eğik çizgi ekler, ardından başka bir kural küçük harfe çevirir.
• Art arda gelen yeniden tasarımlar: 2019'daki taşıma eski adresi B'ye, 2023'teki taşıma B'yi C'ye bağlamıştır. Kimse A kuralını güncellememiştir.
• Eklenti ve sunucu çakışması: CMS eklentisi bir kural uygular, sunucu yapılandırması başka bir kural uygular.
• Kısaltılmış kampanya bağlantıları: Kısa bağlantı servisi, eski kampanya adresine, o da yeni sayfaya gider.

Kısacası her katman bir atlama ekler. Dolayısıyla zinciri çözmek için hangi katmanın hangi kuralı yazdığını bilmeniz gerekir.

Yönlendirme döngüsü ile yönlendirme zinciri arasındaki fark nedir?

Yönlendirme zinciri sonunda bir hedefe ulaşır; yalnızca yol gereksiz uzundur. Döngüde ise hedef hiç gelmez. A adresi B'ye, B de yeniden A'ya gider ve istek sonsuza kadar döner. Tarayıcı bir noktada durur ve kullanıcıya hata sayfası gösterir.

Chrome bu durumda "ERR_TOO_MANY_REDIRECTS" hatası verir. Yani döngü, ziyaretçinin sayfayı hiç görememesi anlamına gelir. Zincir ise sayfayı gecikmeli de olsa açar. Bu nedenle döngü acil müdahale ister, zincir ise planlı bir temizlik ister.

Öte yandan iki sorun aynı kökten gelebilir. Çakışan kurallar bazı adreslerde zincir, bazılarında döngü üretir. Bu yüzden birini bulduğunuzda diğerini de mutlaka arayın.

Pratikte döngüyü çoğu zaman canlıya alınan yeni bir kuraldan hemen sonra fark ediyorum. Bu nedenle her kural değişikliğinden sonra ana sayfayı, bir kategoriyi ve bir ürün sayfasını mutlaka test edin.

Googlebot kaç yönlendirmeyi takip eder?

Google bu konuda net bir sayı veriyor. Google'ın HTTP durum kodları belgesine göre Google tarayıcıları varsayılan olarak en fazla 10 yönlendirme atlamasını izler. Belge, bazı ürünlerin tarayıcılarında bu sınırın farklı olabileceğini de ekliyor.

Ayrıca aynı belge önemli bir ayrıntıyı vurguluyor: Google, yönlendiren adresten gelen içeriği yok sayar ve yalnızca son hedefin içeriğini işler. Yani ara adreslerde ne yazdığınız önemsizdir; Google için anlamlı olan son duraktır.

Peki 10 atlama sınırı rahat bir alan mı? Kâğıt üzerinde evet, pratikte hayır. Google'ın site taşıma rehberi şöyle diyor: Googlebot zincirde 10 atlamaya kadar gidebilse de doğrudan son hedefe yönlendirmenizi önerir. Bu mümkün değilse zinciri kısa tutmanızı, ideal olarak en fazla 3 ve 5'ten az atlamada bırakmanızı ister.

Rehber gerekçeyi de açıkça yazar: zincirleme yönlendirme kullanıcı için gecikme ekler ve her tarayıcı ya da istemci uzun zincirleri desteklemez. Dolayısıyla hedefiniz 10'un altında kalmak değil, sıfır ara adımdır.

Bir noktayı da netleştireyim: 10 atlama sınırı, Google'ın sabrını değil, teknik tavanını anlatır. Bu tavana yaklaşan bir site, çoktan hız ve tarama maliyeti ödüyordur. O yüzden sınırı bir güvenlik payı gibi görmeyin.

Robots.txt dosyasında yönlendirme neden ayrıca önemlidir?

Robots.txt, zincir konusunda ayrı kuralları olan özel bir dosyadır. Google'ın robots.txt belgesine göre Google bu dosya için en az beş yönlendirme atlamasını izler, ardından durur ve dosyayı 404 kabul eder. Dosya 404 sayıldığında Google, sitede tarama kısıtlaması olmadığını varsayar.

Bunun anlamı şudur: robots.txt dosyanız uzun bir zincirin ucunda duruyorsa, içine yazdığınız engelleme kurallarının hiçbiri uygulanmayabilir. Üstelik aynı belgeye göre Google, robots.txt için çerçeve, JavaScript ya da meta refresh türündeki mantıksal yönlendirmeleri izlemez.

Alan adı değişikliklerinde bu tuzağa sık rastlıyorum. Eski alan adındaki robots.txt, yeni alan adına gider; yeni alan adı da http'den https'e bir atlama daha ekler. Böylece dosya bir zincirin sonunda kalır.

Bu yüzden robots.txt adresini her ana sürüm için ayrı ayrı test etmenizi öneririm: http, https, www'lu ve www'suz. İdeal durumda kanonik sürümdeki dosya doğrudan 200 döner. Dosyayı sıfırdan düzenlemeniz gerekiyorsa robots.txt hatalarını anlattığım yazıya da göz atabilirsiniz.

Yönlendirme zinciri site hızını nasıl etkiler?

Her yönlendirme, tarayıcının yeni bir istek göndermesi ve yeni bir yanıt beklemesi demektir. Farklı bir alan adına geçiş varsa buna DNS sorgusu ve yeni bir güvenli bağlantı kurulumu da eklenir. Sayfanın ilk baytı, zincirin son halkası tamamlanmadan gelmez.

Bu gecikme doğrudan ilk bayta kadar geçen süreye yansır. İlk bayt geciktiğinde de en büyük içerikli boyama (LCP) gibi metrikler geriye kayar. Özellikle mobil ağlarda her ek gidiş dönüş hissedilir bir bekleme yaratır.

Somut bir örnek vereyim. Reklam ve e-posta kampanyalarında kullanılan eski adresler çoğu zaman zincirin en uzun olduğu yerlerdir. Kullanıcı reklama tıklar, iki üç atlama sonra sayfaya ulaşır. Bu sırada bir kısmı sabırsızlanıp geri döner. Üstelik yönlendirme sırasında UTM parametreleri düşerse kampanya ölçümünüz de bozulur.

Hızın arama performansına etkisini merak ediyorsanız site hızının SEO'ya etkisini anlattığım yazıyı okuyabilirsiniz. Orada ölçüm yöntemlerini ayrıntılı olarak ele alıyorum.

Kendi ölçümünüzde tarayıcının geliştirici araçlarını açın ve Ağ sekmesinde ilk isteklere bakın. 3xx dönen her satır, sayfanın açılmasından önce harcanan süreyi gösterir. Böylece zincirin maliyetini milisaniye olarak görürsünüz.

Zincirler tarama bütçesini nasıl tüketir?

Googlebot bir zincirdeki her atlamayı ayrı bir istek olarak yapar. Yani üç atlamalı bir zincir, tek bir sayfa için dört istek anlamına gelir. Küçük bir sitede bu fark önemsiz görünebilir. Ancak on binlerce adresi olan bir e-ticaret sitesinde durum değişir.

Örneğin filtre adresleri, eski kategori yolları ve ürün varyantları zincirlere girdiğinde tarama kapasitesinin önemli bir bölümü ara adımlara gider. Böylece yeni ürünlerin ve güncellenen sayfaların keşfi yavaşlar. Sitenizin sunucusu yavaşsa Google tarama hızını zaten düşürür; zincirler bu baskıyı artırır.

Ayrıca her ara adres Google için ayrı bir URL'dir. Google bu adresleri kendi kuyruğunda tutar, belirli aralıklarla tekrar dener. Dolayısıyla temizlemediğiniz her eski kural, uzun süre tarama kayıtlarınızda görünmeye devam eder.

Tarama sıklığındaki düşüşleri ayrıca incelemek isterseniz Googlebot'un neden daha az taradığını anlattığım yazıya bakın. Orada Tarama İstatistikleri raporunu nasıl okuyacağınızı adım adım gösteriyorum.

Kısacası küçük sitelerde zincir daha çok bir hız sorunudur. Büyük sitelerde ise hem hız hem de keşif sorunudur. Öncelik sıranızı sitenizin büyüklüğüne göre belirleyin.

301, 302, 307 ve 308 kodları zinciri nasıl değiştirir?

Zincirdeki her halkanın durum kodu, Google'ın hangi adresi kanonik seçeceğini etkiler. Google'ın yönlendirme belgesine göre kalıcı yönlendirmeler, hedefin kanonik olması gerektiğine dair bir sinyaldir. Geçici yönlendirmelerde ise Google hedefi izler, ancak yönlendirmeyi kanonik sinyali olarak kullanmaz.

Karışık zincirler en kafa karıştırıcı olanlardır. Örneğin 301, ardından 302, ardından yine 301 gelen bir yolda Google'a çelişkili mesaj verirsiniz. Bu yüzden zinciri kısaltırken kodu da gözden geçirin: içerik kalıcı olarak taşındıysa tek bir 301 veya 308 yeterlidir.

Bir de şunu hatırlatayım: Google 303 ve 307 kodlarını 302 gibi, 308 kodunu ise 301 gibi işler. Yine de belge, bu kodların anlam olarak farklı olduğunu ve diğer istemciler için doğru kodu seçmenizi söyler. Yani Google için eşdeğer olmaları, rastgele seçebileceğiniz anlamına gelmez.

Meta refresh ve JavaScript yönlendirmeleri neden riskli?

Zincirdeki bir halka sunucu tarafında değil de sayfanın içinde çalışıyorsa sorun büyür. Google'ın önerdiği sıralama açıktır: önce sunucu taraflı yönlendirme, o mümkün değilse meta refresh, en son çare olarak JavaScript. Belge, JavaScript yönlendirmesini yalnızca diğer ikisini yapamıyorsanız kullanmanızı söylüyor.

Çünkü JavaScript yönlendirmesini görmek için Google'ın sayfayı işlemesi gerekir. İşleme başarısız olursa yönlendirme hiç fark edilmeyebilir. Meta refresh ise gecikmeli kurulduğunda Google tarafından geçici yönlendirme gibi yorumlanır; anında çalışan meta refresh ise kalıcı yönlendirmeye yakın bir sinyal verir.

Denetimlerde en sık rastladığım karma zincir şudur: sunucu 301 ile yeni adrese gönderir, yeni adresteki eski tema da JavaScript ile başka bir sayfaya atar. Tarayıcıda her şey düzgün görünür. Oysa zincirin son halkası bot için belirsiz kalır.

Kısacası zincirin tüm halkalarını sunucu tarafına taşıyın ve mümkünse tek bir halkaya indirin. Sayfa içindeki yönlendirmeleri yalnızca sunucuya erişiminiz olmadığında geçici çözüm olarak düşünün.

Hazır sistemlerde sunucu erişimi kısıtlı olabilir. Böyle bir durumda platformun kendi yönlendirme panelini kullanın ve tema kodundaki eski yönlendirme betiklerini temizleyin.

Search Console'da yönlendirme hatasını nasıl görürsünüz?

Search Console, zincirin sınırı aştığı durumları size doğrudan bildirir. Sayfa Dizine Ekleme raporunda "Yönlendirme hatası" nedeniyle listelenen adresler bu grubun başında gelir. Google'ın rapor açıklamasına göre bu neden şu durumlardan birini kapsar:

• Fazla uzun bir yönlendirme zinciri
• Bir yönlendirme döngüsü
• Sonunda azami URL uzunluğunu aşan bir yönlendirme adresi
• Zincirde hatalı ya da boş bir URL

Aynı raporda "Yönlendirmeli sayfa" nedeni de bulunur. Bu bir hata değildir; Google yalnızca yönlendiren adresin kanonik olmadığını ve dizine girmeyeceğini söyler. Ancak bu listede iç bağlantılarınızın ya da site haritanızın gösterdiği adresler varsa zincirin başlangıç noktasını bulmuşsunuz demektir.

Belirli bir adresi incelemek için URL Denetimi aracını kullanın. Araç, Google'ın seçtiği kanonik adresi ve sayfanın son durumunu gösterir. Rapora yeniyseniz önce Search Console kullanım rehberimi okumanızı öneririm.

Yönlendirme zinciri nasıl tespit edilir?

Search Console yalnızca sınırı aşan durumları gösterir; iki üç atlamalı zincirleri bulmak için kendi taramanızı yapmanız gerekir. Ben tespit işini her zaman aynı sırayla yürütürüm:

1. Tek adres kontrolü: Şüphelendiğiniz adresi yönlendirme denetleyici ile test edin. Her atlamanın kodunu ve hedefini not alın.
2. Ana sürüm testi: Alan adınızın dört sürümünü (http, https, www'lu, www'suz) ayrı ayrı deneyin. Her biri tek atlamada kanonik sürüme gitmeli.
3. Site taraması: Bir tarama aracıyla tüm iç bağlantıları izleyin ve 3xx dönen adresleri listeleyin. Aracın zincirleri ayrı bir raporda gösterip göstermediğine bakın.
4. Kırık bağlantı kontrolü: Zincirin sonu bazen 404'tür. Kırık link kontrolü bu durumları ayrıca yakalar.
5. Harici kaynaklar: Reklam hedef adreslerini, e-posta şablonlarını ve sosyal profil bağlantılarını da listeye ekleyin.

Komut satırını seviyorsanız curl ile de hızlı test yapabilirsiniz. Böylece her yanıtın başlık bilgisini ve Location değerini sırayla görürsünüz. Yine de toplu işte bir tarayıcı araç çok daha pratiktir.

Tespit sırasında bulduğunuz her zinciri aynı tabloya kaydedin: başlangıç adresi, ara adımlar, son hedef ve her halkanın kodu. Bu tablo, bir sonraki düzeltme adımının temelini oluşturur.

Sunucu log kayıtları zinciri nasıl gösterir?

Tarama araçları sitenizi sizin gördüğünüz gibi dolaşır. Log kayıtları ise Googlebot'un gerçekte neyi istediğini gösterir. Bu fark önemlidir, çünkü Google yıllar önce keşfettiği eski adresleri hâlâ düzenli olarak dener.

Log dosyasında Googlebot isteklerini süzün ve 301, 302, 307, 308 kodlarını ayrı bir tabloya alın. Ardından en çok istek alan yönlendiren adresleri sıralayın. Bu listenin tepesindeki adresler, tarama kapasitenizi en çok tüketen ara adımlardır.

Ayrıca Googlebot'un aynı zinciri kısa aralıklarla tekrar tekrar yürüdüğünü görürseniz bu, kuralın düzeltilmesi için güçlü bir önceliktir. Dosyayı elle incelemek yerine log analizi aracımızı kullanabilirsiniz; bot isteklerini ve durum kodlarını gruplar.

Son olarak log analizini bir kez yapıp bırakmayın. Büyük değişikliklerden sonra, özellikle taşıma ve tasarım yenilemelerinden sonraki haftalarda aynı analizi tekrarlayın. Böylece yeni doğan zincirleri erkenden yakalarsınız.

Küçük sitelerde log dosyasına erişim her zaman kolay değildir. Bu durumda Search Console'daki Tarama İstatistikleri raporu iyi bir alternatiftir; yanıt kodlarına göre dağılımı orada da görürsünüz.

Yönlendirme zinciri nasıl düzeltilir?

Yönlendirme zincirini düzeltmenin temel ilkesi basittir: her eski adres, tek atlamada son hedefe gitmelidir. Bunu uygulamak için şu adımları izliyorum:

1. Haritayı çıkarın: Tüm yönlendiren adresleri ve her birinin son hedefini bir tabloya yazın.
2. Kuralları düzleştirin: A→B→C yolunu A→C ve B→C olarak yeniden yazın. B kuralını silmeyin; B'ye gelen bağlantılar da vardır.
3. Doğru kodu seçin: Kalıcı taşımalarda 301 veya 308 kullanın.
4. Hedefi doğrulayın: Son hedefin 200 döndüğünden, noindex taşımadığından ve kanonik etiketinin kendisini gösterdiğinden emin olun.
5. İç bağlantıları güncelleyin: Menü, gövde ve alt bilgi bağlantılarını doğrudan son adrese çevirin.
6. Tekrar test edin: Değişiklikten sonra aynı listeyi yeniden tarayın.

Eski adresler için hedef bulmakta zorlanıyorsanız 404 yönlendirme eşleştirici işinizi kolaylaştırır. Araç, eski ve yeni adres listelerini benzerliğe göre eşleştirir. Yine de her öneriyi elle kontrol edin; otomatik eşleşme bazen alakasız sayfayı önerebilir.

Özellikle eski bir ürünü ana sayfaya yönlendirme alışkanlığından kaçının. Google, alakasız hedefe giden yönlendirmeleri soft 404 olarak değerlendirebilir. En yakın kategori ya da yerine gelen ürün, kullanıcı için de bot için de daha anlamlı bir hedeftir.

Sunucu kurallarında hangi hatalar zincir üretir?

Zincirlerin büyük kısmı, birbirinden habersiz yazılmış sunucu kurallarından çıkar. Apache'de .htaccess, Nginx'te sunucu blokları, CMS tarafında da eklentiler aynı adrese farklı anlarda müdahale eder. Özellikle şu hatalara dikkat edin:

• Kural sırası: Genel kural (http→https) özel kuraldan önce çalışırsa, özel kural ikinci bir atlama olarak eklenir.
• Göreli hedef: Hedef adresi protokolsüz ya da alan adısız yazmak, sunucunun önce varsayılan sürüme gitmesine yol açar.
• Parçalı normalleştirme: https, www ve sondaki eğik çizgi için üç ayrı kural yazmak üç ayrı atlama doğurur.
• Katman tekrarı: Hem CDN'de hem sunucuda hem de CMS'te aynı yönlendirme tanımlı olabilir.
• Parametre kaybı: Sorgu dizesini taşımayan kural, parametreli adresi yanlış hedefe atabilir.

Bu nedenle normalleştirme kurallarını tek bir yerde toplamanızı ve hedefi her zaman tam adresle yazmanızı öneririm. Böylece http ve www'lu bir istek, tek atlamada kanonik sürüme ulaşır. Değişiklikten önce kural dosyasının bir kopyasını alın; ters giden bir kural bütün siteyi döngüye sokabilir.

İç bağlantılar ve site haritası neden son hedefi göstermeli?

Zinciri sunucuda kısaltmak işin yarısıdır. Diğer yarısı, sitenin kendisinin artık yönlendiren adreslere bağlantı vermemesidir. Çünkü her iç bağlantı, Googlebot'a o adresi taramaya değer bulduğunuzu söyler.

Menüde, içerik gövdesinde ya da ürün kartlarında eski adresler duruyorsa, sunucu kuralınız ne kadar temiz olursa olsun en az bir atlama kalır. Üstelik bu atlama her sayfa görüntülemesinde tekrar eder. Kullanıcı tarafında bu küçük bir gecikme, bot tarafında ise sürekli bir israftır.

Site haritası için kural daha nettir: haritada yalnızca 200 dönen, kanonik adresler yer almalıdır. Yönlendiren bir adresi haritada bırakmak, Google'a çelişkili sinyal verir. Haritanızı yeniden oluşturmanız gerekiyorsa XML sitemap oluşturucu ile temiz bir liste çıkarabilirsiniz.

Ayrıca kanonik etiketlerini de kontrol edin. Kanonik etiketi yönlendiren bir adresi gösteriyorsa, Google'a aynı anda iki farklı mesaj verirsiniz. Dolayısıyla iç bağlantı, site haritası ve kanonik etiketi aynı son adreste buluşmalıdır.

Büyük sitelerde bu güncellemeyi elle yapmak zordur. Bu yüzden veritabanında eski adresleri toplu olarak arayıp değiştirmek, çoğu zaman en hızlı yoldur. İşlemden önce mutlaka yedek alın.

Site taşımalarında zinciri nasıl önlersiniz?

En uzun zincirler art arda gelen taşımalardan çıkar. Örneğin önce HTTPS geçişi, ardından alan adı değişikliği, en son da platform değişimi yapan bir sitede eski adresler üç ayrı kuşak kuralın içinden geçer. Yeni bir taşıma planlarken yalnızca bugünkü adresleri değil, geçmişte yönlendirilmiş tüm adresleri de haritaya almalısınız. Aksi hâlde eski zincirin sonuna yeni bir halka eklersiniz.

Benim yaklaşımım şudur: taşımadan önce mevcut yönlendirme kurallarının tamamını dışa aktarırım. Ardından her eski adresin yeni sitedeki son hedefini tek tek belirlerim. Böylece yıllar önceki bir adres bile yeni siteye tek atlamada ulaşır.

Ayrıca geçiş gününden önce yönlendirme listesini bir test ortamında tararım. Döngü ya da üç atlamalı bir zincir görürsem canlıya almadan düzeltirim. Geçişten sonra da ilk iki hafta log kayıtlarını ve Search Console'u günlük izlerim.

Taşıma sürecinin tamamı için ayrıntılı bir liste arıyorsanız SEO migration kontrol listesini okuyabilirsiniz. Orada alan adı, HTTPS, platform ve URL yapısı değişikliklerini tür tür ele alıyorum.

Eski yönlendirmeleri ne kadar süre korumalısınız?

Zinciri kısaltırken eski kuralları silme isteği doğar. Ancak Google, site taşıma rehberinde yönlendirmeleri olabildiğince uzun, genellikle en az bir yıl korumanızı öneriyor. Bu süre, Google'ın yeni adresleri yeniden taramasına ve diğer sitelerden gelen bağlantıları yeni adreslere atamasına izin verir.

Yani çözüm kuralları silmek değil, düzleştirmektir. A→B→C zincirinde B kuralını kaldırırsanız B'ye bağlantı veren siteler 404 görür. Bunun yerine A ve B'yi doğrudan C'ye bağlarsınız.

Pratikte ben dış bağlantı almış adreslerin yönlendirmelerini çok daha uzun süre tutuyorum. Değerli bir sayfaya işaret eden eski bir haber bağlantısı, yıllar sonra bile ziyaretçi getirebilir. Buna karşılık hiç bağlantı almamış, hiç trafik görmemiş ara adresleri bir yıl sonra temizlemek genellikle güvenlidir.

Bu kararı verirken log kayıtlarına ve dış bağlantı verisine bakın. Böylece silme kararını tahmine değil, veriye dayandırırsınız.

Ayrıca kuralları sildiğiniz tarihi bir değişiklik günlüğüne yazın. Birkaç hafta sonra 404 sayısında bir artış görürseniz nedenini hemen bulursunuz.

Düzenli yönlendirme denetimi için kısa kontrol listesi

Yönlendirme zincirleri bir kez temizlenip bitmez; her yeni kampanya, kategori düzenlemesi ya da eklenti güncellemesi yenisini doğurabilir. Bu yüzden üç ayda bir şu kontrolleri yapmanızı öneririm:

• Alan adının dört ana sürümü tek atlamada kanonik adrese gidiyor mu?
• Robots.txt ve site haritası doğrudan 200 dönüyor mu?
• Site taramasında iki veya daha fazla atlamalı adres var mı?
• Search Console'da "Yönlendirme hatası" sayısı arttı mı?
• Log kayıtlarında Googlebot'un en çok istediği yönlendiren adresler hangileri?
• Reklam ve e-posta hedef adresleri doğrudan son sayfaya mı gidiyor?
• Kanonik etiketleri ve iç bağlantılar son adresi mi gösteriyor?

Bu listeyi daha geniş bir teknik denetimin parçası olarak da kullanabilirsiniz. Ben bu kontrolleri bir tabloya işleyip her çeyrekte karşılaştırıyorum. Böylece sorunun büyüyüp büyümediğini tek bakışta görürsünüz. Teknik SEO'nun diğer başlıkları için teknik SEO ipuçlarını topladığım yazıya göz atın.

Yönlendirme sorunlarını ekibimle nasıl çözüyoruz?

Teknik SEO projelerinde yönlendirme temizliği, hızlı ve ölçülebilir sonuç veren işlerden biridir. Ekibimle bu çalışmaya her zaman veriyle başlarız: site taraması, log analizi ve Search Console raporu. Ardından tüm kuralları tek bir haritada toplar, zincirleri düzleştiririz.

Bu süreçte en çok zaman alan kısım teknik düzeltme değil, eski kuralların neden yazıldığını anlamaktır. Bu yüzden ekip olarak her kuralı silmeden önce trafiğini, dış bağlantısını ve iş açısından anlamını birlikte değerlendiririz.

Değişiklikleri önce test ortamında denetleriz, sonra canlıya alırız. Ardından birkaç hafta boyunca log kayıtlarını ve dizine ekleme raporunu izleriz. Strateji ve sonucun sorumluluğu bende kalır; uygulamayı ise alanında deneyimli ekip arkadaşlarım yürütür.

Sitenizde benzer bir denetim yapmak isterseniz SEO danışmanlığı sayfamızdan bize ulaşabilirsiniz. Kendi başınıza ilerlemek isterseniz de bu yazıdaki adımlar ve ücretsiz araçlarımız iyi bir başlangıç sağlar.