Teknik SEO denetimi: kendi sitenizde kontrol etmeniz gereken 12 madde

Teknik SEO denetimi, Google'ın sitenizi tarayıp doğru sayfaları dizine eklemesini ve kullanıcıya hızlı, güvenli, mobilde eksiksiz sunmasını engelleyen altyapı sorunlarını sistematik olarak bulma işidir. Aşağıdaki 12 maddenin neredeyse tamamını Google Search Console, PageSpeed Insights ve Zengin Sonuçlar Testi gibi ücretsiz araçlarla kontrol edebilirsiniz; yazılımcıya çoğu zaman sorunu bulmak için değil, düzeltmek için ihtiyaç duyarsınız. Bilgiler Eylül 2026 itibarıyla günceldir.

Teknik SEO nedir ve denetim neden içerikten önce gelir?

Teknik SEO, bir sitenin taranabilir, dizine eklenebilir, hızlı, güvenli ve mobilde erişilebilir olmasını sağlayan altyapı çalışmalarının bütünüdür. Google'ın okuyamadığı bir sayfa ne kadar iyi yazılmış olursa olsun aramada yer alamaz. Search Essentials'ın teknik gereksinimleri bu zemini üç koşula indirir: Googlebot engellenmemiş olmalı, sayfa HTTP 200 kodu döndürmeli ve dizine eklenebilir içerik taşımalıdır.

Yapay zekâ aramasında da zemin aynıdır. Google'ın yapay zekâ optimizasyon rehberine göre AI Overviews ve AI Mode'da gösterilmek için sayfanın dizinde ve snippet'le (arama sonucundaki kısa özet) sunulmaya uygun olması, sitenin de Search Console'daki Arama üretken yapay zekâ kontrolüyle bu özelliklere dâhil edilmiş olması gerekir; llms.txt gibi özel bir dosya gerekmez. 31 Ağustos 2026'dan beri tüm sitelerde bulunan bu kontrol, siteyi varsayılan olarak dâhil eder. Yani teknik SEO, yapay zekâ yanıtlarında görünürlük (GEO) için de ön şarttır.

Teknik SEO denetimi için hangi ücretsiz araçlar yeterli?

Başlamak için ücretli araç gerekmez: Google Search Console, sitenizin Google'da nasıl taranıp dizine eklendiğini gösteren ücretsiz bir hizmettir.

Araç / rapor	Ne gösterir?
Search Console › Sayfa dizine ekleme	Dizindeki ve dizin dışı adresler, nedenleri
Search Console › URL Denetleme Aracı	Canlı test, işlenmiş HTML, seçilen standart URL
Search Console › robots.txt raporu	Bulunan robots.txt dosyaları ve hatalar
Search Console › Site haritaları	Haritaların durumu
Search Console › HTTPS raporu	Dizindeki HTTP ve HTTPS adresler
Search Console › Core Web Vitals raporu	Gerçek kullanıcı verisiyle URL grupları
Search Console › Bağlantılar raporu	Dahili bağlantılardan bir örnek
PageSpeed Insights	Chrome kullanıcı verisi (CrUX) ve Lighthouse önerileri
Chrome DevTools	Mobil emülasyon, yönlendirmeler, karışık içerik
Zengin Sonuçlar Testi	Yapısal verinin geçerliliği

Tarama ve dizine ekleme: Google sayfalarınızı bulabiliyor mu? (Madde 1–4)

Madde 1: robots.txt nedir, nasıl oluşturulur ve neyi engelliyor?

robots.txt, tarayıcılara sitenizin hangi yollarını taramayacaklarını söyleyen düz metin dosyasıdır. Dosyanın kuralları, IETF'in 2022'de yayımladığı RFC 9309 standardında tanımlanmıştır. Google, robots.txt oluşturma rehberinde dosyayı şöyle kurmayı önerir:

