Search Console 1000 Satır Sınırı Nasıl Aşılır? Tüm Veriyi Alın

Biz Talha Aslan ve ekibi olarak bu soruyu en çok büyüyen e-ticaret sitelerinden ve çok sayfalı içerik projelerinden duyuyoruz. Çünkü bir noktadan sonra raporda gördüğünüz sorgular sitenizin gerçek arama tablosunun yalnızca bir kesiti olur. Bu rehberde önce sınırın tam olarak neyi kestiğini anlatacağız. Ardından her yöntemi adım adım kuracak, sonunda da hangi siteye hangisinin uygun olduğunu bir tabloyla özetleyeceğiz. Kod bloğu vermiyoruz; mantığı ve kurulum sırasını anlatıyoruz.

Search Console'un genel kullanımına yeniyseniz önce Google Search Console nedir ve nasıl kullanılır yazımıza göz atmanızı öneririz. Bu yazı, rapor ekranını tanıdığınızı varsayarak ilerliyor.

Search Console 1000 satır sınırı Performans raporunda neyi kısıtlıyor?

Performans raporu (Performance report) üst kısımda bir grafik, altta da sorgu, sayfa, ülke, cihaz gibi sekmelerden oluşan bir tablo gösterir. Tablo en fazla 1.000 satır listeler. Yani sitenizde 40.000 farklı sorgu gösterim almış olsa bile, ekranda yalnızca bunların bir kısmını görürsünüz.

Google'ın rapordan doğrudan dışa aktarma yardım sayfası bu durumu açıkça yazıyor: Google indirilen veriyi, verinizin temsili örneklerinden oluşan 1.000 satıra kırpar. Ayrıca sayfa, küçük sitelerin verisinin çoğunu ya da tamamını alabileceğini, büyük sitelerin ise genellikle yalnızca bir örnek alacağını belirtiyor.

Burada önemli bir ayrıntı var. Sınır grafiği değil, tabloyu etkiler. Dolayısıyla toplam tıklama ve toplam gösterim grafiği sitenizin genel eğilimini doğru gösterir. Ancak "hangi sorgu, hangi sayfa" sorusuna verilen cevap 1.000 satırla sınırlıdır. Uzun kuyruk sorguların büyük kısmı tam olarak bu kesilen bölgede kalır.

• Grafik: toplam eğilimi doğru gösterir.
• Tablo: en fazla 1.000 satır, tıklamaya göre üstteki satırlar.
• Dışa aktarma: tablo ile aynı sınır, Google E-Tablolar, Excel ve CSV biçiminde.

Dışa aktardığınız dosyada toplamlar neden tablodan farklı görünüyor?

Bu soru, dosyayı ilk kez açan neredeyse herkesin aklına gelir. Dosyadaki 1.000 satırın tıklamalarını topladığınızda, raporun üstündeki toplam tıklama sayısına ulaşamazsınız. Bunun nedeni basittir: toplam, kesilen satırları da içerir.

Google'ın yardım sayfasına göre dışa aktarılan dosyadaki toplamlar, satır sınırını hesaba katmayan gerçek toplamlardır. Öte yandan tablo satırları yalnızca ekrandaki kısmı temsil eder. Bu yüzden iki sayıyı karşılaştırarak "eksik veri" oranınız hakkında kabaca fikir edinebilirsiniz.

Örnek senaryo: example.com sitesinin dışa aktarımında toplam tıklama 10.000 görünüyor, 1.000 satırın toplamı ise 7.000 ediyor. Yani tıklamaların yaklaşık üçte biri tablonuzda görünmeyen sorgulardan ya da anonim sorgulardan geliyor. Bu bir örnek hesaptır; sizin oranınız sitenizin yapısına göre değişir.

Ayrıca raporda "~" ya da "-" olarak görünen değerler indirilen dosyada sıfıra dönüşür. Bu nedenle dosyada sıfır gördüğünüz her hücreyi gerçek bir sıfır gibi yorumlamayın. Özellikle ortalama konum sütununda bu sıfırlar ortalamanızı yanlış yöne çekebilir.

