Języki

Przekierowania JavaScript

Czym jest przekierowanie JavaScript, jak potok renderowania Google traktuje je inaczej niż przekierowanie 301 po stronie serwera, kiedy jest akceptowalnym ostatecznym rozwiązaniem oraz jak je wdrożyć i wykryć — a także gdzie pasują meta refresh i History API.

Opublikowano po raz pierwszy: 27 cze 2026 · Ostatnia aktualizacja: 3 sie 2026 · Zaawansowane
AIAutor:AI v2
1 sygnał dowodowy na tej stronie

Przekierowanie JavaScript wysyła użytkowników i roboty indeksujące na nowy adres URL za pomocą kodu po stronie klienta (window.location.replace() lub .href). Jest to najmniej niezawodny typ przekierowania, ponieważ Google widzi je dopiero po renderowaniu — które może być opóźnione lub całkowicie nieudane, bez ustalonego harmonogramu w żadnym przypadku. Oficjalna kolejność preferencji Google to: po stronie serwera (301/302/307/308) → meta refresh → JavaScript, a dokumentacja mówi wprost: używaj przekierowań JS tylko wtedy, gdy nie możesz zastosować pozostałych dwóch. Gdy Google pomyślnie zinterpretuje przekierowanie, cel staje się sygnałem kanonizacji — ale nie jest to udowodniona gwarancja identycznego PageRank lub wyników rankingowych jak w przypadku 301, więc traktuj je jako ostateczność, a nie zamiennik. Używaj ich na ograniczonych platformach bez dostępu do serwera, dla stron błędów SPA wskazujących na prawdziwy 404, i niewiele więcej. Jeśli musisz go użyć, użyj window.location.replace() w <head>, usuń źródłowy URL z mapy witryny i kieruj wewnętrzne linki na ostateczny cel. Meta refresh to osobne przekierowanie na poziomie HTML, a history.pushState()/replaceState() w ogóle nie są przekierowaniami.

TL;DR — Przekierowanie JavaScript to przekierowanie po stronie klienta (window.location.replace(), .href, .assign()), które Google przetwarza dopiero po renderowaniu — faza trzecia procesu crawl → render → index. Przekierowanie 301 po stronie serwera jest widoczne podczas crawl; przekierowanie JS czeka w kolejce renderowania, a Google nie podaje stałego harmonogramu tego oczekiwania — może być szybkie lub zająć dużo czasu, a renderowanie może całkowicie się nie udać. Udokumentowana preferencja Google to serwer → meta refresh → JavaScript, a dokumentacja mówi, aby używać przekierowań JS tylko wtedy, gdy nie można zastosować pozostałych dwóch. Gdy Google pomyślnie je zinterpretuje, cel staje się stałym sygnałem kanonizacji — nawet Google używał ich na swoim blogu, gdy nic innego nie działało — ale to nie jest udokumentowany dowód identycznych wyników PageRank lub rankingowych jak w przypadku 301, więc są one ostatecznością, a nie sygnałem spamu. Uzasadnione zastosowania to ograniczone platformy bez konfiguracji serwera oraz strony błędów SPA wskazujące na prawdziwy 404. Implementuj za pomocą window.location.replace() w <head>, usuń źródło z mapy witryny, zmień linki wewnętrzne i potwierdź, że Googlebot może pobrać JS. Meta refresh jest na poziomie HTML (0s = stałe, dowolne opóźnienie = tymczasowe), a history.pushState()/replaceState() w ogóle nie są przekierowaniami.

Co liczy się jako przekierowanie JavaScript

Nawigacja skryptowa zależy od renderowania i wykonania, więc nie jest równoważna protokołowo przekierowaniu HTTP. Dowód potwierdzający to twierdzenie Primary standard or official documentation supporting the adjacent article claim. Zakres: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Poziom ufności: wysoki · Zweryfikowano: Google: JavaScript redirects Przetwarzanie jest możliwe, ale nie jest gwarancją dokładnego czasu ani indeksowania. Dowód potwierdzający to twierdzenie Primary standard or official documentation supporting the adjacent article claim. Zakres: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Poziom ufności: wysoki · Zweryfikowano: Google: Redirects and Search

