32. Bölüm: SEO Audit Nasıl Yapılır?

Son güncelleme: 1 Kasım 2026.

SEO Audit denildiğinde çoğu kişinin aklına uzun bir hata listesi geliyor:

• 500 tane 404
• 300 tane eksik Meta Description
• 120 tane tekrarlanan Title
• 40 tane canonical problemi

Sonra rapor hazırlanıyor, müşterinin önüne bırakılıyor ve “Bunların hepsini düzeltmeniz gerekiyor.” deniyor.

Bence iyi bir SEO Audit bundan çok daha fazlası. Asıl amaç mümkün olduğunca fazla hata bulmak değil.

Sitenin büyümesini gerçekten engelleyen problemleri bulmak, doğru sıraya koymak ve daha sonra tekrar bozulmadığından emin olmak.

Çünkü teknik olarak hata görünen her şey aynı önemde değil. Hatta bazı şeyler hiç problem olmayabilir.

1. SEO Audit nedir?

SEO Audit, bir sitenin SEO açısından mevcut durumunu sistematik şekilde analiz etmek. Ama bunu sadece teknik tarama olarak düşünmemek gerekiyor.

İyi bir audit en azından şu alanlara bakmalı:

• Teknik SEO
• Tarama ve dizinleme
• Site mimarisi
• İçerik
• Anahtar kelime hedefleme
• İç linkleme
• Backlink profili
• Rakipler
• Kullanıcı davranışı
• Dönüşüm
• Site performansı
• Ölçümleme altyapısı

Yani SEO Audit sadece “site hataları” raporu değil. Bence daha doğru tanım şu:

Sitenin organik büyümesini neyin engellediğini anlamaya çalışmak.

2. Audit’e araçtan değil, hedeflerden başlayın

Screaming Frog’u açıp siteyi taramak kolay. Semrush Site Audit’i çalıştırmak da kolay. Ama ilk soru bunlar olmamalı.

Önce şunları anlamak gerekiyor:

• Site ne satıyor?
• Hedef pazar ne?
• SEO’dan ne bekleniyor?
• Ana ticari sayfalar hangileri?
• En önemli ürün veya hizmetler neler?
• Müşterinin problemi ne?
• Trafik mi artırılmak isteniyor?
• Lead mi?
• Satış mı?
• Marka görünürlüğü mü?

Çünkü aynı hata farklı sitelerde farklı önem taşır. Örneğin 404 problemi bir haber sitesinde başka, e-ticarette başka, küçük kurumsal sitede başka sonuç doğurabilir.

3. İlk olarak veriye bakarım

Audit’e başlamadan önce mümkünse şu kaynaklara erişmek isterim:

• Google Search Console
• Google Analytics
• Google Tag Manager
• Semrush veya benzeri SEO araçları
• Screaming Frog
• Sitemap
• robots.txt
• Gerekiyorsa sunucu logları
• CRM veya satış verileri

Çünkü sadece crawler’a bakarsak sitenin teknik fotoğrafını görürüz. Ama sitenin gerçekten nasıl performans gösterdiğini göremeyiz.

Örneğin teknik olarak kusursuz görünen bir kategori sayfası hiç trafik almıyor olabilir. Ya da teknik olarak bazı eksikleri olan bir sayfa sitenin en çok satış yapan sayfası olabilir. Bu fark önemli.

4. Search Console’dan neye bakarım?

Audit’in en önemli kaynaklarından biri Search Console. Özellikle şu alanlara bakarım:

• Organik tıklama trendi
• Gösterim trendi
• Ortalama konum
• Markalı / Markasız sorgular
• En güçlü sayfalar
• Düşen sayfalar
• 5–15 pozisyon aralığındaki fırsatlar
• Dizinleme problemleri
• Google’ın seçtiği canonical
• Ülke ve cihaz farkları
• Core Web Vitals

Buradaki temel soru:

Google siteyi şu anda nasıl görüyor?

5. Analytics tarafında neye bakarım?

Search Console arama tarafını gösteriyor. Analytics ise kullanıcı siteye geldikten sonra ne olduğunu anlamamıza yardımcı oluyor. Özellikle şunlar önemli:

