Teknik SEO Denetimi Nasıl Yapılır? Adım Adım 2026

Teknik SEO denetimi, bir web sitesinin Google tarafından sorunsuz taranıp (crawl) indekslenebilmesi ve sıralanabilmesi için altyapısının baştan sona kontrol edilmesidir. Pratikte üç şeyi denetlersiniz: Googlebot sayfalarınızı keşfedip indirebiliyor mu (tarama), bulduğu içeriği index'ine kaydedebiliyor mu (indeksleme), ve sayfalarınız teknik olarak hızlı, mobil uyumlu, doğru yapılandırılmış mı (sıralanabilirlik). Kısacası teknik SEO, içeriğinizin Google'ın gözüne girmeden önce geçmesi gereken kapıdır; bu kapı kapalıysa, ne kadar iyi içerik yazdığınızın bir önemi kalmaz. Bu yüzden teknik denetim, çoğu durumda sayfa içi (on-page) optimizasyon ve içerik çalışmalarından önce gelir: kötü içerik bir sayfayı geriletir, ama bozuk bir teknik altyapı koca siteyi görünmez yapar.

Bu farkı net görmek için Google'ın nasıl çalıştığını hatırlamak gerekir. Google üç temel aşamayla iş görür: Tarama (Crawling) — Googlebot bağlantıları takip ederek sayfaları keşfeder ve indirir; İndeksleme (Indexing) — indirilen içerik işlenir ve Google index'ine kaydedilir; Sıralama/Sunum (Ranking/Serving) — bir sorgu geldiğinde index'teki sayfalar arasından en uygun olanlar sıralanır. Her üç aşamada da ayrı ayrı sorun çıkabilir, ve bir sayfanın "indekslenmemiş" olması ile "indeksli ama sıralanmamış" olması tamamen farklı problemlerdir. Müşterilerimizde sık gördüğümüz yanılgı şudur: sayfa Google'da çıkmıyor diye hemen içeriği veya anahtar kelimeyi suçlarlar; oysa sorun çoğu zaman sayfanın hiç indekslenmemiş olmasıdır — yani daha ilk kapıda takılmıştır. Teknik denetimin amacı tam olarak bu kapıdaki tıkanıklıkları, hangi aşamada olduklarını ayırt ederek bulmaktır.

Bu üç aşamayı bir teşhis çerçevesi olarak kullanmak, denetimin en güçlü tarafıdır. Bir sorun gördüğünüzde önce şunu sorarsınız: tarama mı, indeksleme mi, yoksa sıralama mı? Çünkü her birinin belirtisi ve çözümü farklıdır. Aşağıdaki tablo, bir sayfa beklediğiniz gibi görünmediğinde sorunun hangi aşamada olduğunu nasıl ayırt edeceğinizi ve nereye bakacağınızı özetler:

Bu ayrımı yapmadan denetime başlamak, doktora gitmeden ilaç almaya benzer. site:alanadiniz.com/sayfa-url şeklinde basit bir Google araması bile size çok şey söyler: sonuç çıkıyorsa sayfa indekslidir ve sorun büyük olasılıkla sıralama tarafındadır; hiç çıkmıyorsa daha indeksleme veya tarama aşamasında takılmışsınızdır ve içeriği baştan yazmak zaman kaybı olur. Teknik denetim bu mantığı sistematik hale getirir.

Teknik SEO tam olarak neyi kapsar?

Teknik SEO, sitenizin içeriğiyle değil, o içeriğin sunulduğu altyapıyla ilgilenen SEO koludur. Anahtar kelime seçimi, başlık yazımı, metin kalitesi gibi konular on-page SEO'nun alanına girerken; tarama yönetimi, indeksleme kontrolü, site hızı, mobil uyumluluk, yapısal veri ve güvenlik teknik SEO'nun alanıdır. Bu ikisi birbirini tamamlar: SEO'nun bütününde teknik altyapı sağlam zemin, içerik ise o zeminin üzerine inşa edilen değerdir.

Bir teknik SEO denetiminde tipik olarak şu başlıkları sırayla ele alırız:

• Tarama (crawlability): robots.txt kuralları, Googlebot'un render için ihtiyaç duyduğu CSS/JS kaynaklarına erişimi, tarama bütçesinin gereksiz sayfalara harcanıp harcanmadığı.
• İndeksleme (indexability): noindex etiketleri, kanonik (canonical) seçimleri, yinelenen içerik, indekslenmesi gereken sayfaların gerçekten index'te olup olmadığı.
• Site mimarisi ve iç linkleme: sayfaların kaç tıkla erişilebildiği, yetim (orphan) sayfalar, mantıksal hiyerarşi.
• Performans (Core Web Vitals): LCP, INP ve CLS metrikleri — sayfanın yüklenme ve etkileşim hızı.
• Mobil uyumluluk: mobil-öncelikli indeksleme gerekleri, mobil ve masaüstü içerik eşitliği.
• Yapısal veri (schema.org): doğru ve geçerli işaretleme, hata raporları.
• Güvenlik ve protokol: HTTPS, HTTP→HTTPS yönlendirmeleri, sertifika tutarlılığı.
• Sitemap ve yönlendirmeler: XML sitemap doğruluğu, kırık linkler, yönlendirme zincirleri.

Bu maddelerin hiçbiri "içerik yaz" demez; hepsi "içeriğin Google'a doğru ulaşmasını sağla" der. Bu yüzden teknik denetim, içerik üretiminden bağımsız ama onun ön koşulu olan bir hijyen çalışmasıdır.

Bu çerçevenin 2026'da iki yeni boyutu daha var ve bunları atlamak denetimi eksik bırakır. Birincisi mobil-öncelikli indeksleme: 5 Temmuz 2024 itibarıyla Google tüm siteleri yalnızca akıllı telefon Googlebot'uyla tarıyor; masaüstü-öncelikli istisna kalmadı. Yani Google sitenizin mobil sürümünü görür ve sıralama sinyallerini oradan üretir. Mobil sürümde masaüstüyle aynı ana içerik, başlıklar, iç linkler ve yapısal verinin bulunması artık tercih değil, zorunluluktur — "mobilde kısalttık" dediğiniz her şey Google'ın gördüğü tek sürümdür. İkincisi AI/AEO katmanı: AI Overviews 2025 itibarıyla Türkiye'de ve Türkçe sorgularda aktif, ve yapısal veri artık yalnızca klasik zengin sonuçlar için değil, AI motorlarının içeriğinizi anlaması için de değerli. Teknik altyapınız temiz değilse, bu yeni katmanlarda da görünmezsiniz.

Teknik SEO denetimi neden içerikten önce gelir?

Teknik SEO denetimi içerikten önce gelir, çünkü bozuk bir altyapı en iyi içeriği bile Google'a hiç ulaştırmaz veya değerini düşürür. Bir örnekle açalım: sitenizin robots.txt dosyası yanlışlıkla önemli bir dizini engelliyorsa, o dizindeki sayfalar ne kadar mükemmel yazılmış olursa olsun taranamaz; taranamayan sayfa indekslenemez, indekslenemeyen sayfa da hiçbir sorguda görünmez. Aynı şekilde, sayfalarınız yanlış kanonik etiketlerle başka URL'lere işaret ediyorsa, Google sizin değerli içeriğinizi başka bir adresin kopyası sanıp index'ten dışlayabilir. Bu tür sorunlar içerikle çözülmez; ancak teknik denetimle bulunur ve düzeltilir.

Burada sık karşılaşılan ince bir tuzağa dikkat çekmek gerekir: robots.txt bir sayfayı indeksten çıkarmaz, yalnızca taramayı engeller. Engellenen bir URL başka bir yerden linklenmişse Google onu yine de indeksleyebilir — ama içeriğini okuyamadığı için arama sonucunda boş, açıklamasız bir kayıt olarak gösterir. Bir sayfayı gerçekten index dışında tutmak istiyorsanız doğru araç noindex meta etiketidir; üstelik bunun çalışması için o sayfanın robots.txt ile engellenmemiş olması şarttır, çünkü engelliyse Googlebot sayfaya hiç giremez ve noindex talimatını göremez. Müşteri sitelerinde gördüğümüz klasik çelişki tam budur: sayfa hem robots.txt ile engellenmiş hem de noindex işaretlenmiştir; sonuç olarak Google noindex'i hiç okuyamaz ve sayfa beklenenin aksine index'te kalmaya devam eder. Bu, içerik kalitesiyle hiç ilgisi olmayan, salt teknik bir konfigürasyon hatasıdır.

İçerik ve teknik SEO arasındaki etki farkını şu tabloda görebilirsiniz:

Tablodan da görüleceği gibi teknik sorunlar genellikle sistemiktir: tek bir hatalı yapılandırma yüzlerce sayfayı aynı anda etkileyebilir. Bu yüzden bir denetimde önce teknik temeli sağlama almak, en yüksek getirili işi en başta yapmak demektir. Müşterilerimizde gördüğümüz tipik senaryo şudur: aylarca içerik üretilmiş ama trafik gelmiyordur; denetim yaptığımızda kök neden çoğu zaman içeriğin kalitesizliği değil, sitemap'in Google Search Console'a hiç gönderilmemiş olması ya da kritik sayfaların yanlışlıkla noindex işaretlenmiş olmasıdır. Bu durumlarda haftalarca yeni içerik yazmak yerine, tek bir teknik düzeltme sonuçları hızla değiştirir.

Sık rastladığımız teknik kök nedenleri ve "belirti–gerçek neden" eşleşmesini şöyle özetleyebiliriz:

• "Yeni yazdığımız sayfalar bir türlü görünmüyor" → çoğu zaman XML sitemap Search Console'a hiç gönderilmemiştir veya sayfa hiçbir yerden iç link almayan bir yetim (orphan) sayfadır; Google onu keşfedememektedir.
• "Eski sayfa düşük sırada, içeriği güçlendirdik ama değişmedi" → sayfa yanlış bir kanonik etiketle başka bir URL'yi işaret ediyor olabilir; Google sizin değerlendirmenizi o diğer adrese aktarmaktadır.
• "Mobilde her şey iyi görünüyor ama sıralama kötü" → mobil sürümde masaüstündeki içeriğin bir kısmı (metin, iç link, schema) eksiktir; Google yalnızca eksik mobil sürümü gördüğü için sayfayı zayıf değerlendirir.
• "Bazı sayfalar bir gün var bir gün yok" → aralıklı sunucu hataları (5xx) veya çok yavaş yanıt süreleri Googlebot'un taramasını kesintiye uğratıyor olabilir.

Bu örneklerin ortak noktası şudur: belirti içerikle ilgili görünür, gerçek neden tekniktir. Denetim, bu kök nedenleri yüzeydeki belirtiden ayırmanızı sağlar.

Bu önceliklendirme mantığı, Google'ın kendi değerlendirme çerçevesiyle de uyumludur. Google bir sayfanın güvenilir ve yardımcı olup olmadığını değerlendirirken kullanılabilirlik (usability) sinyallerini de dikkate alır; site hızı ve mobil uyumluluk gibi teknik unsurlar, eşit kalitedeki iki sayfa arasında ayrım yapan bir hijyen faktörü işlevi görür. Burada gerçekçi olmak önemli: Core Web Vitals'ın "iyi" olması sizi tek başına zirveye taşıyan bir bonus değildir, içerik alakası ve kalitesi her zaman önceliklidir. Ama eşik altında kalmak — örneğin LCP'nin 2,5 saniyeyi aşması veya etkileşim gecikmesinin (INP) 200 milisaniyenin üzerine çıkması — sizi eşit kalitedeki bir rakibin gerisine düşürebilir. Yani teknik sağlamlık tek başına sizi zirveye taşımaz, ama eksikliği sizi yarıştan tamamen çıkarabilir. İşletmenizin organik görünürlüğünü kapsamlı değerlendirmek isterseniz, dijital pazarlama danışmanlığı hizmetimiz kapsamında bu teknik ön denetimi her zaman ilk adım olarak ele alırız; mevcut durumunuzu hızlıca görmek için ücretsiz site analizimizden de yararlanabilirsiniz.

