Audyt techniczny SEO w React i Next.js: Jak znaleźć błędy, które niszczą widoczność?

Jeśli szukasz nie teorii, tylko diagnozy i poprawek wdrożonych wprost w kodzie — to dokładnie zakres mojej usługi Audyt techniczny SEO.

Czym właściwie jest audyt techniczny SEO

Audyt techniczny SEO to ustrukturyzowana analiza warstwy technicznej serwisu pod kątem widoczności w wyszukiwarkach. W odróżnieniu od audytu treści (czy piszesz o właściwych rzeczach) i audytu off-site (kto do Ciebie linkuje), audyt techniczny odpowiada na jedno bardzo ważne pytanie: czy nic nie blokuje wyszukiwarce dostępu do Twojej treści i jej zrozumienia?

W praktyce audyt techniczny SEO sprawdza:

1. Dostępność dla robotów — czy crawler może wejść na stronę i pobrać zasoby?
2. Renderowanie — czy po wykonaniu JavaScriptu widać tę samą treść co u użytkownika?
3. Indeksację — czy strony trafiają do indeksu i czy te właściwe?
4. Architekturę — czy struktura URL-i i linkowania wewnętrznego jest logiczna?
5. Wydajność — czy Core Web Vitals i realne odczucie szybkości są na poziomie?
6. Mobile-first — czy wersja mobilna jest pełnowartościowa?
7. Bezpieczeństwo — czy działa HTTPS, kody statusu są poprawne i nie ma mixed content?
8. Dane strukturalne — czy schema.org pomaga zrozumieć i cytować treść?
9. Sygnały techniczne treści — czy canonical, hreflang, paginacja, parametry URL i przekierowania po migracji nie rozbijają indeksacji?

Audyt nie jest wyliczeniem danych z narzędzi takich jak Lighthouse czy Ahrefs — wartość leży w ich interpretacji w kontekście biznesowym. Przykładowo, błąd 404 na zarchiwizowanym wpisie to drobiazg, podczas gdy ten sam błąd na stronie produktu, która wciąż generuje kliknięcia z Google, to już jednak problem ze zmniejszonym przychodem.

Dlaczego dla React i Next.js audyt jest trudniejszy

Klasyczna strona internetowa (np. WordPress) wysyła do przeglądarki gotowy HTML z treścią, crawler dostaje wszystko praktycznie od razu. W aplikacjach React sprawa się komplikuje, ponieważ o widoczności decyduje strategia renderowania:

• CSR (Client-Side Rendering) — serwer odsyła niemal pustą skorupę <div id="root"></div>, a treść dorysowuje JavaScript w przeglądarce. Taki jest domyślny tryb pure React (np. Vite, Create React App), który jest dla SEO najbardziej problematyczny i ryzykowny.
• SSR (Server-Side Rendering) — HTML z treścią generowany jest na serwerze przy każdym żądaniu, a crawler dostaje gotową stronę.
• SSG (Static Site Generation) — HTML budowany jest tylko raz, podczas builda. Rozwiązanie najszybsze i najbezpieczniejsze dla SEO.
• ISR (Incremental Static Regeneration) — hybrydowe podejście Next.js, w którym statyczne strony odświeżane są w tle co określony czas.

Problem w tym, że w jednej aplikacji Next.js (zwłaszcza w App Routerze z React Server Components) różne podstrony mogą używać różnych strategii — i część krytycznej treści potrafi „uciec” do renderowania po stronie klienta, gdzie crawler zobaczy ją z opóźnieniem albo wcale.

Do tego dochodzą problemy, których generyczny poradnik SEO w ogóle nie dotyka:

• dynamiczne metadane — title i description wstrzykiwane przez JS zamiast renderowane serwerowo,
• hydration — ciężki, wolny proces „ożywiania” HTML-a, który psuje INP; kiedy hydratacja się wywraca, Googlebot widzie co innego niż użytkownik — ten scenariusz rozkładam dokładnie w artykule o hydration mismatch i indeksacji,
• bundle size — za dużo JavaScriptu ładowanego eagerly, blokującego główny wątek,
• soft 404 — SPA zwracające status 200 OK na nieistniejących adresach, zamiast prawdziwego 404,
• layout shift — obrazy i komponenty bez zarezerwowanego miejsca, psujące CLS.