• Organik oturumlar
• Açılış sayfası (Landing Page) performansı
• Dönüşüm
• Gelir
• Etkileşim
• Cihaz farkları
• Ülke farkları
• Kullanıcı yolu

Bir sayfa çok trafik alıyor olabilir ama hiç dönüşüm üretmiyor olabilir. Başka bir sayfa düşük trafikle çok yüksek ciro üretiyor olabilir. Audit sırasında bunu bilmezsek yanlış önceliklendirme yapabiliriz.

6. Teknik tarama

Burada Screaming Frog gibi crawler araçları devreye giriyor. Kontrol edilebilecek şeylerden bazıları:

• 3xx
• 4xx
• 5xx
• Canonical
• Noindex
• Title
• Meta Description
• H1
• H2
• İç linkler
• Dış linkler
• Orphan Page
• Redirect Chain
• Redirect Loop
• Görseller
• Alt Text
• Sayfa boyutu
• Sunucu cevap süresi
• Sitemap karşılaştırması

Ama tekrar:

Crawler raporu SEO Audit değildir.

Crawler bize ham veriyi gösterir. Biz onun gerçekten problem olup olmadığına ve ne kadar önemli olduğuna karar veririz.

7. 404 gördük, hemen hata mı?

Hayır. Bir URL gerçekten kaldırıldıysa ve karşılığı yoksa 404 normal olabilir.

Audit raporunda “500 tane 404 var.” demek yerine şunlara bakmak gerekiyor:

• Bu URL’lere iç link var mı?
• Trafik alıyor muydu?
• Backlinki var mı?
• Yeni karşılığı var mı?
• Sitemap’te mi?
• Kullanıcı buraya hâlâ ulaşıyor mu?

Eski bir kampanya sayfası ve hiçbir değeri yoksa 404 kalabilir. Ama güçlü backlinki olan önemli bir ürün sayfası yanlışlıkla 404 olmuşsa çok daha kritik.

Aynı durum kodu. Tamamen farklı öncelik.

8. Title ve Meta Description eksikleri

Araçlar bunu çok sever. “1.200 sayfada Meta Description eksik.” Kırmızı uyarı.

Ama audit raporunda hemen “1.200 Meta Description yazılmalı.” demem. Önce bu sayfalar ne?

• Noindex mi?
• Canonical başka yere mi gidiyor?
• Trafik alıyor mu?
• Ticari mi?
• Google’da görünmesini istiyor muyuz?

Eğer sayfaların yarısı zaten değersizse Meta Description yazmak kaynak israfı olabilir. Bu yüzden:

Hata listesiyle aksiyon listesi aynı şey değil.

9. Tarama ve dizinleme analizi

Burada şu sorulara bakarım:

• Google önemli sayfaları keşfedebiliyor mu?
• Sitemap doğru mu?
• Sitemap’te gereksiz URL var mı?
• robots.txt yanlış alanları kapatıyor mu?
• Noindex kullanımı doğru mu?
• Canonical sinyalleri tutarlı mı?
• Search Console’da “Tarandı: Şu anda dizine eklenmiş değil (Crawled – currently not indexed)” sayfaları artmış mı?
• “Bulundu: Şu anda dizine eklenmiş değil (Discovered – currently not indexed)” problemi var mı?
• Parametre URL’leri çoğalıyor mu?
• Dizin Şişmesi (Index Bloat) var mı?

25. bölümde konuştuğumuz gibi:

Daha fazla indeks her zaman daha iyi değil.

Audit’in amacı Google’a daha çok sayfa göndermek değil, doğru sayfaları göndermek.

10. Sitemap ile gerçek URL yapısını karşılaştırmak

Bu çok basit ama faydalı bir kontrol. Örneğin:

• Sitemap: 20.000 URL
• Crawler: 85.000 URL
• Google: 120.000 URL biliyor

Bu fark bize bir şey anlatıyor. Fazladan URL’ler nereden geliyor? Şu gibi kaynaklar olabilir:

• Filtreler
• Parametreler
• UTM’ler
• Eski URL’ler
• Arşivler
• Site içi arama
• Etiketler
• HTTP / HTTPS
• www / non-www

Bu karşılaştırma özellikle büyük sitelerde çok değerli.

