Teknik SEO

Teknik SEO, aramanın mühendislik katmanıdır. İçerik “ne söylediğin” ise, teknik SEO Google’ın bunu bulup bulamadığı, bulduğunda ne kadar hızlı işleyebildiği ve doğru bağlama oturtup oturtamadığıdır. Başka bir deyişle iyi içerik, teknik altyapı izin verdiği ölçüde görünür olur. Sayfa çok yavaşsa, bot kritik bağlantıları göremiyorsa, yanlış canonical doğru URL’yi bastırıyorsa ya da içerik JavaScript’in arkasında geç oluşuyorsa, en iyi metin bile potansiyelinin altında kalır.

Benim yazılım geçmişim tam olarak burada fark yaratır. Teknik SEO’yu yalnızca başlık etiketi, meta açıklama, alt metin ya da sitemap kontrolü gibi yüzey kontrollerinden ibaret görmem. Bunlar elbette yapılır; ama asıl fark çoğu zaman daha derinde, render yollarında, tarama bütçesinde, log dosyalarında, sunucu yanıtlarında, frontend mimarisinde ve indexleme sinyallerinin birbirini nasıl etkilediğinde ortaya çıkar. Çoğu ajansın “teknik SEO” diye sunduğu şey, pratikte bir checklist taramasından ibarettir. Benim yaklaşımım ise sitenin Google tarafından gerçekten nasıl görüldüğünü, nasıl tarandığını, nasıl render edildiğini ve hangi teknik tavanlara çarptığını anlamaya dayanır.

Bu sayfa SEO hizmetimin teknik derinleşmesidir. Asıl mesele şu: bir sitenin sıralamasını çoğu zaman içerik kalitesi değil, görülmeyen teknik tavanlar kısıtlar. İçerik iyi olabilir, ürün güçlü olabilir, marka güvenilir olabilir; ama Googlebot yanlış yerlere zaman harcıyorsa, önemli sayfalar geç indexleniyorsa, sayfa deneyimi zayıfsa ya da bot sayfanın ana içeriğini render edemiyorsa büyüme kilitlenir. O tavanlar kaldırıldığında içerik nefes alır; aynı içerik daha hızlı keşfedilir, daha doğru anlaşılır ve daha tutarlı performans göstermeye başlar.

Core Web Vitals: ölçülen kullanıcı deneyimi

Core Web Vitals, “site hızlı mı?” sorusunu soyut bir his olmaktan çıkarıp ölçülebilir kullanıcı deneyimine dönüştürür. Google burada laboratuvar ortamında ideal koşullarda alınmış skorlarla yetinmez; gerçek kullanıcı verisine, yani CrUX verisine bakar. Bu önemli bir ayrımdır. Çünkü geliştirici bilgisayarında, hızlı bağlantıda ve temiz önbellekle iyi görünen bir sayfa; gerçek kullanıcıda, mobil ağda, eski cihazda ya da kalabalık bir script yığınıyla bambaşka davranabilir.

Google, gerçek kullanıcı verisiyle üç metriği ölçer:

• LCP (Largest Contentful Paint) — sayfadaki en büyük içeriğin görünme süresidir. Hedef < 2.5s. Kullanıcının “sayfa geldi” hissini en çok etkileyen metriklerden biridir. Tipik suçlular: optimize edilmemiş hero görseli, render-blocking CSS/JS, yavaş sunucu yanıtı yani TTFB, web font yüklenmesi ve gereğinden büyük medya dosyalarıdır. Örneğin ana sayfanın üst kısmında 3000 piksel genişliğinde, sıkıştırılmamış bir görsel kullanılıyorsa kullanıcı aslında metni okumaya hazır olsa bile LCP gecikir. Çözüm: kritik CSS’i inline’la, görseli modern formatta (AVIF/WebP) ve doğru boyutta sun, font’u preload et. Bunun yanında görselin gerçekten ilk ekranda gerekli olup olmadığı, CDN’den servis edilip edilmediği ve sunucu yanıtının gereksiz uygulama katmanlarından geçip geçmediği de kontrol edilmelidir.

