GSC pokazuje kliknięcia, GA4 inną domenę: jak wykryć błędne połączenie danych SEO

GSC pokazuje 1200 kliknięć dziennie. GA4 raportuje 400 sesji organicznych. Czy reszta to dark traffic? Niekoniecznie. W 14% przypadków z naszej próby 105 hostów problem nie dotyczył ruchu – dotyczył tego, że GSC i GA4 opisywały różne domeny. Automatyczny system wybrał pierwszą pasującą property GA4, ignorując to, że defaultUri prowadził do innej domeny niż GSC. Gdy to naprawiliśmy, rozbieżność spadła z 67% do 12% – reszta to standardowe różnice definicyjne między kliknięciem a sesją.

Jakie parametry miał test mapowania?

Audyt przeprowadziliśmy na 50 kontach GA4 z portfolio Semgence, obejmujących łącznie 96 properties i 105 web streamów. Każdy host GSC porównaliśmy z dostępnymi properties GA4 w trzech wymiarach: konfiguracja streamu (defaultUri), dane z raportów (hostName) i ostatnia aktywność (ruch z 90 dni). Celem nie było dopasowanie jak największej liczby par, lecz rozdzielenie pewnych dopasowań od niepewnych – tak, żeby żaden raport SEO nie opierał się na danych z cudzej domeny.

Parametr	Wartość
Konta GA4	50
Properties widoczne	96
Web streamy	105
Hosty GSC	105
Jednoznaczne dopasowania (ground truth)	23
Hosty z wieloma pasującymi properties	11
Hosty bez widocznego dopasowania	71
Narzędzia	Wewnętrzne narzędzia diagnostyczne Semgence (resolver property, diagnostyka mapowania URL, wykrywanie luk w śledzeniu)

Próba 105 hostów nie jest próbą losową – to hosty z kont, do których mamy dostęp agencyjny. Nadreprezentowane są w niej sklepy e-commerce (43%) i serwisy B2B (31%), co odpowiada profilowi klientów Semgence. Wyniki nie są bezpośrednio transferowalne na całą populację polskich stron, ale mechanizm błędu (nieprawidłowe mapowanie domeny) jest niezależny od branży.

Dlaczego nazwa property nie jest dowodem tożsamości domeny?

Property GA4 o nazwie „Moja Firma – www” mogła zostać utworzona dla domeny mojafirma.pl, ale od tamtego czasu ktoś zmienił domenę na mojafirma.com, dodał nowy stream dla nowej domeny i nie usunął starej nazwy. Nazwa property to etykieta, nie dowód – tak samo jak tytuł dokumentu Google Docs nie mówi nic o jego zawartości. Ten sam problem dotyczy stron optymalizowanych pod pozycjonowanie w AI – jeśli dane analityczne opisują złą domenę, nie da się ocenić skuteczności.

W naszym teście resolver sprawdzał każdą property nie po nazwie, lecz po trzech dowodach: defaultUri w web streamie, rzeczywisty hostName w danych GA4 (wymiar hostName w raportach) oraz obecność ruchu z danego hosta w ostatnich 90 dniach. Dopiero gdy wszystkie trzy się zgadzały, system zwracał status domain_evidence_match z wysokim confidence.

Problem z nazwami jest powszechniejszy niż się wydaje. W próbie 96 properties znaleźliśmy 17 (18%), w których nazwa property nie odpowiadała żadnej domenie w skonfigurowanych streamach. Przykładowe wzorce: „Stara domena (2022)” z defaultUri ustawionym na nową domenę, „Test property” z produkcyjnym streamem, „Kopia – GA4” bez żadnego streamu. Raport Graphed potwierdza, że oryginalny URL streamu jest zablokowany po utworzeniu – można go zmienić tylko w ustawieniach, ale wielu administratorów o tym nie wie.

Jak wygląda problem przy wielu kontach i wielu domenach?

Agencje SEO obsługujące wielu klientów mają dostęp do dziesiątek kont GA4. W ramach konsultacji SEO regularnie naprawiamy takie błędne mapowania. Każde konto może mieć kilka properties, każda property kilka streamów. Automatyczny system, który szuka property po nazwie lub pierwszym streamie, może trafić na property z innego konta, która przypadkiem ma podobną nazwę lub domenę.

W próbie 11 hostów z wieloma pasującymi properties system bez guardu wybierałby losowo. Z conservative ambiguity guard – mechanizmem, który wymaga jawnego dowodu domenowego – system poprawnie zidentyfikował 5 z 5 testowanych przypadków wieloznacznych i w żadnym nie wybrał złej property.

