Jak si udržet data ze Search Console déle než 16 měsíců

Search Console drží 16 měsíců výkonnostních dat a zbytek trvale maže. Ve chvíli, kdy potřebujete srovnání za dva roky, zjistíte, že prvních osm měsíců už neexistuje. Hromadný export dat do BigQuery to řeší, ale až ode dne, kdy ho zapnete. Proto je správná chvíle na přečtení tohoto článku dřív, než narazíte na tyto limity. Pokud mám dělat SEO pro klienta, na tohle se ptám jako první. Kolik máme vlastně dat a za jaký čas?

Cover ilustrace k článku o exportu dat ze Search Console do BigQuery.

Co vás limit 16 měsíců ve skutečnosti stojí

Limit zní dost akademicky, dokud na něj nenarazí skutečná otázka. Byl letošní dubnový propad horší než propad před dvěma lety v dubnu? Přinesla loňská přestavba kategorie víc než jen sezónní růst? Kolik tahle sekce vydělávala před migrací, která proběhla před 18 měsíci? Každá z těchto otázek je srovnání přes více než 16 měsíců, a Search Console na všechny odpovídá stejně. Ta data už v reportech ani přes API nezískáte.

Existuje i druhá, méně viditelná cena: omezená granularita. Rozhraní Search Console omezuje export na tisíc řádků a mnohem lepší Search Analytics API stále končí na 50 000 řádcích na den, na typ vyhledávání a na property. Na velkém webu je long tail za těmito řádky reálná návštěvnost, kterou prostě nikdy neuvidíte. Hromadný export žádný limit řádků nemá, dostanete celou tabulku.

Data ze Search Console starší než 16 měsíců zmizí, export do datového skladu je uchová.

Co je hromadný export a jeho jediné tvrdé omezení

Od února 2023 může Search Console posílat denní export výkonnostních dat do projektu BigQuery, který vlastníte. Po zapnutí se objeví tři tabulky a každý den narostou o jeden den dat.

  • searchdata_site_impression, výkon agregovaný podle property, tedy dotaz, země, zařízení, typ vyhledávání, spolu s prokliky, zobrazeními a pozicí. Pokud se u jednoho dotazu zobrazí dvě vaše URL, počítá se to tady jako jedno zobrazení.
  • searchdata_url_impression, totéž, agregované podle URL. Větší a užitečnější tabulka, tady se dělá analýza po stránkách, součty za sekce i rozbor migrací, včetně logických příznaků pro typy rozšířených výsledků.
  • ExportLog, záznam o každém úspěšném denním exportu. Všimněte si slova úspěšném, neúspěšné exporty se sem nezapisují, což určuje, jak pipeline monitorovat (více níže).

Jednu věc musíte přijmout dřív, než cokoli začnete plánovat. Export běží ode dne, kdy ho zapnete, a neumí doplnit data zpětně.

První export proběhne až 48 hodin po úspěšném nastavení a zahrnuje data za den exportu. Starší data doplníte jen v rozsahu, který je v Search Console ještě dostupný, a to okno se stále posouvá. To je nejsilnější argument pro to zapnout export hned teď na každé property, na které záleží, i když žádnou analýzu neplánujete. Úložiště pro tato data stojí velmi málo a historii, kterou nasbírají, si později nekoupíte.

Můj tip z praxe. Zapnutí hromadného exportu zapínám u každé nové klientské property hned na začátku spolupráce, ještě než se zadává jakákoli analýza. Důvodem je to, že pokud nevím, jak se projektu dařilo poslední roky, nejde lehce hledat důvody poklesu výkonu, nebo plánovat další růst. Pokud data nikdy nebudou potřeba, stálo to jen čas na nastavení. Pokud potřeba budou, ať už pro rozbor výkonu webu, efekt migrace na nové CMS, srovnání aktualizace algoritmu nebo model sezónnosti, máte je po ruce. Pokud máme data – nemusíme si nic domýšlet.

Co export neobsahuje

Tady je potřeba být přesný, protože ta mezera lidi uprostřed projektu překvapuje. Hromadný export nese jen výkonnostní data, tedy dotazy, URL, prokliky, zobrazení a pozici.

