JavaScript SEO: upewnij się, że linki przetrwają proces renderowania

Google renderuje JavaScript przy użyciu aktualnej wersji Chroma. Problemem rzadko jest samo renderowanie. Zazwyczaj problemem są linki, które nie stają się kotwicami, oraz strony zależne od stanu, którego crawler nie posiada.

Zespół badawczy ArchiLinks · Zaktualizowano 2026-10-29

Most łączący kamienne fundamenty ze szklanymi konstrukcjami, symbolizujący przetrwanie linków

Co widzi crawler

Googlebot korzysta z aktualnej wersji Chroma od maja 2019 roku. To ostatecznie rozstrzygnęło kwestię jego zdolności do uruchamiania nowoczesnego JavaScriptu.

Ryzyka praktyczne są starsze: renderowanie następuje po crawlowaniu i może być opóźnione, treść ukryta za kliknięciami lub logowaniem nigdy się nie pojawia, a link wygenerowany z handlera onclick na elemencie div nie jest linkiem. Przed sprawdzeniem backlinków do stron, które niedawno przeniesiono na front-end oparty na React, upewnij się, że strony te wyświetlają swoją treść w odpowiedzi surowej lub w wyrenderowanym HTML.

SSR, SSG, CSR: co zmienia się w przypadku linków

Podejście	Treść w pierwszej odpowiedzi	Linki wewnętrzne jako kotwice	Dobre dla
SSR (Next.js, Nuxt)	Tak	Tak, jeśli używasz prawdziwych kotwic	Strony publiczne z dynamicznymi danymi
SSG lub prerender	Tak	Tak	Dokumentacja, blogi, strony marketingowe
CSR aplikacja jednostronicowa	Nie, pusta powłoka	Tylko po renderowaniu	Dashboardy wymagające logowania
Hybrydowy (SSR strony głównej, CSR aplikacji)	Na trasę	Na trasę	Większość produktów z publiczną stroną

Test jeden: surowy HTML versus HTML po renderowaniu

Jeśli kluczowe linki pojawiają się w pierwszej odpowiedzi, kwestia jest zamknięta. Jeśli nie, porównaj z renderowaniem headless.

bash

# raw response: are the links there?
curl -s https://new-shop.com/guides/ | grep -o '<a [^>]*href="[^"]*"' | head -20

# rendered DOM with headless Chrome
chrome --headless --dump-dom https://new-shop.com/guides/ | grep -c '<a '

Ogrodnik badający korzenie drzew, symbolizujący zewnętrzne kontroli zdrowia backlinków

Skąd pochodzą linki zewnętrzne

Błąd renderowania ukrywa Twoją treść. Nie usuwa linków, które inne strony już Ci dały.

Po migracji na Next.js, Vite lub headless CMS uruchom toppages dla hosta i przetestuj 20 najczęściej linkowanych adresów URL pod kątem statusu, canonical i widocznej treści. Zrób to jako pierwsze. Jeśli strona z 40 domenami linkującymi zwraca pustą powłokę lub błąd 404 po stronie klienta, napraw to przed wszystkim innym, ponieważ tam trafia Twoja autorytatywność. Strona różnice między równoważnością linków wewnętrznych a zewnętrznymi pokazuje, jak porównać tę listę z linkami wewnętrznymi, a checklista migracji umieszcza test w planie uruchomienia.

Szablony mają mniejsze znaczenie niż dyscyplina. Express z silnikiem szablonów, motyw WordPress i router aplikacji Next.js mogą wszystkie serwować linki czytelne przez crawle. Każdy z nich może też zawieść, jeśli zespół wypuści kotwice, które istnieją dopiero po kliknięciu.

Checklista linków i renderowania

Nawigacja i paginacja używają znacznika <a href>, a nie handlerów kliknięć na innych elementach.
Każda trasa zwraca poprawny kod statusu. Strony z miękkim błędem 404 muszą zwracać kod 404.
Tag noindex lub canonical wstrzykiwany przez JavaScript musi być zgodny z tym zwracanym przez serwer.
Treść zapasowa w pierwszej odpowiedzi to rzeczywista strona, a nie spinner, który Google może zaindeksować.
Kod autoryzacji nie przekierowuje robotów indeksujących na publicznych trasach.
Pliki CSS i JS niezbędne do renderowania nie są zablokowane w pliku robots.txt.
Ładowanie leniwe (lazy loading) wykorzystuje IntersectionObserver lub natywne atrybuty ładowania, a nie zdarzenia scrollowania.