Typowe scenariusze wieloznaczności, które obserwujemy w praktyce agencyjnej:

Scenariusz	Przykład	Ryzyko bez guardu
Dwa konta, dwa streamy na tę samą domenę	Klient i agencja założyli niezależnie GA4 dla sklepu.pl	System wybiera property z mniejszym ruchem, dane wydają się niskie
Property testowa i produkcyjna	„Sklep – dev” i „Sklep – prod” obie mają stream dla sklepu.pl	Raport bazuje na danych z property testowej (ruch wewnętrzny, boty)
Migracja domeny	starydomen.pl przeniesiony na nowydomen.pl, oba streamy w jednej property	GSC dla nowydomen.pl łączy się z danymi z obu domen naraz
Subdomeny vs domeny	blog.sklep.pl i sklep.pl w jednej property, ale GSC ma domain property	Ruch z bloga zlicza się z ruchem sklepu – zaniżony CR

Badanie TagGurus podkreśla, że śledzenie wielu stron w jednej property GA4 jest problematyczne, ponieważ nie można śledzić pojedynczej sesji w dwóch różnych properties GA4. Oznacza to, że sesje cross-domain są albo zduplikowane, albo ucięte – w obu przypadkach dane są nieprawidłowe.

Czym różni się defaultUri od rzeczywistego hostName?

defaultUri to pole konfiguracyjne w web streamie GA4 – ustawiane raz przy tworzeniu streamu. hostName to wymiar raportowy – odzwierciedla faktyczny ruch. Gdy ktoś zmienia domenę, ale nie aktualizuje defaultUri, te dwa źródła się rozmijają. To rozróżnienie jest kluczowe, bo większość narzędzi trzecich (w tym nasze własne w pierwszej wersji) używała defaultUri jako źródła prawdy.

Źródło	Co pokazuje	Wiarygodność	Kiedy zawodzi
defaultUri (stream config)	Domena ustawiona przy tworzeniu streamu	Niska – może być nieaktualna	Po migracji domeny, rebrandingu, zmianie subdomeny
hostName (raport GA4)	Faktyczna domena, z której przychodzi ruch	Wysoka – oparta na danych real-time	Gdy filtr wyklucza ruch z hosta, gdy ruch jest zerowy
Konfigurowana mapa (explicit)	Ręcznie potwierdzone powiązanie GSC-GA4	Najwyższa – jawny dowód	Nigdy – chyba że ktoś ręcznie wpisze złe dane

W praktyce widzimy trzy typowe stany rozbieżności:

Stan 1 – defaultUri aktualny, hostName zgodny. Wszystko działa poprawnie. W naszej próbie 23 z 34 hostów z widocznym dopasowaniem (68%) było w tym stanie.

Stan 2 – defaultUri nieaktualny, hostName poprawny. Domena została zmieniona, ale ktoś zapomniał zaktualizować stream. Nasz resolver wykrywa to, porównując defaultUri z hostName – jeśli się różnią, podnosi flagę domain_config_stale. W próbie było 8 takich przypadków (24%).

Stan 3 – defaultUri nieaktualny, hostName brak ruchu. Najgorszy scenariusz – domena nie generuje ruchu w GA4 (bo np. tag jest usunięty), a defaultUri wskazuje starą domenę. System bez guardu mógłby połączyć tę property z hostem GSC, dając raport z zerowym ruchem. W próbie były 3 takie przypadki (9%).

Jak Consent Mode v2 pogłębia problem rozbieżności?

Od wejścia w życie zaostrzonych wymogów Consent Mode v2 w 2025 roku, różnica między kliknięciami GSC a sesjami GA4 systematycznie rośnie. Gdy odwiedzający odrzuca cookies analityczne, GA4 nie rejestruje sesji – ale GSC wciąż liczy kliknięcie. Według danych MainTouch ta luka wynosi obecnie 15-55% w zależności od branży i regionu.

Problem polega na tym, że ta luka maskuje błędy mapowania. Gdy widzisz 60% różnicę między GSC a GA4, naturalnie przypisujesz ją Consent Mode. Ale z naszych danych wynika, że w 14% przypadków przynajmniej część tej różnicy wynikała z faktu, że GSC i GA4 opisywały dosłownie inne domeny. Dopiero po naprawie mapowania można rzetelnie zmierzyć wpływ Consent Mode na utratę danych.

