Jeśli chcesz później ocenić, czy zmiana treści, linkowania albo techniki zbiegła się z lepszą widocznością w Google AI Search, najpierw potrzebujesz stanu T0. Bez niego porównanie łatwo sprowadza się do prostego „wcześniej było mniej, później jest więcej”, bez pewności, czy analizujesz ten sam zakres i te same warunki.
Punkt odniesienia nie powinien być jedną liczbą. Powinien zapisywać, co mierzysz, z jakiego źródła pochodzą dane, jaki okres analizujesz, których stron i segmentów dotyczy obserwacja, kiedy nastąpiła zmiana oraz jakie inne zdarzenia mogły wpłynąć na wynik.
3 czerwca 2026 r. Google ogłosił osobne raporty Generative AI Performance w Search Console dla generatywnych funkcji Google Search, takich jak AI Overviews i AI Mode. W komunikacie premierowym Google podał, że raport trafia najpierw do części witryn. Z tego powodu proces uwzględnia zarówno wariant z dedykowanym raportem, jak i wariant bez niego.
Czym jest punkt odniesienia dla widoczności w Google AI Search?
Punkt odniesienia, czyli baseline, to udokumentowany stan T0 zapisany zanim zmienisz analizowany obszar witryny. Nie jest to oficjalna metoda Google ani osobna metryka Search Console. W tym materiale termin oznacza kontrakt pomiarowy, który pozwala wrócić do stanu początkowego i sprawdzić, co faktycznie było mierzone.
Najprostszy model ma trzy elementy:
T0 → interwencja → T1
T0 opisuje stan początkowy. Interwencja to zmiana, którą chcesz później oceniać: aktualizacja treści, przebudowa struktury, zmiana linkowania, korekta techniczna albo inna ingerencja w analizowany obszar. T1 jest późniejszym punktem pomiarowym odnoszącym się do możliwie tego samego zakresu.
Sama para wartości T0 i T1 nie wystarczy. Jeśli pierwszy pomiar obejmuje całą domenę, a zmiana dotyczy tylko kilku adresów URL, wynik całej witryny może ukryć to, co wydarzyło się na analizowanych stronach. Jeśli zmienisz kraj, urządzenie albo okres porównania, również przestajesz porównywać identyczny wycinek danych.
Dobry baseline odpowiada więc nie tylko na pytanie „ile było?”, lecz także: co, gdzie, kiedy i w jakich warunkach zostało zmierzone?
Co trzeba ustalić przed rozpoczęciem pomiaru?
Najpierw ustal jednostkę analizy. Jeśli planowana zmiana obejmuje jeden artykuł, zapisz dane tej strony. Jeśli ingerencja dotyczy grupy wpisów albo całego klastra, stan T0 powinien pozwalać wrócić właśnie do tej grupy. Wynik całej domeny może zostać zachowany jako kontekst, ale nie powinien zastępować pomiaru obszaru, którego dotyczy interwencja.
Drugim elementem jest źródło danych. Search Console pozwala analizować wydajność według takich wymiarów jak strona, kraj, urządzenie i czas. Osobny raport Generative AI Performance pokazuje widoczność adresów URL w generatywnych funkcjach Google Search, jeśli dana witryna ma do niego dostęp.
Trzeci element to okres. Należy zapisać nie tylko datę początku i końca, ale też powód wyboru danego przedziału. Inaczej łatwo zestawić okres spokojny z tygodniem dużej promocji, sezonem sprzedażowym albo momentem, w którym witryna przechodziła równolegle inne zmiany.
Czwarty element to segmentacja. Jeżeli kraj albo typ urządzenia ma znaczenie dla analizowanego ruchu, ten sam podział powinien być możliwy do odtworzenia przy T1. Nie chodzi o mnożenie raportów. Chodzi o zachowanie tych wymiarów, które mogą zmienić interpretację wyniku.
Jak zbudować baseline Google AI Search?
- Określ obiekt pomiaru. Zapisz, czy analizujesz całą domenę, katalog, grupę adresów URL czy pojedynczą stronę. Zakres powinien odpowiadać zmianie, którą planujesz później oceniać.
- Zapisz źródło danych. Zanotuj, czy korzystasz z Generative AI Performance Report, ogólnego raportu Performance, własnego eksportu, obserwacji ręcznych czy danych narzędzia zewnętrznego. Różnych metod nie należy później łączyć tak, jakby mierzyły dokładnie to samo.
- Ustal okres T0. Zapisz datę początku i końca oraz powód wyboru tego przedziału. Nie zakładaj automatycznie, że każda witryna wymaga identycznej liczby dni.
- Zachowaj ważne segmenty. Zanotuj kraj, urządzenie i zakres stron, jeśli wpływają na analizę. Przy T1 wrócisz do tych samych ustawień.
- Zapisz wartości początkowe. Dla dostępnych danych zanotuj stan T0. Nie łącz go z własnym punktowym „AI Visibility Score”, jeśli taki wskaźnik nie ma jasno opisanej metodologii i nie odpowiada metrykom Google.
- Oznacz datę interwencji. Search Console pozwala dodawać własne adnotacje do wykresów Performance i przypisywać je do określonego dnia. Taka adnotacja może wskazać moment zmiany treści, techniki, szablonu lub innego działania.
- Prowadź osobny changelog. Krótka adnotacja na wykresie nie zastępuje pełnego opisu. W changelogu zapisz adresy URL, zakres edycji oraz inne zdarzenia zachodzące w podobnym czasie.
- Zdefiniuj punkt T1. Jeszcze zanim zmienisz stronę, ustal, jakie dane mają zostać ponownie sprawdzone. Dzięki temu późniejsza analiza nie będzie dobierała wskaźników dopiero wtedy, gdy wynik okaże się korzystny albo niekorzystny.
Efektem tej procedury powinien być zapis, który inna osoba może otworzyć kilka tygodni lub miesięcy później i bez zgadywania odtworzyć warunki T0.
FULL czy LIMITED baseline — co zrobić bez raportu Generative AI?
Dostęp do raportu Generative AI Performance nie musi być jednakowy dla wszystkich witryn. Jeśli nie wiesz, czy właściwa usługa ma już ten widok, najpierw sprawdź jak sprawdzić, czy masz raport Generative AI w Google Search Console.
FULL BASELINE
FULL BASELINE ma zastosowanie, gdy witryna posiada dostęp do danych generatywnej widoczności w Search Console. Według dokumentacji premierowej Google raport Search pokazuje impressions związane z funkcjami takimi jak AI Overviews i AI Mode oraz umożliwia analizę m.in. według stron, krajów, urządzeń i czasu.
W takim scenariuszu zapisz stan T0 bezpośrednio dla obszaru, który zamierzasz później zmienić. Jeśli analizujesz grupę URL-i, zachowaj ich listę. Jeśli ważny jest rynek polski i urządzenia mobilne, zapisz te segmenty. T1 powinien wrócić do tej samej definicji.
LIMITED BASELINE
Brak raportu Generative AI nie oznacza, że trzeba zrezygnować z dokumentacji stanu początkowego. Oznacza natomiast, że zakres wniosków będzie mniejszy.
W LIMITED BASELINE można zapisać klasyczne dane Search Console jako kontekst SEO, zakres planowanej zmiany, daty, segmenty oraz ograniczenia pomiaru. Trzeba przy tym jasno zaznaczyć, że dane klasycznego raportu Performance nie są tym samym co osobny pomiar generatywnej widoczności.
Podobna zasada dotyczy narzędzi zewnętrznych. Google podaje, że żadne narzędzie third-party nie ma dostępu do jego wewnętrznych systemów rankingowych lub AI. Własna metryka dostawcy może być użyteczna w określonym procesie, ale nie powinna być opisywana jako wewnętrzna metryka Google ani równoważnik danych Search Console.
Czy ręczne obserwacje AI mają sens?
Mogą stanowić osobną warstwę obserwacyjną, jeśli zapisujesz warunki pomiaru i nie mieszasz jej z danymi Search Console.
Jedno ręczne sprawdzenie nie powinno być traktowane jako stała „pozycja w AI”. Badanie dotyczące powtarzalności pomiaru widoczności w AI Search wskazuje, że odpowiedzi mogą różnić się między uruchomieniami, sformułowaniami zapytań i momentami pomiaru. Jeśli korzystasz z ręcznych testów, zapisuj zestaw zapytań, czas obserwacji oraz sposób powtarzania pomiaru.
Ta warstwa może uzupełnić baseline, lecz nie powinna udawać danych, których witryna nie otrzymuje z Google.
AI Measurement Baseline Card — co zapisać przed zmianą?
AI Measurement Baseline Card to roboczy framework SEOsklep24 służący do zebrania stanu T0 w jednym miejscu. Nie jest formularzem Google ani oficjalnym standardem pomiaru. Jego zadaniem jest ograniczenie sytuacji, w której kilka tygodni później nie wiadomo już, jaki zakres był mierzony, co zmieniono i jakie warunki towarzyszyły obserwacji.
Grafika grupuje 12 pól stanu T0 w cztery obszary: zakres, dane T0, interwencję i kontekst. To framework redakcyjny SEOsklep24.pl, a nie oficjalny formularz Google. Pełny odpowiednik tekstowy znajduje się w tabeli poniżej.
| Pole | Co zapisać | Rola w późniejszym porównaniu |
|---|---|---|
| Zakres pomiaru | Domena, katalog, grupa URL-i albo pojedyncza strona | Określa, czego faktycznie dotyczy T0 |
| Źródło danych | Search Console, raport Generative AI, eksport lub osobna metoda obserwacyjna | Zapobiega mieszaniu różnych metod |
| Status raportu GenAI | FULL albo LIMITED | Pokazuje, jakich danych brakowało w chwili T0 |
| Zakres dat T0 | Data początku i końca | Pozwala odtworzyć badany okres |
| Kraj | Rynek użyty w analizie, jeśli został wydzielony | Chroni przed porównaniem różnych segmentów geograficznych |
| Urządzenie | Mobile, desktop lub cały ruch, jeśli podział jest potrzebny | Utrzymuje zgodność segmentów T0 i T1 |
| Wartości T0 | Metryki dostępne dla wybranego źródła i zakresu | Stanowi zapis stanu początkowego |
| Data interwencji | Dzień wprowadzenia analizowanej zmiany | Oddziela okres bazowy od okresu obserwacji zmiany |
| Opis interwencji | Co zostało zmienione i na których URL-ach | Pozwala później ustalić rzeczywisty zakres ingerencji |
| Inne zdarzenia | Promocje, migracje, aktualizacje techniczne, inne edycje treści | Pomaga rozpoznać możliwe zakłócenia |
| Ograniczenia | Brakujące dane, mała liczba obserwacji, brak raportu GenAI lub inne luki | Wyznacza granicę późniejszych wniosków |
| Punkt T1 | Co ma zostać ponownie zmierzone i według jakiej definicji | Utrzymuje ten sam kontrakt pomiarowy |
Przed zmianą sprawdź, czy karta odpowiada na cztery pytania: co mierzymy, skąd pochodzą dane, co dokładnie zmieniamy i co będziemy później porównywać?
- zakres T0 jest zapisany i możliwy do ponownego ustawienia;
- źródło danych jest nazwane;
- brakujące dane są opisane, a nie ukryte;
- data i zakres interwencji są znane;
- równoległe zdarzenia mają miejsce w changelogu;
- T1 korzysta z tej samej definicji pomiaru.
Karta nie wylicza własnej oceny punktowej. Złożenie kilku różnych sygnałów w jeden „AI Visibility Score” utrudniałoby ocenę, która część wyniku rzeczywiście się zmieniła i według jakiej metodologii została policzona.
Jak dobrać okres baseline przed optymalizacją?
Nie ma jednej oficjalnej liczby dni, którą każda witryna powinna przyjąć jako baseline. Dokumentacja raportu Performance w Search Console pozwala pracować na różnych zakresach czasu i różnej granularności danych, ale nie ustanawia uniwersalnej reguły typu „zawsze używaj 28 dni”.
Okres T0 powinien możliwie dobrze opisywać zwykły stan analizowanego obszaru. Jeśli wybierzesz przedział nietypowy — święta, dużą promocję, awarię albo chwilowy skok zainteresowania — T1 może wyglądać inaczej nawet bez związku z analizowaną zmianą SEO.
Google wskazuje, że agregacja tygodniowa lub miesięczna może ograniczać wpływ części codziennych wahań i różnic między dniami tygodnia. To pomaga przy analizie trendu, ale nadal nie odpowiada za Ciebie na pytanie, jaki okres jest reprezentatywny dla danej witryny.
Dobierając T0, sprawdź trzy rzeczy: czy okres jest typowy dla badanego biznesu, czy nie zawiera zdarzenia mocno zmieniającego popyt oraz czy podobny zakres będzie można sensownie zestawić z T1.
Jeśli biznes ma wyraźną sezonowość, prosty fragment czasu bez kontekstu może dać fałszywe poczucie precyzji. W takiej sytuacji trzeba odnotować sezonowość i ostrożniej formułować wnioski.
Co może zafałszować porównanie before/after?
Największy problem pojawia się wtedy, gdy między T0 a T1 zmienia się więcej rzeczy niż ta, którą chcesz oceniać. Nie zawsze da się tego uniknąć. Można za to zapisać takie zdarzenia i uwzględnić je przy interpretacji. Badania metodologiczne nad projektami before/after i interrupted time series pokazują, że równoległe interwencje oraz zdarzenia występujące w podobnym czasie mogą stanowić alternatywne wyjaśnienie obserwowanej zmiany.
- kilka interwencji równocześnie — np. zmiana treści, linkowania i szablonu na tych samych stronach;
- sezonowość — naturalna zmiana popytu między analizowanymi okresami;
- kampanie lub promocje — działania, które mogą zmienić zainteresowanie marką i stroną;
- migracja lub większa zmiana techniczna — zdarzenie obejmujące większą część serwisu;
- edycje innych powiązanych treści — zmiany w klastrze mogą utrudnić przypisanie wyniku jednej stronie;
- inna definicja T1 — zmiana kraju, urządzenia, zestawu URL-i albo źródła danych między pomiarami;
- zdarzenia zewnętrzne — sytuacje rynkowe i kalendarzowe, których analiza SEO nie kontroluje.
Nie chodzi o stworzenie idealnie sterylnego eksperymentu dla każdej aktualizacji artykułu. Chodzi o to, aby późniejszy raport nie przemilczał zdarzeń, które mogą mieć inne wyjaśnienie niż badana interwencja.
Co baseline pozwala stwierdzić — a czego nie?
Baseline pozwala rzetelniej opisać zmianę między dwoma udokumentowanymi stanami. Możesz sprawdzić, czy wartości wzrosły, spadły albo pozostały zbliżone, na których stronach pojawiła się różnica i kiedy nastąpiła względem zapisanej interwencji.
Możesz też powiedzieć, że zmiana wyniku wystąpiła w okresie następującym po określonej ingerencji, jeśli chronologia rzeczywiście tak wygląda.
Nie możesz na podstawie samego prostego before/after automatycznie uznać, że interwencja spowodowała całą obserwowaną różnicę. Równoległe zdarzenia, wcześniejszy trend, sezonowość albo inne ingerencje mogą prowadzić do podobnego wyniku.
Ta granica jest ważna także wtedy, gdy wynik wygląda bardzo dobrze. Zdanie „AI impressions wzrosły po aktualizacji” opisuje obserwację. Zdanie „aktualizacja spowodowała wzrost AI impressions” jest twierdzeniem o przyczynie i wymaga mocniejszego projektu pomiarowego.
Im lepiej opisany T0, interwencja, T1 i możliwe zakłócenia, tym łatwiej ocenić siłę dowodu. Sam baseline nie usuwa niepewności — sprawia, że wiadomo, gdzie ona występuje.
Przykład: T0 → zmiana → T1
Przykład hipotetyczny. Firma chce ocenić aktualizację kilku artykułów należących do jednego klastra. Zanim zmieni tekst, zapisuje listę badanych URL-i, dostępność raportu Generative AI, zakres czasu, kraj oraz wartości T0. W Search Console oznacza dzień planowanej interwencji, a w osobnym changelogu zapisuje, że na badanych stronach zmieniono treść, lecz nie zmieniono szablonu ani struktury adresów.
W tym samym okresie firma prowadzi akcję promocyjną dotyczącą innej części serwisu. Informacja trafia do changelogu, choć nie dotyczy bezpośrednio analizowanych artykułów.
Przy T1 zespół wraca do tego samego zestawu URL-i, tego samego rynku i tej samej definicji danych. Widoczność jest wyższa niż w T0.
Prawidłowy zapis wyniku brzmi:
„W badanym zakresie widoczność była wyższa w T1 niż w T0, a zmiana nastąpiła po aktualizacji analizowanych treści.”
Zbyt mocny wniosek brzmiałby:
„Aktualizacja tych artykułów spowodowała wzrost widoczności.”
Druga wersja przypisuje przyczynę, której sam układ T0–T1 jeszcze nie dowodzi. Różnica między tymi zdaniami jest niewielka językowo, ale duża metodologicznie.
Co zrobić po zbudowaniu punktu odniesienia?
Jeśli nie masz jeszcze jasno określonego obszaru wymagającego zmiany, wcześniejszym krokiem może być audyt AI Search. Gdy zakres interwencji jest już znany, można przejść do planowanej zmiany i zachować jej opis w changelogu.
Najlepiej nie zmieniać definicji pomiaru tylko dlatego, że przy T1 inny fragment danych wygląda korzystniej.
Przy punkcie T1 wróć do tych samych stron, segmentów i źródła danych. Jeśli warunki się zmieniły, zapisz różnicę. Jeśli równolegle wystąpiło inne zdarzenie, uwzględnij je przy interpretacji.
Najważniejszym rezultatem baseline nie jest „dobry wynik”. Jest nim możliwość sprawdzenia, od jakiego stanu zaczęła się analiza i jak silny wniosek naprawdę wspierają późniejsze dane.