İçerik öncesi mi, sonrası mı? Doğru sıralama

Pratikte teknik SEO ve içerik birbirini dışlamaz; bir öncelik sırası içinde birlikte ilerler. Yeni bir projeye başlarken veya devraldığımız bir sitede çalışırken izlediğimiz mantık şudur:

1. Önce engelleri kaldır: Tarama ve indeksleme önündeki kritik teknik blokajlar (yanlış robots.txt, hatalı noindex, kanonik karmaşası, kırık HTTPS) en başta giderilir. Bunlar içeriğin Google'a ulaşmasını fiziksel olarak engelleyen sorunlardır.
2. Sonra temeli sağlamlaştır: Site mimarisi, iç linkleme, mobil uyumluluk ve Core Web Vitals gibi performans ayağı düzenlenir. Bu adım, indekslenebilen içeriğin daha iyi değerlendirilmesini sağlar.
3. Ardından içeriği üret ve büyüt: Sağlam zemin kurulduktan sonra anahtar kelime araştırması, sayfa içi optimizasyon ve içerik kümeleri devreye girer. Bu aşamada artık her yeni içerik sağlam bir altyapı üzerine eklenir ve emeğiniz boşa gitmez.

Bu sıralama, içeriğin önemsiz olduğu anlamına gelmez — aksine, içerik uzun vadede sıralamayı belirleyen en güçlü unsurdur. Demek istediğimiz şudur: teknik altyapı bozukken üretilen içerik, sızdıran bir kovaya su taşımaya benzer. Önce kovadaki delikleri (teknik sorunları) kapatır, sonra su (içerik) taşırsınız. Nitekim bir sitenin teknik temeli sağlamsa, sonraki adımlar olan anahtar kelime araştırması ve içerik üretimi çok daha verimli sonuç verir; çünkü ürettiğiniz her sayfa artık doğru taranır, doğru indekslenir ve performans olarak da değerlendirilmeye hazır olur.

Bu kuralın tek istisnası, hangi tür siteyle çalıştığınıza göre dengeyi kaydırmanızdır. Aşağıdaki tablo, denetim sırasında ağırlığı nereye vermeniz gerektiğini farklı senaryolar için özetliyor:

Bu tablonun verdiği mesaj nettir: "önce teknik" genel bir doğrudur, ama körü körüne uygulanan bir kural değil, duruma göre ağırlık verdiğiniz bir önceliklendirme çerçevesidir. Özellikle e-ticaret sitelerinde teknik tarafın yükü daha ağırdır; binlerce filtre ve parametre kombinasyonu tarama bütçesini tüketip asıl önemli ürün ve kategori sayfalarının taranmasını geciktirebilir. Bu nedenle e-ticaret projelerinde teknik denetim ve içerik optimizasyonunu bir arada ele almak gerekir; ürün ve kategori sayfalarının hem teknik hem içerik tarafını birlikte düzenlemek için e-ticaret SEO rehberimiz bu dengeyi ayrıntılı işliyor.

Bu rehberin ilerleyen bölümlerinde teknik denetimin her bir ayağını adım adım ele alacağız: taramadan indekslemeye, Core Web Vitals'tan yapısal veriye ve Google Search Console ile sürekli izlemeye kadar. Sayfa hızı tarafına ayrı bir önem vereceğiz; çünkü Core Web Vitals teknik SEO'nun en ölçülebilir performans ayağıdır ve site hızı ile SEO ilişkisini ayrı bir rehberde derinlemesine ele aldık. Amacımız, sonunda kendi sitenizde uygulayabileceğiniz, somut ve önceliklendirilmiş bir teknik denetim yol haritası bırakmak. Önce kapıları açıyoruz; içeriği konuşacağımız çok yer var.

Tarama ve İndeksleme Sorunları Nasıl Denetlenir? robots.txt, Sitemap ve Canonical

Tarama ve indeksleme denetimi, Google'ın sitenizi keşfedip (crawl) ve dizine ekleyebildiğinden (index) emin olma sürecidir. Bu kontrol teknik SEO denetiminin en kritik ayağıdır; çünkü içeriğiniz ne kadar iyi olursa olsun, Google sayfayı tarayamıyor ya da indeksleyemiyorsa o sayfa hiçbir sorguda görünmez. Google üç aşamayla çalışır: önce Googlebot sayfaları keşfedip indirir (tarama), sonra içeriği işleyip dizine kaydeder (indeksleme), en sonunda sorguya en uygun sonuçları sıralar (serving/ranking). Burada kritik bir ayrım var: bir sayfanın indekslenmemiş olması ile indeksli ama sıralanmamış olması tamamen farklı sorunlardır ve çözümleri de farklıdır. Denetime başlarken önce hangi aşamada tıkanma olduğunu netleştirmeniz gerekir.

Hangi aşamada sorun olduğunu hızlıca ayırt etmek için şu pratik teşhis sırasını kullanırız:

Bu bölümde robots.txt, XML sitemap, canonical etiketleri, noindex kullanımı ve yinelenen içerik gibi tarama/indeksleme katmanını adım adım nasıl denetleyeceğinizi anlatıyoruz. Müşterilerimizde gördüğümüz tablo şu: sıralama düşüşlerinin önemli bir kısmı içerik kalitesinden değil, yanlış kurgulanmış bir robots.txt kuralından ya da yanlış canonical'dan kaynaklanır. Bu denetimi büyük ölçüde Google Search Console üzerinden yapacağınız için, raporları okumayı bilmek bu işin temelidir. İçerik tarafını sağlamlaştırmadan önce bu teknik zemini kontrol etmek, çoğu zaman tek satırlık bir düzeltmeyle ciddi görünürlük kazandırır.

robots.txt nasıl denetlenir?

robots.txt, Googlebot'a hangi yolları tarayabileceğini söyleyen bir tarama kontrol dosyasıdır; sitenizin kök dizininde (ornek.com/robots.txt) bulunur. Önemli bir yanılgıyı baştan düzeltelim: robots.txt indekslemeyi garantili biçimde engellemez. Bir URL'i robots.txt ile taramaya kapatsanız bile, o sayfaya başka yerlerden link verilmişse Google onu yine indeksleyebilir; sadece içeriğini okumadan, çoğu zaman "Bu sayfa hakkında bilgi yok" gibi cılız bir gösterimle. Yani gizli/özel kalmasını istediğiniz bir sayfayı dizinden çıkarmak için robots.txt yanlış araçtır.

Denetim sırasında robots.txt dosyanızda kontrol etmeniz gereken noktalar:

• Render için gerekli kaynaklar engelleniyor mu? CSS ve JavaScript dosyalarını Disallow ile kapatmayın. Google sayfayı tıpkı bir tarayıcı gibi render eder; bu kaynakları engellerseniz sayfanızı eksik/bozuk görür ve değerlendirmesi yanlış olur. Özellikle bileşenlerini istemci tarafında JavaScript ile çizen modern sitelerde (React, Vue, headless e-ticaret) ana içeriği üreten JS dosyasının engellenmesi, Google'ın boş bir sayfa görmesine yol açabilir.
• Yanlışlıkla tüm site kapatılmış mı? Geliştirme ortamından canlıya geçişte unutulan bir Disallow: / satırı tüm siteyi taramaya kapatabilir; bu, sitenin dizinden silinmesine kadar gidebilen en tehlikeli hatalardandır. Staging/test ortamlarında siteyi kapatmak için robots.txt kullanılır, ama canlıya alırken bu satırın taşınması en sık görülen kazalardan biridir. Denetimi her yayın (deploy) sonrası rutin bir kontrol adımı yapın.
• Mobil ve masaüstü için kurallar aynı mı? Mobil-öncelikli indeksleme 5 Temmuz 2024'te tüm siteler için tamamen tamamlandığından, Google artık tüm indeksleme ve sıralama sinyallerini akıllı telefon taramasından alır. Mobil ve masaüstü için aynı robots kurallarını kullanın; mobil sürümde masaüstüyle aynı ana içerik, başlıklar, iç linkler ve yapısal veri bulunmalıdır.
• Sitemap satırı var mı? robots.txt'nin sonuna Sitemap: direktifiyle XML sitemap adresinizi eklemek iyi bir pratiktir; Googlebot dosyayı her okuduğunda sitemap'inizi hatırlar.
• Kurallar doğru yorumlanıyor mu? Disallow / Allow önceliği, joker karakterler (*) ve satır sonu işaretleri (\$) kolayca yanlış yazılır. robots.txt'yi tahminle değil, Search Console'daki robots.txt test/inceleme özelliğiyle doğrulayın; belirli bir URL'in taranmaya açık olup olmadığını birebir test edin.

Bir sayfayı gerçekten dizinden çıkarmak istiyorsanız doğru yöntem robots.txt değil, noindex meta etiketi (ya da X-Robots-Tag HTTP başlığı) kullanmaktır. PDF, resim gibi HTML olmayan dosyalarda meta etiket koyamayacağınız için X-Robots-Tag HTTP başlığı tek seçeneğinizdir. Ama burada kritik bir tuzak var: Google'ın noindex direktifini görebilmesi için o sayfanın robots.txt ile engellenmemiş olması gerekir. Bir sayfayı hem robots.txt ile taramaya kapatıp hem de noindex koyarsanız, Google sayfayı taramayacağı için noindex etiketini hiç okuyamaz ve sayfa dizinde kalmaya devam edebilir. Bu, sahada en sık karşılaştığımız çelişkilerden biridir. Doğru sıra şudur: önce noindex'in okunmasına izin verin (taramaya açık bırakın), sayfa dizinden düştükten sonra dilerseniz robots.txt kuralı eklersiniz.

XML sitemap denetimi: ne içermeli, ne içermemeli?

XML sitemap, Google'a "şu sayfaları taramanı ve indekslemeni istiyorum" listesi sunan dosyadır; özellikle büyük siteler ve iç linki zayıf yeni sayfalar için keşfi hızlandırır. Sitemap denetiminin altın kuralı şudur: sitemap'iniz yalnızca indekslenebilir, kanonik (tercih edilen) URL'leri içermelidir. Aşağıdaki tablo, sitemap'e girmesi gereken ve girmemesi gereken URL türlerini özetler:

Tüm URL'lerin HTTPS olması yalnızca sitemap için değil, canonical ve hreflang etiketleri için de geçerli bir kuraldır; HTTPS temel bir gereklilik ve sıralama sinyalidir, dolayısıyla tüm site HTTPS'e taşınmalı ve HTTP istekleri HTTPS'e yönlendirilmelidir. Çok büyük sitelerde tek bir sitemap dosyası 50.000 URL veya 50 MB sınırını aşabilir; bu durumda içerik tipine göre bölünmüş (ürünler, kategoriler, blog) birden çok sitemap ve bunları toplayan bir sitemap index dosyası kullanmak hem yönetimi hem de "hangi bölüm indekslenmiyor" teşhisini kolaylaştırır.

Sitemap'inizi hazırladıktan sonra Search Console'un Site Haritaları bölümünden gönderin ve durumunu izleyin; "gönderilen" ile "indekslenen" URL sayısı arasındaki büyük fark, denetlemeniz gereken bir indeksleme sorununun habercisidir. Proje deneyimimizde "yeni sayfalar Google'da görünmüyor" şikayetinin en sık kök nedeni, sitemap'in hiç GSC'ye gönderilmemiş olmasıdır; bu yüzden yeni içerik kümeleri yayınladığınızda sitemap gönderimini bir kontrol adımı olarak işletmeniz gerekir. Yeni bir sayfanın gerçekten indekslenip indekslenmediğini doğrulamak için ise Search Console'un URL İnceleme aracını kullanıp gerekirse "İndekslenmeyi iste" ile manuel taramayı tetikleyebilirsiniz. Toplu indeksleme tetiklemenin gerçek aracı ise her zaman sitemap'tir; URL İnceleme tek tek doğrulama içindir.

Canonical etiketleri neden denetlenmeli?

