Google Search Console Nedir, Nasıl Kullanılır? 2026

Google Search Console (GSC), Google'ın site sahiplerine ÜCRETSİZ sunduğu, sitenizin Google aramasındaki performansını izlediğiniz, sorunları teşhis ettiğiniz ve indekslemeyi yönettiğiniz resmî kontrol panelidir. Kısaca: sitenizin Google'la konuştuğu yerdir. Hangi sorgularda kaç kez göründüğünüzü, kaç tıklama aldığınızı, hangi sayfalarınızın indekslendiğini, teknik hataları ve Core Web Vitals durumunu doğrudan Google'ın kendi verisiyle gösterir. Bir siteyi Google'da ciddiye alıp büyütmek istiyorsanız, GSC olmazsa olmazdır; çünkü Google'ın sitenizi nasıl gördüğünü başka hiçbir araç bu kadar doğru anlatmaz.

Bunu somutlaştıralım. Bir SEO çalışmasında üç temel soruya cevap ararsınız: Google sayfalarımı görüyor mu (tarama), index'ine alıyor mu (indeksleme), ve aldıysa sıralıyor mu (sıralama)? Google aramasının çalışma mantığı tam olarak bu üç aşamadır: tarama (crawling), indeksleme (indexing) ve sıralama (serving/ranking). Her üç aşamada da ayrı ayrı sorun çıkabilir ve bir sayfanın "indekslenmemiş" olması ile "indekslendiği halde sıralanmaması" tamamen farklı problemlerdir. İşte Search Console, bu üç aşamanın her birini sizin için şeffaflaştıran tek araçtır. Üçüncü taraf SEO araçları (Ahrefs, Semrush gibi) sizin için tahmin yürütür; GSC ise Google'ın gerçek verisini verir. SEO'nun ne olduğunu ve nasıl yapıldığını anlattığımız genel rehberde de vurguladığımız gibi, ölçemediğiniz şeyi yönetemezsiniz; GSC ise ölçümün başladığı yerdir.

Bu üç aşamayı ve GSC'nin her birinde size ne gösterdiğini tek bir tabloda görmek, aracın neden vazgeçilmez olduğunu netleştirir:

Tablodan da görüleceği gibi, "sayfam Google'da yok" şikâyetinin altında çok farklı kök nedenler yatabilir; GSC bu nedeni isim isim söyler. Örneğin bir müşterimizde 400 ürün sayfasının yalnızca 60'ı indeksliydi; sorun ne içerikti ne de cezaydı, kanonik etiketlerin yanlış kurulması yüzünden Google sayfaları "kanonik alternatif" sayıp ayıklıyordu. Bunu yalnızca Sayfalar raporundaki gruplama sayesinde dakikalar içinde teşhis ettik. Teknik SEO denetimi yaparken bu tür indeksleme kayıplarını ilk olarak GSC'de yakalarsınız.

Google Search Console tam olarak ne işe yarar?

Müşterilerimizde gördüğümüz en yaygın yanılgı, GSC'yi yalnızca "trafik gösteren bir grafik" sanmaktır. Oysa araç çok daha derindir. En temel haliyle GSC şu işleri yapar:

• Gerçek arama performansınızı gösterir: Hangi anahtar kelimelerde (sorgu) görünüyorsunuz, kaç gösterim ve tıklama alıyorsunuz, ortalama pozisyonunuz kaç? Bu, sahip olabileceğiniz en güvenilir kendi verinizdir; çünkü tahmin değil, fiilen Google'da aldığınız aramalardır.
• İndeksleme durumunu raporlar: Hangi sayfalarınız index'te, hangileri değil ve neden değil (noindex, kanonik alternatif, taranıp indekslenmemiş, 404 vb.)?
• Tek bir URL'i inceletir: Belirli bir sayfanın indeksli olup olmadığını, son ne zaman tarandığını, Google'ın hangi kanonik URL'i seçtiğini görür ve manuel tarama tetiklersiniz.
• Sitemap gönderirsiniz: XML sitemap'inizi Google'a iletip durumunu takip edersiniz. Deneyimimizde "yeni sayfalarım Google'da çıkmıyor" şikâyetinin en sık kök nedeni, sitemap'in hiç GSC'ye gönderilmemiş olmasıdır.
• Teknik sağlığı izler: Core Web Vitals (gerçek kullanıcı verisiyle), mobil kullanılabilirlik, yapısal veri hataları ve manuel işlem/güvenlik uyarıları tek panelde toplanır.

Bu işlevlerin her birinin somut bir karşılığı var. Performans raporu size dört temel metrik verir: Tıklama, Gösterim, TO (CTR, yani tıklama/gösterim oranı) ve Ortalama Pozisyon. Bu dördünü sorgu, sayfa, ülke, cihaz ve arama görünümü bazında filtreleyebilirsiniz. Örneğin "ülke: Türkiye" ve "cihaz: mobil" filtresini birlikte uygulayıp, mobilde takılı kalan sayfalarınızı izole edebilirsiniz. URL İnceleme aracı ise tek bir sayfa için Google'ın kanonik seçimini, son tarama zamanını ve render edilmiş halini gösterir; bir sayfada büyük bir değişiklik yaptıysanız "İndekslenmeyi iste" (Request Indexing) ile yeniden taranmasını tetikleyebilirsiniz. Yapısal verinizde yanlış varsa "Geliştirmeler" raporları desteklenen tipler için hata/uyarı çıkarır.

Burada 2026 için önemli bir uyarı: FAQ (SSS) ve HowTo zengin sonuçları artık beklenmemelidir. Google, FAQ zengin sonucunu 2023'te yalnızca otoriter devlet ve sağlık siteleriyle sınırladı; 2026'da ise desteğini tamamen kaldırıyor (FAQ raporu ve Rich Results Test desteği 2026 içinde, Search Console API tarafı 2026 içinde kalkıyor). HowTo zengin sonucu da kaldırıldı. Yani GSC'de "FAQ raporum kayboldu" gördüğünüzde bu bir hata değil, beklenen davranıştır. FAQ ve HowTo şemaları zarar vermez ve içeriğin anlaşılırlığı/AEO açısından hâlâ değerli olabilir; ama artık görsel zengin sonuç getirmezler. Buna karşılık Article/BlogPosting, Product + Offer + AggregateRating, BreadcrumbList, Organization ve LocalBusiness gibi tipler hâlâ zengin sonuç verir ve GSC'nin "Geliştirmeler" bölümünde izlenir.

Bu yüzden Search Console'u sadece bir "rapor aracı" değil, SEO çalışmanızın komuta merkezi olarak görmek gerekir. Teknik SEO denetimi yaparken indeksleme ve tarama sorunlarının çoğunu önce GSC'de fark edersiniz; anahtar kelime araştırması yaparken ise zaten görünmeye başladığınız ama tıklama alamadığınız sorguları keşfederek hızlı kazanımlar yakalarsınız. Hatta GSC'nin Performans raporu, başka hiçbir aracın veremeyeceği bir şeyi verir: sizin sitenizin fiilen aldığı sorgular. Keyword Planner ya da Ahrefs tahmini hacim verirken, GSC gerçek talebi gösterir; bu da onu sıralama faktörlerini kendi sitenizde test ettiğiniz bir laboratuvara dönüştürür.

Neden ücretsiz ve neden her site için şart?

GSC Google'ın kendi ürünüdür ve tamamen ücretsizdir; bir bütçe kalemi değildir. Bu, küçük bir işletme sitesi ile büyük bir e-ticaret mağazasını aynı veri kalitesine eşitleyen önemli bir avantajdır. Pahalı SEO araçları sizin sitenize "dışarıdan" bakarken, GSC içeriden, Google'ın gözünden bakar. "Şart" demenin pratik sebepleri net:

• Veri kaynağı tekildir: Bir sayfanın neden indekslenmediğini, hangi sorguda kaçıncı sırada olduğunuzu yalnızca Google'ın kendisi kesin bilir. Üçüncü taraf araçlar bunu modelleyerek tahmin eder; GSC ölçer.
• Sorunları erken yakalarsınız: Yanlışlıkla bir bölümü "noindex" yapmak, sitemap'in kırılması, sunucu hatalarının artması ya da bir manuel işlem (ceza) bildirimi GSC'de görünür. Bu uyarıları görmeyen bir site, trafiğini kaybettikten haftalar sonra durumu fark eder.
• Karar verirken yön gösterir: Hangi içeriklerin gerçekten talep gördüğünü, hangi sayfaların 8-15. sıralarda takılıp kaldığını (yani biraz iyileştirmeyle ilk sayfaya taşınabilecek fırsatları) GSC'deki ortalama pozisyon ve tıklama oranı verisinden okursunuz.

Bu üç sebebi günlük pratiğe dökelim. GSC ile diğer araçların rolünü karıştırmamak için ayrımı netleştirmek faydalı:

Görüldüğü gibi GSC ile ücretli araçlar rakip değil, tamamlayıcıdır: rakip ve kelime havuzu istihbaratı için ücretli araçlara, kendi sitenizin gerçeğine inmek için GSC'ye ihtiyaç duyarsınız. Backlink ve link inşası tarafında bile GSC'nin "Bağlantılar" raporu, size kimlerin link verdiğini Google'ın gözünden gösteren ücretsiz bir başlangıç noktasıdır.

2026 itibarıyla bu önem daha da arttı, çünkü arama deneyiminin sunumu değişti. Google, AI Overviews ve AI Mode'u aramanın merkezine taşıdı; klasik on mavi link hâlâ duruyor ama AI özetleri çoğu sorguda en üstte konumlanıyor. Bu durum, gösterim aldığınız halde tıklama oranınızın düşebileceği anlamına gelir; üçüncü taraf çalışmalar AI Overview göründüğünde üst sıradaki sayfanın tıklama oranında belirgin (yaklaşık yarı yarıya seviyelerinde) düşüşler raporluyor ve aramaların yarısından fazlasının dış siteye tıklama olmadan bittiğini gösteriyor. Bu rakamlar Google'ın resmî verisi değil, üçüncü taraf çalışmalardır; ama yönelimi yalnızca GSC'nin performans verisinde, kendi sayfalarınızda somut olarak takip edebilirsiniz. Sıralamanın temelleri (alaka, kalite, E-E-A-T, kullanılabilirlik) değişmedi; ama gösterim-tıklama ilişkisini izlemek için GSC artık daha da kritik. Yapay zekâ aramalarındaki yeni dinamikleri merak ediyorsanız AI Overviews'te nasıl görünürüm yazımız bu tabloyu detaylandırıyor; arama görünürlüğünü bütünsel ölçmek için yapay zekâ görünürlüğünün nasıl ölçüldüğünü de inceleyebilirsiniz.

Pratik bir okuma örneği verelim. GSC Performans raporunda bir sayfanız "gösterim yükseldi, tıklama sabit, ortalama pozisyon 1,2" gösteriyorsa, bu büyük olasılıkla o sorguda bir AI özetinin devreye girdiğinin işaretidir: birinci sıradasınız ama kullanıcı yanıtı SERP'te alıp tıklamadan gidiyor olabilir. Bu durumda strateji "daha yukarı çıkmak" değil, içeriğin AI özetinin ötesinde değer sunmasını sağlamak ve answer-first kurguya geçmektir. Aynı raporda bir sayfanız "yüksek gösterim, çok düşük TO, ortalama pozisyon 6-9" gösteriyorsa, kazanım büyük ihtimalle başlık ve açıklamada gizlidir. İşte bu iki senaryoyu birbirinden ayıran şey GSC verisidir; "trafik düştü" demek kolaydır, ama nedenini ancak bu üç metrik üçlüsünü birlikte okuyarak söylersiniz.

