Teknik SEO Denetimi: Kontrol Listesi ve Önceliklendirme

Teknik SEO denetimi, bir sitenin arama motorları tarafından bulunmasını, taranmasını, dizine eklenmesini ve doğru sayfa olarak anlaşılmasını engelleyen sorunları sıraya koyarak bulma işidir. Çoğu denetim raporu yüzlerce satırlık bir uyarı listesine dönüşür ve okuyan kişi neyin önce çözüleceğini bilemez. Bu rehber, tersini yapar: denetimi sıralı bir akışa böler, her adımda neye bakılacağını söyler ve en sonda bulguları etki ile emek eksenine yerleştirerek önceliklendirir.

Yazı bir şemsiye rehberdir. Her başlıkta yalnızca denetim sorusunu ve karar noktasını veriyoruz; derin teşhis gerektiren konular için ilgili ayrıntılı yazıya bağlantı bırakıyoruz. Amaç, "Bu sitenin sorunu nerede olabilir ve önce neyi çözmeliyim?" sorusuna bir harita sunmaktır.

Teknik SEO Denetimi Kapsamı ve Veri Kaynakları

Denetime başlamadan önce kapsamı yazın. Aksi hâlde araç neyi bulursa onu raporlarsınız ve rapor, sitenin gerçek hedefleriyle ilgisiz maddelerle dolar. Kapsam belirlerken üç şeyi netleştirin: hangi alan adları ve diller denetleniyor, hangi sayfa türleri önemli (ana sayfa, kategori, ürün, blog), ve hangi iş hedefi için (organik trafik, dönüşüm, yeni sitenin dizinlenmesi gibi).

Denetimde üç tür veri kaynağı birlikte kullanılır ve hiçbiri tek başına yeterli değildir.

• Arama motoru verisi: Search Console'daki dizin kapsamı, tarama istatistikleri ve performans raporları, Google'ın sitenizi nasıl gördüğünü doğrudan gösteren tek birincil kaynaktır.
• Tarayıcı çıktısı: Bir site tarama aracı, sayfaları sizin görmek istediğiniz sırayla dolaşır; durum kodlarını, başlıkları, canonical etiketlerini, iç linkleri ve yönlendirmeleri toplar. Araç Google değildir, yalnızca bir model sunar.
• Sunucu kayıtları: Gerçek botların hangi adresleri, ne sıklıkla ve hangi yanıt koduyla istediği, tahmin yerine kanıt sağlar.

Araçlar arasındaki farkları baştan kabul edin. Bir tarayıcı aracı "sorunsuz" dediğinde Google'ın aynı sayfayı dizinlediği anlamına gelmez; Search Console dizinlenmediğini söylediğinde de nedeni araç göstermeyebilir. Çelişki gördüğünüzde Google'ın kendi verisi önceliklidir, araç bulgusu ise nedeni bulmak için kullanılır.

Kapsamın bir parçası da "yapmayacaklarınızdır". Küçük bir blog için sunucu günlük analizi ve ayrıntılı tarama bütçesi çalışması gereksiz olabilir; çok dilli bir pazaryeri için ise hreflang ve yönlendirme kontrolü şarttır. Bu kararı denetimin başında yazılı yapın ki rapor kapsama sadık kalsın.

Tarama ve robots.txt Kontrolü

İlk soru şudur: Arama motorları önemli sayfalarınıza ulaşabiliyor mu? Tarama, dizinlemenin ön koşuludur; botlar bir adrese erişemiyorsa içeriğini değerlendiremez.

robots.txt dosyasında kontrol edilecekler şunlardır: Dosya kök dizinde ve erişilebilir mi, sunucu ona 200 mü yoksa hata mı döndürüyor, kurallar yanlışlıkla CSS, JavaScript ya da önemli klasörleri engelliyor mu, sitemap adresi doğru verilmiş mi? Google'ın robots.txt belgesi, dosyanın tarayıcılara hangi adreslere erişebileceğini söylediğini ve esas olarak sunucunun gereksiz isteklerle yorulmasını önlemek için kullanıldığını belirtir. Aynı belge, robots.txt'nin bir sayfayı Google'dan uzak tutma mekanizması olmadığını, engellenen bir adresin başka yerlerden bağlantı alırsa yine de dizinlenebileceğini ve sayfayı dizin dışında tutmak için noindex ya da parola korumasının kullanılması gerektiğini söyler. Bu ayrım, denetimde en sık yapılan hataların başında gelir: Dizinde görünmesini istemediğiniz sayfayı robots.txt ile engellemek, Google'ın noindex etiketini görmesini de engeller.