Przekierowanie JavaScript nawiguje przeglądarkę do nowego adresu URL za pomocą kodu po stronie klienta. Typowe metody i ich różnice:

  • window.location.replace("url") — nawiguje i usuwa oryginalny adres URL z historii sesji. To jest ta do użycia: przycisk wstecz pomija źródło przekierowania zamiast odsyłać użytkownika z powrotem.
  • window.location.href = "url" — nawiguje, ale zachowuje oryginał w historii, więc przycisk wstecz wraca do strony przekierowującej (i może tworzyć pętlę). document.location.href i window.location.assign("url") działają tak samo.
  • history.pushState() / history.replaceState() — nie są przekierowaniami. Przepisują pasek adresu bez żadnej nawigacji ani sygnału HTTP, więc roboty indeksujące nie traktują ich jako przekierowań. SPA używają ich do zmian adresów URL w aplikacji; potrzebują prawdziwych linków <a href> (lub rzeczywistych nawigacji), aby były indeksowalne.

Istotna granica: .replace(), .href i .assign() wszystkie wyzwalają prawdziwą nawigację dokumentu (różnica między nimi dotyczy tylko tego, co dzieje się z historią sesji), podczas gdy pushState()/replaceState() nigdy nie nawigują — dotykają stanu historii i paska adresu i niczego więcej. Żadna z tych czterech metod nie jest HTTP 301; “przekierowanie” tutaj to skrót dla nawigacji po stronie klienta, a nie kod statusu.

Meta refresh (<meta http-equiv="refresh" content="0;url=...">) jest często łączone z przekierowaniami JS, ale to dyrektywa HTML parsowana przed uruchomieniem JavaScript — osobna, bardziej niezawodna kategoria, omówiona poniżej.

Jak Google przetwarza przekierowanie JavaScript

To jest sedno. Potok Google działa etapami, a przekierowanie JS i przekierowanie po stronie serwera są wykrywane na różnych etapach:

  1. Crawl — Googlebot pobiera adres URL i czyta surowy HTML. Przekierowanie po stronie serwera 301/302/307/308 jest widoczne tutaj.
  2. Kolejka renderowania — strony zwracające 200 czekają na renderowanie. Dokumentacja Google zauważa: “may stay on this queue for a few seconds, but it can take longer than that.” (tłumaczenie) „może pozostać w tej kolejce przez kilka sekund, ale czasem trwa to dłużej”. Google nie publikuje stałego harmonogramu na poziomie usługi poza tym, więc traktuj oczekiwanie jako nieprzewidywalne — może być szybkie lub się przeciągać — zamiast zakładać konkretną liczbę dni lub tygodni.
  3. Renderowanie + indeksowanie — headless Chromium uruchamia JavaScript. To jest pierwszy moment, w którym przekierowanie JS istnieje z punktu widzenia Google.

Ta sama idea, którą przedstawiam w Crawling i w JavaScript SEO, ma tutaj zastosowanie: renderowanie to osobny krok od pobierania, a wszystko, co od niego zależy, dziedziczy to opóźnienie i to ryzyko.

A ryzyko jest realne. Google zastrzega, że nie każdy pobrany adres uda się wyrenderować, więc przekierowanie JavaScript może pozostać niewidoczne, jeśli renderowanie zawiedzie. (Google Search Central) W oknie przed przetworzeniem przekierowania — i na zawsze, jeśli renderowanie się nie powiedzie — Google może utrzymywać pustą stronę źródłową w swoim indeksie.

Oficjalna kolejność preferencji Google