Şunu da net söyleyelim: GSC sihirli bir sıralama aracı değildir; size sıra yükseltmez, veriyi gösterir. Asıl iş, bu veriyi okuyup doğru aksiyona dönüştürmektir. Bir e-ticaret sitesinde "ürün adı + fiyat" sorgularında çok gösterim alıp az tıklama aldığınızı GSC'de görürseniz, sorun büyük olasılıkla başlık ve açıklamanızdadır; bu durumda meta başlık ve açıklamanızı yeniden yazmak ya da hızlıca bir taslak çıkarmak için meta title-description oluşturucu aracımızı kullanmak somut bir kazanım sağlar. E-ticaret özelinde indeksleme ve kategori derinliği konusunda ürün ve kategori sayfaları SEO rehberimiz tamamlayıcı olacaktır. Veriyi teşhise, teşhisi aksiyona bağlamak; GSC'nin gerçek değeri buradadır.

Özetle Search Console, sitenizin Google karşısındaki "sağlık karnesi" ve erken uyarı sistemidir: ücretsizdir, kurulumu yarım saatlik bir iştir ve sağladığı veri başka hiçbir yerden alınamaz. Yeni kurulan kişisel bir bloğunuz da olsa, binlerce ürünlü bir mağazanız da olsa kurulması gereken ilk araçtır. Bu rehberin devamında hesabı nasıl kurup doğrulayacağınızı, performans raporunu nasıl okuyacağınızı ve indeksleme sorunlarını nasıl çözeceğinizi adım adım göstereceğiz. SEO çalışmanızı en baştan doğru kurgulamak isterseniz, dijital pazarlama danışmanlığı hizmetimiz kapsamında GSC kurulumundan veri yorumlamaya kadar süreci sizinle birlikte yürütüyor; dilerseniz ücretsiz bir site analizi ile mevcut durumunuzu birlikte değerlendirebiliriz.

Google Search Console Kurulumu: Mülk Doğrulama ve Sitemap Gönderme

Google Search Console kurulumu üç adımdan oluşur: mülkü ekleyip sahipliği doğrulamak, XML sitemap'i göndermek ve ilk ayarları yapmak. Doğrulama, Google'a "bu site bana ait" demenin resmi yoludur; doğrulanmamış bir mülkte hiçbir veri göremez, sitemap gönderemez, indeksleme isteyemezsiniz. Kurulumu doğru yapmak, ileride alacağınız tüm sinyallerin (gerçek sorgularınız, indeksleme durumu, Core Web Vitals) temiz ve eksiksiz olmasını sağlar. Bu yüzden ilk 15 dakikayı acele etmeden geçirmek, sonraki aylarda yanlış teşhis koymanızı önler.

Pratikte en sık karşılaştığımız sorun, doğrulamanın yarım kalması ya da yanlış mülk türünün seçilmesidir. Aşağıda iki mülk türünü, beş doğrulama yöntemini ve doğrulama sonrası yapılması gereken ilk işleri somut adımlarla anlatıyoruz. Search Console'un genel mantığını ve hangi raporların neye yaradığını ayrı bir başlıkta ele aldığımız için, burada doğrudan kurulumun teknik detaylarına odaklanıyoruz; SEO'nun bütününü merak ediyorsanız SEO nedir, nasıl yapılır rehberimiz iyi bir başlangıç noktası.

Hangi mülk türünü seçmeliyim: Domain mi, URL Öneki mi?

Search Console iki mülk türü sunar ve seçiminiz, ilerideki veri kapsamını belirler. Kısa cevap: çoğu site için Domain (Alan Adı) mülkü en sağlıklı seçimdir, çünkü tek bir kayıt altında tüm alt alan adlarını ve hem HTTP hem HTTPS protokollerini toplar.

• Domain mülkü: example.com şeklinde, protokol ve "www" olmadan girilir. Bu mülk https://example.com, https://www.example.com, http://example.com, hatta blog.example.com gibi tüm alt alan adlarını ve protokol varyantlarını tek çatı altında toplar. Veri parçalanmaz; raporlarınız sitenin tamamını yansıtır. Tek dezavantajı, doğrulamanın yalnızca DNS kaydıyla yapılabilmesidir.
• URL Öneki (URL Prefix) mülkü: Tam adresi protokolüyle birlikte girersiniz: https://www.example.com. Bu mülk yalnızca o tam önekle başlayan URL'leri kapsar; http:// sürümü ya da "www"siz hali ayrı bir mülk sayılır. Avantajı, DNS dışında dört farklı doğrulama yöntemini de desteklemesidir.

Müşterilerimizde gördüğümüz tipik hata, yalnızca https://www.example.com URL öneki mülkü ekleyip "www"siz ya da HTTP üzerinden gelen trafiği gözden kaçırmaktır. Site farklı varyantlar arasında doğru yönlendirme yapsa bile, ayrı mülkler veriyi böler. Bizim önerimiz: Önce Domain mülkünü kurun (tüm tabloyu görmek için), gerekiyorsa belirli alt bölümleri ayrı izlemek için ek olarak URL Öneki mülkleri ekleyin. İkisi birlikte sorun yaratmaz; aksine, DNS doğrulaması bir nedenle gecikirse URL Öneki mülkü size hızlı bir geçici giriş sağlar.

Pratik bir örnekle netleştirelim. Diyelim ki sitenizin canlı sürümü https://magazaniz.com üzerinde çalışıyor, blogunuz blog.magazaniz.com alt alan adında duruyor ve eski sayfalarınızın bir kısmı hâlâ "www"li adrese yönleniyor. Yalnızca https://www.magazaniz.com URL öneki mülkü kurarsanız, blog alt alan adından gelen tüm tıklama ve gösterimler raporlarınızda hiç görünmez; üstelik "www"siz ana adresinizdeki trafiği de kaçırırsınız. Bu durumda "blog yazılarım hiç gösterim almıyor" gibi yanlış bir teşhise varırsınız; oysa veri sadece başka bir mülke düşüyordur. Domain mülkü bu üç parçayı (ana alan, blog alt alanı, www varyantı) tek raporda birleştirir ve büyük resmi doğru görmenizi sağlar.

Mülk doğrulama yöntemleri nelerdir?

Doğrulama, sahipliği Google'a kanıtlama işlemidir ve beş ana yöntem vardır. Hangisini seçeceğiniz, mülk türünüze ve siteye erişim seviyenize bağlıdır. Aşağıdaki tablo, her yöntemin ne zaman uygun olduğunu özetliyor.

Bu yöntemler birbirinin alternatifidir; sahipliği kanıtlamak için yalnızca birini tamamlamanız yeterlidir. Yine de pratikte tek bir yöntemle yetinmek yerine, sonradan bozulma ihtimaline karşı ikinci bir yöntemi de aktif tutmak akıllıcadır. Örneğin DNS doğrulamasını tamamlayıp ek olarak GA4 doğrulamasını da bırakırsanız, biri bir gün geçersiz hâle gelse bile mülkünüz doğrulanmış kalır ve aylarca biriken veriniz silinmez. Hangi yöntemi kullanırsanız kullanın, doğrulama kanıtını (TXT kaydı, dosya, meta etiket) kalıcı tutmanız gerektiğini unutmayın; Google sahipliği periyodik olarak yeniden kontrol eder.

DNS doğrulaması nasıl yapılır?

Domain mülkü için tek yol DNS doğrulamasıdır ve aslında en güvenilir olanıdır, çünkü doğrulama tek bir tema dosyasına ya da eklentiye bağlı kalmaz. Adımlar şöyle:

1. Search Console'da Domain mülkünü eklediğinizde Google size bir TXT kaydı değeri verir (genellikle google-site-verification= ile başlayan bir dize).
2. Alan adınızı yönettiğiniz sağlayıcının (örneğin alan adı kayıt firması ya da DNS yönetiminizin yapıldığı yer) DNS yönetim paneline girin.
3. Yeni bir TXT kaydı oluşturun: Host/Ad alanına genellikle @ (kök alan), Değer alanına Google'ın verdiği dizeyi yapıştırın.
4. Kaydedin ve Search Console'a dönüp "Doğrula" düğmesine basın.

DNS değişiklikleri internette yayılırken (propagation) zaman alabilir; çoğu sağlayıcıda birkaç dakikada tamamlanır ama bazı durumlarda saatler sürebilir. İlk denemede "doğrulanamadı" hatası alırsanız panik yapmayın; kaydı doğru girdiyseniz bir süre bekleyip tekrar deneyin. Doğrulama tamamlandıktan sonra TXT kaydını silmeyin; Google sahipliği periyodik olarak yeniden kontrol eder, kayıt kalkarsa mülk doğrulamasını kaybedersiniz.

DNS doğrulamasında en sık takılınan üç nokta şudur ve hepsinin somut çözümü vardır. Birincisi, Host alanına alan adının tamamını yazmak: Çoğu panelde kök alan için yalnızca @ işareti ya da boş bırakma beklenir; buraya example.com yazmak kaydı yanlış konuma yerleştirir. İkincisi, kopyalarken araya boşluk ya da satır sonu karışması; google-site-verification= dizesinin başında veya sonunda görünmez bir boşluk varsa doğrulama başarısız olur, dizeyi olduğu gibi ve kırpılmadan yapıştırın. Üçüncüsü, sağlayıcının kayda otomatik olarak alan adınızı eklemesi nedeniyle değerin çift yazılmasıdır; doğrulamadan önce kaydın yalnızca Google'ın verdiği dizeden ibaret olduğunu kontrol edin. Bazı sağlayıcılar TXT kayıtlarına ayrıca bir TTL (yaşam süresi) değeri sorar; bunu varsayılanda bırakmak güvenlidir.

Burada önemli bir güvenlik notu: TXT kaydını eklemek, alan adınızın yönlendirmesini ya da e-posta akışını değiştirmez; yalnızca bir doğrulama dizesi ekler. Yine de DNS paneliyle çalışırken mevcut MX (e-posta), A, AAAA ve CNAME kayıtlarına dokunmamaya dikkat edin; bunlardan birini yanlışlıkla silmek ya da değiştirmek sitenizi veya e-postanızı erişilemez hâle getirebilir. Mümkünse değişiklik öncesi mevcut kayıtların ekran görüntüsünü alın. DNS panelinize erişiminiz yoksa, geçici çözüm olarak URL Öneki mülküyle HTML etiketi yöntemini kullanabilir, DNS erişimi sağlanınca Domain mülküne geçebilirsiniz.

HTML etiketi ve diğer hızlı yöntemler ne zaman tercih edilir?

DNS'e erişiminiz yoksa ama sitenin temasını ya da analitik kurulumunu yönetiyorsanız, URL Öneki mülküyle daha hızlı yöntemlere geçebilirsiniz:

• HTML meta etiketi: Google'ın verdiği meta etiketini sayfanın <head> bölümüne, tüm sayfalarda görünecek şekilde (genellikle ortak header/template dosyasına) ekleyin. Yayına aldıktan sonra "Doğrula"ya basın. Etiketi sonradan kaldırmayın; doğrulama düşer.
• HTML dosyası: Google'ın verdiği benzersiz dosyayı sitenin kök dizinine yükleyin (örneğin example.com/googleXXXX.html erişilebilir olmalı). Sunucu/FTP erişimi olanlar için pratiktir.
• Google Analytics / Tag Manager: Sitede zaten GA4 ya da GTM kuruluysa ve Search Console'a giriş yaptığınız Google hesabı bu kurulumların yönetici erişimine sahipse, tek tıkla doğrulayabilirsiniz. İzleme kodunuzun <head> içinde olması gerekir.