Engel kontrolünü adım adım yapmak için robots.txt testinde tarama engellerini bulma yazısındaki yöntemi izleyebilirsiniz. Orada kuralların nasıl sınandığı anlatılıyor; denetimde bunu tek bir kontrol satırı olarak tutun.

Taramanın ikinci boyutu verimliliktir. Büyük sitelerde botun sınırlı zamanını filtre sayfaları, sonsuz takvimler ve parametreli adresler tüketebilir. Küçük sitelerde bu nadiren sorundur. Sitenizin ölçeği hakkında emin değilseniz, tarama bütçesi optimizasyonu yazısı hangi sitelerin bu konuyu ciddiye alması gerektiğini ve nasıl ölçüleceğini açıklar.

Bu başlıkta bir kontrol listesi:

1. robots.txt erişilebilir ve beklenen yanıtı veriyor mu?
2. Önemli sayfalar, CSS ve JavaScript dosyaları engellenmiş mi?
3. Dizin dışı kalması gereken adresler robots.txt yerine noindex ile mi yönetiliyor?
4. Search Console tarama istatistiklerinde sunucu hatası ya da yanıt süresi artışı var mı?
5. Parametreli ve filtreli adresler kontrolsüz çoğalıyor mu?

Dizine Ekleme, noindex ve Canonical

Taranmak dizine girmek demek değildir. Bu başlıkta hangi sayfaların dizinde olması gerektiğini, hangilerinin olmaması gerektiğini ve gerçeğin bunlarla örtüşüp örtüşmediğini kontrol edersiniz.

Denetim için önce Search Console'daki dizin kapsamı raporunu açın ve durumları iki gruba ayırın: dizinde olması gerekenler ama olmayanlar, ve dizinde olmaması gerekenler ama olanlar. Birinci grup görünürlük kaybıdır, ikinci grup ise kalite ve kanibalizasyon riskidir. Bir sayfanın dizinlenmeme nedeni sayfanın kendisinde, yönlendirmesinde, kalitesinde ya da sinyallerinde olabilir. Sistematik bir teşhis için Google'ın indekslemediği sayfaların teşhisi yazısı, durum etiketlerini nasıl okuyacağınızı ve her birinde ne yapacağınızı sıralar.

Üç sinyali birbiriyle karşılaştırın:

• noindex: Sayfa dizinden çıkarılmak isteniyor. Yanlışlıkla önemli bir sayfada, özellikle şablon ya da test ortamından kalma bir etiket olarak bulunması, denetimin en değerli bulgularından biridir.
• canonical: Sayfa kendini mi gösteriyor, başka bir adresi mi? Canonical bir öneridir; Google başka bir adresi seçebilir. Birden çok sayfa aynı canonical'a işaret ediyorsa içerik gerçekten aynı mı, yoksa yanlış yapılandırma mı?
• Sitemap ve iç linkler: Bunlar da hangi adresin tercih edildiğini gösterir. Canonical bir adresi söylerken sitemap başka bir adresi listeliyorsa Google'a çelişkili sinyal vermiş olursunuz.

Canonical hatalarının türleri ve nasıl sınanacağı için canonical etiketi hataları ve denetimi yazısına bakın. Denetim sırasında hedefiniz her hatayı çözmek değil, sayfa türü başına doğru kuralı doğrulamaktır: ürün sayfaları kendini mi gösteriyor, filtre sayfaları kategoriye mi?

Bu aşamada bir not düşün: Hangi sayfa türlerinde dizin dışı bırakma kararı bilinçli, hangilerinde kazara? Bilinçli kararlar rapora girmez, kazara olanlar ise yüksek öncelikli bulgudur.

Sitemap Sağlığı

