Search Console Verisini 16 Ay Ötesinde Saklama Rehberi

Search Console, organik görünürlüğün birinci elden kaynağıdır; ancak geçmişi sınırsız değildir. Google, arama trafiği düşüşlerini inceleme yazısında Performans raporunun tarih aralığını 16 aya çıkarmayı önerir ve bu süreyi uzatmak isteyenlere Search Analytics API ile veriyi çekip kendi sistemlerinde saklamalarını söyler. Yani 16 ayın ötesi, siz bir şey yapmadıkça elinizde olmayacak bir geçmiştir. Bu bilgiyi Google'ın arama trafiği düşüşleri yazısında (yeni sekmede açılır) görebilirsiniz.

Bu rehber, verinin arşivlenmesini üç soru üzerinden ele alır: hangi yöntem hangi derinlikte veri verir, kurulum ve kota sınırları nelerdir, arşivi kim ve ne kadar süre kullanabilir? Anlatım SEO analistleri, ajanslar ve veri mühendisleri için yazıldı. Raporu okumayı zaten biliyorsanız, arayüzdeki sorgu ve sayfa görünümlerini anlatan Search Console Performans raporu rehberiyle birlikte okumak iyi bir başlangıçtır.

Dar Pencere Neden Pahalıya Patlar?

Geçmiş veri, ancak ihtiyaç duyduğunuz gün değerini gösterir. Bir trafik düşüşü, bir tasarım yenilemesi ya da bir yıl önceki kampanya hakkında soru geldiğinde, cevabı veren veri çoğu zaman pencerenin dışına düşmüş olur. Verinin sonradan yeniden üretilememesi, arşivlemeyi ilk aydan itibaren bir altyapı kararı hâline getirir.

Yıllık karşılaştırmanın yarım kalması

Mevsimsel işlerde en kritik karşılaştırma, bu ayı geçen yılın aynı ayıyla kıyaslamaktır. Bunun için bir yıl geriye gitmeniz gerekir; 16 aylık pencere bu işi yalnızca dört aylık bir tamponla görür. Aylar ilerledikçe tampon eriyor, bir önceki yılın üstünde ikinci bir yıl karşılaştırması ise hiç mümkün olmuyor. Bu, aritmetik bir sonuçtur: iki yıllık trend görmek isteyen ekip, daha en baştan arşive ihtiyaç duyar.

Büyük olayların öncesini kaybetmek

Alan adı taşıma, URL yapısı değişikliği ya da bir algoritma güncellemesi sonrasında "önceki dönem" ölçütü gerekir. Olay yaşandıktan on dört ay sonra analiz yapmak isterseniz, olay öncesi taban çizgisi pencerenin dışında kalmış olabilir. Tabanı kaybetmek, etkiyi ölçmek yerine tahmin etmeye mecbur bırakır.

Kurgusal örnek: ikinci kış sezonu

Kurgusal bir senaryo düşünelim: Bir çevrimiçi mağaza, kış koleksiyonu için hazırladığı kategori sayfalarını ikinci sezonda yeniden yazıyor. Yöneticiler, ilk sezonda hangi sorguların hangi sayfalara tıklama taşıdığını görmek istiyor. Ekip arşiv tutmadıysa ilk sezonun sorgu düzeyindeki verisi arayüzden silinmiş olacak; geriye yalnızca birkaç ekran görüntüsü ve hatırlananlar kalacak. Arşivi baştan kuran bir ekip ise aynı soruyu tek bir sorguyla cevaplar. Hikâyenin dersi, beklemenin bedelidir.

Arşiv neyi çözmez?

Arşiv, ham performans verisini korur; yorumu, etiketlemeyi ve olay notlarını kendiliğinden üretmez. Tarihli bir değişiklik günlüğü tutmuyorsanız, birikmiş yıllarca günün neden değiştiğini açıklamak yine zor kalır. Arşivi bir not defteriyle eşleştirmek, saklamanın değerini birkaç kat artırır.

Üç Yol: Arayüz Dışa Aktarımı, API ve Toplu Dışa Aktarım