• CLS (Cumulative Layout Shift) — sayfa yüklenirken düzenin ne kadar kaydığını ölçer. Hedef < 0.1. Kullanıcının bir butona basacakken butonun yer değiştirmesi, metin okurken reklam alanının araya girmesi ya da font geç geldiği için tüm satırların yeniden akması CLS problemidir. Suçlular: boyutu belirtilmemiş görsel/iframe, sonradan enjekte edilen reklam/banner, geç gelen font yani FOIT/FOUT davranışlarıdır. Çözüm: her medyaya width/height, alan rezervasyonu, font-display stratejisi. Örneğin ürün kartlarında görsel alanı baştan ayrılmazsa, görseller geldikçe kartlar aşağı iter ve kullanıcı deneyimi bozulur. Bu yalnızca estetik bir sorun değildir; etkileşimi, güven hissini ve arama performansını etkileyen teknik bir problemdir.

• INP (Interaction to Next Paint) — kullanıcının etkileşimine sayfanın ne kadar hızlı yanıt verdiğini ölçer ve FID’in yerini almıştır. Hedef < 200ms. Kullanıcı menüye tıkladığında, filtre seçtiğinde, sepete eklediğinde ya da form alanına yazdığında sayfanın kilitlenmesi genellikle ağır JavaScript’in ana iş parçacığını bloklamasından kaynaklanır. Suçlu: ana iş parçacığını bloklayan ağır JavaScript. Çözüm: JS’i azalt, böl, ertele; gereksiz hydration’ı kaldır. Özellikle modern frontend framework’leriyle yapılmış sitelerde, ekranda küçük bir metin göstermek için bile gereğinden fazla JavaScript yüklenebiliyor. Bu da hem kullanıcıyı hem botu yavaşlatıyor.

Ben bu sorunları yalnızca PageSpeed/Lighthouse’un sentetik skoruyla teşhis etmem. Lighthouse yararlıdır ama tek başına gerçek değildir. Laboratuvar yeşil olup saha kırmızı olabilir; yani test aracı iyi skor verirken gerçek kullanıcılar yavaşlık yaşıyor olabilir. Bu yüzden gerçek kullanıcı verisiyle bakarım. Hangi şablonlar sorunlu, problem mobilde mi masaüstünde mi yoğunlaşıyor, gecikme sunucudan mı frontend’den mi geliyor, metrik belirli sayfa tiplerinde mi bozuluyor — teknik SEO çalışmasının değeri bu ayrıştırmada ortaya çıkar.

Tarama bütçesi ve log analizi

Google’ın botu sitende sınırsız zaman harcamaz. Her site için fiilen bir kaynak kullanımı vardır: bot belirli URL’leri belirli sıklıkta tarar, bazılarını daha sık ziyaret eder, bazılarını aylarca görmezden gelebilir. Bu yüzden soru şudur: Googlebot zamanını para sayfalarına mı harcıyor, yoksa sonsuz filtre kombinasyonlarına, parametreli URL’lere, arama sonucu sayfalarına, gereksiz yönlendirme zincirlerine, 404’lere ve düşük değerli URL’lere mi dağıtıyor?

Bunu tahminle değil, sunucu log dosyalarından görürüm. Loglar Googlebot’un gerçekte neyi, ne zaman, hangi durum koduyla, ne sıklıkla taradığını gösterir. Search Console bir özet verir; log dosyaları ise ham gerçeği gösterir. Örneğin sitemap’te önemli kategori sayfaları varken botun zamanının büyük kısmını ?sort=price, ?color=blue, ?page=37 gibi parametreli URL’lerde harcadığını görebiliriz. Ya da botun eski URL’lerden yeni URL’lere, oradan da başka URL’ye giden yönlendirme zincirlerinde boğulduğunu fark ederiz.