Sitemap, Google'a önemsediğiniz adreslerin listesini verir. Zorunlu değildir, ancak büyük ya da sık güncellenen sitelerde keşfi hızlandırır ve denetim için yararlı bir referanstır, çünkü "sitemap'te olan ama sorunlu sayfaları" ortaya çıkarır.

Sağlıklı bir sitemap şu şartları taşır: Yalnızca dizinlenmesini istediğiniz, 200 yanıtı veren ve kendi canonical'ı olan adresleri içerir. İçinde yönlendirilen, noindex'li, 404 veren ya da canonical'ı başka yere işaret eden adresler varsa liste Google'a çelişkili sinyal verir. Dosya boyutu ve adres sayısı sınırlarına uyulmalı, büyük sitelerde sitemap dizini kullanılmalı, robots.txt'de ve Search Console'da doğru adres tanımlanmalıdır.

Denetimde pratik yöntem şudur: Sitemap'teki tüm adresleri bir tarayıcı aracına liste olarak verin ve her adresin durum kodunu, noindex durumunu ve canonical'ını karşılaştırın. Sapma gösteren satırlar doğrudan düzeltme listesidir. Ayrıntılı kontroller ve hata çözümleri için XML sitemap denetimi ve hata çözümü yazısı, sık görülen hataları ve çözümlerini ayrı ayrı anlatır.

Küçük sitelerde sitemap ikincil önemdedir: Google'ın kendi başlangıç kılavuzu da sitemap'in zorunlu olmadığını belirtir. O yüzden bu kalemin önceliğini sitenin büyüklüğüne ve güncelleme sıklığına göre ayarlayın. Yeni içeriğin keşfi hızlıysa ve iç linkler sağlamsa, sitemap sorunu düşük öncelikli kalabilir.

Yönlendirme ve Durum Kodları

Her adres bir durum kodu döndürür ve bu kod botlara sayfanın kaderini söyler. Denetimde amaç, kodların sayfanın gerçek durumuyla uyuşmasını sağlamaktır.

En sık bulunan sorunlar yönlendirme zincirleri ve döngüleridir. Bir adres üç ya da dört adım sonra hedefe ulaşıyorsa hem botlar hem kullanıcılar zaman kaybeder; döngü ise sayfayı tamamen erişilemez kılar. Çözüm genellikle zinciri tek adıma indirmek ve iç linkleri doğrudan son adrese yönlendirmektir. Adım adım yöntem için yönlendirme zinciri ve döngüsü nasıl düzeltilir yazısını kullanın.

Bir de "yumuşak 404" sorunu vardır: Sayfa 200 döndürür ama içeriği "bulunamadı" demektir. Bu tür sayfalar hem kullanıcıyı hem Google'ı yanıltır. Denetimde 200 dönen ama neredeyse boş olan sayfa şablonlarını ayrıca arayın.

Durum kodu denetiminde küçük bir kural işe yarar: Önemli sayfaya giden her iç link doğrudan 200 veren adrese gitmelidir. Yönlendirme, dış bağlantıların ve eski adreslerin güvenlik ağıdır; iç gezinmenin normal yolu olmamalıdır.

Site Yapısı ve İç Linkler

İç linkler, hem kullanıcıya hem botlara hangi sayfaların önemli olduğunu ve birbirine nasıl bağlandığını söyler. Site yapısı denetiminde üç soru sorulur.

1. Derinlik: Önemli sayfalara ana sayfadan kaç tıklamada ulaşılıyor? Çok derinde kalan sayfalar geç keşfedilir ve az önemsenir.
2. Yetim sayfalar: Hiçbir iç link almayan ama sitemap'te ya da dizinde bulunan sayfalar var mı?
3. Anchor kalitesi: İç linklerin metni, hedef sayfanın konusunu anlatıyor mu, yoksa "buraya tıklayın" gibi boş ifadeler mi kullanılıyor?

Pratik kontrol için tarayıcı aracından sayfa başına gelen iç link sayısını çıkarın ve en önemli iş sayfalarınızı bu listede arayın. Beklenenden az link alan stratejik bir sayfa, hızlı kazanç fırsatıdır; çünkü bir iç link eklemek çoğu zaman en düşük emekli düzeltmelerden biridir.