Neobsahuje report Indexování stránek, statistiky procházení ani žádný další report Search Console. Pokud zní otázka „které URL vypadly z indexu“, tabulky vyhledávání v BigQuery na ni odpovědět neumí.

Tato data přicházejí z URL Inspection API (omezené na 2 000 kontrol denně a 600 za minutu na property) nebo z reportu Indexování stránek. Můj kompletní monitoring používá obojí, export pro historii výkonu a kontroly vybraných URL pro stav indexace. V BigQuery se spojí, ale každé přichází odjinud.

Ještě jedna vestavěná mezera, jsou anonymizované dotazy. Anonymizované dotazy z exportu nezmizí: řádek zůstane, jen pole s dotazem má hodnotu null a řádek je označený příznakem is_anonymized_query.

Analýza na úrovni dotazů proto pracuje s podmnožinou a na webech s velkým long tailem je ta podmnožina znatelně menší než celek. Při nastavení si jednou srovnejte součty s reporty v Search Console. Ověříte si tak podíl anonymizovaných dotazů ve vlastních datech.

A ať už v Search Console najdete cokoli, odpovědi asistentů typu ChatGPT nebo Perplexity v ní nejsou vůbec. Jak se v nich značka objevuje, je samostatné měření s vlastním postupem.

Export, API, nebo obojí? Rozhodnutí

PotřebujetePoužijteProč
Průběžnou historii výkonnostních dat od dneška dálHromadný exportBez limitů na řádky, denně, po zapnutí bez údržby
Zachytit posledních 16 měsíců, než expirujíJednorázový backfill přes APIExport dozadu nesahá, API ano, v rámci svých limitů na řádky
Malý web, občasné otázkyStahování přes API podle potřebyLimity na řádky na malých webech málokdy vadí, datový sklad může být zbytečná režie
Velký web, seriózní průběžná analýzaObojíAPI jednorázově doplní minulost, export pokryje všechno od dneška dál

Kombinace obojího je praktická odpověď pro většinu webů, kterým na tom záleží. Jednou spusťte přes API backfill posledních 16 měsíců do staging tabulky, ve stejném týdnu zapněte export a obě sady spojte přes datum. Od té chvíle běží pipeline bez zásahu.

Jak to provozovat bez překvapení

  1. Základní nastavení obvykle zvládnete během několika hodin. Projekt v Google Cloud se zapnutou fakturací a BigQuery API, pak přidělte servisnímu účtu Search Console (search-console-data-export@system.gserviceaccount.com) role BigQuery Job User a BigQuery Data Editor a v nastavení property zapněte export. Může to udělat jen vlastník property. Google simuluje první export a pošle vlastníkům e-mail, průběžné exporty začnou přibližně do 48 hodin.
  2. Náklady na úložiště řešte už návrhem. Tabulky jsou rozdělené podle data_date. Vždy filtrujte podle sloupce s partition a expiraci partition i expiraci celé tabulky nastavujte jen tehdy, když opravdu chcete, aby historie expirovala (celý smysl tady obvykle je, že nechcete). U většiny webů jsou měsíční náklady malé, u velmi velkých property zkontrolujte v prvním týdnu denní přírůstek tabulek a o retenci rozhodněte vědomě.
  3. Hlídejte chybějící dny, nejen chyby. O většině chyb se dozvíte. Google pošle e-mail každému vlastníkovi property a každému plnému uživateli, když chyba exportu nastane a když se odstraní. Neplatí to pro přechodné chyby, například chyby připojení k serveru. Do ExportLog se neúspěšný export nezapíše a Google chybějící den zkouší doexportovat jen asi týden. Kontrolní dotaz na chybějící partition je pojistka pro případ, že e-mail zapadne nebo se den po týdnu zahodí. Spolehlivá kontrola je proto naplánovaný dotaz, který se ptá, jestli existuje očekávaná partition a má věrohodný počet řádků.
  4. Nad surovými tabulkami vytvořte vrstvu databázových pohledů, ne dashboardy přímo nad nimi. Tenká vrstva view (URL rozdělené do sekcí, příznaky brandových a nebrandových dotazů a časové dimenze) drží každý navazující report konzistentní a každou opravu na jednom místě. Právě tohle mění datový export v SEO správu místo jednorázového nastavení.