Eksik kalan payın bir kısmı ise hiçbir dışa aktarma yöntemiyle geri gelmez. Bunun nedenini Search Console sorguları neden eksik yazımızda ayrıntılı anlattık; aşağıda da kısaca değineceğiz.

Hangi siteler Search Console 1000 satır sınırına takılır?

Küçük bir kurumsal sitenin ayda gösterim aldığı farklı sorgu sayısı çoğu zaman birkaç yüzü geçmez. Böyle bir sitede tablo zaten verinin tamamına yakınını gösterir. Dolayısıyla her site için ek kurulum gerekmez.

Sınır şu durumlarda gerçek bir sorun hâline gelir:

• Binlerce ürün ya da kategori sayfası olan e-ticaret siteleri.
• Yüzlerce blog yazısı yayınlamış içerik siteleri ve haber siteleri.
• Birden çok dilde ya da birden çok ülkede yayın yapan siteler.
• Uzun kuyruk sorgulardan trafik alan yerel hizmet ve rehber siteleri.
• 16 aydan daha uzun bir geçmişi saklamak isteyen her site.

Son madde gözden kaçar. Performans raporu en fazla 16 aylık veri gösterir. Bu nedenle iki yıl önceki sezonla bugünü karşılaştırmak istiyorsanız, veriyi bugünden itibaren düzenli olarak dışarıda saklamanız gerekir. Yani sorun yalnızca satır sayısı değil, zamanla kaybolan geçmiştir.

Örnek senaryo: example.com 3.000 ürünlü bir mağaza olsun. Ürün sayfaları tek tek az tıklama alıyor. Tablonun ilk 1.000 satırı marka sorguları ve kategori sorgularıyla doluyor. Sonuç olarak ürün düzeyindeki fırsatlar raporda hiç görünmüyor. Bu tablo bize sınırın neden stratejik bir kör nokta olduğunu gösteriyor.

Arayüzde filtreyle dilimleme sınırı ne kadar aşar?

Kurulum yapmadan önce akla gelen ilk yöntem, raporu filtrelerle dilimlemektir. Her filtre yeni bir 1.000 satırlık pencere açar. Örneğin önce yalnızca /urunler/ ile başlayan sayfaları, sonra /blog/ ile başlayanları filtreleyebilirsiniz. Böylece her bölüm için ayrı 1.000 satır alırsınız.

Dilimlemek için kullanabileceğiniz başlıca boyutlar şunlardır:

1. Tarih: tek bir ay yerine haftalık ya da günlük aralıklar seçin.
2. Sayfa: URL içeren ya da belirli bir dizinle başlayan filtreler kullanın.
3. Ülke: hedef pazarlarınızı ayrı ayrı indirin.
4. Cihaz: masaüstü, mobil ve tableti ayırın.
5. Sorgu: marka sorgularını hariç tutan bir filtre ekleyin.

Ancak bu yöntemin ciddi sınırları var. Dilimleri birleştirdiğinizde aynı sorgu birden çok dosyada tekrar edebilir. Ayrıca her dosyayı elle indirmek zaman alır ve hata riskini artırır. Bu nedenle dilimlemeyi tek seferlik bir inceleme için kullanın, düzenli raporlama için kullanmayın.

Marka ve marka dışı sorguları ayırmak için düzenli ifade (regex) filtresi işinizi çok kolaylaştırır. Bunun kurulumunu Search Console'da marka ve marka dışı sorgu ayrımı rehberimizde gösterdik.

Search Console API 1.000 satırdan fazlasını nasıl verir?

Search Console API, Performans raporundaki veriyi programla sorgulamanızı sağlar. Arama Analizi (Search Analytics) sorgusunda satır sınırı parametresi varsayılan olarak 1.000'dir. Ancak Google'ın geliştirici belgelerine göre bu değeri tek istekte 25.000'e kadar yükseltebilirsiniz.