Search Console verisini dışarı almanın üç ana yolu vardır ve hiçbiri ötekinin tam yerine geçmez. Doğru seçim, geriye dönük veriye mi yoksa ileriye dönük süreklilik mi ihtiyaç duyduğunuza bağlıdır.

Arayüzdeki dışa aktarım

Google'ın "Search Console verisi hakkında" belgesine göre tablolar en fazla 1.000 satır gösterir ve bazı satırlar dışarıda kalabilir; Search Console API ise daha geniş bir seçki döndürebilir. Raporlardaki dışa aktarım düğmesi, küçük siteler ve anlık ihtiyaçlar için pratiktir. Belge ayrıca, raporda "~" veya "-" olarak görünen değerlerin dışa aktarımda sıfır olarak indirildiğini belirtir. Bu ayrıntı, sıfırı gerçek sıfır sanma hatasına karşı bir uyarıdır: Search Console verisi hakkında belgesi (yeni sekmede açılır) bu davranışı açıkça anlatır.

Search Analytics API

API, tarih aralığını siz belirlediğiniz için geriye dönük veri çekmenin tek yoludur: pencerenin içinde kalan günleri günlük tek tek alıp kendi deponuza yazarsınız. Sorgu başına en fazla 25.000 satır dönebilir ve daha fazlası için sayfalama gerekir. Bu sınırları bir sonraki bölümlerde ayrıntılı ele alacağız.

BigQuery toplu dışa aktarımı

Toplu dışa aktarım, Search Console'un performans verisini düzenli olarak sizin Google Cloud projenizdeki bir BigQuery veri kümesine yazar. En büyük avantajı, kurulduktan sonra bir daha dokunmanıza gerek kalmamasıdır. En büyük sınırı ise kurulumdan önceki günleri içermemesidir. Kurulum belgesine göre geçmiş veri için API ya da raporlar kullanılmalıdır.

Yöntemlere tek bakış

Pratikte güçlü bir düzen ikisini birleştirir: toplu dışa aktarımı hemen açıp ileriye dönük sürekliliği garanti altına almak, API ile de pencerede hâlâ duran geçmişi kurtarmak. Ayrıca aylık raporlama şablonunuz varsa, arşivi onun veri kaynağı yapmak mantıklıdır; şablon için aylık SEO raporu rehberine bakabilirsiniz.

Hangisini ne zaman seçmeli?

Kararı üç soruyla verebilirsiniz. Birincisi, sitenin yalnızca birkaç sayfası ve düşük hacmi varsa arayüz dışa aktarımı ve aylık bir not yeterli olabilir; ancak bu yol, ay içinde bir gün atlandığında geri döndürülemez bir boşluk bırakır. İkincisi, sorgu ve sayfa düzeyinde yıllarca SQL ile analiz yapmak istiyorsanız toplu dışa aktarım doğal tercihtir, çünkü veri zaten tarihe göre bölümlenmiş gelir. Üçüncüsü, başka bir veri ambarına ya da kendi şemanıza yazmak istiyorsanız API size tam kontrol verir. Çoğu ajans için gerçekçi yanıt, her müşteri mülkünde toplu dışa aktarımı açmak ve API'yi yalnızca geçmişi kurtarma betiği olarak kullanmaktır. Bunun nedeni basit: toplu dışa aktarımın bakım yükü, kurulumdan sonra neredeyse sıfıra yakındır.

Toplu Dışa Aktarımı Adım Adım Kurmak

Bu bölüm, Google'ın "Yeni bir toplu dışa aktarım başlatın" belgesindeki adımların uygulama sırasını ve sık atlanan noktaları özetler. Ayrıntılı ekran adları için toplu dışa aktarım kurulum belgesi (yeni sekmede açılır) esas alınmalıdır.

Ön koşullar

Bir Google Cloud projesi, açık faturalama ve etkinleştirilmiş BigQuery API ile BigQuery Storage API gerekir. Belge, ücretsiz bir kullanım düzeyi olduğunu, bunun üzerindeki depolama ve sorgu kullanımının ise ücretlendirildiğini söyler. Bu nedenle kurulumdan önce projeye bir bütçe uyarısı eklemek iyi bir alışkanlıktır; uyarı eşiğini bütçenize göre kendiniz belirlersiniz.

