Teknik SEO: Google sitenizi nasıl okur ve nerede takılır

Teknik SEO, içerik ne kadar iyi olursa olsun Google'ın o içeriğe ulaşıp ulaşamadığını, ne olduğunu anlayıp anlamadığını ve sonuçlarda doğru sayfayı gösterip göstermediğini belirleyen katmandır. Yazılımla başlayıp SEO'ya geçtiğim için bu katmana hep mühendis gözüyle baktım. Pratikte gördüğüm şey şu: teknik sorunların çoğu karmaşık değil. Yanlış kalmış bir noindex, kendine değil başka sayfaya bakan bir canonical ya da robots.txt'e eklenmiş tek bir satır, bir sitenin aylarca görünmemesine yetiyor.

Bu yazıda teknik SEO'yu Google'ın çalışma sırasına göre ele alıyorum: önce tarama, sonra dizine ekleme, en sonda sonuçlarda sunum. Sıra önemli, çünkü bir aşamada tıkanan sayfa sonrakine hiç geçemiyor. Dayandığım olguların hepsi Google'ın kendi dokümanlarından geliyor ve sayfanın sonunda listeli. Google'ın yazmadığı bir şeyi kesin bilgi gibi sunmayacağım.

Teknik SEO neyi çözer, neyi çözmez

Teknik SEO sıralama üretmez, sıralamanın önündeki engelleri kaldırır. Arama yapan kişinin ihtiyacını karşılamayan bir sayfa, kusursuz bir altyapıda da sıralanmaz. Tersi de geçerli: harika bir yazı, taranamayan bir sitede kimsenin eline geçmez. Bu yüzden teknik işi içerikten ayırıp "bir kere yaparım biter" diye düşünmek de, tüm enerjiyi ona verip içeriği ihmal etmek de yanlış.

Google'ın kendi ifadesiyle hiçbir sayfa için tarama, dizine ekleme ya da sunma garantisi yok, Search Essentials'a uyan sayfalar için bile. Yani teknik SEO bir garanti vermez, olasılığı artırır ve nedeni bulunabilir hale getirir. Sorun çıktığında "neden dizinde yok" sorusunun cevabı elinizde bir rapor olarak bulunmalı, tahmin olarak değil.

Google bir siteyi nasıl okur

Google'ın tarif ettiği üç aşama var.

1. Tarama: Googlebot bilinen sayfalardaki bağlantılardan ve gönderilen sitemap'lerden yeni adresleri keşfeder, sayfaları indirir. Hangi sitenin ne sıklıkta ve kaç sayfa taranacağına kendisi karar verir. Sunucu zorlanıyor gibi görünürse, örneğin 500 hataları dönüyorsa, hızını düşürür.
2. Dizine ekleme: İndirilen sayfanın metni, başlık ve alt etiket gibi öğeleri, görselleri ve videoları çözümlenir. Birbirinin kopyası ya da çok benzeri sayfalar bir kümede toplanır ve kümeden bir temsilci, yani canonical sayfa seçilir. Sinyaller bu sayfa için saklanır ve her şey dizine yazılır.
3. Sunum: Biri arama yaptığında Google dizine bakar, alaka ve kalite açısından en uygun sayfaları sıralar. Konum, dil ve cihaz gibi bağlam sonucu etkiler.

Bu üç aşama, bir sorunun hangi katmanda olduğunu aramak için de iyi bir harita. Sayfa hiç görünmüyorsa önce taranıp taranmadığına, taranıyorsa dizine eklenip eklenmediğine, eklenmişse neden o sorguda gösterilmediğine bakarsınız. Çoğu insan üçüncü soruyla başlıyor, yani "neden birinci sayfada değilim" diyor, oysa ilk iki aşama temiz değilse o soru anlamsız.

Tarama katmanı

robots.txt ne yapar, ne yapmaz