Daha fazlası için başlangıç satırı (startRow) parametresiyle sayfalama yaparsınız. Yani ilk istekte ilk 25.000 satırı, ikinci istekte sonraki 25.000 satırı istersiniz. Boş yanıt geldiğinde verinin sonuna ulaşmışsınız demektir.

Bununla birlikte API'nin de bir tavanı var. Google'ın tüm verinizi alma rehberi, API'nin her arama türü için günde en fazla 50.000 satır veri sunduğunu belirtiyor. API bu satırları tıklamaya göre sıralar. Dolayısıyla çok büyük sitelerde API bile her şeyi vermez; yine de arayüze göre çok daha geniş bir pencere açar.

Belgeler bir noktayı daha vurguluyor: API tüm satırları döndürmeyi garanti etmez, en üstteki satırları döndürür. Bu nedenle API verisini "sitenin tam listesi" olarak değil, "en geniş örnek" olarak yorumlayın. Güncel sınır değerlerini her zaman resmi belgeden kontrol edin, çünkü Google bu değerleri değiştirebilir.

Ayrıca API her arama türünü ayrı sayar. Web, görsel, video ve haber verisini ayrı ayrı sorgulamanız gerekir. Böylece görsel aramadan gelen trafiği web aramasıyla karıştırmadan incelersiniz.

API'de sayfalama ve günlük sorgulama nasıl kurgulanmalı?

Google'ın önerisi nettir: her gün, yalnızca bir günlük veri için sorgu çalıştırın. Bu yaklaşım hem günlük satır tavanını verimli kullanır hem de kotanızı aşmanızı önler. Örneğin bir aylık veriyi tek seferde istemek yerine otuz ayrı günlük sorgu çalıştırırsınız.

Kurguyu şu sırayla planlamanızı öneriyoruz:

1. Hangi boyutlara ihtiyacınız olduğunu belirleyin: tarih, sorgu, sayfa, ülke, cihaz.
2. Arama türlerini seçin; her biri için ayrı sorgu çalıştıracaksınız.
3. Tarih aralığını tek bir gün olarak ayarlayın.
4. Satır sınırını 25.000 yapın ve başlangıç satırını sıfırdan başlatın.
5. Yanıt dolu geldikçe başlangıç satırını 25.000 artırarak tekrar isteyin.
6. Boş yanıt gelince o günü kapatın ve sonucu kendi tablonuza yazın.
7. Ertesi gün aynı işlemi bir sonraki tarih için tekrarlayın.

Bir de zamanlama konusu var. Belgelere göre veri genellikle iki ila üç gün sonra hazır hâle gelir. Ayrıca API varsayılan olarak yalnızca kesinleşmiş veriyi döndürür. Taze veriyi de istemek için veri durumu (dataState) parametresini "all" yapabilirsiniz; ancak bu günlerin değerleri sonradan değişebilir.

Bu nedenle otomatik akışınızda son birkaç günü birkaç gün sonra yeniden çekip üzerine yazmanızı öneririz. Böylece kesinleşmemiş rakamlar raporunuzda kalıcı hata yaratmaz. Veri gecikmesiyle ilgili ayrıntıları Search Console veriler işleniyor uyarısı yazımızda bulabilirsiniz.

API kotası ve "pahalı sorgu" sizi nasıl etkiler?

Search Console API ücretsizdir, ama sınırsız değildir. Google, site başına, kullanıcı başına ve proje başına istek sınırları uygular. Ayrıca kısa vadeli ve uzun vadeli yük sınırları vardır. Güncel değerleri resmi kullanım sınırları sayfasından kontrol etmenizi öneriyoruz.

Asıl dikkat etmeniz gereken konu "pahalı sorgu" kavramıdır. Google'ın belgelerine göre sayfaya ya da sorgu metnine göre gruplama veya filtreleme yaptığınızda sorgu pahalılaşır. Hem sayfa hem sorgu boyutunu birlikte istediğinizde ise sorgu en pahalı hâlini alır. Üstelik tarih aralığını uzattıkça yük de artar.