Dokumentacja przekierowań przedstawia hierarchię od najbardziej do najmniej niezawodnych:

  1. Przekierowania po stronie serwera — 301/308 (stałe), 302/307 (tymczasowe). Najlepsze dla wszystkiego: widziane w czasie indeksowania, jednoznaczne.
  2. Meta refresh — na poziomie HTML. 0-sekundowy meta refresh jest traktowany jako stałe przekierowanie (jak 301); każdy opóźniony meta refresh jest traktowany jako tymczasowe.
  3. Przekierowania JavaScript — ostateczność.

Google zaleca używanie przekierowań JavaScript dopiero wtedy, gdy nie da się zastosować przekierowania po stronie serwera ani odświeżenia meta. Stałe przekierowania przekazują sygnał kanoniczny do celu; tymczasowe utrzymują oryginał w wynikach. (Jak to współdziała z wyborem kanonicznym, opisano w Kanonalizacja).

Własna dokumentacja przekierowań Google wymienia nawigację lokalizacji JavaScript wśród stałych metod przekierowań i mówi, że cel staje się sygnałem kanonizacji, gdy Google go zinterpretuje — więc płaskie twierdzenie “JS redirects don’t pass PageRank” (tłumaczenie) „przekierowania JS nie przekazują PageRank” jest fałszywe. To, czego dokumentacja nie ustala, to że wynik jest identyczny, natychmiastowy lub tak niezawodny jak 301 po stronie serwera — opisuje sygnał kanoniczny, a nie gwarancję zgodnego przepływu PageRank, rankingu czy czasu. Uczciwe ujęcie: 301 przekazuje sygnał w czasie indeksowania z niemal pewnością; przekierowanie JS przekazuje go tylko wtedy i tylko jeśli renderowanie się powiedzie, a Google nie obiecuje, że wynik będzie dokładnie taki sam jak w przypadku 301. Ta luka — nie utracone equity — jest prawdziwym kosztem wyboru JavaScript.

To także dlatego przekierowania JS nie są same w sobie wyzwalaczem kary. Stają się problemem spamerskim tylko wtedy, gdy są używane do cloakingu — pokazywania robotom jednej strony i przekierowywania użytkowników do czegoś innego lub wysyłania użytkowników mobilnych do niepowiązanej domeny. Polityka Google dotycząca ukrytych przekierowań dotyczy tego zamiaru, a nie techniki.

Kiedy przekierowanie JavaScript jest właściwym narzędziem

Istnieją uzasadnione przypadki:

  • Ograniczone platformy. Niektóre współdzielone hostingi, CDN lub konfiguracje CMS nie dają ci dostępu do reguł przekierowań po stronie serwera. Przekierowanie JS to ważny fallback — i co istotne, Google używał przekierowań JS na swoim blogu Webmaster, ponieważ, jak ujął to Gary Illyes, “that was the only thing we could use for 1:1 redirects, and it works on Google” (tłumaczenie) „to była jedyna rzecz, której mogliśmy użyć do przekierowań 1:1, i działa na Google” (OnCrawl).
  • Obsługa błędów w SPA. Google wprost popiera przekierowanie JavaScript do adresu, pod którym serwer zwraca kod HTTP 404. (Google Search Central) Aplikacja jednostronicowa, która rozwiązuje złą trasę, może przekierować do prawdziwego punktu końcowego 404, aby Google poprawnie przetworzył błąd zamiast indeksować miękki 404.

W przypadku stałych migracji URL to nie jest narzędzie — użyj 301. Ten sam punkt podnoszę w migracjach stron: przekierowania JavaScript to ostateczność, a Google może ich nigdy nie zobaczyć.

Generatory statycznych stron: pułapka aliasów Hugo

Częstym zaskoczeniem jest to, że frontmatter aliases: w Hugo historycznie generował strony HTML z meta odświeżeniem, a nie przekierowania 301 po stronie serwera — a inne generatory statyczne robiły podobne rzeczy domyślnie. Domyślne ustawienia generatorów zmieniają się między wersjami, więc sprawdź faktyczne wyjście swojej aktualnie wdrożonej wersji, zamiast zakładać; jeśli aliases: nie daje Ci przekierowań 301, potrzebujesz reguł przekierowań na poziomie platformy (Netlify _redirects, Cloudflare Workers, Vercel vercel.json) oraz (w Hugo) disableAliases: true. Omawiam to szczegółowo w Hugo SEO.