Canonical etiketi (rel="canonical"), yinelenen veya birbirine çok benzer içeriğe sahip URL'ler arasında Google'a "asıl, tercih edilen sürüm budur" demenin yoludur. Doğru kurgulandığında, dağılan otorite ve PageRank sinyallerini tek bir URL'de toplar; böylece Google'ın hangi sürümü sıralayacağı konusunda kafası karışmaz. Kendi kendine kanonik (self-referencing) — yani bir sayfanın kendini kanonik göstermesi — iyi bir pratiktir ve her indekslenebilir sayfada bulunması önerilir.

Burada hatırlanması gereken kritik bir nokta var: canonical bir direktif değil, bir öneridir. Google sizin belirttiğiniz canonical'ı dikkate alır ama her zaman ona uymak zorunda değildir; içerik, iç linkleme ve diğer sinyaller başka bir URL'i işaret ediyorsa Google farklı bir kanonik seçebilir. Bu yüzden denetimde "ben canonical koydum" demekle yetinmeyin; URL İnceleme aracında "kullanıcı tarafından belirtilen kanonik" ile "Google tarafından seçilen kanonik" satırlarının uyuşup uyuşmadığını birebir kontrol edin. İkisi farklıysa, Google sizin tercihinizi reddetmiş demektir ve nedenini araştırmanız gerekir.

Canonical denetiminde dikkat etmeniz gereken yaygın hatalar:

• Yanlış URL'e işaret eden canonical: Bir kategori sayfasının canonical'ı yanlışlıkla ana sayfayı ya da alakasız bir sayfayı gösteriyorsa, hedef sayfa indeksten düşebilir. Şablon (template) kaynaklı bir hatada bu, sitenin tamamına yayılır; örneğin tüm ürün sayfalarının canonical'ının tek bir sabit URL'e gömülü kaldığı durumlar gördük.
• Karışık protokol/host sinyalleri: Canonical'lar tutarlı biçimde HTTPS ve tek bir tercih edilen host (www'lı veya www'sız) göstermeli; Google genelde tutarlı, güvenli yapıyı tercih eder. Aynı içeriğin http, https, www ve www'suz dört varyantı varsa hepsi tek bir kanonik HTTPS sürüme yönlenmelidir.
• noindex + canonical çakışması: Aynı sayfaya hem noindex hem başka bir sayfaya canonical vermek çelişkili sinyaldir; hangi davranışı istediğinize karar verip tek bir sinyal bırakın. "Bu sayfayı indeksleme" demek istiyorsanız noindex yeter; "bu sayfanın otoritesini başka sayfada topla" demek istiyorsanız canonical kullanın, ama ikisini aynı anda kullanmayın.
• Sayfalama (pagination) yanlışları: Listeleme sayfalarının 2., 3. sayfalarının canonical'ını 1. sayfaya yönlendirmek yaygın bir hatadır; her sayfalama URL'i kendini kanonik göstermelidir, aksi halde derin sayfalardaki ürün/içerik linkleri taranmadan kalabilir.
• Sitemap ile uyumsuzluk: Sitemap'e koyduğunuz URL ile o sayfanın canonical'ının işaret ettiği URL aynı olmalı; sitemap'te A URL'i varken sayfanın canonical'ı B'yi gösteriyorsa Google'a iki farklı şey söylemiş olursunuz.

Çok dilli ya da çok bölgeli sitelerde canonical, hreflang ile birlikte değerlendirilir. hreflang etiketleri karşılıklı (reciprocal) olmalı, bir x-default tanımı bulunmalı ve her dil sürümü kendi dilindeki kanonik sayfaya işaret etmelidir. Burada Alis projelerinde öğrendiğimiz önemli bir nüansı paylaşalım: hreflang ile sunucu taraflı dil yönlendirmesini karıştırmayın. Türkçe ziyaretçiyi sunucudan otomatik olarak /en sürümüne yönlendirmek sonsuz yönlendirme döngüsü yaratabilir; hreflang Google'a hangi sürümün hangi dil/bölge için olduğunu bildirir, kullanıcıyı zorla yönlendirmez. Bu ayrımı kavramak, çok dilli sitelerde tarama hatalarının ve aniden düşen indekslemenin önemli bir bölümünü baştan önler.

İndeksleme sorunları nasıl teşhis edilir?

İndeksleme sorunlarını teşhis etmenin en güvenilir yolu Search Console'daki Sayfalar (İndeksleme) raporudur. Bu rapor, hangi sayfaların indeksli olduğunu, hangilerinin neden indekslenmediğini gösterir ve nedenleri kategorize eder. En sık gördüğümüz kategorileri ve her birinde ne yapılması gerektiğini şöyle özetleyebiliriz:

Her kategoriyi bir kontrol listesi gibi okuyup gerçek bir sorun mu (örneğin yanlışlıkla noindex'lenmiş önemli bir sayfa) yoksa beklenen bir durum mu (örneğin filtre/etiket sayfalarının indekslenmemesi) ayırmanız gerekir. Özellikle "Tarandı, henüz indekslenmedi" durumu çoğu zaman teknik bir hata değil, bir kalite sinyalidir: Google sayfayı görmüş ama indekse almaya değer bulmamıştır. Bu durumda çözüm robots/sitemap'le oynamak değil, içeriği özgünleştirmek, derinleştirmek ve kullanıcı niyetini gerçekten karşılayan, "insanlar için" bir hale getirmektir.

Denetimde sık karşılaşılan iki yapısal sorun:

• Yinelenen içerik (duplicate content): E-ticarette en yaygın haliyle, aynı ürünün farklı filtre/sıralama parametreleriyle (renk, beden, ?sort= gibi) onlarca farklı URL üretmesidir. Bu, Google'ın aynı içeriği tekrar tekrar taramasına ve doğru sürümü seçmekte zorlanmasına yol açar. Çözüm, canonical ile asıl ürün/kategori URL'sini işaret etmek ve gerekirse parametreli URL'leri sitemap dışında tutmaktır. Yinelenen içerik bir "ceza" değildir; ancak otoriteyi böler ve yanlış sürümün sıralanmasına yol açabilir. Bu konuyu e-ticaret SEO rehberimizde ürün ve kategori sayfaları özelinde daha derin ele alıyoruz.
• Tarama bütçesi (crawl budget): Çok sayıda düşük değerli, yinelenen ya da parametreli URL üreten büyük sitelerde Googlebot zamanını bu sayfalara harcar; önemli sayfalarınız daha seyrek taranır. Burada amaç, gereksiz URL'leri (faset filtreler, sonsuz takvim sayfaları, iç arama sonuç sayfaları) taranmaktan ve indekslenmekten makul biçimde azaltarak Googlebot'u değerli içeriğe yönlendirmektir. Tarama bütçesi çoğunlukla yalnızca on binlerce URL'li büyük siteler için gerçek bir kısıttır; birkaç yüz sayfalık küçük siteler bu konuyu fazla dert etmemeli, bunun yerine içerik ve iç linkleme kalitesine odaklanmalıdır.

İndeksleme denetimini tamamlarken site mimarisi ve iç linklemeyi de gözden geçirmek gerekir: Googlebot sayfaları ağırlıklı olarak linkleri takip ederek keşfettiği için, hiçbir yerden link almayan "yetim (orphan)" sayfalar sitemap'te olsa bile geç ve zayıf indekslenir. Sağlam bir iç linkleme yapısı, hem keşfi hem de PageRank dağıtımını iyileştirir; bu yüzden tarama/indeksleme denetimini izole bir teknik adım gibi değil, içerik mimarisiyle iç içe yürütürüz.

Bu denetim adımları, daha geniş teknik SEO ve içerik çalışmasının yalnızca bir katmanıdır. Tarama/indeksleme tarafını sağlama aldıktan sonra sayfa içi (on-page) SEO ile başlık, içerik ve iç linkleme yapınızı; konu otoritesi ve içerik kümesi stratejisiyle de sitenizin konuyu ne kadar kapsamlı işlediğini güçlendirmeniz gerekir. İndeksleme katmanını her yayın sonrası izlemeyi alışkanlık haline getirmek için Search Console raporlarını düzenli okumanızı öneririz. Tarama, indeksleme ve canonical katmanının bütününü işletmenizle birlikte düzenli denetlememizi isterseniz dijital pazarlama danışmanlığı hizmetimiz ya da hızlı bir başlangıç için ücretsiz analiz formumuz üzerinden sürece dahil olabilirsiniz.

Sayfa Hızı, Core Web Vitals ve INP: Teknik SEO Denetiminin Performans Ayağı

Sayfa hızı denetimi, sitenizin gerçek kullanıcı deneyimini ölçülebilir teknik metriklere indirgeyip Google'ın "İyi" eşiklerine göre değerlendirme sürecidir. 2026 itibarıyla bu ölçümün omurgası Core Web Vitals'tır: LCP, INP ve CLS. Bir teknik SEO denetiminde performans, içerik kalitesinden sonra gelen ama atlanamayacak bir hijyen katmanıdır; çünkü Google bu metrikleri hem sıralama sinyali ailesine dahil eder hem de aynı verileri Search Console üzerinden size geri raporlar. Müşterilerimizde gördüğümüz en yaygın hata, hız denetimini tek bir araç skorunun (örneğin Lighthouse'un yeşil/kırmızı rozeti) ötesine taşımamak. Oysa doğru bir denetim, laboratuvar verisi ile sahadaki gerçek kullanıcı verisini ayırt etmek ve doğru metriği doğru eşikle okumakla başlar.

Bu bölümde önce güncel eşikleri ve özellikle 2024'te değişen INP metriğini netleştiriyoruz, ardından mobil-öncelikli indeksleme ile HTTPS'in performans denetimindeki yerini ele alıyoruz. Detaylı uygulama adımları için site hızı ve Core Web Vitals rehberimiz ile PageSpeed Insights iyileştirme yazımızı ayrı ayrı ele alıyoruz; burada amacımız bu metrikleri bir denetim akışına nasıl yerleştireceğinizi göstermek. Performans, kapsamlı bir teknik SEO denetiminin ölçülebilir tek ayağı olduğu için, denetim raporunuzun en somut çıktısını da çoğu zaman bu bölüm üretir.

Core Web Vitals nedir ve 2026 güncel eşikleri nelerdir?

Core Web Vitals, bir sayfanın yükleme hızını, etkileşim tepkiselliğini ve görsel kararlılığını ölçen üç temel kullanıcı deneyimi metriğinin ortak adıdır. Google bu üç metrik için "İyi" kabul edilen eşik değerlerini, gerçek kullanıcıların 75. persentilinde ölçülen değerlere göre belirler; yani ziyaretçilerinizin en az dörtte üçünün bu eşiğin altında bir deneyim yaşaması beklenir. Bu "75. persentil" detayı denetimde sıkça gözden kaçar: ortalama (mean) değil, en yavaş yaşanan deneyimlerin de hesaba katıldığı bir eşiktir. Yani sayfanızın çoğu yüklemesi hızlıyken, ziyaretçilerinizin dörtte birinde yaşanan kötü deneyim metriği "Zayıf"a çevirebilir. Güncel eşikler şöyledir:

Denetim sırasında bu üç metriği birbirinden bağımsız değerlendirin: bir sayfa LCP'de mükemmel olup INP'de zayıf olabilir. LCP, sunucu yanıt süresi, render-engelleyici kaynaklar ve büyük görsellerle ilgilidir; CLS, boyutu belirtilmemiş görseller, geç yüklenen reklamlar ve font değişimleriyle bozulur; INP ise tamamen JavaScript'in ana iş parçacığını (main thread) ne kadar meşgul ettiğiyle ilgilidir. Üçü farklı kök nedenlere işaret ettiği için, bir denetim raporunda "site yavaş" demek yerine hangi metriğin hangi şablonda (anasayfa, kategori, ürün, blog) eşiği aştığını ayrı ayrı işaretlemek gerekir. Aşağıdaki tablo, her metriği hangi kök nedenlere ve müdahale alanına bağlayacağınızı denetim sırasında hızla görmenizi sağlar:

FID neden gitti, INP neden geldi?

INP (Interaction to Next Paint), 12 Mart 2024 itibarıyla FID'in (First Input Delay) yerini alarak resmî bir Core Web Vital oldu. FID artık kullanımdan kaldırılmıştır; bu yüzden 2026'da hazırlanan bir denetim raporunda "FID'imiz iyi" gibi bir ifade görüyorsanız o rapor eskimiştir. İnternette hâlâ FID'i Core Web Vital olarak gösteren çok sayıda eski içerik dolaştığı için, denetimde kullandığınız araç ve şablonların güncel olduğundan emin olun. Pratik bir kontrol: kullandığınız üçüncü taraf denetim aracı raporunda "FID" sütunu hâlâ varsa veya INP'yi hiç ölçmüyorsa, o aracın metodolojisi güncellenmemiş demektir ve verdiği "geçti" notuna güvenmeyin.

Bu değişimin mantığı şudur: FID yalnızca kullanıcının ilk etkileşimindeki girdi gecikmesini ölçüyordu. Oysa kullanıcılar zamanlarının yaklaşık %90'ını sayfa yüklendikten sonra geçirir; tıklamalar, dokunuşlar, menü açmalar, filtre uygulamalar hep bu süreçte olur. INP, sayfanın tüm oturum boyunca yapılan etkileşimlere verdiği yanıt hızını ölçer ve sadece girdi gecikmesini değil; girdi gecikmesi + işleme süresi (processing) + sunum gecikmesinin (presentation delay) tamamını kapsar. Yani INP, kullanıcının bir butona bastığında ekranda gözle görülür bir değişiklik görene kadar geçen toplam süreyi yansıtır. Bu, FID'e kıyasla çok daha gerçekçi ve daha katı bir tepkisellik ölçüsüdür. Aradaki en kritik fark da burada gizlidir: FID'in iyi olması, sayfanın geri kalanının da tepkisel olduğunu garantilemiyordu; INP ise tek bir "geç" etkileşimi bile yakaladığı için, sayfanızın en kötü anını ölçer. Bu yüzden FID'de yıllarca sorunsuz görünen birçok site, INP'ye geçişle birlikte "Geliştirilmeli" veya "Zayıf" tarafına düştü.

Denetimde INP'yi yorumlarken şu aralıkları kullanın:

• ≤ 200 ms — İyi (Good): Etkileşimler akıcı algılanır.
• 201–500 ms — Geliştirilmeli (Needs Improvement): Gecikme hissedilir; iyileştirme listesine alın.
• > 500 ms — Zayıf (Poor): Kullanıcı belirgin takılma yaşar; öncelikli müdahale gerektirir.

Pratikte INP problemleri neredeyse her zaman ağır JavaScript'ten kaynaklanır: üçüncü taraf etiketler (chat widget'ları, analitik, reklam scriptleri), büyük çerçeve paketleri (bundle), uzun süren olay dinleyicileri (event listener) ve ana iş parçacığını bloke eden senkron işlemler. Bir e-ticaret denetiminde özellikle kategori filtreleri, sepete ekleme butonları ve varyant seçicileri INP'nin en çok bozulduğu noktalardır; bu yüzden INP ölçümünü mutlaka bu etkileşimli şablonlar üzerinde yapın. Somut bir senaryo: müşterilerimizde sık karşılaştığımız tablo, anasayfa ve blog yazılarının INP'sinin "İyi" çıkması ama aynı sitenin kategori sayfasındaki filtre tıklamasının 400-500 ms'yi bulmasıdır; çünkü filtre, ana iş parçacığında senkron çalışan ağır bir yeniden render tetikler. Burada çözüm sunucuyu hızlandırmak değil, o etkileşimdeki JavaScript işini hafifletmek veya parçalamaktır. E-ticaret özelindeki performans nüanslarını e-ticaret SEO rehberimizde daha ayrıntılı işliyoruz.

Laboratuvar verisi mi, saha verisi mi? Denetimde hangisine bakmalı?

Bu, performans denetiminin en kritik ayrımıdır ve çoğu yanlış teşhis buradan doğar. İki tür veri vardır:

• Saha verisi (field / CrUX): Gerçek kullanıcıların gerçek cihaz ve bağlantılarında oluşan veridir. Google'ın Chrome User Experience Report (CrUX) veri tabanından gelir ve Core Web Vitals değerlendirmesinde sıralama açısından sayılan veri budur. Search Console'daki Core Web Vitals raporu ve PageSpeed Insights'ın üst kısmı bu veriyi gösterir.
• Laboratuvar verisi (lab): Lighthouse'un kontrollü, simüle edilmiş bir ortamda tek seferlik ürettiği veridir. Hata ayıklama (debug) için mükemmeldir çünkü tekrarlanabilir ve neyin yavaşlattığını adım adım gösterir; ama gerçek kullanıcı deneyimini birebir temsil etmez. Önemli not: INP saha metriğidir; Lighthouse laboratuvar ortamında INP'yi doğrudan ölçemez, yalnızca ona yaklaşık bir gösterge (Total Blocking Time gibi) sunar.

İki veri türü arasındaki ayrımı denetim ekibinizle netleştirmek için şu özet tabloyu kullanabilirsiniz:

Doğru denetim akışı şudur: önce saha verisiyle (Search Console CWV raporu + PageSpeed Insights'ın CrUX bölümü) hangi URL gruplarının hangi metrikte eşiği aştığını tespit edin; sonra laboratuvar verisiyle (Lighthouse) o sayfalardaki kök nedeni teşhis edin. Tersini yaparsanız — yani sadece Lighthouse skoruna bakarsanız — gerçekte kullanıcılarınızı hiç etkilemeyen bir sorunu kovalayıp, sahada gerçekten kötü deneyim yaratan bir şablonu gözden kaçırabilirsiniz. Sık görülen bir örnek: yeni veya az trafikli bir sayfada CrUX'ta yeterli veri toplanmamış olabilir; bu durumda saha verisi "yok" görünür ve geçici olarak laboratuvar verisiyle ilerlemeniz gerekir, ancak bu sayfa trafik aldıkça mutlaka saha verisine geri dönmelisiniz. Search Console'un bu raporunu nasıl okuyacağınızı Google Search Console rehberimizde adım adım anlatıyoruz; sayfa bazlı laboratuvar teşhisi içinse denetim araçlarımız ve PageSpeed Insights birlikte kullanılır.

Bir noktanın altını çizelim: Core Web Vitals'ı "iyi" yapmak tek başına sizi rakiplerinizin üzerine çıkaran sihirli bir bonus değildir. Google bunu bir eşik/hijyen faktörü olarak konumlandırır; içerik alakası ve kalitesi her zaman önceliklidir. Performans, eşit kalitedeki iki sayfa arasında ayrım yapabilen, kötü olduğunda sizi geriye iten ama mükemmel olduğunda tek başına zirveye taşımayan bir faktördür. Başka bir deyişle: hızı düzeltmek kötü içeriği iyi yapmaz, ama yavaşlık iyi içeriği sırtından aşağı çekebilir. Bu yüzden denetimde performansı, içerik ve E-E-A-T çalışmalarının yerine değil, onların yanında bir hijyen kontrolü olarak konumlandırın. Bu önceliklendirme mantığını, denetim raporunuzu sahibine sunarken de net biçimde ifade etmek, "her şeyi yeşile boyayalım" baskısının bütçeyi yanlış yere harcamasını önler.

Mobil-öncelikli indeksleme: denetim neyi mobil gözüyle görmeli?

Mobil-öncelikli indeksleme (mobile-first indexing), 5 Temmuz 2024 itibarıyla tüm siteler için tamamen tamamlanmıştır. Artık masaüstü-öncelikli istisna yoktur; Google'ın tüm indeksleme ve sıralama sinyalleri sitenizin akıllı telefon (mobil) sürümünün taranmasından gelir. Bunun teknik SEO denetimi için anlamı nettir: sitenizi değerlendirirken masaüstü görünümüne değil, Googlebot'un gördüğü mobil görünüme bakmalısınız. Pratik bir denetim yöntemi, tarayıcınızın geliştirici araçlarındaki cihaz emülasyonunu açıp sayfayı mobil görünümde JavaScript'siz/JavaScript'li olarak karşılaştırmak ve Search Console'un URL İnceleme aracındaki "render edilmiş HTML" çıktısını incelemektir; bu çıktı, Google'ın gerçekte ne gördüğünü gösteren en güvenilir kaynaktır.

Denetim sırasında mobil sürümde şunların masaüstüyle birebir aynı olduğunu doğrulayın:

• Ana içerik: Mobil sürümde "daha az göster", sekme arkasına gizleme veya tamamen çıkarılmış metin bölümleri varsa, Google o içeriği görmüyor olabilir. Mobilde gizlenen ama masaüstünde dolu olan bir sayfa, mobil-öncelikli dünyada içeriksiz sayılır. (Not: sekme/akordeon arkasında olsa da DOM'da yüklü duran içerik genelde görülür; asıl risk, mobilde DOM'a hiç eklenmeyen veya tamamen kaldırılan içeriktir.)
• Başlıklar ve hiyerarşi: H1/H2/H3 yapısı mobilde de eksiksiz bulunmalı. Başlık hiyerarşisinin sağlamlığı, hem taranabilirlik hem de soru-cevap odaklı içerik için kritik olduğundan, bu konuyu sayfa içi SEO yazımızda ayrıca ele alıyoruz.
• İç linkler: Mobil menü ve içerik içi bağlantılar, masaüstündeki keşif yollarını aynen sunmalı; aksi halde derin sayfalarınızın taranması zorlaşır. Mobilde sadeleştirilmiş bir menü, masaüstünde erişilebilen kategori veya alt sayfalara giden iç linkleri gizliyorsa, o sayfalar mobil-öncelikli taramada keşif gücünü kaybeder.
• Yapısal veri (structured data): Schema işaretlemesi mobil sürümde de bulunmalı; sadece masaüstüne eklenmiş schema mobil-öncelikli indekslemede işe yaramaz. Yapısal verinin doğru kurulumunu schema markup rehberimizde ele alıyoruz.

Ayrıca performans ölçümlerinizi mobil cihaz profiliyle yapın. Bir sayfa masaüstünde hızlı görünüp, daha zayıf işlemci ve mobil ağ koşulları altında LCP veya INP eşiğini rahatlıkla aşabilir. INP özelinde bu fark daha da belirgindir: aynı JavaScript yükü, masaüstü işlemcide milisaniyeler sürerken orta-alt segment bir telefonda kat kat uzayabilir. PageSpeed Insights ve Search Console, mobil ve masaüstü verilerini ayrı raporladığı için ikisini ayrı ayrı denetleyin; gerçek kullanıcılarınızın çoğunluğu mobildeyse mobil eşikleri önceliğiniz olmalıdır. Türkiye'deki çoğu işletme sitesinde trafiğin büyük kısmı mobilden geldiği için, mobil eşikleri sahada zayıfsa rapordaki ilk önceliğiniz bu olmalıdır.

HTTPS: performans değil ama atlanmaması gereken bir temel kontrol

HTTPS, doğrudan bir hız metriği olmasa da teknik SEO denetiminin performans ve güvenlik kesişimindeki temel bir gerekliliğidir ve Google tarafından bir sıralama sinyali / temel gereklilik olarak ele alınır. Denetimde şu kontrolleri yapın:

• Sitenin tamamı HTTPS üzerinden sunuluyor mu? Tek bir HTTP sayfası bile "karışık içerik" (mixed content) uyarısına yol açabilir; özellikle eski blog yazılarındaki HTTP ile gömülü görsel, script veya iframe bağlantıları bu sorunun en yaygın kaynağıdır.
• HTTP sürümleri kalıcı (301) olarak HTTPS'e yönlendiriliyor mu? Yönlendirmenin tek adımda olması da önemlidir; HTTP'den HTTPS'e geçerken araya giren birden çok yönlendirme (örneğin önce www, sonra protokol) hem hızı düşürür hem de tarama bütçesini boşa harcar.
• XML sitemap, canonical etiketleri ve hreflang işaretlemeleri her zaman HTTPS sürümünü gösteriyor mu? Tutarsız protokol, Google'ın kanonik seçiminde kafa karışıklığı yaratır.

Bu kontroller küçük görünse de, HTTPS tutarsızlıkları kanonikleşme ve indeksleme sorunlarının sık karşılaşılan kök nedenlerindendir; bu yüzden performans denetiminizin yanına eklenmeleri yerinde olur. Aynı içeriğin hem HTTP hem HTTPS, hem www hem www'siz sürümünün erişilebilir olması, Google'ın gözünde dört ayrı URL anlamına gelir ve sinyallerinizi böler. Denetimin bu kalemini, indeksleme ve canonical incelemesiyle birlikte değerlendirmenizi öneririz; bu konuları daha geniş ele aldığımız teknik SEO denetimi rehberinin ilgili bölümlerine başvurabilirsiniz.

Performans denetimi için pratik kontrol listesi

Bir teknik SEO denetiminin performans ayağını şu sırayla yürütmenizi öneririz:

1. Search Console Core Web Vitals raporuyla, mobil ve masaüstü için saha verisinde İyi/Geliştirilmeli/Zayıf URL gruplarını çıkarın.
2. Sorunlu her URL grubu için temsil eden bir örnek sayfayı PageSpeed Insights'ta açıp önce CrUX (saha) verisini, sonra Lighthouse (laboratuvar) teşhisini okuyun.
3. Metriği kök nedene eşleyin: LCP için sunucu yanıtı/görsel/render-engelleyici kaynak; CLS için boyutsuz görsel/geç gelen öğeler; INP için ağır JavaScript ve üçüncü taraf scriptler.
4. Ölçümü mutlaka mobil profilde ve etkileşimli şablonlarda (kategori, ürün, filtre) tekrarlayın; INP yalnızca etkileşim olan sayfalarda anlam taşır.
5. HTTPS tutarlılığını ve sitemap/canonical/hreflang protokolünü doğrulayın.
6. Bulguları şablon bazında önceliklendirin: en çok trafik alan ve sahada en kötü performans gösteren şablonlar listenin başına gelmeli.

Önceliklendirmeyi somutlaştırmak için her bulgunun yanına iki basit eksen yazmak işe yarar: etki (kaç URL'i ve ne kadar trafiği ilgilendiriyor) ve düzeltme maliyeti (kod değişikliği mi, ayar mı, içerik mi). Yüksek etkili ve düşük maliyetli düzeltmeler — örneğin tek bir ağır üçüncü taraf scriptini ertelemek veya hero görseline boyut vermek — denetim raporunun "önce bunları yapın" başlığına girer; düşük etkili ama yüksek maliyetli işler (köklü bir tema/altyapı değişikliği gibi) ise ayrı bir orta-vadeli plana alınır. Bu ayrım, ekibin sınırlı zamanını sahada en çok hissedilecek iyileştirmelere yönlendirir.

Bu yapı, performansı soyut bir skordan çıkarıp eyleme dönüştürülebilir bir denetim çıktısına dönüştürür. Sitenizin Core Web Vitals tablosunu çıkarıp önceliklendirme ve teknik iyileştirme planını birlikte kurgulamamızı isterseniz, dijital pazarlama danışmanlığı hizmetimiz kapsamında bunu yapıyoruz; hızlı bir başlangıç için ücretsiz analiz formumuzu doldurabilirsiniz. Performansın detaylı uygulama tarafını ise Core Web Vitals rehberimizde bulabilirsiniz.

Yapısal Veri ve Tarama Edilebilirlik: Google İçeriği Nasıl "Görür"?

Teknik SEO denetiminin en kritik aşamalarından biri, içeriğinizin Google tarafından doğru taranıp doğru anlaşıldığını doğrulamaktır. Yapısal veri (schema markup), sayfanızın anlamını arama motorlarına makine-okunabilir biçimde anlatan; hreflang çok dilli sürümleri eşleyen; render ise Googlebot'un sayfayı son hâliyle görüp göremediğini belirleyen üç teknik katmandır. Bu üçü doğru kurulmazsa içeriğiniz mükemmel olsa bile Google onu eksik veya yanlış yorumlayabilir. Müşterilerimizde sık gördüğümüz şudur: İçerik kalitesi yüksek, sayfa hızı kabul edilebilir, ama yapısal veri yanlış tiple kurgulanmış ya da kritik metin JavaScript'e gömülü olduğu için Googlebot'un eline yarım ulaşıyor. Bu bölümde her katmanı somut eşikler, gerçek senaryolar ve adım adım kontrollerle ele alıyoruz.

Hatırlatmakta fayda var: Google üç temel aşamayla çalışır — tarama (crawling), indeksleme (indexing) ve sıralama (serving/ranking). Yapısal veri ve render sorunları çoğunlukla indeksleme aşamasını bozar; hreflang sorunları ise yanlış ülke/dil sürümünün sıralanmasına yol açar. Bir sayfanın "indexlenmemiş" olması ile "sıralanmamış" olması bambaşka iki problemdir ve denetimde bunları karıştırmak yanlış teşhise götürür. Bu mantığın detayını SEO nedir ve nasıl yapılır rehberimizde ele aldık; burada teknik denetim gözüyle bakıyoruz.

Yapısal veri (schema markup) teknik olarak nasıl denetlenir?

Yapısal veri denetimi, sayfalarınızdaki schema.org işaretlemesinin (1) geçerli olup olmadığını, (2) doğru içerik tipini tanımlayıp tanımlamadığını ve (3) gereksiz/yanlış tipler içerip içermediğini kontrol etmektir. Önerilen format JSON-LD'dir; Google bunu net biçimde ayrıştırır ve sayfanın görsel düzeninden bağımsızdır. Bu, işaretlemeyi sayfanın HTML akışına serpiştirmek (microdata) yerine tek bir blokta toplamanıza izin verdiği için bakım ve denetim açısından da rahattır. Denetimde iki ana araç kullanılır: zengin sonuç (rich result) uygunluğu için Rich Results Test, saf schema.org doğrulaması için Schema Markup Validator. Search Console'daki "Geliştirmeler" raporları ise canlı sitenizdeki desteklenen tiplerde çıkan hataları toplu gösterir ve bu raporlar lab testinden değil, gerçek Googlebot taramasından beslendiği için en gerçekçi sinyaldir.

Burada 2026 itibarıyla en sık yapılan teknik hatayı netleştirelim: FAQPage ve HowTo işaretlemesi artık görsel zengin sonuç (rich result) getirmez. Google, FAQ rich result'ı Ağustos 2023'te yalnızca otoriter devlet ve sağlık siteleriyle sınırladı; sıradan işletme, e-ticaret, SaaS ve ajans siteleri bu açılır SSS görünümünü çoktan kaybetti. 2026'da ise destek tamamen kaldırılıyor — FAQ arama görünümü, zengin sonuç raporu ve Rich Results Test desteği 2026 içinde, Search Console API'deki FAQ desteği 2026 içinde sonlanıyor. HowTo rich result'ı ise zaten Eylül 2023'te (önce mobilde, sonra masaüstü dahil) tamamen kaldırıldı. Yani bir denetim raporunda "FAQ schema ekleyince Google'da açılır sorular çıkar" gibi bir kazanç vaadi yazmak teknik olarak yanlıştır. İnternette dolaşan eski rehberler bu iddiayı hâlâ tekrarladığı için, devraldığınız bir denetimde "FAQ schema ekleyerek SERP yüzölçümünü büyütelim" tavsiyesi görürseniz bunu güncel olmayan bir öneri olarak işaretleyin.

İyi haber şu: kullanılmayan veya artık rich result vermeyen yapısal veri Search'e zarar vermez; Google bunu açıkça belirtti. Dolayısıyla mevcut FAQPage işaretlemenizi telaşla sökmeniz gerekmez — denetim raporunuzda bunu "acil kaldır" değil, "rich result beklentisini sıfırla" maddesi olarak konumlandırın. Üstelik schema, klasik zengin sonucun ötesinde bir işe yarar: AI Overviews ve büyük dil modellerinin içeriğinizi yapısal olarak anlamasına yardımcı olur. Bu yüzden iyi yapılandırılmış işaretleme, yapay zekâ aramalarında görünürlük açısından hâlâ değerlidir — bu boyutu yapısal veri ve schema markup rehberimizde derinlemesine, AEO odağıyla ise GEO rehberimizde ele alıyoruz.

Teknik denetimde odaklanmanız gereken, 2026'da hâlâ gerçek zengin sonuç veren tiplerdir:

Pratik tavsiyemiz, müşterilerimizde uyguladığımız temel set: Organization + BreadcrumbList + içeriğe uygun ana tip (blog için Article, ürün için Product, mağaza/şube için LocalBusiness). Bu üçlüyü doğru kurun, sonra spesifik zengin sonuç fırsatlarına göre genişletin. Bir denetimde sık rastladığımız hata, Review/AggregateRating'in izin verilmeyen yerlerde "self-serving" (kendi kendine yıldız verme) biçiminde kullanılmasıdır; Google bu yıldızları yalnızca Product, Recipe, Course, Book, LocalBusiness gibi belirli tiplerde gösterir, serbest yıldız işaretlemesi geçersizdir. Örneğin bir hizmet sayfasına "Service" tipine iliştirilmiş 4,9 yıldız koymak hem zengin sonuç vermez hem de gözden geçirme yönergeleri açısından riskli bir manipülasyon sinyalidir.

İkinci sık hata, schema'da iddia edilen verinin sayfada görünür olmamasıdır. Google, yapısal veriyi kullanıcının da gördüğü içeriğin bir tasviri olarak bekler. Sayfada hiç yazmayan bir indirim fiyatı, gerçekte alınmamış bir ödül ya da olmayan bir stok durumunu schema'da iddia etmek, en hafif sonucunda zengin sonucun gösterilmemesi, en ağırında ise yapısal veri ihlali nedeniyle manuel işlemdir. Denetimde her şablon için "schema'da ne yazıyor / sayfada ne görünüyor" karşılaştırmasını mutlaka yapın.

Yapısal veriyi adım adım nasıl test ederim?

Denetimi sistematik yürütmek için şu sırayı izleyebilirsiniz:

1. Şablon başına temsilci URL seçin: Anasayfa, kategori, ürün, blog, yerel/şube gibi her şablon türünden bir temsilci URL alın ve önce bunları test edin. Tek tek sayfa kovalamak yerine şablon mantığıyla ilerleyin — bir tema/altyapı hatası genelde o şablondaki tüm sayfaları aynı anda etkiler, dolayısıyla bir şablonu düzeltmek yüzlerce sayfayı birden onarır.
2. Rich Results Test ile uygunluk: Seçtiğiniz URL'leri Rich Results Test'ten geçirip hangi zengin sonuç tipine uygun bulunduklarını ve varsa hataları görün. Burada "uygun" çıkması garanti gösterim değildir; Google yine de uygun gördüğü sorgularda gösterir.
3. Tip ve içerik uyumu: İşaretlenen tipin sayfa içeriğiyle gerçekten örtüştüğünü ve schema'daki her değerin sayfada görünür karşılığı olduğunu doğrulayın.
4. Schema Markup Validator ile saf doğrulama: Zengin sonuç odaklı olmayan ama AEO/anlamlandırma için tuttuğunuz tipleri (ör. FAQPage, Organization ilişkileri) schema.org standardına göre doğrulayın.
5. Toplu izleme: Search Console "Geliştirmeler" raporlarında biriken hata/uyarıları takip edin; bunlar gerçek Googlebot taramasından gelir, lab testinden daha gerçekçidir. Not: FAQ raporu 2026 içinde kaldırılacağı için bu raporun yokluğu artık bir eksiklik değil, beklenen durumdur.
6. Tutarlılık denetimi: Schema'daki marka adı, adres ve telefonun sitedeki görünür bilgiyle ve dış profillerle birebir aynı olduğunu doğrulayın.

Bu son madde özellikle yerel işletmeler için kritiktir: NAP tutarsızlığı hem güveni hem yerel sıralamayı düşürür. Adres veya telefonun farklı sayfalarda ya da Google İşletme Profili ile schema arasında küçük farklarla yazılması bile (örneğin bir yerde "Mah." kısaltması, başka yerde açık yazım) güven sinyalini zedeler. Yerel işletmelerde schema ile Google İşletme Profili'nin uyumunu nasıl kurguladığımızı yerel SEO rehberimizde anlattık. Tüm bu yapısal veri ve yapay zekâ görünürlüğü sinyallerinizi tek seferde otomatik taramak isterseniz GEO denetim aracımız sayfanızın AI motorlarına ne kadar net "okunduğunu" hızlıca raporlar.

Render edilebilirlik: Googlebot sayfanın son hâlini görüyor mu?

Render (işleme), Googlebot'un JavaScript çalıştıktan sonraki nihai sayfayı görüp göremediğidir. Bu, modern sitelerin en sinsi teknik SEO sorunudur: ham HTML'de görünmeyen ama tarayıcıda JavaScript ile yüklenen içerik (ürün açıklamaları, iç linkler, hatta ana metin) Google tarafından geç veya hiç görülmeyebilir. Tek sayfa uygulaması (SPA) mantığıyla kurulmuş, içeriği istemci tarafında çizen sitelerde bu risk en yüksektir. Denetimde temel soru şudur: kullanıcının gördüğü içerik, Googlebot'un render ettiği içerikle aynı mı?

Bunu test etmenin en güvenilir yolu Search Console'daki URL İnceleme aracıdır. Bir URL'yi inceleyip "Taranan sayfayı görüntüle / Test edilen sayfa" altındaki render edilmiş HTML'e ve ekran görüntüsüne bakın. Ana içeriğiniz, başlıklarınız ve iç linkleriniz orada görünmüyorsa render sorununuz var demektir. Hızlı bir ön kontrol için tarayıcıda JavaScript'i kapatıp sayfayı yeniden yükleyebilir veya sayfanın kaynağına bakıp ana metnin ham HTML'de bulunup bulunmadığını görebilirsiniz; ancak nihai karar her zaman Google'ın kendi render çıktısıyla verilmelidir. URL İnceleme aracı ayrıca sayfanın indexli olup olmadığını, son taranma zamanını ve Google'ın seçtiği kanonik URL'yi de gösterir; "İndekslenmeyi iste" ile manuel tarama tetikleyebilirsiniz. Bu aracın tüm yeteneklerini Google Search Console rehberimizde adım adım gösterdik.

Render edilebilirliği bozan en yaygın teknik hatalar ve denetim kontrolleri:

• robots.txt ile engellenen CSS/JS: Render için gerekli kaynakları (stil ve script dosyaları) robots.txt'te engellemeyin. Engellerseniz Googlebot sayfayı yarım render eder; örneğin engellenmiş bir script dosyası, o script'in ürettiği ürün listesini Google'ın hiç görmemesine yol açabilir. Mobil ve masaüstü için aynı kuralları kullanın.
• Mobil-masaüstü içerik farkı: Mobil-öncelikli indeksleme 5 Temmuz 2024'te tüm siteler için tamamen tamamlandı; artık Google indeksleme ve sıralama sinyallerinin tamamını akıllı telefon taramasından alır, masaüstü-öncelikli istisna kalmadı. Mobil sürümde masaüstüyle aynı ana içerik, başlıklar, iç linkler ve yapısal veri bulunmalı. "Mobilde gizledim, sadece masaüstünde var" yaklaşımı pratikte içeriğin Google için hiç var olmaması demektir.
• JavaScript'e gömülü kritik içerik: Ana metin ve navigasyon mümkünse sunucu tarafında (SSR) veya statik olarak gelsin; render'a bağımlı kalan içerik gecikmeli indekslenir ve tazelik gerektiren sayfalarda bu gecikme sıralamaya yansır.
• Performans ayağı: Render hızı doğrudan Core Web Vitals'a bağlanır. Güncel eşikler — LCP ≤ 2,5 saniye, INP ≤ 200 milisaniye, CLS ≤ 0,1 — sayfanın 75. persentil gerçek kullanıcı verisiyle ölçülür. Burada FID'in (First Input Delay) 12 Mart 2024'ten beri yerini INP'ye (Interaction to Next Paint) bıraktığını hatırlatalım; bir denetim raporunda hâlâ FID metriği kullanmak güncelliğini yitirmiş olur. INP, ilk etkileşimin değil tüm oturum boyunca etkileşimlere yanıt hızını ölçer ve aralıkları ≤200ms iyi, 201–500ms geliştirilmeli, >500ms zayıftır.

Render ve hız ayağını birlikte ölçmek için PageSpeed Insights, Lighthouse ve gerçek kullanıcı verisi sağlayan CrUX'u kullanın. Lighthouse lab koşullarında bir teşhis verir; CrUX ise sahadaki gerçek kullanıcıların yaşadığı deneyimi yansıttığı için Core Web Vitals değerlendirmesinde esas alınan budur. Bu performans katmanını site hızı ve Core Web Vitals rehberimizde ayrıntılı işliyoruz.

hreflang: çok dilli sayfalar doğru ülke ve dilde mi sıralanıyor?

hreflang, aynı içeriğin farklı dil veya bölge sürümlerini Google'a eşleyen bir işaretlemedir; amacı, doğru kullanıcıya doğru dildeki sürümü göstermektir. Teknik denetimde hreflang dört kuralla kontrol edilir:

• Karşılıklılık (reciprocal): A sayfası B'yi gösteriyorsa, B de A'yı göstermeli. Tek yönlü hreflang Google tarafından yok sayılır; bu, çok dilli sitelerde en sık gözden kaçan ve hreflang'in sessizce çalışmamasına yol açan hatadır.
• x-default: Hiçbir dil-bölge eşleşmediğinde gösterilecek varsayılan sürüm tanımlanmalı. Örneğin tanımlı dilleriniz dışında bir kullanıcı geldiğinde gösterilecek genel/uluslararası sürüm bu olur.
• Kanonik uyumu: hreflang, her dilde o dilin kanonik sayfasına işaret etmeli; noindex'li veya yönlendirilen bir URL'yi göstermemeli. hreflang ile canonical birbiriyle çelişirse Google sinyalleri tutarsız bulur ve eşlemeyi yok sayabilir.
• Mutlak HTTPS URL'ler: Tüm hreflang, canonical ve sitemap girdileri HTTPS sürümünü göstermeli; HTTP'den HTTPS'e tam yönlendirme olmalı. HTTPS bir temel gerekliliktir, dolayısıyla yapısal sinyallerin hiçbiri HTTP sürümünü işaret etmemeli.

Burada kritik bir tuzağa dikkat: hreflang bir yönlendirme aracı değildir. hreflang Google'a "şu kullanıcıya şu sürümü göster" der; sunucunuzda ziyaretçiyi diline göre zorla başka URL'ye yönlendirmek tamamen ayrı bir mekanizmadır ve ikisi karıştırıldığında ciddi sorun çıkar. Deneyimlerimizde gördüğümüz klasik hata, Türkçe ziyaretçiyi sunucu tarafında otomatik olarak İngilizce sürüme yönlendirmektir — bu, hem kötü kullanıcı deneyimi hem de sonsuz yönlendirme döngüsü riski yaratır; ziyaretçi (ve Googlebot) iki sürüm arasında durmadan ileri geri atılır. Doğru yaklaşım, hreflang ile dil eşlemesini bildirmek; yönlendirme veya dil önerisini ise ayrı, dikkatli ve döngü oluşturmayacak bir mantıkla (örneğin yönlendirme yerine bir dil seçim önerisi göstererek) kurgulamaktır.

hreflang sorunlarını teşhis ederken Search Console'un Sayfalar/İndeksleme raporu yardımcıdır: bir sayfa "kanonik alternatif" veya "duplicate" olarak işaretlenmişse, çoğunlukla hreflang veya canonical sinyalleriniz çelişiyordur. Canonical (rel="canonical") yinelenen veya benzer içerikte tercih edilen URL'yi belirtir ve PageRank'i o URL'de toplar; kendi kendine kanonik (self-referencing) iyi bir pratiktir. Bu üç sinyalin — canonical, hreflang ve sitemap — hepsinin tutarlı şekilde indexlenebilir, kanonik HTTPS URL'leri göstermesi gerekir. XML sitemap'inize asla noindex, yönlendirme hedefi veya duplicate URL koymayın; yalnızca indexlenebilir kanonik URL'ler girin ve Search Console'dan gönderin. Sitemap'in Search Console'a gönderilmemiş olması, "yeni sayfalar bir türlü indexlenmiyor" şikâyetinin en sık kök nedenidir.

Tarama bütçesi ve indeksleme hijyeni

Son olarak, tarama edilebilirliğin temel hijyenini denetleyin. robots.txt taramayı kontrol eder ama indekslemeyi garantili engellemez — engellenen bir URL başka yerden linklenirse yine indexlenebilir, üstelik Google içeriğini göremediği için arama sonucunda boş/tuhaf bir görünümle çıkabilir. Bir sayfayı index'ten gerçekten çıkarmak için robots.txt değil, noindex meta etiketi veya HTTP başlığı kullanılır; üstelik Google'ın bu noindex'i görebilmesi için o sayfanın robots.txt ile engellenmemiş olması gerekir. Bu çok sık yapılan bir mantık hatasıdır: Bir sayfayı hem robots.txt ile engelleyip hem de "noindex koydum ama hâlâ indexte" diye şikâyet etmek — engelliyse Googlebot sayfaya hiç girmediği için noindex etiketini okuyamaz ve etiket işlevsiz kalır.

Denetim raporunuzda şu üç durumu ayrı ayrı doğrulayın: bir sayfanın indexlenmemiş olması, taranamamış olması ve sıralanmaması birbirinden farklı problemlerdir. Sayfa taranıp indexlendiği hâlde hiç tıklama almıyorsa bu bir teknik değil, alaka/kalite veya rekabet sorunudur ve çözümü farklı yerdedir. Search Console'un Sayfalar raporu indeksleme tarafının nedenini (noindex, taranıp indexlenmemiş, 404, kanonik alternatif vb.) ayrıştırır; Performans raporu ise sıralama tarafını (gösterim var ama tıklama yoksa CTR sorunu, gösterim de yoksa görünürlük sorunu) gösterir. Bu teknik temizlik, on-page ve içerik tarafıyla birleştiğinde anlam kazanır; sayfa içi sinyalleri on-page SEO rehberimizde, tüm bu teknik altyapının üzerine kurulan konu otoritesini ise topical authority ve içerik kümesi yazımızda ele alıyoruz. Teknik denetiminizi profesyonel bir gözle yaptırmak isterseniz dijital pazarlama danışmanlığı hizmetimiz kapsamında sitenizi baştan sona tarayıp önceliklendirilmiş bir yol haritası çıkarıyoruz.

Teknik SEO denetimi adım adım nasıl yapılır?

Teknik SEO denetimi, bir sitenin Google'ın üç temel aşamasında (tarama, indeksleme, sıralama) yaşadığı tüm engelleri sistematik biçimde tespit etme sürecidir. Doğru sıra önemlidir: önce Googlebot'un sayfaya ulaşıp ulaşamadığını, sonra indeksleyip indeksleyemediğini, en sonunda performans ve yapısal veri katmanını incelersiniz. Müşterilerimizde gördüğümüz en yaygın hata, denetime hız puanından başlamaktır; oysa indekslenemeyen bir sayfanın hızı hiç fark etmez. Aşağıda uçtan uca, tekrarlanabilir bir akış sunuyoruz.

Denetimin temel mantığını anlamak için Google sıralama faktörleri 2026 yazımızı ve teknik SEO'nun on-page tarafıyla nasıl birleştiğini gösteren on-page SEO rehberimizi birlikte okumanızı öneririz; bu üçü tek bir bütünün parçalarıdır.

Şu noktayı baştan netleştirelim: "indekslenmemiş" ile "sıralanmamış" tamamen ayrı iki tablodur ve çözümleri de farklıdır. Bir sayfa indeksli olduğu hâlde hiçbir sorgu için ilk sayfalarda görünmüyorsa sorun teknikte değil, içerik alakası, arama amacı uyumu veya rekabet tarafındadır; bunu denetimle değil, içerik ve strateji çalışmasıyla çözersiniz. Tersine, içeriği mükemmel ama indekslenemeyen bir sayfanın hiç şansı yoktur. Denetimde ilk işiniz bu ayrımı her sayfa için net yapmaktır; çünkü yanlış teşhis, haftalarca yanlış katmanda emek harcamanıza yol açar.

Adım adım teknik SEO denetim akışı

Aşağıdaki sekiz adımı sırayla uygulayın. Her adım bir öncekinin sonucuna dayanır; atlamayın. Akışı "huniyi yukarıdan aşağı" gibi düşünün: en üstte Googlebot'un kapıdan girip giremediği (tarama), ortada içeriğin index'e kaydedilip kaydedilmediği (indeksleme), en altta sayfanın hızlı, mobil uyumlu ve makinece anlaşılır olup olmadığı (performans ve yapısal veri) sorgulanır. Üstteki bir tıkanıklık, alttaki tüm iyileştirmeleri anlamsız kılar.

1. Tarama (crawl) erişimini doğrulayın

Önce robots.txt dosyasını kontrol edin. robots.txt tarama kontrolü içindir, indekslemeyi garantili engellemez; ama render için gerekli CSS/JS kaynaklarını yanlışlıkla engelliyorsanız Google sayfanızı eksik görür. Mobil ve masaüstü için aynı kuralların geçerli olduğundan emin olun. Site genelinde bir Disallow: / kalıntısı (genellikle staging'den canlıya taşınırken unutulur) tüm trafiğinizi öldürebilir.

robots.txt'i okurken üç şeyi mutlaka kontrol edin. Birincisi, kural sırası: Googlebot en spesifik (en uzun eşleşen) kuralı uygular, dolayısıyla genel bir Disallow altında dar bir Allow istisnası varsa bunun doğru yazıldığından emin olun. İkincisi, dosyanın bağlandığı host: https://siteadi.com/robots.txt ile www'lu sürüm farklı dosyalar sunabilir; her ikisini de açın. Üçüncüsü, robots.txt içinde bildirilen sitemap satırının doğru ve HTTPS adresini gösterdiğini doğrulayın. Pratik bir teşhis ipucu: bir geliştirme sürecinin ardından organik trafik birden düştüyse, ilk bakacağınız yer neredeyse her zaman robots.txt'tir; canlıya yanlışlıkla taşınmış bir staging kuralı, en sık karşılaştığımız "felaket" senaryosudur.

2. İndeksleme durumunu çıkarın

Bir sayfanın "indekslenmemiş" olması ile "sıralanmaması" farklı sorunlardır. Google Search Console'un Sayfalar/İndeksleme raporu hangi sayfaların indexli, hangilerinin neden indexlenmediğini (noindex, kanonik alternatif, taranıp indexlenmemiş, 404) gösterir. Bir sayfayı indeksten çıkarmak için robots.txt değil noindex meta etiketi/HTTP başlığı kullanılır; üstelik Google noindex'i okuyabilsin diye o sayfa robots.txt ile engellenmemiş olmalıdır. Bu iki kuralı karıştırmak en sık gördüğümüz çelişkidir. GSC kullanımını derinlemesine ele aldığımız Google Search Console rehberi bu raporları satır satır açıklar.

Sayfalar raporundaki "İndekslenmedi" durumlarını yüzeysel geçmeyin; her bir neden farklı bir aksiyon ister. Sık karşılaşılan durumları ve doğru yorumunu aşağıdaki tabloda topladık:

Önemli bir nüans: "Keşfedildi - şu anda indekslenmedi" ile "Taranıp indekslenmedi" sık karıştırılır ama çözümleri zıttır. Birincisinde Google sayfayı henüz görmedi (erişim/öncelik problemi), ikincisinde gördü ve beğenmedi (kalite problemi). Yüzlerce URL'in birinci grupta sıkışması çoğu zaman zayıf iç linkleme ve tarama önceliği sorununa işaret eder; bu yüzden bu adımı iç link yapınızla birlikte değerlendirin.

3. Tekil URL'leri inceleyin

Şüpheli sayfalar için GSC'nin URL İnceleme aracını çalıştırın: indexli olup olmadığını, son taranma zamanını, Google'ın seçtiği kanoniği ve render sonucunu görürsünüz. Yeni veya güncellenmiş kritik sayfalar için "İndekslenmeyi iste" ile manuel tarama tetikleyebilirsiniz. Yapısal verinin doğru render edildiğini de burada teyit edin.

URL İnceleme'de en kıymetli iki bilgi şunlardır: "Google tarafından seçilen kanonik" ile "Kullanıcı tarafından belirtilen kanonik" satırlarının uyuşup uyuşmadığı ve "Test edilen sayfayı görüntüle" altındaki render edilmiş HTML. Render çıktısında ana içeriğiniz, başlıklarınız ve JSON-LD bloğunuz görünmüyorsa, sayfanız büyük olasılıkla istemci tarafı JavaScript'e fazla bağımlıdır ve Google içeriği geç ya da eksik görüyordur. "İndekslenmeyi iste" özelliğini stratejik kullanın: bu, toplu indeksleme aracı değildir, günlük kotası vardır ve sıra garantisi sunmaz. Yüzlerce sayfayı tek tek istemek yerine, çok sayıda yeni sayfa için doğru yol sitemap'i güncel tutmak ve iç linklemeyle keşfi kolaylaştırmaktır.

4. Sitemap ve kanonik tutarlılığını denetleyin

XML sitemap yalnızca indexlenebilir, kanonik URL'ler içermelidir; noindex sayfa, yönlendirme hedefi veya duplicate URL koymayın ve tüm girişler HTTPS olsun. rel="canonical" ile yinelenen içerikte tercih edilen URL'yi belirtin; kendi kendine kanonik (self-referencing) iyi bir pratiktir. Sitemap'i GSC'nin Sitemap'ler bölümünden gönderin. Pratikte "yeni sayfalar Google'da görünmüyor" şikayetinin kök nedeni çoğu zaman sitemap'in GSC'ye hiç gönderilmemiş olmasıdır; bu nedenle bu adımı asla atlamayın.

Kanonik sinyallerini değerlendirirken şu üç kanalın aynı URL'yi göstermesi gerektiğini unutmayın: sayfanın rel="canonical" etiketi, sitemap'teki giriş ve sayfaya gelen iç linkler. Bu üçü çeliştiğinde Google kendi kararını verir ve sizin tercih ettiğiniz URL'yi seçmeyebilir. E-ticarette bu çelişki çok yaygındır: filtre ve sıralama parametreleri (?renk=mavi, ?siralama=fiyat) yüzlerce neredeyse-aynı URL üretir; bunların hepsi temiz ana ürün/kategori URL'sine kanonik vermeli, sitemap'e ise yalnızca temiz sürüm girmelidir. Bu konuyu derinlemesine ele aldığımız e-ticaret SEO rehberimizde ürün ve kategori sayfalarındaki kanonik kalıplarını örneklerle bulabilirsiniz. Ayrıca büyük sitelerde tek dev sitemap yerine bölümlere ayrılmış sitemap'ler (ürünler, kategoriler, blog) ve bir sitemap index dosyası kullanmak, GSC'de hangi bölümün indekslenme oranının düşük olduğunu izole etmenizi sağlar.

5. Mobil eşdeğerliği ve HTTPS'i kontrol edin

Mobil-öncelikli indeksleme 5 Temmuz 2024'te tüm siteler için tamamen tamamlandı; tüm indeksleme ve sıralama sinyalleri artık akıllı telefon taramasından geliyor. Bu yüzden mobil sürümde masaüstüyle aynı ana içerik, başlıklar, iç linkler ve yapısal veri bulunmalı. HTTPS temel bir gerekliliktir: tüm site HTTPS olmalı, HTTP→HTTPS yönlendirilmeli; sitemap, canonical ve hreflang her zaman HTTPS göstermeli.

Pratikte mobil eşdeğerlik en çok şu üç yerde bozulur: ilk olarak, mobilde "Devamını oku" sekmesi arkasına gizlenen ve render edilmeyen metin; Google sekme arkasındaki içeriği görebilir ama tasarımınız onu DOM'dan tamamen çıkarıyorsa o içerik mobil sürümde yok sayılır. İkincisi, masaüstünde olup mobilde kaldırılan iç linkler veya gezinme menüsü; bu, Google'ın sitenizi keşfetme ve PageRank dağıtma yeteneğini doğrudan zayıflatır. Üçüncüsü, yalnızca masaüstü şablonuna eklenen JSON-LD yapısal verisi; mobil şablon onu içermiyorsa zengin sonuç uygunluğunuz sessizce kaybolur. HTTPS tarafında ise en sinsi sorun "karışık içerik"tir (mixed content): sayfa HTTPS sunulurken içindeki bir görsel, script veya canonical hâlâ HTTP gösterir. Tüm sinyallerin tek bir HTTPS sürümde birleştiğini doğrulayın.

6. Core Web Vitals ve performansı ölçün

Performans katmanına ancak indeksleme sağlıklı olduktan sonra geçin. Güncel Core Web Vitals eşikleri (75. persentil "İyi" değerleri) şöyledir: LCP ≤ 2,5 saniye, INP ≤ 200 milisaniye, CLS ≤ 0,1. Önemli not: 12 Mart 2024 itibarıyla INP (Interaction to Next Paint), FID'in yerini aldı; FID artık kullanımdan kaldırıldı, dolayısıyla bir denetim raporunda hâlâ "FID" görüyorsanız o şablon eskimiş demektir. Bu eşikleri ve düzeltme yöntemlerini site hızı ve Core Web Vitals rehberimizde, ölçüm araçlarını ise PageSpeed Insights yazımızda ayrıntılı bulabilirsiniz.

Üç metriği yorumlarken hangi metriğin neyi yakaladığını ve denetimde nereye bakacağınızı bilin:

INP'nin FID'den temel farkını anlamak denetim için kritiktir: FID yalnızca ilk etkileşimin gecikmesini ölçüyordu; INP ise kullanıcının sayfayla geçirdiği tüm süre boyunca her tıklama, dokunuş ve tuş etkileşimine verilen yanıtı kapsar. Mantığı şudur: kullanıcılar zamanlarının büyük bölümünü sayfa yüklendikten sonra geçirir, dolayısıyla "tıkladığımda kaç milisaniyede tepki alıyorum" sorusu gerçek deneyimi temsil eder. INP aralıkları: ≤200 ms iyi, 201-500 ms geliştirilmeli, 500 ms üzeri zayıftır. Denetimde lab verisi (Lighthouse) ile saha verisini (CrUX) ayırın: lab tek bir kontrollü ölçümdür ve özellikle INP'yi tam yansıtmaz çünkü gerçek kullanıcı etkileşimi taklit edilemez; bu yüzden CWV kararlarınızı her zaman gerçek kullanıcı verisine dayandırın. Son olarak Core Web Vitals'ın yerini doğru konumlandırın: bu bir hijyen/eşik faktörüdür, içeriğin önüne geçmez. "İyi" değerler eşit kalitedeki iki sayfa arasında ayrım yapabilir ama zayıf içeriği sıralamada kurtarmaz.

7. Yapısal veriyi (schema) doğrulayın

Sitenin temel schema setini kontrol edin: Organization + BreadcrumbList + içeriğe uygun ana tip (Article, Product veya LocalBusiness). 2026'da hâlâ görsel zengin sonuç veren tipler arasında Article/BlogPosting, Product + Offer + AggregateRating, BreadcrumbList, Organization ve LocalBusiness bulunur. Schema'yı JSON-LD formatında yazın ve Rich Results Test ile Schema Markup Validator araçlarından geçirin. Detaylı kullanım için yapısal veri / schema markup rehberimize bakın.

Burada bir denetimcinin en büyük yanılgısına dikkat çekelim: FAQPage ve HowTo yapısal verisini ekleyip görsel zengin sonuç (açılır SSS, adım kartları) beklemek. Google FAQ zengin sonucunu Ağustos 2023'te yalnızca otoriter devlet ve sağlık siteleriyle sınırladı; sıradan işletme, e-ticaret, SaaS ve ajans siteleri bu görünümü almayı çoktan bıraktı. 2026'da destek tamamen kaldırılıyor: FAQ arama görünümü ve Rich Results Test desteği 2026 içinde, Search Console API'deki FAQ desteği 2026 içinde sona eriyor. HowTo zengin sonucu da kaldırıldı. Bu schema'ları eklemek zarar vermez ve içeriği AI motorlarının yapısal olarak anlamasına (AEO açısından) yardımcı olabilir; fakat bunlardan SERP'te görsel bir kazanç beklemeyin. Denetim raporunuzda bu beklentiyi düzeltmek, ekibin yanlış bir önceliğe emek harcamasını engeller. Buna karşılık gerçekten görsel sonuç veren tipleri (Product için fiyat/yıldız/stok, Article için üst-hikaye görünümü, BreadcrumbList için yol gösterimi) doğru yapılandırmaya odaklanın; AggregateRating/Review yalnızca izin verilen tiplerde (ör. Product, LocalBusiness) gösterilir, serbest "kendi kendini öven" yıldızlar gösterilmez.

8. Çok dilli ve uluslararası sinyalleri gözden geçirin

Çok dilli site işletiyorsanız hreflang etiketlerinin karşılıklı (reciprocal) olduğundan, x-default verildiğinden ve her birinin kendi dilindeki kanonik sayfaya işaret ettiğinden emin olun. Bir uyarı: hreflang bir yönlendirme aracı değildir; ziyaretçiyi sunucu tarafından otomatik başka bir dile yönlendirmek sonsuz döngü riski yaratır. hreflang yalnızca Google'a dil-bölge eşlemesini bildirir.

hreflang denetiminde en sık üç hata çıkar: birincisi, A sayfası B'ye hreflang verirken B'nin A'ya geri vermemesi (tek yönlü, geçersiz eşleme); ikincisi, hreflang'in kanonik ile çelişmesi, yani sayfa kendi dil sürümüne hreflang verirken kanoniği başka bir dile işaret etmesi; üçüncüsü, x-default'un hiç verilmemesi, böylece eşleşmeyen dil/bölge ziyaretçilerine hangi sürümün gösterileceğinin belirsiz kalması. Bir ek not: sunucu tarafında ziyaretçinin diline göre otomatik yönlendirme yapmak hem döngü riski taşır hem de Googlebot'un bölgesine göre tek bir sürümde sıkışıp diğerlerini hiç görmemesine yol açabilir; doğru çözüm yönlendirme değil, doğru hreflang sinyalleridir.

Hangi araçları kullanmalı?

Teknik SEO denetiminin omurgası ücretsiz Google araçlarıdır; ücretli araçlar üzerine eklenir, yerine geçmez. En güvenilir veri her zaman kendi sitenizin gerçek verisidir.

GSC'nin Performans raporu dört temel metrik verir: Tıklama, Gösterim, TO (CTR) ve Ortalama Pozisyon. Bunları sorgu, sayfa, cihaz ve ülke bazında filtreleyerek teknik bir sorunun trafiğe yansıyıp yansımadığını doğrulayabilirsiniz; örneğin gösterim var ama tıklama düşükse sorun teknik değil, büyük olasılıkla başlık/açıklama tarafındadır. Site genelinde altyapı tespiti veya rakip analizi için e-ticaret altyapı tespit aracımızı da denetiminize ekleyebilirsiniz. Core Web Vitals raporu GSC içinde CrUX verisiyle URL gruplarını İyi/Geliştirilmeli/Zayıf olarak sınıflar ve mobil ile masaüstünü ayrı gösterir; saha verisi her zaman lab verisinden önceliklidir.

Araçlar arasında bir iş bölümü kurun: GSC size "Google sitemi gerçekte nasıl görüyor" sorusunun cevabını verir (saha gerçeği), Lighthouse/PageSpeed tek bir sayfayı kontrollü koşulda derinlemesine inceler (lab teşhisi), Rich Results Test yapısal verinizin uygunluğunu doğrular. Hiçbiri tek başına yeterli değildir; örneğin bir sayfa Lighthouse'ta yeşil görünüp CrUX saha verisinde "Geliştirilmeli" çıkabilir, çünkü gerçek kullanıcıların cihazları ve bağlantıları lab ortamından yavaştır. Bu durumda saha verisini esas alın. Hız ölçümlerinin nasıl yorumlanacağını ve hangi düzeltmenin hangi metriği iyileştirdiğini PageSpeed Insights rehberimizde adım adım ele aldık.

Denetimde en sık görülen teknik hatalar

On yıllık saha deneyimimizde aynı hataların tekrar ettiğini görüyoruz. Aşağıdaki liste, denetim raporlarında en çok işaretlediğimiz sorunları öncelik sırasına göre toplar.

• noindex / robots.txt çelişkisi: Sayfa robots.txt ile engellenmiş ama aynı zamanda noindex taşıyor. Google sayfayı tarayamadığı için noindex'i hiç okuyamaz; sayfa başka yerden linklenmişse yine indexlenebilir. İstenen sonuç için sayfayı taranabilir bırakıp noindex'i okutmak gerekir.
• Sitemap'te indexlenmeyen URL'ler: noindex sayfalar, yönlendirme hedefleri veya HTTP sürümler sitemap'e konunca Google karışık sinyaller alır. Sitemap yalnızca kanonik, indexlenebilir HTTPS URL içermeli.
• Render için gerekli kaynakların engellenmesi: robots.txt'te CSS/JS engellenince Google sayfayı kullanıcının gördüğü gibi göremez ve içeriği eksik değerlendirir.
• Mobil-masaüstü içerik farkı: Mobil sürümde daraltılmış içerik, eksik iç link veya eksik yapısal veri. Mobil-öncelikli indekslemede değerlendirilen sürüm mobildir; eksik olan ne varsa Google'ın gözünde yoktur.
• Eski/yanlış schema beklentisi: FAQPage ve HowTo yapısal verisi ekleyip görsel zengin sonuç (açılır SSS, adım kartları) beklemek. Google FAQ rich result'ı Ağustos 2023'te yalnızca otoriter devlet ve sağlık siteleriyle sınırladı ve 2026'da desteği tamamen kaldırıyor (FAQ search appearance ve Rich Results Test desteği 2026 içinde, Search Console API desteği 2026 içinde). HowTo rich result'ı da kaldırıldı. Bu schema'lar zarar vermez ve içerik anlaşılırlığı/AEO açısından hâlâ değerli olabilir, ama bunlardan görsel zengin sonuç beklemeyin.
• Karışık kanonik sinyaller: Bir sayfa kendine kanonik derken sitemap veya iç linkler başka URL'ye işaret ediyor. Google çelişkili sinyalde kendi seçtiği kanoniği kullanır ve bu sizin istediğiniz URL olmayabilir.
• Eksik HTTPS tutarlılığı: Site HTTPS ama bazı iç linkler, canonical'lar veya hreflang girişleri hâlâ HTTP gösteriyor. Tüm sinyaller HTTPS'te birleşmeli.
• Performans katmanını içerikten önce optimize etmek: CWV bir hijyen/eşik faktörüdür; içerik alakası ve kalitesi her zaman önceliklidir. "İyi" CWV, eşit kalitedeki iki sayfa arasında ayrım yapabilir ama zayıf içeriği kurtarmaz.
• Eski metrik ve şablon kullanmak: Denetim raporunda hâlâ "FID" geçiyorsa veya "FAQ schema ekleyince açılır SSS çıkar" yazıyorsa, kullanılan şablon güncellenmemiş demektir. 12 Mart 2024'ten beri geçerli Core Web Vital INP'dir; eski metriğe göre alınan kararlar yanlış önceliklere yol açar.
• Yönlendirme zincirleri ve döngüleri: A → B → C şeklinde uzayan 301 zincirleri tarama bütçesini boşa harcar ve sinyal kaybına yol açar; daha kötüsü A → B → A döngüleri sayfayı tamamen erişilemez kılar. Her yönlendirmenin tek adımda nihai hedefe gitmesini sağlayın.
• Yumuşak 404 (soft 404): "Ürün bulunamadı" gibi boş bir sayfa 200 durum koduyla dönerse Google bunu içeriksiz ama "var" sanır; gerçek 404 veya uygun yönlendirme döndürmek doğru sinyaldir.

Bu hataların çoğu, teknik denetimi düzenli bir takvime bağladığınızda kalıcı olarak ortadan kalkar. Teknik SEO'yu içerik tarafındaki çalışmayla birleştirmek için topical authority ve içerik kümesi yaklaşımımızı, denetimin başlangıç noktası olan strateji için ise SEO nedir ve nasıl yapılır rehberimizi inceleyebilirsiniz.

Denetimden sonra ne yapmalı?

Bulguları tek seferlik bir liste olarak değil, etkisine göre önceliklendirilmiş bir yol haritası olarak ele alın. Önce indekslemeyi engelleyen kritik sorunları (yanlış noindex, engellenmiş kaynaklar, eksik sitemap) düzeltin; bunlar trafiğe doğrudan ve hızlı etki eder. Ardından mobil eşdeğerliği ve HTTPS tutarlılığı gibi yapısal konuları, en sonunda Core Web Vitals ve schema iyileştirmelerini ele alın. Her düzeltmeden sonra GSC'de etkiyi izleyin; URL İnceleme ile yeniden tarama isteyin ve İndeksleme raporundaki sayıların düzeldiğini teyit edin.

Önceliklendirmeyi somutlaştırmak için bulguları "etki" ve "çaba" eksenlerinde sınıflandırmak işe yarar. Yüksek etki - düşük çaba kalemleri (örneğin canlıya kaçmış bir Disallow: / kuralını silmek, sitemap'i GSC'ye göndermek) ilk gün halledilmelidir; bunlar genelde tek satırlık düzeltmelerle büyük kazanç sağlar. Yüksek etki - yüksek çaba kalemleri (örneğin tüm sitenin INP'sini düşürmek için JavaScript'i hafifletmek) planlı bir sprint gerektirir. Düşük etki kalemlerini ise kuyruğun sonuna alın; her bulguya aynı aciliyetle koşmak ekibi yorar ve gerçek kazançları geciktirir. Düzeltmelerin etkisini ölçerken sabırlı olun: indeksleme değişikliklerinin GSC'ye yansıması ve yeniden taramanın tamamlanması günler, bazen haftalar alabilir; bir düzeltmeyi "işe yaramadı" diye geri almadan önce yeterli süre tanıyın.

Teknik SEO denetimi tek seferlik bir iş değildir; site büyüdükçe yeni sayfalar, yönlendirmeler ve şablon değişiklikleri sürekli yeni sorunlar üretir. Bir kez "temiz" çıkan bir site, üç ay sonra bir tema güncellemesi veya yeni bir ürün kataloğu yüklemesiyle yeniden bozulabilir; bu yüzden denetimi sürekliliğe bağlamak, tek seferlik bir temizlikten çok daha değerlidir. Kayseri merkezli ekibimiz olarak müşterilerimizde bu denetimi düzenli aralıklarla tekrarlıyor ve bulguları somut bir iş listesine çeviriyoruz. Sitenizin teknik durumunu uçtan uca incelememizi ve önceliklendirilmiş bir yol haritası çıkarmamızı istiyorsanız GEO denetim aracımızla hızlı bir başlangıç yapabilir, kapsamlı bir değerlendirme için ücretsiz analiz formumuzu doldurabilir veya dijital pazarlama danışmanlığı hizmetimizle sürekli bir teknik SEO takibi kurabilirsiniz.