Google Search Console ve Bing Webmaster Tools'a Başlangıç: Doğrulama, URL Inspection ve Temel Raporlar

Sürüm notu: Bu yazı Google Search Console ve Bing Webmaster Tools yardım sayfalarının Kasım 2026 hâlini esas alır; kod örnekleri .NET 10 ile derlenip denenmiştir.

Önce Tahmin Et

Bookstore'u https://www.bookstore.example adresinde yayınladın ve Search Console'a https://www.bookstore.example/ adresiyle, yani bir URL (Uniform Resource Locator) önekiyle, bir property ekledin. Bir ay sonra pazarlama ekibi blog.bookstore.example'ı açıyor, eski http:// adresleri de hâlâ dışarıdan link alıyor. Sence bu property bu üç adresin hangisinin verisini gösterir? Bir de şu: Bing Webmaster Tools'u kurmak için sıfırdan doğrulama yapman gerekir mi?

İki Property Tipi: Domain ve URL-prefix

Search Console'da her şey bir property'ye bağlı ve iki tip var. Domain property, kök domain'i, bütün subdomain'leri ve bütün protokolleri (http, https) kapsar; bookstore.example diye, protokolsüz ve www'suz girilir. Doğrulaması yalnızca DNS (Domain Name System) kaydıyla yapılabilir. URL-prefix property ise yalnızca girdiğin önekle, protokol dahil, başlayan URL'leri kapsar: https://www.bookstore.example/ property'si http:// sürümünü de, blog. subdomain'ini de görmez.

Baştaki sorunun cevabı bu yüzden "yalnızca ilki". Pratik öneri: site sahibi olarak önce bir Domain property kur, bütün verini tek yerde gör. Belirli bir bölümü ayrı izlemek istersen, örneğin İngilizce içerik için https://www.bookstore.example/en/, onu ek bir URL-prefix property olarak ekle. URL-prefix property'yi DNS ile doğrularsan eşleşen Domain property de otomatik doğrulanıyor.

Doğrulama Yöntemleri ve Kalıcılık

Domain property için tek yol, DNS sağlayıcında Search Console'un verdiği değerle bir TXT (text) kaydı oluşturmak. Kaydın görünmesi bir gün veya daha uzun sürebilir. URL-prefix property için daha çok seçenek var: kök dizine bir HTML (HyperText Markup Language) dosyası yüklemek, ana sayfanın <head>'ine meta tag eklemek, Google Analytics veya Google Tag Manager üzerinden doğrulamak.

Gözden kaçan kural şu: doğrulama tek seferlik değil. Search Console token'ın varlığını periyodik olarak kontrol ediyor; bulamazsa seni uyarıyor, sorun düzelmezse bir süre sonra yetkin düşüyor. DNS kaydını doğruladıktan sonra silmek, meta tag'i bir layout değişikliğinde kaybetmek ya da dosyayı yeni deploy'da unutmak yetkiyi sessizce bitirir. Bu yüzden meta tag yöntemini seçtiysen, onu koda değil configuration'a bağla:

namespace Bookstore.Web.Seo;

public sealed class SearchVerificationOptions
{
    public const string SectionName = "SearchVerification";

    public string? Google { get; init; }
    public string? Bing { get; init; }
}

@using Microsoft.Extensions.Options
@using Bookstore.Web.Seo
@inject IOptions<SearchVerificationOptions> Verification
@if (Verification.Value.Google is { Length: > 0 } google)
{
    <meta name="google-site-verification" content="@google" />
}
@if (Verification.Value.Bing is { Length: > 0 } bing)
{
    <meta name="msvalidate.01" content="@bing" />
}

builder.Services.Configure<SearchVerificationOptions>(
    builder.Configuration.GetSection(SearchVerificationOptions.SectionName));

Layout bu partial'ı yalnızca ana sayfada basıyor, çünkü Google meta tag'i giriş yapılmamış ana sayfanın <head>'inde arıyor. Yerel testte değerler sahte token'lar:

$ curl -s http://localhost:5481/ | grep -E "verification|msvalidate"
            <meta name="google-site-verification" content="local-test-google-token" />
    <meta name="msvalidate.01" content="LOCALTESTBINGTOKEN" />

Birden fazla kişi aynı property'yi farklı yöntemlerle doğrulayabilir; bu iyi bir yedek. Aynı yöntemi kullanan iki sahibin birbirinin token'ını ezmemesi gerekiyor. Ajans veya danışmanla çalışıyorsan Google'ın SEO (Search Engine Optimization) hizmeti almak üzerine yazdığı "Do you need an SEO?" sayfasındaki öneri net: denetim için yalnızca okuma yetkisi ver, yazma yetkisi verme. SEO danışmanına verilen tam yetki, yanlış bir Removals isteğiyle bütün siteyi geçici olarak sonuçlardan çıkarabilir.

URL Inspection: Tek Bir Sayfanın Röntgeni