W Next.js dochodzi jeszcze warstwa frameworka. Audyt musi sprawdzić, czy Metadata API generuje poprawne title, description, canonical, robots i Open Graph dla każdej trasy; czy dynamiczne strony mają właściwe statusy przez notFound() zamiast miękkiego komunikatu 404; czy app/sitemap.ts i app/robots.ts odzwierciedlają realną strukturę serwisu; czy granica między Server Components i Client Components nie wypycha kluczowej treści do hydracji; oraz czy cache, ISR i rewalidacja nie serwują Google starych metadanych po zmianach w CMS-ie.

To są dokładnie te miejsca, w których strona „wygląda świetnie”, a mimo to nie rośnie w Google. Audyt frontendowy szuka ich u źródła — w kodzie, w danych i w konfiguracji frameworka, nie w raporcie PDF.

Nowa rzeczywistość 2026: dwóch odbiorców — Googlebot i crawlery AI

Do niedawna audyt projektowaliśmy pod jednego odbiorcę, czyli Googlebota. Dzisiaj Twoją stronę odwiedza co najmniej kilkunastu nie-ludzkich konsumentów, a najważniejsi z nich to crawlery silników AI: GPTBot (ChatGPT), ClaudeBot, PerplexityBot, Google-Extended i inne.

Z technicznego punktu widzenia, jest jedna kluczowa rzecz warta zapamiętania: praktycznie żaden z crawlerów AI nie renderuje JavaScriptu. Crawlery AI zazwyczaj biorą wyłącznie surowy HTML i nic poza nim nie widzą. Dla porównania, Googlebot renderuje, ale w drugim podejściu (fali), ponieważ najpierw interesuje go czysty HTML.

Konsekwencje są bardzo wyraźne, ponieważ aplikacja w CSR potrafi być poprawnie zindeksowana przez Google, a jednocześnie praktycznie niewidoczna w ChatGPT Search i Perplexity. Cała treść, którą dorysowuje JavaScript, dla tych silników jest traktowana, jakby nie istniała.

To właśnie tu spotykają się SEO i GEO (Generative Engine Optimization) oraz AEO (Answer Engine Optimization). Jeśli zależy Ci na cytowaniach w odpowiedziach AI, w 2026 to realne źródło ruchu i autorytetu — krytyczna treść musi być w HTML-u, zanim wykona się JavaScript. Innymi słowy, SSR lub SSG stało się standardem, jeśli zależy Ci (a powinno) na widoczności w narzędziach AI i w podpowiedziach AI w Google.

Praktyczna wskazówka, którą stosuję: crawluję serwis Screaming Frogiem z user-agentem GPTBot lub PerplexityBot i wyłączonym renderowaniem JS. To, czego nie widać w tym widoku, jest niewidoczne dla AI.

Jak wyszukiwarka widzi Twoją stronę: crawling → rendering → indexing

Żeby audyt miał sens, trzeba rozumieć trzy fazy, które strona musi przejść, zanim pojawi się w wynikach.

1. Crawling

Googlebot odkrywa adresy, przechodząc po linkach i czytając mapy witryny. Każdy serwis ma swój crawl budget, czyli limit podstron, które robot odwiedzi w danym oknie czasowym. Błędy techniczne (łańcuchy przekierowań, masa parametrów URL, strony 5xx) marnują ten budżet, zostawiając wartościowe podstrony nieodwiedzone. Przy większych serwisach sam crawl z zewnątrz nie wystarcza — realne zachowanie robota najlepiej weryfikować w logach Cloudflare i analizie crawl budgetu.

2. Rendering (tu giną aplikacje JS)

Googlebot działa w dwóch falach: najpierw pobiera surowy HTML, jeśli zasoby na to pozwalają, kolejkuje stronę do renderowania, czyli wykonania JavaScriptu, by zobaczyć pełną treść. Między falą pierwszą a drugą jest zauważalna luka czasowa.

To ma trzy konsekwencje dla aplikacji React/Next.js:

1. Treść dostępna dopiero po wykonaniu JS jest indeksowana później niż treść w HTML-u.
2. Googlebot zobaczy pustą stronę, jeśli JS się wywróci, przekroczy timeout albo zablokujesz jego pliki w robots.txt.
3. Crawlery AI w ogóle nie dochodzą do drugiej fali, ponieważ dla nich liczy się tylko surowy HTML.

Najprostszy test, od którego zaczynam audyt każdej aplikacji JS:

# Co crawler dostaje w surowym HTML-u, zanim wykona JavaScript?
curl -s https://twojadomena.pl/wazna-podstrona | grep "fragment-twojej-tresci"

Jeśli curl (albo Ctrl+U / „Pokaż źródło strony”) nie zawiera Twojej kluczowej treści, nagłówków i linków nawigacji — masz problem renderowania, niezależnie od tego, jak ładnie strona wygląda w przeglądarce. Drugą stroną tego testu jest porównanie surowego HTML-a z wyrenderowanym DOM-em (zakładka Elements w DevTools) oraz z widokiem w narzędziu Kontrola adresu URL w Google Search Console.

3. Indexing

Po renderowaniu Google analizuje treść i zapisuje ją w indeksie. Tylko zindeksowane strony pojawiają się w wynikach. Tu polują takie problemy jak zduplikowana treść, błędne canonical, przypadkowy noindex albo soft 404.

Kiedy przeprowadzić audyt

Audyt techniczny to nie jednorazowa akcja, tylko element higieny. Są jednak momenty, w których robisz go obowiązkowo:

• przed startem nowej strony lub aplikacji (taniej naprawić przed indeksacją niż po),
• po migracji — zmiana frameworka, przejście na App Router, zmiana domeny, redesign, zmiana hostingu,
• po nagłym spadku ruchu organicznego,
• cyklicznie — duże serwisy i e-commerce co kwartał, mniejsze strony firmowe co 6–12 miesięcy,
• po każdym większym wdrożeniu — w aplikacjach JS jeden przypadkowy noindex czy zepsuty canonical potrafi skasować tygodnie pracy. Dlatego u siebie pilnuję tego automatycznymi testami regresji SEO w CI/CD.

Audyt krok po kroku — 9 warstw

Poniżej kompletna lista kontrolna. Ułożyłem ją w warstwy od najważniejszej (jeśli crawler nie wejdzie, reszta nie ma znaczenia) do uzupełniających.

Warstwa 1: Crawl i indeksacja

robots.txt — pierwszy plik, jaki sprawdza robot, a najczęstszy, poważny błąd w aplikacjach JS to blokowanie plików .js i .css. Oznacza to, że Googlebot nie wyrenderuje strony. Upewnij się też, że nie ma globalnego Disallow: / (zostawionego po stagingu) i że na końcu jest ścieżka do mapy witryny.

sitemap.xml — powinna zawierać wyłącznie kanoniczne adresy ze statusem 200, bez duplikatów i parametrów, z aktualnym lastmod. W Next.js generuj ją dynamicznie (np. app/sitemap.ts), żeby nie rozjeżdżała się z realną zawartością serwisu.

Stan indeksacji w GSC — raport „Indeksowanie stron” to bezpośrednie źródło prawdy od Google. Przeanalizuj strony wykluczone i z błędami; każdy status (np. „Strona z przekierowaniem”, „Wykryta — obecnie niezindeksowana”, „Strona zawiera tag noindex”) to konkretna wskazówka.

Kody statusu HTTP — błędy 4xx psują UX i marnują crawl budget. Podczas gdy błędy 5xx to już coś znacznie poważniejszego, ponieważ potrafią doprowadzić do wypadnięcia z indeksu. W SPA pilnuj zwłaszcza soft 404, bo nieistniejący adres musi zwracać prawdziwy status 404/410.

Migracje i przekierowania — po zmianie domeny, CMS-a, frameworka albo struktury URL najpoważniejsze błędy są w mapie przekierowań. Audyt powinien sprawdzić, czy stare adresy z ruchem i linkami prowadzą przez 301 do najbliższych odpowiedników, a nie do strony głównej. Trzeba też sprawdzić czy nie ma łańcuchów przekierowań oraz czy linki kanoniczne po migracji wskazują już nowe, docelowe adresy.