Tok dat ze Search Console do BigQuery s kontrolou doručení denního exportu.

Jak vypadá kontrolní dotaz

Tohle je hlídací úloha z bodu 3 výše. Naplánujte ji na každé ráno a nastavte upozornění, když vrátí prázdný výsledek nebo podezřele nízký počet řádků. Nahraďte si jen název projektu a datové sady.

SELECT
data_date,
COUNT(*) AS pocet_radku,
SUM(clicks) AS prokliky,
SUM(impressions) AS zobrazeni
FROM `vas-projekt.searchconsole.searchdata_url_impression`
WHERE data_date = DATE_SUB(CURRENT_DATE("America/Los_Angeles"), INTERVAL 2 DAY)
GROUP BY data_date

 

Na dvou detailech záleží. Ptám se na předevčírem, ne na včerejšek, protože export má zpoždění a včerejší partition ještě legitimně chybět může. A WHERE je na sloupci s partition, takže dotaz projde jeden den dat, ne dva roky. Kdo tenhle filtr vynechá, dostane první nečekaně vysoký účet za BigQuery přesně od kontrolní úlohy, která měla hlídat, že je všechno v pořádku.

Čeho se vyvarovat

  • Neodkládejte zapnutí exportu na chvíli, „až se rozjede analytický projekt“. Každý měsíc odkladu je měsíc historie, který nebude existovat. Nejdřív zapněte, plánujte potom.
  • Neslibujte zadavatelům úplnost na úrovni dotazů. Anonymizované dotazy jsou vyloučené záměrně. Součty reportujte ze součtů, analýzu dotazů z viditelné podmnožiny a vždy označte, co je co.
  • Nečekejte v těchto tabulkách data o indexaci nebo procházení. Jen výkon. Stav indexace je samostatná pipeline s vlastní kvótou a stejně tak co vědí vaše serverové logy o Googlebotu.
  • Nedotazujte se bez filtru na partition. SELECT * přes dva roky tabulky searchdata_url_impression na velké property je způsob, jak vznikají překvapivé účty za BigQuery.
  • Nesrovnávejte čísla z BigQuery s rozhraním Search Console a nepanikařte kvůli malým rozdílům. Samo rozhraní ukazuje filtrované pohledy a anonymizované dotazy vynechává. Kompletnější záznam je export, ne naopak.
  • Nezapínejte export na jiné property, než nad kterou analyzujete. Export na doménové property a analýzy nad URL-prefix property znamenají, že čísla nesedí. Zdroj pravdy je potřeba určit dopředu.
  • Nenastavujte expiraci, abyste ušetřili. Po roce zjistíte, že historie zmizela stejně jako v Search Console. Náklady se hlídají přes velikost tabulek, ne expirací.
  • Nestavte dashboardy přímo nad surovou tabulkou. Po změně struktury webu se rozsype každý graf. Mezi data a report patří vrstva view s rozdělením URL do sekcí.

Co se otevře, jakmile se data nasbírají

Datová pipeline se vyplatí u otázek, které dřív nešlo zodpovědět. Skutečné meziroční srovnání na úrovni URL a dotazů, okna před a po migraci webu nebo aktualizaci Google algoritmu měřené na identických sadách dotazů. Můžete také porovnat trendy po sekcích spojené s daty o tržbách i analýzu long tailu.

U migrací platí jedno omezení. Data ukážou efekt migrace, ale příčinu najdete v mapě přesměrování, a tu je potřeba ověřit hned po spuštění, ne až podle propadu v grafu o tři měsíce později.

Nic z toho nevyžaduje složité SQL. Všechno stojí na jednom rozhodnutí, které musí přijít včas. Kdo ho udělá dnes, bude mít za rok data. Kdo ho odloží na chvíli, až bude potřeba, bude mít za rok stále jen posledních 16 měsíců, tedy jiné období než dnes.

Pokud chcete dělat kvalitní SEO pro klienty, začal bych zde.