Analiza dowodów z Search Console

Search Console odpowiada na większość pytań dotyczących renderowania, jeśli użyjesz odpowiedniego raportu. Skorzystaj z Narzędzia Inspekcji URL, a następnie opcji „Wyświetl zindeksowaną stronę”.

Porównaj trzy elementy: HTML pobrany przez Google, zrzut ekranu oraz zasoby strony, które nie zostały załadowane. Strona, która wygląda kompletnie w Twojej przeglądarce, ale pusto na zrzucie ekranu, jest zwykle zablokowana przez błąd skryptu lub niedozwolony zasób, a rozwiązanie leży w Twojej konfiguracji budowania aplikacji, a nie w samej treści.

Pamiętaj o opóźnieniu. Zmiana, którą wdrożysz dzisiaj, pojawi się w narzędziu inspekcyjnym dopiero po ponownym zindeksowaniu URL przez Google, co może zająć kilka dni.

Kiedy SSR się opłaca

Strony publiczne, które muszą się pozycjonować: tak. Dashboardy: nie.

Jeśli trasa ma przyciągać ruch organiczny, serwuj treść w pierwszej odpowiedzi. Jeśli strona wymaga logowania, pomiń dodatkową złożoność. Wybieraj metodę na poziomie trasy, a nie całego projektu, i udokumentuj decyzję, aby kolejny deweloper nie cofnął zmian.

Użyj narzędzia Test wyników bogatych i Inspekcji URL, aby porównać wyrenderowany wynik.
Przetestuj za pomocą narzędzia Live Test w Search Console po każdej aktualizacji frameworka.

Dwa domy na wzgórzu pokazujące prerenderowanie versus renderowanie po stronie klienta

Czy renderowanie po stronie serwera jest wymagane, czy wystarczy prerenderowanie?

Renderowanie po stronie serwera jest opcjonalne. To sposób na przekazanie w pierwszej odpowiedzi tego, czego potrzebuje crawler. Wiele publicznych stron osiąga ten cel dzięki prerenderowaniu, statycznemu buildowi lub renderowaniu po stronie serwera tylko dla kluczowych podstron, pozostawiając strefy zalogowania bez zmian.

Załóżmy, że strony produktów i dokumentacja są publiczne, podczas gdy dashboard wymaga logowania. Prerenderuj pierwszą grupę. Dashboard pozostaw po stronie klienta. Dzięki temu strony publiczne przekazują swoje linki w pierwszej odpowiedzi, a dashboard może pozostać tak złożony, jak to konieczne.

Prerenderowanie tylko strony głównej

Prerenderowanie strony głównej rozwiązuje problem pierwszego crawlowania, ale każda inna trasa czeka na wyrenderowanie przez przeglądarkę. Jeśli strona główna linkuje do podstron kategorii renderowanych po stronie klienta, linki na tych podstronach nadal zależą od procesu renderowania. Sprawdź każdy szablon, który kontrolujesz, a nie tylko stronę startową.

Prowadź krótką listę publicznych tras z ich metodą renderowania. Lista szybciej wskaże luki niż raport z crawlowania.

Czy renderowanie po stronie serwora zmienia widoczność lokalną

Renderowanie po stronie serwera może wpłynąć na szybkość pojawienia się pierwszej treści, co czytelnicy odczuwają. Samo w sobie nie sprawia, że strona jest relevantna dla zapytania lokalnego. Sygnały te pochodzą z treści strony, danych firmy i linków do niej prowadzących.

Traktuj renderowanie jako sposób, dzięki któremu te sygnały stają się czytelne dla crawlera, a linki mierz osobno za pomocą API.

Aplikacje Vite i React serwujące jeden shell

Build Vite, który serwuje jeden HTML shell dla każdej ścieżki, przenosi całą pracę na klienta. Taka aplikacja może nadal pozycjonować się dla niektórych zapytań, ale każda publiczna trasa wymaga planu: prerenderuj ją, renderuj po stronie serwera lub zaakceptuj stratę i zanotuj to.