Bu yöntemleri seçerken altyapınıza göre küçük ama önemli farklar vardır. WordPress kullanıyorsanız meta etiketi genellikle bir SEO eklentisinin (ör. Yoast, Rank Math) doğrulama alanına yapıştırılır; etiketi tema dosyasına elle eklemek tema güncellemesinde kaybolacağı için bu daha güvenlidir. Next.js, Shopify ya da özel bir altyapı kullanıyorsanız meta etiketini ortak layout/head bileşenine eklemek en sağlıklısıdır. HTML dosyası yöntemini seçtiyseniz, dosyanın gerçekten erişilebilir olduğunu doğrulamak için adresini tarayıcıda açıp içeriğini görebildiğinizden emin olun; bazı sunucular .html uzantılı statik dosyaları yönlendirme kurallarına takabilir. GA4 doğrulamasında ise dikkat edilecek nokta, izleme kodunun gövdenin (<body>) içinde değil, <head> içinde yer almasıdır; aksi halde Google kodu doğrulama amacıyla okuyamaz.

Hangi yöntemi seçerseniz seçin, birden fazlasını aynı anda aktif tutmak sorun yaratmaz; aksine yedeklilik sağlar. Örneğin DNS + HTML etiketini birlikte tutarsanız, biri bir nedenle bozulsa bile mülk doğrulanmış kalır. Bu kurulum işleri, sitenizin teknik altyapısının da düzgün olmasını gerektirir; head etiketleri, kanonik yapı ve yönlendirmelerin tutarlılığını teknik SEO denetimi rehberimizde ayrıntılı ele alıyoruz. Bu kurulumların doğru yapılandırılması bizim dijital pazarlama danışmanlığı hizmetimizin de ilk adımlarından biridir.

Sitemap nasıl gönderilir ve ne işe yarar?

XML sitemap, Google'a sitenizdeki önemli URL'lerin bir listesini sunan bir dosyadır; tarama ve keşfi hızlandırır. Doğrulama tamamlandıktan sonra sitemap göndermek, özellikle yeni ya da büyük sitelerde sayfaların daha hızlı bulunmasına yardımcı olur. Search Console'un sol menüsündeki Site Haritaları (Sitemaps) bölümünden sitemap URL'nizi (genellikle https://example.com/sitemap.xml) girip "Gönder"e basmanız yeterlidir.

Sitemap'inizin sağlıklı olması için birkaç temel kurala dikkat edin. Bunlar Google'ın resmi önerileridir ve gerçekten fark yaratır:

• Sitemap yalnızca indekslenebilir, kanonik URL'ler içermeli. noindex etiketli sayfaları, yönlendirme (3xx) hedeflerini ve yinelenen (duplicate) URL'leri sitemap'e koymayın.
• Tüm URL'ler HTTPS sürümünde olmalı; sitemap'iniz HTTP adresleri listeliyorsa düzeltin. HTTPS hem temel bir gereklilik hem de bir sıralama sinyalidir.
• URL'ler mutlak (tam) adres olmalı ve mülkünüzün kapsamıyla uyumlu olmalı. Domain mülkü kurduysanız alt alan adlarınızı da kapsayan sitemap'leri gönderebilirsiniz.
• Çok büyük sitelerde tek sitemap'i bir sitemap indeksi (sitemap index) altında birden çok dosyaya bölün.

Deneyimimizde "yeni sayfalar Google'da görünmüyor" şikayetinin en sık kök nedeni, sitemap'in hiç gönderilmemiş ya da yanlış (noindex/yönlendirme içeren) URL'lerle dolu olmasıdır. Sık karşılaştığımız bir başka durum, sitemap'in eski bir CMS yapısından kalma yüzlerce duplicate ya da etiket/arşiv sayfasını listelemesi; bu, Google'ın asıl önemli sayfalarınızı keşfetme verimini düşürür. Sitemap göndermenin indekslemeyi garanti etmediğini de unutmayın; Google sitemap'i bir öneri/keşif sinyali olarak görür, son kararı kendi verir. Bir URL'i sitemap'e koymak, içeriğin kalitesinin ya da arama amacına uygunluğunun yerini tutmaz; zayıf içerik sitemap'te olsa da indekslenmeyebilir. Sitemap doğru içerikle gönderildikten sonra, Search Console'daki Sayfalar/İndeksleme raporundan hangi URL'lerin indekslendiğini, hangilerinin neden dışarıda kaldığını (noindex, kanonik alternatif, taranıp indekslenmemiş, 404 gibi) takip edebilirsiniz. Bu raporları ve genel arayüzü kullanmayı, bu kümedeki içerik kümesi ve topical authority yazımızla birlikte planlarsanız hangi sayfaların öncelikli indekslenmesi gerektiğini de netleştirebilirsiniz.

Doğrulama sonrası yapılacak ilk ayarlar nelerdir?

Mülk doğrulanıp sitemap gönderildikten sonra, ilk haftalarda verinin temiz ve eksiksiz birikmesi için birkaç ayarı hemen yapmanızı öneririz:

• Tercih edilen mülki belirleyin: Hem Domain hem URL Öneki mülkünüz varsa, ana raporlama için Domain mülkünü esas alın; veriyi orada bütünsel görürsünüz.
• Kullanıcı ve izinleri ekleyin: Ekip arkadaşlarınızı ya da ajansınızı "Ayarlar > Kullanıcılar ve izinler" üzerinden ekleyin. Mülk sahibi (owner) tüm yetkiye, "tam" (full) kullanıcı çoğu işleve, "kısıtlı" (restricted) kullanıcı yalnızca görüntülemeye erişir. Doğrulama dizesini paylaşmak yerine bu yetki sistemini kullanın; böylece birinin erişimini sonradan tek tıkla kaldırabilirsiniz.
• URL İnceleme aracını test edin: Önemli bir sayfanızın URL'ini "URL İnceleme" kutusuna yapıştırıp indeks durumunu, son taranma zamanını ve Google'ın seçtiği kanonik URL'i kontrol edin. Burada Google'ın seçtiği kanonik ile sizin belirttiğiniz kanonik farklıysa, bu ileride çözmeniz gereken bir sinyal çelişkisidir. Yeni yayınladığınız kritik bir sayfa için "İndekslenmeyi iste" (Request Indexing) ile manuel tarama tetikleyebilirsiniz; bu, toplu kullanım için değil, tekil acil sayfalar içindir.
• Veri birikmesini bekleyin: Performans raporundaki Tıklama, Gösterim, TO (CTR) ve Ortalama Pozisyon metrikleri geçmişe dönük dolmaz; doğrulama anından itibaren toplanmaya başlar. İlk birkaç gün boş ya da kısıtlı veri görmeniz normaldir.

Bu ilk ayarlar tamamlandığında Search Console'unuz artık gerçek sorgularınızı, indeksleme durumunuzu ve Core Web Vitals verinizi düzgün toplamaya başlar. Core Web Vitals raporunun gerçek kullanıcı verisiyle (CrUX) çalıştığını ve yeterli trafik birikene kadar bazı URL gruplarında "yeterli veri yok" görebileceğinizi de aklınızda tutun; bu, kurulum hatası değil, ölçümün doğası gereğidir. Bizim müşteri kurulumlarında izlediğimiz sıra şudur: Domain mülkü + DNS doğrulaması, ardından temiz bir sitemap, ardından kullanıcı izinleri ve URL İnceleme testi. Bu temel sağlam atıldığında, ilerleyen aşamalarda anahtar kelime fırsatlarını ve sıralama performansını izlemek çok daha kolay olur; nitekim anahtar kelime araştırması rehberimizde de gerçek sorgularınızı görmek için en güvenilir kaynağın kendi Search Console verileriniz olduğunu vurguluyoruz. Kurulumdan emin değilseniz ya da çok dilli/karmaşık bir mülk yapınız varsa, bir ücretsiz analiz talebiyle yapıyı birlikte gözden geçirebiliriz.

Performans Raporu: Tıklama, Gösterim, CTR ve Pozisyon Nasıl Okunur?

Performans raporu, Google Search Console'da gerçek arama verinizi gördüğünüz tek panodur ve sitenizin Google aramasında nasıl performans gösterdiğini dört temel metrikle özetler: Tıklama (Clicks), Gösterim (Impressions), TO/CTR (tıklama oranı) ve Ortalama Pozisyon. Bu rapor, üçüncü taraf araçların tahmin ettiği değil, sitenizin Google'dan gerçekten aldığı aramaları gösterir; bu yüzden sahip olduğunuz en güvenilir SEO verisi budur. Müşterilerimizde gördüğümüz en yaygın hata, ekiplerin Ahrefs ya da Semrush gibi araçların tahmini verilerine bakıp kendi Search Console verilerini görmezden gelmesidir. Bu araçlar değerlidir; ama bir kelimede "ortalama" bir hacim ve "tahmini" bir tıklama oranı sunarlar. Search Console ise sizin sitenizin, sizin başlığınızla, sizin gerçek sorgularınızdan aldığı kesin sayıları verir. Oysa anahtar kelime araştırması yaparken bile en sağlam başlangıç noktası, sitenizin halihazırda gösterim aldığı gerçek sorgulardır; çünkü orada Google sizi zaten "bu konunun adayı" olarak görmektedir.

Performans raporunu açtığınızda üstte bu dört metrik kart hâlinde durur; her birinin yanındaki kutucuğa tıklayarak grafikte açıp kapatabilirsiniz. Varsayılan olarak Tıklama ve Gösterim açıktır; CTR ve Pozisyon'u da açıp aynı grafikte birlikte okumak, asıl içgörünün çıktığı yerdir. Metriklerin tek başına anlamı sınırlıdır; birbirleriyle ilişkili okunduklarında fırsat ve sorun haritası ortaya çıkar. Bir başka deyişle Performans raporu, tek tek sayılardan çok bu dört sayının oranları ve birlikte hareketleri üzerinden okunur.

Dört temel metrik tam olarak neyi ölçer?

Her metriğin tanımı net olmalı, çünkü yanlış yorum yanlış aksiyona yol açar:

• Gösterim (Impressions): Sitenizin bir URL'inin arama sonuçlarında kullanıcıya görünmesi. Kullanıcı o sayfaya kadar kaydırmamış olsa bile, sonuç o sorgu için listelenmişse gösterim sayılır. Gösterim, "Google beni bu sorgu için aday görüyor" demektir; yani sıralama sürecinin (tarama → indeksleme → sıralama) üçüncü aşamasına girdiğinizin kanıtıdır.
• Tıklama (Clicks): Kullanıcının arama sonucundan sitenize gelmek için bağlantıya tıklaması. Gerçek trafiğin ham sayısıdır. Bir kullanıcı aynı sorgu içinde sonuca girip geri dönüp tekrar tıklarsa bu tek tıklama sayılır; metrik, "kaç ziyaret" değil "kaç benzersiz tıklama olayı" mantığına yakındır.
• TO/CTR (tıklama oranı): Tıklama bölü gösterim. Yani sizi gördüğü hâlde kaç kullanıcının tıkladığı. %2 CTR, sizi gören her 100 kişiden 2'sinin tıkladığı anlamına gelir. CTR, başlık ve açıklamanızın "ikna gücünün" en doğrudan göstergesidir; ama yalnızca metin kalitesini değil, sonucun SERP'te nereye düştüğünü ve etrafında ne olduğunu (AI Overview, zengin sonuç, reklam) da yansıtır.
• Ortalama Pozisyon: Sorgular ve gösterimler boyunca sitenizin ortalama sıralama konumu. Bu bir ortalamadır; tek bir sabit sıra değildir. Bir sayfa bir sorguda 3., başka bir sorguda 28. çıkıyorsa, ortalama pozisyon bu değerlerin gösterim ağırlıklı ortalamasıdır. Bu yüzden "ortalama pozisyonum 9" demek, hiçbir sorguda 9. olmadığınız hâlde gerçekleşebilir.

Ortalama pozisyonu okurken sık yapılan bir yanılgıya dikkat edin: ortalama pozisyonunuz 18'den 12'ye iyileştiğinde, tıklamalarınız sabit kalmış hatta düşmüş gibi görünebilir. Bu çelişkili değildir. Birinci sayfanın altına ya da ikinci sayfaya yaklaşmak gösterimi artırır ama bu konumlarda CTR çok düşüktür; gerçek tıklama sıçraması genellikle ilk 3-5 sıraya girdiğinizde gelir. Bunun pratik bir uzantısı da şudur: yeni bir sayfa yayınladığınızda ortalama pozisyonunuz başta düşük (yani sayısal olarak yüksek, ör. 40+) görünebilir, çünkü Google sayfayı çeşitli sorgular için test ederken çok sayıda alakası zayıf sorguda da gösterir. Birkaç hafta içinde Google sayfayı gerçek niyetiyle eşleştirdikçe ortalama pozisyon doğal olarak oturur. Bu yüzden pozisyonu asla tek başına değil, daima gösterim ve CTR ile birlikte değerlendiririz.

Sorgu, sayfa, ülke, cihaz: filtrelerle veriyi nasıl dilimlersiniz?

Performans raporunun asıl gücü, bu dört metriği farklı boyutlara göre kırabilmenizdir. Grafiğin altındaki sekmeler size aynı veriyi farklı açılardan gösterir:

• Sorgular (Queries): Kullanıcıların sitenizi bulduğu gerçek arama terimleri. Hangi kelimelerin gösterim ve tıklama getirdiğini buradan görürsünüz. (Not: Gizlilik nedeniyle düşük hacimli/anonim sorgular gizlenir, dolayısıyla sorgu satırlarının toplamı her zaman üstteki toplam tıklamaya birebir eşit olmaz. Bu bir hata değil, beklenen davranıştır; özellikle küçük sitelerde "(other)" payı yüksek olabilir.)
• Sayfalar (Pages): Hangi URL'lerin trafik aldığı. İçeriğinizin hangi parçasının çalıştığını gösterir. Bir sayfanın çok sayıda farklı sorgudan tıklama alması genelde iyi bir konu otoritesi sinyalidir.
• Ülkeler (Countries): Trafiğin coğrafi dağılımı. Türkiye merkezli bir işletmeyseniz Türkiye dışı gösterimlerin neden geldiğini sorgulamak değerlidir; bazen bu, alakasız uluslararası gösterimlerin CTR'nizi yapay biçimde düşürdüğünü ortaya çıkarır. Filtreyi Türkiye'ye sabitlediğinizde gerçek hedef kitlenizin CTR'si çok daha sağlıklı görünebilir.
• Cihazlar (Devices): Mobil, masaüstü, tablet kırılımı. Google 5 Temmuz 2024'te mobil-öncelikli indekslemeyi tüm siteler için tamamladı; sıralama sinyalleri artık akıllı telefon taramasından geliyor. Bu yüzden mobildeki pozisyon ve CTR'niz, masaüstünden zayıfsa öncelikli olarak ele alınmalıdır. Mobilde pozisyonun masaüstünden belirgin düşük olması çoğu zaman mobil sayfa hızı veya kullanılabilirlik sorununa işaret eder.
• Tarihler (Dates): Aynı metrikleri günlük zaman serisi olarak verir; ani bir tek-gün sıçramasının mı yoksa kalıcı bir trendin mi söz konusu olduğunu burada ayırt edersiniz.
• Arama görünümü (Search Appearance): Sonuçların hangi özel görünümlerle (ör. yapısal veri tabanlı zengin sonuçlar, video) çıktığını gösterir. Bir uyarı: FAQ ve HowTo gibi eski zengin sonuç türleri Google tarafından kaldırıldığından, bu görünümlerin raporlarda yer alması beklenmemelidir.

Bu boyutları tek tek bakmak yerine birleştirmek, profesyonel kullanımın özüdür. Search Console'da bir sorguya tıkladığınızda, raporu o sorguya sabitleyip "Sayfalar" sekmesine geçebilirsiniz; böylece "bu sorgu için hangi sayfam sıralanıyor?" sorusunu yanıtlarsınız. Tersi de mümkün: bir sayfaya sabitleyip "Sorgular" sekmesine geçerek o sayfanın hangi kelimelerden tıklama aldığını görürsünüz. Bu çapraz filtreleme, bir sayfayı yanlış sorgunun mu sıralayıp sıralamadığını ya da tek bir sayfanın yamulmuş şekilde birden çok ilgisiz sorguya cevap vermeye mi çalıştığını ortaya çıkarır; bu da sayfa içi SEO ve içerik kümeleme kararlarınızı doğrudan besler. Aynı yöntem "yamyamlık" (cannibalization) teşhisinde de altın değerindedir: tek bir sorguya sabitleyip Sayfalar sekmesine geçtiğinizde aynı sorgu için iki-üç farklı sayfanızın sırayla gösterim aldığını görüyorsanız, sayfalarınız birbirinin sıralamasını yiyordur. Çözüm genelde içerikleri birleştirmek ve zayıf olanı güçlü olana 301 ile yönlendirmektir.

Search Console arayüzünün önemli bir kısıtı da şudur: tablo en çok 1.000 satır gösterir ve karmaşık çok katmanlı filtreleri tek ekranda kuramazsınız. Daha derin analiz için verinizi dışa aktarmanızı, ya da Search Console'u Looker Studio gibi bir araca bağlayıp pano kurmanızı öneririz. Yine de günlük teşhisin büyük çoğunluğu doğrudan arayüzdeki bu çapraz filtrelerle çözülür; aracı zenginleştirmeden önce bu temel hareketleri akıcı kullanmak çok daha değerlidir.

Karşılaştırma ve tarih aralığı: trendi nasıl yakalarsınız?

Tek bir tarih aralığının mutlak sayıları yanıltıcı olabilir; asıl bilgi değişimde saklıdır. Tarih seçicideki "Karşılaştır" sekmesiyle iki dönemi yan yana koyabilirsiniz. Pratikte en sık kullandığımız üç karşılaştırma vardır:

• Son 3 ay ile önceki 3 ay: İçerik çalışmalarınızın ya da bir teknik SEO denetiminin ardından sitenin genel yönünü görmek için. Üç ay, SEO sinyallerinin olgunlaşması için makul bir penceredir; daha kısa dönemler gürültü içerir.
• Yıldan yıla (aynı dönem, geçen yıl): Mevsimsellik içeren işletmelerde (ör. e-ticaret, turizm) adil kıyas için. Geçen ayla bu ayı kıyaslamak, sezonsal bir sektörde yanlış paniğe yol açabilir; örneğin bir hediye/çiçek e-ticaretinde şubat ile mart kıyası anlamsızken, geçen yılın martı ile bu yılın martı doğru kıyastır.
• Belirli bir yayın/güncelleme tarihinden önce ve sonra: Özel tarih aralığı seçerek bir içerik revizyonunun ya da yeni bir içerik kümesinin gerçekten fark yaratıp yaratmadığını ölçersiniz.

Önemli bir teknik nokta: Performans raporundaki standart "Web Arama" sekmesinde tarihsel veri 16 ay ile sınırlıdır. Daha uzun trend analizi için verinizi düzenli dışa aktarmanızı (CSV/Sheets) ya da Search Console'un bulk veri dışa aktarımı (örneğin BigQuery'ye akıtma) seçeneklerini değerlendirmenizi öneririz; aksi hâlde 16 aydan eski veriniz kalıcı olarak kaybolur. Ayrıca, Search Console verisi gerçek zamanlı değildir: en güncel bir-iki günün verisi henüz tam oturmamış olabilir, dolayısıyla "bugün tıklamam düştü" paniğine kapılmadan önce verinin tamamlanmasını beklemek gerekir.