Warstwa 2: Renderowanie (warstwa frontendowa)

To serce audytu aplikacji JS:

• Strategia renderowania per typ strony. Strony marketingowe, blog, podstrony usługowe i kategorie powinny iść przez SSR lub SSG (innymi słowy, wszystko, co ma zdobywać pozycje w wyszukiwarce). CSR zostaw dla zalogowanych paneli i widoków, które i tak nie będą nigdy indeksowane.
• Diff HTML vs DOM. Porównaj surowe źródło z wyrenderowanym DOM-em. Treść, która pojawia się dopiero po client-side rendering, jest dla crawlerów AI niewidoczna, a dla Google opóźniona.
• Dynamiczne metadane. title, description, canonical, Open Graph muszą być renderowane serwerowo. W Next.js korzystaj z Metadata API (generateMetadata), a nie z wstrzykiwania znaczników po stronie klienta. W czystym React rozważ przeniesienie krytycznych tras na renderowanie serwerowe zamiast łatać react-helmet.
• Statusy tras w Next.js. Nieistniejąca podstrona powinna kończyć się prawdziwym 404 przez notFound(), a usunięta treść często lepiej działa jako 410. Komunikat „nie znaleziono” wyrenderowany w aplikacji przy statusie 200 jest dla SEO soft 404 i potrafi negatywnie wpływać na indeks.
• Granice Server/Client Components. "use client" jest potrzebne dla interakcji, ale nie powinno obejmować całych layoutów, list artykułów, opisów usług czy bloków contentowych. Im więcej krytycznej treści trafia do Client Components, tym większe ryzyko pustego HTML-a, ciężkiej hydratacji i gorszego INP.
• Cache i rewalidacja. W App Routerze problemy SEO potrafią wynikać nie z samego HTML-a, tylko z tego, kiedy się odświeża. Audyt sprawdza, czy zmiana tytułu, linku kanonicznego, ceny produktu albo opisu kategorii w CMS-ie faktycznie odświeża odpowiednią trasę, sitemapę i dane strukturalne.
• Treść ukryta za interakcją. Zakładki, akordeony, „pokaż więcej” — treść musi być w DOM, a nie wstrzykiwana dopiero po onClick. Inaczej crawler jej nie zobaczy. Sam akordeon jest bezpieczny, ale pod jednym warunkiem: odpowiedź siedzi w wyrenderowanym serwerowo HTML i jest tylko chowana CSS-em, a nie odmontowywana z drzewa do czasu kliknięcia. To rozróżnienie staje się krytyczne przy crawlerach AI. Google wykona JavaScript i prędzej czy później rozwinie panel albo odczyta treść zdublowaną w danych strukturalnych (FAQPage w JSON-LD), więc tam masz dwie siatki bezpieczeństwa. W wypadku silników AI nie ma żadnej, ponieważ nie wykonują JS i zwykle nie parsują JSON-LD — interesuje je tylko widoczny tekst strony. Komponent typu „doklej się dopiero po hydracji” jest dla nich pustym div-em, a structured data nie nadrobi tej luki. Jedyne, co realnie widzą, to treść obecna w surowym HTML.
• Nawigacja w statycznym HTML. Główne menu i stopka muszą być linkami (<a href>) dostępnymi bez wykonywania JS. Hamburger renderowany dopiero po kliknięciu potrafi ukryć przed crawlerem całą strukturę serwisu.
• Test pod crawlery AI. Crawl z user-agentem GPTBot/PerplexityBot bez renderowania JS. Pokazuje, co widzą silniki, które nie wykonują JavaScriptu.

Warstwa 3: Architektura i linkowanie wewnętrzne