Zanim sprawdzisz backlinki do tras po rebuildzie, zdecyduj, jak każda publiczna trasa pozyskuje swoją treść. W przeciwnym razie dane o linkach pokażą linki zewnętrzne prowadzące do stron bez treści.

Testowanie, czy trasa pokazuje swoje linki

Dwa testy odpowiadają na większość pytań. Surowa odpowiedź pokazuje to, co crawler otrzymuje przed uruchomieniem skryptów. Wyrenderowany DOM pokazuje to, co przeglądarka buduje później. Link pojawiający się tylko w drugim przypadku jest nadal linkiem, ale zależy on od poprawnego procesu renderowania.

Odczytywanie Live Test w Search Console

Uruchom Live Test z Inspekcji URL dla jednej trasy na raz. Sprawdź wyrenderowany HTML, a następnie listę zasobów, które nie załadowały się. Zablokowany skrypt może usunąć cały blok nawigacji, a strona będzie wyglądać na pustą, bez widocznego błędu.

Powtórz test po aktualizacji frameworka, ponieważ nowe domyślne ustawienia mogą zmienić to, czy linki renderują się przed czy po uruchomieniu skryptu. Przewodnik strony niezaindeksowane opisuje, co robić, gdy wyrenderowana strona nadal nie jest indeksowana.

Kiedy trasa się renderuje, ale treścią jest spinner

Fallback w pierwszej odpowiedzi ma większe znaczenie, niż większość zespołów zakłada. Spinner lub pusty kontener oznaczają, że strona nie zawiera żadnej treści dla crawlera w tym momencie. Umieść tytuł, wstęp i główne linki w pierwszej odpowiedzi, nawet jeśli szczegółowa lista ładuje się później.

Fallback, który jest prawdziwą stroną, może pozostać prosty. Jego jedynym zadaniem jest przechowywanie treści do momentu załadowania reszty.

Przeniesienie strony klienckiej bez utraty linków

Wypisz trasy z linkami zewnętrznymi

Uruchom toppages dla hosta i zanotuj top 50 URL-i. Przetestuj te trasy jako pierwsze, przed zmianami w kodzie, aby wiedzieć, co rebuild musi zachować.

Porównaj surową i wyrenderowaną odpowiedź

Dla każdej trasy sprawdź surowy HTML i wyrenderowany DOM w starym i nowym buildzie. Znotuj każdy link, który istnieje w jednym, ale nie w drugim.

Zamień handlery kliknięć na kotwice

Zamień nawigację na prawdziwe kotwice z poprawnym adresem. Optymalizacja prędkości może poczekać na sprint, podczas gdy brakująca kotwica kosztuje trasę jej ścieżkę w obrębie witryny.

Powtórz test po wydaniu

Tydzień po wydaniu uruchom Live Test na tych samych trasach i porównaj wyniki z wcześniejszymi. Różnice pokażą, gdzie rebuild zmienił wynik.

Kody statusu i przekierowania w aplikacji klienckiej

Aplikacja single-page często pokazuje ekran „nie znaleziono”, podczas gdy serwer zwraca status 200. Google może potraktować taką stronę jako soft 404, a linki zewnętrzne prowadzące do nieistniejącego URL-a przynoszą mało korzyści. Poprawka należy po stronie serwera.

Nieznane trasy, które nadal zwracają 200

Zwróć prawdziwy 404 z serwera dla każdej trasy, która nie istnieje, i zachuj ekran „nie znaleziono” w aplikacji dla odwiedzających przychodzących trasą kliencką. Jeśli istnieje zastępstwo, wyślij 301.

Sprawdź kilka fikcyjnych adresów na żywym hoście po każdym wydaniu. Kluczowy jest kod odpowiedzi, a nie strona widziana w przeglądarce.

Przekierowania uruchamiane w przeglądarce

Przekierowanie uruchamiane po załadowaniu strony, np. poprzez odczytanie parametru URL w komponencie, to coś innego niż przekierowanie po stronie serwera. Crawler może zindeksować pierwszą odpowiedź przed uruchomieniem przekierowania. Jeśli trasa została trwale przeniesiona, zwróć 301 z serwera i zachuj parametry zmieniające treść. Przepis na mapę przekierowań pokazuje, jak przetestować te reguły.