11. Bazen sitemap düzgün görünür ama yine de problem sitemap’tedir

2. bölümde bahsettiğimiz haber sitesi örneği burada çok iyi oturuyor. Sorunumuz şuydu:

Yeni haberler Google’da geç indeksleniyordu.

Screaming Frog “Sitemap hatalı.” demiyordu. Search Console “Sitemap 10 dakika cache’leniyor.” diye bir uyarı vermiyordu. Teknik olarak sitemap açılıyordu, XML geçerliydi ve sunucu hata vermiyordu.

Ama yeni haber URL’leri sitemap’e yaklaşık 10 dakika geç giriyordu. Normal bir kurumsal sitede 10 dakika çok önemli olmayabilir. Haber sitesinde önemli.

Burada hatayı bir araçtan bulmadık. Önce problemi gördük:

Haberler neden geç indeksleniyor?

Sonra ihtimalleri analiz ettik:

• Google URL’yi nasıl keşfediyor?
• İç link ne zaman oluşuyor?
• Sitemap’e ne zaman giriyor?
• Sunucu tarafında gecikme var mı?
• Cache var mı?

Sonunda sitemap’in cache’lendiğini bulduk. Cache süresini saniyelere indirdiğimizde geç indeksleme problemi büyük ölçüde azaldı.

Bence bu örnek SEO Audit’in ne olduğunu çok güzel anlatıyor.

Araçta hata görünmüyor olması, problem olmadığı anlamına gelmiyor.

12. Bazen audit’in başlangıç noktası hata değil, belirtidir

Bu ayrımı önemli buluyorum. Örneğin:

• Trafik düştü.
• İndeksleme gecikti.
• Kategori görünürlüğü kayboldu.
• Mobil dönüşüm düştü.
• Google yanlış canonical seçiyor.
• Bir ülkenin trafiği aniden azaldı.

Bunlar bize sebebi söylemiyor. Bunlar belirti.

Audit sırasında süreç bazen şöyle ilerliyor:

Belirti → ihtimaller → veri → test → sebep → çözüm

SEO araçları hazır hata listelerinde çok iyiler. Ama gerçek projelerdeki bazı problemler için bizim “Bu neden oluyor olabilir?” sorusunu sormamız gerekiyor.

13. Site mimarisi

Audit sırasında sadece tek tek sayfalara bakmam. Sitenin nasıl organize edildiğine de bakarım. Örneğin:

• Ana kategoriler doğru mu?
• Alt kategoriler mantıklı mı?
• Kullanıcı ürüne kaç tıkta ulaşıyor?
• Önemli sayfalar çok derinde mi?
• Breadcrumb var mı?
• İç link ağı dengeli mi?
• Orphan Page var mı?
• Aynı konu birden fazla yerde mi dağılmış?

Bazen problem içerik değil.

Mimari.

Google iyi içeriği buluyor ama site içindeki önemini yeterince anlayamıyor olabilir.

14. İç link analizi

Audit sırasında şunlara bakmak çok faydalı:

• Hangi sayfalar en çok iç link alıyor?
• Hangi önemli sayfalar çok az iç link alıyor?
• İç link anchor’ları anlamlı mı?
• Kullanıcı ilgili içeriğe yönlendiriliyor mu?
• Orphan Page var mı?
• Kategori ile ürün ilişkisi doğru mu?
• Blog içeriği ticari sayfalara bağlanıyor mu?

31. bölümdeki basketbol ayakkabısı örneğinde olduğu gibi içerik trafik alabilir. Ama kullanıcı ürüne yönlendirilmiyorsa ticari açıdan görevini yerine getirmiyor olabilir.

Teknik olarak sayfa çalışıyor. Stratejik olarak çalışmıyor. Audit bunu da görmeli.

15. İçerik analizi

Teknik taraf düzgün olsa bile site yükselmeyebilir. O zaman içerik tarafına bakmak gerekiyor. Örneğin:

• Arama niyeti doğru mu?
• İçerik kullanıcı sorusunu cevaplıyor mu?
• Güncel mi?
• Çok benzer sayfalar var mı?
• İçerik çakışması var mı?
• Rakip daha iyi ne yapıyor?
• Sayfa sadece anahtar kelime için mi yazılmış?
• Gerçek deneyim var mı?
• Kullanıcıya karar desteği sunuyor mu?
• İçerikten ticari sayfalara geçiş var mı?