Servis hesabı ve roller

Google Cloud tarafında, search-console-data-export@system.gserviceaccount.com hesabına iki rol verilir: BigQuery Job User ve BigQuery Data Editor. Erişim incelemesi yaparken bu hesabı rastgele temizlenecek bir hesap gibi görmeyin; dışa aktarım Search Console'un bu hesap üzerinden projenize yazmasına dayanır. Yetkiyi değiştirmeden önce sorumluyu bilgilendirin.

Search Console tarafında kurulum

Search Console'da Ayarlar bölümünden Toplu veri dışa aktarımı seçilir ve proje kimliği girilir. Belge, proje numarası değil proje kimliği girilmesi gerektiğini özellikle vurgular. Veri kümesi adı varsayılan olarak "searchconsole" gelir ve bu dizeyle başlamak zorundadır.

Veri kümesi konumu

Konum seçimi, sonradan kolay değişmeyen bir karardır. Belge, dışa aktarımlar başladıktan sonra konumu kolayca değiştiremeyeceğinizi açıkça uyarır. Verinin hangi bölgede duracağını hukuk ve kurum politikalarınıza göre baştan seçin; sonradan taşımak ek iş demektir.

İlk aktarım ve geriye dönük veri

İlk dışa aktarım, başarılı yapılandırmadan sonra en geç 48 saat içinde gerçekleşir ve o günün verisini içerir. Kurulumdan önceki veriler dışa aktarıma dahil değildir. Bu, kurulumu "yarın yaparım" diye ertelemenin gerçek bir maliyeti olduğu anlamına gelir: her gün, geriye dönük kurtarılamayacak bir günü pencerenin dışına iter.

Şemaya dokunmayın

Belge, tablo şemasının değiştirilmemesi gerektiğini, aksi hâlde dışa aktarımın başarısız olacağını belirtir. Bu yüzden analistlerin kendi sütunlarını ya da hesaplanmış alanlarını bu tablolara eklemesini engelleyin; bunun yerine ayrı bir veri kümesinde görünüm ya da türetilmiş tablo oluşturun.

API ile Geriye Dönük Veri Çekme ve Kotalar

Toplu dışa aktarım geçmişi getirmediği için, pencerede hâlâ duran günleri kurtarmak API ile yapılır. Arşiv kalitesini belirleyen şey burada kullanacağınız sorgu desenidir.

Günlük sorgu deseni

Google'ın "Tüm verinizi alma" belgesi, tek günlük sorgular çalıştırmayı önerir: başlangıç ve bitiş tarihini aynı gün yaparsınız. Belgeye göre bir günlük sorgunun günlük kotayı aşmaması beklenir. Veri genellikle 2 ila 3 gün sonra hazır olur; en son uygun tarihi bulmak için son 10 günü tarihe göre gruplayan bir sorgu çalıştırabilirsiniz. Bu desen, tüm veriyi alma rehberinde (yeni sekmede açılır) adım adım anlatılır.

Satır sınırı ve sayfalama

Arama Analizi sorgu referansına (yeni sekmede açılır) göre rowLimit 1 ile 25.000 arasında olabilir ve varsayılan değeri 1.000'dir. Tüm satırları almak için aynı sorguyu, startRow değerini her seferinde 25.000 artırarak tekrarlar ve sıfır satır dönene kadar sürdürürsünüz. Satır sınırını gözden kaçıran bir betik, varsayılan 1.000 satırla sessizce eksik veri toplar. Betiğin ilk testi bu yüzden satır sayısını kontrol etmelidir.

Günlük 50 bin satır tavanı

Aynı belgeye göre API, arama türü başına günde en fazla 50 bin satır veri gösterir ve bu satırlar tıklamaya göre sıralanır. Üst sınırın dışında kalan satırlar dönmez. Sorgu belgesi de API'nin tüm satırları değil, en üsttekileri döndürmeyi garanti etmediğini söyler. Arşivde web, görsel ve video gibi her arama türünü ayrı çalıştırmak gerekir.

Boyut seçimi eksik veri üretebilir

