Blog · 27 Ekim 2026
Teknik SEO Nedir? Kontrol Listesiyle Teknik SEO Denetimi
Teknik SEO, bir sitenin arama motorları tarafından sorunsuz taranabilmesi, doğru sayfaların dizine eklenebilmesi ve kullanıcıya hızlı, güvenli, mobil uyumlu biçimde sunulabilmesi için yapılan altyapı çalışmalarının bütünüdür. İçerik ve bağlantılar "ne söylediğinizi" belirlerken teknik SEO, Google'ın bu söylediklerinizi bulup okuyabilmesini sağlar. Teknik temel bozuksa en iyi içerik bile arama sonuçlarında görünmez.
Bu yazıda teknik SEO'nun bileşenlerini tek tek ele alıyor, her birinin nasıl kontrol edileceğini somut adımlarla anlatıyor ve sonunda kendi sitenize uygulayabileceğiniz öncelik sıralı bir denetim tablosu veriyoruz. Amaç, "her şeye bakıp hiçbir şeyi düzeltmeyen" bir denetim yerine, gerçekten trafiği etkileyen sorunları önce bulan bir çalışma düzeni kurmak.
Teknik SEO neden ayrı bir iş?
Arama motorunun bir sayfayı sonuçlarda göstermesi üç aşamadan geçer: tarama (Googlebot sayfayı bulur ve indirir), dizine ekleme (sayfanın içeriği işlenir ve dizinde saklanır) ve sıralama (sorguya göre hangi sayfanın hangi sırada gösterileceğine karar verilir). İçerik ve backlink çalışmaları üçüncü aşamayı etkiler. Teknik SEO ise ilk iki aşamanın kesintisiz çalışmasını sağlar ve sıralamada kullanıcı deneyimi sinyallerine katkı verir.
Pratikte teknik sorunlar sessizdir. Bir geliştirici yanlışlıkla canlı siteye noindex etiketi bırakır, bir tema güncellemesi kanonik adresleri bozar, bir taşıma sonrası yüzlerce sayfa 404 vermeye başlar. Trafik düşer ama sitede gözle görülür bir hata yoktur. Bu yüzden teknik SEO bir kerelik kurulum değil, düzenli tekrarlanan bir denetimdir. Genel bir site sağlık kontrolünün nasıl kurgulandığını merak ediyorsanız SEO analizi rehberimiz teknik denetimin daha geniş analiz içindeki yerini gösteriyor.
Taranabilirlik: Googlebot sitenizi bulabiliyor mu?
Taranabilirlik, arama motoru botunun sayfalarınıza ulaşıp içeriği indirebilmesidir. Burada üç ana bileşen vardır: robots.txt, iç bağlantı yapısı ve tarama bütçesi.
robots.txt dosyası
robots.txt, alan adınızın kökünde (alanadi.com/robots.txt) duran ve botlara hangi yolları taramamaları gerektiğini söyleyen düz metin dosyasıdır. Kontrol ederken şu sorulara cevap arayın:
- Dosya erişilebilir mi ve 200 durum kodu mu dönüyor? Sunucu hatası veren bir robots.txt, Google'ın taramayı geçici olarak durdurmasına yol açabilir.
- Önemli bir dizin yanlışlıkla engellenmiş mi? Özellikle
Disallow: /satırı, geliştirme ortamından canlıya taşınan sitelerde sık görülen bir hatadır. - CSS ve JavaScript dosyaları engellenmiş mi? Google sayfayı bir tarayıcı gibi işler; bu dosyalara erişemezse sayfayı eksik görür.
- Site haritası adresi
Sitemap:satırıyla belirtilmiş mi?
Önemli bir ayrım: robots.txt taramayı engeller, dizine eklemeyi değil. Engellenmiş bir URL'ye başka sitelerden bağlantı varsa, Google içeriği okuyamasa da adresi dizine ekleyebilir. Bir sayfanın arama sonuçlarında görünmesini istemiyorsanız robots.txt değil noindex kullanmanız gerekir ve noindex'in görülebilmesi için sayfanın taranmasına izin verilmelidir.
İç bağlantı yapısı
Googlebot yeni sayfaları büyük ölçüde bağlantıları takip ederek bulur. Hiçbir sayfadan bağlantı almayan "yetim" sayfalar, site haritasında olsalar bile geç keşfedilir ve zayıf sinyal taşır. Kontrol için:
- Önemli sayfalarınızın ana sayfadan en fazla üç dört tıklamada ulaşılabilir olduğunu doğrulayın.
- Bağlantıların standart
<a href="...">etiketiyle verildiğinden emin olun. Yalnız JavaScript tıklama olayıyla çalışan menüler botlar için bağlantı sayılmayabilir. - Bağlantı metinlerinin hedef sayfanın konusunu anlatmasına dikkat edin; "buraya tıklayın" yerine açıklayıcı metin kullanın.
- Kırık iç bağlantıları (404'e giden linkler) ve yönlendirmeye giden iç linkleri düzeltin; iç linkler doğrudan nihai adrese gitmeli.
Tarama bütçesi
Tarama bütçesi, Google'ın belirli bir sürede sitenizde taramaya ayırdığı kaynak miktarıdır. Birkaç yüz sayfalık bir kurumsal sitede genellikle sorun olmaz. Asıl risk, filtre ve sıralama parametreleri yüzünden binlerce URL varyasyonu üreten e-ticaret ve ilan siteleridir. Belirtiler şunlardır: yeni ürünlerin günlerce dizine girmemesi, Search Console'un tarama istatistiklerinde parametreli adreslerin baskın olması, önemsiz sayfaların önemli sayfalardan daha sık taranması.
Çözüm genellikle şu üçlüdür: gereksiz parametre kombinasyonlarını robots.txt ile taramaya kapatmak, kopya varyasyonlarda kanonik etiketi doğru kullanmak ve sunucu yanıt süresini düşürmek. Yavaş yanıt veren sunucu, Google'ın tarama hızını kendiliğinden azaltmasına neden olur.
Dizine eklenebilirlik: doğru sayfalar dizinde mi?
Taranan her sayfa dizine eklenmez, eklenmesi de gerekmez. Hedef, değerli sayfaların dizinde, kopya ve değersiz sayfaların dizin dışında olmasıdır.
noindex etiketi
<meta name="robots" content="noindex"> etiketi ya da aynı işi gören X-Robots-Tag HTTP başlığı, sayfanın dizine eklenmemesini söyler. Teşekkür sayfaları, iç arama sonuçları, sepet ve hesap sayfaları için uygundur. Denetimde iki yönlü bakın: dizinde olması gereken bir sayfada yanlışlıkla noindex var mı, dizinde olmaması gereken sayfalarda eksik mi? Eklenti ve tema ayarları, kategori ya da etiket arşivlerine toplu noindex ekleyebildiği için CMS kullanan sitelerde bu kontrol özellikle önemlidir.
Kanonik etiket
<link rel="canonical" href="..."> etiketi, birbirine çok benzeyen sayfalardan hangisinin asıl sürüm olduğunu belirtir. Kanonik bir talimat değil, güçlü bir ipucudur; Google başka sinyallerle çelişiyorsa farklı bir sürümü seçebilir. Sık görülen hatalar:
- Tüm sayfaların kanoniğinin ana sayfayı göstermesi (şablon hatası).
- Kanonik adresin 404 veren ya da yönlenen bir URL olması.
- HTTP ile HTTPS, sonunda eğik çizgi olan ve olmayan sürümler arasında tutarsızlık.
- Kanonik etiketi olan sayfada aynı anda
noindexbulunması; bu iki sinyal birbiriyle çelişir.
Search Console sayfa raporu
Dizine ekleme durumunu görmenin en güvenilir yolu Google Search Console'daki sayfa dizine ekleme raporudur. Rapor, sayfaları dizine eklenmiş ve eklenmemiş olarak ayırır ve eklenmeyenler için nedenleri listeler: "noindex etiketiyle hariç tutuldu", "yönlendirmeli sayfa", "bulunamadı (404)", "kopya, Google kullanıcıdan farklı bir kanonik seçti", "tarandı, şu anda dizine eklenmedi" gibi. Bu nedenlerin her biri farklı bir aksiyon gerektirir.
Tek tek sayfalar için URL denetimi aracı, sayfanın dizinde olup olmadığını, Google'ın seçtiği kanonik adresi ve son tarama tarihini gösterir. Raporların nasıl okunacağını adım adım görmek için Google Search Console rehberine göz atabilirsiniz.
XML site haritası
Site haritası, dizine eklenmesini istediğiniz URL'lerin listesini arama motoruna sunar. Bağlantı yapısının yerini tutmaz ama keşfi hızlandırır. İyi bir site haritası için kurallar:
- Yalnız 200 durum kodu dönen, kanonik ve dizine eklenebilir URL'leri içermeli. Yönlenen, 404 veren ya da
noindextaşıyan adresler site haritasında olmamalı. - Tek dosya en fazla 50.000 URL ve sıkıştırılmamış hâlde 50 MB olabilir; daha büyük sitelerde site haritası dizini kullanılır.
lastmoddeğeri yalnız içerik gerçekten değiştiğinde güncellenmeli. Her gün tüm sayfalarda değişen bir tarih, bu sinyali anlamsız hâle getirir.- Site haritası Search Console'a gönderilmeli ve robots.txt içinde belirtilmeli.
Search Console'daki site haritası raporunda "gönderilen" ile "dizine eklenen" sayıları arasında büyük fark varsa, site haritasında dizine girmeye uygun olmayan adresler var demektir.
HTTPS ve güvenlik
HTTPS bugün temel bir beklentidir. Google HTTPS'i sıralama sinyali olarak kullanır ve tarayıcılar HTTP sitelerini güvensiz olarak işaretler. Kontrol listesi kısadır ama atlanmamalıdır:
- HTTP sürümü tek adımda, kalıcı (301) yönlendirmeyle HTTPS sürümüne gitmeli.
- www ve www'siz sürümlerden yalnız biri kullanılmalı, diğeri ona yönlenmeli.
- Sertifika geçerli olmalı ve süresi dolmadan yenilenmeli.
- HTTPS sayfalarda HTTP üzerinden yüklenen görsel veya script (karışık içerik) bulunmamalı.
- Kanonik etiketler, site haritası ve iç bağlantılar HTTPS adresleri kullanmalı.
Yönlendirmeler: 301, 302 ve zincirler
Yönlendirmeler, URL değiştiğinde ziyaretçiyi ve arama motorunu yeni adrese taşır. Doğru türü seçmek önemlidir:
- 301 (kalıcı): Adres kalıcı olarak değişti. Google, hedef adresi kanonik olarak benimser. Site taşıma, URL yapısı değişikliği ve birleştirilen sayfalar için kullanılır.
- 302 (geçici): Adres geçici olarak başka yere gidiyor, eski adres geri gelecek. Kalıcı bir değişiklikte 302 kullanmak, Google'ın hangi adresi esas alacağı konusunda gereksiz belirsizlik yaratır.
Yönlendirme zinciri, A'nın B'ye, B'nin C'ye yönlenmesidir. Her ek adım tarama kaynağı harcar ve sayfa yüklenmesini yavaşlatır; Google da çok uzun zincirlerin sonunu takip etmeyebilir. Site taşımalarında zincirler kaçınılmaz olarak oluşur: önce HTTP'den HTTPS'e, sonra eski URL yapısından yenisine. Denetimde her eski adresin tek adımda nihai adrese gittiğinden emin olun. Yönlendirme döngüsü ise A'nın B'ye, B'nin tekrar A'ya gitmesidir ve sayfayı tamamen erişilemez kılar.
Bir adresin yönlendirme yolunu görmek için tarayıcı geliştirici araçlarının Ağ sekmesini ya da komut satırında curl -I -L adres komutunu kullanabilirsiniz; her adımın durum kodu sırayla listelenir.
404 ve soft 404 hataları
404, sayfanın bulunamadığını bildiren normal bir durum kodudur. Silinmiş bir ürünün 404 vermesi tek başına sorun değildir. Sorun şu durumlarda başlar:
- Trafik alan, backlink kazanmış ya da iç bağlantı alan bir sayfanın 404'e düşmesi. Bu sayfalar ilgili güncel sayfaya 301 ile yönlendirilmeli.
- İç bağlantıların 404 sayfalara gitmesi. Bu hem kullanıcıyı hem botu çıkmaza sokar.
- Tüm silinen sayfaları toplu olarak ana sayfaya yönlendirmek. Google bunu çoğu zaman soft 404 olarak değerlendirir.
Soft 404, sunucunun 200 (başarılı) kodu döndürdüğü ama içeriğin aslında "sayfa bulunamadı" ya da boş olduğu durumdur. Stokta olmayan ürün sayfasının boş şablon göstermesi, sonuç bulunamayan arama sayfaları ve çok ince içerikli sayfalar tipik örneklerdir. Çözüm, gerçekten olmayan sayfa için gerçek 404 ya da 410 kodu döndürmek veya sayfaya anlamlı içerik eklemektir.
Core Web Vitals: LCP, INP ve CLS
Core Web Vitals, Google'ın sayfa deneyimini ölçtüğü üç metriktir. Değerlendirme gerçek kullanıcı verisinin 75. yüzdeliğine göre yapılır.
| Metrik | Neyi ölçer | İyi | Zayıf |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Görünür alandaki en büyük içeriğin yüklenme süresi | 2,5 sn ve altı | 4 sn üstü |
| INP (Interaction to Next Paint) | Tıklama ve dokunmalara sayfanın tepki süresi | 200 ms ve altı | 500 ms üstü |
| CLS (Cumulative Layout Shift) | Yükleme sırasında öğelerin beklenmedik kayması | 0,1 ve altı | 0,25 üstü |
INP, 2024'te FID'in yerini aldı; artık yalnız ilk etkileşim değil, sayfadaki tüm etkileşimlerin tepki süresi önemlidir.
Sık görülen nedenler ve çözümler
- LCP yüksekse: Ana görsel sıkıştırılmamış ya da geç keşfediliyordur. Görseli modern formatta (WebP, AVIF) ve doğru boyutta sunun, ana görsele tembel yükleme (lazy loading) uygulamayın, sunucu yanıt süresini ve oluşturmayı engelleyen CSS ile JavaScript'i azaltın.
- INP yüksekse: Ana iş parçacığını uzun süre meşgul eden JavaScript vardır. Ağır üçüncü taraf scriptleri gözden geçirin, uzun görevleri bölün, etkileşim anında yapılan gereksiz işleri erteleyin.
- CLS yüksekse: Görsellerin, reklam alanlarının ve gömülü içeriklerin boyutu tanımlı değildir ya da web fontu yüklenince metin kayar. Görsellere
widthveheightverin, dinamik alanlara önceden yer ayırın.
Ölçüm için iki tür veri vardır: gerçek kullanıcılardan toplanan saha verisi (Search Console'daki Core Web Vitals raporu ve PageSpeed Insights'ın üst bölümü) ve kontrollü ortamda üretilen laboratuvar verisi (Lighthouse). Google'ın değerlendirmesi saha verisine dayanır; laboratuvar verisi ise sorunun nedenini bulmak için kullanılır.
Mobil uyumluluk
Google siteleri mobil öncelikli dizine ekleme ile, yani ağırlıklı olarak sayfanın mobil sürümüne bakarak değerlendirir. Bu yüzden mobil sürümde eksik olan içerik, Google için de eksiktir. Kontrol edilecekler:
- Sayfada
<meta name="viewport" content="width=device-width, initial-scale=1">etiketi var mı? - Mobil ve masaüstü sürümlerde aynı ana içerik, başlıklar, yapılandırılmış veri ve meta etiketler bulunuyor mu?
- Metin yakınlaştırmadan okunabiliyor, butonlar parmakla rahat tıklanabiliyor mu?
- Yatay kaydırma gerektiren taşan öğeler var mı?
- Mobilde ekranı kapatan araya giren pencereler içeriğe erişimi engelliyor mu?
En pratik test, sayfayı gerçek bir telefonda açmak ve Chrome geliştirici araçlarındaki cihaz görünümüyle farklı ekran genişliklerinde denemektir. Lighthouse raporu da mobil kullanılabilirlik sorunlarını listeler.
Yapılandırılmış veri
Yapılandırılmış veri, sayfa içeriğini arama motorlarının makine tarafından okunabilir biçimde anlamasını sağlayan schema.org işaretlemesidir. Google'ın önerdiği format JSON-LD'dir. Doğru kullanıldığında ürün fiyatı, değerlendirme yıldızı, breadcrumb, etkinlik tarihi gibi zengin sonuç görünümlerine uygunluk kazandırır; bu görünümler garanti değildir ama mümkün hâle gelir.
Sık kullanılan türler: Organization ve LocalBusiness (kurum bilgisi), Product (ürün, fiyat, stok), Article (blog ve haber), BreadcrumbList (sayfa yolu). Denetimde dikkat edilecek nokta, işaretlemenin sayfada görünen içerikle birebir uyumlu olmasıdır; sayfada olmayan bir fiyatı ya da yorumu işaretlemek Google yönergelerine aykırıdır. Doğrulama için Google'ın Zengin Sonuçlar Testi'ni, site genelindeki durum için Search Console'daki ilgili geliştirme raporlarını kullanın.
hreflang: çok dilli ve çok bölgeli siteler
Siteniz birden fazla dilde ya da ülkede yayın yapıyorsa hreflang etiketleri, Google'a hangi kullanıcıya hangi sürümün gösterileceğini söyler. Türkçe sayfanın Türkiye'deki kullanıcıya, İngilizce sayfanın diğer kullanıcılara gösterilmesi gibi. Kurallar:
- Her dil sürümü hem kendisini hem diğer tüm sürümleri listelemeli (karşılıklılık). A sayfası B'yi gösteriyor ama B, A'yı göstermiyorsa etiket yok sayılabilir.
- Dil kodu ISO 639-1 (
tr,en), isteğe bağlı bölge kodu ISO 3166-1 Alpha-2 (tr-TR,en-GB) biçiminde olmalı.en-UKgibi hatalı kodlar geçersizdir. - Hiçbir dile uymayan kullanıcılar için
x-defaulttanımlanmalı. - hreflang'de gösterilen adresler kanonik ve 200 dönen sayfalar olmalı.
hreflang HTML başlığında, HTTP başlığında ya da site haritasında verilebilir; büyük sitelerde site haritası yöntemi bakımı kolaylaştırır. Hangi yöntem seçilirse seçilsin tek bir yerde tutarlı biçimde uygulanmalıdır.
JavaScript ve render
React, Vue veya benzeri çerçevelerle kurulan sitelerde içerik tarayıcıda JavaScript ile oluşturulur. Google JavaScript'i işleyebilir, ancak bu iş ek kaynak ve zaman gerektirir; render aşaması taramadan sonra gelir ve gecikebilir. Ayrıca script hata verirse, bir API yanıt vermezse ya da içerik ancak kullanıcı etkileşimiyle yükleniyorsa Google sayfayı boş görebilir.
Kontrol için şunları yapın:
- Tarayıcıda sayfanın kaynak kodunu (sağ tık, sayfa kaynağını görüntüle) açın. Ana metin, başlıklar ve bağlantılar ham HTML'de var mı?
- Search Console'daki URL denetimi aracıyla canlı testi çalıştırın ve Google'ın gördüğü işlenmiş HTML'i inceleyin.
- Başlık etiketi, meta açıklama, kanonik ve
noindexgibi kritik etiketlerin JavaScript ile sonradan değiştirilmediğinden emin olun. Ham HTML'denoindexvarsa Google sayfayı render etmeden dizin dışı bırakabilir.
Kalıcı çözüm, önemli sayfalarda sunucu tarafı oluşturma (SSR) ya da statik üretim kullanmaktır. Böylece içerik ilk HTML yanıtında hazır gelir ve hem arama motorları hem yapay zekâ tarayıcıları için okunabilir olur.
URL yapısı
İyi bir URL kısa, okunabilir ve kalıcıdır. /blog/teknik-seo gibi bir adres hem kullanıcıya hem arama motoruna sayfanın konusunu anlatır; /index.php?id=4821&cat=7 ise anlatmaz. Kurallar:
- Kelimeleri tire ile ayırın, alt çizgi ve boşluk kullanmayın.
- Küçük harf kullanın; büyük ve küçük harfli iki sürüm ayrı URL sayılabilir.
- Türkçe karakterleri sadeleştirin (ş yerine s, ğ yerine g) ya da tutarlı biçimde kodlayın; karışık kullanım kopya adres üretir.
- Gereksiz klasör derinliğinden, tarih ve ID'lerden kaçının.
- Sonda eğik çizgi kullanımında tek bir kural belirleyin ve diğer sürümü ona yönlendirin.
- Yayındaki URL'leri gerekmedikçe değiştirmeyin; değiştirirseniz 301 yönlendirme kurun.
Teknik SEO denetimi nasıl yürütülür?
Denetimi rastgele maddelere bakarak değil, etkinin büyüklüğüne göre sıralayarak yapın:
- Erişim ve dizin: robots.txt,
noindex, sunucu hataları ve Search Console sayfa raporu. Burada bir hata, sitenin tamamını etkileyebilir. - Kopya ve kanonik: HTTP/HTTPS, www, eğik çizgi ve parametre varyasyonlarının tek bir sürümde birleştiğini doğrulayın.
- Yönlendirme ve hatalar: Zincirler, döngüler, kırık iç bağlantılar ve trafik kaybettiren 404'ler.
- Performans: Core Web Vitals saha verisi, önce en çok trafik alan şablonlarda.
- Zenginleştirme: Yapılandırılmış veri, hreflang ve URL düzeni.
Her bulguyu etkilediği sayfa sayısı ve bu sayfaların trafiğiyle birlikte not edin. Yalnız teknik açıdan değil, iş etkisi açısından önceliklendirmek, düzeltme listesini geliştirici ekibe kabul ettirmeyi kolaylaştırır. Düzeltmeden sonra Search Console'da ilgili raporda doğrulama başlatın ve tıklama ile gösterim değişimini birkaç hafta izleyin. seoanalytics.com.tr gibi Search Console ve GA4 verisini tek panelde birleştiren bir araçla, düzeltme öncesi ve sonrası dönemleri sayfa bazında karşılaştırmak daha hızlı olur. Bulguları karar vericilere aktarırken SEO raporu hazırlama rehberindeki şablonu kullanabilirsiniz.
Teknik düzeltmeler tamamlandıktan sonra görünürlük artsa da tıklamalar aynı kalıyorsa, sorun artık altyapıda değil arama sonucu görünümündedir. Bu durumda başlık ve açıklama optimizasyonuna geçmek gerekir; ayrıntılar için CTR rehberine bakabilirsiniz.
Teknik SEO kontrol listesi
| Madde | Nasıl kontrol edilir | Öncelik |
|---|---|---|
| robots.txt önemli sayfaları engellemiyor | alanadi.com/robots.txt dosyasını açın, Disallow satırlarını inceleyin; Search Console'daki robots.txt raporuna bakın | Yüksek |
| Dizinde olması gereken sayfada noindex yok | Sayfa kaynağında robots meta etiketini ve HTTP yanıtında X-Robots-Tag başlığını kontrol edin | Yüksek |
| Sayfa dizine ekleme raporunda beklenmedik hariç tutma yok | Search Console sayfa raporunda eklenmeme nedenlerini tek tek inceleyin | Yüksek |
| Sunucu 5xx hatası vermiyor | Search Console tarama istatistiklerine ve sunucu loglarına bakın | Yüksek |
| HTTP ve www sürümleri tek adreste birleşiyor | Dört sürümü (http, https, www, www'siz) curl -I ile deneyin, hepsi tek adımda kanonik sürüme gitmeli | Yüksek |
| Kanonik etiketler doğru adresi gösteriyor | Örnek sayfalarda canonical değerini ve URL denetimi aracında Google'ın seçtiği kanoniği karşılaştırın | Yüksek |
| Önemli içerik ham HTML'de mevcut | Sayfa kaynağını görüntüleyin; URL denetimi canlı testinde işlenmiş HTML'e bakın | Yüksek |
| XML site haritası temiz ve gönderilmiş | Site haritasında yalnız 200 dönen kanonik URL'ler olduğunu doğrulayın; Search Console site haritası raporuna bakın | Orta |
| Yönlendirme zinciri ve döngüsü yok | Eski adresleri curl -I -L ile izleyin, tek adımda nihai adrese gitmeli | Orta |
| Trafik alan 404 sayfa yok | Search Console'da 404 listesini trafik ve backlink verisiyle eşleştirin, değerlileri 301 ile yönlendirin | Orta |
| Soft 404 yok | Search Console sayfa raporundaki soft 404 nedenini inceleyin; boş ürün ve arama sayfalarını kontrol edin | Orta |
| Kırık iç bağlantı yok | Site içi tarama yapın ya da önemli şablonlardaki linkleri elle kontrol edin | Orta |
| Core Web Vitals iyi aralıkta | Search Console Core Web Vitals raporu ve PageSpeed Insights saha verisi | Orta |
| Mobil sürüm masaüstüyle aynı içeriği taşıyor | Gerçek telefonda ve geliştirici araçlarındaki cihaz görünümünde karşılaştırın | Orta |
| HTTPS sertifikası geçerli, karışık içerik yok | Tarayıcı adres çubuğu ve konsol uyarıları; sertifika bitiş tarihini takvime ekleyin | Orta |
| Yapılandırılmış veri hatasız | Zengin Sonuçlar Testi ve Search Console geliştirme raporları | Düşük |
| hreflang karşılıklı ve geçerli kodlu | Her dil sürümünün diğerlerini listelediğini ve x-default bulunduğunu kontrol edin | Düşük (çok dilli sitede yüksek) |
| URL'ler kısa, küçük harfli ve tutarlı | Site haritasındaki adresleri gözden geçirin; parametreli ve büyük harfli varyasyonları arayın | Düşük |
| Yetim sayfa yok | Site haritasındaki URL'leri iç bağlantı alan URL'lerle karşılaştırın | Düşük |
Sık sorulan sorular
Teknik SEO ile on-page SEO arasındaki fark nedir?
On-page SEO sayfanın içeriğiyle ilgilenir: başlık, metin, anahtar kelime kullanımı, meta açıklama. Teknik SEO ise o içeriğin taranması, dizine eklenmesi ve hızlı sunulması için gereken altyapıyı kapsar. İkisi birbirini tamamlar; biri eksikse diğerinin etkisi sınırlı kalır.
Teknik SEO denetimi ne sıklıkla yapılmalı?
Kapsamlı denetim için birkaç ayda bir yeterlidir. Bunun yanında site taşıma, tema veya altyapı değişikliği, büyük içerik güncellemesi gibi her önemli değişiklikten sonra kısa bir kontrol yapın ve Search Console uyarılarını haftalık takip edin.
Küçük bir site için tarama bütçesi önemli mi?
Genellikle hayır. Birkaç yüz ya da birkaç bin sayfalık sitelerde Google tüm sayfaları rahatça tarar. Tarama bütçesi, parametreli URL'lerle çok sayıda varyasyon üreten büyük e-ticaret, ilan ve haber sitelerinde öncelikli konudur.
Teknik sorunları düzelttikten sonra sonuç ne zaman görülür?
Bu, Google'ın ilgili sayfaları yeniden tarama hızına bağlıdır. Sık taranan önemli sayfalarda değişiklik birkaç gün içinde yansıyabilir, az taranan sayfalarda haftalar sürebilir. Search Console'da doğrulama başlatmak ve URL denetimi aracıyla dizine ekleme istemek süreci hızlandırabilir.