Trend okurken, Google'ın büyük çekirdek güncellemelerinin (örneğin Mart 2024 Core Update, ki yaklaşık 45 günde tamamlanan en kapsamlı güncellemelerden biriydi ve Yardımcı İçerik Sistemi'ni doğrudan çekirdek sıralama sistemine entegre etti) yaşandığı tarihleri grafikte zihinsel olarak işaretlemek, ani trafik değişimlerini doğru nedene bağlamanızı sağlar. Bir düşüşü "algoritma cezası" sanıp paniklemeden önce, tarihin bir core güncelleme penceresine denk gelip gelmediğini ve düşüşün belirli sayfa/sorgu gruplarında mı yoksa sitenin tamamında mı olduğunu kontrol etmek temel disiplindir. Çoğu zaman gerçek neden algoritma değil; bir teknik sorun (yanlışlıkla eklenen noindex, çöken bir sayfa şablonu, bozulan bir sitemap) ya da mevsimsellik olur. Mart 2024 sonrası güncellemelerin hedefinin "yalnızca arama motoru için yazılmış, yardımcı olmayan içeriği" azaltmak olduğunu da hatırlayın; düşüş bir core güncellemeye denk geliyor ve etkilenen sayfalar zayıf/ince içerikse, çözüm ceza aramak değil içeriği "önce insan" ilkesiyle gerçekten güçlendirmektir.

Fırsat avı: Performans raporundan hangi somut aksiyonlar çıkar?

Performans raporu yalnızca bir gözlem panosu değildir; doğru okunduğunda doğrudan yapılacaklar listesi üretir. Aşağıdaki tabloda, bizim müşteri denetimlerinde rutin olarak aradığımız sinyalleri, ne anlama geldiklerini ve hangi aksiyona dönüştüklerini özetledik:

Bu tablodaki ikinci satır, yani birinci sayfa eşiğindeki sayfalar, deneyimimizde en yüksek geri dönüşü olan fırsattır. Pozisyonu 8 ile 20 arasında olan sorguları filtreleyin; bunlar Google'ın zaten ilgili bulduğu ama henüz tam ödüllendirmediği sayfalardır. Çoğu zaman sıfırdan yeni içerik üretmek yerine bu mevcut sayfaları güçlendirmek çok daha hızlı sonuç verir: içeriği güncel veriyle tazelemek, eksik alt başlıkları (özellikle People Also Ask'ta çıkan soruları) eklemek, konuyla ilgili güçlü iç sayfalardan bağlantı vermek ve başlığı sorgunun gerçek diline yaklaştırmak. Bu yüzden içerik takviminizi planlarken Search Console'un bu kesitini ham veri olarak kullanmanızı, hatta bunu dijital pazarlama danışmanlığı süreçlerimizde olduğu gibi düzenli bir ritme bağlamanızı öneririz.

Başlık ve açıklama optimizasyonunu hız kazanmak için tek tek el yordamıyla yazmak yerine bir taslaktan başlamak da işe yarar; bu noktada meta başlık ve açıklama oluşturucu aracımız ilk sürümü çıkarmanızı hızlandırır, ardından sorgunun diline göre elle inceltirsiniz. Yazım ilkeleri için ise meta title ve description nasıl yazılır rehberimiz başlangıç noktasıdır. Yalnızca şunu unutmayın: başlığı her ne kadar özenle yazsanız da Google başlıkları sık sık yeniden yazar, dolayısıyla SERP'te aynen görünmeyebilir; bu yüzden başlık değişikliğinin etkisini varsayım yerine yine Performans raporundaki CTR değişiminden ölçmek gerekir.