robots.txt, tarayıcılara hangi adreslere girebileceklerini söyler ve temel amacı sitenizi gereksiz isteklerle yormalarını önlemektir. Google'ın dokümanındaki vurgu net: robots.txt bir sayfayı Google'dan uzak tutmanın yolu değildir. Engellediğiniz bir adresi başka siteler link veriyorsa Google yine dizine ekleyebilir. Sonuçlarda açıklamasız, yalnızca adres olarak görünür.

Bir sayfanın aramada çıkmasını istemiyorsanız noindex meta etiketi ya da X-Robots-Tag başlığı kullanırsınız, ya da sayfayı parola ile korursunuz. Burada sık düşülen bir tuzak var: noindex etiketini Google'ın görebilmesi için sayfanın taranabilir olması gerekir. Hem robots.txt ile engelleyip hem noindex koyarsanız Google etiketi hiç okuyamaz. Bu iki aracı karıştırmak, gördüğüm en yaygın hatalardan biri.

Teknik ayrıntılar da küçük şeyler değil. Dosya sitenin kök dizininde olmalı ve her host, protokol ve port için ayrı geçerli. Google dosyanın ilk 500 KiB'ını okuyor, fazlasını yok sayıyor. Dosyaya erişirken 4xx (429 hariç) dönerse Google bunu "robots.txt yok" diye yorumlayıp kısıtlama uygulamıyor. 5xx dönerse tarama bir süre duruyor. Yani yanlışlıkla kapanmış bir sunucu ya da yanlış yönlendirme, robots.txt üzerinden tüm siteyi etkileyebilir.

Başka bir uyarı: CSS ve JavaScript dosyalarını robots.txt ile engellemek sayfayı Google için anlaşılmaz hale getirebilir. Kaynak dosyaları "taranmasın" diye engelleyen eski satırlar, sayfanın Google tarafından doğru işlenmesini zorlaştırabiliyor.

Sitemap

Sitemap, Google'a "şu adresler önemli" demenin düzenli yoludur ama dizine eklenmeyi garantilemez. Google XML, RSS/Atom ve düz metin biçimlerini destekliyor. Bir dosya en fazla 50 MB (sıkıştırılmamış) ya da 50.000 adres olabilir, fazlası için sitemap dizin dosyası kullanılır. Adresler mutlak olmalı ve istediğiniz canonical adresleri içermeli.

İki ayrıntı sık yanlış biliniyor. İlki <priority> ve <changefreq>: Google ikisini de yok sayıyor, yani ikisini özenle doldurmak boşuna emek. İkincisi <lastmod>: Google bu alanı yalnızca tutarlı ve doğrulanabilir biçimde doğruysa kullanıyor. Telif yılı güncellemesi gibi önemsiz bir değişiklikte tarihi yenilemek, alanın güvenilirliğini düşürür. Ana içerik, yapılandırılmış veri ya da bağlantılar değiştiğinde yenileyin.

Sitemap'in her site için şart olmadığını da Google söylüyor. Yaklaşık 500 sayfa ve altındaki, birbirine iyi bağlanmış siteler çoğu zaman sitemap olmadan da keşfedilir. Yine de bedeli düşük olduğu için koymanızı öneririm.

İç bağlantılar ve tarama bütçesi

Google yeni sayfaları büyük ölçüde bağlantılardan bulur. Google, önemli her sayfanın sitenizdeki en az bir başka sayfadan bağlanmasını öneriyor. Bağlantıların <a href="..."> biçiminde olması gerekiyor. Tıklanınca JavaScript çalıştıran ama href taşımayan öğeler Google tarafından bağlantı sayılmayabilir.