Belge, sayfa ve sorgu boyutlarını dahil etmenin bazı verilerin düşmesine yol açabileceğini söyler; çünkü sistem sonucu makul sürede hesaplamak için veri atar. Doğru toplamlar için sayfa ve sorgu boyutları olmadan ayrı bir günlük toplam sorgusu da çalıştırıp arşivde sakladığınızda, ayrıntı sorgusuyla bir kontrol toplamı elde edersiniz. İki rakam arasındaki fark, sorgu düzeyinde ne kadar verinin eksik kaldığını gösteren ölçüdür.

Kesinleşmiş ve taze veri

Sorgu referansına göre dataState varsayılan olarak "final" değerindedir ve yalnızca kesinleşmiş veriyi döndürür. "all" taze veriyi de katar, "hourly_all" ise saatlik ve kısmi olabilen bir kırılım ekler. Arşiv için varsayılan değer genellikle daha güvenlidir: kısmi bir günü kalıcı saklarsanız, daha sonra değişebilecek bir rakamı sabitlemiş olursunuz. Tarihler Pasifik Saati'ne göre yorumlanır; zaman dilimi farkını yerel raporlarda ayrıca not etmek gerekir.

Kota sınırları

Google'ın kullanım sınırları sayfası, Search Analytics çağrıları için site başına dakikada 1.200, kullanıcı başına dakikada 1.200 sorgu sınırı tanımlar. Proje başına ise günde 30.000.000 ve dakikada 40.000 sorgu sınırı vardır. Kısa vadeli kota 10 dakikalık parçalarla, uzun vadeli yük ise 1 günlük dönemlerle ölçülür. Tek bir siteyi günlük çeken bir betik bu tavanlara yaklaşmaz; yüzlerce siteyi paralel çeken ajans betikleri ise yaklaşabilir. Ayrıntı için kullanım sınırları sayfasına (yeni sekmede açılır) bakın.

Tablo Şeması, Sorgu Alışkanlıkları ve Anonimleştirilmiş Sorgular

Veri BigQuery'ye düştüğünde asıl iş başlar: doğru toplayan sorgu yazmak ve eksik verinin nerede durduğunu bilmek.

Üç tablo

Google'ın tablo kılavuzuna göre toplu dışa aktarım searchconsole veri kümesinde üç tablo oluşturur: mülke göre toplanmış searchdata_site_impression, URL'ye göre toplanmış searchdata_url_impression ve ExportLog. Veri kümesi adını kurulumda değiştirebilirsiniz. Ayrıntılı alan listesi için tablo kılavuzu ve başvuru belgesi (yeni sekmede açılır) esas kaynaktır.

Önemli alanlar

• data_date: Satırın oluşturulduğu gün; Pasifik Saati'ne göre tutulur.
• search_type: web, image, video, news, discover ve googleNews gibi değerler alır.
• sum_top_position: Sıfır tabanlıdır; site tablosunda ortalama konum SUM(sum_top_position)/SUM(impressions) + 1 olarak hesaplanır.
• is_anonymized_query: Nadir sorguları işaretler; bayrak doğruyken sorgu alanı kullanıcı gizliliği için boştur.

Belge, anonimleştirilmiş sorgunun site tablosunda sıfır uzunlukta bir dize, başka bir yerde ise boş değer olarak anlatıldığını belirtir. Bu iki davranışı da sorgularınızda karşılayın ve kendi veriniz üzerinde hangisinin geçerli olduğunu kontrol edin.

Her zaman toplama yapın

Sorgu kılavuzuna göre tablolardaki veri tarih, URL ya da site anahtarlarına göre birleştirilmiş olmayabilir; aynı sorgu için birden fazla satır görebilirsiniz. Bu yüzden SUM ve COUNT gibi toplama işlevlerini her zaman kullanmalısınız. Kılavuzun "yanlış yol" örneği tek satır döndürüp sayıyı eksik gösterir, "doğru yol" ise toplamayı yapar. Sorgu kılavuzu (yeni sekmede açılır) bu farkı örnekle gösterir.

Anonimleştirilmiş sorguların payı

