238 stron i cztery formularze
To case study o nas. Nasz serwis rósł szybciej niż jego mierzalność: 238 podstron i formularz kontaktowy na czterech z nich. Zanim zaczęliśmy naprawiać, zapisaliśmy stan wyjściowy z metodą pomiaru przy każdej liczbie, żeby dało się później sprawdzić, czy cokolwiek to dało.
Dlaczego pokazujemy własny serwis
Historię klienta z jego nazwą można opublikować dopiero po pisemnej zgodzie. Zbieramy te zgody dopiero teraz, więc zamiast zmyślać liczby dla anonimowej firmy, pokazujemy projekt, w którym klientem jesteśmy my sami. Cała korzyść jest po stronie czytelnika: każdą liczbę możemy podpisać metodą, którą ją policzyliśmy, i pokazać też tę część, która wypadła słabo.
Zasada, którą stosujemy w raportach dla klientów i której trzymamy się tutaj: liczba bez podanego źródła jest opinią, a nie wynikiem.
Serwis rósł, lejek nie istniał
Przez kilka miesięcy dokładaliśmy treści: wpisy, strony usług, karty tematyczne. Wszystko po to, żeby serwis miał głębię, którą lubi zarówno Google, jak i modele AI. Problem w tym, że rozbudowa treści wyprzedziła dwie nudne rzeczy, na których stoi cała reszta: możliwość zostawienia kontaktu i pomiar.
4 sierpnia 2026 policzyliśmy stan wyjściowy. Wyszło to.
| Miara | Stan wyjściowy | Jak policzone |
|---|---|---|
| Pliki HTML w serwisie | 238 | przejście po katalogach serwisu, 4 sierpnia 2026 |
| Strony z formularzem kontaktowym | 4 z 238 | wyszukanie znacznika formularza w plikach |
| Strony z kodem pomiarowym | 78 z 238 | wyszukanie kodu menedżera tagów |
| Strony z bannerem zgody | 168 z 238 | wyszukanie skryptu zgody |
| Adresy w głównej mapie witryny | 96 | zliczenie wpisów w pliku mapy |
| Strony poza mapami witryny | 112 z 238 | różnica liczby plików i adresów w obu mapach |
Prawie każda podstrona, którą ktoś mógł znaleźć w wyszukiwarce, była ślepą uliczką. Czytelnik docierał do treści, kiwał głową i nie miał gdzie kliknąć. Prawie połowa serwisu nie była nawet zgłoszona w mapie witryny.
Najpierw lejek, potem kolejne treści
Kolejność była świadoma i odwrotna do tej, którą wybiera większość firm. Nie dołożyliśmy ani jednej nowej strony, dopóki istniejące nie miały gdzie prowadzić czytelnika i dopóki nie było widać, co się na nich dzieje.
- Spisaliśmy stan wyjściowy w jednym dokumencie, z jawnym źródłem każdej liczby i osobną listą rzeczy, których celowo nie mierzyliśmy. Bez tego nie dałoby się później udowodnić żadnej poprawy.
- Napisaliśmy narzędzie, które przechodzi rekurencyjnie po wszystkich podstronach, także zagnieżdżonych, i wstrzykuje ten sam formularz kontaktowy w jedno oznaczone miejsce w kodzie.
- Analogicznie z pomiarem i zgodą na pliki cookie: jedno narzędzie, jeden znacznik, jeden przebieg po całym serwisie.
- Jeden generator mapy witryny i pliku
llms.txt, żeby żadna nowa podstrona nie mogła już wypaść poza indeksowanie. - Zamknięcie duplikatów adresów przekierowaniami stałymi, z tą samą listą reguł w konfiguracji obu serwerów, bo rozjazd między nimi jest najczęstszym źródłem cichych błędów.
- Formularz podpięty do własnego systemu obsługi zgłoszeń, z pułapką na boty i informacją o przetwarzaniu danych przy każdym wysłaniu.
Stan po pracach, policzony tą samą metodą
Liczby poniżej policzyliśmy 5 sierpnia 2026 w źródle serwisu, dokładnie tymi samymi poleceniami co przy stanie wyjściowym. To jedyny sposób, żeby porównanie miało sens.
- Na 5 sierpnia 2026 serwis liczył 278 plików HTML, czyli w międzyczasie urósł, a mimo to udział stron bez formularza i bez pomiaru spadł do pojedynczych przypadków.
- Reszta to strony, które formularza mieć nie powinny: polityka prywatności, regulamin, strona błędu, pliki techniczne.
- Duplikaty adresów zamknięte przekierowaniami stałymi po obu stronach konfiguracji, więc ta sama treść przestała występować pod kilkoma adresami.
Czego nadal nie umiemy udowodnić
Nie pokazujemy ruchu z wyszukiwarki ani liczby zgłoszeń z formularza w podziale na źródła. Konto usługi, przez które nasz panel sięga po dane z Google Search Console i Analytics, zwraca błąd autoryzacji, a pliki z odczytami są puste. Do czasu naprawy każda liczba o ruchu byłaby zmyślona, więc jej tu nie ma.
To jest zresztą najlepsza ilustracja tezy z tego case study. Możesz mieć poprawnie zbudowany lejek i i tak nie umieć pokazać wyniku, jeśli pomiar nie działa. Dlatego przy klientach zaczynamy od dostępów, a nie od treści.
Ile to trwało
| Etap | Kiedy | Co się działo |
|---|---|---|
| Pomiar stanu wyjściowego | 4.08.2026 | Policzenie serwisu, danych panelu i infrastruktury, spisanie tego, czego świadomie nie mierzymy. |
| Naprawa lejka i pomiaru | 4-5.08.2026 | Wstrzyknięcie formularza, kodu pomiarowego i zgody w cały serwis, jeden generator mapy witryny, zamknięcie duplikatów adresów. |
| Stan końcowy | 5.08.2026 | Przeliczenie tymi samymi poleceniami i porównanie z dokumentem wyjściowym. |
| Otwarte | - | Przywrócenie dostępu do danych z wyszukiwarki, bez którego nie ma jak pokazać efektu na ruchu. |
Praca, która zamieniła cztery formularze na dwieście dwadzieścia trzy, zajęła dwa dni. Nie dlatego, że jesteśmy szybcy, tylko dlatego, że zrobiło ją narzędzie przechodzące po plikach, a nie człowiek klikający w każdą podstronę.
Co z tego wynika, jeśli masz podobną firmę
- Policz, zanim zaczniesz. Trzy liczby wystarczą na start: ile masz podstron, na ilu da się zostawić kontakt, ile z nich jest w mapie witryny. Bez nich nie udowodnisz sobie ani agencji, że coś się poprawiło.
- Formularz na każdej stronie, nie tylko na kontakcie. Ludzie z wyszukiwarki i z odpowiedzi AI wchodzą w głąb serwisu, a nie na stronę główną. Jeśli tam nie ma jak się odezwać, cała praca nad treścią kończy się cudzą wizytą.
- Jedno narzędzie zamiast ręcznego wklejania. Kod pomiarowy wklejany ręcznie zawsze gdzieś wypadnie. Generator przechodzący po plikach nie zapomina.
- Reguły przekierowań muszą być w każdej konfiguracji serwera, jakiej używasz. Regułę dopisaną w jednym miejscu i pominiętą w drugim widać dopiero wtedy, gdy zaczyna szkodzić.
- Dostępy do pomiaru załatw pierwszego dnia. To najnudniejszy punkt każdej współpracy i jedyny, którego brak potrafi unieważnić raport z całego kwartału.
Trzy pytania, które dostajemy o to case study
Bo publikacja historii klienta z nazwą wymaga jego pisemnej zgody, a my zbieramy te zgody dopiero teraz. Na własnym serwisie nikogo o zgodę pytać nie musimy i możemy pokazać surowe liczby razem z metodą, którą je policzyliśmy.
Konto usługi, przez które panel pobiera dane z Google Search Console i Analytics, zwraca błąd autoryzacji. Dopóki tego nie naprawimy, nie mamy prawa pokazywać liczb o ruchu, więc ich nie pokazujemy.
Od policzenia trzech rzeczy: ile masz podstron, na ilu z nich da się zostawić kontakt i ile z nich w ogóle jest w mapie witryny. Te trzy liczby zwykle wystarczą, żeby zobaczyć, gdzie ucieka efekt pracy nad treścią.
Chcesz mieć takie same liczby o swojej stronie
Podaj adres, a policzymy to samo u Ciebie: ile podstron zna Google, na ilu można zostawić kontakt i czego brakuje, żeby modele AI miały Cię za co cytować. Za darmo, w pięć dni roboczych.