Ten materiał to szczegółowe, przed-i-po studium przypadku fikcyjnej firmy Metria Cloud — B2B SaaS działającego w obszarze analityki produktowej dla zespołów enterprise. Serwis miał w momencie rozpoczęcia audytu około 3000 zaindeksowanych podstron, cztery wersje językowe, blog, centrum pomocy oraz rozbudowane katalogi integracji. Celem było przeprowadzenie pełnego audytu technical SEO w ciągu 8 tygodni, wdrożenie rekomendacji i pomiar efektów w jasno określonych oknach czasowych. Case jest fikcyjny, ale wszystkie liczby, procesy i sekwencje decyzji odwzorowują realne projekty o podobnej skali i złożoności.
Nie chcemy pokazać tu „10 trików SEO”. Chcemy pokazać, jak wygląda dobrze poukładany audyt techniczny w B2B: od diagnostyki, przez priorytety, aż po stabilne wyniki, które utrzymują się w kolejnych kwartałach. Jeśli szukasz szerszego kontekstu strategicznego, zajrzyj później do naszego materiału o audycie technical SEO krok po kroku oraz do powiązanego studium odbudowy widoczności B2B SaaS. Dziś skupiamy się wyłącznie na tym konkretnym projekcie.
Stan początkowy: z czym zaczynaliśmy
Metria Cloud trafiła do nas po 18 miesiącach od dużego redesignu, który — jak pokazała diagnoza — został zrobiony bez konsultacji z zespołem SEO. Efektem było rozlane drzewo URL, kilkaset duplikatów, ciężki front-end i brak spójnej strategii indeksacji. Klient raportował trzy główne bóle: spadek ruchu organicznego o 34 procent rok do roku, drastyczny wzrost kosztu pozyskania lead’a z kanału SEO oraz zauważalny spadek widoczności na frazy kategorii „product analytics” i „feature flags”. Dodatkowo GSC pokazywało masowe „Odkryto — obecnie nie zaindeksowano” dla świeżej dokumentacji.
Zanim przeszliśmy do jakichkolwiek rekomendacji, uruchomiliśmy pełen zaciąg danych: crawl całego serwisu (Screaming Frog SEO Spider plus crawler własny obsługujący render JS), eksport logów serwerowych z 90 dni, Google Search Console (Search Analytics + Index Coverage + Crawl Stats), GA4 z kanałami i atrybucją, Chrome UX Report, PageSpeed Insights dla dwunastu reprezentatywnych szablonów, Ahrefs i Semrush dla widoczności historycznej oraz Semtools dla kontekstu rynkowego. Dopiero po 10 dniach zbierania i czyszczenia danych zaczęliśmy formułować hipotezy — to ważne, bo większość błędów audytowych bierze się z przedwczesnych wniosków.
Na wejściu obraz był trudny. Mediana LCP z CrUX dla sekcji product (/product/*) wynosiła 4,8 s, INP 312 ms, CLS 0,19. Google indeksował tylko 47 procent ważnych URL z sitemapy. Średni czas do pierwszego crawla nowego URL to 11,3 dnia. Roboty tracily 38 procent budżetu crawla na URL z parametrami śledzącymi, paginacjami filtrów i kombinacjami facetów w sekcji /integrations/. JS-owy hydration dominował w Total Blocking Time, a ścieżki CSS ważyły 780 KB przed minifikacją. Meta tagi, dane strukturalne i hreflang były rozspójnione po migracji. Krótko: typowy B2B technical-debt package, tylko w większej skali.
Ważny kontekst biznesowy: Metria Cloud w momencie audytu miała MRR rzędu 1,4 mln USD, 78 procent nowych lead’ów z kanałów płatnych, 12 procent z SEO, 10 procent z referral i partnerstw. W planie strategicznym zarządu była odwrotna proporcja w horyzoncie 18 miesięcy — więcej SEO, mniej paid. Bez fundamentów technicznych taki pivot jest niemożliwy, bo kanał organiczny nie skaluje się bez zdrowej infrastruktury. Audyt miał więc nie tylko cel taktyczny (ruch, lead’y), ale strategiczny (udowodnić, że SEO może być kanałem numer jeden) — to warto mieć na uwadze, czytając dalsze decyzje projektowe.
Dodatkową warstwą komplikacji była struktura zespołu po stronie klienta. Zespół developerski liczył 14 osób podzielonych na trzy squady (product, platform, growth). Każdy squad miał własny backlog, własne okno deploy’u i własny poziom znajomości SEO (od bardzo wysokiego w growth do zerowego w platform). Pierwsze dwa tygodnie projektu zainwestowaliśmy nie tylko w zaciąg danych, ale też w mapowanie zależności organizacyjnych. Jeśli nie wiesz, czyj pull request zatwierdza zmianę w robots.txt, to ta zmiana nie wejdzie nigdy.
Kluczowe problemy — siedem obszarów, które zdecydowały o wyniku
Po przemieleniu danych wyłoniliśmy siedem obszarów o największym wpływie na ruch i konwersję. Każdy z nich miał przypisaną hipotezę, metrykę sukcesu, właściciela po stronie klienta i zdefiniowany rozmiar wysiłku wdrożeniowego w story points. To nie jest luksus — to warunek powodzenia w projekcie, w którym równolegle pracuje zespół contentowy, developerski i platformowy.
1. Rozlane drzewo URL i duplikacja w sekcji integracji
/integrations/ generowało ponad 1100 unikalnych adresów z parametrami utm, filtrami kategorii integracji, sortowaniem i stronicowaniem. 61 procent tych URL zwracało 200, ale miało niemal identyczną treść. Duplikaty marnowały crawl, rozmywały sygnały i blokowały indeksację kluczowych podstron integracji biznesowych (HubSpot, Salesforce, Segment).
2. Crawl budget zżerany przez parametry śledzące i facety
Analiza logów z Cloudflare pokazała, że 38 procent wszystkich requestów Googlebota szło do URL z parametrami, których nie powinien w ogóle odwiedzać. Dodatkowo paginacja w blogu generowała sztuczne głębokości (strona 37, 38, 39), a Googlebot honorowo przez nie przechodził, porzucając świeżo opublikowane URL na listach kategorii.
3. LCP w szablonach product i pricing
Mediana LCP 4,8 s na /product/* brała się z trzech rzeczy naraz: render-blocking CSS (blokujące ok. 1,6 s), hero video ładowane w eager mode bez placeholdera oraz font swap opóźniony o 900 ms przez FOUT/FOIT mix. Na urządzeniach mobilnych było jeszcze gorzej — 5,7 s w P75 CrUX.
4. CLS na stronach dokumentacji i w listach blogowych
CLS 0,19 (czyli „Poor” w CrUX) pochodził z trzech źródeł: dynamicznie wstrzykiwane banery consentowe bez zarezerwowanej wysokości, obrazy w listach artykułów bez width/height, oraz komponent „polecane integracje” ładowany async po interakcji użytkownika. Skutek: czytelnicy tracili pozycję na stronie, a Googlebot mierzył to wszystko w raportach.
5. Fragmentaryczne dane strukturalne i hreflang
Po migracji schema Article była obecna, ale zdezaktualizowana (stare daty), schema Product dla sekcji cennikowej nie miała ceny ani availability, a hreflang pominął język niemiecki w około 420 URL. Rezultat: Google pokazywał angielskie wersje niemieckim użytkownikom, co psuło CTR i bounce-adjusted engagement.
6. Architektura wewnętrznych linków
Pillar pages o największej wadze biznesowej („product analytics”, „event tracking”, „feature flags management”) miały po 12–18 linków wewnętrznych przychodzących. Dla kontekstu: konkurencja w segmencie utrzymywała 60–120 linków przychodzących na swoje pillary. Bez masowej przebudowy internal linking nie było sposobu na ruch ze stronę „product analytics”, bo autorytet strony głównej nie przepływał głęboko.
7. Indeksacja dokumentacji i centrum pomocy
Dokumentacja (/docs/*) — najcenniejszy zasób B2B SaaS dla „informacyjnych” fraz top-of-funnel — miała wskaźnik indeksacji 42 procent. Część URL była zablokowana w robots.txt przez niefortunny wildcard, część miała duplikat „x-default” w hreflang kierujący na zmienioną strukturę, a część (około 280 URL) była oznaczona noindex po starym wdrożeniu preview.
Rozwiązania — co i jak wdrożyliśmy w 8 tygodni
Wdrożenie podzieliliśmy na cztery sprinty dwutygodniowe. Każdy sprint miał jasne kryteria wyjścia, osobę odpowiedzialną i metrykę potwierdzającą, że zmiana zadziałała. To jest kluczowe — bez twardych kryteriów wyjścia projekty technical SEO kończą się „trochę lepiej” zamiast „o 40 procent lepiej”.
Sprint 1 (tydzień 1–2): fundament crawlu i indeksacji
Zaczęliśmy od warstwy robots.txt i architektury URL. Zbudowaliśmy nowy plik robots.txt z wykluczeniami parametrów śledzących (Disallow na wzorce *utm_* oraz */?sort=, */?filter=, */?page= powyżej strony 5) oraz jasno zdefiniowanym Sitemap. Następnie skonsolidowaliśmy 11 sitemap w pięciu logicznych grupach (product, integrations, blog, docs, static), z których każda miała limit 45 tys. URL i lastmod aktualizowany on-deploy.
Równolegle wdrożyliśmy canonical self-referencing dla wszystkich stron listowych, canonical „strona bazowa” dla paginacji filtrów, i rel=prev/next zostawiliśmy wyłącznie dla paginacji głównej bloga. Dla /integrations/* wprowadziliśmy whitelisting — tylko 180 kanonicznych URL może być indeksowanych, reszta ma noindex + canonical do strony bazowej kategorii. Brzmi drastycznie, ale to właśnie było źródło 61 procent duplikacji.
Sprint 2 (tydzień 3–4): Core Web Vitals
W sprincie drugim zajęliśmy się wydajnością. Critical CSS zredukowaliśmy z 780 KB do 214 KB poprzez PurgeCSS, podział na szablony, oraz wczytywanie reszty z media="print" onload="this.media='all'". Fonty przenieśliśmy na font-display: swap z preload dla głównych wariantów (400 i 700). Hero video w /product/* zamieniliśmy na obraz poster WebP + lazy video (klikalne) na mobile, co zbiło LCP w P75 z 5,7 s do 2,6 s w ciągu trzech tygodni po wdrożeniu.
CLS pociąłem w trzech miejscach jednocześnie. Banery consent dostały stałą wysokość i mount przed hydration. Wszystkie obrazy zyskały atrybuty width/height z aspect-ratio w CSS. Komponent „polecane integracje” został przepisany na SSR z zarezerwowanym slotem. Po 21 dniach od deploy’u mediana CLS z CrUX spadła z 0,19 do 0,05, czyli w zieloną strefę.
Sprint 3 (tydzień 5–6): dane strukturalne, hreflang, indeksacja dokumentacji
Zaktualizowaliśmy schema Article o datePublished + dateModified z rzeczywistych commitów CMS, dorzuciliśmy Author z URL do profilu autora, oraz breadcrumbs BreadcrumbList na wszystkich szablonach głębokości 3+. Dla /pricing/* wdrożyliśmy schema Product z ofertami per plan (Offer.priceCurrency, Offer.price, Offer.availability). Schema FAQPage wróciła na 34 pillary (tam, gdzie było to merytorycznie uzasadnione) i działała zgodnie z wytycznymi Google.
Hreflang przeszedł pełną regenerację z poziomu CMS — wspólne pole source-of-truth, alternatywne wersje automatycznie walidowane, x-default dla rynku globalnego. Dla /docs/* zdjęliśmy noindex z 281 URL, odblokowaliśmy w robots.txt ścieżki /docs/api/*, zbudowaliśmy dedykowaną sitemap docs z priority 0.8 i częstością „weekly”. W ciągu 10 dni wskaźnik indeksacji docs wzrósł z 42 do 81 procent.
Sprint 4 (tydzień 7–8): internal linking i finał
Ostatni sprint był skupiony na internal linking i konsolidacji. Zbudowaliśmy matrix „hub → spoke” dla trzech głównych pillarów. Każdy pillar zyskał 40–60 dodatkowych linków przychodzących z odpowiednich artykułów bloga, stron docs i stron case study. Linki były kontekstowe (nie stopkowe), z anchor textami zgodnymi z intencją. W tym momencie warto też podlinkować szerszy kontekst — zobacz nasz materiał o internal linking dla B2B SaaS.
Dodatkowo wdrożyliśmy 301 dla 340 URL zidentyfikowanych jako duplikaty historyczne (z migracji sprzed 18 miesięcy). Dla ważniejszych redirectów dopisaliśmy ręczne linki zastępcze na żywych stronach, żeby równoważyć rozpływ autorytetu. Przeprowadziliśmy też pełny re-submit sitemapy po każdym sprincie, a na koniec uruchomiliśmy IndexNow dla /blog/* i /docs/* (Bing, Yandex, DuckDuckGo honorują). Polecamy przejrzeć dokumentację web.dev Vitals oraz Google Search Central po więcej kontekstu metodologicznego.
Dodatkowe prace wdrożeniowe w Sprincie 4
Poza internal linkingiem i redirectami, w sprincie 4 zamknęliśmy kilka rzeczy, które często są pomijane w projektach technical SEO. Zbudowaliśmy dashboard w Looker Studio, który łączy GSC, GA4 i logi w jednym widoku — z alertowaniem na nagłe spadki crawl rate i indeksacji. Do repozytorium dodaliśmy pre-commit hook sprawdzający, czy nowe strony mają podstawowe elementy SEO (title, meta description, canonical, hreflang, schema). Dla zespołu contentowego przygotowaliśmy szablon briefu, który automatycznie sprawdza, czy proponowana fraza ma sens z perspektywy architektury informacji (czy nie duplikuje pillara, czy jest miejsce w klastrze, czy ma wystarczający wolumen).
Ostatnim elementem sprintu 4 była walidacja end-to-end. Przeprowadziliśmy drugi pełen crawl (dokładnie tym samym setupem, co na wejściu), porównaliśmy wynik z baseline i opisaliśmy wszystkie różnice. Zamknęliśmy 247 issue’ów z backlogu SEO, z czego 189 było high-priority. 58 pozostałych zostało świadomie odłożonych na następny kwartał, bo ich wpływ biznesowy był niższy niż koszt wdrożenia — to też decyzja, którą trzeba świadomie podjąć i udokumentować. Na koniec zrobiliśmy tygodniowy freeze zmian technicznych, żeby algorytm Google dostał stabilny obraz do przeliczenia.
Rezultaty — co się zmieniło w liczbach
Efekty mierzyliśmy w trzech oknach: +4 tygodnie po zakończeniu sprintów (wczesne sygnały), +8 tygodni (stabilizacja) oraz +16 tygodni (trwały efekt). W każdym oknie raportowaliśmy tę samą metrykę, tym samym źródłem, o tej samej porze, żeby nie wprowadzać szumu porównawczego. Poniżej ujęcie w oknie +16 tygodni — najuczciwsze dla B2B, gdzie cykl decyzyjny jest długi i wyniki SEO stabilizują się dopiero po kwartale.
Ruch organiczny w oknie +16 tygodni vs. baseline wzrósł o 73 procent (sesje organiczne w GA4). Pozycje top-10 dla zdefiniowanej listy 200 fraz komercyjnych i informacyjnych wzrosły z 48 do 127. Indexed pages z sitemapy wzrosły z 1410 do 2680 (z 3000 ważnych URL). Średni czas do pierwszego crawla nowego URL spadł z 11,3 dnia do 2,1 dnia. Koszt pozyskania leada z SEO spadł o 41 procent przy jednoczesnym wzroście liczby leadów — co oznacza, że efekt jest dwukierunkowy: więcej leadów taniej.
Tabela: metryki przed i po — szczegółowo
| Metryka | Baseline (T0) | Po +4 tyg. | Po +8 tyg. | Po +16 tyg. (cel) | Zmiana (T0 → +16 tyg.) |
|---|---|---|---|---|---|
| LCP P75 /product/* (mobile) | 5,7 s | 3,1 s | 2,6 s | 2,5 s | -56 procent |
| LCP P75 /product/* (desktop) | 4,8 s | 2,3 s | 1,9 s | 1,8 s | -62 procent |
| INP P75 (cały serwis) | 312 ms | 221 ms | 178 ms | 162 ms | -48 procent |
| CLS P75 (cały serwis) | 0,19 | 0,09 | 0,05 | 0,04 | -79 procent |
| Crawl budget na „śmieciowe” URL | 38 procent | 19 procent | 9 procent | 6 procent | -84 procent |
| Indeksacja URL z sitemapy | 1410 (47 procent) | 1820 (61 procent) | 2310 (77 procent) | 2680 (89 procent) | +90 procent URL |
| Indeksacja /docs/* | 42 procent | 81 procent | 88 procent | 94 procent | +124 procent |
| Średni czas do pierwszego crawla | 11,3 dnia | 5,8 dnia | 3,1 dnia | 2,1 dnia | -81 procent |
| Pozycje top-10 (200 fraz) | 48 | 67 | 94 | 127 | +165 procent |
| Pozycje top-3 (200 fraz) | 12 | 19 | 31 | 48 | +300 procent |
| Ruch organiczny (sesje GA4, mies.) | 84 300 | 98 100 | 121 400 | 145 900 | +73 procent |
| Lead’y z SEO (mies.) | 112 | 134 | 171 | 204 | +82 procent |
| CPL z SEO | 240 USD | 205 USD | 162 USD | 141 USD | -41 procent |
| Widoczność Semrush (SI) | 14,2 | 17,8 | 22,4 | 26,9 | +89 procent |
| Bounce-adjusted engagement | 0,41 | 0,47 | 0,53 | 0,58 | +41 procent |
Warto zwrócić uwagę na dwa elementy. Po pierwsze — najszybciej poprawiły się metryki techniczne (LCP, CLS, crawl budget), bo są najbliżej deploy’u. Po drugie — metryki biznesowe (lead’y, CPL, widoczność) potrzebowały 12–16 tygodni, żeby się ustabilizować, bo algorytm musi przetworzyć zmiany i użytkownicy muszą zacząć inaczej zachowywać się na stronie. Proporcja zmian (gorące metryki szybko, chłodne metryki wolno) jest typowa dla B2B SaaS o tej skali.
Trzeci istotny wniosek z tabeli: efekty kumulują się w czasie. Wzrost pozycji top-3 z 12 do 48 (czyli czterokrotny) jest nieliniowy — pierwsze 20 pozycji pojawia się w tygodniach 5–9, kolejne 16 w tygodniach 10–14, a ostatnie 12 dopiero w tygodniach 15–16. To dokładnie pokazuje, dlaczego raportowanie efektów audytu w tygodniu 8 daje połowiczny obraz. Stakeholderzy w B2B SaaS muszą być przygotowani na tę kadencję od początku projektu, inaczej stracą cierpliwość i zaczną wprowadzać zmiany, które zaburzą trajektorię.
Warto też skomentować relację między LCP a lead’ami. Na pierwszy rzut oka to metryki z dwóch różnych światów. W rzeczywistości łączą je dwie rzeczy: (1) szybsza strona ma wyższy completion rate formularzy rejestracyjnych — w Metria Cloud wzrost z 2,1 do 3,4 procenta po poprawie LCP, (2) lepsze sygnały techniczne przekładają się na wyższe pozycje na frazach transakcyjnych, a te frazy konwertują 3–4 razy lepiej niż informacyjne. W efekcie poprawa techniczna daje dźwignię w dwóch miejscach naraz — dlatego w B2B inwestycja w CWV zwraca się szybciej niż w e-commerce, gdzie konwersja jest jednoetapowa.
Framework replikacji — jak zrobić to samo na swojej stronie
Poniżej numerowany framework, który wdrażamy w każdym projekcie technical SEO B2B o skali 1000+ URL. Jeśli chcesz zreplikować ten wynik na swojej stronie, zacznij od góry i nie przeskakuj punktów. Kolejność ma znaczenie, bo każdy następny krok korzysta z efektów poprzedniego.
- Zaciąg danych (dni 1–10). Uruchom pełen crawl (Screaming Frog lub Sitebulb plus crawler z renderem JS), wyeksportuj logi serwera z 90 dni, zbierz GSC (Search Analytics, Index Coverage, Crawl Stats), CrUX dla topowych szablonów, GA4, Ahrefs lub Semrush. Zbierz wszystkie dane zanim zaczniesz formułować hipotezy — to eliminuje bias.
- Segmentacja URL (dni 11–14). Podziel wszystkie URL na sekcje (product, blog, docs, integrations, static, listing, paginacja, parametry). Przypisz każdej sekcji intent (transakcyjny, informacyjny, nawigacyjny) i typ (hub, spoke, pomocniczy). Bez segmentacji nie wiesz, które URL są ważne.
- Identyfikacja problemów (dni 14–20). Dla każdej sekcji wylicz metryki: LCP, CLS, INP, wskaźnik indeksacji, crawl frequency, głębokość klikalna, liczba linków przychodzących, spójność schematów. Problemy rankuj po (impact x reach) / effort.
- Priorytetyzacja (dni 21–25). Weź top 10 problemów po score. Dla każdego zdefiniuj hipotezę, oczekiwany efekt, metrykę sukcesu, właściciela i termin. Reszty nie ruszaj — to zabije projekt.
- Sprint 1: fundament (tydzień 4–5). Robots.txt, sitemapy, canonicale, noindex na duplikatach, 301 na URL historycznych. To sprzątanie, które odblokowuje wszystko inne.
- Sprint 2: Core Web Vitals (tydzień 6–7). Critical CSS, lazy loading, font swap, aspect-ratio dla obrazów, SSR dla komponentów dynamicznych. Cel: wszystkie szablony w zielonej strefie CrUX w oknie +28 dni.
- Sprint 3: dane strukturalne i indeksacja (tydzień 8–9). Schema per szablon (Article, Product, FAQPage, BreadcrumbList), hreflang regeneracja z single source of truth, odblokowanie sekcji dokumentacji.
- Sprint 4: internal linking i konsolidacja (tydzień 10–11). Matrix hub-spoke, 40–60 nowych linków na pillar, anchor texts zgodne z intencją, re-submit sitemap, IndexNow dla najświeższych sekcji.
- Okno stabilizacji (tydzień 12–16). Nic nie ruszaj. Mierz tygodniowo. Pozwól algorytmowi przeliczyć sygnały. Raportuj do stakeholderów w tej samej kadencji i tym samym formacie.
- Retrospektywa i roadmap (tydzień 16–17). Sprawdź, które zmiany przyniosły największy zwrot. Zaktualizuj framework dla tego konkretnego klienta. Zdefiniuj next steps na kolejny kwartał — bez tego wyniki zaczną dryfować.
Najczęstsze błędy — czego nie robić, nawet jeśli kusi
W projektach B2B SaaS o skali 1000+ URL regularnie widzimy te same pomyłki. Jeżeli planujesz podobny audyt, miej je na oku — każdy z nich potrafi zniszczyć efekty całego sprintu.
- Wdrożenie zmian przed zaciągiem danych. Najczęstszy błąd. Zespół widzi „oczywiste” problemy i zaczyna poprawiać, zanim zmierzy. Efekt: pierwszy sprint poprawia metryki, których nikt nie mierzył, a prawdziwe źródła problemu zostają.
- Traktowanie crawl budget jak mitu. W serwisach 200-stronicowych to rzeczywiście mit. W serwisach 3000+ z facetami i parametrami — to twarda rzeczywistość, która decyduje o 30–40 procentach widoczności.
- Wdrażanie noindex bez canonical. Noindex bez canonical powoduje, że Google traci sygnał o kanonicznej wersji i w długim okresie może de-indeksować też strony, które chcesz mieć zaindeksowane.
- Lift-and-shift schematów z innego projektu. Schema ma być kontekstowa. Schema Product na stronie „o nas” nie pomoże, a potrafi zaszkodzić.
- Agresywna przebudowa internal linking w jednym deploy’u. Zamiast dodać 60 linków naraz — rozłóż na 3–4 tygodnie. Google lepiej przetworzy stopniową zmianę i nie potraktuje jej jako manipulacji.
- Pomijanie /docs/*. Dokumentacja to krypto-skarb B2B SaaS. Jeżeli jej nie indeksujesz, oddajesz 30–40 procent top-of-funnel konkurencji.
- Raportowanie tylko ruchu. Ruch bez lead’ów to vanity. Raportuj zawsze parę ruch + konwersja, bo tylko wtedy widzisz, czy zmiany technical SEO przełożyły się na biznes.
- Brak okna stabilizacji. Projekty kończone w tygodniu 8 zamiast 16 dają 50–60 procent maksymalnego wyniku. Cztery tygodnie dodatkowej cierpliwości dają resztę.
FAQ — najczęściej zadawane pytania
Czy 8 tygodni to realny horyzont na audyt technical SEO serwisu B2B o skali 3000 URL?
Tak, pod warunkiem że zespół developerski ma przynajmniej 40 procent pojemności zarezerwowane na wdrożenia z backlogu SEO oraz że product management akceptuje bufor na refactor. Bez tych dwóch rzeczy realne okno to 12–14 tygodni.
Jak szybko widać efekty w Google Search Console?
Pierwsze sygnały (wzrost crawl rate, spadek liczby błędów) widać w 7–10 dni po zakończeniu sprintu 1. Pozycje zaczynają drgać w okolicy tygodnia 4–5. Stabilny wzrost ruchu organicznego pojawia się w oknie 12–16 tygodni. Wszystko krótsze to szum.
Czy Core Web Vitals naprawdę wpływają na pozycje?
Wpływają, ale pośrednio. Bezpośredni wpływ jest niewielki (ok. 1–3 procent), ale CWV decydują o dwóch rzeczach: bounce-adjusted engagement (który wpływa na sygnały behawioralne) oraz crawl efficiency (szybsze strony są częściej crawlowane). W sumie pełne wdrożenie CWV daje 10–20 procent efektu w rankingu.
Dlaczego indeksacja dokumentacji jest tak ważna dla B2B SaaS?
Dokumentacja pokrywa frazy informacyjne top-of-funnel („how to”, „what is”, „api reference”), które generują 30–50 procent ruchu organicznego w kategorii i ściągają intencję edukacyjną. Dobrze zindeksowana dokumentacja to jedna z najtańszych dźwigni ruchu w B2B.
Co z AI Overviews i cytowaniami w ChatGPT, Perplexity, Gemini?
Ten audyt nie był pod AIO. W oknie +16 tygodni zaobserwowaliśmy wzrost cytowań w Perplexity o 140 procent i w ChatGPT o 86 procent, ale to efekt uboczny — lepsza indeksacja, bardziej spójne dane strukturalne i poprawiona treść podnoszą też widoczność w modelach. Dedykowany layer AIO robi się jako osobny projekt po fundamentach technical.
Czy trzeba robić migrację CMS, żeby zrobić taki audyt?
Nie. W tym case’ie nie było migracji. Wszystkie zmiany były dostępne z poziomu istniejącego CMS (headless Next.js + Sanity) plus konfiguracji CDN (Cloudflare). Migracja CMS jest potrzebna tylko wtedy, gdy obecny system nie pozwala na podstawowe operacje (schema per szablon, hreflang per URL, canonical control).
Jak pogodzić tempo wdrożenia z code review i quality gate?
Robimy to przez feature flags plus canary deploy. Każda zmiana technical SEO wchodzi najpierw na 10 procent ruchu, monitorujemy 48 godzin, potem 50 procent, potem pełny rollout. Nie traci się tempa, a bezpieczeństwo wdrożeń jest zachowane.
Ile kosztuje taki audyt i wdrożenie po stronie agencji?
Przy skali 3000 URL — 8 tygodni audytu z wdrożeniem mieści się zwykle w przedziale 40–70 tys. USD po stronie usługi, plus proporcjonalne zaangażowanie zespołu klienta (2 developerów part-time, 1 content lead, 1 product manager na 0,2 FTE). Zwrot z inwestycji w modelu B2B SaaS widać zwykle po 6–9 miesiącach od zakończenia projektu.
Jak wygląda raportowanie do zarządu w trakcie projektu?
Co dwa tygodnie, zawsze w tym samym formacie: jedna strona z trzema sekcjami. Pierwsza sekcja — metryki techniczne (LCP, CLS, INP, crawl rate, indeksacja). Druga — metryki biznesowe (pozycje, ruch, lead’y, CPL). Trzecia — blokery i decyzje wymagane od zarządu. Bez narracji, bez slide’ów, bez wykresów po 20 minutach pracy w PowerPoincie. Zarząd w B2B SaaS żyje decyzjami, nie estetyką — format musi to odzwierciedlać.
Czy ten framework działa też dla stron 500–1500 URL?
Działa, ale sprinty można skrócić do jednego tygodnia i cały projekt zamknąć w 4–5 tygodniach. Główne różnice: crawl budget rzadko jest problemem przy 500 URL, więc sprint 1 jest krótszy. Internal linking też jest prostszy, bo mniej węzłów w grafie. Za to Core Web Vitals są identycznym problemem w każdej skali — technologia frontend’u nie zależy od liczby URL.
Jakie narzędzia są absolutnie niezbędne do takiego audytu?
Minimum: crawler (Screaming Frog lub Sitebulb), dostęp do logów serwera, GSC, GA4, CrUX API, PageSpeed Insights. Opcjonalnie, ale mocno pomaga: Ahrefs lub Semrush dla historycznej widoczności, Looker Studio lub Power BI dla dashboardów, BigQuery dla analityki na dużych zbiorach logów. Pakiet narzędziowy dla projektu 3000 URL to zwykle koszt 800–1500 USD miesięcznie przez 3 miesiące — pomijalny wobec efektu biznesowego, ale warto go zaplanować na początku projektu, żeby nie dublować subskrypcji.
Co zrobić, jeśli zarząd nie chce czekać 16 tygodni?
Można zrobić mini-audyt w 3 tygodnie, skupiony tylko na top 5 problemach po score impact/effort. Wyniki będą słabsze (zwykle 30–40 procent efektu pełnego audytu), ale pojawią się szybciej i pokażą kierunek. Kluczowe: z góry zakomunikować, że to jest mini-wersja, a nie pełen audyt. W przeciwnym razie zarząd uzna wynik za niepowodzenie, zamiast za dowód, że warto robić pełną wersję.
Co dalej — jak utrzymać i rozwinąć wynik
Wynik +73 procent ruchu i -41 procent CPL nie jest stanem końcowym. To punkt startowy do kolejnych kwartałów. Z naszego doświadczenia w podobnych projektach B2B SaaS po 16 tygodniach stabilizacji warto wejść w trzy równoległe strumienie pracy, które domykają system i zamieniają jednorazowy skok w trwałą dźwignię.
Pierwszy strumień to continuous technical health. Po takim audycie serwis ma niską „technical debt”, ale każdy deploy może ją podnosić. Dlatego wdrażamy automatyczne testy CWV w CI/CD (np. Lighthouse CI z progami regresji na PR), cotygodniowy crawl diff (pokazuje zmiany w statusach, canonicalach, schematach od ostatniego tygodnia), oraz alertowanie na nagłe skoki w GSC (Index Coverage, Crawl Stats). Bez tego po trzech miesiącach technical debt zacznie wracać, bo zespół produktowy nie pamięta o SEO przy każdym feature.
Drugi strumień to content ekspansja na bazie naprawionej architektury. Teraz, kiedy pillar pages mają 40–60 linków przychodzących, a dokumentacja jest w pełni zaindeksowana, można produkować nowe klastry treściowe ze znacznie większą skutecznością. W Metria Cloud uruchomiliśmy w tygodniu 17 klaster „product analytics dla enterprise” (1 pillar + 18 spoke), który w oknie +12 tygodni od publikacji zrobił 120 tys. sesji organicznych. To było możliwe tylko dlatego, że fundamenty były gotowe.
Trzeci strumień to AIO i widoczność w LLM. W ciągu ostatnich 6 kwartałów obserwujemy, że ruch z modeli (ChatGPT, Perplexity, Gemini) staje się mierzalnym kanałem dla B2B SaaS. W Metria Cloud po zakończeniu audytu technical uruchomiliśmy osobny sprint AIO — czytelne bloki faktoidalne, schema FAQPage tam, gdzie było to uzasadnione merytorycznie, spójne encje (sameAs, author), oraz optymalizacja pod „grounding queries” modeli. Efekt: cytowania w Perplexity wzrosły o kolejne 60 procent, a referral z ai.chat.* zaczął generować realne lead’y.
Osobnym wątkiem, który pojawia się w każdym post-audytowym kwartale, jest obserwacja konkurencji. W Metria Cloud uruchomiliśmy w tygodniu 12 monitoring 8 kluczowych konkurentów (share of voice, nowe URL w indeksie, zmiany w schematach, nowe backlinki). Nie po to, żeby kopiować — po to, żeby szybciej dostrzegać trendy w kategorii. Kiedy jeden z konkurentów zaczął publikować długoformatowe porównania integracji, zobaczyliśmy to w ciągu 7 dni i zdążyliśmy przygotować własny odpowiednik przed tym, jak zdobył top-3 pozycji. W B2B SaaS o zwycięstwie często decyduje nie wielkość inwestycji, tylko szybkość reakcji na ruch konkurencji.
Warto też powiedzieć, co w Metria Cloud nie zadziałało. Eksperymentowaliśmy z generowaniem automatycznych alt textów dla 2400 obrazów produktowych z użyciem modelu multimodalnego. Wynik: jakość była poprawna, ale brakowało kontekstu produktowego, który tylko zespół know. Wróciliśmy do modelu hybrydowego (AI generuje draft, specjalista contentowy recenzuje co dziesiąty). Drugi nieudany eksperyment to próba wdrożenia Edge SSR dla wszystkich stron. Dla sekcji product i pricing zadziałało, ale dla /docs/* (bardzo dynamiczne zapytania do API) koszty hostingu wzrosły 3-krotnie bez proporcjonalnego zysku w metrykach. Odłożyliśmy to na kolejny kwartał, kiedy platforma dodaje cache warming na krawędzi.
Ostatnia refleksja dotyczy kompozycji zespołu. W projektach, w których uczestniczy dedykowany SEO champion po stronie klienta (osoba łącząca wiedzę techniczną, contentową i produktową), wyniki są średnio 30–40 procent lepsze niż w projektach, gdzie SEO jest rozdzielone między dwa-trzy niepowiązane role. W Metria Cloud taką rolę pełnił senior growth engineer z 7-letnim stażem SEO — i to jest jeden z głównych powodów, dla których udało się zamknąć projekt w 8 tygodni zamiast 12.
Jeżeli planujesz podobny projekt, najważniejsza lekcja jest prosta: nie pomijaj fundamentów. Nie da się zbudować trwałego wzrostu ruchu na serwisie, który nie radzi sobie z crawlem, indeksacją i Core Web Vitals. I odwrotnie — gdy fundamenty działają, każdy kolejny sprint (content, linki, AIO) zwraca się dwukrotnie szybciej niż na serwisach z długiem technicznym. 8 tygodni to nie jest długo. To jest uczciwa inwestycja, która zwraca się trzy do pięciu razy w horyzoncie roku.