1. Düz metin düzenleyicide küçük harfle robots.txt adlı, UTF-8 kodlamalı bir dosya oluşturun.
2. User-agent, Disallow/Allow kurallarını ve tam adresli Sitemap: satırını yazın (aşağıdaki örnek gibi).
3. Dosyayı kök dizine yükleyin (https://alanadiniz.com.tr/robots.txt); dosya yalnız bu protokol, ana makine ve port için geçerlidir. Adresi gizli pencerede açıp herkese açık olduğunu doğrulayın.

Test sitesi yayına alınırken unutulan tek bir Disallow: / satırı bütün siteyi taramaya kapatır. RFC 9309'a göre robots.txt isteği 4xx kodu döndürürse tarayıcı her şeyi tarayabilir, 5xx döndürürse siteyi tamamen engelli saymalıdır. Google, 500 KiB'tan sonrasını okumaz, dosyayı genellikle 24 saate kadar önbellekte tutar ve crawl-delay satırını desteklemez (robots.txt spesifikasyonu).

Nasıl kontrol edilir: Search Console › Ayarlar altındaki robots.txt raporu, en çok taranan 20 ana makine (host) için bulunan dosyaları, son tarama zamanını ve hataları gösterir; düzeltmeden sonra yeniden tarama da isteyebilirsiniz.

İyi sonuç: Dosya 200 döndürür (hiç yoksa 404 de sorun değildir, 5xx ise risklidir), yalnız sepet, hesap, iç arama gibi aramada değeri olmayan yolları kapatır, sayfanın anlaşılması için gereken CSS ve JavaScript'i engellemez ve tam adresli Sitemap: satırı içerir.

robots.txt bir sayfayı Google'dan kaldırmaz; dizin dışında tutmak için taranabilir sayfaya noindex ekleyin.

Google'ın robots.txt giriş rehberi, engellenen bir sayfanın başka sitelerden bağlantı alırsa aramada açıklamasız görünebileceğini belirtir. Yapay zekâ botlarının izinleri de bu dosyada verilir; ayrıntılar llms.txt rehberimizde.

Madde 2: Sitemap nedir, XML site haritanız temiz mi?

Site haritası (sitemap), aramada görünmesini istediğiniz adresleri arama motorlarına liste hâlinde bildiren, genellikle XML biçimindeki dosyadır. Site haritası oluşturma rehberi tek dosyayı 50.000 URL ya da sıkıştırılmamış 50 MB ile sınırlar ve tam adresli URL ister. Google priority ve changefreq değerlerini yok sayar, lastmod değerini yalnız doğruysa kullanır. Yaklaşık 500 ya da daha az sayfalı, iç bağlantıları eksiksiz bir site haritaya ihtiyaç duymayabilir.

Nasıl kontrol edilir: Site haritaları raporunda durum “Başarılı” olmalı. Haritadan 10–20 adresi URL Denetleme Aracı ile açın: yönlendirilen, 404 döndüren, noindex taşıyan ya da başka adresi kanonik gösteren sayfa haritada olmamalı.

İyi sonuç: Yalnız 200 kodu döndüren kanonik adresler, gerçek değişikliği yansıtan tarihler ve ürün, kategori, blog için ayrı haritalar. Böylece Sayfa dizine ekleme raporunu tek haritayla süzüp sorunlu şablonu hemen görürsünüz.

Madde 3: Sayfa dizine ekleme raporu ne söylüyor?

Sayfa dizine ekleme raporu, Google'ın bildiği adreslerden hangilerinin dizinde olduğunu ve diğerlerinin neden dışarıda kaldığını gösterir. Google raporun yardım sayfasında her adresin dizine girmesini beklememenizi, önemli sayfaların kanonik sürümlerini hedeflemenizi söyler. Asıl sorun, önemli bir sayfanın yanlış nedenle dışarıda kalmasıdır.

Nasıl kontrol edilir: Nedenleri en kalabalık satırdan başlayarak okuyun ve her biri için “bilerek mi?” diye sorun. Türkçe arayüzde sık görülenler:

Durum	Ne demek?	Ne yapmalı?
Tarandı: Şu anda dizine eklenmiş değil	Tarandı ama eklenmedi	Yeniden göndermeye gerek yok; içerik değerini, kopyaları ve iç bağlantıları iyileştirin
Bulundu: Şu anda dizine eklenmiş değil	Henüz taranmadı; çoğu zaman siteyi yormamak için ertelenir	İç bağlantıları ve sunucu hızını kontrol edin
Kopya, Google kullanıcıdan farklı bir standart sayfa seçti	Google, beyan ettiğiniz standart URL yerine başka bir adres seçti	Kanonik, yönlendirme, iç bağlantı ve haritayı tek adreste birleştirin
Soft 404	“Bulunamadı” içeriği, ama 404 kodu yok	404 ya da 410 döndürün veya gerçek içerik koyun

Tek sayfa için URL Denetleme Aracı dizindeki sürümü ve “Canlı URL'yi test et” ile bugünkü hâli gösterir. “Dizine ekleme iste” düğmesinin günlük sınırı vardır ve istek, sayfanın dizine gireceği anlamına gelmez.

İyi sonuç: Önemli sayfaların tamamı dizinde, her dizin dışı neden bilinçli bir karar. Düzeltmeden sonra “Düzeltmeyi doğrula”ya basın; doğrulama genellikle iki hafta kadar sürer.

Madde 4: Canonical URL nedir, kopya sayfalar doğru yönetiliyor mu?

Canonical (kanonik) URL, aynı ya da çok benzer içerikli adresler arasından aramada temsilci seçilen adrestir; Search Console'da “standart URL” diye geçer. Google, kanonikleştirme belgesinde bir miktar kopya içeriğin normal olduğunu ve spam ihlali sayılmadığını açıkça yazar; rel="canonical" ise kural değil, ipucudur.

?renk=siyah&beden=m gibi adresler için filtreli gezinme rehberi gereksiz filtrelerin taranmasını engellemeyi önerir; ayrıntılar e-ticaret kategori sayfalarında SEO rehberimizde.

Nasıl kontrol edilir: URL Denetleme'de “Kullanıcı tarafından beyan edilen standart URL” ile “Google tarafından seçilen standart URL” alanlarını karşılaştırın. Kopya adresleri birleştirme rehberi, yönlendirmeyi ve rel="canonical"ı güçlü, site haritasını zayıf sinyal olarak sınıflandırır.

İyi sonuç: İki alan aynı; kanonik etiket, iç bağlantılar, harita ve yönlendirmeler tek adresi gösteriyor. Birbirinden farklı olması gereken sayfaları Google kopya saydıysa içeriklerini belirgin biçimde farklılaştırın; kanonikleştirme sorun giderme rehberine göre bu sayfalar düzeltmeden sonra da iki haftaya kadar aynı kopya kümesinde kalabilir.

Durum kodları, yönlendirmeler ve HTTPS nasıl denetlenir? (Madde 5–7)

Madde 5: 404 hatası nedir, soft 404 ve 5xx hataları nasıl bulunur?

404 hatası, istenen adreste sayfa bulunmadığını bildiren HTTP durum kodudur. Google'ın 2011 tarihli açıklaması 404'ü webin olağan bir parçası sayar: bazı adreslerin 404 vermesi sitenin geneline zarar vermez. Search Console yardımı da yerine yenisi konmadan kaldırılan sayfanın 404 döndürmesini sorun saymaz.

HTTP durum kodları belgesine göre dizindeki URL 4xx döndürürse dizinden çıkar; 5xx ve 429 kodları taramayı yavaşlatır, hata sürerse URL'ler zamanla dizinden düşer.

Soft 404 daha sinsidir: sayfa “bu ürün artık yok” ya da boş bir liste gösterir ama 200 kodu döndürür. Kaldırılan ürünü boş şablonla yayında tutan mağazalar ve sonuçsuz iç arama sayfaları tipik örneklerdir.

Nasıl kontrol edilir: Sayfa dizine ekleme raporunda “Bulunamadı (404)”, “Soft 404” ve “Sunucu hatası (5xx)” satırlarını açın. Var olmayan bir adresi (ör. /deneme-12345) URL Denetleme'de canlı test edin: yanıt 404 olmalıdır.

İyi sonuç: Önemli sayfalarda 4xx, 5xx ve soft 404 yok; özel 404 sayfanız gerçekten 404 döndürüyor; bağlantı alan kaldırılmış sayfalar eşdeğerine 301 ile gidiyor.

Madde 6: 301 yönlendirme ve yönlendirme zincirleri doğru mu?

301 yönlendirme, bir adresin kalıcı olarak taşındığını bildiren sunucu yanıtıdır. Google, 301 ve 308 gibi kalıcı yönlendirmeleri hedefin kanonik seçilmesi için sinyal sayar; yönlendirme rehberine göre 302 gibi geçici yönlendirmeler bu sinyali vermez.

Art arda taşımalar zincir bırakır: http://alanadiniz.com.tr/urun önce HTTPS'ye, sonra www'li sürüme, en son /urunler/urun adresine gidiyorsa bu üç atlama tek bir 301'e indirilmelidir. Googlebot en fazla 10 atlamayı izler, ama Google site taşıma rehberinde doğrudan son adrese yönlendirmeyi, olmuyorsa atlamaları ideal olarak en fazla 3'te, her durumda 5'in altında tutmayı önerir.

Nasıl kontrol edilir: Chrome DevTools › Ağ (Network) sekmesinde “Günlüğü koru”yu (Preserve log) işaretleyip eski bir adresi açın ve 301/302 satırlarını sayın.

İyi sonuç: Her eski adres tek atlamada, sunucu taraflı 301 ya da 308 ile son adrese gidiyor; iç bağlantılar doğrudan son adresi gösteriyor ve yönlendirmeler en az bir yıl yerinde kalıyor.

Madde 7: SSL sertifikası nedir, HTTPS doğru çalışıyor mu?

SSL/TLS sertifikası, sitenin anahtarını alan adına bağlayarak kimliğini doğrulayan ve şifreli bağlantı kurulmasını sağlayan dijital belgedir; SSL, bugünkü TLS protokolünün öncülüdür. Google, sayfanın HTTP ve HTTPS sürümü varsa HTTPS sürümünü dizine eklemeyi tercih eder. Sayfa deneyimi rehberine göre ise Core Web Vitals dışındaki unsurlar sıralamaya doğrudan katkı sağlamaz; HTTPS'nin asıl gerekçesi güvenlik ve güvendir.

Nasıl kontrol edilir: HTTPS raporu, dizindeki HTTP ve HTTPS URL sayısını ve HTTP'de kalma nedenlerini (geçersiz sertifika, haritada HTTP adres gibi) listeler. HTTPS bir sayfa, görselleri ya da betikleri HTTP üzerinden yüklüyorsa karışık içerik oluşur. Çoğu tarayıcı betik gibi etkin içeriği varsayılan olarak engeller; görsel gibi edilgen içeriği ise Chrome HTTPS'ye yükseltmeye çalışır, güvenli sürüm yoksa yüklemez. DevTools Konsol sekmesindeki “Mixed Content” uyarılarına bakın.

İyi sonuç: Dizindeki adreslerin tamamı HTTPS; her http:// adresi tek atlamada HTTPS'ye gidiyor; sertifika geçerli; kanonik, harita ve iç bağlantılar HTTPS.

Site hızı ve mobil uyum: Core Web Vitals nasıl ölçülür? (Madde 8–9)

Madde 8: LCP nedir, INP nedir, CLS nedir?

Core Web Vitals, yükleme hızını, etkileşime yanıtı ve görsel kararlılığı gerçek kullanıcı verisiyle ölçen üç metriktir:

• LCP (Largest Contentful Paint): Görünür alandaki en büyük görsel ya da metin bloğunun ekrana gelme süresi.
• INP (Interaction to Next Paint): Ziyaret boyunca yapılan tıklama, dokunma ve tuş basışlarından sonra tarayıcının bir sonraki kareyi çizmesine kadar geçen sürelerin en uzunu (aykırı değerler hariç); Mart 2024'te FID'nin yerini aldı.
• CLS (Cumulative Layout Shift): Sayfa açık kaldığı süre boyunca yaşanan beklenmedik düzen kaymalarının en yoğun dönemini (en büyük kayma patlamasını) ölçer.

Metrik	İyi	İyileştirme gerektiriyor	Zayıf
LCP	2,5 sn ve altı	2,5–4 sn	4 sn üstü
INP	200 ms ve altı	200–500 ms	500 ms üstü
CLS	0,1 ve altı	0,1–0,25	0,25 üstü

web.dev'in Core Web Vitals rehberi, “iyi” sonuç için üç eşiğin de sayfa yüklemelerinin 75. yüzdelik diliminde, yani ziyaretlerin en az dörtte üçünde karşılanmasını ister; mobil ve masaüstü ayrı değerlendirilir. Google, Core Web Vitals belgesinde ve sayfa deneyimi rehberinde bu metriklerin sıralama sistemlerince kullanıldığını söyler; ama tek bir sayfa deneyimi sinyali yoktur ve Google zayıf deneyimde bile en alakalı içeriği göstermeye çalışır.

Nasıl kontrol edilir: Search Console'daki Core Web Vitals raporu, CrUX verileriyle benzer sayfaları gruplar ve grubu en kötü metriğine göre etiketler. Mobilde “Zayıf” bir gruptan örnek adresi PageSpeed Insights'ta açın. Aracın belgelerine göre üstteki saha verisi son 28 günü, alttaki Lighthouse sonucu tek bir simülasyonu gösterir; ikisi farklı çıkabilir.

İyi sonuç: Önemli URL gruplarının tamamı mobilde ve masaüstünde “İyi”; Lighthouse puanının 100 olması gerekmez. Düzeltmeden sonra raporda “İzlemeyi Başlat”a basın; Google sorunu 28 gün izler.

Madde 9: Mobil öncelikli dizine ekleme için mobil sürüm eksiksiz mi?

Mobil öncelikli dizine ekleme, Google'ın dizine ekleme ve sıralamada akıllı telefon tarayıcısıyla taradığı mobil sürümü esas alması demektir. Haziran 2024 duyurusuna göre masaüstü Googlebot ile taranan son siteler de 5 Temmuz 2024'ten bu yana yalnız Googlebot Smartphone ile taranıyor; mobilde erişilemeyen içerik dizine eklenemiyor. Mobil öncelikli dizine ekleme rehberi duyarlı (responsive) tasarımı önerir ve iki sürümde aynı içeriği, yapısal veriyi, başlık ile meta açıklamayı ister.

Nasıl kontrol edilir: URL Denetleme'de canlı test yapıp mobil ekran görüntüsüne ve işlenmiş HTML'ye bakın. DevTools cihaz emülasyonuyla ürün açıklaması, yorumlar, bağlantılar ve yapısal verinin iki sürümde aynı olduğunu karşılaştırın.

İyi sonuç: Tek duyarlı tasarım, mobilde eksiksiz içerik ve makul HTML boyutu. Şubat 2026'da güncellenen Googlebot belgesine göre Googlebot, arama için HTML gibi desteklenen dosyaların yalnız ilk 2 MB'ını (sıkıştırılmamış veri; PDF'lerde 64 MB) tarar; satır içi dev JSON ya da SVG ile şişen sayfalarda içeriğin bir kısmı sınır dışında kalabilir.

JavaScript, yapısal veri ve iç bağlantılar (Madde 10–12)

Madde 10: JavaScript ile yüklenen içerik Google'a görünüyor mu?

Google JavaScript kullanan sayfaları üç aşamada işler: tarama, işleme (rendering) ve dizine ekleme. 200 kodu döndüren sayfalar işleme kuyruğunda birkaç saniye, bazen daha uzun bekleyebilir; içeriğini JavaScript ile oluşturan siteler bu yüzden daha dikkatli denetlenmelidir.

Nasıl kontrol edilir: İki adımda bakın.

1. “Sayfa kaynağını görüntüle” (Ctrl+U) ile ham HTML'ye bakın; ürün açıklaması, fiyat ve kategori bağlantıları orada yoksa içerik JavaScript'e bağımlıdır.
2. URL Denetleme canlı testinde “Test edilen sayfayı göster” altındaki işlenmiş HTML'de bu metinleri arayın.

İyi sonuç: Ana içerik ve bağlantılar ham ya da işlenmiş HTML'de eksiksiz. Yeni bir altyapıya geçiyorsanız sunucu taraflı oluşturma (SSR), statik oluşturma ya da hydration (sunucuda üretilen HTML'nin tarayıcıda etkileşimli hâle getirilmesi) seçin; Google dinamik oluşturmayı önerilen çözüm değil, geçici çare sayar.

Madde 11: Yapısal veri nedir, işaretlemeniz hatasız mı?

Yapısal veri, sayfanın içeriğini (ürün, fiyat, makale gibi) arama motorlarının anlayacağı standart biçimde tanımlayan işaretlemedir; sözlüğünü Schema.org topluluğu geliştirir. Google, yapısal veri rehberinde JSON-LD'yi önerir ve kullanıcıya görünmeyen bilginin işaretlenmemesini ister.

Yapısal veri politikalarına göre işaretleme zengin sonucun mutlaka gösterileceği anlamına gelmez ve içeriği gerçekten temsil etmelidir; aksi hâlde manuel işlemle zengin sonuç uygunluğu kaybedilebilir.

SSS (FAQ) zengin sonucu 7 Mayıs 2026'dan beri Google Arama'da gösterilmiyor; FAQPage işaretlemesini açılır SSS kutuları için eklediyseniz bu beklentiyi listenizden çıkarın.

Google kararı 8 Mayıs 2026 tarihli değişiklik günlüğü kaydında duyurdu. Yapay zekâ optimizasyon rehberi de yapısal verinin yapay zekâ özelliklerinde görünmek için zorunlu olmadığını belirtir.

Nasıl kontrol edilir: Her şablondan bir adresi Zengin Sonuçlar Testi'nden geçirin ve Search Console'daki zengin sonuç raporlarını izleyin.

İyi sonuç: Test hatasız; işaretlemedeki fiyat, stok ve puan sayfadakiyle aynı ve birlikte güncelleniyor.

Madde 12: Yetim sayfa nedir, iç bağlantılarınız yeterli mi?

Yetim sayfa, sitenizde hiçbir sayfadan bağlantı almayan, yalnız site haritası ya da doğrudan adresle ulaşılan sayfadır. Bağlantılar, Google için hem yeni sayfaları bulmanın yolu hem alaka sinyalidir; bağlantı rehberi önem verdiğiniz her sayfanın en az bir iç bağlantı almasını ister. Google bağlantıları güvenilir biçimde yalnız href taşıyan a öğelerinden çıkarır; bağlantı metni de hedefi anlatan kısa bir ifade olmalıdır.

Nasıl kontrol edilir: Site haritasındaki adresleri bir tarama aracının iç bağlantılardan bulduğu adreslerle karşılaştırın; haritada olup taramada çıkmayanlar yetim adayıdır. Ücretsiz ön kontrol için Bağlantılar raporundaki dahili bağlantı listesine bakın; rapor bir örnek gösterir, ama listede hiç görünmeyen önemli bir sayfa, bağlantı ihtiyacına işaret eder.

İyi sonuç: Her önemli sayfaya menüden ve ilgili içeriklerden açıklayıcı metinli iç bağlantılar geliyor. Başka sitelerden gelen dış bağlantılar (backlink) ise ayrı bir konudur.

Hangi teknik SEO hatasını önce düzeltmelisiniz? Etki–efor tablosu

Etkisi yüksek, eforu düşük bulgulardan başlayın. Tablo, tipik bir KOBİ ya da e-ticaret sitesi için Spreadon'un değerlendirmesidir; Google'ın bir sıralaması değildir.

Bulgu	Etki	Efor
robots.txt önemli yolları engelliyor	Çok yüksek	Düşük
Önemli sayfalarda noindex, 4xx ya da 5xx	Çok yüksek	Düşük–orta
HTTPS eksik, sertifika geçersiz	Yüksek	Düşük–orta
Mobilde eksik içerik	Yüksek	Orta–yüksek
Kanonik sinyalleri tutarsız	Yüksek	Orta
İçerik JavaScript'e bağımlı	Yüksek	Yüksek
Yönlendirme zincirleri, haritada hatalı URL'ler	Orta	Düşük
Yetim sayfalar	Orta	Düşük–orta
Core Web Vitals “Zayıf”	Orta	Orta–yüksek
Yapısal veri hataları	Düşük–orta	Düşük

Örnek senaryo: Temasını değiştiren 1.200 ürünlü kurgusal bir mağazada ürün şablonundaki unutulmuş noindex aynı gün kaldırılır; eski kampanya adreslerindeki üç atlamalı zincir ve işaretlemedeki eski fiyatlar aynı hafta düzeltilir; mobilde “İyileştirme gerektiriyor” durumundaki LCP ayrı iş olarak planlanır.

Adım adım: ilk teknik SEO denetiminizi yapın

1. Search Console'u kurun. Mümkünse Alan mülkü seçin; robots.txt ve HTTPS raporları her mülk türünde görünmez.
2. Genel tabloyu görün. Dizindeki sayfa sayısını önemli sayfa sayınızla kıyaslayın; site: sorgusunun sonuçları her zaman eksiksiz değildir.
3. Erişimi ve dizini doğrulayın. robots.txt, site haritası ve dizine ekleme raporlarını “bilerek mi?” sorusuyla okuyun; Ayarlar › Arama'da üretken yapay zekâ bölümünde sitenin dâhil olduğuna da bakın.
4. Şablon başına bir adresi canlı test edin. Ana sayfa, kategori, ürün ve blog şablonunda durum kodu, standart URL, işlenmiş HTML ve mobil görüntüye bakın.
5. Hızı, HTTPS'yi ve yapısal veriyi ölçün. Core Web Vitals ve HTTPS raporları ile Zengin Sonuçlar Testi yeterlidir.
6. Önceliklendirin, düzeltin, doğrulayın. Bulguları etki–efor tablosuna yazın; düzeltmeden sonra “Düzeltmeyi doğrula” ve “İzlemeyi Başlat” düğmelerini kullanın.

Teknik SEO denetiminde sık yapılan hatalar

• robots.txt ile engellenen sayfaya noindex eklemek: Google sayfayı taramadığı için noindex etiketini göremez.
• Lighthouse puanını Core Web Vitals sanmak: Değerlendirme gerçek kullanıcı verisiyle yapılır.
• Bilinmeyen her adresi ana sayfaya yönlendirmek: Google bunu soft 404 olarak değerlendirebilir; eşdeğeri olmayan sayfa için 404 ya da 410 döndürün.

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

Google'ın bu konuda bir kuralı yoktur; önerimiz deneyime dayanır. Search Console bildirimlerini her ay gözden geçirin; kapsamlı denetimi yılda en az bir kez, binlerce ürünlü e-ticaret sitelerinde üç ayda bir yapın. Tema, altyapı ya da URL yapısı değişikliği ve açıklanamayan trafik düşüşü de denetim sebebidir.

Takvimi gerçekçi tutun: Google'ın SEO başlangıç rehberine göre bir değişikliğin aramaya yansıması birkaç saatten birkaç aya kadar sürebilir. Bir ekiple çalışmayı düşünüyorsanız SEO hizmeti almadan önce bilmeniz gerekenler yazımıza göz atın ya da ücretsiz SEO analizi isteyin.