Menü, alt bilgi ve sayfa içi bağlam linklerini ayrı düşünün. Menü ve alt bilgi linkleri sitenin her yerinde tekrar ettiği için bağlam sinyali zayıftır; asıl değer içerik içinde, konuyla ilgili doğal geçen linklerden gelir. Kategori ve alt kategori yapısının mantıklı bir hiyerarşi oluşturup oluşturmadığını, breadcrumb kullanılıp kullanılmadığını da bu aşamada kontrol edin.

Son olarak kırık iç linkleri tarayın. Kırık bir iç link hem kullanıcıyı hem botu çıkmaz sokağa götürür. Bu tür düzeltmeler çoğunlukla toplu yapılabilir ve emek-etki oranı yüksektir.

JavaScript ve Sayfa Oluşturma

Birçok modern site içeriği tarayıcıda JavaScript ile oluşturur. Bu, denetimde ayrı bir soru doğurur: Google'ın gördüğü sayfa, kullanıcının gördüğü sayfayla aynı mı?

İlk kontrol, ham HTML ile işlenmiş HTML'i karşılaştırmaktır. Önemli içerik, başlıklar ve linkler yalnızca JavaScript çalıştıktan sonra ortaya çıkıyorsa, bu içeriğin dizinlenmesi işleme sürecine bağlı hâle gelir. Search Console'daki URL Denetimi aracı, Google'ın sayfayı nasıl işlediğini gösteren birincil kaynaktır. Navigasyon linklerinin gerçek bağlantı olarak (href ile) var olup olmadığını, tıklamayla değişen bir olay dinleyicisinden mi oluştuğunu da kontrol edin; botlar yalnızca ilkini güvenilir biçimde izler.

Aşağıdaki durumlar denetimde dikkat gerektirir:

• Ürün ya da makale metni sayfa yüklendikten sonra eklenen bir istekle geliyorsa.
• Başlık, meta açıklama ve canonical etiketleri JavaScript ile değiştiriliyorsa.
• Sonsuz kaydırma sayfalamanın yerine geçiyorsa ve ikinci sayfaya giden gerçek adres yoksa.
• Önemli kaynaklar robots.txt ile engelleniyorsa ve bu yüzden sayfa tam işlenemiyorsa.

Ayrıntılı teşhis, farklı işleme yaklaşımları ve çözüm seçenekleri için JavaScript SEO, rendering ve indeksleme yazısını okuyun. Şemsiye denetimde yeterli olan, "kritik içerik ham HTML'de var mı, değilse işlenmiş HTML'de güvenilir biçimde görünüyor mu" sorusunu cevaplamaktır.

Hız ve Sayfa Deneyimi Özeti

Sayfa hızı ayrıntılı bir konudur; bu rehberde yalnızca denetim özeti veriyoruz. Ölçüm tarafında web.dev, Core Web Vitals için üç metrik ve hedef eşik tanımlar: En büyük içerikli boyama (LCP) sayfa yüklenmeye başladıktan sonra 2,5 saniye içinde gerçekleşmelidir; etkileşimden sonraki boyama (INP) 200 milisaniye ya da altında olmalıdır; kümülatif düzen kayması (CLS) 0,1 ya da altında kalmalıdır. Değerlendirme, sayfa yüklemelerinin yetmiş beşinci yüzdelik diliminde, mobil ve masaüstü ayrı ayrı yapılır ve sayfanın geçmesi için üç hedefin de karşılanması gerekir.

Denetimde pratik yaklaşım şu: Search Console'daki Core Web Vitals raporundan zayıf ve iyileştirme gerektiren URL gruplarını bulun, bu grupların hangi sayfa şablonlarından geldiğini ayırın ve kök nedeni şablon düzeyinde arayın. Tek tek sayfaları düzeltmek yerine şablonu düzeltmek, binlerce sayfayı bir seferde iyileştirir.

Hız bulgularını önceliklendirirken şunu unutmayın: Sayfa deneyimi, tek başına sıralamayı belirleyen bir etken değildir; içeriğin alaka düzeyi ve niyet uyumu çoğu sorguda daha belirleyicidir. Bu nedenle çok ciddi bir hız sorunu yoksa hız maddesini denetim sırasında tarama, dizinleme ve yönlendirme sorunlarının arkasına yerleştirmek makuldür. Hız konusunun derinine inmek istiyorsanız sitenizin sayfa şablonlarını ve ölçüm kaynaklarını ayrı bir performans çalışmasına bırakın.

