Teknik SEO: hataları önem sırasına koyarak çözün

Teknik SEO, arama motorunun ve kullanıcının içeriğe doğru biçimde ulaşabilmesi için sitenin altyapısını incelemektir. Sunucu yanıtı, yönlendirme, render, indeks tercihleri, bağlantılar ve performans aynı sistemin farklı katmanlarıdır. Bir araç yüzlerce uyarı ürettiğinde yapılacak ilk iş hepsini düzeltmeye çalışmak değil, hangisinin gerçek bir engel olduğunu anlamaktır.

Denetimde üç soru sorun: Bu bulgu hangi sayfaları etkiliyor? Kullanıcıya veya arama erişimine etkisi nedir? Kanıtı tekrar üretebiliyor muyum? “Sayfa yavaş” yerine “ürün şablonunda ilk ekrandaki görsel geç yükleniyor; mobil testte aynı sorun üç örnekte tekrarlandı” yazmak geliştirici için çalışılabilir bir görev oluşturur.

Teknik mükemmellik ile arama başarısı aynı şey değildir. Çok hızlı bir sayfa yanlış soruyu cevaplıyorsa kullanıcı değerini tamamlamaz. Google sayfa deneyimini daha geniş bir kalite bağlamında değerlendirir; tek bir metrik bütün sonucu temsil etmez. Google sayfa deneyimi açıklaması

Öncelik yalnız hata sayısıyla belirlenmez. Bir şablon hatası bin sayfaya yayılırken tek bir ana dönüşüm sayfasındaki arıza da ciddi olabilir. Düzeltme riskini ayrıca yazın. Toplu URL değişikliği, küçük CSS düzeltmesinden farklı bir yayın ve geri alma planı gerektirir. Acil sorunu çözmek için geri dönüşsüz geniş değişiklik yapmak zorunda değilsiniz.

200, sunucunun isteğe başarılı yanıt verdiğini belirtir; sayfanın indeksleneceğini kanıtlamaz. Kaldırılmış bir ürün için boş hata ekranını 200 ile vermek anlam karışıklığı yaratabilir. Yönlendirmelerde 3xx ailesi, bulunamayan kaynaklarda 404 veya 410 gibi durumlar, sunucu sorunlarında 5xx yanıtları farklı işaretlerdir. Google bu grupları farklı şekilde işler. Google HTTP durum kodları rehberi

Teknik incelemede yalnız tarayıcıda gördüğünüz metne güvenmeyin. “Sayfa bulunamadı” yazan ekran gerçekte 200 dönüyor olabilir. Tersine, güzel görünen bir bakım sayfası yanlış yanıtla kalıcı içerik gibi sunulabilir. Yanıt kodu, başlıklar ve görünen içerik tutarlı olmalıdır.

Bir hatayı tekrar üretirken URL, tarih, cihaz ve oturum durumunu kaydedin. Önbellek veya bölgesel sunucu davranışı nedeniyle herkes aynı yanıtı almayabilir. Bu belirsizliği raporda saklamayın; örneklemin sınırını yazın.

Kurgusal örnek: Bir mağaza denetiminde 240 ürün sayfasında içerik eksikliği, başlık hatası ve düşük bağlantı sayısı raporlanıyor. Ekip her ürünü ayrı düzenlemeye hazırlanıyor. Şablon örneklemesinde ürün verisi isteğinin oturum açmış kullanıcıda çalıştığı, anonim ziyaretçide boş döndüğü görülüyor. Bir kök neden birden fazla uyarıya yol açmış durumda.

Düzeltme görevi “240 sayfayı SEO uyumlu yap” biçiminde yazılmıyor. Kabul ölçütleri belirleniyor: anonim istek ürün adını ve açıklamasını almalı, ürün bağlantıları doğru hedefi göstermeli, bulunmayan ürün uygun durum vermeli, mobilde satın alma yolu çalışmalı. Değişiklik önce kontrollü ortamda üç farklı ürün durumuyla sınanıyor.

Yayın sonrasında örnek ürünler yeniden kontrol ediliyor; bütün sitenin her gün baştan denetlenmesi yerine aynı kök nedene ilişkin kanıtlar izleniyor. Eğitimdeki sayı gerçek bir müşteri sonucu değildir. Örnek, uyarı sayısından kök nedene geçmenin önemini gösterir.

1. Ana sayfa, kategori, detay, arama ve hata sayfasından birer örnek seçin.
2. HTTP durumu, temel içerik, canonical, robots ve iç bağlantıları kaydedin.
3. Mobilde menü, form ve ana görevleri deneyin; yalnız ekran görüntüsünü değerlendirmeyin.
4. Bulgu için tekrar üretme adımları yazın. Beklenen ve gözlenen davranışı ayrı belirtin.
5. Kapsamı, önceliği ve yayın sonrası kabul kriterini ekleyin. Geri alma gerekip gerekmediğini değerlendirin.
6. Düzeltme sonrasında aynı örnekleri aynı yöntemle kontrol edin. Yeni sorun görmeden testi sürekli genişletmeyin.

İyi teknik görev şöyle biter: “Düzeltildiğini şu koşullarda anlayacağız.” Araç puanı yükseldiği için kapanan fakat kullanıcı yolu hâlâ bozuk olan görev tamamlanmış değildir. Yaygın hatalar; neden yerine belirtiyi düzeltmek, yalnız ana sayfayı test etmek ve bütün 404'leri ana sayfaya yönlendirmektir. Sonuncusu kullanıcıya karşılık gelen içerik sunmaz. Kaynak kontrolü: 27 Eylül 2026.

Bir hata kartını şu düzenle yazabilirsiniz: “Anonim kullanıcı ürün detayına girdiğinde açıklama alanı boş kalıyor. Oturum açıkken aynı URL dolu geliyor. Sorun üç ürün örneğinde gözlendi. Beklenen davranış, herkese açık ürün açıklamasının oturumdan bağımsız görünmesi.” Bu kısa kayıt problemi yeniden üretilebilir hale getirir. Ardından örnek URL, zaman, ilgili yanıt ve kapsam eklenir.

Kartın çözüm bölümünde teknolojiyi gereğinden erken dikte etmeyin. Geliştirici farklı bir güvenli çözüm önerebilir. Kabul kriterini sabit tutmak, çözüm yolunda esneklik sağlar. Son kontrolde yalnız başarılı ürün değil, bulunmayan ürün ve eksik görsel gibi sınır durumlarını da değerlendirin. Bir düzeltme başka şablonları etkilediyse kapsamı yeniden açın; etkilemediyse aynı testi gereksiz tekrarlarla büyütmek yerine değişikliği kapatın. Teknik SEO böylece sürekli uyarı üretmekten uygulanabilir mühendislik işine dönüşür.