Tarama bütçesi konusu çoğu kişide abartılıyor. Google'ın tarif ettiği eşikler kabaca şunlar: haftalık değişen bir milyon ve üzeri benzersiz sayfa, günlük değişen 10.000 ve üzeri sayfa, ya da Search Console'da çok sayıda adresin "Keşfedildi, şu anda dizine eklenmedi" durumunda görünmesi. Bunların altındaki bir sitede sorun genellikle bütçe değil, sayfanın kalitesi ya da keşfedilebilirliğidir. Bütçenin gerçekten sorun olduğu sitelerde de Google'ın önerisi basit: kopya sayfaları birleştirmek, değersiz adresleri robots.txt ile kapatmak (bunun için noindex işe yaramaz, çünkü Google o sayfaları yine istiyor), kalıcı silinen sayfalar için 404 ya da 410 dönmek, uzun yönlendirme zincirlerinden kaçınmak ve sunucuyu hızlı tutmak.

Filtre ve sıralama parametreleriyle sonsuz adres üreten e-ticaret sitelerinde bu konu özellikle önem kazanır. Aynı mantıkla şablonla binlerce sayfa üreten sitelerde de. Bu tuzağı programmatic SEO yazısında ayrıca ele aldım.

Dizine ekleme katmanı

Canonical ve yinelenen içerik

Aynı içeriğe birden çok adresten ulaşılabiliyorsa Google bunları kümeler ve birini seçer. Sizin rel="canonical" ile belirttiğiniz adres bir ipucu, emir değil. Google yönlendirmeleri, sitemap'teki varlığı, HTTPS kullanımını ve içeriğin ne kadar eksiksiz olduğunu da hesaba katıyor. Dokümanın dediği gibi tercihinizi belirtiyorsunuz, karar Google'da.

Çoğu sitede kopya içerik kötü niyetten değil, yapıdan doğuyor: http ve https sürümleri, www ve çıplak alan adı, sonunda eğik çizgi olan ve olmayan adresler, izleme parametreleri, sıralama ve filtre adresleri, yanlışlıkla açık kalmış test siteleri. Google yinelenen içeriğin kendi başına bir spam ihlali olmadığını söylüyor. Sorun, hem kullanıcı için hem performans takibi için karışıklık yaratması.

Pratikte şunu öneriyorum: her sayfa kendini gösteren bir canonical taşısın (mutlak adresle), site tek bir ana adrese yönlensin (301), sayfalama yapılan listelerde her sayfa kendi canonical'ını taşısın ve ilk sayfaya işaret etmesin. Sayfalamada rel="next" ve rel="prev" etiketlerini Google kullanmıyor, bu etiketler için zaman harcamayın.

HTTP durum kodları

Sunucunun söylediği şey, sayfanın görünüşünden daha belirleyici. Google'ın dokümanındaki özet şöyle:

• 200 gibi 2xx kodları: içerik işlenir, dizine eklenme garantisi yok.
• 301 ve 308: hedefin işlenmesi için güçlü sinyal. 302, 303 ve 307 daha zayıf sinyal.
• 404, 410 ve diğer 4xx kodları: içerik yok sayılır, eskiden dizinde olan adres zamanla düşer. 401 ya da 403 ile tarama hızını sınırlamaya çalışmak işe yaramaz.
• 429 ve 5xx: sunucu zorlanıyor sayılır, tarama yavaşlar. Hata sürerse dizindeki adresler de düşer.

Googlebot yönlendirmeleri 10 adıma kadar izliyor ama uzun zincirler tarama verimini düşürür ve bazı diğer istemciler daha az adım izler.

"Soft 404" ayrı bir sorun. Sayfa "bulunamadı" ya da boş bir içerik gösteriyor ama sunucu 200 dönüyor. Tek sayfa uygulamalarında bu çok yaygın, çünkü istemci tarafı yönlendirme gerçek bir 404 kodu üretemiyor. Google iki çıkış yolu veriyor: JavaScript ile gerçekten 404 dönen bir adrese yönlendirmek, ya da hata ekranına noindex etiketi eklemek.

Search Console'daki durumlar

Sayfa dizine ekleme raporu, teknik SEO'nun teşhis ekranı. Raporda görülen birkaç durumu doğru okumak çok zaman kazandırıyor:

"Tarandı, şu anda dizine eklenmedi" durumunu çok kişi teknik hata sanıyor. Google bunu hata olarak sınıflamıyor. Çoğu zaman cevap teknikte değil, sayfanın başka bir sayfada zaten karşılanan bir ihtiyaca cevap vermesinde.

JavaScript ve işleme

Google JavaScript'i işleyebilir, ama bu işlem taramadan ayrı bir kuyrukta yapılır. HTTP 200 dönen sayfalar, bir robots meta etiketi izin vermemedikçe, işleme kuyruğuna girer ve Google'ın dizine ekleyeceği şey işlenmiş HTML olur. Yani sayfa JavaScript çalıştıktan sonra ortaya çıkan metni içeriyorsa, o metin dizine girebilir. Girmesi için kaynakların robots.txt ile engellenmemiş olması gerekir.

Pratik çıkarımlar:

• Bağlantılar için <a href> kullanın. İstemci tarafı yönlendirmede #/sayfa biçimi yerine History API ile gerçek adresler üretin, çünkü fragment adreslerini Googlebot çözemeyebilir.
• Canonical'ı JavaScript ile eklemek mümkün ama ilk HTML'deki değerle uyumlu olmalı ve tek bir etiket bulunmalı.
• noindex etiketini JavaScript ile kaldırmaya güvenmeyin. noindex taşıyan sayfanın işlenmesi atlanabilir.
• Sunucu tarafı ya da ön işlemeli çıktı hâlâ tavsiye ediliyor, çünkü hem kullanıcıyı hem de JavaScript çalıştırmayan botları hızlandırıyor.

"Dinamik işleme" yani botlara ayrı, kullanıcıya ayrı sunum, Google'ın dokümanında artık geçici bir çözüm olarak anılıyor ve uzun vadeli öneri değil. Benzer içerik sunulduğu sürece cloaking sayılmıyor ama tamamen farklı içerik sunmak sayılabilir. Bu sınırı cloaking yazısında ayrıntılı anlattım.

Mobil ve sayfa deneyimi

Google mobil sürümü dizine ekliyor ve sıralıyor. Sitenizin mobilde masaüstünden eksik içerik göstermesi, yani birincil içeriğin mobilde daha az olması, doğrudan dizindeki içeriği daraltır. Duyarlı tasarım Google'ın önerdiği yapı. Etkileşim (tıklama, kaydırma, yazma) gerektiren yerlerde birincil içeriği geç yüklemeyin, çünkü Googlebot bu etkileşimleri yapmıyor.

Core Web Vitals için Google'ın yayımladığı iyi eşikler: En Büyük İçerik Boyama (LCP) 2,5 saniyenin altı, Sonraki Boyamaya Etkileşim (INP) 200 milisaniyenin altı, Kümülatif Düzen Kayması (CLS) 0,1'in altı. Google bu metrikleri gerçek kullanıcı deneyimini ölçen bir takım olarak sunuyor ve iyi puanları öneriyor. Ama tek başına sıralamayı belirlediklerini söylemiyor. Benim sahadaki yorumum şu: Core Web Vitals'ı bir rekabet avantajı değil, bir zemin olarak görmek lazım. Kırmızı bölgedeyseniz düzeltin, yeşildeyseniz içerik ve bağlantılara dönün.

Başlık, yapılandırılmış veri ve görünüm

Google başlık bağlantılarını otomatik üretiyor ve <title> etiketinde sorun görürse, örneğin boş, eski, yanıltıcı ya da her sayfada aynı kalıp ise, başlığı kendisi yeniden yazabiliyor. Başlığın uzunluğu için resmî bir karakter sınırı yok, kırpma cihaz genişliğine göre oluyor. Bu yüzden en önemli sözcükleri başa koymak ve her sayfa için benzersiz, içeriği anlatan bir başlık yazmak işe yarar.