Çoğu sitede tarama bütçesinin önemli kısmı çöp URL’lerde israf olur. Bu israf özellikle büyük sitelerde, e-ticaret yapılarda, filtreleme sistemi güçlü olan kataloglarda ve çok sayıda dil/versiyon barındıran projelerde büyür. Çözüm her zaman “robots.txt ile kapat” kadar basit değildir. Bazen robots, parametre yönetimi, canonical, noindex, sitemap temizliği, iç link mimarisi ve yönlendirme düzeni birlikte ele alınmalıdır. Amaç botu körleştirmek değil, doğru yere yönlendirmektir. Gereksiz alanları toparlamak, yeni ve güncellenen içeriğin daha hızlı indexlenmesini sağlar; çünkü Googlebot’un dikkati daha değerli URL’lere kayar.

Render: Google içeriğini gerçekten görüyor mu?

Modern sitelerde en sık atlanan sorunlardan biri render meselesidir. Bir sayfanın tarayıcıda sana doğru görünmesi, Google’ın onu aynı şekilde, aynı zamanda ve aynı güvenilirlikle gördüğü anlamına gelmez. Özellikle JavaScript ağırlıklı yapılarda kritik içerik, menü linkleri, ürün listeleri, yorumlar, fiyatlar ya da iç linkler client-side render sonrasında oluşuyorsa indexleme riski doğar.

İçerik üç şekilde oluşabilir:

• SSG / SSR (server’da render) — bot HTML’i hazır görür. En güvenli yol budur. Sayfanın ana içeriği, başlıkları, linkleri ve temel yapısı ilk HTML içinde gelir. Googlebot fazladan JavaScript çalıştırmak zorunda kalmadan neye baktığını anlar.
• CSR (tarayıcıda JavaScript ile) — bot önce boş iskelet görür, sonra ikinci dalgada JS’i çalıştırıp içeriği görmeye çalışır. Bu model gecikme + hata riski taşır. JavaScript dosyası geç yüklenirse, hata verirse, engellenirse ya da render kuyruğu gecikirse içerik geç anlaşılır veya hiç anlaşılmayabilir.

Google JavaScript çalıştırır, ama bu garanti değildir ve maliyetlidir. “Google artık JS görüyor” cümlesi teknik olarak eksiktir. Evet, görebilir; ama her sayfada, her zaman, hızlı ve eksiksiz göreceği varsayımı risklidir. Kritik içerik ve linkler client-side’a bağlıysa indexlenme sorunları doğar. Örneğin kategori sayfasındaki ürün linkleri ilk HTML’de yoksa, bot site mimarisini eksik algılayabilir. Blog yazısının ana metni JS sonrası geliyorsa, Google önce boş veya zayıf bir sayfa görebilir. Filtre sayfaları client-side URL değiştiriyor ama gerçek HTML üretmiyorsa, tarama ve indexleme sinyalleri karışabilir.

Denetimde “Googlebot bu sayfada ne görüyor”u, yani render sonrası HTML’i kontrol ederim. İlk HTML ile JavaScript çalıştıktan sonraki HTML arasındaki farklara bakarım. Kritik başlıklar, içerik blokları, canonical, meta robots, hreflang, breadcrumb, ürün verisi ve iç linkler doğru yerde mi; yoksa JavaScript’in insafına mı bırakılmış? Gerekirse içeriği sunucu tarafında üretilen bir yapıya (SSR/SSG) taşırım veya hibrit bir kurgu öneririm. Teknik SEO’da güzel görünen arayüz değil, arama motorunun güvenle okuyabildiği yapı önemlidir.

Indexleme kontrolü ve yinelenen içerik

Indexleme kontrolü, Google’a “neyi tarayabilirsin, neyi indexleyebilirsin, hangi URL asıl sürümdür?” sorularının net cevabını vermektir. Bu sinyaller birbirine karıştığında Google kendi kararını verir; o karar da her zaman senin istediğin karar olmaz.