Kolejny czynnik to ad-blockery i rozszerzenia prywatności. Badanie BlogPros szacuje, że narzędzia te blokują 20-30% sesji GA4 w segmencie technologicznym, a mniej niż 5% w segmencie seniorów. To oznacza, że rozbieżność GSC-GA4 jest silnie zależna od demografii odwiedzających – kolejny powód, by nie diagnozować jej jedną cyfrą, ale analizować per segment.

Jak działa conservative ambiguity guard?

Poprawne mapowanie danych jest warunkiem wstępnym każdej strategii content marketingowej opartej na danych. Guard działa w trzech krokach. Pierwszy: sprawdza, czy istnieje jawna konfiguracja (configured_map). Jeśli tak – używa jej i kończy. Drugi: szuka domain_evidence_match – property, w której hostName z raportu GA4 odpowiada hostowi GSC. Jeśli jest dokładnie jedna taka property – używa jej z wysokim confidence. Trzeci: jeśli jest więcej niż jedna pasująca property (ambiguous_domain_match) lub żadna nie pasuje (no_visible_stream_match) – system zwraca status bez wyboru i wymaga ręcznej weryfikacji.

Kluczowa zasada: system nigdy nie zgaduje. Brak dopasowania jest raportowany jako brak dopasowania, nie jako zero ruchu. To fundamentalna różnica przy mierzeniu ROI pozycjonowania.

Status guardu	Co oznacza	Działanie systemu	Częstość w próbie
configured_map	Jawna, ręczna konfiguracja GSC-GA4	Używa skonfigurowanej property, 100% confidence	0/105 (brak configured maps)
domain_evidence_match	Jeden stream z pasującym hostName	Używa tej property, wysoki confidence	23/105 (22%)
ambiguous_domain_match	Dwa lub więcej streamów z pasującym hostName	Nie wybiera, wymaga ręcznej decyzji	11/105 (10%)
no_visible_stream_match	Żaden stream nie pasuje do hosta GSC	Nie wybiera, raportuje „brak mapy”	71/105 (68%)

Warto zauważyć, że 68% hostów z kategorii no_visible_stream_match to nie błąd systemu – to stan rzeczywisty. Te hosty albo nie mają wdrożonego GA4, albo mają property na kontach, do których nasz resolver nie miał dostępu. Prawdziwa wartość guardu polega na tym, że odróżnia „nie wiem” od „zero” – co jest fundamentalną zasadą rzetelnej diagnostyki danych.

Jakie wyniki dał benchmark na realnych kontach?

Kategoria	Wynik	Uwagi
Jednoznaczne dopasowania	23/23 poprawne (100%)	Jeden host, jedna property z dowodami
Wieloznaczne dopasowania	5/5 bezpieczne (100%)	System zwrócił „ambiguous”, nie zgadywał
Kontrole negatywne	5/5 poprawne (100%)	Hosty bez GA4 oznaczone jako no_visible_stream_match
False selections	0 w badanej próbie	Zero błędnych wyborów property

Wynik „zero false selections” dotyczy wyłącznie badanej próby (33 przypadki testowe). Te dane wykorzystujemy m.in. w audycie widoczności w AI, gdzie poprawne mapowanie GSC-GA4 jest warunkiem wstępnym analizy. Nie rozszerzamy tego wyniku na wszystkie 105 hostów – 71 z nich nie miało widocznego dopasowania i wymaga ręcznej konfiguracji.

Dla porównania: przed wdrożeniem guardu, system typu „pierwszy pasujący stream” popełniał błędy w 3 z 11 wieloznacznych przypadków (27% error rate). W praktyce oznaczało to, że co czwarty raport porównujący GSC z GA4 opierał się na danych z niewłaściwej property. Klient widział „spadek konwersji z organic”, a w rzeczywistości patrzył na dane property testowej.

Jak wygląda diagnostyka krok po kroku?

Poniższy workflow stosujemy w Semgence przy każdym onboardingu nowego klienta i przy każdym audycie SEO, zanim w ogóle zaczniemy analizować dane ruchu. Kolejność kroków jest istotna – każdy opiera się na wyniku poprzedniego.

Krok 1 – inwentaryzacja properties. Listujemy wszystkie properties GA4, do których mamy dostęp z danego konta. Sprawdzamy ich nazwy, daty utworzenia i liczbę streamów. Na tym etapie nie oceniamy jeszcze dopasowania – tylko tworzymy mapę tego, co istnieje.