Belgeler bu tür sorgularda sistemin hesaplamayı yönetilebilir tutmak için bazı verileri düşürebileceğini de belirtiyor. Yani sayfa ve sorguyu birlikte istediğiniz bir tabloda, toplamlar sitenizin genel toplamından daha düşük çıkabilir. Bu bir hata değil, sistemin bilinen davranışıdır.

Pratikte şu dengeyi kurabilirsiniz:

• Genel eğilim için yalnızca tarih ve cihaz gibi hafif boyutları kullanın.
• Sorgu listesi için sayfa boyutunu eklemeden ayrı bir sorgu çalıştırın.
• Sayfa ile sorgu eşleşmesine yalnızca gerçekten ihtiyaç duyduğunuz analizlerde başvurun.

Örneğin bir anahtar kelime yamyamlığı incelemesi, sayfa ve sorgu eşleşmesini zorunlu kılar. Bu analizin mantığını keyword cannibalization nedir yazımızda anlattık.

Kod yazmadan Search Console verisine nasıl ulaşırsınız?

Her işletmenin bir geliştiricisi yoktur ve bu gayet normaldir. API'yi doğrudan kullanmadan da 1.000 satırın ötesine geçebilirsiniz. Bunun iki yaygın yolu var.

İlk yol, Google E-Tablolar için geliştirici firmaların sunduğu üçüncü taraf eklentilerdir. Bu eklentiler arka planda aynı API'yi kullanır ve sonucu doğrudan bir tabloya yazar. Ancak her eklenti farklı izinler ister. Bu nedenle kurmadan önce hangi verilere erişim istediğini dikkatle okuyun. Belirli bir eklentiyi önermiyoruz; geliştiricisi tanınan ve izinleri net olanı seçin.

İkinci yol, Google'ın kendi Looker Studio bağlayıcısıdır. Bu yöntem herhangi bir eklenti gerektirmez. Ayrıca veriyi bir pano içinde görsel olarak sunar. Bir sonraki bölümde bu bağlayıcıyı ayrıntılı anlatıyoruz.

Öte yandan kod yazmadan çalışan yöntemlerin de bir sınırı var. Hepsi sonuçta API'nin tavanına tabidir. Yani günlük satır tavanı ve anonim sorgu kaybı bu yöntemlerde de geçerlidir. Dolayısıyla "eklenti kurdum, artık her şeyi görüyorum" düşüncesi yanıltıcıdır.

Kısacası küçük ve orta ölçekli bir site için kod yazmadan çalışan yöntemler genellikle yeterlidir. Ancak veri hacminiz büyüdükçe toplu dışa aktarıma geçmeyi düşünmeniz gerekir.

Looker Studio bağlayıcısı Search Console 1000 satır sınırını aşar mı?

Evet, aşar. Looker Studio'daki Search Console bağlayıcısı veriyi API üzerinden çeker. Bu nedenle tablolarınızda 1.000 satırdan çok daha fazlasını görebilirsiniz. Google'ın Search Central blogundaki açıklamaya göre bağlayıcının da tavanı API ile aynıdır: site ve arama türü başına günlük 50.000 satır.

Bağlantıyı kurmak için resmi yardım sayfasındaki sırayı izleyebilirsiniz:

1. Looker Studio'ya Search Console'da kullandığınız Google hesabıyla giriş yapın.
2. Yeni bir veri kaynağı oluşturun ve Search Console bağlayıcısını seçin.
3. İstenirse erişim izni verin.
4. Mülkünüzü seçin.
5. Tablo türünü belirleyin: Site Impression ya da URL Impression.
6. Arama türünü seçin ve bağlanın.

Google'ın Looker Studio Search Console bağlantı belgesine göre mülkte en az görüntüleme izniniz olmalıdır. Ayrıca belge, gizlilik nedeniyle bazı nadir sorguların boş değerli tek bir satırda toplanabileceğini söylüyor. Bu satırı sorgu alanında boş değerleri hariç tutan bir filtreyle temizleyebilirsiniz.