• robots.txt / meta robots / X-Robots-Tag — neyin taranacağı ve indexleneceği. Robots.txt taramayı kontrol eder; meta robots ve X-Robots-Tag indexleme davranışını etkiler. Yanlış yerde kullanılan noindex, değerli bir sayfayı arama sonuçlarından çıkarabilir. Yanlış robots engeli ise Google’ın sayfayı görmesini veya sayfadaki sinyalleri işlemesini engelleyebilir.
• Canonical — aynı/benzer içeriğin hangi sürümünün asıl olduğunu gösterir. Yanlış canonical, doğru sayfanın gizlenmesine yol açar. Örneğin bir ürün sayfası yanlışlıkla kategoriye canonical veriyorsa, ürün sayfasının indexlenmesi zayıflayabilir. Ya da tüm sayfaların ana sayfaya canonical verdiği hatalı kurulumlarda site kendi görünürlüğünü sabote eder.
• Yinelenen içerik — parametreler, http/https, www/non-www, trailing slash, sayfalama gibi farklı URL sürümlerinde aynı veya çok benzer içeriğin oluşmasıdır. Tek doğru sürümde toplanmalı. Aksi halde otorite bölünür, bot gereksiz URL’lere gider ve Google hangi sayfayı göstereceğine kendisi karar verir.
• Öksüz sayfalar — hiçbir iç linki olmayan sayfalar bot tarafından zor bulunur. Sitemap’te yer alsalar bile site mimarisi içinde desteklenmeyen sayfalar zayıf sinyal verir. Bir sayfanın önemli olduğunu söylemenin en pratik yollarından biri, ona bağlamlı iç linkler vermektir.

Bu katmanda amaç, hata temizlemenin ötesinde karar mekanizmasını sadeleştirmektir. Google’a çelişkili sinyal vermeyen, tekil, net ve tutarlı bir URL yapısı kurulduğunda hem tarama hem indexleme daha öngörülebilir hale gelir.

Yapısal veri (schema.org)

Yapısal veri, arama motoruna sayfanın ne olduğunu makine diliyle söyler: makale mi, ürün mü, SSS mı, yerel işletme mi, hizmet sayfası mı, kişi profili mi? İnsan metni okuyarak bağlamı anlayabilir; arama motoru ise bu bağlamı daha güvenli işlemek için yapılandırılmış sinyallerden yararlanır.

Doğru schema, genellikle JSON-LD formatında uygulanır. Burada önemli olan sadece schema eklemek değil, sayfadaki gerçek içerikle uyumlu ve doğrulanabilir schema eklemektir. Sayfada olmayan yorum puanını işaretlemek, olmayan fiyat bilgisini ürün verisi gibi sunmak ya da her sayfaya alakasız FAQ eklemek uzun vadede iyi bir strateji değildir. Teknik olarak geçerli, içerikle uyumlu ve sayfanın amacını destekleyen yapı tercih edilmelidir.

Doğru schema (JSON-LD) hem zengin sonuçların — yıldız, fiyat, SSS açılır gibi — hem de yapay zeka aramalarının seni alıntılamasının önünü açar. Çünkü arama sistemleri yalnızca kelime eşleşmesine değil, varlıkları, ilişkileri ve sayfanın tipini anlamaya da çalışır. Bir hizmet sitesinde Person, ProfessionalService, Service, BreadcrumbList ve FAQPage gibi şemalar, sayfanın ne olduğunu makineye net anlatmak için birlikte kullanılır.

Site mimarisi ve iç linkleme

Düz, mantıklı bir hiyerarşi hem kullanıcıya hem bota yardım eder. Kullanıcı aradığını daha hızlı bulur; bot ise hangi sayfaların önemli olduğunu daha net anlar. Önemli sayfalar ana sayfaya yakın, yani az tıkla erişilebilir olmalı. Derinde gömülen, yalnızca birkaç filtre kombinasyonundan ulaşılabilen veya hiçbir menü/bağlam içinde görünmeyen sayfalar zayıf sinyal alır.

İlgili sayfalar birbirine link vermeli; hub & spoke modeli burada çok işe yarar. Hub sayfa ana konuyu toplar, spoke sayfalar alt konuları derinleştirir. Böylece hem kullanıcı yolculuğu doğal akar hem de Google konu kümelerini daha iyi anlar. İç linkleme, otoriteyi sitenin içinde akıtır ve botu doğru sayfalara yönlendirir. Örneğin teknik SEO sayfasından e-ticaret SEO’ya, SEO uzmanlığı sayfasına veya ilgili alt hizmetlere verilen bağlamlı linkler yalnızca kullanıcı için değil, arama motoru için de anlamlıdır.

