Teknik SEO Denetimi Neleri Kapsar?

Teknik SEO denetimi, bir web sitesinin taranmasını, dizine eklenmesini ve sıralamasını etkileyen teknik sorunların sistematik incelemesidir. Bu inceleme beş katmanda ilerler: tarama ve indeksleme, sayfa içi, sayfalar arası, hız ve yapılandırılmış veri. Her katmanın kendi kontrol kodu, kanıt formatı ve skora etkisi vardır; kritik bir bulgu sayfayı aramadan tamamen çıkarabilirken düşük seviyeli bir bulgu yalnızca bir iyileştirme fırsatıdır. Rakip kaynakların çoğu sayfa başlığı ve meta açıklama için “60 karakter”, “160 karakter” gibi sayıları Google şartıymış gibi sunar; oysa Google resmi olarak sabit bir karakter sınırı vermez, yalnızca cihaz genişliğine göre kesme yapar. Aynı disiplinsizlik yapılandırılmış veri ve robots.txt için de geçerlidir: biri sıralamayı garanti etmez, diğeri bir sayfayı aramadan gizlemez. TechnoRadical’ın kendi denetim aracının gerçek kontrol kodları, kanıt formatları ve puanlama mantığı katman katman aktarılır; her katmanda gerçekte neyin, hangi eşikle test edildiği böylece görünür hale gelir. Search Console verisi, bağlantı profili ve yapay zeka görünürlüğü ise bu taramanın kapsamı dışındadır.

Teknik SEO denetimi neyi ölçer, hangi katmanlardan oluşur

Teknik SEO denetimi beş katmanda çalışır: tarama ve indeksleme, sayfa içi, sayfalar arası, hız ve yapılandırılmış veri. Her katman farklı bir soruyu cevaplar: arama motoru siteye erişebiliyor mu, tek tek sayfalar doğru işaretlenmiş mi, sayfalar birbiriyle çelişiyor mu, sayfa yeterince hızlı açılıyor mu ve makineler içeriği doğru okuyabiliyor mu.

TechnoRadical’ın kendi denetim aracı bu beş katmanı tararken ayrıca ikinci bir katmanı, içerik yapısını (bölümleme, cevap paragrafı, tablo, kaynak gösterimi) da ölçer ve bunun için ayrı bir skor üretir. İki skor birbirinden bağımsızdır: biri sitenin teknik SEO durumunu, diğeri içeriğin yapısal açıklığını gösterir. Bu ayrım kasıtlıdır, çünkü bir site teknik olarak kusursuz olup içerik yapısı zayıf olabilir, ya da tam tersi. İçerik yapısı skoru answer-first paragraf, soru başlığı ve tablo kullanımı gibi konuları kapsar; bu konular ayrıca GEO (Generative Engine Optimization, üretken arama motorlarında görünürlük çalışması) serisinde işlenir ve teknik SEO skorunun dışında kalır.

Tarama ve indeksleme katmanı hangi kontrolleri içerir

Tarama ve indeksleme katmanı, arama motorunun siteye erişip erişemediğini ve URL envanterini keşfedip keşfedemediğini beş kontrolle test eder. Bu kontroller robots.txt varlığı, site haritası bildirimi, site haritasının okunabilirliği, yönlendirme zinciri uzunluğu ve HTTPS kullanımıdır.

Beş kontrolün gerçek kodu ve kanıt formatı şöyledir.

• SEO-ROBOTS-YOK (orta seviye): robots.txt isteği 200 dışında bir HTTP yanıtı döndürdüğünde tetiklenir. Kanıt, ham HTTP yanıtının kendisidir: GET /robots.txt → HTTP 404.
• SEO-SITEMAP-BILDIRIM-YOK (orta seviye): robots.txt var ama içinde Sitemap: satırı yoksa üretilir.
• SEO-SITEMAP-BOS (kritik seviye): bildirilen site haritasından hiç URL çıkarılamazsa üretilir; bu, indekslemeyi doğrudan etkiler.
• SEO-YONLENDIRME-ZINCIRI (orta seviye): http’den https’e ve www ile www’suz sürüm arasındaki geçiş ikiden fazla adımda çözülüyorsa üretilir.
• SEO-HTTPS-YOK (kritik seviye): sitenin son adresi https:// ile başlamıyorsa üretilir.