Yapılandırılmış veri için Google JSON-LD'yi öneriyor, Microdata ve RDFa'yı da kabul ediyor. Kural basit: işaretlediğiniz bilgi sayfada görünür olmalı. Görünmeyen bilgiyi, doğru olsa bile, işaretlemek kurallara aykırı. Zengin sonuç almak için gerekli alanların eksiksiz ve doğru olması gerekiyor, eksik çok alan eklemek değil. Doğrulama için Rich Results Test'i kullanın. Ayrıca yapay zeka özellikleri için özel bir şema gerekmediğini Google açıkça söylüyor, bunu yapay zeka aramalarında görünmek yazısında ele aldım.

Çok dilli ve çok bölgeli siteler

hreflang Google'a hangi sayfaların aynı içeriğin dil ya da bölge sürümü olduğunu söyler. Üç yerden verilebilir: HTML <link> etiketleri, HTTP başlıkları ya da sitemap. Biri yeterli. Kurallar sıkı: her sürüm kendisini ve diğer tüm sürümleri listelemeli, sürümler birbirine karşılıklı bağlanmalı (karşılığı olmayan işaret yok sayılır), adresler mutlak olmalı, kodlar ISO 639-1 dil kodu ve isteğe bağlı bölge kodundan oluşmalı ve eşleşme bulunamayan kullanıcılar için x-default tanımlanabilir.

Google bir sayfanın dilini hreflang'a ya da lang özniteliğine bakarak değil, algoritmik olarak belirliyor. Bu yüzden hreflang, dil tespiti için değil, sürümleri birbirine bağlamak için. Bu sitenin kendisi de Türkçe ve İngilizce sürümleri bu şekilde bağlıyor.

Yapay zeka tarayıcıları ve llms.txt

Son iki yılda teknik SEO konuşmalarına yeni bir başlık girdi: yapay zeka sistemlerinin siteyi nasıl okuduğu. Burada ayırmanız gereken iki şey var. Google'ın AI Overviews ve AI Mode özellikleri normal Google dizinini kullanıyor. Google bunlar için ek teknik şart olmadığını, yani sayfanın dizine eklenmiş ve snippet ile gösterilebilir olmasının yeterli olduğunu yazıyor. Yeni bir dosya, özel işaretleme ya da özel şema gerekmiyor.

ChatGPT ve Perplexity gibi sistemler ise kendi tarayıcılarını kullanıyor ve robots.txt'te ayrı ayrı yönetiliyor. OpenAI, arama için OAI-SearchBot, model eğitimi için GPTBot kullandığını ve ikisinin bağımsız ayarlandığını belirtiyor. Perplexity de PerplexityBot'un arama sonuçlarında göstermek için çalıştığını, temel model eğitimi için kullanılmadığını yazıyor. Bu ayrımı robots.txt'e doğru yansıtmak teknik SEO'nun yeni bir kalemi. Ayrıntıları yapay zeka aramalarında görünmek yazısında topladım.

llms.txt ise bu tartışmanın en çok yanlış anlaşılan parçası. Bir site haritası değil, bir erişim kontrolü de değil. Google, Search için bu dosyayı kullanmadığını açıkça söylüyor. Başka sistemlerin okuyabileceği düşük maliyetli bir keşif dosyası olarak değerlendirmek daha doğru.

URL yapısı ve HTTPS

Adres yapısında altın kural yok ama Google'ın tarama ve kopya yönetimi dokümanlarından çıkan birkaç tutarlı ilke var. Aynı sayfa tek bir adresten erişilebilir olsun. Parametre kullanıyorsanız ayırıcı olarak standart & kullanın, çünkü virgül ve noktalı virgül çoğu zaman ayırıcı olarak tanınmıyor. Filtre kombinasyonunun sonucu yoksa 404 dönün, genel bir hata sayfasına yönlendirmeyin. Fragment (#) sonrasını Google genelde yok sayar, bu yüzden sayfa numarası ya da içerik ayrımı için fragment kullanmayın.

HTTPS konusunda yapılacak şey kısa: tüm site HTTPS olsun, HTTP adresler 301 ile HTTPS'e gitsin ve sitemap ile canonical'lar HTTPS adreslerini göstersin. Google canonical seçerken protokolü de hesaba katıyor, yani HTTP'de kalan tek bir sayfa bile sinyalleri bölebilir.