Burada sadece kelime sayısına bakmam. 300 kelimelik çok iyi sayfa, 3.000 kelimelik kötü sayfadan daha değerli olabilir.

16. İçerik Eskimesi (Content Decay)

Audit sırasında eski içeriklere özellikle bakmak gerekir.

Örneğin “2023 En İyi SEO Araçları” sayfası hâlâ trafik almaya çalışıyorsa güncelliğini incelemek gerekir. İçerik için şu kararı vermek gerekir:

• Güncellenecek mi?
• Birleştirilecek mi?
• Yönlendirilecek mi?
• Kaldırılacak mı?

Bazen yeni içerik yazmak yerine eski içeriği düzeltmek daha hızlı sonuç verir.

17. Anahtar Kelime Çakışması (Keyword Cannibalization)

Birbirine çok benzeyen 5 sayfa aynı sorgu için yarışıyor olabilir. Örneğin:

• En iyi kahve makineleri
• En iyi ev tipi kahve makineleri
• Ev için kahve makinesi önerileri
• Kahve makinesi tavsiyesi

Aynı arama niyetini hedefliyorlarsa sayfaları yeniden değerlendirmek gerekebilir. Şu gibi çözümler değerlendirilebilir:

• Birleştirme
• Yeniden konumlandırma
• Canonical
• İç link
• Yönlendirme

18. Rakip analizi

Rakip analizi audit’in önemli parçalarından biri. Ama “Rakipte ne varsa biz de yapalım.” şeklinde değil.

Şunlara bakıyorum:

• Rakip hangi sorgularda güçlü?
• Hangi içerik türleri trafik alıyor?
• Hangi kategori yapısı var?
• Hangi sayfaları backlink alıyor?
• Hangi konularda bizden daha iyi?
• Biz hangi konularda daha iyiyiz?
• Hangi İçerik Boşlukları (Content Gap) var?
• Hangi Backlink Boşlukları (Link Gap) var?

Bazen sitenin hiçbir büyük teknik problemi yoktur. Rakip sadece bizden çok daha güçlüdür. Bu da audit sonucudur.

19. Backlink analizi

Burada şu alanlara bakarım:

• Referans Veren Alan Adı (Referring Domain)
• Link kalitesi
• Konu alakası
• Link verilen sayfalar
• Anchor Text
• Follow / Nofollow
• Yeni linkler
• Kaybedilen linkler
• Rakip Link Gap
• Şüpheli linkler

Ama audit raporuna “12.000 toxic backlink bulundu, hemen Disavow.” yazmam.

30. bölümde konuştuğumuz gibi Toxic Score Google’ın resmi metriği değil. Gerçek riski ayrıca değerlendirmek gerekiyor.

20. Core Web Vitals ve site performansı

Bunu 24. bölümde detaylı konuşmuştuk. Audit sırasında şunlar incelenebilir:

• LCP
• INP
• CLS
• TTFB
• Görseller
• JavaScript
• Üçüncü taraf scriptleri
• Cache
• CDN

Ama tekrar aynı kural: PageSpeed 72 görmek tek başına “Büyük SEO problemi.” demek değil. Gerçek kullanıcı verisi, sayfanın önemi ve iş etkisi birlikte değerlendirilmeli.

21. Mobil deneyim

Google mobil sürümü temel aldığı için mobil taraf kritik. Şunlar kontrol edilebilir:

• Mobilde içerik eksik mi?
• İç linkler aynı mı?
• Kullanıcı menüye ulaşabiliyor mu?
• Butonlar çalışıyor mu?
• Pop-up ekranı kaplıyor mu?
• Checkout rahat mı?
• Mobil hız kötü mü?
• Yapılandırılmış Veri (Structured Data) tutarlı mı?

Masaüstünde çok güzel olup mobilde problemli sitelere hâlâ rastlıyoruz.

22. Yapılandırılmış Veri (Structured Data) ve Schema

Audit sırasında Schema tarafına da bakarım:

• Doğru Schema kullanılıyor mu?
• Hatalar var mı?
• Sayfadaki bilgiyle uyumlu mu?
• Eksik alan var mı?
• Zengin Sonuçlar Testi’ni (Rich Results Test) geçiyor mu?
• Google gerçekten bu türü destekliyor mu?

Ama Schema çokluğu başarı değildir. Doğru sayfada doğru yapılandırılmış veri önemli.

23. Uluslararası sitelerde ek kontroller

Uluslararası bir siteyse audit biraz daha genişler. Özellikle şunlar incelenmeli:

• Hreflang
• Dil kodları
• Ülke kodları
• Karşılıklı bağlantılar
• x-default
• Canonical ilişkisi
• Alt dizin / subdomain
• Para birimi
• İçerik yerelleştirmesi
• Ülke bazlı performans

Örneğin en-EN gibi yanlış kodlama bir şablon hatasıysa binlerce sayfayı aynı anda etkileyebilir.

24. Audit sırasında dönüşüm tarafına da bakılmalı

Bence burada klasik SEO Audit’ten biraz ayrılıyorum.

Teknik olarak her şey doğru olabilir. Ama şu durumlar olabilir:

• Kullanıcı ürünü bulamıyor
• Kullanıcı CTA göremiyor
• Form çok uzun
• Telefon numarası görünmüyor
• Fiyat bilgisi yok
• Ürün bağlantısı yok

Daha önce anlattığım müşteri örneğinde trafik yaklaşık %10 düşerken ciro yaklaşık %180 arttı. Çünkü amaç sadece daha fazla kullanıcı getirmek değil, doğru kullanıcıyı doğru ürüne yönlendirmekti.

Bu yüzden benim için audit sadece “Google siteyi anlayabiliyor mu?” sorusuna bakmıyor. Bir de “Kullanıcı geldiğinde yapmasını istediğimiz şeye ulaşabiliyor mu?” sorusuna bakıyor.

25. Ölçümleme altyapısını da audit’e dahil etmek gerekiyor

Bazen SEO açısından hiçbir bağlantısı yokmuş gibi görünen bir değişiklik ölçümlemeyi bozabiliyor.

Bir müşterimizde Google Analytics kodlarının siteden tamamen silindiğini fark ettik. Normalde “Analytics kodu neden silinsin?” diye düşünürsünüz. Ama oldu. Ve bunu fark edene kadar veri alamadık. Daha kötüsü, kaybedilen veriyi sonradan geri getiremiyorsunuz.

Bu nedenle audit sırasında şu gibi kontrolleri de yapmak gerekiyor:

• Google Analytics çalışıyor mu?
• Google Tag Manager çalışıyor mu?
• Dönüşümler ölçülüyor mu?
• Temel event’ler geliyor mu?
• Search Console bağlantıları doğru mu?

Ölçemediğimiz SEO’yu yönetmek çok daha zor.

26. Site açık mı? Bunu ayda bir kontrol etmek yetmez

Audit aylık yapılabilir. Ama bazı şeylerin aylık kontrol edilmesi yeterli değil. Bunların en önemlisi sitenin erişilebilirliği.

Müşteriyle çalışmaya başladığımızda yaptığımız ilk işlerden biri siteyi UptimeRobot benzeri bir izleme sistemine eklemek. Bu sistemler siteyi belirli aralıklarla kontrol ediyor. Site cevap vermediğinde e-posta, SMS veya bildirim gibi yöntemlerle haber verebiliyor.

Yakın zamanda yeni çalışmaya başladığımız bir müşterimizin sitesi yaklaşık 1 saat kapalı kaldı.

SEO yapıyoruz. Google Ads veriyoruz. İçerik üretiyoruz. Backlink çalışıyoruz. Ama site açılmıyorsa bunların hiçbirinin o anda anlamı kalmıyor.

Kullanıcı geliyor, site yok. Reklama para harcıyoruz, site yok. Googlebot geliyor, sunucu cevap vermiyor.

Bu yüzden bazı SEO kontrolleri periyodik değil, anlık izlenmeli.

Bence burada basit bir öncelik sırası var:

Önce site çalışacak. Sonra siteyi büyüteceğiz.