Bağlayıcının bir avantajı daha var: veri paylaşımı. Sahibin kimlik bilgileriyle kurulan bir rapor, başka kişilerin kendi Search Console erişimi olmadan da raporu görmesini sağlar. Ancak bu ayarı kimle paylaştığınıza dikkat edin, çünkü raporu gören herkes sorgu verinizi de görür.

Site Impression ile URL Impression arasındaki fark nedir?

Bu iki seçenek, Search Console'un performans verisini toplamak için kullandığı iki farklı yöntemdir. Site Impression mülk düzeyinde toplar. URL Impression ise veriyi sayfa düzeyinde toplar. Bu fark rakamlarınızı doğrudan değiştirir.

Mülk düzeyinde toplamada aynı arama sonucunda sitenizden iki sayfa görünse bile sistem tek bir gösterim sayar. Sayfa düzeyinde ise her sayfa kendi gösterimini alır. Dolayısıyla URL Impression tablosundaki gösterim toplamı genellikle daha yüksek çıkar. Ortalama konum değeri de iki tabloda farklı çıkar.

Bir veri kaynağı yalnızca bir yöntemi kullanabilir. Bu nedenle ikisini yan yana görmek istiyorsanız iki ayrı veri kaynağı oluşturup aynı rapora eklemeniz gerekir. Örneğin üst bölümde genel eğilimi Site Impression ile, alt bölümde sayfa analizini URL Impression ile gösterebilirsiniz.

Mülk türünün de rakamları etkilediğini unutmayın. Alan adı mülkü ile URL ön eki mülkü arasındaki farkı alan adı mülkü mü, URL ön eki mi yazımızda anlattık.

Toplu veri dışa aktarımı (BigQuery bulk export) nedir?

Toplu veri dışa aktarımı (bulk data export), Search Console performans verinizin her gün otomatik olarak Google BigQuery'ye aktarılmasıdır. BigQuery, Google Cloud'un büyük veri tablolarını sorgulamaya yarayan veri ambarıdır. Bu yöntem, Search Console'un sunduğu en kapsamlı veri yoludur.

Google'ın yardım sayfasına göre bu dışa aktarımda mülkünüz için Search Console'da bulunan tüm performans verisini görürsünüz; tek istisna anonim sorgulardır. Yani API'deki günlük satır tavanı burada geçerli değildir. Uzun kuyruk sorguların tamamına yakını tablolarınıza düşer.

Bununla birlikte bu yöntemin üç önemli özelliği var:

• Geçmişe dönük veri getirmez. Dışa aktarım, kurulum gününden itibaren çalışır.
• Bir Google Cloud projesi ve faturalandırma hesabı gerektirir.
• Veriyi okumak için SQL bilgisi ya da BigQuery'ye bağlanan bir raporlama aracı gerekir.

İlk madde en kritik olanıdır. Bugün kurmazsanız, bugünün verisi BigQuery'de hiçbir zaman olmayacak. Kurulumdan önceki dönem için API'yi ya da raporları kullanmanız gerekir. Bu nedenle büyük bir siteyi yönetiyorsanız kurulumu ertelememenizi öneriyoruz.

Öte yandan kurulumu bir kez yaparsınız ve dışa aktarım sonra her gün kendiliğinden çalışır. Böylece 16 aylık geçmiş sınırı da sizin için ortadan kalkar; veriyi istediğiniz kadar saklarsınız.

BigQuery toplu dışa aktarımını adım adım nasıl kurarsınız?

Kurulumu iki tarafta yaparsınız: önce Google Cloud, sonra Search Console. Google'ın yeni toplu dışa aktarım başlatma sayfasındaki sırayı özetliyoruz:

1. Faturalandırması etkin ve BigQuery'nin açık olduğu bir Google Cloud projesi hazırlayın.
2. Proje kimliğini (project ID) not edin; proje numarasını değil.
3. API ve hizmetler bölümünde BigQuery API ile BigQuery Storage API'nin etkin olduğunu kontrol edin.
4. IAM bölümünde search-console-data-export@system.gserviceaccount.com hizmet hesabını yetkili olarak ekleyin.
5. Bu hesaba BigQuery Job User ve BigQuery Data Editor rollerini verin.
6. Search Console'da mülkünüzün Ayarlar bölümünde toplu veri dışa aktarma (Bulk data export) seçeneğini açın.
7. Proje kimliğini, veri kümesi adını ve veri kümesi konumunu girin.
8. Onaylayıp devam edin.

Veri kümesi adı varsayılan olarak searchconsole olur ve bu ifadeyle başlamak zorundadır. Konum seçimine ise özellikle dikkat edin. Yardım sayfası, dışa aktarım başladıktan sonra konumu değiştirmenin zor olduğunu belirtiyor.

Google'a göre ilk dışa aktarım, başarılı kurulumdan sonraki 48 saat içinde gerçekleşir. Bu sürede tabloların boş görünmesi normaldir. Ayrıca tablo yapısını (şema) değiştirmeyin; yardım sayfası bunun dışa aktarımın başarısız olmasına yol açtığını söylüyor.

BigQuery'de hangi tablolar oluşur ve nasıl okunmalı?

Dışa aktarım, seçtiğiniz veri kümesinde üç tablo oluşturur. Google'ın tablo rehberi ve başvuru sayfası bunları şöyle tanımlıyor:

• searchdata_site_impression: mülk düzeyinde toplanmış performans verisi.
• searchdata_url_impression: URL düzeyinde toplanmış performans verisi.
• ExportLog: her başarılı dışa aktarımın kaydı. Sistem başarısız denemeleri bu tabloya yazmaz.

Gördüğünüz gibi ilk iki tablo, Looker Studio'daki Site Impression ve URL Impression ayrımıyla aynı mantığı izler. Dolayısıyla genel eğilim için site tablosunu, sayfa analizi için URL tablosunu kullanırsınız.

Tabloları okurken üç kurala dikkat edin. Birincisi, tarih alanı (data_date) Pasifik saatine göredir. İkincisi, aynı anahtarlara sahip satırlar tekrar edebilir; çünkü Search Console veriyi kademeli olarak biriktirir. Bu yüzden metrikleri sorgularınızda neredeyse her zaman toplamanız gerekir.

Üçüncüsü ortalama konumdur. Tablolarda hazır bir ortalama konum sütunu yoktur. Bunun yerine sıfırdan başlayan konum toplamı bulunur. Ortalama konumu, bu toplamı gösterim toplamına bölüp bir ekleyerek hesaplarsınız. Bu ayrıntıyı atlarsanız tüm konum değerleriniz bir sıra yukarıda görünür.

Ayrıca ExportLog tablosunu düzenli kontrol edin. Bir gün eksikse, o günün dışa aktarımı büyük olasılıkla başarısız olmuştur. Böylece raporunuzdaki ani düşüşün gerçek bir trafik kaybı mı yoksa veri boşluğu mu olduğunu ayırt edersiniz.

BigQuery maliyetini nasıl kontrol altında tutarsınız?

BigQuery'nin belirli bir ücretsiz kullanım katmanı var. Bu katmanı aşan depolama ve sorgu kullanımını ise Google faturanıza ekler. Güncel ücretsiz katman ve fiyatları Google Cloud'un resmi fiyat sayfasından kontrol edin; bu değerler zamanla değişebilir.

Maliyeti büyüten iki unsur var: biriken depolama ve özensiz sorgular. Toplu dışa aktarım varsayılan olarak veriyi süresiz saklar. Bu nedenle uzun vadede depolama büyür. Ancak asıl maliyet çoğu zaman gereksiz geniş sorgulardan gelir.

Maliyeti kontrol etmek için şu adımları öneriyoruz:

1. Tablo yerine bölüm (partition) için son kullanma süresi tanımlayın.
2. Sorgularınızda her zaman tarih aralığı filtresi kullanın.
3. Yalnızca ihtiyacınız olan sütunları seçin.
4. Google Cloud'da bütçe uyarısı oluşturun.
5. Panolarınızı ham tablo yerine özet tablolara bağlayın.

