JavaScript a SEO w sklepie – headless, renderowanie i indeksowanie treści

Najczęstsze problemy JavaScript SEO w sklepach

W audytach sklepów opartych na JavaScripcie powtarza się kilka problemów. Większość z nich nie wynika z samego frameworka, tylko z decyzji wdrożeniowych, które łatwo przeoczyć, testując sklep wyłącznie w przeglądarce.

Linki, których robot nie widzi

Google rozpoznaje linki w elementach a z atrybutem href. Nawigacja oparta na zdarzeniach kliknięcia – np. przycisk lub element div, który zmienia stronę skryptem – może sprawić, że Googlebot nie znajdzie kategorii, kolejnych stron listingu czy kart produktów. To szczególnie groźne w menu, filtrach i paginacji. Zasady budowania linków wewnętrznych opisaliśmy w artykule o linkowaniu wewnętrznym w sklepie.

Adresy z fragmentami zamiast pełnych ścieżek

Aplikacje jednostronicowe czasem używają fragmentów adresu, np. sklep.pl/#/kategoria/buty. Google zaleca korzystanie z History API i pełnych ścieżek, bo fragmenty nie są traktowane jako osobne adresy. Każda kategoria, filtr indeksowany i produkt powinny mieć własny, czytelny adres – o zasadach budowy adresów piszemy w tekście o przyjaznych adresach URL w sklepie.

Canonical, tytuł i meta robots zmieniane JavaScriptem

Jeśli pierwotny HTML zawiera jeden tag canonical, a JavaScript zmienia go na inny, Google dostaje sprzeczne sygnały. Dokumentacja Google zaleca, by canonical ustawiony skryptem był zgodny z tym w pierwotnym HTML – a najlepiej, by był poprawny od początku. To samo dotyczy meta robots: noindex w pierwotnym HTML może spowodować pominięcie renderowania. Zasady stosowania canonical opisaliśmy w artykule o tagu canonical w e-commerce.

Kod 200 dla nieistniejących stron

Aplikacje jednostronicowe często zwracają kod 200 dla każdego adresu, a komunikat „produkt nie istnieje” wyświetlają dopiero skryptem. Dla Google to pozorny błąd 404 – strona wygląda na pustą, ale serwer twierdzi, że wszystko jest w porządku. Google zaleca w takich przypadkach przekierowanie do adresu, który zwraca prawdziwy kod 404, albo dodanie meta robots noindex. Co zrobić ze stronami wycofanych produktów, opisaliśmy w artykule o produktach niedostępnych i wycofanych.

Treść ładowana po interakcji

Opisy w zakładkach pobieranych z serwera po kliknięciu, opinie wczytywane po przewinięciu czy produkty w listingu doładowywane wyłącznie przyciskiem „pokaż więcej” bez osobnych adresów – to treści, których robot może nie zobaczyć. Googlebot nie klika i nie przewija jak użytkownik. Treść ważna dla SEO powinna być w HTML po renderowaniu bez interakcji, a kolejne strony listingu – dostępne pod własnymi adresami.