Denetim raporuna eklenecek asgari bilgi: sorunlu şablon, ilgili metrik, tahmini kök neden ve düzeltmenin emek seviyesi.

Yapılandırılmış Veri ve Çok Dillilik

Son teknik katman, sayfanın ne olduğunu makineye anlatan işaretleme ve çok dilli sitelerde dil eşleşmesidir.

Yapılandırılmış veri tarafında üç şeyi kontrol edin: İşaretleme sayfadaki görünür içerikle uyuşuyor mu, sözdizimi geçerli mi ve kullandığınız türler gerçekten ilgili mi? schema.org, tür ve özellik tanımlarının kaynağıdır; Google ise hangi türlerin zengin sonuç için desteklendiğini ayrıca belgeler. Her türü eklemek amaç değildir; işaretleme, sayfadaki içeriğin doğru bir yansıması olmalıdır. Sayfada olmayan bir bilgiyi işaretlemek ilke ihlalidir ve işe yaramaz.

Çok dilli sitelerde hreflang, aynı içeriğin diğer dil sürümlerini birbirine bağlar. Denetimde kontrol edilecekler: Karşılıklı (iki yönlü) işaretleme var mı, dil ve bölge kodları geçerli mi, her sürüm kendini de gösteriyor mu, hreflang'deki adresler canonical adreslerle aynı mı? En sık görülen hata, bir dilin diğerine işaret edip karşılığının bulunmamasıdır. Ayrıntılı kontrol adımları için hreflang etiketlerini denetleme rehberi yazısına bakın.

Türkçe ve İngilizce sürümü olan siteler için ek bir kontrol daha vardır: Her dilin sayfaları kendi dilinde mi sunuluyor, dil değiştirici aynı içeriğin karşılığına mı götürüyor, meta başlık ve açıklamalar da çevrilmiş mi? Teknik doğru olup içerik yarım çevrilmiş bir sürüm, kullanıcı için de arama motoru için de kafa karıştırıcıdır.

Önceliklendirme Matrisi: Etki ve Emek

Denetim bittiğinde elinizde onlarca bulgu olur. Hepsini aynı anda çözmek mümkün değildir, bu yüzden sıra gerekir. En basit ve etkili yöntem, her bulguyu iki eksende puanlamaktır: Etki (düzeltilirse görünürlük ve dizinleme üzerinde ne kadar fark yaratır) ve emek (düzeltmek ne kadar iş gerektirir).

Etki puanını verirken bir sıra düzeni kullanın: Önce taramayı ve dizinlemeyi engelleyen sorunlar (robots.txt engeli, yanlış noindex, sunucu hataları), sonra sinyalleri karıştıran sorunlar (canonical çelişkileri, yönlendirme zincirleri, sitemap hataları), en sonda optimizasyon sayılan konular (hız ayarı, ek işaretleme). Çünkü bir sayfa dizinde değilse, onun hızını ayarlamanın bir anlamı yoktur.

Etkiyi değerlendirirken sayfanın önemini de hesaba katın. Satış getiren bir kategori sayfasındaki canonical hatası, kimsenin okumadığı bir etiket sayfasındaki aynı hatadan çok daha yüksek önceliklidir. Her bulgunun yanına etkilenen sayfa sayısını ve sayfa türünü yazın.

Emek tarafında "kim yapacak" sorusu belirleyicidir. İçerik ekibinin yapabileceği bir başlık düzeltmesi ile geliştirici sprinti gerektiren bir yeniden işleme değişikliği aynı emek sınıfında değildir. Matrisi doldururken sorumluyu da yazın.

Örnek Şablon: Teknik SEO Denetim Önceliklendirme Tablosu

Aşağıdaki tablo, kurgu bir örnek olarak hazırlanmıştır; satırlardaki bulgular, sayılar ve sorumlular uydurmadır ve yalnızca biçimi göstermek içindir. Kendi sitenizin bulgularıyla değiştirin. Kurgu senaryo: Orta ölçekli bir ürün sitesi, Türkçe ve İngilizce sürümleriyle denetleniyor.