Log dosyaları ve ölçüm

Search Console Google'ın size gösterdiği tarafı verir. Sunucu logları ise Googlebot'un gerçekte ne istediğini gösterir. Şu soruların cevabı loglarda: Googlebot en çok hangi bölümleri tarıyor, 404 ve 5xx kaç istek aldı, parametreli adreslere ne kadar zaman harcıyor. Günlük kayıtlarda "Googlebot" yazan her isteğe güvenmeyin. Kullanıcı aracısı taklit edilebiliyor. Google, gerçek Googlebot'u doğrulamak için ters DNS sorgusu ya da yayımladığı IP aralıklarıyla eşleştirmeyi öneriyor.

Teknik SEO'nun yanında bakılması gerekenler

Teknik temel, tek başına sonuç getirmez. Gördüğüm üç komşu konu özellikle teknik kararlarla iç içe.

Birincisi bağlantı profili. Altyapı tamam olsa bile site hakkında dışarıdan sinyal yoksa ilerlemek zorlaşır, ama bu sinyali satın alarak üretmeye çalışmak başlı başına bir risk. Konuyu backlink satın almak yazısında Google'ın spam politikasına göre ele aldım.

İkincisi reklam tarafı. Google Ads hedef sayfaları da taranabilir ve çalışır olmalı. Reklam politikasının hedef sayfa gereklilikleri, hata dönen, taranamayan ya da yetersiz içerikli sayfaları ret nedeni sayıyor. Ret ve askıya alma süreçlerini reklam reddedildi ve hesap askıya alındı yazılarında ayrı ayrı anlattım.

Üçüncüsü ölçüm ve süreç. Arama trafiğinden gelen talebin sonunda nereye düştüğünü görmeyen bir teknik SEO çalışması eksik kalıyor. Talepleri toplayan yapının nasıl kurulacağını özel CRM yazılımı yazısında anlattım. Denetim ve raporlama gibi tekrar eden işleri bir iş akışına bağlamak isteyenler için LangGraph ile yapay zeka ajanı yazısı, böyle bir sistemin nasıl tasarlanacağını gösteriyor. Yaptığım işlere işler sayfasından bakabilirsiniz, sorunuz varsa iletişim sayfasından yazabilirsiniz.

Denetim sırası

Sıra önemli olduğu için bir siteyi şu sırayla denetlemeyi öneriyorum. Her adım bir önceki temiz değilse anlamsız.

1. Site tek bir ana adrese (HTTPS, tek www tercihi) 301 ile yönleniyor mu?
2. robots.txt 200 dönüyor mu ve önemli bir bölümü yanlışlıkla engelliyor mu?
3. Önemli sayfalar noindex taşıyor mu, hem HTML'de hem başlıkta?
4. Sitemap yalnızca canonical, 200 dönen adresleri içeriyor mu ve Search Console'a gönderilmiş mi?
5. Her önemli sayfaya en az bir iç bağlantı var mı ve bağlantılar <a href> mı?
6. Sayfa dizine ekleme raporunda "robots.txt tarafından engellendi", "Soft 404" ve "Keşfedildi, dizine eklenmedi" durumlarının nedenleri biliniyor mu?
7. JavaScript ile oluşan içerik, URL Denetleme aracında işlenmiş HTML'de görünüyor mu?
8. Mobil sürüm masaüstüyle aynı birincil içeriği taşıyor mu?
9. LCP, INP ve CLS gerçek kullanıcı verisinde iyi eşiklerde mi?
10. Başlıklar benzersiz mi, yapılandırılmış veri görünür içerikle uyumlu mu?

Tek bir şey yapacaksanız ilk altısını yapın. Sitelerin büyük çoğunluğunda sorun orada çıkıyor ve düzeltmeleri aynı gün içinde bitebiliyor.