CTR'yi yorumlarken iki çağdaş gerçeği akılda tutmak gerekir. Birincisi, başlık ve açıklamayı iyileştirmek CTR'yi artırabilir; ancak yukarıda belirttiğimiz gibi Google başlıkları sık sık yeniden yazıyor, dolayısıyla başlığınız her zaman aynen görünmeyebilir. İkincisi, 2026 itibarıyla Google aramalarının önemli bir bölümü AI Overviews ve zengin sonuçlar nedeniyle dış siteye tıklama olmadan bitiyor; üçüncü taraf çalışmaları aramaların yaklaşık yarısından fazlasının "sıfır-tık" olduğunu raporluyor (bu oranlar çalışmaya göre değişir, yaklaşık değerlerdir ve Google'ın resmî rakamı değildir). Üstelik AI Overviews, Mayıs 2025'ten itibaren Türkiye'de ve Türkçe sorgularda aktiftir; yani bu etki Türk pazarındaki sayfalarınız için de geçerlidir. Bu, düşük CTR'nin her zaman sizin hatanız olmadığı anlamına gelir; bazı bilgilendirici sorgularda yüksek gösterim alıp düşük tıklama almak yapısal hâle geldi. Bu nedenle giderek artan biçimde içeriğinizi yalnızca tıklama için değil, AI motorlarının doğrudan alıntılayabileceği netlikte de yazmak gerekiyor; bu yaklaşımın detaylarını AI Overviews'da nasıl görünürsünüz yazımızda ele alıyoruz.

Performans raporunu hangi sıklıkta ve nasıl bir disiplinle okumalısınız?

Performans raporu günlük bakılacak bir pano değildir; SEO sinyalleri haftalar-aylar ölçeğinde olgunlaşır ve veride doğal bir gürültü vardır. Günlük takıntılı bakış, gerçek bir trendi gürültüden ayırt etmenizi zorlaştırır. Müşterilerimize önerdiğimiz ritim şudur: haftada bir hızlı genel bakış (ani düşüş/yükseliş var mı, indekslemede bir kopma yaşandı mı), ayda bir derinlemesine fırsat analizi (eşik sayfalar, düşük CTR sorguları, yeni gösterim kazanan sorgular, yamyamlık kontrolü) ve büyük güncelleme dönemlerinde olağan dışı kontrol. Her oturumda mutlaka aynı boyutları aynı sırayla taramak (önce sorgular, sonra sayfalar, sonra cihaz/ülke, sonra karşılaştırma) zamanla sitenizin "normalini" tanımanızı sağlar; çünkü anomaliyi ancak normali bildiğinizde fark edersiniz.

Bu okuma disiplinini tek başına değil, Search Console'un diğer raporlarıyla birlikte yürütmek gerekir. Performans raporunda bir sayfanın gösterimi aniden sıfıra düştüyse, hemen başlık yazmaya koşmadan önce URL İnceleme aracıyla o sayfanın hâlâ indeksli olup olmadığını, Sayfalar (İndeksleme) raporunda yeni bir hata türü belirip belirmediğini ve Core Web Vitals raporunda bir bozulma olup olmadığını kontrol ederiz; çünkü "indekslenmemiş olmak" ile "sıralanmamak" tamamen farklı sorunlardır ve çözümleri de farklıdır. Sıralama düşüşünün arkasında sıklıkla bir tarama/indeksleme sorunu yatar ve bunu yalnızca Performans grafiğine bakarak göremezsiniz. Bu bütünsel okuma alışkanlığı, SEO'nun bütününde sürdürülebilir ilerlemenin temelidir ve hangi içeriğin gerçekten çalıştığını tahmin yerine veriyle kanıtlar; raporu düzenli, yapılı ve diğer GSC verileriyle çapraz okuyan ekipler, rakiplerinden çok daha hızlı ve çok daha az "panik kararıyla" ilerler.

Search Console ile İndeksleme Sorunlarını Nasıl Teşhis Edersiniz?

Search Console'un en güçlü tarafı, bir sayfanın Google'a girip girmediğini ve girmemişse neden girmediğini somut olarak göstermesidir. Bunu anlamak için Google'ın üç aşamalı çalıştığını hatırlamak gerekir: Tarama (Googlebot sayfayı keşfeder ve indirir), İndeksleme (içerik işlenip Google index'ine kaydedilir) ve Sıralama (sorguya göre sonuçlar sıralanır). Search Console size her üç aşamada da nerede takıldığınızı söyler. Burada kritik bir ayrım var: bir sayfanın indekslenmemiş olması ile sıralanmaması bambaşka şeylerdir. İndekslenmemiş sayfa Google'ın hafızasında hiç yoktur; indeksli ama sıralanmayan sayfa ise hafızadadır, sadece sorgulara yeterince alakalı bulunmamıştır. Bu iki durumun çözümü de tamamen farklıdır, dolayısıyla teşhisi doğru koymak ilk adımdır.

Bu ayrımı pratikte hangi rapora bakacağınıza dönüştürmek için basit bir karar kuralı kullanırız: bir URL'yi URL İnceleme aracına yapıştırın. "URL Google'da değil" çıkıyorsa sorun indeksleme aşamasındadır ve çözüm bu bölümde anlatılan tarama/kanonik/noindex teşhisindedir. "URL Google'da" çıkıyor ama yine de trafik gelmiyorsa sorun sıralama aşamasındadır; bu durumda Performans raporuna geçip sayfanın hangi sorgularda gösterim aldığını, ortalama pozisyonunu ve tıklama oranını incelemeniz gerekir. İki aşamayı karıştırmak en pahalı hatadır: indekslenmemiş bir sayfaya backlink veya içerik eklemek (sıralama müdahalesi) boşa kürek çekmektir, çünkü sayfa zaten yarışın içinde değildir.

Müşterilerimizde en sık karşılaştığımız senaryo şudur: yeni bir blog yazısı veya ürün sayfası yayına alınır, birkaç gün beklenir ve "Google'da çıkmıyoruz" denir. Çoğu zaman sorun sıralama değil, sayfanın henüz hiç indekslenmemiş olmasıdır. Özellikle yeni veya otoritesi düşük sitelerde Google, keşfettiği her URL'yi anında taramaz; bir öncelik sırasına koyar. Bu yüzden yeni bir bölüm yayına aldığınızda ilk birkaç gün "Keşfedildi - şu anda indekslenmedi" durumunu görmek normaldir ve panik gerektirmez. Search Console bu ayrımı saniyeler içinde yapmanızı sağlar. Teknik SEO denetimi nasıl yapılır yazımızda bu teşhis akışını site geneli için ele alıyoruz; bu bölümde ise tekil URL ve rapor düzeyinde derinleşeceğiz.

URL İnceleme Aracı Ne İşe Yarar, Nasıl Kullanılır?

URL İnceleme (URL Inspection) aracı, tek bir adresin Google nezdindeki güncel durumunu gösteren teşhis panelinizdir. Search Console'un üst arama çubuğuna sitenize ait herhangi bir URL'yi yapıştırdığınızda araç size şu bilgileri verir: sayfa Google index'inde var mı, en son ne zaman tarandı, Google hangi URL'yi kanonik (tercih edilen) olarak seçmiş, sayfa nasıl render ediliyor ve tarama sırasında bir engel çıkmış mı. Bu tek araç, "neden indekslenmiyorum" sorularının büyük kısmını tek başına yanıtlar.

URL İnceleme aracının pratikte en çok kullanılan üç işlevi şunlardır:

• İndeksleme durumu kontrolü: "URL Google'da" yazıyorsa sayfa indekslidir. "URL Google'da değil" yazıyorsa hemen altındaki sebep satırını okuyun; sorunun tarama mı, kanonik seçimi mi yoksa noindex mi olduğunu burası söyler.
• İndekslenmeyi iste (Request Indexing): Yeni yayınladığınız veya güncellediğiniz bir sayfa için manuel tarama tetiklersiniz. Bu, indekslemeyi garanti etmez, sadece Googlebot'a "buraya bir bak" sinyali gönderir. Toplu URL gönderme aracı değildir; her seferinde tek URL içindir ve günlük bir kota sınırı vardır, bu yüzden yüzlerce sayfayı tek tek istemek yerine sitemap'e güvenmek daha verimlidir.
• Canlı URL testi: "Canlı URL'yi test et" ile sayfanın şu anki halini Googlebot'un nasıl gördüğünü kontrol edersiniz. Render edilmiş HTML'i ve ekran görüntüsünü incelemek, JavaScript ile yüklenen içeriğin Google tarafından görülüp görülmediğini anlamanın en doğrudan yoludur.

URL İnceleme aracının gösterdiği iki ayrı görünümü karıştırmamak önemlidir. "Dizine eklenmiş URL" sekmesi Google'ın en son taradığı sürümü (yani index'teki hali) gösterir; "Canlı test" ise sayfanın şu anki halini test eder. Bir sayfada noindex'i yeni kaldırdıysanız, index sekmesi hâlâ eski (noindex'li) durumu raporlayabilir; gerçek güncel durumu görmek için canlı testi çalıştırmanız gerekir. Bu ayrım, "düzelttim ama hâlâ engelli görünüyor" tipindeki yanlış alarmları önler.

Mobil-öncelikli indeksleme 5 Temmuz 2024'te tüm siteler için tamamen tamamlandığından, URL İnceleme'nin gösterdiği render artık akıllı telefon Googlebot'unun gördüğüdür. Bu yüzden render çıktısında masaüstüyle aynı ana içeriği, başlıkları, iç linkleri ve yapısal veriyi görmeniz gerekir; mobilde "gizlenen" bir içerik (örneğin masaüstünde gösterilip mobilde sekmenin arkasına saklanan ama hiç yüklenmeyen metin) Google için yok hükmündedir. Sayfanızın yapısal verisini incelerken doğru kurguladığınızdan emin olmak için yapısal veri ve schema markup rehberi yazımız işinize yarar.