27. Sürekli izleme ile aylık audit aynı şey değil

Bunu iki ayrı katman gibi düşünüyorum.

Birinci katman sürekli izleme. Örneğin:

• Site açık mı?
• Sunucu cevap veriyor mu?
• SSL problemi var mı?
• Kritik servisler çalışıyor mu?

Bunların bazısını dakikalar içerisinde bilmek gerekiyor.

İkinci katman periyodik SEO Audit. Örneğin:

• Canonical yapısı
• Dizinleme
• İç linkler
• Sitemap
• robots.txt
• İçerik
• Backlinkler
• Core Web Vitals
• Analytics
• Dönüşümler

Bunları daha kapsamlı şekilde belirli periyotlarla kontrol ediyoruz.

Biri diğerinin alternatifi değil. İkisine de ihtiyaç var.

28. Hata listesinden önce etki listesini çıkarın

Audit tamamlandı. Elimizde 300 problem var. Şimdi en önemli aşama başlıyor. Hangisini önce çözeceğiz?

Ben problemleri kabaca şöyle sınıflandırmayı seviyorum:

• Kritik
• Yüksek
• Orta
• Düşük

Ama bunu sadece teknik hatanın büyüklüğüne göre yapmamak gerekiyor. İş etkisi de önemli.

Örneğin site tamamen kapalıysa bu en yüksek önceliklerden biri. Önemli kategori noindex olmuşsa yine kritik olabilir. Ama 20 eski blog yazısında Meta Description eksikliği çok daha düşük öncelik olabilir.

29. Etki x Efor yaklaşımı

Audit sonrası en kullanışlı yöntemlerden biri. Her işi iki eksende düşünebiliriz: etki ve efor. Dört grup çıkar:

İlk grup genellikle hızlı kazanımlar.

Örneğin önemli kategori yanlış canonical nedeniyle dizine girmiyor. Düzeltmek 10 dakika. Potansiyel etkisi yüksek. Bunu bekletmenin anlamı yok.

30. Her hata düzeltilmeli mi?

Hayır. Bence audit’in en önemli cevaplarından biri bu.

Araç 1.000 uyarı çıkarabilir. Ama bunların 700 tanesi iş açısından anlamsız olabilir.

SEO Audit’in kalitesi kaç hata bulduğu ile değil, hangi hataların gerçekten önemli olduğunu ayırabildiği ile ölçülmeli.

31. 5.000 hatayı müşteriye vermek kolay, 10 önemli problemi seçmek zor

Bence burada SEO uzmanının gerçek değeri ortaya çıkıyor.

Crawler raporunu dışarı aktarıp müşteriye göndermek birkaç dakika. Ama “Bu 5.000 hata içinden şu 8 konu önümüzdeki üç ayda en büyük etkiyi yaratacak.” diyebilmek tecrübe gerektiriyor.

Çünkü önceliklendirme için şunlar birlikte düşünülmeli:

• SEO
• İş modeli
• Kullanıcı davranışı
• Teknik altyapı
• Kaynak
• Rekabet

32. Yazılımcıya görev nasıl verilmeli?

Audit raporunda “Canonical hatalı.” yazmak yeterli değil. Yazılımcının anlaması gereken:

• Problem ne?
• Hangi URL’ler etkileniyor?
• Beklenen davranış ne?
• Mevcut davranış ne?
• Nasıl test edeceğiz?
• Önceliği ne?

Örneğin “/urun?color=x URL’lerinde canonical parametresiz ürün URL’sine gitmeli.” gibi net görev daha faydalı. Gerekirse örnek URL’ler ve beklenen çıktı da verilmeli.

33. Müşteriye verilecek rapor ile geliştirici raporu aynı olmamalı

Müşteriye problemi, etkisini, önceliğini ve iş sonucunu anlatmak gerekiyor. Geliştiriciye ise teknik detay, URL örneği, beklenen sonuç ve test yöntemi gerekiyor.

CEO’ya 200 satırlık canonical tablosu göstermek gereksiz. Yazılımcıya da “SEO’yu iyileştirelim.” demek işe yaramaz.

Aynı audit’in farklı hedef kitleler için farklı çıktıları olabilir.