• Struktura URL — krótkie, czytelne adresy, małe litery, myślniki zamiast podkreśleń, bez zbędnych parametrów. Struktura powinna odzwierciedlać hierarchię serwisu.
• Linkowanie wewnętrzne — kluczowe podstrony dostępne w 3–4 kliknięciach od strony głównej. Szukaj stron osieroconych (bez żadnych linków przychodzących), napraw zepsute linki oraz stosuj strategię klastrów tematycznych wraz z opisowymi anchor textami.
• Tagi canonical — wskazują wersję oryginalną i bronią przed duplikacją. Uważaj na pętle i łańcuchy kanoniczne oraz na link kanoniczny wskazujący na noindex.
• Paginacja i listingi — kategorie bloga, listingi produktów i archiwa nie mogą tworzyć nieskończonej liczby słabych podstron bez wartości. Audyt sprawdza, czy paginacja ma logiczne adresy, linkowanie do kolejnych stron, unikalne linki kanoniczne tam, gdzie strony mają być indeksowane, i sensowną decyzję, które listingi mają pracować w Google.
• Parametry URL i filtry — sortowanie, UTM-y, warianty widoku, wyszukiwarka wewnętrzna i filtry e-commerce potrafią wygenerować tysiące duplikatów. W React/Next.js szczególnie łatwo ukryć ten problem za stanem aplikacji i searchParams. Trzeba rozdzielić parametry użyteczne dla SEO od technicznych, które powinny być kanonikalizowane, blokowane, ignorowane albo oznaczone noindex.
• Wersje językowe — jeśli serwis ma kilka języków, hreflang i link kanoniczny muszą ze sobą współpracować. Każda wersja językowa powinna wskazywać własny link kanoniczny i komplet alternatyw. W Next.js App Router zwykle robi się to przez alternates.languages w generateMetadata().

Warstwa 4: Core Web Vitals i wydajność

Aktualne progi (2026), które Google nagradza w rankingu:

• LCP (Largest Contentful Paint) < 2,5 s — szybkość załadowania największego elementu (zwykle hero image lub główny blok tekstu).
• INP (Interaction to Next Paint) < 200 ms — responsywność interfejsu; zastąpił FID w marcu 2024.
• CLS (Cumulative Layout Shift) < 0,1 — stabilność layoutu.

W aplikacjach React głównym winowajcą jest JavaScript, więc diagnozę prowadzę po konkretnych elementach:

• LCP: hero image bez priority/preloadu, lazy-loading głównego obrazu, render-blocking resources, wolny TTFB.
• INP: długie taski na głównym wątku, ciężka hydratacja, za duży bundle, nadmiar JS ładowanego eagerly. Lekarstwo: dzielenie kodu, web workers, odraczanie niekrytycznego JS, ograniczenie hydratacji. Pięć najczęstszych wzorców kodu, które niszczą INP w React, opisuję w osobnym artykule o INP.
• CLS: obrazy bez podanych wymiarów, fonty bez font-display: swap, dynamicznie wstrzykiwana treść i reklamy bez zarezerwowanego miejsca.

I rzecz najważniejsza, o której musisz pamiętać: PageSpeed Insights jest sygnałem o potencjalnych nieprawidłowościach, ale nie jest diagnozą. Audyt ma odpowiedzieć, co konkretnie powoduje słaby wynik — obrazy, fonty, JS, layout shift czy third-party scripts.

W 2026 warto dodać do tej warstwy jeszcze jedną rzecz: Przeglądanie Agentowe w Lighthouse. To eksperymentalna kategoria, która patrzy na accessibility tree, CLS, llms.txt i WebMCP. Nie jest czynnikiem rankingowym, ale dobrze pokazuje, czy strona jest czytelna i stabilna dla agentów AI, a nie tylko dla klasycznego crawlera.

Warstwa 5: Optymalizacja mobilna

Google stosuje mobile-first indexing — do oceny używa wersji mobilnej. Audytuj z user-agentem Googlebot Smartphone, nie desktopowym. Testuj na symulacji średniopółkowego telefonu: ciężki bundle JS, który MacBook Pro przełyka bez problemu, na realnym smartfonie potrafi się dławić i psuć INP. Sprawdź responsywność (RWD), czytelność czcionek i odstępy.

Warstwa 6: Bezpieczeństwo