URL Inspection aracı, bir URL'nin Google'daki durumunu gösteriyor. Index'teki sürüm için en çok bakacağın alanlar şunlar:

• Google-selected canonical ve User-declared canonical: senin rel="canonical" ile verdiğin oy ve Google'ın verdiği karar. Farklılarsa serinin altıncı yazısındaki teşhis yoluna gir.
• Last crawl ve Crawled as: son crawl tarihi ve desktop mı mobil mi crawl edildiği. Index'teki bütün veri bu crawl'dan geliyor.
• Crawl allowed?, Page fetch ve Indexing allowed?: robots.txt izni, sayfanın indirilip indirilemediği ve noindex durumu.
• Referring page ve Sitemaps: Google'ı bu URL'ye götürmüş olabilecek sayfa ve URL'yi içeren sitemap'ler.

Bir tuzak: robots.txt crawl'ı engelliyorsa "Indexing allowed?" her zaman "Yes" gösterir, çünkü Google sayfayı göremediği için oradaki noindex'i de göremez. "Yes" burada "index'lenebilir" değil, "engel görmedim" demek.

Live test, URL'yi o anda indirip test eder; bu yüzden index'teki sürümden farklı sonuç verebilir. Sınırları önemli: canonical seçimini, duplicate durumunu, manual action'ları, kalite ve güvenlik sorunlarını kontrol etmez. "URL is available to Google" sonucu index'lenmeyi garanti etmez. Ekran görüntüsü yalnızca live test'te var. Request indexing ile yeniden index'leme isteyebilirsin ama property başına günlük bir kota var ve istek de garanti değil; çok sayıda sayfa için doğru araç lastmod değerleri doğru bir sitemap.

Page Indexing Raporu

Page indexing raporu, Google'ın bildiği URL'leri "indexed" ve "not indexed" olarak ayırıyor ve index'lenmeyenler için bir neden veriyor. En sık göreceğin nedenler: Crawled – currently not indexed, Discovered – currently not indexed, Duplicate without user-selected canonical, Duplicate, Google chose different canonical than user, Alternate page with proper canonical tag, URL marked 'noindex', Blocked by robots.txt, Soft 404, Not found (404), Page with redirect ve Server error (5xx). Bu nedenlerin hangisinin sorun, hangisinin beklenen durum olduğunu bir sonraki yazıda tek tek ayıracağız; örneğin mertozen.com'un Kasım 2026'da /en/ yapısına geçmesinden sonra eski ?lang=en adreslerinin "Page with redirect" olarak görünmesi tam istenen şey, çünkü bu adresler artık 301 ile yeni URL'lere yönleniyor.

Bir sorunu düzelttikten sonra "Validate fix" düğmesi var. Google önce bütün örneklerin düzeltilmiş olmasını bekliyor; tek bir örnek kalsa doğrulama duruyor. Süreç tipik olarak iki haftaya kadar, bazen daha uzun sürüyor; bu sırada düğmeye tekrar basmamak gerekiyor.

Performance Raporu: Click, Impression, CTR ve Position

Performance raporunun dört metriği şöyle tanımlı: click, kullanıcının Google sonuçlarından siteye tıklama sayısı; impression, sitenin sonuçlarda görünme sayısı; CTR (click-through rate, tıklama oranı) click'in impression'a oranı; average position ise sitenin en üstteki sonucunun ortalama pozisyonu. Rapor sorgu, sayfa, ülke, cihaz, search appearance ve tarih boyutlarında kırılabiliyor; arama tipleri Web, Image, Video ve News olarak ayrı. En yeni veri ön veri olabiliyor ve birkaç saat içinde değişebiliyor.

Okurken bir sayma kuralını bil: property bazında bakarken aynı sorguda sitenin birden çok sayfası çıksa bile bunlar tek impression sayılır ve pozisyon en üstteki sonuçtur; sayfa bazında bakınca her URL ayrı sayılır. Bu yüzden property ve sayfa görünümünde CTR ve pozisyon farklı çıkar ve bu bir hata değildir.

AI (Artificial Intelligence, yapay zekâ) özellikleri: Google'ın "AI features and your website" sayfasına göre AI Overviews ve AI Mode'dan gelen trafik genel Search Console verisine, Performance raporunda "Web" arama tipine dahil. Haziran 2026'dan beri ayrıca generative AI performans raporları da var ve 31 Ağustos 2026 itibarıyla bütün sitelere açıldı. Bu raporun ne gösterip ne göstermediğini GEO (Generative Engine Optimization) serisinin ölçüm yazısında ayrıntılı ele alacağız.

Bing Webmaster Tools: Import ile Beş Dakikada