Tabloyu kullanırken öncelik sütununu etki, emek ve yukarıdaki sıra düzenine göre bilinçli verin; tabloyu sırasıyla doldurmak yerine, önce dizin ve tarama engellerini yukarı çekin. Tabloyu paydaşlarla paylaşırken her satırın yanına bir doğrulama yöntemi de yazın: Düzeltmeden sonra hangi raporda ya da hangi araçla sorunun kapandığı görülecek?

Sıkça Sorulan Sorular

Teknik SEO denetimi ne sıklıkla yapılmalı?

Sabit bir süre yoktur. Büyük bir yayın, taşıma ya da altyapı değişikliğinden sonra, ayrıca belirli aralıklarla (örneğin çeyrekte bir kez) tam denetim yapılır. Aradaki dönemlerde Search Console'daki dizin kapsamı ve tarama raporlarını düzenli izlemek yeterli olabilir. Sıklığı sitenin büyüklüğü ve değişim hızı belirler.

Denetime hangi başlıktan başlanmalı?

Taramayı ve dizine eklemeyi engelleyen sorunlardan: robots.txt erişimi, yanlış noindex, sunucu hataları ve durum kodları. Bir sayfa dizinde değilse hızını ya da işaretlemesini ayarlamanın anlamı yoktur. Sonra canonical, sitemap ve yönlendirme çelişkilerine, en sonda optimizasyon konularına geçin.

Hangi araçlar denetim için gereklidir?

Search Console zorunlu birincil kaynaktır. Buna ek olarak bir site tarama aracı sayfa düzeyinde veriyi toplar. Sunucu kayıtları gerçek bot isteklerini gösterir. Araç sayısından çok, çelişen sonuçlarda Google'ın kendi verisine öncelik vermek önemlidir. Küçük bir sitede iki kaynak çoğu zaman yeterlidir.

Bulunan sorunlar nasıl önceliklendirilir?

Her bulguyu etki ve emek eksenlerinde puanlayın. Yüksek etki ve düşük emek hemen yapılır, yüksek etki ve yüksek emek planlanır. Etkiyi değerlendirirken önce tarama ve dizine ekleme engellerini, sonra sinyal çelişkilerini, en son optimizasyonları sıralayın; etkilenen sayfanın önemini de hesaba katın.

Küçük bir site için denetim kapsamı nasıl daraltılır?

Kapsamı sitenin gerçek hedeflerine göre daraltın. Taranabilirlik, dizin kapsamı, canonical, durum kodları, iç linkler ve temel hız kontrolü çoğu küçük site için yeterlidir. Tarama bütçesi çalışması, ayrıntılı günlük analizi ve karmaşık hreflang kontrolü yalnızca site büyüklüğü ve yapısı gerektirdiğinde eklenir.

Teknik denetim sonucu müşteriye nasıl raporlanır?

Önce kısa bir özet verin: en kritik üç bulgu, etkisi ve önerilen sıra. Ardından önceliklendirme tablosunu, her satır için sorumluyu ve düzeltme sonrası doğrulama yöntemini ekleyin. Teknik ayrıntıyı ek bölüme bırakın. Sonuç beklentisini abartmadan yazın; düzeltmelerin etkisi zamanla görülür.

Sonuç ve Sonraki Adım

İyi bir teknik denetim, uzun bir uyarı listesi değil, sıralı bir karar belgesidir. Kapsamı yazın, taramadan dizinlemeye doğru ilerleyin, sinyal çelişkilerini bulun, hız ve işaretleme gibi iyileştirmeleri sona bırakın ve bulguları etki ile emeğe göre sıralayın. Her satır bir sahibe ve bir doğrulama yöntemine bağlandığında denetim raporu uygulanabilir hâle gelir.

Denetimin ardından yazılacak ya da yenilenecek içerik çıktıysa, bu işi ayrı bir üretim hattı olarak yönetmek gerekir. Metinleri profesyonel olarak hazırlatmak isterseniz makale yazımı hizmetine göz atın; Akua Adforce'ta sipariş akışı seçim, sepet, ödeme, satıcı onayı ve teslimat bildirimiyle ilerler, bir sorun olursa itiraz yolu da vardır.