• HTTPS na całej witrynie, bez mixed content, ze starymi adresami HTTP przekierowanymi przez 301. Monitoruj datę wygaśnięcia certyfikatu SSL — wygasły potrafi zatrzymać crawlowanie.
• Obsługa kodów stanu — przekierowania 301 dla przeniesionych treści, prawdziwe 404/410 dla usuniętych, brak długich łańcuchów redirectów.

Warstwa 7: Dostępność i semantyka HTML

Dostępność nie jest tylko osobnym wymaganiem WCAG, ponieważ dla SEO ma znaczenie, ponieważ porządna semantyka pomaga crawlerom i silnikom AI zrozumieć strukturę dokumentu. W audycie sprawdzam, czy strona ma jeden sensowny h1, logiczną hierarchię nagłówków, linki opisujące cel przejścia, teksty alternatywne dla obrazów niosących informację oraz elementy interaktywne zbudowane jako prawdziwe przyciski i linki, a nie klikalne div-y.

W React i Next.js częste błędy pojawiają się w komponentach współdzielonych. Przykładowo, ikony dostają rolę obrazka bez alternatywy, link jest zastąpiony handlerem onClick, menu mobilne istnieje dopiero po hydracji, a komponent karty ma kilka konkurujących linków. Te wszystkie błędy nie zawsze mają bezpośredni wpływ na pozycje, ale pogarsza crawlowalność, UX, wiarygodność strony i ostatecznie jakość danych, które trafiają do narzędzi AI.

Warstwa 8: Dane strukturalne (schema.org)

Dane strukturalne pomagają wyszukiwarce zrozumieć treść i otwierają drogę do rich snippets. W 2026 mają drugą, równie ważną funkcję: to po nich silniki AI często wybierają, co zacytować. Zadbaj o schema.org dla organizacji, usług, breadcrumbs, FAQ i artykułów, waliduj w Rich Results Test i walidatorze Schema.org. To jeden z najtańszych sposobów na jednoczesne korzyści zarówno w Google, jak i w AI search.

W Next.js dane strukturalne powinny wynikać z tego samego źródła danych co treść strony. Jeśli tytuł artykułu, cena produktu albo autor zmieniają się w CMS-ie, JSON-LD musi zmienić się razem z nimi. Rozjazd między widoczną treścią, metadanymi i schema.org to negatywny sygnał jakościowy, i dla Google, i dla silników odpowiedzi.

Warstwa 9: Warstwa GEO/AEO

To rozszerzenie, które musi być częścią współczesnego audytu technicznego.

• krytyczna treść w surowym HTML (patrz: crawlery AI nie renderują JS),
• jasna, dobrze ustrukturyzowana treść z nagłówkami i sekcjami FAQ, które AI łatwo cytuje,
• schema.org jako sygnał dla silników generatywnych,
• świadoma i przemyślana decyzja, czy i które boty AI (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) dopuszczasz w robots.txt. Blokada oznacza brak cytowań w danym silniku.

Narzędzia do audytu technicznego

Narzędzia dostarczają dane; wartość leży w interpretacji i łączeniu sygnałów z różnych źródeł.

Same narzędzia nie są jednak procedurą audytu. W profesjonalnej diagnostyce ważne jest zestawienie kilku perspektyw: tego, co widzi crawler bez JavaScriptu; tego, co widzi Google po renderowaniu; tego, co zapisuje indeks; tego, jak zachowuje się aplikacja po deployu; i tego, które błędy mają realny wpływ na ruch, leady albo sprzedaż. To dlatego dwa identyczne komunikaty w narzędziu mogą dostać zupełnie inny priorytet w backlogu.

Najczęstsze błędy (ze szczególnym uwzględnieniem React/Next.js)

Indeksacja

• blokowanie plików .js/.css w robots.txt (uniemożliwia renderowanie),
• przypadkowy noindex zostawiony po stagingu lub wstrzyknięty warunkowo przez komponent,
• błędne canonical (pętle, wskazania na noindex, niespójność z og:url),
• nieaktualna mapa witryny z adresami 404/301,
• brak lub niespójny hreflang w wersjach językowych,
• parametry URL indeksowane jako osobne duplikaty.

Renderowanie i framework