Bu beş kontrolün içinde en sık yanlış anlaşılan robots.txt’tir. Google Search Central’ın robots.txt giriş dokümantasyonu şunu açıkça yazar: “it is not a mechanism for keeping a web page out of Google” (robots.txt, bir sayfayı Google’dan gizleme mekanizması değildir). Aynı sayfa “a page that’s disallowed in robots.txt can still be indexed if linked to from other sites” (robots.txt’te engellenen bir sayfa, başka sitelerden link alıyorsa yine de dizine eklenebilir) diyerek devam eder. Bu ayrım, robots.txt dosyasının taramayı sınırlayan ama bir sayfayı dizinden çıkarmayan bir mekanizma olduğunu gösterir; sayfayı aramadan tamamen çıkarmak için ayrıca, robots.txt ile aynı sayfada birlikte kullanıldığında etkisiz kalan noindex etiketi gerekir. Denetim aracının robots.txt eksikliğini “kritik” değil “orta” seviyede işaretlemesinin nedeni tam olarak budur: dosyanın yokluğu sayfayı gizlemez, yalnızca tarama önceliği sinyalini kaybettirir. Bu beş kontrolün tamamı sitenin taranabilir olup olmadığını ölçer, kaç sayfasının taranmaya değeceğini değil; tarama bütçesinin hangi büyüklükteki siteler için gerçek bir sorun haline geldiği ayrı bir eşik sorusudur ve küçük ölçekli çoğu sitede hiç devreye girmez.

Gerçek bir robots.txt dosyası, sitemap bildirimini şu şekilde taşır.

User-agent: *
Disallow: /admin/

Sitemap: https://ornek-site.com/sitemap.xml

Sayfalar arası kontroller kırık link ve yönlendirme hatalarını nasıl sınıflar

Sayfalar arası kontroller, tek bir sayfaya bakarak görülemeyen üç sorunu tarar: kırık iç bağlantılar, hiç iç bağlantı almayan yetim sayfalar ve tekrarlayan başlıklar. Bunlardan kırık link ve yetim sayfa kontrolü, HTTP yanıt kodlarını sitenin tamamı tarandıktan sonra karşılaştırır.

Kırık link kontrolünün (SEO-KIRIK-LINK, orta seviye) gerçek kuralı şudur: yalnızca 404, 410, 5xx sunucu hataları ve bağlantı hatası (isteğin hiç sonuçlanmaması) kırık sayılır. 401, 403 ve 429 yanıtları kasıtlı olarak dışarıda bırakılır; bunlar çoğunlukla bir güvenlik duvarının botu engellemesidir, gerçek bir ziyaretçide sayfa normal açılır. Çalışan bir sayfaya “kırık” demek denetimi çürütülebilir hale getirir.

Yetim sayfa kontrolü (SEO-YETIM-SAYFA, orta seviye), site haritasında yer alan ama hiçbir taranan sayfadan iç bağlantı almayan URL’leri işaretler. Bu kontrol yalnızca tarama site haritasını büyük ölçüde kapsadığında (tam tarama) güvenilirdir; kısmi bir taramada “yetim” görünen bir sayfa, aslında taranmamış başka bir sayfadan bağlantı alıyor olabilir.

Bu iki kontrolün tespit ettiği sorunların çoğu, aslında bir sayfayı silme veya birleştirme kararına dönüşür. Search Console’un Sayfa Dizine Ekleme raporu bu kararın sonucunu iki ayrı hata kategorisinde raporlar. “Soft 404” hatası şöyle tanımlanır: “it returns a user-friendly ‘not found’ message but not a 404 HTTP response code” (kullanıcı dostu bir “bulunamadı” mesajı gösterir ama 404 HTTP kodu döndürmez). Yönlendirme hataları ise üç isimlendirilmiş kategoride toplanır: “a redirect chain that was too long, a redirect loop, a redirect URL that eventually exceeded the max URL length” (çok uzun bir yönlendirme zinciri, bir yönlendirme döngüsü, azami URL uzunluğunu aşan bir yönlendirme). Bir sayfa feda edilirken 301 ile yönlendiriliyorsa hedefin başka bir yönlendirmeye değil doğrudan son adrese işaret etmesi gerekir; aksi halde bu üç kategoriden birine düşer. Bu noktada devreye giren hangi sayfanın feda edileceği kararı, 301, canonical, noindex seçenekleri arasında hangisinin doğru olduğunu belirler.