Krok 2 – analiza streamów. Dla każdej property wyciągamy listę web streamów z ich defaultUri. Zaznaczamy rozbieżności: streamy bez defaultUri, streamy z pustym measurement ID, streamy wskazujące na subdomeny vs domeny główne.

Krok 3 – dowód ruchu. Dla każdego streamu z defaultUri pasującym do hosta GSC sprawdzamy wymiar hostName w raporcie GA4 za ostatnie 90 dni. Jeśli hostName potwierdza ruch z domeny GSC – to domain_evidence_match. Jeśli hostName pokazuje inną domenę – flagujemy domain_config_stale.

Krok 4 – rozwiązanie wieloznaczności. Dla hostów z ambiguous_domain_match porównujemy wolumen ruchu między pasującymi properties. Property z wyższym ruchem jest prawdopodobnie produkcyjna – ale to wymaga ręcznego potwierdzenia z klientem.

Krok 5 – konfiguracja explicit map. Po ręcznym potwierdzeniu tworzymy configured_map – jawne powiązanie host GSC z property GA4, z datą utworzenia i osobą odpowiedzialną. Od tego momentu system pomija heurystykę i używa mapy.

Dlaczego „brak mapy” nie oznacza „zero ruchu”?

71 z 105 hostów (68%) nie miało automatycznego dopasowania. To nie znaczy, że te domeny nie mają ruchu z GA4. Znaczy, że system nie znalazł wystarczającego dowodu, aby automatycznie połączyć dane GSC z konkretną property GA4.

Błąd, który popełnia większość narzędzi: traktowanie braku mapy jako braku ruchu. Raport SEO mówi wtedy „brak danych GA4”, a klient myśli, że strona nie generuje sesji. To jeden z najczęstszych problemów, które wykrywamy podczas audytu treści i analizy ścieżek konwersji. W rzeczywistości sesje są – po prostu w innej property, pod innym streamem, albo pod innym hostName niż ten, którego system szukał.

Z 71 hostów bez mapy, po ręcznej analizie zidentyfikowaliśmy 23 hosty (32%), które faktycznie miały dane GA4 – ale na kontach, do których nasz resolver nie miał dostępu w momencie audytu. Kolejne 19 (27%) miało GA4, ale z tagiem na subdomenie, a nie na domenie głównej. Tylko 29 (41%) naprawdę nie miało żadnego wdrożenia GA4.

Powód braku mapy	Liczba hostów	Procent	Rozwiązanie
Property na innym koncie (brak dostępu)	23	32%	Uzyskać dostęp do właściwego konta GA4
Tag GA4 na subdomenie, GSC na domenie głównej	19	27%	Domain property w GSC lub dodatkowy stream w GA4
Brak wdrożenia GA4	29	41%	Wdrożyć tag GA4 lub skonfigurować server-side tagging

Jakie są realne konsekwencje błędnego mapowania dla SEO?

Błędne mapowanie GSC-GA4 nie jest problemem technicznym, który „nie wpływa na ranking”. Wpływa na decyzje, które wpływają na ranking. Oto trzy scenariusze, które widzieliśmy w praktyce:

Scenariusz A – fałszywy spadek konwersji. Sklep e-commerce z dwoma properties GA4 (testowa i produkcyjna). System raportowy łączył GSC z property testową, która miała 10x mniejszy ruch. Raport pokazywał „spadek CR z organic o 80%”. Klient planował rezygnację z kampanii contentowej. Po naprawie mapowania okazało się, że CR jest stabilny – po prostu patrzył na złe dane.

Scenariusz B – niewidoczny ruch z bloga. Serwis B2B z blogiem na subdomenie blog.firma.pl i stroną główną na firma.pl. GSC domain property obejmował obie subdomeny, ale GA4 miał stream tylko dla firma.pl. Ruch z bloga (35% ruchu organicznego) nie pojawiał się w raportach GA4 – co prowadziło do wniosku, że „blog nie generuje ruchu”. W rzeczywistości generował, ale system go nie widział.

Scenariusz C – zduplikowane sesje. Firma po rebrandingu z domena-stara.pl na domena-nowa.pl. Oba streamy w jednej property, redirect 301 z starej na nową. GA4 liczył sesje z obu domen osobno, dając zawyżone dane o ruchu organicznym. Po usunięciu starego streamu i naprawie mapowania ruch spadł o 22% – ale to był ruch rzeczywisty, nie artefakt konfiguracyjny. Tego typu problemy regularnie wykrywamy przy pozycjonowaniu sklepów internetowych.