Kanonik seçimi konusunda da araç sizi şaşırtabilir. URL İnceleme iki ayrı kanonik satırı gösterir: "Kullanıcının belirttiği kanonik" (sizin rel="canonical" etiketiyle söylediğiniz) ve "Google tarafından seçilen kanonik" (Google'ın gerçekte tercih ettiği). Bu ikisi farklıysa, Google sizin işaret ettiğiniz URL yerine başka bir sürümü tercih etmiş demektir; bu genellikle yinelenen içerik, tutarsız iç linkleme veya çelişkili sinyal anlamına gelir. Pratikte en sık gördüğümüz tetikleyiciler şunlardır:

• Aynı içeriğin hem "www" hem "www" olmayan, ya da hem HTTP hem HTTPS sürümünün erişilebilir olması.
• İzleme parametreli URL'lerin (ör. "?utm_source=" gibi ekler) ayrı sayfa gibi taranması.
• İç linklerinizin tutarsız olması: bazı linkler sondaki taksiz sürüme, bazıları taksizine, bazıları parametreli sürüme gitmesi.
• Sitemap'te bir URL, kanonik etiketinde başka bir URL göstermeniz.

Bu durumda çözüm, tüm sinyalleri tek bir kanonik URL'de buluşturmaktır: iç linkler, sitemap, kanonik etiket ve yönlendirmeler hepsi aynı sürümü işaret etmeli. Google'ın kanonik kararı bir öneri değerlendirmesidir; ne kadar tutarlı sinyal verirseniz, sizin tercih ettiğiniz URL'yi seçme olasılığı o kadar artar.

Sayfalar (İndeksleme) Raporu Hangi Sorunları Gösterir?

Sayfalar/İndeksleme raporu (eski adıyla Coverage), sitenizin tamamı için kuş bakışı bir indeksleme tablosudur. Rapor sayfalarınızı iki ana grupta toplar: indekslenmiş sayfalar ve indekslenmemiş sayfalar. Asıl değer indekslenmemiş grubundadır, çünkü her satır size sayfanın neden dışarıda kaldığını söyleyen bir sebep etiketi taşır. Bu, site genelindeki kalıpları görmenizi sağlar: tek bir sayfa değil, yüzlerce sayfa aynı sebeple dışarıda kalıyorsa orada yapısal bir sorun vardır. URL İnceleme tekil teşhis için, Sayfalar raporu ise toplu kalıp tespiti içindir; ikisi birbirini tamamlar.

Raporu okurken doğru refleks, en yüksek sayıya sahip "indekslenmemiş" satırından başlamaktır. Çünkü 3 sayfanın "noindex" ile dışarıda kalması çoğu zaman bilinçli bir tercihtir; ama 1.200 sayfanın "Kanonik alternatif" olarak işaretlenmesi büyük olasılıkla bir yapılandırma hatasıdır ve önce onu çözmek en yüksek getiriyi sağlar. Raporda en sık karşılaşılan sebep kategorileri ve anlamları şunlardır:

Bu sebepleri "kasıtlı" ve "kazara" diye ikiye ayırmak teşhisi hızlandırır. Bazı sayfaların index dışında olması doğrudur ve düzeltilmesi gereken bir hata değildir: filtre/sıralama parametreli e-ticaret URL'leri, sepet ve ödeme sayfaları, etiket arşivleri, dahili arama sonuç sayfaları, yönetim ekranları. Bunların "Kanonik alternatif", "noindex" veya "yönlendirme" sebebiyle dışarıda kalması beklenir. Buna karşılık ana ürün/kategori sayfalarınızın, blog yazılarınızın veya hizmet sayfalarınızın bu listede görünmesi gerçek bir alarmdır. Bu yüzden raporu okurken her satırı "bu sayfa zaten index'te olmamalı mıydı?" sorusuyla süzmek gerekir; aksi halde normal davranışı hata sanıp gereksiz müdahale edersiniz.

Burada sık yapılan bir hatayı vurgulamak gerekir: bir sayfayı index dışında tutmak için robots.txt kullanmak yanlıştır. robots.txt tarama kontrolü içindir, indekslemeyi garantili engellemez; engellenen bir URL başka bir yerden link aldığında Google onu yine de indeksleyebilir (genellikle açıklamasız, çıplak bir başlıkla). Bir sayfayı index dışında bırakmanın doğru yolu noindex etiketidir; üstelik Google'ın noindex'i görebilmesi için o sayfanın robots.txt ile engellenmemiş olması gerekir. Engelliyse Googlebot sayfaya hiç giremez ve noindex talimatını okuyamaz, böylece amacınızın tam tersi gerçekleşir. Bu kombinasyon hatası (hem robots.txt engeli hem noindex) sahada en sık gördüğümüz "neden hâlâ index'te" vakalarının başında gelir. Bu inceliği teknik SEO denetimi sürecinizde mutlaka kontrol edin.

Bir başka kritik nokta sitemap hijyenidir. XML sitemap'inize yalnızca indekslenebilir, kanonik URL'leri koymalısınız; noindex'li, yönlendirilen veya yinelenen URL'leri sitemap'e koymak Google'a çelişkili sinyaller gönderir. Sitemap yalnızca HTTPS sürümlerini içermeli ve her zaman kanonik adresi göstermelidir. Sitemap'i Search Console'un "Sitemap'ler" bölümünden gönderir ve durumunu buradan izlersiniz; "Başarılı" durumu Google'ın dosyayı okuyabildiği anlamına gelir, içindeki her URL'nin indekslendiği anlamına gelmez (bunu Sayfalar raporundan ayrıca takip edin). Deneyimimizde "yeni sayfalar Google'da görünmüyor" şikâyetlerinin kök nedeni çoğu zaman sitemap'in hiç gönderilmemiş olmasıdır; dolayısıyla yeni bir bölüm yayına aldığınızda ilk işiniz sitemap'i gönderdiğinizden emin olmaktır. İndeksleme mantığının site genelindeki yansımalarını topical authority ve içerik kümesi yaklaşımıyla birlikte ele almak, hangi sayfaların öncelikli indekslenmesi gerektiğini netleştirir; iç linkleme ağı zayıf olan derin sayfalar "Keşfedildi - indekslenmedi" kuyruğunda en uzun bekleyenlerdir.

Core Web Vitals Raporu Neyi Ölçer?

Search Console içindeki Core Web Vitals raporu, sitenizin performansını gerçek kullanıcı verisiyle (CrUX — Chrome User Experience Report) değerlendirir. Bu, laboratuvar testlerinden farklıdır: Lighthouse veya PageSpeed Insights'ın laboratuvar skoru tek bir simüle edilmiş yüklemeyi gösterirken, Search Console'daki rapor sitenizi gerçekten ziyaret eden kullanıcıların yaşadığı deneyimi yansıtır. Aradaki fark pratikte büyük olabilir: hızlı bir cihaz ve bağlantıyla yapılan laboratuvar testi "yeşil" çıkarken, gerçek kullanıcılarınızın çoğu orta segment telefon ve mobil veri kullanıyorsa CrUX verisi "Zayıf" gösterebilir. Rapor, benzer sayfaları URL gruplarında toplar ve her grubu İyi, Geliştirilmeli veya Zayıf olarak sınıflandırır. Mobil ve masaüstü için ayrı raporlar sunar; mobil-öncelikli indeksleme çağında mobil raporu önceliklendirmeniz beklenir.

CrUX'un bir başka önemli özelliği yeterli veri gerektirmesidir: yeterli trafiği olmayan sayfalar/gruplar raporda görünmeyebilir. Yani düşük trafikli yeni bir sayfanın Core Web Vitals durumunu Search Console'da göremeyebilirsiniz; bu durumda tekil laboratuvar analizi (PageSpeed Insights/Lighthouse) tek seçeneğinizdir. Ayrıca rapor verisi gecikmelidir; CrUX 28 günlük kayan bir pencereye dayandığı için bir düzeltmenin yeşile dönmesi haftalar alabilir. Bu yüzden bir iyileştirmeden hemen sonra rapora bakıp "değişmedi" demek yanıltıcıdır; laboratuvar aracında düzelmeyi doğrulayıp ardından alan verisinin yetişmesini beklemek doğru yaklaşımdır.

Raporun değerlendirdiği üç metrik ve güncel "İyi" eşikleri (75. persentilde) şunlardır:

Burada güncel kalmak için önemli bir uyarı var: INP, 12 Mart 2024 itibarıyla FID'in (First Input Delay) yerini almış resmî bir Core Web Vital'dir. FID artık kullanımdan kaldırılmıştır; internette hâlâ dolaşan "FID Core Web Vital'dir" bilgisi eskidir ve yazılarınızda bunu tekrarlamak güncellik açısından hata olur. Aradaki fark pratiktir: FID yalnızca ilk etkileşimin gecikmesini ölçüyordu, INP ise sayfanın tüm oturum boyunca her etkileşime verdiği yanıt hızını kapsar (girdi gecikmesi, işleme süresi ve sunum gecikmesinin tamamı). Mantığı şudur: kullanıcılar zamanlarının büyük çoğunluğunu sayfa yüklendikten sonra geçirir, dolayısıyla yalnızca ilk tıklamayı ölçmek yetersizdir. INP için aralıklar şöyledir: 200 ms ve altı İyi, 201-500 ms arası Geliştirilmeli, 500 ms üzeri Zayıf.

Bu üç metriğin tipik tetikleyicileri farklıdır; raporda hangisinin kötü çıktığı, nereye bakacağınızı doğrudan söyler. LCP genellikle ağır hero görselleri, yavaş sunucu yanıtı (TTFB) veya geç yüklenen yazı tipleriyle bozulur. CLS, boyutu belirtilmemiş görsel/reklam alanları, sonradan tepeden enjekte edilen banner'lar veya web fontu yüklenirken kayan metinle kötüleşir. INP ise ağır JavaScript'in ana iş parçacığını (main thread) uzun süre meşgul etmesiyle yükselir; üçüncü taraf etiketler, büyük analitik/etkileşim script'leri ve gereğinden ağır bileşenler en sık suçlulardır. Yani INP probleminin çözümü "görseli küçültmek" değil, çoğu zaman JavaScript'i hafifletmek, bölmek veya ertelemektir.

Core Web Vitals'ı doğru konumlandırmak gerekir. Bu metrikler sıralama için bir bonus puan değil, bir hijyen/eşik faktörüdür; içerik alakası ve kalitesi her zaman önceliklidir. Google bu ölçümlere resmî olarak belirli bir ağırlık atamaz, dolayısıyla "Core Web Vitals'ı yeşile çevirince üst sıralara çıkarım" beklentisi yanlıştır. Pratikte bu metrikler, eşit kalitedeki iki sayfa arasında bir ayrım kriteri gibi davranır ve kötü performans kullanıcı deneyimini doğrudan bozarak (terk oranını artırarak) dolaylı zarar verir. Search Console raporu hangi URL gruplarının sorunlu olduğunu söyler; ama sorunu nasıl çözeceğinizi adım adım site hızı ve Core Web Vitals rehberi yazımızda anlatıyoruz. Tekil bir sayfanın laboratuvar analizini yapmak ve somut iyileştirme önerileri almak içinse PageSpeed Insights nedir, nasıl iyileştirilir yazımız tamamlayıcı kaynaktır. İki aracı birlikte kullanmak en sağlıklısıdır: PageSpeed Insights ile tek sayfayı laboratuvar koşullarında teşhis eder, Search Console raporuyla site genelindeki gerçek kullanıcı kalıbını izlersiniz.

Mobil Kullanılabilirlik ve Diğer Geliştirme Raporları

Search Console'un "Geliştirmeler" bölümü, performansın ötesinde sayfa deneyimi ve yapısal veriyle ilgili raporları toplar. Mobil uyumluluk, mobil-öncelikli indekslemenin tamamen tamamlandığı bir dünyada artık opsiyonel bir özellik değil, temel bir gerekliliktir; sayfanız mobilde düzgün görünmüyor, metni okunmuyor veya dokunma hedefleri çok yakınsa bu hem kullanıcı deneyimini hem indekslemeyi etkiler. Mobil sürümde masaüstüyle aynı ana içeriğin, başlıkların, iç linklerin ve yapısal verinin bulunması bu yüzden kritiktir. Buradaki klasik tuzak, masaüstü için zengin bir sayfa hazırlayıp mobilde performans uğruna içeriğin bir kısmını hiç yüklememektir; Google artık akıllı telefon Googlebot'unun gördüğüyle çalıştığı için, mobilde yüklenmeyen içerik sıralama için de yok sayılır.

"Geliştirmeler" altında ayrıca desteklenen yapısal veri tipleri için hata ve uyarı raporları çıkar. Burada güncel bir gerçeği bilmek gerekir: FAQ (SSS) rich result raporu 2026 içinde kaldırılıyor. Google, FAQPage zengin sonucunu Ağustos 2023'te yalnızca otoriter devlet ve sağlık siteleriyle sınırlamıştı; 2026'da ise desteği tamamen sonlandırıyor (Search Console API'deki FAQ desteği 2026 içinde kalkıyor). Dolayısıyla "FAQ schema eklersem Search Console'da açılır SSS zengin sonucu raporu görürüm ve aramada çıkar" beklentisi artık geçerli değildir. Aynı durum HowTo rich result için de geçerlidir; o da kaldırılmıştır. Bu schema tipleri zarar vermez ve içeriğin yapısal anlaşılırlığı (özellikle AI motorları açısından) için değerli olabilir, ama görsel zengin sonuç beklemeyin; içeriğinizi soru-cevap yapısında kurgulamanın asıl getirisi artık zengin sonuç değil, hem okunabilirlik hem de AI yanıt motorlarınca alıntılanabilirliktir.

Buna karşılık bazı yapısal veri tipleri 2026'da hâlâ görsel zengin sonuç üretmeye devam ediyor; "Geliştirmeler" altındaki ilgili raporlar bu tipler için anlamlıdır. Hangi tipin hâlâ rich result verdiğini, hangisinin yalnızca anlamlandırma değeri taşıdığını ayırt etmek, çabanızı doğru yere yönlendirir:

Bu tablonun pratik sonucu nettir: e-ticaret yapıyorsanız enerjinizi Product ve BreadcrumbList işaretlemesinin Search Console'da hatasız görünmesine harcayın; yerel bir işletmeyseniz Organization/LocalBusiness'a; içerik yayıncısıysanız Article'a. FAQ/HowTo için harcanan eski "rich result avı" enerjisini artık içerik kalitesine ve doğru kurgulanmış şemaya yönlendirin. Bunların doğru kurgusunu schema markup rehberimizde, hatasız doğrulamayı ise Rich Results Test ve Schema Markup Validator araçlarıyla yapabilirsiniz.

Bu raporları bir bütün olarak değerlendirdiğinizde Search Console, sitenizin teknik sağlık panosu haline gelir: İndeksleme raporu hangi sayfaların Google'a girdiğini, URL İnceleme tekil sorunların kök nedenini, Core Web Vitals gerçek performans deneyimini, Geliştirmeler ise yapısal veri ve mobil uyumluluğu gösterir. Bu panoyu düzenli (örneğin haftalık) okumayı bir alışkanlığa dönüştürmek, sorunları büyümeden yakalamanın en ucuz yoludur; bir indeksleme düşüşü veya Core Web Vitals gerilemesi haftalar sonra fark edilirse trafik kaybı çoktan gerçekleşmiş olur. Tüm bu teknik teşhis ve iyileştirme sürecini sizin adınıza kurgulamamızı isterseniz dijital pazarlama danışmanlığı hizmetimiz veya hızlı bir başlangıç için ücretsiz analiz sayfamız üzerinden bizimle çalışabilirsiniz.

GSC Verisini Aksiyona Nasıl Çevirirsiniz?

Google Search Console verisini aksiyona çevirmek, raporlarda gördüğünüz tıklama, gösterim, ortalama pozisyon ve TO (tıklama oranı) metriklerini somut içerik ve teknik kararlara dönüştürmek demektir. Veriyi izlemek tek başına sıralama getirmez; asıl değer, GSC'nin gösterdiği gerçek arama davranışına bakıp "hangi sayfayı güncelleyeceğim, hangi sorgu için yeni içerik üreteceğim, hangi teknik sorunu çözeceğim" sorularına net cevap vermenizdedir. Müşterilerimizde sürekli gördüğümüz şu: GSC'yi açıp grafiğe bakan çok, o veriden bir görev listesi çıkaran az. Bu bölümde, ham metriği işe yarar bir aksiyona dönüştürmenin pratik yollarını ve sık yapılan hataları ele alıyoruz.

GSC'nin en güçlü yanı, size gerçekten aldığınız aramaları göstermesidir; tahmin değil, kendi verinizdir. Üçüncü taraf araçlar hacim ve zorluk için tahmin üretirken, GSC tam olarak hangi sorguda kaç gösterim ve tıklama aldığınızı, ortalama hangi pozisyonda göründüğünüzü söyler. Bu yüzden anahtar kelime çalışmalarınızda GSC'yi merkeze almanızı öneririz. Konuyu sıfırdan kurmak isterseniz anahtar kelime araştırması rehberimiz GSC verisini diğer araçlarla nasıl birleştireceğinizi anlatıyor; bütünsel bir bakış için de SEO nedir, nasıl yapılır rehberimize göz atabilirsiniz.

Pratikte işleyen bir disiplin, GSC verisini düzenli bir ritimle okumaktır. Önerdiğimiz çerçeve şudur: veriyi haftalık değil, anlamlı bir pencerede (örneğin son 3 ay, mümkünse önceki 3 ayla karşılaştırmalı) okuyun; çünkü tek bir günün veya haftanın dalgalanması karar almak için fazla gürültülüdür. GSC verisinin yaklaşık iki günlük bir gecikmeyle geldiğini ve sorgu listesinde gizlilik nedeniyle çok düşük hacimli (anonimleştirilen) sorguların gösterilmediğini de unutmayın; bu yüzden tıklama toplamı ile sorgu satırlarının toplamı her zaman birebir tutmaz. Bu sınırları bilmek, veriyi doğru ölçekte yorumlamanızı sağlar.

Performans Raporundan İçerik Görevleri Nasıl Çıkar?

Performans raporu dört temel metrik verir: Tıklama, Gösterim, TO ve Ortalama Pozisyon. Bu dördünü birlikte okuduğunuzda, somut içerik görevleri kendiliğinden ortaya çıkar. Tek bir metriğe bakmak yanıltır; örneğin yalnız tıklamaya bakarsanız, gösterimi yüksek ama tıklanmayan büyük bir fırsat kütlesini gözden kaçırırsınız. İşte müşteri projelerinde tekrar tekrar uyguladığımız desenler:

• Yüksek gösterim, düşük TO: Sayfa görünüyor ama tıklanmıyor. Bu genellikle başlık ve meta açıklamasının arama amacını yansıtmaması demektir. Önce başlık etiketini ve açıklamayı gözden geçirin; başa en önemli kelimeyi koyun, açıklamayı tıklatıcı yazın. Başlığı 50-60 karakter bandında, açıklamayı 150-160 karakter civarında tutmak iyi bir başlangıçtır; Google başlık ve açıklamaları sık yeniden yazsa da, sorgu niyetiyle birebir örtüşen, net bir başlık yeniden yazılma olasılığını düşürür. Meta title ve description nasıl yazılır yazımız bu işin kalıbını veriyor; hızlıca taslak üretmek için meta title-description oluşturucu aracımızı kullanabilirsiniz.
• Ortalama pozisyon 8-20 arası: İkinci sayfanın eşiğindeki sorgular, en yüksek getirili fırsatlardır. Bu sayfalar zaten alakalı bulunuyor; içeriği derinleştirmek, eksik alt başlıkları eklemek ve iç linkle desteklemek çoğu zaman onları ilk sayfaya taşır. Pozisyonu filtreleyip 8-20 bandındaki sorguları bir liste hâline getirin; bu, somut bir güncelleme kuyruğudur. Pratik bir ipucu: bu bandı yalnız pozisyona göre değil, gösterime göre de sıralayın; çünkü 11. sırada olup ayda binlerce gösterim alan bir sorgu, 9. sırada olup yüz gösterim alan bir sorgudan çok daha değerli bir güncelleme adayıdır.
• Tek sayfaya gelen çok sayıda farklı sorgu: Sayfayı tıklayıp "Sorgular" sekmesine geçtiğinizde, bir sayfanın aslında onlarca alt konuya hizmet ettiğini görürsünüz. Bunlardan bazıları o sayfada yarım kalmış, kendi başlarına ayrı birer yazıyı hak eden konulardır. Bu, içerik kümenizi (cluster) genişletmenin en sağlam verisidir. Ayrıca tersini de yakalarsınız: aynı veya çok benzer sorgu için iki ayrı sayfanız gösterim alıyorsa, muhtemelen kendi içeriğinizle yarışıyorsunuz (anahtar kelime yamyamlığı); bu durumda iki sayfayı birleştirmek ya da birini açıkça farklı bir niyete konumlandırmak gerekir.
• Pozisyon 1-3 ama TO beklenenin altında: Üst sıradasınız ama AI Overviews ya da öne çıkan bir kutu tıklamayı yutuyor olabilir. 2026 Haziran itibarıyla AI özetleri çoğu sorguda üstte konumlandığı için, üst sırada olmak eski getiriyi vermeyebilir. Üçüncü taraf çalışmalar, AI özeti göründüğünde üst sıradaki sayfanın tıklama oranında ciddi bir düşüş (yaklaşık olarak ve çalışmaya göre değişen oranlarda) raporluyor; bunlar Google'ın resmî rakamları değildir, eğilim olarak okuyun. Burada hedef, içeriği doğrudan yanıt verecek biçimde yapılandırmak ve marka bilinirliğiyle tıklamayı geri kazanmaktır.
• Düşen sorgular ("decay"): Önceki dönemle karşılaştırma açıp tıklaması en çok gerileyen sorguları işaretleyin. Çoğu zaman bu, içeriğin tazeliğini yitirmesi ya da bir rakibin sizi geçmesidir. Eskimiş tarih, ölçü ve örnekleri güncellemek, çoğu durumda yeni içerik üretmekten daha hızlı geri dönüş sağlar.

Bu desenleri bir kez kavradığınızda, GSC artık bir grafik değil, haftalık görev üreten bir motor olur. Pozisyon 8-20 bandını her ay tarayıp güncelleme yapmak, yeni içerik üretmekten çoğu zaman daha hızlı sonuç verir; çünkü Google sayfanızı zaten ilgili bulmuş, yalnızca son bir itme bekliyordur.

Sorgu Verisini Arama Amacına Göre Okumak

GSC'deki her sorgu bir niyet taşır ve bu niyeti doğru okumak aksiyonun yönünü belirler. Aynı sayfaya gelen sorguları bilgilendirici, ticari ve işlemsel olarak ayırdığınızda, içeriğin nereye evrileceği netleşir. "Nasıl", "nedir", "neden" içeren sorgular bilgilendirici amaçlıdır ve içeriğin öğretici kısmını besler; "en iyi", "karşılaştırma", "vs", "yorum" gibi sorgular ticari araştırma niyetini gösterir ve karşılaştırma tabloları, artı-eksi listeleri ile karşılanır; "fiyat", "satın al", "sipariş" gibi sorgular ise işlemsel niyettir ve dönüşüm odaklı bir bölüm gerektirir. Dördüncü bir grup olan navigasyonel sorgular (genelde marka adınızı içerenler) ise zaten size ulaşmak isteyen kullanıcılardır; bunlarda yüksek TO normaldir ve bunları geniş bilgilendirici sorgularla aynı kefeye koyup "TO düşük" diye paniklememek gerekir.

Pratikte bunu hızlandırmak için sorgu listesini niyet kelimeleriyle filtreleyebilirsiniz. GSC'nin sorgu filtresine "nasıl", "nedir" gibi kalıpları girip kaç gösterim ve tıklama geldiğini görmek, içeriğin hangi niyete daha güçlü hizmet ettiğini saniyeler içinde gösterir. Aşağıdaki tablo, bu eşleştirmeyi pratik bir karara bağlar:

Müşterilerimizde gördüğümüz yaygın bir kayıp şudur: bilgilendirici bir yazıya işlemsel sorgular gelir ama sayfada satın alma yolu yoktur; ya da tersine, ticari niyetli sorguya yalnızca kuru bir tanım sunulur. GSC sorgu listesi bu uyumsuzluğu açıkça gösterir. Sorguların büyük bölümü hâlâ bilgilendirici amaçlıdır; bu içerik huninin üstünü besler, ticari ve işlemsel bölümler dönüşümü yakalar. Bilgilendirici trafiğin yüksek olması kötü değildir; asıl mesele, o trafiği aynı sayfa içinde bir sonraki adıma (karşılaştırma, teklif, iletişim) yumuşakça taşıyabilmektir. Arama amacını içeriğe yerleştirme mantığını derinleştirmek için SEO uyumlu içerik nasıl yazılır ve on-page SEO rehberlerimizden faydalanabilirsiniz.

İndeksleme ve Teknik Sinyalleri Aksiyona Çevirmek

GSC'nin İndeksleme (Sayfalar/Coverage) ve URL İnceleme raporları, içerik kadar kritik teknik görevler üretir. Burada temel ayrım şudur: bir sayfanın "indekslenmemiş" olması ile "sıralanmamış" olması farklı şeylerdir. Google üç aşamada çalışır; tarama (Googlebot sayfayı keşfedip indirir), indeksleme (içerik işlenip Google index'ine kaydedilir) ve sıralama (sorguya en uygun sonuçlar dizilir). Sayfa indekste yoksa hiç sıralanamaz; indekste ama sırada değilse sorun içerik alakası veya kalitesindedir. GSC bu ikisini ayırt etmenizi sağlar: URL İnceleme aracı bir URL'in indexli olup olmadığını, son taranma zamanını, Google'ın seçtiği kanonik URL'yi ve render sonucunu gösterir.

İndeksleme raporunda gördüğünüz tipik durumları aksiyona şöyle çevirin:

Burada sık karışan iki kavramı netleştirelim. Bir sayfayı indeksten çıkarmak için robots.txt değil, "noindex" meta etiketi (ya da HTTP başlığı) kullanılır; üstelik Google'ın noindex'i görebilmesi için o sayfa robots.txt ile engellenmemiş olmalıdır, aksi hâlde Googlebot sayfayı tarayamaz ve noindex hiç okunamaz. robots.txt'in görevi taramayı kontrol etmektir, indekslemeyi garantili engellemez; engellenen bir URL başka yerden linklenirse yine indexlenebilir. Ayrıca render için gerekli CSS/JS kaynaklarını robots.txt ile engellememeye dikkat edin; mobil-öncelikli indeksleme 2024 ortasında tüm siteler için varsayılan olduğundan, Googlebot sitenizi akıllı telefon olarak görür ve mobil sürümde aynı ana içerik, başlıklar ve iç linkler bulunmalıdır.

Yeni veya güncellenmiş bir sayfayı hızla taratmak isterseniz URL İnceleme aracındaki "İndekslenmeyi iste" işlevini kullanın; ama bunu toplu indeksleme aracı gibi düşünmeyin. Bu işlev tek bir URL için manuel tarama tetikler ve indekslemeyi garanti etmez, yalnızca sıraya alır. Toplu keşif ve indeksleme için doğru araç, sağlam bir XML sitemap ve güçlü bir iç linkleme yapısıdır. Teknik tarafı sistematik denetlemek için teknik SEO denetimi rehberimizi takip edebilirsiniz.

Bir diğer kritik veri kaynağı GSC içindeki Core Web Vitals raporudur. Bu rapor, CrUX gerçek kullanıcı verisiyle URL gruplarını İyi, Geliştirilmeli ve Zayıf olarak sınıflar; mobil ve masaüstü ayrıdır. Hedef eşikler nettir: LCP (Largest Contentful Paint) en fazla 2,5 saniye, INP (Interaction to Next Paint) en fazla 200 milisaniye, CLS (Cumulative Layout Shift) en fazla 0,1. Bu değerler 75. persentil için "İyi" eşiğidir; yani kullanıcılarınızın en az dörtte üçünün bu deneyimi yaşaması hedeflenir. Burada önemli bir hataya değinelim; 12 Mart 2024'ten beri etkileşim metriği FID (First Input Delay) değil, INP'tir. INP yalnız ilk etkileşimi değil, sayfanın tüm oturum boyunca kullanıcı etkileşimlerine yanıt hızını ölçer; eski yazılarda hâlâ FID geçiyor olabilir ama GSC artık INP'i raporlar. "Zayıf" gruplanan URL'leri alıp performans iyileştirmesi yapmak, GSC'nin size sunduğu en somut teknik görev listelerinden biridir. Şu noktayı da unutmayın: Core Web Vitals'ı "iyi" kılmak bir sıralama bonusu değil, bir hijyen/eşik faktörüdür; içerik alakası ve kalitesi her zaman önceliklidir, ama eşit kalitedeki iki sayfa arasında hız fark yaratabilir. Bu raporu derinlemesine okumak için site hızı ve Core Web Vitals rehberimize ve uygulamalı iyileştirme için PageSpeed Insights yazımıza bakabilirsiniz.

GSC Kullanırken Sık Yapılan Hatalar

Yıllardır onlarca projede GSC kullanırken aynı hataların tekrar ettiğini görüyoruz. Bunları bilmek, veriyi yanlış yorumlayıp yanlış aksiyon almanın önüne geçer:

• Sitemap'i GSC'ye hiç göndermemek: "Yeni sayfalarım Google'da görünmüyor" şikayetinin en sık kök nedeni, XML sitemap'in Search Console'a hiç gönderilmemiş olmasıdır. Sitemap'ler bölümünden gönderin; sitemap yalnızca indekslenebilir, kanonik URL'ler içermeli, noindex ve yönlendirme hedeflerini koymayın, hepsi HTTPS olmalı. Gönderdikten sonra "okundu" durumunu ve algılanan URL sayısını takip edin; sıfır kalıyorsa sitemap'in adresi ya da biçimi hatalıdır.
• Yanlış mülk türünü (property) kurmak: GSC'de "URL ön eki" ve "Alan adı (Domain)" mülkleri farklı veri kapsar. Sadece "https://www..." ön ekli mülk kurarsanız, http, www'siz veya alt alan adlarından gelen trafiği kaçırabilirsiniz. Tüm varyantları tek yerde görmek için, doğrulayabiliyorsanız Alan adı mülkü kurmak çoğu işletme için daha sağlıklıdır.
• Ortalama pozisyonu mutlak gerçek sanmak: Ortalama pozisyon, farklı sorgu, cihaz, ülke ve kişiselleştirmenin ortalamasıdır; tek bir gerçek sıra değildir. Sorgu ve sayfa bazında filtrelemeden "pozisyonum düştü" demek yanıltıcıdır. Bazen yeni bir sorguda alt sıralarda görünmeye başlamak ortalama pozisyonu düşürür, ama bu aslında genişleme demektir. Her zaman filtreleyerek, segment bazında okuyun.
• TO'yu bağlamsız değerlendirmek: Düşük TO her zaman kötü değildir. Marka sorgularında TO yüksek, geniş bilgilendirici sorgularda doğal olarak düşüktür. Ayrıca üst sırada olup AI Overviews nedeniyle TO düşmesi sizin hatanız olmayabilir. TO'yu daima sorgunun niyetiyle birlikte okuyun.
• "İndekslenmeyi iste"yi toplu araç sanmak: Bu işlev tek tek URL'ler için manuel tarama tetikler; yüzlerce sayfayı buradan göndermeye çalışmak doğru yöntem değildir, üstelik günlük bir kotası vardır. Toplu keşif için sağlam bir sitemap ve iç linkleme yapısına güvenin.
• Veri gecikmesini ve örneklemeyi unutmak: GSC verisi yaklaşık iki günlük gecikmeyle gelir; "bugünkü" performansa bakıp acele karar almak yanıltır. Ayrıca çok düşük hacimli sorgular gizlilik için listede gösterilmez; bu yüzden sorgu satırlarının toplamı, sayfanın toplam tıklamasını her zaman tutmaz. Bu normaldir, eksik veri değildir.
• FAQ ve HowTo zengin sonucu beklemek: GSC'nin Geliştirmeler raporlarında FAQ tipi hâlâ görünebilse de, FAQ zengin sonucu Ağustos 2023'ten beri neredeyse hiçbir sıradan işletme/e-ticaret sitesi için gösterilmiyor (yalnızca otoriter devlet ve sağlık siteleriyle sınırlandı) ve 2026'da tamamen kaldırılıyor; HowTo zengin sonucu da daha önce kaldırıldı. Bu schema'ları hâlâ ekleyebilirsiniz, çünkü içeriği anlaşılır kılar ve AI motorlarına yardımcı olur, ama görsel zengin sonuç (açılır sorular) beklemeyin. Hangi schema tiplerinin hâlâ zengin sonuç verdiğini (Article, Product, BreadcrumbList, LocalBusiness gibi) yapısal veri ve schema markup rehberimizde bulabilirsiniz.
• FID'e göre optimize etmeye çalışmak: Eski rehberlerin etkisiyle hâlâ "FID Core Web Vital'dir" denildiğini görüyoruz. Bu yanlıştır; FID kullanımdan kaldırıldı, yerini INP aldı. GSC'nin raporladığı metrik INP'tir ve hedef 200 milisaniye altıdır. Optimizasyonu doğru metriğe yapın.
• Veriyi izleyip aksiyon almamak: En yaygın hata budur. GSC'yi haftada bir açıp grafiğe bakmak değil, ondan görev listesi çıkarmak gerekir. Pozisyon 8-20 bandı, düşük TO sayfaları ve "Zayıf" CWV grupları; bunlar her ay tekrarlanan üç somut görev kuyruğudur.

GSC Verisini Stratejiye Bağlamak

GSC'den çıkardığınız tekil görevleri daha büyük bir resme bağladığınızda etkisi katlanır. Sorgu verisinden ortaya çıkan alt konuları rastgele yazılar olarak değil, bir içerik kümesi olarak ele alın; her küme yazısı ana pillar sayfaya, pillar da kümelere iç linkle bağlansın. Bu çift yönlü ağ, konu otoritenizi (topical authority) ve taranabilirliği güçlendirir. GSC'nin sorgu raporu, kümenizdeki eksik başlıkları bulmanın en güvenilir yoludur; rakip analizine girmeden, kendi verinizden içerik boşluğu (content gap) çıkarırsınız. Örneğin bir pillar sayfaya gelen onlarca farklı sorguyu listelediğinizde, hangi alt konuların yarım kaldığını ve hangilerinin kendi başına bir cluster yazısını hak ettiğini doğrudan görürsünüz. Bu mantığı kurmak için topical authority ve içerik kümesi rehberimizi öneririz.

GSC verisini stratejiye bağlarken pratik bir aylık ritim kurmanızı öneririz: ayın başında önceki 3 ayı bir önceki dönemle karşılaştırın, pozisyon 8-20 bandını ve gerileyen sorguları işaretleyin, düşük TO yüksek gösterimli sayfaların başlık-açıklamasını yenileyin, "Zayıf" CWV gruplarını teknik kuyruğa alın ve indeksleme raporundaki yeni hataları kapatın. Bu beş adım, GSC'yi pasif bir gösterge panosundan haftalık görev üreten bir motora dönüştürür. Tüm bu adımların E-E-A-T çerçevesiyle örtüştüğünü unutmayın; güncel, doğru ve gerçekten yardımcı içerik üretmek, Google'ın çekirdek sistemlerinin ödüllendirdiği yaklaşımdır ve manipülatif kısa yollardan uzun vadede daha güçlüdür.

Son olarak, GSC verisini düzenli okumak ve aksiyona çevirmek zaman ve uzmanlık ister; çoğu işletme için asıl darboğaz veri eksikliği değil, o veriyi sürekli işe çevirecek disiplindir. Bu süreci kurumsal bir düzene oturtmak isterseniz, Kayseri merkezli ekibimizin dijital pazarlama danışmanlığı hizmetiyle GSC verinizi haftalık görev kuyruklarına dönüştürebiliriz. Sitenizin mevcut durumunu görmek için ücretsiz analiz sayfamızdan başlayabilir, böylece GSC'nin gösterdiği fırsatları net bir yol haritasına çevirebilirsiniz.