Sayfa başlığı ve meta açıklaması hangi eşikle kontrol edilir

Sayfa başlığı 30-60 karakter aralığının, meta açıklaması ise 70-160 karakter aralığının dışına çıktığında araç bunu işaretler; ama bu eşik bir Google şartı değildir, aracın kendi okunabilirlik sezgisidir.

Gerçek kontrol kodları şunlardır.

• SEO-TITLE-YOK (kritik seviye): <title> etiketi hiç yoksa.
• SEO-TITLE-UZUN (orta seviye): başlık 60 karakteri aşıyorsa; kanıt, başlığın ilk 80 karakteri ve toplam uzunluğudur.
• SEO-TITLE-KISA (düşük seviye): başlık 30 karakterin altındaysa.
• SEO-DESC-YOK (orta seviye): <meta name="description"> etiketi yoksa.
• SEO-DESC-UZUN (düşük seviye): açıklama 160 karakteri aşıyorsa.
• SEO-DESC-KISA (düşük seviye): açıklama 70 karakterin altındaysa; kanıt açıklamanın tam metnidir.

Bu sayılar Google Search Central’ın kendi ifadesiyle çelişir. Title link dokümantasyonu şöyle yazar: “while there’s no limit on how long a title element can be, the title link is truncated in Google Search results as needed, typically to fit the device width” (title elementinin uzunluğuna sabit bir sınır yoktur; başlık, genellikle cihaz genişliğine sığacak şekilde gerektiğinde kesilir). Aynı sayfa, Google’ın bir sorun tespit ettiğinde kendi başlığını üretebileceğini de ekler. Snippet dokümantasyonu meta açıklama için aynı ilkeyi tekrarlar: sabit bir karakter sınırı yoktur, snippet cihaz genişliğine göre kesilir ve Google bazen kendi ürettiği pasajı meta açıklamanın önüne geçirir.

Bu, sektörde dolaşan “title 60 karakteri geçmesin” veya “meta açıklama 150-160 karakter olsun” kuralının bir Google şartı değil, kesilme davranışının gözlemlenmesinden gelen bir sezgi olduğunu gösterir. Sezgi tamamen işe yaramaz değildir; kesilme davranışının kabaca nerede başladığını tahmin etmeye yarar. Ama bir eşiği aşmanın “hata” sayılması ile bir Google kuralını ihlal etmiş olmak aynı şey değildir, ve rakip içeriklerin çoğu bu ikisini ayırt etmeden aynı cümlede kullanır. Sayıların kaynağının nereden geldiğini ayırt etmek için genel olarak iddianın kaynağını geriye doğru izlemek gerekir; bu, yalnızca title/meta eşikleri için değil, sektörde dolaşan her sayı için geçerli bir yöntemdir.

Canonical ve yinelenen içerik denetimde nasıl yakalanır

Canonical ve yinelenen içerik kontrolleri üç ayrı bulgu üretir: canonical etiketinin yokluğu, birden fazla sayfada tekrarlanan başlık ve birden fazla sayfada tekrarlanan meta açıklama; üçü de tek başına kanibalizasyon kanıtı sayılmaz.

SEO-CANONICAL-YOK (orta seviye), <link rel="canonical"> etiketi bulunamadığında üretilir. SEO-TITLE-YINELENEN (orta seviye), aynı başlık birden fazla sayfada tekrarlandığında üretilir; aracın kendi açıklama metni şöyle der: “bu tek başına kanibalizasyon kanıtı değildir; sayfaların niyeti, kapsamı ve Search Console sorguları birlikte incelenmelidir.” SEO-DESC-YINELENEN (düşük seviye) aynı mantığı meta açıklama için tekrarlar.

SEO-CANONICAL-YOK yalnızca etiketin sayfada tamamen bulunmadığı durumu yakalar. Etiket sayfada varken robots.txt çakışması, noindex çelişkisi, hreflang uyumsuzluğu veya JavaScript enjeksiyonu yüzünden sessizce yanlış bir URL’yi hedeflemesi ayrı bir denetim konusudur ve hiçbir hata mesajı üretmeden gerçekleşir; kanonik etiketin sessizce yanlış kurulduğu on bir yapılandırma hatası bu senaryoları tek tek ele alır.