Jak różnice stref czasowych wpływają na rozbieżności?

GSC raportuje w czasie Pacific Time (UTC-7/UTC-8), GA4 w strefie czasowej ustawionej w property (najczęściej CET/CEST dla polskich stron). Różnica 9 godzin oznacza, że sesja z 23:30 CET pojawi się w GA4 w dniu bieżącym, ale w GSC – już w dniu następnym. Przy dużym ruchu nocnym (np. serwisy z treścią rozrywkową) ta rozbieżność sięga 5-8% dziennego ruchu.

Nie można tego problemu „naprawić” – można go jedynie uwzględnić. W naszych raportach porównujemy dane GSC i GA4 w oknach tygodniowych lub miesięcznych, nigdy dziennych. Przy porównaniu dziennym rozbieżność stref czasowych nakłada się na rozbieżność definicji (kliknięcie vs sesja), dając wynik, którego nie da się sensownie interpretować. Badanie SocialLand potwierdza tę praktykę – dzienne porównania GSC i GA4 są statystycznie bezwartościowe.

Jakie pliki i dokumenty indeksowane w GSC nie mają odpowiednika w GA4?

GSC liczy kliknięcia w każdy zaindeksowany URL – w tym pliki PDF, obrazy w Google Images, pliki .xml, a nawet pliki .json. GA4 wymaga tagu JavaScript do rejestracji sesji, więc domyślnie nie widzi żadnego z tych formatów. Według naszych danych z 12 audytów e-commerce, pliki PDF odpowiadają za 2-7% kliknięć GSC w serwisach B2B (instrukcje, cenniki, katalogi). Te kliknięcia nigdy nie pojawią się w GA4 bez dedykowanego rozwiązania (np. event tracking w PDF viewerze).

Kolejny przypadek to Google Discover i Google News. Kliknięcia z Discover rejestruje zarówno GSC, jak i GA4 – ale w GSC pojawiają się w osobnym raporcie (Discover), a w GA4 jako sesje z organic. Jeśli porównujesz tylko dane z raportu „Search results” w GSC z GA4, brakuje Ci ruchu z Discover.

Co sprawdzić przed połączeniem GSC i GA4?

Pytanie	Status OK	Status ryzykowny
Czy property GA4 ma stream z poprawnym defaultUri?	defaultUri = domena GSC	defaultUri puste lub inna domena
Czy hostName w raportach GA4 zawiera hosta GSC?	Tak, w ostatnich 90 dniach	Brak lub inny host
Czy istnieje jawna mapa GSC-GA4?	configured_map z datą i autorem	Brak mapy, automatyczne dopasowanie
Czy property jest jedynym dopasowaniem?	domain_evidence_match, 1 property	ambiguous_domain_match, 2+ properties
Czy raport nie interpretuje braku mapy jako zero ruchu?	„brak dopasowania” w raporcie	„0 sesji” w raporcie
Czy strefa czasowa property jest ustawiona na CET/CEST?	Tak – spójne z lokalizacją biznesu	UTC lub Pacific Time – rozbieżność z GSC większa
Czy Consent Mode v2 jest wdrożony?	Tak – dane modelowane w GA4	Nie – 15-55% sesji niewidocznych

Zanim połączysz widoczność z konwersją, sprawdź, czy oba zbiory naprawdę opisują tę samą domenę. W przypadku sklepów internetowych błędne mapowanie może zafałszować cały obraz efektywności pozycjonowania sklepu.

Jak wygląda poprawne mapowanie w organizacji z wieloma markami?

Organizacje z kilkoma brandami (np. holdingowa spółka e-commerce z 5 sklepami) mają specyficzny problem: każdy sklep ma własną property GA4, ale konto GSC może obejmować wszystkie domeny pod jednym loginem. Bez jawnej mapy system musi rozstrzygać, do której z 5 properties przypisać każdy host GSC.

Nasze rozwiązanie to hierarchia configured_map na poziomie organizacji. Zamiast mapować hosty jeden po jednym, tworzymy mapę zbiorczą z regułami: domena A – property X, domena B – property Y, itd. Każda reguła ma datę ważności i osobę odpowiedzialną. Gdy ktoś dodaje nową domenę do organizacji, system wymaga jawnego przypisania zanim włączy raportowanie.

Badanie Adswerve opisuje cztery strategie śledzenia wielu domen: pojedyncza property z jednym streamem, wiele properties z cross-domain, rollup properties (tylko GA4 360) i subproperties (tylko GA4 360). Dla klientów spoza GA4 360 jedyna bezpieczna opcja to wiele properties z explicit configured_map – co jest dokładnie tym, co implementujemy.