[#uwaga] Nie blokuj w robots.txt plików JavaScript, CSS ani adresów API, z których frontend pobiera dane produktów. Jeśli Googlebot nie może ich pobrać, wyrenderuje stronę bez treści – nawet jeśli dla klientów wszystko działa poprawnie.

Sklep headless – na co zwrócić uwagę przy wdrożeniu

Architektura headless daje swobodę projektowania frontendu, szybkość i możliwość łączenia wielu źródeł danych. Z perspektywy SEO oznacza jednak, że wiele rzeczy, które klasyczna platforma zapewnia „z pudełka”, trzeba zaprojektować samodzielnie.

Dlatego przy wdrożeniu headless warto przygotować listę wymagań SEO jeszcze przed wyborem technologii: renderowanie po stronie serwera, poprawne kody odpowiedzi, mapa witryny, obsługa przekierowań, canonical, dane strukturalne, czytelne adresy i linki HTML. Przejście z klasycznej platformy na headless to w praktyce migracja – z mapą przekierowań i kontrolą indeksowania, opisaną w artykule o migracji sklepu a SEO.

Wykres – które sposoby renderowania i rozwiązania w sklepie headless są bezpieczne dla SEO. [#chart:se87b]

Dane strukturalne i mapa witryny w sklepie z JavaScriptem

Dane strukturalne produktu – nazwa, cena, dostępność, oceny – można wstawiać do strony także JavaScriptem, a Google potrafi je odczytać po renderowaniu. Bezpieczniej jest jednak generować je po stronie serwera, razem z resztą treści. Wtedy nie zależą od tego, czy i kiedy strona zostanie wyrenderowana, a cena i dostępność w znacznikach są zawsze zgodne z tym, co widzi klient i co trafia do feedu produktowego.

W sklepie headless trzeba też zadbać o mapę witryny, której klasyczna platforma dostarcza automatycznie. Mapa powinna zawierać wyłącznie adresy kanoniczne zwracające kod 200, aktualizować się po dodaniu lub wycofaniu produktu i nie obejmować adresów wyników wyszukiwania ani kombinacji filtrów, których nie chcesz indeksować. Dla dużych katalogów warto podzielić ją na kilka plików – np. osobno kategorie i produkty – co ułatwia kontrolę indeksowania w Search Console.

Współpraca SEO z zespołem programistów

W sklepach opartych na JavaScripcie wiele decyzji SEO zapada w kodzie, a nie w panelu administracyjnym. Dlatego najlepiej sprawdza się współpraca od początku projektu: lista wymagań SEO jako część specyfikacji, testy na środowisku testowym przed publikacją i wspólna kontrola po wdrożeniu. Środowisko testowe powinno być zabezpieczone przed indeksowaniem, np. hasłem, a po publikacji trzeba upewnić się, że blokady nie przeszły na wersję produkcyjną.

Przydaje się też prosta lista kontrolna dla każdej większej zmiany we frontendzie: czy zmieniły się adresy, czy linki nadal są elementami a z href, czy kody odpowiedzi są poprawne, czy treść jest w HTML po renderowaniu. Kilka minut testów przed wdrożeniem oszczędza tygodnie odbudowy widoczności.

Jak sprawdzić, co widzi Googlebot

Testowanie sklepu wyłącznie w przeglądarce to za mało – przeglądarka wykonuje wszystkie skrypty, ma zapisane ciasteczka i pozwala na interakcję. Żeby zobaczyć sklep oczami Google, warto skorzystać z kilku narzędzi.

1. Narzędzie do sprawdzania adresu URL w Search Console – test wersji opublikowanej pokazuje zrenderowany HTML, zrzut ekranu i zasoby, których nie udało się pobrać.

2. Test wyników z elementami rozszerzonymi – pokazuje zrenderowany kod i wykryte dane strukturalne dla dowolnego adresu.

3. Porównanie źródła strony z wersją zrenderowaną – jeśli w źródle nie ma opisu produktu ani linków, a pojawiają się dopiero po renderowaniu, sklep polega na renderowaniu po stronie klienta.

4. Crawl z renderowaniem JavaScript – narzędzia do crawlowania pozwalają porównać treść i linki przed i po wykonaniu skryptów na wielu adresach naraz.

5. Raport Indeksowanie stron w Search Console – rosnąca liczba stron „zeskanowanych, ale jeszcze niezindeksowanych” lub pozornych błędów 404 może wskazywać na problemy z renderowaniem.

[#tip] Prosty test: otwórz kartę produktu, wyłącz JavaScript w przeglądarce i odśwież stronę. Jeśli zniknęła nazwa, cena, opis i linki do kategorii, sklep w pełni polega na renderowaniu po stronie klienta – a to sygnał, by przeanalizować sposób renderowania przed kolejnymi inwestycjami w treści.

JavaScript a szybkość sklepu

JavaScript wpływa nie tylko na indeksowanie, ale też na szybkość i wrażenia klientów. Duże pakiety skryptów opóźniają wyświetlenie głównej treści i reakcję strony na kliknięcia. Wśród podstawowych wskaźników internetowych dobra wartość LCP to maksymalnie 2,5 sekundy, a INP – maksymalnie 200 milisekund dla 75. percentyla wizyt. Sklep, w którym główny obraz produktu pojawia się dopiero po pobraniu i wykonaniu kilku megabajtów JavaScriptu, ma z tym zwykle problem.

Renderowanie po stronie serwera i ograniczenie skryptów zewnętrznych – czatów, pikseli, widżetów – poprawia jednocześnie SEO, szybkość i konwersję. Warto regularnie przeglądać, które skrypty są naprawdę potrzebne na kartach produktów i w kategoriach.

Filtry, paginacja i sortowanie w aplikacji JavaScript

Listingi kategorii to miejsce, w którym JavaScript najczęściej ukrywa treść przed wyszukiwarką. Filtry działające wyłącznie po stronie przeglądarki, paginacja zastąpiona nieskończonym przewijaniem i sortowanie bez zmiany adresu sprawiają, że robot widzi tylko pierwszą porcję produktów. Jeśli kategoria ma kilkaset produktów, a Googlebot dociera tylko do pierwszych dwudziestu, pozostałe karty mogą być odkrywane wyłącznie przez mapę witryny – co osłabia ich pozycję.

Rozwiązaniem jest połączenie wygody klienta z dostępnością dla robota: nieskończone przewijanie może działać dla użytkownika, ale kolejne strony listingu powinny mieć własne adresy i linki HTML, a filtry przeznaczone do indeksowania – stałe adresy z treścią generowaną po stronie serwera. Pozostałe kombinacje filtrów mogą działać skryptem bez tworzenia nowych adresów.

Platforma SaaS czy headless – decyzja biznesowa

Headless nie jest celem samym w sobie. Dla wielu sklepów klasyczna platforma SaaS daje wystarczającą elastyczność i rozwiązuje większość kwestii technicznego SEO bez dodatkowej pracy programistów. Headless ma sens, gdy sklep potrzebuje bardzo niestandardowego frontendu, łączy wiele źródeł danych albo ma zespół, który utrzyma taką architekturę. Porównanie popularnych platform znajdziesz w tekście Shoper czy WooCommerce, a jeśli rozważasz klasyczne wdrożenie, zobacz, jak pracujemy przy sklepach na Shoperze.

[#przyklad] Sklep z wyposażeniem wnętrz przeszedł na frontend headless z renderowaniem po stronie klienta. Kilka tygodni po wdrożeniu w Search Console wyraźnie wzrosła liczba stron zeskanowanych, ale niezindeksowanych, a nowe produkty pojawiały się w indeksie z dużym opóźnieniem. Po włączeniu renderowania po stronie serwera dla kategorii i kart produktów oraz zamianie przycisków nawigacji na linki z atrybutem href nowe karty zaczęły być indeksowane szybciej, a liczba stron w indeksie wróciła do poziomu sprzed migracji.

[#checklista] JavaScript SEO w sklepie: renderowanie po stronie serwera lub statyczne; treść i linki w HTML bez interakcji; linki jako a z href; pełne ścieżki zamiast fragmentów; canonical i meta robots poprawne w pierwotnym HTML; prawdziwe kody 404 i 410; JS, CSS i API niezablokowane w robots.txt; mapa witryny i przekierowania obsłużone; kontrola w narzędziu do sprawdzania adresu URL.

Najczęściej zadawane pytania

Czy Google indeksuje strony oparte na JavaScripcie?

Tak. Google renderuje strony w przeglądarce Chromium i indeksuje treść po wykonaniu skryptów. Renderowanie to jednak dodatkowy etap, który może nastąpić z opóźnieniem, a błędy w implementacji mogą sprawić, że część treści i linków nie zostanie zauważona.

Czy sklep headless jest gorszy dla SEO?

Nie, jeśli jest dobrze wdrożony – z renderowaniem po stronie serwera, poprawnymi kodami odpowiedzi, linkami HTML i obsługą przekierowań. Ryzyko pojawia się, gdy frontend polega wyłącznie na renderowaniu po stronie klienta.

Czy dynamic rendering to dobre rozwiązanie?

Google opisuje dynamic rendering jako obejście, a nie zalecane rozwiązanie. Zamiast niego rekomenduje renderowanie po stronie serwera, generowanie statyczne lub hydratację.

Jak sprawdzić, czy Google widzi treść mojego sklepu?

Użyj narzędzia do sprawdzania adresu URL w Search Console i obejrzyj zrenderowany HTML oraz zrzut ekranu. Porównaj go ze źródłem strony – jeśli treść pojawia się tylko po renderowaniu, warto sprawdzić, czy Google ją faktycznie indeksuje.

Czy noindex dodany JavaScriptem działa?

To ryzykowne. Google może pominąć renderowanie strony, która w pierwotnym HTML ma noindex, a zmiana dyrektyw skryptem może dawać sprzeczne sygnały. Dyrektywy robots i canonical najlepiej ustawiać poprawnie od razu w HTML z serwera.

Czy filtry i paginacja w sklepie headless wymagają osobnych adresów?

Tak, jeśli mają być dostępne dla wyszukiwarki. Kolejne strony listingu i filtry, które chcesz indeksować, powinny mieć własne adresy i linki HTML, a nie tylko zmieniać zawartość strony skryptem.

Podsumowanie

JavaScript nie jest wrogiem SEO, ale wymaga świadomych decyzji. Najbezpieczniejsze dla sklepu są renderowanie po stronie serwera, generowanie statyczne lub hydratacja, linki HTML, pełne adresy, poprawne kody odpowiedzi oraz canonical i meta robots ustawione od razu w HTML. Regularna kontrola w narzędziu do sprawdzania adresu URL i crawlach z renderowaniem pozwala wychwycić problemy, zanim odbiją się na widoczności.

Jeśli planujesz sklep headless albo podejrzewasz, że Google nie widzi treści Twojego sklepu, sprawdź, jak prowadzimy SEO dla sklepów internetowych.