Aynı kılavuz, anonimleştirilmiş sorguların çoğu zaman bir sitenin en yaygın tek sorgusu olabildiğini söyler. Dolayısıyla "en çok sorgu" listesini sorgu metni boş olan satırları dışarıda bırakarak oluşturmalısınız; yoksa listenin tepesinde anlamsız bir boş satır görürsünüz. Toplam tıklama ve gösterim hesaplarında ise bu satırları tutun, çünkü toplamları arayüzle uyuşturan onlardır.

Satırları sınırlayan bir başka katman

Arayüz belgesi, nadir sorguların kullanıcı gizliliği için raporlardan çıkarıldığını da belirtir. Yani arşivinizin sorgu düzeyindeki toplamı, hiçbir yöntemde sitenin tüm gerçek sorgularının toplamı değildir. Rapora not düşün: "sorgu düzeyi veri, gizlilik filtrelemesinden geçmiş bir örneklemdir."

Basit yedek: aylık dışa aktarım ve tablo şeması

BigQuery kullanmayacak küçük ekipler için hafif bir düzen de yeterli olabilir: ayda bir kez önceki ayın verisini API ile çekip bir CSV dosyasına yazmak ve dosyayı sürümlenmiş bir depoda saklamak. Genel bir şema önerisi (Google'ın zorunluluğu değildir): tarih, arama türü, ülke, cihaz, sayfa, sorgu, tıklama, gösterim, konum toplamı ve çekim tarihi. Sorgu alanı boş kalabileceği için sütunu boşluğa izin veren tanımlayın; anonimleştirilmiş satırlar için ayrı bir işaret sütunu ekleyin. Dosya adını ay ve arama türüyle standartlaştırın ve her dosyanın yanında satır sayısını ve toplam tıklamayı kaydeden küçük bir özet tutun. Bu özet, ileride dosyanın bozulup bozulmadığını anlamanın en ucuz yoludur.

Saklama Süresi, Erişim Güvenliği ve Maliyet Disiplini

Arşiv, kurulduğu günden itibaren bir yönetim konusudur. Neyi ne kadar sakladığınız, kimin okuyabildiği ve ne kadara mal olduğu önceden kararlaştırılmalıdır.

BigQuery'de varsayılan: sonsuz saklama

Kurulum belgesine göre veri, siz bir son kullanma süresi belirlemedikçe projeniz için sonsuza kadar birikir. Tablo kılavuzu da tabloların ve bölümlerin varsayılan olarak sonsuza kadar tutulduğunu söyler. Bu, arşiv amacıyla kurulum yapanlar için iyi bir varsayılandır; ancak saklama politikanız belirli bir süreyle sınırlıysa bunu açıkça tanımlamak zorundasınız.

Süre sınırı koyacaksanız bölüm düzeyinde koyun

Belgeye göre tablolar oluştuktan sonra en az 14 günlük bölüm son kullanma süresi tanımlayabilirsiniz. Tablo kılavuzu ise tablonun tamamına son kullanma tarihi koymanın büyük olasılıkla istediğiniz şey olmadığını, çünkü bütün veriyi sileceğini vurgular. Doğru yaklaşım bölüm bazında sürelendirmektir. Bu ayrım, hatalı bir tek ayarın yıllarca birikmiş arşivi silmesini engeller.

Erişimi en az yetkiyle verin

Arşiv ham sorgu ve sayfa verisi içerir; müşteriye ait rekabet açısından hassas bilgi taşıyabilir. Aşağıdakiler Google belgesindeki kurallar değil, genel iyi uygulamadır: veri kümesi okuma yetkisini ekip rolleriyle sınırlayın, hizmet hesaplarını sahibi belli adlarla oluşturun, ajans-müşteri ilişkisinde veri kümesinin kimin projesinde duracağını sözleşmeye yazın ve sözleşme bittiğinde veriyi kimin alacağını baştan netleştirin.

Kişisel veri bakışı

Sorgu metni teorik olarak kişisel veri içerebilecek serbest metindir; kullanıcıların arama kutusuna yazdığı şeyler öngörülemez. Anonimleştirme, Google'ın bu riski azaltmak için uyguladığı bir önlemdir ve toplu dışa aktarımda bu sorgu metinleri boş gelir. Yine de arşivinizi başka sistemlerle birleştirmeden önce hukuk danışmanınızla saklama süresini ve amacı gözden geçirin.

Devir teslim ve belgeleme

Arşivler çoğu zaman onu kuran kişiden daha uzun yaşar. Proje kimliğini, veri kümesi adını ve konumunu, çekim betiğinin nerede çalıştığını ve hangi kimlik bilgisini kullandığını tek sayfalık bir belgede toplayın. Ajanslarda bu belge müşteriyle paylaşılan devir paketinin parçası olmalıdır; sözleşme bittiğinde veriyi kimin alacağı, nereye taşınacağı ve ne zaman silineceği yazılı olmalıdır.

Maliyeti kontrol altında tutun

Sorgu kılavuzu, BigQuery'de çalıştırılan her sorgunun ücretlendirileceğini ve tabloların büyüyebileceğini hatırlatır. Tablolar tarihe göre bölümlendiği için WHERE koşuluyla tarih aralığını sınırlamak, taranan veriyi ve dolayısıyla maliyeti düşürür. Pratik alışkanlıklar: "SELECT *" yerine gereken sütunları seçin, panel sorgularını tarih koşullu yazın ve sık kullanılan özetleri küçük türetilmiş tablolara aktarın. Güncel fiyatlandırma için Google Cloud'un resmi sayfasına bakın.

Başarısız dışa aktarım riski

ExportLog tablosu yalnızca başarılı dışa aktarımları kaydeder; başarısız denemeler orada görünmez. Tablo kılavuzu ayrıca epoch_version alanının, bir tablo ve tarih için önceden kaydedilmiş veri revize edildiğinde arttığını söyler. Dolayısıyla "son tarih geldi mi" sorusunu ExportLog üzerinden, "veri değişti mi" sorusunu ise epoch_version üzerinden izleyin.

Aylık Operasyon Listesi ve Yaygın Hatalar

Arşiv kurmak bir kerelik iştir, doğru çalıştığından emin olmak ise sürekli bir iş. Aşağıdaki liste, küçük bir ekibin ayda yarım saatte yürütebileceği bir düzendir. Rapor tarafında bu listeyi gösterim ve sorgu paneli rehberindeki panel mantığıyla birleştirirseniz, arşiv doğrudan görünürlük raporunuza akar.

Ay başı kontrol listesi

1. ExportLog tablosunda önceki ayın her günü için bir kayıt olduğunu doğrulayın.
2. Site tablosundaki aylık toplam tıklamayı, arayüzdeki aynı ay toplamıyla karşılaştırın; küçük farkları yazıya geçirin, büyükleri araştırın.
3. API çekim betiğinin son çalışma kaydına ve satır sayılarına bakın.
4. CSV yedeğini kullanıyorsanız özet dosyasındaki satır sayısı ve toplam tıklamayı yeniden hesaplayın.
5. Faturalama panelinde BigQuery depolama ve sorgu harcamasını inceleyin.
6. Erişim listesini gözden geçirip ayrılan kişilerin yetkisini kaldırın.

Yaygın hata: Kurulumu ertelemek

Toplu dışa aktarım geriye dönük veri getirmediği için her geciken gün kalıcı bir boşluktur. "Önce şemayı tasarlayayım" diye bekleyen ekipler, tasarım bittiğinde birkaç haftalık veriyi kaybetmiş olur. Önce açın, şemayı sonra düşünün; çünkü şemayı zaten Google belirler.

Yaygın hata: Tabloyu değiştirmek

Kendi sütununu ekleyen ya da tabloyu yeniden yapılandıran bir analist, şema değişikliklerinin dışa aktarımı bozacağı uyarısını tetikler. Türetilmiş tabloları ayrı veri kümesinde tutun.

Yaygın hata: Toplama yapmadan okumak

Sorgular aynı anahtar için birden fazla satır içerebildiğinden, toplamasız bir özet sayıyı eksik gösterir. Panelleri kuran kişi bu davranışı bilmiyorsa, arşiv rakamları arayüzle uyuşmadığı için tüm hat güvenilmez görünür.

Yaygın hata: Anonimleştirilmiş satırları tamamen silmek

Boş sorgulu satırları arşivden çıkarmak toplam tıklama ve gösterimi arayüzdeki rakamdan uzaklaştırır. Çözüm, silmek değil, sorgu listelerinde filtrelemek ve toplamlarda tutmaktır.

Yaygın hata: Zaman dilimini unutmak

Hem API hem tablolar Pasifik Saati'ne göre tarih verir. Türkiye saatine göre gün sınırı farklı olduğundan, günlük grafikleri yerel takvimle birebir eşleştirirken küçük kaymalar normaldir. Raporlarda "tarihler Pasifik Saati'ne göre" notu bulunmalıdır.

Yaygın hata: Ham veriyi tek başına karar sanmak

Arşiv, tarihsel kanıt sağlar; neden-sonuç ilişkisi kurmaz. Bir düşüşün nedenini bulmak için sitede yapılan değişiklik günlüğüyle birlikte okumak gerekir.

Sıkça Sorulan Sorular

Search Console verisi 16 ay sonra kendiliğinden başka bir yerde saklanır mı?

Hayır. Arayüzdeki geçmiş sınırlıdır ve Google, süreyi uzatmak isteyenlere Search Analytics API ile veriyi çekip kendi sistemlerinde saklamalarını önerir. Toplu dışa aktarım da yalnızca kurulduktan sonraki günleri biriktirir, geriye dönük veri getirmez. Bu yüzden saklama kararını ve başlangıç tarihini siz belirlersiniz.

Toplu dışa aktarım eski verimi BigQuery'ye taşır mı?

Taşımaz. Google'ın kurulum belgesine göre dışa aktarım kurulumdan önceki veriyi içermez; ilk aktarım yapılandırmadan sonra en geç 48 saat içinde gerçekleşir. Geçmişi kurtarmak için API çekimini ya da raporların dışa aktarımını kullanın ve bunu mümkün olan en erken günde başlatın.

API ile tüm sorgu satırlarını almak mümkün mü?

Her zaman değil. Google'ın belgesine göre API, arama türü başına günde en fazla 50 bin satır gösterir ve sorgu belgesi tüm satırların değil en üsttekilerin döneceğini söyler. Günlük tek günlük sorgular ve sayfalama düzeni en iyi kapsamı verir, ama sınır yine de geçerlidir.

BigQuery'de sorgu maliyetini nasıl düşük tutarım?

Tablolar tarihe göre bölümlendiği için sorgularınıza her zaman bir tarih aralığı koşulu ekleyin ve yalnızca gereken sütunları seçin. Google'ın belgesi, ücretsiz kullanım düzeyinin üzerindeki depolama ve sorgu kullanımının ücretlendirildiğini belirtir; güncel fiyatı Google Cloud sayfasından kontrol edin.

Anonimleştirilmiş sorgu satırlarını silmeli miyim?

Silmeyin, yalnızca analizde bilinçli ayırın. Bu satırlar sorgu metni olmadan toplam tıklama ve gösterimi taşır; sorgu bazlı listelerde filtrelenmeli, site toplamlarında ise tutulmalıdır. Aksi hâlde toplamlar arayüzdeki rakamdan sapar.

Sonuç

Search Console verisini 16 ayın ötesinde tutmak, üç parçalı bir karardır. İleriye dönük süreklilik için BigQuery toplu dışa aktarımı hemen açılmalı, çünkü kurulumdan önceki günler dışa aktarıma dahil değildir. Pencerede hâlâ duran geçmiş için API ile günlük sorgular çekilmeli, satır sayfalama ve arama türü başına günde 50 bin satır sınırı hesaba katılmalı. Küçük ekipler için aylık CSV ve özet dosyası da geçerli bir başlangıçtır. Her durumda toplama yapan sorgular, anonimleştirilmiş satırların bilinçli ele alınması, bölüm düzeyinde saklama kuralı ve en az yetkiyle erişim arşivin değerini korur.

Arşivinizden çıkan bulguları yayına dönüştürecek içerik üretimi için SEO içerik yazımı hizmetimize göz atabilirsiniz; kapsam ve koşullar ürün sayfasında yazılıdır.