Canonical, noindex, robots.txt ve Sitemap: İndeksleme Sinyalleri

“Sayfayı robots.txt ile engelledik ama hâlâ Google’da çıkıyor.” İndeksleme şikâyetlerinin önemli kısmı bu cümleyle başlar. Bir sayfanın arama sonuçlarında yer alıp almayacağını tek bir ayar değil, farklı işler yapan dört sinyal belirler: robots.txt, noindex, canonical ve XML sitemap. Sorun, bu sinyallerin birbirinin yerine kullanılmasından ya da aynı URL için çelişen mesaj vermesinden çıkar. Bu rehber her sinyalin gerçekte ne yaptığını, hangi senaryoda hangisinin seçileceğini ve sonucun Search Console’da nasıl doğrulanacağını anlatır.

İndeksleme kontrol araçlarının farkı

Temel ayrım tarama (crawling) ile indeksleme (indexing) arasındadır. Tarama, botun URL’yi talep edip içeriği indirmesidir; indeksleme, içeriğin arama dizinine alınmasıdır. Her sinyal bu zincirin farklı bir halkasına dokunur. Halkayı karıştırırsanız sonuç da karışır.

Sinyal	Etki ettiği aşama	Bağlayıcılık	Tipik kullanım
robots.txt Disallow	Tarama	Uyan botlar için bağlayıcı	Sonsuz URL alanları, dahili arama, yönetim yolları
meta robots / X-Robots-Tag noindex	İndeksleme	Bağlayıcı (taranırsa)	Teşekkür sayfası, ince içerikli arşivler
rel="canonical"	Kopyalar arasında seçim	İpucu	Parametreli, izleme kodlu, yinelenen URL’ler
XML sitemap	Keşif ve öncelik	İpucu	İndekslenmesi istenen kanonik URL listesi
301/308 yönlendirme	URL birleştirme	Güçlü sinyal	Kalıcı taşınan veya birleştirilen sayfalar

robots.txt protokolü RFC 9309 ile standartlaştırılmıştır; ancak yalnız protokole uyan botları bağlar ve bir erişim denetimi mekanizması değildir. Gizli kalması gereken içerik kimlik doğrulamayla korunur. robots.txt herkese açıktır ve engellediğiniz yolları dünyaya ilan eder. Güvenlik aracı değildir.

robots.txt ile noindex karıştırılmamalı

Sahada en sık gördüğümüz hata, bir sayfayı sonuçlardan çıkarmak için robots.txt ile engellemektir. Engellenen sayfa taranamaz, dolayısıyla üzerindeki noindex etiketi de okunamaz. Google sayfaya bağlantı bulursa URL’yi içerik olmadan dizine alabilir; Search Console bu durumu Sayfalar raporunda “Indexed, though blocked by robots.txt” (robots.txt ile engellenmesine rağmen dizine eklendi) satırında gösterir.

Doğru sıra şudur: önce sayfaya noindex eklenir, sayfa taranabilir bırakılır, dizinden çıktığı doğrulandıktan sonra gerekiyorsa tarama engeli eklenir. Google, robots.txt içindeki Noindex: kuralını 2019’dan beri desteklemiyor. Bu satır bugün ölü koddur.

HTML olmayan kaynaklarda (PDF, DOCX, görsel) noindex HTTP başlığıyla verilir. Nginx’te örnek:

location ~* \.(pdf|docx?)$ {
    add_header X-Robots-Tag "noindex" always;
}

Nginx’te bir location bloğuna add_header eklediğinizde üst bloklardaki add_header yönergeleri (ör. güvenlik başlıkları) o blokta devralınmaz; gerekiyorsa onları da tekrarlayın. Bu davranış, güvenlik başlıklarının PDF yanıtlarında sessizce kaybolmasının klasik nedenidir. Apache’de mod_headers etkinken eşdeğeri:

<FilesMatch "\.(pdf|docx?)$">
    Header set X-Robots-Tag "noindex"
</FilesMatch>

Canonical ne zaman çalışır, ne zaman yok sayılır

Canonical, “bu içeriğin birden çok adresi var; tercih ettiğim adres bu” demektir. Bir emir değil, ipucudur. Google bildirimi diğer sinyallerle birlikte tartar ve uyumsuzluk görürse kendi seçimini yapar. Canonical’ın yok sayıldığı tipik durumlar:

• İçerik farklı: Kategori sayfasının canonical’ı ana sayfaya verilmiş. Sayfalar gerçekten kopya değilse canonical anlamını yitirir.
• Sinyaller çelişiyor: Canonical A’yı gösteriyor, ama iç bağlantıların tamamı ve sitemap B’yi içeriyor.
• Hedef sorunlu: Canonical hedefi 3xx, 404 veya noindex dönüyor.
• Birden çok canonical: Tema ve SEO eklentisi ayrı ayrı canonical basıyor; birden çok, farklı değer varsa Google hepsini yok sayabilir.
• head dışında: Canonical body içinde ya da head geçersiz bir öğe yüzünden erken kapanmış.

Canonical ile noindex aynı sayfada birlikte kullanılmaz. “Bu sayfa B’nin kopyası” ve “bu sayfayı dizine alma” mesajları yan yana geldiğinde birleştirme sinyalleri noindex yüzünden kaybolabilir. Kopyaysa canonical. İstenmiyorsa noindex.

Canonical mutlak URL ile yazılır; protokol, alan adı ve sondaki eğik çizgi açısından kurumsal web sitenizin tercih ettiği biçimle tutarlı olmalıdır:

<link rel="canonical" href="https://www.example.com/hizmetler/teknik-seo/" />

Parametreli URL, filtre ve sayfalama

Parametreler üç türdür ve her biri farklı ele alınır:

1. İçeriği değiştirmeyenler (utm_source, gclid, oturum kimliği): Canonical parametresiz URL’yi gösterir. İç bağlantılarda bu parametreler hiç kullanılmaz.
2. İçeriği daraltanlar (filtre, sıralama): Değerli kombinasyonlar (ör. “kategori + marka”) kendi kanonik URL’leriyle dizine girebilir; diğerlerinde canonical veya noindex kullanılır. Kombinasyon sayısı patlıyorsa (çoklu filtre, fiyat aralığı) robots.txt ile tarama alanını daraltmak tarama kaynağını korur.
3. Sayfalama (/page/2/, ?page=2): Her sayfa kendine canonical verir. Google rel="prev"/rel="next" işaretlemesini indeksleme sinyali olarak artık kullanmıyor; sayfalar arasında normal <a href> bağlantıları yeterlidir.

Search Console’daki eski URL Parametreleri aracı kaldırıldı; parametre yönetimi tamamen site tarafındaki sinyallere kaldı. Hangi parametrelerin gerçekte tarandığını görmenin en güvenilir yolu sunucu loglarıdır. Tahmin etmeyin, loga bakın. Yöntem log tabanlı tarama analizi yazısında.

robots.txt ile filtre alanını daraltan örnek:

User-agent: *
Disallow: /*?*orderby=
Disallow: /*?*filter_
Disallow: /?s=
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://www.example.com/sitemap_index.xml

* joker karakteri ve $ satır sonu işareti RFC 9309’da tanımlıdır. Bir URL için birden çok kural eşleştiğinde en uzun (en özel) eşleşen kural geçerlidir; eşitlikte Allow kazanır. CSS ve JavaScript dosyalarını engellemeyin; Google sayfayı render edemezse içeriği eksik değerlendirir. Eski şablonlardan kalma Disallow: /wp-includes/ satırları hâlâ bu sorunu üretir.

XML sitemap’in içeriği ve bakımı

Sitemap, dizine girmesini istediğiniz URL’lerin listesidir; “sitedeki her şey” değildir. İçerik kuralları:

• Yalnız 200 dönen, noindex taşımayan, kendine canonical veren URL’ler.
• Yönlendirilen, silinen, parametreli veya robots.txt ile engellenen URL yok.
• lastmod yalnız içerik anlamlı biçimde değiştiğinde güncellenir. Google, doğruluğu tutarlı olduğunda lastmod’u kullanır; priority ve changefreq değerlerini ise dikkate almaz.
• Tek dosyada en fazla 50.000 URL ve sıkıştırılmamış 50 MB; daha büyük sitelerde sitemap index dosyası kullanılır.

WordPress 5.5’ten bu yana çekirdek, /wp-sitemap.xml adresinde sitemap üretir. Yoast SEO veya Rank Math gibi bir eklenti kendi sitemap’ini (/sitemap_index.xml) etkinleştirdiğinde çekirdek sitemap’i genellikle kapatır. Yine de iki sitemap’in birlikte yayında olmadığını ve Search Console’a yalnız kullandığınızın gönderildiğini kontrol edin.

Sitemap temizliğini düzenli denetlemek için URL’lerin durum kodlarını toplu kontrol edin:

curl -s https://www.example.com/post-sitemap.xml \
  | grep -o '<loc>[^<]*' | sed 's/<loc>//' \
  | while read -r u; do
      printf '%s %s\n' "$(curl -s -o /dev/null -w '%{http_code}' "$u")" "$u"
    done | grep -v '^200 '

Çıktı boş olmalı. Satır dönüyorsa sitemap’te 200 olmayan URL vardır ve önce o temizlenir.

Senaryo bazlı karar tablosu ve doğrulama

Senaryo	Önerilen sinyal	Kaçınılacak
Form gönderimi sonrası teşekkür sayfası	noindex, sitemap dışı	robots.txt engeli
UTM’li kampanya URL’leri	Canonical parametresiz URL’ye	Parametreli URL’ye iç bağlantı
Dahili site araması sonuçları	robots.txt Disallow (dizinde değilse)	Sitemap’e ekleme
Kalıcı taşınan sayfa	301/308 yönlendirme	Yalnızca canonical
Yazar veya etiket arşivi, ince içerik	noindex, follow bağlantılar korunur	Canonical ana sayfaya
PDF katalog, web sayfasında karşılığı var	X-Robots-Tag noindex veya HTTP canonical	Sayfada robots meta denemek
Staging ortamı	Kimlik doğrulama + noindex	Yalnızca robots.txt

Search Console ile doğrulama

1. URL Denetimi: Bir URL için kullanıcının belirttiği canonical (User-declared canonical) ile Google’ın seçtiği canonical (Google-selected canonical) alanlarını karşılaştırın. Farklıysa sinyaller çelişiyor demektir.
2. Sayfalar raporu: Arayüz diline göre adları değişen şu satırları inceleyin: “Excluded by ‘noindex’ tag”, “Indexed, though blocked by robots.txt”, “Duplicate, Google chose different canonical than user” ve “Alternate page with proper canonical tag”. İlk ve son satır beklenen durumlar olabilir; ortadakiler genellikle düzeltme ister.
3. Sitemap raporu: Gönderilen URL sayısı ile dizine eklenen sayı arasındaki farkın nedenlerini Sayfalar raporunda sitemap filtresiyle inceleyin.
4. robots.txt raporu: Ayarlar altındaki robots.txt raporuyla Google’ın en son aldığı sürümü ve getirme hatalarını kontrol edin.

Bu sinyaller en çok site taşımalarında ve yeniden tasarımlarda bozulur; geçiş dönemindeki kontroller web sitesi taşırken SEO kaybını önleme rehberinde. Yapılandırılmış veri ise indeksleme sinyali değil, içerik anlamı aktaran ayrı bir katmandır; o konu kurumsal sitede schema.org işaretlemesi yazısında. Bu sinyalleri site mimarisiyle birlikte tasarlamak, teknik SEO ve site mimarisi çalışmasında ilk ele aldığımız iştir.

Sık sorulan sorular

robots.txt ile engellenen bir sayfa neden hâlâ arama sonuçlarında görünüyor?

robots.txt taramayı engeller, indekslemeyi değil. Google sayfaya dış veya iç bağlantılar bulursa URL’yi içeriğini okumadan dizine alabilir. Sayfanın sonuçlardan çıkması isteniyorsa robots.txt engeli kaldırılır ve sayfaya noindex eklenir.

Canonical etiketi yazdığım halde Google neden başka bir URL seçti?

Canonical bir ipucudur. İç bağlantılar, sitemap, yönlendirmeler ve içerik benzerliği farklı bir URL’yi destekliyorsa Google kendi seçimini yapabilir. URL Denetimi aracında kullanıcı tarafından belirtilen ve Google tarafından seçilen canonical alanlarını karşılaştırın, sinyalleri aynı URL’de birleştirin.

noindex sayfayı sitemap’te tutmalı mıyım?

Hayır. Sitemap yalnız dizine girmesini istediğiniz, 200 dönen kanonik URL’leri içerir. noindex sayfaları sitemap’e koymak çelişkili sinyal üretir ve Search Console’da gereksiz uyarılara yol açar. Tek istisna, noindex’in hızlı fark edilmesi için geçici olarak tutmaktır.

Sayfalamalı listelerde ikinci ve sonraki sayfalara canonical olarak ilk sayfayı göstermeli miyim?

Genellikle hayır. Her sayfalama sayfası farklı içerik listelediği için kendine canonical verir. İlk sayfaya canonical vermek, sonraki sayfalardaki öğelere giden bağlantıların keşfini zayıflatabilir.