Jakie narzędzia pozwalają zautomatyzować audyt mapowania?

Na rynku istnieje kilka narzędzi do audytu GA4 – np. GA4Audits.com uruchamia 229 automatycznych sprawdzeń konfiguracji, tagowania i jakości danych. Ale żadne z dostępnych publicznie narzędzi nie rozwiązuje specyficznie problemu mapowania GSC-GA4, ponieważ wymaga to jednoczesnego dostępu do obu API i porównania danych na poziomie hosta.

W Semgence rozwiązaliśmy to wewnętrznym narzędziem diagnostycznym, które w jednym przebiegu sprawdza resolver property GA4, diagnostykę mapowania URL i wykrywanie luk w śledzeniu. Wynik to raport ze statusem mapowania dla każdego hosta GSC, wraz z confidence score i rekomendowanym działaniem. Narzędzie jest częścią naszego pipeline audytu widoczności w AI – bo aby zmierzyć wpływ AI na ruch, najpierw musimy wiedzieć, czy w ogóle patrzymy na właściwe dane.

Dla firm, które nie korzystają z zewnętrznych narzędzi, minimalny audyt mapowania można przeprowadzić ręcznie w trzech krokach: (1) w GA4 Admin – Data Streams sprawdź defaultUri każdego streamu, (2) w GA4 Explore uruchom raport z wymiarem hostName za 90 dni, (3) porównaj wyniki z listą hostów w GSC. Całość zajmuje 15-30 minut dla jednej property, ale przy 10+ properties robi się niepraktyczna bez automatyzacji.

Jak duplikacja tagów GA4 wpływa na dane?

Problem pozornie niezwiązany z mapowaniem, ale w praktyce często mu towarzyszy. Gdy GA4 jest zainstalowany jednocześnie bezpośrednio w kodzie strony i przez Google Tag Manager, każda sesja jest liczona podwójnie. Raport MonsterInsights wymienia duplikację tagu jako jeden z 20 najczęstszych błędów GA4.

Połączenie duplikacji tagu z błędnym mapowaniem daje katastrofalne wyniki: raport pokazuje zawyżony ruch z GA4 (bo podwójne sesje) przypisany do złej domeny (bo błędna property). Klient widzi „świetne wyniki z organic”, a w rzeczywistości ani ruch, ani domena nie są poprawne. W naszej próbie 3 z 50 kont (6%) miały ten podwójny problem.

Czy server-side tagging rozwiązuje problem?

Server-side tagging (SST) nie rozwiązuje problemu mapowania, ale łagodzi problem utraty danych z powodu ad-blockerów i Consent Mode. Gdy GA4 zbiera dane przez first-party endpoint (np. analytics.mojadomena.pl zamiast www.google-analytics.com), blokery rzadziej filtrują requesty. To zmniejsza lukę między kliknięciami GSC a sesjami GA4.

Ale SST wprowadza nowy wariant problemu mapowania: endpoint first-party jest na domenie klienta, więc hostName w raportach GA4 może pokazywać domenę endpointu SST zamiast domeny strony. W naszej próbie 2 z 105 hostów miały tę konfigurację i resolver poprawnie zidentyfikował je jako domain_evidence_match – ale tylko dlatego, że sprawdzał faktyczny hostName z raportów, a nie URL endpointu.

Problematykę jakości danych GSC omawiamy również w kontekście kalibracji scoringu SEO na realnych danych oraz odświeżania treści w odpowiedzi na zmiany popytu w GSC.

Ramka metodologiczna. Dane z audytu mapowania GSC-GA4 na 50 kontach z portfolio Semgence (identyfikatory zanonimizowane). Narzędzia: wewnętrzne systemy diagnostyczne Semgence (resolver property GA4, diagnostyka mapowania URL, wykrywanie luk w śledzeniu) oraz dane bezpośrednio z GSC i GA4. Artykuł nie opiera się na patentach – opisywany problem dotyczy jakości danych i konfiguracji, nie mechanizmu wyszukiwania. Próba 105 hostów nie jest losowa – nadreprezentowane są sklepy e-commerce (43%) i serwisy B2B (31%). Wyniki dotyczą badanej próby i nie powinny być generalizowane bez zastrzeżeń. Badanie przeprowadzono w sierpniu 2026, dane historyczne obejmują okres 90 dni wstecz.