Bu temkinli dil rastgele değil, Google’ın kendi mekanizmasıyla uyumludur. Google Search Central’ın canonicalization sayfası süreci şöyle tanımlar: Google önce her sayfanın ana içeriğini belirler, benzer sayfaları gruplar, sonra “chooses the page that, based on the factors (or signals) the indexing process collected, is objectively the most complete and useful for search users” (indeksleme sürecinin topladığı sinyallere dayanarak, arama kullanıcıları için objektif olarak en eksiksiz ve kullanışlı sayfayı seçer) diyerek temsilci URL’yi belirler. Duplike URL birleştirme rehberi bu sinyalleri güce göre sıralar: 301 yönlendirmesi ve rel="canonical" etiketi “güçlü sinyal”, site haritasında listelenmek ise yalnızca “zayıf sinyal”dir. Aynı rehber şunu da ekler: “none of them are required; … if you don’t specify a canonical URL, Google will identify which version of the URL is objectively the best version to show to users in Search” (hiçbiri zorunlu değildir; canonical URL belirtilmese bile Google hangi sürümün objektif olarak en iyisi olduğunu kendisi belirler). Best practice olarak site içi bağlantıların da duplike değil canonical URL’ye verilmesi önerilir.

Google’ın Arama Savunucusu John Mueller de aynı temkini paylaşıyor. Search Engine Journal’ın aktardığı bir yanıtta Mueller şöyle diyor: “if you have 3 different pages appearing in the same search result, that doesn’t seem problematic to me just because it’s ‘more than 1’” (aynı sonuç sayfasında üç farklı sayfa görünmesi, sırf birden fazla olduğu için sorunlu değildir). Bu yüzden yinelenen başlık bulgusu bir alarm değil bir inceleme davetiyesidir; kanibalizasyonun gerçek zarar verip vermediği ancak Search Console’daki gösterim ve tıklama dağılımıyla anlaşılır.

Sayfa hızı denetimde hangi eşiklerle ölçülür

Sayfa hızı iki ayrı katmanda ölçülür: Core Web Vitals’ın (Google’ın temel kullanıcı deneyimi ölçütlerinin) resmi eşikleri ve aracın kendi sayfa ağırlığı/betik sayısı kontrolleri.

Web.dev’in resmi rehberleri üç metrik için “iyi” eşiğini şöyle verir.

Metrik	İyi	Geliştirilmeli	Zayıf
LCP (Largest Contentful Paint, en büyük içerik boyaması)	2,5 sn veya altı	2,5-4,0 sn	4,0 sn üstü
INP (Interaction to Next Paint, etkileşimden sonraki boyamaya geçen süre)	200 ms veya altı	200-500 ms	500 ms üstü
CLS (Cumulative Layout Shift, kümülatif yerleşim kayması)	0,1 veya altı	0,1-0,25	0,25 üstü

Bu eşikler LCP, INP ve CLS için web.dev’in resmi sayfalarında yayınlanır ve mobil-masaüstü karışık sayfa yüklemelerinin 75. yüzdelik dilimi üzerinden değerlendirilir. TTFB (Time to First Byte, ilk bayta kadar geçen süre) bu üçlünün içinde değildir; TTFB resmi bir Core Web Vitals metriği değil, tanı amaçlı destekleyici bir ölçümdür. Türkçe kaynaklardan bazıları TTFB’yi dördüncü bir Core Web Vitals gibi sayar; bu ayrımı atlamak, ölçülen şeyin ne olduğunu bulanıklaştırır.

Aracın kendi kontrolleri sayfa ağırlığına ve betik sayısına bakar: SEO-SAYFA-AGIR (orta seviye) HTML yanıtı 3 milyon bayt (3 MB) üzerindeyse, SEO-SCRIPT-COK (orta seviye) sayfada 20’den fazla harici betik yükleniyorsa üretilir. İkisi de Core Web Vitals’ın yerini tutmaz; yalnızca ağır bir sayfanın büyümesine katkıda bulunan iki somut nedeni gösterir.