İç linkleme yapılırken “her sayfadan her sayfaya link verelim” mantığıyla hareket edilmez. Linkin bağlamı, çapa metni, sayfadaki konumu ve kullanıcının o anda gerçekten ihtiyaç duyabileceği bir sonraki adım önemlidir. Teknik SEO’da iyi mimari, menü yapısı, breadcrumb, footer linkleri, içerik içi bağlantılar ve sitemap birlikte düşünülür.

Çok dillilik: hreflang

Çok dilli projelerde teknik SEO daha hassas hale gelir. Birden fazla dilde yayın yapan sitelerde hreflang etiketleri, Google’a hangi sayfanın hangi dil/bölge için olduğunu söyler. Türkçe sayfanın Türkçe kullanıcılara, İngilizce sayfanın İngilizce kullanıcılara gösterilmesi beklenir; ama bu kendiliğinden her zaman doğru çalışmaz.

Yanlış kurulmuş hreflang, yanlış dildeki sayfanın sıralanmasına veya iki versiyonun birbirini yemesine yol açar. Örneğin Türkçe sayfa İngilizce sayfaya doğru karşılık vermiyorsa, Google bu ilişkiyi güvenilir bulmayabilir. Ya da tüm diller kendini canonical gösterirken hreflang ilişkileri eksikse, sinyaller çakışabilir. Doğru kurulum: karşılıklı yani reciprocal etiketler + x-default. Her dil versiyonu diğer ilgili dil versiyonlarını göstermeli, ilişkiler tek taraflı kalmamalıdır.

Hreflang yalnızca etiket eklemek değildir; URL yapısı, canonical, sitemap, dil seçici, içerik eşleşmesi ve sayfaların gerçekten karşılıklı alternatif olup olmadığı birlikte kontrol edilmelidir. Bir dildeki sayfanın diğer dilde birebir karşılığı yoksa, hreflang eşleştirmesi dikkatli yapılmalıdır.

İzleme: düzeltmeyi doğrula

Teknik SEO “yap ve unut” değildir. Bir sorunu düzelttiğini düşünmek yetmez; düzeltmenin Google tarafından görülüp görülmediğini, kullanıcı verisine yansıyıp yansımadığını ve indexleme davranışını değiştirip değiştirmediğini doğrulamak gerekir.

Bu yüzden Search Console verilerini (Crawl Stats, Index Coverage, Core Web Vitals raporu) ve gerçek kullanıcı verisini birlikte takip ederim. Log tarafında Googlebot’un davranışının değişip değişmediğine, gereksiz URL taramasının azalıp azalmadığına ve önemli sayfaların daha sık ziyaret edilip edilmediğine bakarım. Index Coverage tarafında hariç bırakılan sayfaların nedeni değişmiş mi, Core Web Vitals tarafında laboratuvar değil saha verisi iyileşmiş mi; bunlar teknik çalışmanın sahadaki karşılığıdır.

Teknik SEO’nun değeri, raporda “şu kadar hata bulundu” demek değildir. Değer, hatanın neden önemli olduğunu anlamak, doğru önceliği vermek, çözümü uygulamak ve etkisini doğrulamaktır. Bazı hatalar görünürde büyük ama etkide küçüktür; bazıları ise sessizce sitenin büyümesini kilitler. Benim işim bu ayrımı yapmak ve teknik müdahaleyi sıralama potansiyeline bağlamaktır.

---

Teknik temel sağlamsa, içerik ve otorite çalışması çok daha hızlı sonuç verir. Çünkü içerik daha kolay keşfedilir, sayfalar daha doğru indexlenir, otorite daha verimli akar ve kullanıcı deneyimi arama motorunun ölçebildiği şekilde iyileşir. E-ticaret sitesindeysen, kendi teknik zorlukları için ayrıca şuna bakabilirsin: e-ticaret SEO. Sitenin teknik tavanlara takıldığını, Google’ın içeriğini eksik gördüğünü ya da büyümenin görünmeyen altyapı sorunlarıyla yavaşladığını düşünüyorsan bana yaz.