Najlepsze praktyki wdrożeniowe

Jeśli przekierowanie JavaScript jest naprawdę Twoją jedyną opcją:

  • Użyj window.location.replace(), a nie .href. Jak ujmuje to Search Engine Journal, przekierowania JS “typically use window.location.replace() function rather than window.location.href to avoid UX redirect loops” (tłumaczenie) „zazwyczaj używają funkcji window.location.replace() zamiast window.location.href, aby uniknąć pętli przekierowań UX” (SEJ).
  • Umieść je w <head>, a nie w <body>. Przeglądarki analizują HTML sekwencyjnie i uruchamiają skrypty, gdy na nie trafią, więc “position JavaScript redirects in the <head> tag rather than <body> to minimize delay” (tłumaczenie) „umieść przekierowania JavaScript w tagu <head> zamiast w <body>, aby zminimalizować opóźnienie” (OnCrawl).
  • Przekieruj do miejsca docelowego w jednym skoku. Przekierowanie JS na stronę, która sama przekierowuje gdzie indziej za pomocą 301, tworzy łańcuch; łańcuchy marnują budżet indeksowania i mogą pojawić się w GSC jako błąd przekierowania.
  • Usuń URL źródłowy ze swojej mapy witryny XML. Mapy witryn powinny zawierać kanoniczne, indeksowalne URL-e — a nie te, które przekierowują.
  • Przekieruj wewnętrzne linki do miejsca docelowego, aby nie przechodziły przez przekierowanie w ogóle.
  • Upewnij się, że Googlebot może pobrać JS. Jeśli przekierowanie znajduje się w zewnętrznym skrypcie zablokowanym przez robots.txt, Google nie może go wyrenderować i nie zobaczy przekierowania.

Jak wykrywać przekierowania JavaScript

Nie ogłaszają się jak 301 w nagłówku, więc musisz renderować:

  • Crawler z włączonym renderowaniem JS. OnCrawl zaleca indeksowanie z “JavaScript rendering enabled (5-second timeout minimum)” (tłumaczenie) „włączonym renderowaniem JavaScript (minimalny limit czasu 5 sekund)”; Screaming Frog i Ahrefs Site Audit mogą oba renderować. Bez renderowania strona z przekierowaniem JS wygląda po prostu jak normalne 200.
  • Chrome DevTools. Zakładka Network (z włączoną opcją „Preserve log”) pokazuje nawigację po stronie klienta; rozszerzenie Redirect Path również ją oznacza.
  • W Search Console pomyślnie przetworzone przekierowanie JS pojawia się w sekcji Strona z przekierowaniem — ten sam status co każdy przekierowany URL, co jest normalne dla źródeł niekanonicznych. Ta etykieta nie jest jednak gwarantowana przy każdym sprawdzeniu: odzwierciedla to, co Google pobrało, wyrenderowało, zinterpretowało i skanonizowało w danym momencie próbkowania, więc URL może pokazywać inny status (lub jeszcze żaden status przekierowania) między sprawdzeniami, bez błędu z Twojej strony.

Co bym faktycznie zrobił

Najpierw po stronie serwera, za każdym razem. Meta odświeżenie (0 sekund), gdy możesz edytować HTML, ale nie konfigurację serwera. JavaScript tylko wtedy, gdy obie opcje są niedostępne — i wtedy z window.location.replace() w <head>, czystą mapą witryny i sprawdzeniem, że przekierowanie faktycznie renderuje się dla Googlebota. W przypadku czegokolwiek trwałego lub o wysokiej wartości, dodatkowa niezawodność 301 jest warta prawie każdego wysiłku, aby ją uzyskać.

Dodaj notatkę eksperta

Przypnij cytat eksperta

Nowa osoba? Najpierw utwórz jej nieprzejęty profil na /admin/experts/ → Przypnij cytat eksperta .