34. Audit raporu nasıl olmalı?

Bence iyi audit raporu şu yapıda olabilir:

• Yönetici özeti
• Mevcut durum
• En kritik 5–10 problem
• Teknik SEO
• İçerik
• Site mimarisi
• Backlink
• Rakipler
• Dönüşüm / kullanıcı deneyimi
• Ölçümleme
• Önceliklendirme
• Yol haritası

Ama 150 sayfalık PDF olmak zorunda değil. Raporun amacı:

Bilgi göstermek değil, aksiyon aldırmak.

35. Audit sonunda mutlaka yol haritası çıkmalı

Problemler bulundu. Ama “Şimdi ne yapacağız?” sorusuna cevap yoksa audit eksik.

Örneğin şöyle bir yol haritası çıkabilir:

Her proje farklı. Ama sıra olmalı.

36. Biz SEO Audit’i her ay sıfırdan yapıyoruz

Burada bizim yaklaşımımız biraz daha sıkı. Müşterilerimizde SEO Audit’i sadece işe başladığımızda yapıp bırakmıyoruz.

Her ay yeniden kontrol ediyoruz.

Çünkü web sitesi yaşayan bir sistem:

• Yeni ürün ekleniyor.
• Tema güncelleniyor.
• Yazılım değişiyor.
• Yeni kategori açılıyor.
• Script ekleniyor.
• Kampanya kodları geliyor.
• Cache ayarları değişiyor.
• Yeni deploy yapılıyor.

Ve bir şeyi düzeltirken hiç beklemediğiniz başka bir şeyi bozabiliyorsunuz. Bu yüzden “Geçen ay kontrol etmiştik.” benim için yeterli değil.

37. Düzeltilen hata tekrar geri gelebilir

Bunu da gerçek bir müşteride yaşadık.

Canonical problemimiz vardı. Bulduk. Düzelttik. Kontrol ettik. Her şey doğru çalışıyordu.

Daha sonra sitede başka bir güncelleme yapıldı. Sonraki kontrollerimizde aynı canonical hatasının tekrar ortaya çıktığını gördük.

Eğer “Bunu zaten düzeltmiştik.” deyip bir daha kontrol etmeseydik uzun süre gözden kaçabilirdi.

Yazılım dünyasında buna Regresyon (Regression) deniyor. SEO tarafında da aynı mantık var.

Bir düzeltmenin yapılmış olması, sonsuza kadar doğru kalacağı anlamına gelmiyor.

38. Aylık audit biraz da SEO regresyon testi

Bu nedenle audit sırasında sadece yeni hata aramıyoruz. Daha önce düzelttiğimiz kritik alanların hâlâ doğru çalışıp çalışmadığını da kontrol ediyoruz. Örneğin:

• Canonical hâlâ doğru mu?
• Sitemap hâlâ doğru mu?
• Noindex yanlış yere gelmiş mi?
• Analytics hâlâ çalışıyor mu?
• GTM hâlâ sayfada mı?
• Redirect’ler bozulmuş mu?
• Yeni 404’ler oluşmuş mu?
• Kritik sayfalar hâlâ 200 dönüyor mu?
• robots.txt değişmiş mi?

Bunu biraz SEO regresyon testi olarak düşünebiliriz.

39. Audit’in amacı sadece yeni hata bulmak değildir

Bazen audit yaparsınız ve yeni ciddi problem bulamazsınız. Bu kötü bir audit değildir. Tam tersine sonuç “Her şey hâlâ doğru çalışıyor.” olabilir. Bu da değerli.

Çünkü Analytics kodunun silindiğini birkaç gün içinde fark etmekle üç ay sonra fark etmek aynı şey değil. Canonical hatasını birkaç URL’de yakalamakla binlerce URL’ye yayıldıktan sonra fark etmek de aynı şey değil.

40. Her şeyi aynı anda çözmeye çalışmak

Audit sırasında yapılan büyük hatalardan biri.

500 görev çıkıyor. Hepsi Jira’ya ekleniyor. Yazılım ekibi bakıyor: “Bunların hepsi mi acil?” Sonuç: Hiçbiri yapılmıyor.

Bence daha iyi yaklaşım: İlk kritik problemleri çöz. Sonucu ölç. Sonra devam et.

