Strona wygląda dobrze w przeglądarce, działa płynnie, treści się ładują, przyciski odpowiadają. A potem przychodzi zimny prysznic: Google nie pokazuje części podstron, opisy są ucięte albo ruch organiczny stoi w miejscu. W przypadku serwisów opartych na JavaScript to nie jest wyjątek, tylko codzienność, która potrafi wywrócić strategię SEO do góry nogami.
W praktyce problem rzadko siedzi w jednym miejscu. Czasem winny jest render po stronie klienta, czasem błędny routing, czasem blokada zasobów, a czasem zwykły bałagan w logice aplikacji. Dobra diagnoza polega na tym, żeby nie zgadywać, tylko krok po kroku sprawdzić, co Googlebot naprawdę widzi, kiedy wchodzi na stronę.
Dlaczego JavaScript potrafi namieszać w indeksowaniu
Silniki wyszukiwarek od lat radzą sobie z JavaScriptem coraz lepiej, ale „radzą sobie” nie znaczy „zawsze i od razu”. W praktyce crawlowanie i renderowanie to dwa różne etapy, a między nimi bywa kolejka, opóźnienie i mnóstwo okazji do błędów. Strona może być dostępna dla użytkownika, a mimo to dla bota wyglądać jak pusta rama z ładowaniem w tle.
Największy problem pojawia się wtedy, gdy kluczowa treść, linki wewnętrzne albo meta dane powstają dopiero po wykonaniu skryptów. Jeśli coś nie zdąży się wyrenderować, nie zostanie zapisane do indeksu. I właśnie dlatego przy diagnozie trzeba patrzeć nie tylko na front, ale też na to, jak aplikacja zachowuje się w środowisku crawlowania.
Najpierw ustal, czy problem naprawdę dotyczy indeksowania
Łatwo pomylić problem z indeksacją z kłopotem z widocznością albo rankingiem. Strona może być zaindeksowana, ale słabo oceniana pod kątem jakości lub dopasowania do zapytania. Może też istnieć w indeksie, lecz nie zdobywać ruchu, bo konkurencja wygrywa treścią, linkami albo intencją.
Dlatego pierwszy krok jest prosty: sprawdź, czy URL jest w indeksie, czy tylko nie rankuje. W Google Search Console warto porównać raport Strony, wynik operatora site: oraz stan konkretnego adresu w inspekcji URL. Dopiero gdy zobaczysz, że strona nie trafia do indeksu albo trafia niepełnie, można mówić o realnym problemie technicznym.
Co od razu sprawdzić w Search Console
Na początku nie szukaj fajerwerków. Wejdź w inspekcję adresu, zobacz status wykrywania, indeksowania i renderowania, a potem otwórz raporty dotyczące stron i map witryny. To daje szybki obraz tego, czy Google w ogóle dociera do adresu, czy widzi go jako duplikat, przekierowanie, soft 404 albo stronę zablokowaną.
Przy stronach JS ważne są też komunikaty o „stronie zeskanowanej, ale nie zindeksowanej” oraz „odkrytej, ale obecnie nie zindeksowanej”. To nie zawsze oznacza błąd techniczny, ale często pokazuje, że Google ma trudność z oceną wartości strony albo z pełnym odczytem zawartości po renderze. Bez tego tropu można godzinami błądzić po omacku.
Sprawdź, co widzi bot, a nie tylko użytkownik
To jeden z najważniejszych punktów. Użytkownik widzi przeglądarkę, styl, animacje i interakcje. Bot najpierw widzi kod HTML, potem może wykonać część skryptów, ale nie zawsze zrobi to szybko ani w pełnym zakresie. Jeśli treść zależy od późniejszego renderowania, musisz ustalić, czy jest dostępna w surowym HTML, czy dopiero po uruchomieniu JavaScriptu.
Najprostszy test to porównanie źródła strony z tym, co pokazuje renderowana wersja w narzędziach deweloperskich. Jeśli w źródle nie ma istotnych nagłówków, opisów, linków lub danych produktowych, a pojawiają się dopiero po chwili, masz pierwszy trop. To nie dowód winy, ale bardzo często sygnał ostrzegawczy.
Różnica między view source a renderowanym DOM
„Pokaż źródło strony” pokazuje HTML wysłany z serwera. Renderowany DOM to wynik działania JavaScriptu po załadowaniu. Te dwie rzeczy mogą wyglądać podobnie, ale w praktyce różnice bywają ogromne, zwłaszcza w aplikacjach SPA, gdzie treść jest wstrzykiwana dopiero po stronie klienta.
Jeśli bot nie widzi tej treści w odpowiednim momencie, nie ma czego indeksować. Warto więc porównać obie wersje w kilku kluczowych adresach: stronie głównej, kategorii, podstronie produktowej, artykule i filtrze. Takie porównanie szybko pokazuje, czy problem jest systemowy, czy ogranicza się do wybranych typów stron.
Przejrzyj HTML zwracany przez serwer
Wiele diagnoz zaczyna się od prostej, ale bardzo skutecznej rzeczy: pobrania surowego HTML. Można to zrobić przez przeglądarkę, curl albo narzędzie typu Screaming Frog. Chodzi o to, by zobaczyć, co serwer wysyła jeszcze przed wykonaniem jakiegokolwiek skryptu.
Jeśli HTML jest ubogi, pozbawiony treści, canonicali, tagów meta i sensownych linków wewnętrznych, to już dużo wyjaśnia. W projektach opartych na JS często zakłada się, że „przecież renderujemy po stronie klienta”, ale dla wyszukiwarki to bywa za mało. Serwer powinien dostarczać możliwie kompletny szkielet informacji, a nie samą obudowę.
Na co patrzeć w surowym kodzie
Sprawdź, czy w HTML znajdują się tytuł, opis, nagłówki, linki kanoniczne, znaczniki hreflang, dane strukturalne i ważne odnośniki. Jeśli ich nie ma, a są dopiero po renderze, trzeba ocenić, czy to akceptowalne z perspektywy SEO. Im bardziej krytyczny element dla zrozumienia strony, tym mniej sensu ma odkładanie go na etap po stronie klienta.
Ważne jest też to, czy kod nie jest przetykany błędami, które rozwalają parser. Zdarza się, że jeden niezamknięty tag albo problem w generowaniu komponentu powoduje, że część treści znika w nieprzewidywalny sposób. Boty nie są cierpliwe wobec brudnego HTML.
Sprawdź renderowanie w narzędziach Google
Google Search Console daje kilka wskazówek, ale przy bardziej złożonych problemach warto sięgnąć po renderowanie w praktyce. Inspekcja URL pokazuje zrzut ekranu i wyrenderowany HTML, o ile Google był w stanie go wygenerować. To bardzo cenna informacja, bo pozwala porównać oczekiwania z rzeczywistością.
Jeśli zrzut ekranu pokazuje połowę strony albo pusty ekran, a ważne treści się nie pojawiają, nie ma sensu zgadywać. Trzeba sprawdzić, czy skrypty się ładują, czy nie blokuje ich polityka bezpieczeństwa, czy nie ma problemu z API, albo czy aplikacja nie zależy od zbyt długiego czasu wykonania.
Jak czytać wynik renderowania
Nie wystarczy zobaczyć, że strona „się renderuje”. Trzeba sprawdzić, co dokładnie zostało widoczne dla bota. Niekiedy Google pokazuje stronę, ale nie ładuje dynamicznych list, recenzji, danych cenowych albo segmentów treści, które są ważne dla intencji wyszukiwania.
Jeśli render zawiera tylko nagłówek i stopkę, a reszta jest pusta, przyczyna może leżeć w błędach JavaScript, opóźnionych wywołaniach API lub zależności od sesji użytkownika. To już konkret, z którym można pracować. Bez renderu łatwo popełnić kosztowny błąd i optymalizować nie ten fragment, co trzeba.
Przeanalizuj logi serwera
Logi są nudne tylko na pierwszy rzut oka. W rzeczywistości potrafią szybko powiedzieć, czy Googlebot odwiedza stronę, jak często to robi, które adresy pomija i czy natrafia na błędy. Przy serwisach JS to jedno z najcenniejszych źródeł prawdy, bo pokazuje realne zachowanie bota, a nie domysły zespołu.
Warto sprawdzić szczególnie odpowiedzi serwera dla Googlebota: statusy 200, 3xx, 4xx i 5xx, czas odpowiedzi oraz ścieżki prowadzące do kluczowych stron. Jeśli bot wielokrotnie trafia na przekierowania albo błędy 5xx, problem może wyglądać jak „indeksacja”, ale w gruncie rzeczy jest zwykłym problemem dostępności.
Co w logach zdradza kłopot z JavaScriptem
Jeśli Googlebot odwiedza stronę, a potem szybko wychodzi bez dalszych żądań po zasoby, może to oznaczać, że renderowanie nie kończy się poprawnie. Przy dłuższych łańcuchach zależności, gdzie JS musi pobrać dane z wielu endpointów, każdy słabszy punkt potrafi zatrzymać całą maszynę.
W logach widać też, czy bot trafia na zasoby blokowane przez robots.txt, czy dostaje 403, albo czy API używane przez frontend nie odsyła pustych odpowiedzi dla ruchu spoza sesji. Taki detal łatwo przeoczyć, a później człowiek zastanawia się, czemu strona „działa tylko w domu, a nie w Google”.
Zweryfikuj blokady techniczne
Jednym z najczęstszych powodów problemów są blokady, które wpadły do projektu przy okazji porządków technicznych. Można niechcący zablokować pliki JS, CSS, endpointy API albo całe sekcje serwisu. Dla człowieka to drobiazg, dla bota często ściana.
Najpierw sprawdź robots.txt, potem nagłówki odpowiedzi serwera i ewentualne reguły bezpieczeństwa w CDN, WAF albo firewallu aplikacyjnym. Jeśli któraś warstwa odcina botowi dostęp do skryptów potrzebnych do renderu, problem będzie wracał jak bumerang, niezależnie od tego, ile zmian wprowadzisz w treści.
Najczęstsze blokady, które trzeba wykluczyć
- blokada plików JavaScript i CSS w robots.txt,
- reguły WAF traktujące boty jak podejrzany ruch,
- przekierowania zależne od regionu lub języka,
- różne wersje strony dla użytkownika i bota,
- błędy w polityce CORS lub w pobieraniu danych z API,
- brak dostępu do zasobów przy pierwszym wejściu bez cookies.
Ta lista nie jest długa dla ozdoby. Każdy z tych punktów widziałem w realnych projektach i każdy potrafił wywołać chaos w indeksacji. Najgorsze jest to, że objawy bywają podobne, a przyczyny kompletnie różne.
Sprawdź architekturę renderowania
Nie każda strona JS działa tak samo. Jedne używają czystego client-side rendering, inne server-side rendering, jeszcze inne static site generation albo hybrydę. To ma znaczenie, bo diagnoza wygląda inaczej w zależności od tego, kiedy treść trafia do HTML.
Jeśli wszystko dzieje się po stronie klienta, ryzyko problemów z indeksowaniem rośnie. Jeśli HTML przychodzi już z treścią, a JS tylko dodaje interaktywność, szanse na spokojną pracę są dużo większe. W praktyce najlepiej, gdy kluczowe elementy SEO są dostępne możliwie wcześnie, bez czekania na długi łańcuch skryptów.
Client-side rendering, SSR i hydratacja
Client-side rendering wymaga, żeby przeglądarka wykonała skrypt i dopiero potem zbudowała stronę. SSR wysyła gotowy HTML z serwera. Hydratacja łączy te dwa światy, ale czasem właśnie w tym miejscu pojawiają się pęknięcia: treść jest widoczna, lecz interakcje nie działają, albo odwrotnie.
Jeśli Google widzi wersję „przed hydratacją”, może nie otrzymać części danych. To nie jest teoria, tylko dość częsty scenariusz w aplikacjach opartych na nowoczesnych frameworkach. Z tego powodu trzeba kontrolować nie tylko końcowy efekt wizualny, lecz także kolejność ładowania i czas pojawienia się treści.
Nie ignoruj linkowania wewnętrznego
W serwisach JS linki często są generowane dynamicznie. To wygodne dla zespołu, ale bywa słabe dla robotów, jeśli odnośniki nie są dostępne w prosty, przewidywalny sposób. Bez mocnego linkowania wewnętrznego część podstron staje się dla Google trudna do znalezienia albo słabo powiązana z resztą serwisu.
Sprawdź, czy linki są prawdziwymi odnośnikami HTML, a nie tylko obsługą kliknięcia przez JavaScript. To różnica, która potrafi zadecydować o odkrywalności wielu podstron. Jeżeli bot musi „zgadywać” trasę po stronie, to zwykle nie kończy się to dobrze.
Jak ocenić linki w aplikacji
W narzędziach do crawlowania przejrzyj strukturę linków wychodzących z kluczowych szablonów. Zobacz, czy kategorie prowadzą do produktów, produkty do powiązanych treści, a artykuły do tematów uzupełniających. Jeśli wszystko działa tylko po kliknięciu w interfejs, bez normalnego linku w kodzie, tracisz ważną część sygnałów dla wyszukiwarki.
Ważne są też linki do paginacji, filtrowania i archiwów. Przy stronach opartych na dużej liczbie dynamicznych widoków właśnie te elementy często decydują o tym, czy crawl budget jest wykorzystywany sensownie, czy rozprasza się na ślepych zaułkach.
Porównaj wersję mobilną i desktopową
Google indeksuje przede wszystkim wersję mobilną, więc rozjazd między widokiem na telefonie a desktopem nie jest błahostką. Jeśli w mobile treść jest ukryta, skrócona albo ładowana inaczej, to właśnie tę wersję bierze pod uwagę wyszukiwarka. I tu pojawia się klasyczna pułapka: zespół sprawdza stronę na laptopie i jest przekonany, że wszystko gra.
Warto testować oba warianty, ale większą wagę przyłożyć do mobilnego. Zdarzało mi się widzieć strony, na których desktop był poprawny, a mobile wręcz obcinał część nagłówków i linków. W indeksie lądowała więc wersja okrojona, choć użytkownikom na większym ekranie wydawało się, że problemu nie ma.
Przejrzyj dane strukturalne i meta informacje
W aplikacjach JS dane strukturalne często są dodawane dynamicznie. To bywa skuteczne, ale tylko wtedy, gdy robot zdąży je zobaczyć i przetworzyć. Jeśli schema.org pojawia się z opóźnieniem albo w ogóle nie trafia do renderowanego DOM, tracisz okazję do lepszego zrozumienia strony.
To samo dotyczy title, description, canonicali i hreflang. Jeśli te elementy są ustawiane po stronie klienta, trzeba sprawdzić, czy Google faktycznie je pobiera i zapisuje. W przeciwnym razie serwis może wyglądać nowocześnie, ale technicznie będzie kulał w bardzo podstawowych miejscach.
Najważniejsze elementy do kontroli
| Element | Po co go sprawdzać | Typowy problem |
|---|---|---|
| title | Określa temat strony | Brak w HTML lub nadpisanie po renderze |
| meta description | Wpływa na snippet | Dynamiczne generowanie z opóźnieniem |
| canonical | Wskazuje wersję preferowaną | Błędny adres lub brak w renderze |
| hreflang | Obsługuje wersje językowe | Niekompletne pary i konflikty |
| dane strukturalne | Pomagają zrozumieć treść | Wstrzykiwanie po czasie, który bot może pominąć |
Tabela nie zastąpi testu w praktyce, ale porządkuje to, co naprawdę trzeba skontrolować. W SEO dla JS detale mają większe znaczenie niż efektowne deklaracje. Jeden brakujący canonical potrafi narobić więcej szkody niż cały miesiąc kosmetycznych zmian w treści.
Sprawdź szybkość i stabilność odpowiedzi serwera
Jeśli serwer odpowiada wolno, bot może nie doczekać pełnego renderu albo ograniczyć zakres przetwarzania. To szczególnie groźne przy ciężkich stronach, które ładują wiele bibliotek, grafik, trackerów i zewnętrznych skryptów. Im dłuższy czas odpowiedzi, tym większa szansa, że Google zapisze niepełny obraz strony.
Nie chodzi wyłącznie o Core Web Vitals. Tu stawką jest to, czy infrastruktura w ogóle pozwala botowi zobaczyć całość. Z własnego doświadczenia wiem, że czasem wystarczy odchudzić jeden zbędny skrypt marketingowy, by indeksacja zaczęła działać wyraźnie lepiej.
Gdzie szukać spowolnień
Sprawdź TTFB, czas pobierania skryptów, liczbę zapytań do API i błędy 5xx w momentach większego ruchu. Zwróć uwagę na CDN, cache oraz na to, czy odpowiedzi nie są uzależnione od ciasteczek lub nagłówków, które bot otrzymuje inaczej niż użytkownik. To małe różnice, ale w praktyce robią ogromną robotę.
Jeżeli strona działa dobrze tylko na ciepłym cache’u, a pierwszy kontakt jest ospały, bot może dostać najgorszą wersję doświadczenia. A to wystarcza, by część adresów była przetwarzana niechętnie albo z opóźnieniem.
Użyj crawla jak detektora, nie jak odkurzacza
Narzędzia typu crawler są bardzo pomocne, ale trzeba ich używać z głową. Nie wystarczy przeskanować serwisu i spojrzeć na listę błędów. Warto porównywać wersję bez renderowania i z renderowaniem JavaScriptu, a potem patrzeć, które adresy różnią się najbardziej.
To świetny sposób na wyłapanie miejsc, gdzie treść znika, linki się nie pojawiają albo meta dane nie są generowane poprawnie. Crawler pokaże ci nie tylko to, co jest, ale też to, czego nie ma tam, gdzie powinno być. I właśnie o ten brak zwykle toczy się cała gra.
Na co zwracać uwagę w raportach crawl
- różnice między HTML raw a rendered,
- liczbę wykrytych linków wewnętrznych,
- strony z pustą lub bardzo krótką treścią,
- duplikaty title i description,
- adresy zwracające inne treści w zależności od user-agenta,
- strony, które po renderze tracą canonical lub hreflang.
Jeśli ten sam adres wygląda inaczej w zależności od tego, jak go pobierasz, masz sygnał, że problem jest głębszy niż zwykły błąd treści. Tego nie warto odkładać, bo z czasem rozjazd między wersjami zwykle rośnie, a nie maleje.
Gdy indeksacja siada po wdrożeniu, sprawdź ostatnie zmiany
W praktyce bardzo często problem pojawia się zaraz po deployu. Nowa biblioteka, inna konfiguracja cache, zmiana trasowania, aktualizacja frameworka, dodanie przekierowania i już masz gotowy kłopot. Jeśli indeksacja pogorszyła się nagle, historia zmian zwykle prowadzi prosto do źródła.
Warto porównać wersję sprzed wdrożenia i po wdrożeniu. Czasem wystarczy odtworzyć kilka kluczowych stron w środowisku testowym i porównać ich HTML oraz render. Takie porównanie potrafi oszczędzić mnóstwo czasu, bo zamiast zgadywać, widzisz dokładnie, co wypadło z gry.
Przykład z praktyki: strona, która „istniała”, ale nie dla Google
W jednym z projektów e-commerce wszystko wyglądało dobrze. Produkty ładowały się szybko, filtr działał, a zespół był przekonany, że problem z ruchem wynika z sezonowości. Dopiero analiza renderu pokazała, że Googlebot nie dostaje listy produktów, bo API zwracało pełne dane tylko po ustawieniu ciasteczka sesyjnego.
Dla użytkownika nie było różnicy, bo przeglądarka po wejściu generowała ciasteczko automatycznie. Dla bota już tak. Po poprawieniu logiki odpowiedzi API i przeniesieniu kluczowych danych do SSR liczba zaindeksowanych kart produktów zaczęła rosnąć, a wraz z nią ruch z długiego ogona. To była zwykła, techniczna poprawka, bez magicznych sztuczek.
Jak zbudować sensowną kolejność diagnozy
Najlepiej iść od rzeczy najprostszych do bardziej złożonych. Najpierw sprawdź, czy URL jest w indeksie i jak wygląda w Search Console. Potem porównaj surowy HTML z renderem, przejrzyj logi, zweryfikuj blokady i dopiero na końcu wchodź w szczegóły frameworka, hydratacji i architektury renderowania.
Taka kolejność nie jest przypadkowa. Chodzi o to, by nie przepalać czasu na analizę rzeczy, które nie mają znaczenia, zanim nie wykluczysz podstaw. W SEO technicznym łatwo zakochać się w skomplikowanych teoriach, a potem przeoczyć prosty błąd w robots.txt albo jeden źle ustawiony endpoint.
Praktyczna ścieżka działania
- Sprawdź status adresu w Search Console.
- Porównaj source HTML z renderem.
- Przejrzyj logi serwera pod kątem Googlebota.
- Zweryfikuj robots.txt, nagłówki i blokady zasobów.
- Oceń linkowanie wewnętrzne i dostępność treści.
- Skontroluj meta dane, canonicale i dane strukturalne.
- Sprawdź wydajność, błędy API i zachowanie po wdrożeniu.
To prosta ścieżka, ale bardzo skuteczna. Nie trzeba od razu robić rewolucji w całej aplikacji. Często wystarczy jedna dobrze trafiona poprawka, żeby wyszukiwarka zaczęła widzieć stronę tak, jak widzi ją użytkownik.
Na co uważać, żeby nie pomylić objawów z przyczyną
Najczęstszy błąd polega na tym, że ktoś widzi słabą indeksację i od razu zaczyna poprawiać treści albo linki zewnętrzne. To czasem pomaga, ale jeśli problem jest techniczny, to tylko pudrowanie rany. Strona może mieć świetny content i nadal być kiepsko widoczna, jeśli bot nie potrafi jej poprawnie wyrenderować.
Drugi błąd to ślepa wiara w to, co pokazuje przeglądarka. Użytkownik ma pełne środowisko, cache, sesję, cookies i nieskończoną cierpliwość do ładowania. Bot nie zawsze dostaje taki komfort. Dlatego diagnoza musi opierać się na porównaniu środowisk, a nie na jednym, wygodnym dla zespołu widoku.
Co zwykle daje najlepszy efekt naprawczy
Jeśli strona ma poważne problemy z indeksacją, najskuteczniejsze bywają rozwiązania, które skracają drogę do treści. Server-side rendering, statyczne generowanie stron, rozsądna hydratacja i ograniczenie ciężkich zależności JS bardzo często przynoszą więcej niż dziesięć kosmetycznych optymalizacji. W szczególności ważne jest, by najcenniejsze elementy były dostępne bez opóźnienia.
Warto też porządnie uporządkować architekturę linków, zadbać o stabilne meta dane i usunąć wszystko, co blokuje render. Czasem to oznacza mniej efektowny front, ale lepszy wynik w wyszukiwarce. A w marketingu internetowym wynik wygrywa z efektownością szybciej, niż wielu osobom się wydaje.
Jeśli podejdziesz do tematu metodycznie, diagnoza przestaje być zgadywanką. Wtedy łatwiej odróżnić problem z renderowaniem od problemu z architekturą, a problem z indeksacją od zwykłego spadku jakości strony. I właśnie w tym miejscu najczęściej zaczyna się prawdziwa poprawa widoczności.