Meta refresh to przekierowanie zapisane w kodzie strony, a nie w odpowiedzi serwera. Przeglądarka najpierw pobiera dokument z kodem 200, dopiero potem znajduje w nim polecenie przejścia gdzie indziej i wykonuje je natychmiast albo po zadanym czasie. Serwer nie ma o tym przekierowaniu pojęcia, więc w nagłówkach odpowiedzi nie widać po nim śladu.
Skrót: Google interpretuje meta refresh bez opóźnienia jako przekierowanie trwałe, a z opóźnieniem jako tymczasowe. W kolejności zalecanych metod stoi na drugim miejscu, za przekierowaniami po stronie serwera i przed przekierowaniami JavaScriptem. Wersja z opóźnieniem ma dodatkowy problem: W3C uznaje ją za błąd dostępności, opisany jako technika F40.
Jak działa meta refresh
Polecenie umieszcza się w sekcji nagłówkowej dokumentu. Zawiera dwie informacje: liczbę sekund do wykonania przejścia oraz adres docelowy. Wartość zero oznacza przejście natychmiastowe, każda wyższa wprowadza pauzę, podczas której użytkownik widzi jeszcze starą stronę.
Kluczowa różnica względem przekierowania serwerowego polega na kolejności zdarzeń. Przy przekierowaniu po stronie serwera przeglądarka dostaje samą informację o zmianie adresu i nie pobiera treści starej strony. Przy meta refresh pobiera pełny dokument, renderuje go, a dopiero potem wykonuje przejście, więc cała ta praca idzie na marne.
Ma to jeszcze jedną konsekwencję, przez którą problem bywa niewidoczny w audytach. Adres z meta refresh zwraca kod 200, czyli wygląda w raporcie jak zwykła, poprawnie działająca podstrona, choć w rzeczywistości nikt nigdy nie ogląda jej treści.
Jak Google interpretuje meta refresh
Wyszukiwarka rozróżnia dwa przypadki i traktuje je zupełnie inaczej, o czym mówi wprost dokumentacja. Meta refresh bez opóźnienia jest interpretowany jako przekierowanie trwałe, a więc odpowiednik kodu 301. Meta refresh z opóźnieniem interpretowany jest jako przekierowanie tymczasowe, czyli odpowiednik kodu 302.
| Wariant | Interpretacja Google | Odpowiednik serwerowy |
|---|---|---|
| bez opóźnienia | przekierowanie trwałe | kod 301 |
| z opóźnieniem | przekierowanie tymczasowe | kod 302 |
Praktyczny wniosek jest taki, że opóźnienie dodane dla wygody użytkownika, na przykład po to, żeby zdążył przeczytać komunikat o przenosinach, zmienia charakter przekierowania w oczach wyszukiwarki. Stary adres zostaje wtedy w indeksie zamiast przekazać pozycje nowemu, dokładnie tak, jak przy błędnie użytym kodzie 302 przy trwałej zmianie.
Miejsce meta refresh wśród metod przekierowania
Google porządkuje dostępne metody według tego, jak niezawodnie działają, i kolejność ta rzadko pojawia się w polskich poradnikach. Na pierwszym miejscu stoją przekierowania po stronie serwera, czyli kody 301 i 308 przy zmianach trwałych oraz 302, 303 i 307 przy tymczasowych. Meta refresh wskazany jest jako rozwiązanie zastępcze na wypadek, gdy platforma nie pozwala ustawić przekierowania serwerowego.
Na końcu stawki znajdują się przekierowania wykonywane skryptem, z wyraźnym zastrzeżeniem: renderowanie strony może się nie powieść, a wtedy przekierowanie w ogóle nie zostanie wykryte. Meta refresh jest więc bezpieczniejszy od przekierowania skryptem, ale gorszy od każdego rozwiązania serwerowego.
Dlaczego opóźniony meta refresh łamie dostępność
Osobny argument, niezależny od pozycjonowania, pochodzi od W3C. Przekierowanie z opóźnieniem uznawane jest za błąd dostępności, opisany jako technika F40, ponieważ stanowi nieoczekiwaną zmianę kontekstu, nad którą użytkownik nie ma kontroli.
Dla osoby korzystającej z czytnika ekranu albo czytającej wolniej oznacza to, że strona znika w trakcie lektury i nie da się tego zatrzymać ani cofnąć. Ta sama technika W3C wskazuje jednocześnie, że wariant z zerowym opóźnieniem jest dopuszczalny, bo przejście następuje natychmiast i użytkownik nie zdąży zauważyć zmiany.
Obie perspektywy prowadzą więc do tego samego wniosku. Jeśli już musisz użyć meta refresh, ustaw zerowe opóźnienie, bo wtedy jednocześnie zyskujesz interpretację przekierowania trwałego i unikasz błędu dostępności.
Co meta refresh kosztuje użytkownika
Poza kwestiami interpretacji jest jeszcze zwykły rachunek czasu i on wypada dla tej metody niekorzystnie. Przy przekierowaniu serwerowym przeglądarka dostaje krótką odpowiedź z samą informacją o nowym adresie i od razu rusza dalej. Przy meta refresh musi pobrać cały dokument, przetworzyć jego kod, znaleźć polecenie i dopiero wtedy zacząć pobieranie właściwej strony.
Różnica rośnie wraz z wagą strony pośredniej. Jeśli zawiera ona pełny szablon serwisu razem z arkuszami stylów i skryptami, użytkownik pobiera komplet plików, których nigdy nie zobaczy. Na łączu mobilnym o słabym zasięgu potrafi to oznaczać kilka sekund czekania na stronę, która i tak zaraz zniknie.
Drugim kosztem jest zachowanie przycisku powrotu. Po przekierowaniu serwerowym cofnięcie prowadzi do miejsca sprzed wejścia, natomiast przy meta refresh strona pośrednia zostaje w historii przeglądarki. Cofnięcie wraca więc na nią, a ona natychmiast przekierowuje do przodu, przez co użytkownik zostaje uwięziony i nie może opuścić strony przyciskiem powrotu.
Gdzie meta refresh wciąż się spotyka
Rozwiązanie uchodzi za przestarzałe, a mimo to regularnie wychodzi przy audytach, zwykle w kilku powtarzalnych miejscach.
- Strony zaparkowanych domen i tanie usługi przekierowania domeny, które nie oferują konfiguracji serwera.
- Strony pośrednie po wylogowaniu albo po wysłaniu formularza, z komunikatem i odliczaniem.
- Stare podstrony po migracji, gdzie przekierowanie dodano ręcznie w szablonie, bo tak było szybciej.
- Systemy zarządzania treścią bez dostępu do konfiguracji serwera, gdzie meta refresh bywa jedyną dostępną opcją.
- Strony w usługach hostingu statycznego, w których nie da się ustawić reguł po stronie serwera bez dodatkowej warstwy.
Czym zastąpić meta refresh
Zamiennikiem jest przekierowanie po stronie serwera, dobrane do charakteru zmiany. Przy trwałej zmianie adresu właściwy jest kod 301, przy zmianie tymczasowej kod z rodziny odpowiedzi tymczasowych. Pełne zestawienie kodów wraz z reakcją wyszukiwarki na każdą grupę znajdziesz w liście kodów odpowiedzi HTTP.
Jeśli platforma naprawdę nie pozwala ustawić reguł serwerowych, zostaw meta refresh, ale bez opóźnienia. Komunikat o przenosinach, który miał uzasadniać pauzę, lepiej umieścić na stronie docelowej, bo tam przeczyta go każdy, kto rzeczywiście dotarł do celu, a nie tylko ten, kto zdążył w wyznaczonych sekundach.
Jak wykryć meta refresh na swoim serwisie
Wykrycie jest trudniejsze niż przy przekierowaniach serwerowych właśnie dlatego, że nie widać go w nagłówkach odpowiedzi. Adres raportuje kod 200, więc typowe zestawienia statusów pokazują go jako stronę bez zarzutu.
Potrzebne jest narzędzie zaglądające do treści dokumentu, a nie tylko do nagłówków. Sprawdzanie przekierowań i statusów HTTP odczytuje także znacznik meta refresh na stronie docelowej i sygnalizuje go osobno, dzięki czemu takie przypadki nie giną wśród poprawnych odpowiedzi.
Przy przeglądzie zwróć szczególną uwagę na adresy, które kiedyś były podstronami z ruchem, a dziś zwracają kod 200 przy podejrzanie krótkiej treści. To typowy ślad po ręcznie dodanym przekierowaniu w szablonie, o którym zwykle nikt już nie pamięta.
Drugim tropem jest rozjazd między adresem sprawdzanym a tytułem strony w wyniku. Jeśli narzędzie pokazuje kod 200, ale tytuł należy wyraźnie do innej podstrony niż ta, o którą pytałeś, prawdopodobnie trafiłeś na stronę pośrednią z przekierowaniem w treści. Taki rozjazd łatwo przeoczyć przy sprawdzaniu pojedynczych adresów, a rzuca się w oczy przy przeglądaniu całej listy naraz.
Warto też przejrzeć adresy zaparkowanych domen należących do firmy, bo to właśnie tam meta refresh występuje najczęściej i najdłużej pozostaje niezauważony. Domena kupiona lata temu na wszelki wypadek potrafi przez cały ten czas przekierowywać w sposób, który wyszukiwarka odczytuje jako tymczasowy, przez co nigdy nie przekazuje niczego serwisowi docelowemu.
Najczęstsze pytania
Czy meta refresh szkodzi pozycjonowaniu?
Sam w sobie nie, o ile nie ma opóźnienia. Google interpretuje natychmiastowy meta refresh jako przekierowanie trwałe, czyli odpowiednik kodu 301. Problem zaczyna się przy opóźnieniu, bo wtedy przekierowanie odczytywane jest jako tymczasowe i stary adres zostaje w indeksie.
Czy meta refresh jest lepszy od przekierowania skryptem?
Tak. W kolejności zalecanej przez Google metody serwerowe są na pierwszym miejscu, meta refresh na drugim, a przekierowania JavaScriptem na ostatnim. Przy tych ostatnich dokumentacja ostrzega, że renderowanie strony może się nie powieść i przekierowanie w ogóle nie zostanie wykryte.
Ile sekund opóźnienia jest bezpieczne?
Zero. Każde opóźnienie zmienia interpretację na przekierowanie tymczasowe, a dodatkowo W3C uznaje opóźniony meta refresh za błąd dostępności opisany jako technika F40. Wariant z zerowym opóźnieniem jest dopuszczalny z obu perspektyw, bo użytkownik nie zdąży zauważyć zmiany kontekstu, a wyszukiwarka odczytuje takie przejście jako zmianę trwałą.
Dlaczego nie widzę meta refresh w raporcie statusów?
Bo przekierowanie siedzi w treści dokumentu, a nie w odpowiedzi serwera. Adres zwraca kod 200 i w zestawieniu wygląda jak poprawna podstrona. Do wykrycia potrzebne jest narzędzie czytające zawartość strony docelowej, a nie wyłącznie nagłówki.
Czy trzeba usuwać istniejące meta refresh?
Jeśli platforma pozwala ustawić przekierowanie po stronie serwera, warto je zastąpić, bo działa szybciej i nie wymaga pobierania strony pośredniej. Jeśli nie pozwala, wystarczy usunąć opóźnienie i przenieść ewentualny komunikat na stronę docelową.