SEO’da bazen daha az görev, daha fazla sonuç üretir.

41. Sadece teknik SEO’ya bakmak

Bu da büyük hatalardan biri.

Site teknik olarak mükemmel olabilir. Ama şu durumda site yine yükselmeyebilir:

• İçerik kötü
• Ürün zayıf
• Arama niyeti yanlış
• Marka bilinmiyor
• Backlink yok
• Dönüşüm yok

Bu yüzden teknik audit ile SEO Audit’i aynı şey görmemek gerekiyor. Teknik analiz audit’in sadece bir parçası.

42. Rakipleri incelememek

Site kendi içinde çok iyi görünebilir. Ama Google’da tek başına yarışmıyoruz. Rakip:

• 10 kat daha fazla içerik üretmiş olabilir.
• Çok daha güçlü backlink profiline sahip olabilir.
• Kullanıcı niyetini daha iyi karşılıyor olabilir.
• Daha iyi ürün sunuyor olabilir.
• Marka talebi çok daha yüksek olabilir.

Audit sonunda sadece “Bizde ne yanlış?” değil, “Rakip bizden neyi daha iyi yapıyor?” sorusuna da cevap vermek gerekiyor.

43. Raporu yapıp bırakmak

Bence en kötü audit modeli bu.

SEO Audit hazırlanıyor. 150 sayfa. Toplantıda sunuluyor. Google Drive’a yükleniyor. Sonra kimse açmıyor. Altı ay sonra yeni audit isteniyor.

Audit’in değerli olabilmesi için görevlerin şu bilgileri takip edilmeli:

• Sahibi
• Önceliği
• Termin tarihi
• Durumu
• Sonucu

Bence audit raporundan daha önemli olan şey:

Audit sonrası proje yönetimi.

Bir sonraki bölümde (33) tam olarak bunu konuşacağız.

44. Ben audit sonunda ne görmek isterim?

En kısa haliyle şu soruların cevabını:

• Site şu anda çalışıyor mu?
• Ölçüm sistemleri doğru çalışıyor mu?
• Sitenin en büyük SEO problemi ne?
• En büyük fırsatı ne?
• İlk neyi düzelteceğiz?
• Bunun etkisini nasıl ölçeceğiz?
• Sonra ne yapacağız?

Bunların cevabı yoksa audit çok detaylı olsa bile eksik kalabilir.

Sonuç olarak

SEO Audit’in amacı bütün kırmızı uyarıları yeşile çevirmek değil. Amacı:

Organik büyümeyi engelleyen sorunları bulmak, önem sırasına koymak ve sistemin hâlâ doğru çalıştığını düzenli olarak doğrulamak.

Bazen problem 10.000 eksik Meta Description değildir. Tek bir yanlış canonical olabilir. Silinmiş bir Analytics kodu olabilir. Sitemap’in 10 dakika cache’lenmesi olabilir. Geçen ay düzelttiğiniz bir hatanın başka güncellemeden sonra tekrar ortaya çıkması olabilir.

Ya da en temel problem şudur:

Site açılmıyordur.

Ayda milyonlarca lira SEO ve reklam bütçesi harcasanız da kullanıcı siteye ulaşamıyorsa önce çözmeniz gereken problem budur.

Bu yüzden bazı kontroller aylık yapılır. Bazılarının ise 7/24 izlenmesi gerekir.

Ve bazı problemlerin cevabını hiçbir araç size doğrudan “Problem burada.” diye söylemez. Bazen bizim belirtiden yola çıkıp nedeni bulmamız gerekir.

Bence SEO Audit’in gerçek değeri tam olarak burada ortaya çıkıyor.

Hata bulmakta değil, doğru problemi bulmakta.

Ve belki daha da önemlisi:

Dün düzelttiğimiz şeyin bugün hâlâ doğru çalıştığından emin olmakta.

Önceki: 31. Bölüm, SEO Başarısını Nasıl Ölçeriz? · İçindekiler · Sonraki: 33. Bölüm, Gerçek Bir SEO Projesi Nasıl Yönetilir?

Bu bölümün ilk hali X’te yayınlandı (8 Ekim 2026).