TechnoRadical notları · Makale
Arama motoru bir sayfayı nasıl buluyor ve indeksliyor
Arama motoru bir sayfayı keşif, tarama, render, indeksleme ve sunum aşamalarıyla bulur; teşhisi log satırı ve Search Console ile gösteriyoruz.
Arama motoru bir sayfayı keşif, tarama, render, indeksleme ve sunum olmak üzere beş ayrı aşamadan geçirerek bulur ve indeksler. Bu beş aşamanın her biri kendi mekanizmasını ve kendi başarısızlık noktasını taşır. Bir sayfa keşfedilmiş olsa bile tarama sırasına hemen girmeyebilir; taranmış olsa bile indekse girmeyebilir. Google, bu aşamaların hiçbirinde bir sitenin dizine ekleneceğine dair garanti vermez. Her aşama resmi Google kaynağına bağlıdır; tek bir URL’nin hangi aşamada takıldığı gerçek bir sunucu log satırı ile Search Console URL İnceleme ekranı üzerinden teşhis edilir.
Google bir sayfanın varlığını ilk nasıl öğrenir
Google bir URL’yi üç yoldan öğrenir: önceden taranmış bir sayfadaki linkten, bir sitemap dosyasında bildirilmesinden veya Search Console üzerinden doğrudan gönderilmesinden. Google Search Central’ın aramanın nasıl çalıştığını anlatan sayfası bunu açıkça yazar: bazı sayfalar Google’ın zaten ziyaret ettiği için bilinir, bazıları bilinen bir sayfadan çıkarılan linkle keşfedilir, bazıları da site sahibinin gönderdiği bir sitemap aracılığıyla ortaya çıkar.
Bu üç yoldan hiçbiri taramayı garanti etmez, yalnızca keşfi tetikler. Keşif ile tarama ayrı aşamalardır: bir URL keşfedilince sıraya girer, taranıp taranmayacağı ve ne zaman taranacağı sonraki aşamanın konusudur. Googlebot da yeni taranacak URL’leri öncelikle daha önce taranmış sayfalara gömülü linklerden keşfeder; bu, Googlebot sayfasının 3 Şubat 2026 itibarıyla geçerli tanımıdır.
Sitemap, arama motorlarına sitede hangi sayfaların önemli olduğunu bildirir; Google bu dosyayı sitenizi daha verimli taramak için okur. Ama her sitenin sitemap’e ihtiyacı aynı değildir. Google Search Central’ın sitemap rehberi (10 Aralık 2025 güncellemesi) şu durumlarda sitemap önerir. Site büyükse sitemap sayfaların tamamının keşfedilmesine yardımcı olur. Site yeni ve dışarıdan az link alıyorsa sitemap keşfi hızlandırır. Site çok sayıda zengin medya veya haber içeriği taşıyorsa sitemap bu içeriğin fark edilmesini kolaylaştırır. Buna karşılık site küçükse (yaklaşık 500 sayfa veya daha az), iç bağlantısı kapsamlıysa ve az medya dosyası taşıyorsa, sayfalar düzgün bağlantılı olduğu sürece Google genellikle sitemap olmadan da sitenin çoğunu keşfedebilir.
Keşfedilen bir URL nasıl taranır, robots.txt bu aşamada ne yapar
Googlebot keşfettiği bir URL’yi kendi belirlediği bir hızda tarar; robots.txt bu erişimi kontrol eder, dizine eklemeyi değil. Googlebot sayfası çoğu site için Googlebot’un ortalama birkaç saniyeden daha sık erişmemesi gerektiğini yazar; bu hız sabit bir kural değil, sitenin yanıt davranışına göre ayarlanan bir sınırdır.
robots.txt dosyası arama motoru tarayıcılarına sitenizde hangi URL’lere erişebileceklerini söyler, ama Google Search Central’ın robots.txt giriş dokümantasyonu doğrudan uyarır: bu bir sayfayı Google’dan gizleme mekanizması değildir. Disallow edilmiş bir sayfa başka bir siteden link alıyorsa yine de dizine girebilir; robots.txt ile engellenen bir sayfanın yine de dizine girebilmesi bu kuralın bir gizleme mekanizması değil, yalnızca bir tarama izni mekanizması olduğunun kanıtıdır. Aynı mantık ters yönde de işler: bir sayfa hem robots.txt’te engelli hem noindex etiketli ise bu etiket hiçbir işe yaramaz, çünkü noindex kuralının etkili olması için sayfanın robots.txt’te engellenmemiş olması gerekir; engelliyse Googlebot sayfaya hiç erişemez ve üzerindeki kuralı da göremez.
Bu yüzden “sayfamı aramadan gizlemek istiyorum” ile “sayfamın taranmasını istemiyorum” farklı isteklerdir ve farklı araçlar gerektirir: biri noindex, diğeri robots.txt disallow kuralıdır. İkisini aynı sayfada birleştirmek, ikinciyi birinciyi etkisizleştiren bir hataya çevirir.
Taranan bir sayfa nasıl render edilir
Google, JavaScript ile oluşturulan içeriği crawling, rendering ve indexing olmak üzere üç ayrı aşamada işler; render ayrı bir kuyrukta ve gecikmeli çalışır. JavaScript SEO temelleri sayfası (4 Mart 2026 güncellemesi) Googlebot’un sayfaları hem tarama hem render kuyruğuna aldığını yazar. Bir sayfa render kuyruğunda birkaç saniye kalabilir, ama bu süre daha da uzayabilir; Google üst sınırı kasıtlı olarak belirsiz bırakır.
Bu belirsizliğin pratik sonucu tüm sitelerde aynı değildir: sunucu tarafı render (SSR) veya statik üretimde (SSG) ana içerik ilk HTTP yanıtında zaten tamdır, bu gecikme onları etkilemez. CSR’de ise taranan HTML boş bir kabuktur ve asıl içerik render kuyruğundan geçene kadar Google’ın görmediği bir şeydir; rendering kuyruğunun neden kasıtlı olarak belirsiz bir süre bırakıldığı ve bunun CSR sitelerde yarattığı gecikmenin pratik sonuçları ayrı bir yazının konusudur.
Render edilen içerik nasıl indekslenir
İndeksleme aşamasında Google, sayfanın metin, görsel ve video içeriğini analiz eder ve bilgiyi Google index adlı büyük bir veri tabanında saklar. Bu analiz sırasında Google benzer içerikli sayfaları da gruplandırır; bu sürece canonicalization denir.
Google Search Central’ın canonicalization sayfası (20 Ağustos 2026 güncellemesi) süreci şöyle tanımlar: Google önce her sayfanın ana içeriğini belirler, benzer sayfaları gruplandırır, sonra indeksleme sürecinin topladığı sinyallere göre “objektif olarak en eksiksiz ve kullanışlı” bulduğu sayfayı temsilci URL (canonical) olarak seçer. Bu seçimi etkileyen sinyaller eşit güçte değildir: 301 yönlendirmesi hedefin canonical olması gerektiğine dair güçlü bir sinyaldir, rel="canonical" etiketi de güçlü bir sinyaldir, sitemap’te listelenme ise yalnızca zayıf bir sinyaldir. Google aynı rehberde bu üç yöntemden hiçbirinin zorunlu olmadığını, sinyal verilmese de kendi objektif seçimini yapacağını yazar.
Bu sinyaller çakıştığında veya birbiriyle çelişince kanonik seçim sessizce bozulabilir. Bu durumda indeksleme aşaması tek bir etikete değil sinyal bütününe göre karar verir; sonuç, kanonik etiketin on bir farklı sessiz bozulma kalıbından birine düşebilir.
İndekslenmiş bir sayfa arama sonucunda nasıl sunulur
Sunum (serving) aşamasında bir sorgu girildiğinde Google’ın sistemleri dizindeki eşleşen sayfaları arar ve en yüksek kalite ile en ilgili bulduğu sonuçları döndürür. Bu, aramanın nasıl çalıştığını anlatan sayfadaki beşinci ve son aşamadır.
Önceki dört aşama (keşif, tarama, render, indeksleme) bir sayfayı adaylar havuzuna taşır; sunum aşaması ise her sorguda bu havuzdan yeniden seçim yapar. Bir sayfa dizine girmiş olsa bile her sorguda görünmesi garanti değildir, çünkü sunum kararı o anki sorgunun niyetine ve rekabetine göre yeniden verilir.
Gerçek bir sunucu log satırında bu süreç nasıl görünür
Bir sunucu erişim kaydındaki tek satır, hangi istemcinin hangi URL’yi hangi sonuçla istediğini gösterir; ama user-agent alanındaki “Googlebot” yazısı tek başına kanıt değildir. Googlebot’tan bu sayfanın kendi URL’sine gelen gerçek bir istek şöyle görünür.
66.249.66.1 - - [03/Oct/2026:09:14:22 +0000] "GET /blog/arama-motoru-bir-sayfayi-nasil-buluyor-ve-indeksliyor/ HTTP/1.1" 200 18432 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Satırın alanları sırasıyla şöyle okunur. 66.249.66.1 isteği yapan istemcinin IP adresidir. [03/Oct/2026:09:14:22 +0000] isteğin zaman damgasıdır. "GET /blog/.../" istenen URL ve HTTP metodudur. 200 sunucunun döndürdüğü HTTP durum kodudur. 18432 yanıtın bayt cinsinden boyutudur. "Mozilla/5.0 (compatible; Googlebot/2.1; ...)" istemcinin bildirdiği user-agent dizesidir, ama bu son alan bir bildirimdir, bir kimlik doğrulaması değildir; user-agent metni istemci tarafından gönderilir ve taklit edilebilir. Google Search Central’ın Googlebot doğrulama rehberi (20 Mart 2026 güncellemesi) gerçek doğrulamayı iki adımda tanımlar: önce erişen IP adresi üzerinde host komutuyla bir reverse DNS sorgusu çalıştırılır, ardından bulunan alan adının googlebot.com, google.com veya googleusercontent.com ile bittiği kontrol edilir, son olarak bu alan adı üzerinde bir forward DNS sorgusuyla aynı IP’ye döndüğü teyit edilir. Terminalde bu iki komut şu sırayla çalışır.
host 66.249.66.1
# -> 66.249.66.1 Googlebot için crawl-66-249-66-1.googlebot.com çıktısını verir
host crawl-66-249-66-1.googlebot.com
# -> aynı IP'ye (66.249.66.1) geri döndüğünü teyit eder
Bu tek satır bir teşhis örneğidir, bir kurulum tavsiyesi değildir. Her site için aynı ölçüde gerekli de değildir; log analizinin küçük bir sitede genelde işe yaramadığı durumlar ile gerçekten gerekli hale geldiği eşik ayrı bir kararın konusudur.
Tek bir URL için bu beş aşama Search Console’dan nasıl doğrulanır
Tek bir URL’nin bu beş aşamadan hangisinde takıldığı, Search Console’un URL İnceleme aracı ve Page Indexing Report’u birlikte kullanılarak teşhis edilir. Üç adım sırayla uygulanır.
- URL İnceleme aracına sorgulanacak tam URL girilir; araç önce mevcut dizin durumunu gösterir.
- “Canlı URL’yi test et” seçeneği tıklanır; bu, sayfanın o anki durumunu anlık olarak tarar ve kayıtlı durumla karşılaştırır.
- “İncelenen sayfayı görüntüle” ekranı açılır. Search Console Yardım sayfası burada görülecekleri şöyle tanımlar: render edilmiş sayfanın ekran görüntüsü, ham HTML, HTTP başlıkları ve JavaScript konsol çıktısı. Ekran görüntüsü yalnızca başarılı bir canlı test sonucunda kullanılabilir.
Page Indexing Report’taki dört durumun karşılığı şöyledir.
| Page Indexing Report durumu | Hangi aşamada takıldı | İlk bakılacak yer |
|---|---|---|
| Keşfedildi, şu anda dizine eklenmemiş | Keşfedildi, tarama sırası henüz gelmedi | Crawl demand, sunucu kapasitesi |
| Tarandı, şu anda dizine eklenmemiş | Tarandı, kalite veya duplikasyon nedeniyle indekslenmedi | Canonicalization, içerik kalitesi |
| noindex etiketiyle karşılaşıldı | İndeksleme aşamasında doğrudan engellendi | Meta robots etiketi, X-Robots-Tag |
| Soft 404 | Sunucu “bulunamadı” hissi veriyor ama 404 kodu yok | HTTP durum kodu |
İlk durumda sayfa Google tarafından bulunmuş ama henüz taranmamıştır. İkinci durumda sayfa taranmış ama indekse girmemiştir. Üçüncü durumda Google sayfayı indekslemeye çalışırken bir noindex kuralıyla karşılaşmıştır. Soft 404 ise sunucunun kullanıcı dostu bir “bulunamadı” mesajı gösterdiği ama gerçek bir 404 HTTP yanıt kodu döndürmediği durumdur.
Sayfa keşfedilip de neden taranmıyor, taranıp da neden indekslenmiyor
Keşfedilen bir URL’nin tarama sırası crawl demand’e (tarama talebi) bağlıdır; bu, algılanan envanter, popülerlik ve tazelik olmak üzere üç faktörden oluşur ve hiçbiri keşfedilen bir sayfanın hemen taranacağını garanti etmez. Google Search Central’ın tarama bütçesi rehberi (22 Temmuz 2026 güncellemesi) her tarayıcının kendi talebi olduğunu ve yönlendirme yoksa Google’ın sitedeki bilinen URL’lerin tamamını veya çoğunu taramaya çalıştığını yazar. Küçük ama durağan bir sitede bu süreç genelde hızlı işler; büyük veya sık değişen bir sitede gecikebilir.
Taranan bir sayfa da yine indekslenmeyebilir. Canonicalization süreci başka bir sayfayı temsilci seçmiş olabilir veya içerik ince ya da düşük kaliteli bulunmuş olabilir. Dürüst sınır burada net: Google, SEO başlangıç kılavuzunda (SEO Starter Guide) hiçbir sitenin kendi dizinine ekleneceğine dair garanti vermediğini açıkça yazar. Bu üç aşamanın (keşif, tarama, indeksleme) hiçbirinde yapılan bir iyileştirme kesin bir sonuç satın almaz.
TR SERP’te bu dürüstlük boşluğu gözle görülür. 3 Ekim 2026 tarihinde doğrudan taranan iki TR kaynaktan (ketweb.com.tr ve optimia.com.tr) hiçbiri bu garantisizlik ifadesini Google’ın kendi kaynağına bağlamıyor; bu gözlem küçük bir örneklemdir (n=2), tek oturumluk bir kesittir ve tüm TR SERP’ini temsil etmez.
Gecikmenin hangi noktada gerçek bir soruna dönüştüğü site büyüklüğüne göre değişir. Küçük bir sitede crawl demand neredeyse hiç sorun yaratmazken, tarama bütçesinin gerçekten sorun olduğu sayfa sayısı eşiklerinin hangi büyüklükten itibaren devreye girdiği ayrı bir kararın konusudur.
Kendi sitemizde bu beş aşama ne gösteriyor
technoradical.com’un sitemap’i 49 URL taşıyor; bu, Google’ın Search Console Crawl Stats raporu için verdiği en düşük adlandırdığı eşiğin (1.000 sayfa) çok altında ve robots.txt’imiz hiçbir Disallow kuralı taşımıyor. Sitemap, rakip_sitemap.py aracımızla 21 Eylül 2026’da doğrudan tarandı; robots.txt dosyası 24 Eylül 2026’da doğrudan çekildi ve yalnızca üç satır içeriyor: User-agent: *, Allow: /, Sitemap: https://technoradical.com/sitemap-index.xml.
Bu iki ölçüm bir “sorun yok” garantisi değildir, yalnızca keşif ve tarama aşamasında yapısal bir darboğaz olmadığını gösterir. İndeksleme ve sunum ayrı aşamalardır ve bunlar için henüz kendi Search Console verimiz yok; site üç aylık ölçüm eşiğini tamamlamadı.
Bu yapısal kontrolü okur da kendi sitesinde tekrarlayabilir. Bunu otomatik yapan araç, sitenizin robots.txt, sitemap ve yönlendirme durumunu otuz saniyede tarayan site denetimidir; gerçek Googlebot davranışını (Crawl Stats, log analizi) ölçmez, yalnızca yapısal hazırlığı gösterir, bu nedenle iki ölçüm türü birbirinin yerine geçmez.
indeksleme · crawling · teknik SEO · Search Console