• krytyczna treść tylko w CSR — opóźniona dla Google, niewidoczna dla AI,
• metadane wstrzykiwane po stronie klienta zamiast serwerowo,
• soft 404 w SPA (status 200 zamiast 404),
• nadmierna, wolna hydratacja psująca INP,
• zbyt szerokie użycie Client Components dla treści, która powinna być renderowana na serwerze,
• cache lub ISR serwujące nieaktualne metadane po zmianach w CMS-ie.

Wydajność i mobile

• nieskompresowane, ciężkie obrazy bez WebP/AVIF i bez wymiarów (CLS),
• za duży bundle JS ładowany eagerly,
• audytowanie tylko na desktopie zamiast na symulacji mobilnej.

Struktura

• strony osierocone bez linków wewnętrznych,
• zbyt głęboka struktura (ważne strony 5+ kliknięć od HP),
• nawigacja niedostępna bez wykonania JS,
• paginacja bez jasnej decyzji indeksować/nie indeksować,
• przekierowania po migracji prowadzące przez łańcuchy albo do zbyt ogólnych stron.

Co zrobić z wynikami audytu technicznego SEO?

Raport to dopiero początek i najważniejsze, by zalecenia w dokumencie PDF nie wylądowały w szufladzie. Pisałem o tym szerzej w audyt SEO to nie lista TODO, tylko pull requesty.

Jak wygląda sensowny proces? Mniej więcej tak:

1. Priorytetyzacja — każdy problem dostaje wagę: krytyczny (blokuje indeksację/widoczność), ważny, drobne usprawnienie.
2. Kontekst i kierunek wdrożenia — nie „popraw LCP”, tylko „hero image ładuje się lazy; dodaj priority, preload i przejdź na AVIF”.
3. Wdrożenie w kodzie — wybrane poprawki trafiają wprost do commitów i PR-ów, a nie wracają jako luźna lista zadań.
4. Pomiar before/after — na tych samych metrykach i typach podstron: GSC (indeksacja, CWV, widoczność zapytań), GA4 (czy ruch i konwersje realnie rosną), Lighthouse/WebPageTest (diagnoza techniczna).

Dla aplikacji React/Next.js dochodzi jeszcze tłumaczenie problemów SEO na zadania frontendowe: zmiana granicy Server/Client Components, poprawienie generateMetadata(), naprawa statusów tras, uporządkowanie searchParams, rozdzielenie stanu UI od indeksowalnych URL-i, dodanie testów regresji dla noindex i linków kanonicznych albo spięcie rewalidacji z CMS-em. To jest ten moment, w którym audyt przestaje być marketingowym dokumentem, a staje się realną pracą inżynierską.

SEO techniczne nie kończy się w dniu merge'a, ponieważ po zmianach trzeba zweryfikować, czy Google widzi nowy stan i czy nie pojawiły się nowe problemy. Pomaga w tym wykrywanie anomalii SEO z Search Console, BigQuery i AI.

Jak wygląda audyt w StriveLab

W StriveLab prowadzę audyt techniczny SEO z perspektywy, która łączy SEO, frontend i produkt. Trzy rzeczy, które go wyróżniają:

• Widoczność techniczna — weryfikuję, czy Google i silniki AI dostają właściwy HTML, metadane i strukturę URL, a nie pustą skorupę do dorysowania przez JS.
• Core Web Vitals u źródła — diagnozuję LCP, INP i CLS po konkretnych elementach kodu (obrazy, fonty, bundle, hydratacja, third-party), a nie po ogólnym wyniku narzędzia.
• Next.js bez ślepej wiary w framework — sprawdzam Metadata API, statusy tras, sitemapę, robots.ts, hreflang, cache, ISR i granice Server/Client Components. Jest to o tyle istotne, że sam wybór Next.js nie gwarantuje technicznego SEO na odpowiednim poziomie.
• Poprawki w kodzie, a nie raport — audyt kończy się listą zmian z priorytetami albo ich wdrożeniem w repozytorium, z porównaniem przed/po na tych samych metrykach.

Sprint ma największy sens dla stron i aplikacji w Next.js oraz React, serwisów po migracji technologicznej, stron usługowych zależnych od ruchu organicznego, landing page'y, portali contentowych i produktów B2B z publiczną częścią SEO.