Bing Webmaster Tools'u kurmanın en kısa yolu Search Console'dan import. My Sites sayfasında Import'a tıklıyor, Google hesabınla giriş yapıp izin veriyorsun; Bing doğrulanmış sitelerini ve sitemap'lerini listeliyor, seçtiklerin otomatik doğrulanmış olarak ekleniyor. Bir seferde 100 siteye kadar import edilebiliyor. Bing sahipliği Search Console hesabın üzerinden periyodik olarak yeniden kontrol ediyor; o erişimi geri çekersen başka bir yöntemle doğrulaman gerekir. Alternatifler XML (Extensible Markup Language) dosyası, msvalidate.01 meta tag'i, DNS CNAME (Canonical Name) kaydı ve Domain Connect. Yeni doğrulanan sitenin trafik verisi 48 saate kadar gecikebiliyor.

Bing neden önemli? Kendi arama trafiğinin ötesinde, Microsoft Copilot ve Bing'deki AI destekli cevaplar Bing'in index'iyle grounding yapıyor ve Bing Webmaster Tools Şubat 2026'dan beri bu yüzeylerdeki citation'ları gösteren bir AI Performance raporunu public preview olarak sunuyor. Ayrıntısı GEO serisinde. Bing ayrıca IndexNow ile değişen URL'leri anında bildirmeyi destekliyor; uygulaması Teknik SEO serisinin "XML Sitemap ve IndexNow" yazısında.

mertozen.com İçin İlk Hafta Kontrol Listesi

Bu siteyi örnek alarak, iki aracı kurduktan sonraki ilk hafta için kısa bir liste:

Gün 1: mertozen.com için Domain property kur. Bu tek property www'lu ve www'suz adresleri, http ve https'i, TR sayfaları ve /en/ altındaki EN sayfaları birlikte kapsar. İstersen https://www.mertozen.com/en/ için ek bir URL-prefix property aç; İngilizce içeriğin performansını ayrı görmek kolaylaşır.

Gün 1: Sitemaps raporuna /sitemap.xml'i gönder. Sitenin robots.txt'i zaten Sitemap: satırı içeriyor, ama gönderim sana raporda okunan URL sayısını ve hataları gösterir. robots.txt raporunda dosyanın sorunsuz okunduğunu kontrol et.

Gün 2: Bing Webmaster Tools'a Search Console'dan import et.

Gün 2–3: Bir TR ve bir EN yazıyı URL Inspection ile incele. Google-selected canonical, User-declared canonical ile aynı mı? EN yazının canonical'ı /en/blog/... adresi mi? Crawled as mobil mi?

Gün 7: Page indexing raporunda "not indexed" nedenlerine bak; beklenen ve beklenmeyen nedenleri ayır. Performance raporunda ilk haftalık veriyi bir referans olarak kaydet; yorumlamak için henüz erken.

Kalıcı: kullanıcıları gözden geçir, okuma yetkisi yeten herkese yalnızca okuma yetkisi ver; e-posta bildirimlerinin açık olduğunu kontrol et.

Üretimde Dikkat

Doğrulama token'larını altyapı kodunun parçası yap. DNS kaydı Terraform gibi bir araçla yönetiliyorsa TXT kaydı da orada dursun; birisi "bu ne işe yarıyor?" deyip silemesin.

Taşıma ve yeniden yapılanmalardan önce property'leri düşün. Bir subdomain'e veya yeni domain'e geçişte Domain property'n hazırsa veri kesintisiz görünür. Site taşıma süreci Teknik SEO serisinin "Site Taşıma" yazısında.

Search Console verisini düzenli dışa aktar. Arayüz sınırlı bir geçmiş saklıyor; uzun dönemli karşılaştırma için veriyi kendin saklamak gerekecek. Derin analiz ve dashboard işi ilerideki Analytics ve Ölçüm serisinde.

Sık Düşülen Tuzaklar

Yalnızca URL-prefix property kurup www'suz ya da http trafiği görmemek. Domain property bu kör noktayı kapatır.

Doğrulama dosyasını veya DNS kaydını iş bitti diye silmek. Doğrulama süreklidir; token gidince yetki de gider.

Request indexing'i bir yayın adımı sanmak. Kota var, garanti yok; doğru sitemap ve iç link'ler asıl keşif yolu.

Live test'in "available" sonucunu "index'lendi" diye okumak. Live test canonical'ı ve kaliteyi kontrol etmez.

Küçük Bir Deneme

★☆☆ Kendi siten için hangi property tipini kullandığını kontrol et; URL-prefix ise bir Domain property ekle ve iki property'nin toplam click sayılarını karşılaştır.

★★☆ SearchVerificationOptions'ı genişlet: production ortamında Google token'ı boşsa uygulama açılırken uyarı loglasın. Options validation ile ValidateOnStart kullan.

★★★ Sitenin sitemap'indeki URL'lerden rastgele on tanesini seç ve her biri için URL Inspection'daki "Google-selected canonical" değerini bir tabloya yaz. Kaç tanesinde senin canonical'ınla aynı?

Araçlar kuruldu. Bir sonraki yazıda bu araçları en sık açtığın soruyla kullanacağız: "Sayfam neden index'lenmedi?" sorusu için adım adım bir teşhis ağacı.