İlk madde hayati önemdedir. Google'ın tablo rehberine göre tablo düzeyinde son kullanma süresi tüm verinizi siler. Bölüm düzeyinde süre ise yalnızca eski günleri temizler. Kurulum sayfası da bölüm süresini en az 14 gün olarak ayarlamanızı öneriyor.

Örnek senaryo: example.com yalnızca son 12 ayı analiz ediyor. Bu durumda bölüm süresini 12 aya ayarlamak depolamayı sınırlar. Öte yandan çok yıllı sezon karşılaştırması yapıyorsanız süre tanımlamayın ve yalnızca sorgu disiplinine odaklanın.

Hangi siteye hangi yöntem uygun?

Dört yöntemi tek tabloda karşılaştırdık. Satırları kendi sitenizin büyüklüğüne ve ekibinizin teknik kapasitesine göre okuyun.

Tablodaki tavan değerleri resmi belgelere dayanır, ancak Google bu değerleri değiştirebilir. Bu nedenle kurulumdan önce güncel değerleri ilgili yardım sayfasından doğrulayın.

Pratikte bu yöntemler birbirini dışlamaz. Örneğin birçok proje için en verimli kurgu, BigQuery dışa aktarımını hemen açmak ve kurulum öncesi dönemi API ile doldurmaktır. Böylece hem geçmişi hem geleceği kapsayan tek bir veri tabanınız olur.

Anonim sorgular hangi yöntemde olursa olsun neden eksik kalır?

Hiçbir dışa aktarım yöntemi anonim sorguları geri getirmez. Google, kullanıcı gizliliğini korumak için çok az kişinin yaptığı sorguları raporlarda göstermez. Bu durum arayüz, API, Looker Studio ve BigQuery için aynıdır.

BigQuery tablolarında bu satırlar kaybolmaz, ama sorgu metni boş kalır. Tablo rehberine göre bu satırlarda anonim sorgu alanı doğru değerini alır ve sorgu alanı boş kalır. Yani bu trafiğin varlığını ve hacmini görürsünüz, ancak hangi kelimeden geldiğini göremezsiniz.

Bu bilgi analizinizi iki şekilde etkiler. Birincisi, sorgu düzeyindeki toplamlar her zaman site toplamından düşük kalır. İkincisi, uzun kuyruk ağırlıklı sitelerde bu boşluk daha büyüktür. Dolayısıyla "toplu dışa aktarım açtım, artık her şey tam" beklentisi de doğru değildir.

Peki ne yapabilirsiniz? Anonim payı ayrı bir satır olarak izleyin. Bu pay zaman içinde hızla büyüyorsa, sitenizin çok dağınık ve düşük hacimli sorgulardan trafik aldığını gösterir. Bu da içerik stratejiniz için kendi başına anlamlı bir sinyaldir.

Ayrıca Discover verisinde benzer bir anonimleştirme alanı bulunur. Bu alan doğru olduğunda URL ve ülke gibi bilgiler eksik kalabilir. Bu nedenle Discover analizlerinde de toplamlara temkinli yaklaşın.

Tam veriyle hangi SEO analizlerini yapabilirsiniz?

Veriyi 1.000 satırın ötesine taşımanın amacı daha büyük bir dosya değil, daha iyi karardır. Tam veriye ulaştığınızda arayüzde imkânsız olan analizler mümkün hâle gelir.

• Uzun kuyruk fırsat analizi: çok gösterim alan ama tıklaması düşük sorguları sayfa bazında bulursunuz.
• Yamyamlık tespiti: aynı sorguda birbirinin yerine geçen sayfaları görürsünüz.
• İçerik eskimesi takibi: aylar içinde yavaşça trafik kaybeden yazıları erkenden yakalarsınız.
• Kategori ve dizin performansı: URL yapısına göre bölüm bölüm büyümeyi ölçersiniz.
• Çok yıllı sezon karşılaştırması: 16 aylık sınırın ötesine geçen eğilimleri görürsünüz.
• Ülke ve cihaz kırılımı: hedef pazarlarınızdaki gerçek talebi ayrıştırırsınız.