Core Web Vitals ölçümünün kendisi de tek bir sayı değildir. TechnoRadical’ın hız modülü iki farklı veri döndürür ve bunları karıştırmamak önemlidir: saha verisi (CrUX, yani Chrome User Experience Report), Chrome kullanıcılarının son 28 günlük toplulaştırılmış deneyiminden gelir ve trafiği az olan sitelerde bu veri oluşmayabilir; laboratuvar verisi ise tek bir sanal cihazda yapılan tek seferlik bir ölçümdür, her zaman vardır ama gerçek kullanıcı davranışını temsil etmez. Bir site için saha ve laboratuvar hız verisinin ayrı ayrı görülmesi, hangi ölçüme ne kadar güvenileceğini netleştirir. Bu katman hangi sayfanın hangi bantta durduğunu gösterir, ama tespit edilen sorunu hangi kod satırının düzelteceğini söylemez; Core Web Vitals nasıl düzeltilir yazısı LCP, CLS ve INP için çalışan kod örnekleriyle bu adımı tamamlar.

Yapılandırılmış veri denetimde neyi doğrular, neyi doğrulamaz

Yapılandırılmış veri kontrolü, sayfada JSON-LD (yapılandırılmış veriyi HTML içine gömen bir format) biçiminde bir işaretleme olup olmadığını doğrular; bunun ötesinde bir garanti taşımaz. Sayfada <script type="application/ld+json"> etiketi bulunamadığında bulgu üretilir ve kanıt olarak bu etiketin yokluğu gösterilir. Aracın kendi açıklaması şu ayrımı zaten taşır: yapılandırılmış veri desteklenen içerik türlerini makinece okunabilir biçimde tanımlar, zorunlu değildir ve sıralama ya da görünürlük garantisi vermez.

Bu, Google’ın kendi resmi ayrımıyla birebir örtüşür. Yapılandırılmış veri genel politikaları sayfası şöyle yazar: “using structured data enables a feature to be present, it does not guarantee that it will be present” (yapılandırılmış veri kullanmak bir özelliğin var olmasını mümkün kılar, var olacağını garanti etmez). Yaptırım tarafında da aynı sınır korunur: “a structured data manual action means that a page loses eligibility for appearance as a rich result; it doesn’t affect how the page ranks in Google web search” (bir yapılandırılmış veri manuel işlemi, sayfanın zengin sonuç olarak görünme uygunluğunu kaybetmesi demektir; sayfanın web aramasındaki sıralamasını etkilemez). Yani şema eklemek zengin sonuç uygunluğu sağlar, sıralama faktörü değildir; manuel bir ceza durumunda bile kaybedilen şey yalnızca bu uygunluktur.

Bulgular kritik, orta, düşük ve bilgi seviyesine nasıl ayrılır

Araç her bulguyu dört seviyeden birine koyar: kritik, orta, düşük ve bilgi; skor 100 puanla başlar ve bulunan her sorunun ağırlığı kadar düşer.

Seviye	Ne anlama gelir	Skora etkisi	Örnek bulgu
Kritik	Sayfa aramadan tamamen görünmez olur veya taranamaz	Büyük (10-20 puan aralığında)	SEO-HTTPS-YOK, SEO-NOINDEX, SEO-SITEMAP-BOS
Orta	Ölçülebilir bir kayıp var ama sayfa yine de görünür	Orta (4-10 puan aralığında, yaygınlık arttıkça üst sınıra yaklaşır)	SEO-CANONICAL-YOK, SEO-KIRIK-LINK
Düşük	İyileştirme fırsatı, acil değil	Küçük (1-4 puan aralığında)	SEO-DESC-KISA, SEO-H1-COKLU
Bilgi	Hata değil, farkında olunması gereken bir durum	Sıfır	Kasıtlı olabilecek bir yapılandırma tespit edildiğinde düşülen puan olmadan bildirilir

100 puanlık hesap basit ama kümülatiftir. Örneğin bir sitede HTTPS eksikliği gibi büyük etkili bir kritik bulgu skordan onlu bir pay düşürür; buna orta şiddette iki bulgu (örneğin canonical eksikliği ve bir sitemap bildirimi eksikliği) birkaçar puan daha eklerse ve üç düşük seviyeli bulgu birer iki puan kırparsa, toplam düşüş yirmili puan bandına ulaşır ve site 100 üzerinden yetmişli bir skora iner. Aynı zaafın iki farklı görünümü (örneğin hem eksik hem çok kısa bir başlık aynı anda raporlanmaz) skoru iki kez düşürmez; araç böyle çakışan gruplarda yalnızca en ağır bulguyu sayar.