Örneğin içerik eskimesi analizi, aylar boyunca sayfa bazında veri saklamayı gerektirir. Bu analizin adımlarını content decay nedir yazımızda anlattık. Ayrıca Search Console'un yeni özet ekranı hızlı bir ilk bakış sunar; onu Search Console Insights nedir yazımızda inceledik.

Kısacası tam veri, sorunun cevabını değil, doğru soruyu sormanızı sağlar. Analizi yapan kişinin sitenizi, sektörünüzü ve hedeflerinizi tanıması bu yüzden hâlâ belirleyicidir.

Search Console verisini dışa aktarırken sık yapılan hatalar nelerdir?

Sahada en sık gördüğümüz hatalar teknik değil, yorumlama hatalarıdır. Veri doğru gelse bile yanlış okunduğunda yanlış karar aldırır.

1. Dışa aktarılan 1.000 satırı sitenin tamamı sanmak.
2. Site Impression ile URL Impression rakamlarını aynı tabloda karıştırmak.
3. BigQuery'de tekrar eden satırları toplamadan okumak.
4. Ortalama konumu hesaplarken bir eklemeyi unutmak.
5. Tabloya son kullanma süresi tanımlayıp tüm veriyi kaybetmek.
6. Kesinleşmemiş son günleri kalıcı veri gibi raporlamak.
7. Toplu dışa aktarımı "sonra açarız" diye ertelemek.

Son hata en pahalı olanıdır, çünkü geri dönüşü yoktur. Toplu dışa aktarım geçmişe dönük çalışmadığı için ertelenen her gün kalıcı olarak kaybolur. Ancak API ile son 16 ayı yine de kurtarabilirsiniz; bu yüzden geç kalmış olmanız tamamen çaresiz olduğunuz anlamına gelmez.

Bir başka sık hata da yetki yönetimidir. Looker Studio raporunu sahibin kimlik bilgileriyle kurup herkese açık bağlantıyla paylaşmak, sorgu verinizi istemediğiniz kişilere açabilir. Bu nedenle paylaşım ayarlarını düzenli olarak gözden geçirin.

Bu kurulumu sitenizde kim yapar ve sonuçları kim takip eder?

Teknik kurulum birkaç saatlik bir iş gibi görünebilir. Ancak asıl değer, verinin her ay doğru okunmasından ve aksiyona dönüşmesinden gelir. Biz bu süreci SEO danışmanlığı hizmetimiz kapsamında uçtan uca ele alıyoruz.

Çalışmaya genellikle sitenizin veri ihtiyacını ölçerek başlıyoruz. Ardından uygun yöntemi seçiyor, gerekiyorsa BigQuery dışa aktarımını ve geçmiş veri doldurmayı kuruyoruz. Sonra da bu veriden düzenli bir rapor ve öncelik sırasına dizdiğimiz bir iş listesi çıkarıyoruz. Örneğin hangi sayfanın güncelleneceğine ve hangi sorgu için yeni içerik gerektiğine bu listeyle karar veriyoruz.

Şunu açıkça belirtelim: hiçbir veri kurulumu sıralama garantisi vermez. Doğru veri, doğru kararı kolaylaştırır; sonucu ise içerik, teknik altyapı ve rekabet birlikte belirler. Bu yüzden size abartılı vaatler yerine ölçülebilir bir çalışma planı sunuyoruz.

Sitenizde Search Console verisinin yetersiz kaldığını düşünüyorsanız, SEO danışmanlığı sayfamızdan teklif isteyebilirsiniz. Sitenizin yapısına göre hangi yöntemin uygun olduğunu ve kapsamı teklifte netleştiriyoruz.

Temel rehber: Dijital Pazarlama Nedir? Türleri, örnekleri ve nasıl yapıldığı, beynin içinden geçen etkileşimli bir filmle tek sayfada.