Önceliklendirme kararı da bu seviye sırasını izler: araç bulguları önce seviyeye (kritik, orta, düşük, bilgi), aynı seviye içinde ise puan etkisinin büyüklüğüne göre sıralar. Pratikteki sonucu şudur: önce kritikler kapatılır, sonra orta seviyeler puan etkisi büyükten küçüğe işlenir, düşükler zaman kaldığında ele alınır. Bu sıralamanın kendi sitenizde veya bir müşterinin sitesinde nasıl göründüğünü görmek için otuz saniyede çalışan ücretsiz tarama gerçek zamanlı bir bulgu listesi, kanıt ve skor üretir.

Teknik SEO denetimi neyi ölçemez, hangi garantiyi vermez

Teknik SEO denetimi ham HTML ve HTTP yanıtları üzerinden çalışır; JavaScript ile sonradan oluşturulan içeriği göremez ve Search Console verisi, bağlantı profili, gerçek kullanıcı deneyimi ile yapay zeka cevaplarındaki görünürlük bu taramanın dışında kalır.

TechnoRadical’ın denetim aracı bu sınırları açıkça bildirir, tahmin etmez.

• Search Console ve analitik verisi: gerçek tıklama, gösterim ve sorgu verisi yalnızca site sahibinin kendi hesabından alınabilir.
• Bağlantı profili: siteye gelen dış bağlantılar ücretli bir veri sağlayıcı gerektirir; otomatik tarama bunu ölçemez.
• Gerçek kullanıcı deneyimi: yalnızca yeterli trafiği olan sitelerde CrUX saha verisi oluşur; küçük sitelerde bu boşluk laboratuvar ölçümüyle kısmen kapatılır, tamamen değil.
• Yapay zeka cevaplarındaki görünürlük: markanın ChatGPT, Gemini veya Perplexity cevaplarında geçip geçmediği, sayfadan ölçülebilen yapısal işaretlerden farklı, ayrı bir ölçüm gerektirir.

Bu dört sınırın ortak noktası şu: teknik SEO denetimi kritik engelleri kaldırır ama bir sıralama garantisi vermez. Bir sitenin denetimden yüksek puan alması, o sitenin daha üst sırada çıkacağı anlamına gelmez; yalnızca arama motorunun siteyi tarayıp doğru yorumlamasının önündeki teknik engellerin azaldığı anlamına gelir. Bunun tam mekanizması, yani sıralama garantisinin neden verilemediği, Google’ın sıralama kararını etkileyen çok daha geniş bir sinyal grubuna dayanır.

Teknik SEO denetimi ne sıklıkla tekrarlanmalı?

Teknik SEO denetimi her anlamlı değişiklikten sonra ve düzenli olarak ayda bir tekrarlanmalıdır. Anlamlı değişiklik; tema güncellemesi, eklenti kurulumu, sunucu taşıma veya toplu içerik yayını gibi işlemleri kapsar. Bu araçların en sık bozulduğu anlar tam olarak bu değişikliklerin hemen sonrasıdır; bir eklenti güncellemesi robots.txt’i sessizce değiştirebilir veya bir tema geçişi canonical etiketlerini kaybettirebilir.

WordPress veya Shopify gibi hazır altyapılarda teknik SEO denetimi farklı mı yapılır?

Kontrol mantığı platformdan bağımsızdır; araç HTTP yanıtına ve HTML yapısına bakar, hangi CMS’in bunu ürettiğiyle ilgilenmez. Ama düzeltme adımı platforma göre değişebilir. Google’ın kendi robots.txt dokümantasyonu bazı CMS kullanıcılarının (Wix, Blogger gibi) robots.txt dosyasını doğrudan düzenleyemeyebileceğini belirtir; bu durumda düzeltme dosyayı elle yazmak yerine platformun kendi SEO ayarları üzerinden yapılır. Kontrolün kendisi, yani robots.txt’in var olup olmadığı ve neyi işaretlediği, değişmez.