Co to jest przekierowanie meta refresh? Definicja i wpływ na SEO

Jak działa przekierowanie meta refresh

Przekierowanie meta refresh to po prostu znacznik meta z atrybutem http-equiv o wartości refresh. W atrybucie content podaje się liczbę sekund, średnik i adres docelowy, na przykład „0; url=https://example.pl/nowa-strona/”. Bez adresu znacznik przeładowuje tę samą stronę po upływie czasu, co kiedyś stosowały portale z wiadomościami.

Meta refresh był szczególnie popularny w latach 90. i na początku XXI wieku, gdy wiele osób publikowało strony na darmowych hostingach bez dostępu do konfiguracji serwera. Dziś spotykam go najczęściej na starych podstronach, które przetrwały kilka migracji, w szablonach stron „dziękujemy za wysłanie formularza” oraz w prostych kreatorach stron.

Kluczowa różnica wobec zwykłych przekierowań: serwer zwraca stronę normalnie, z kodem 200, a przekierowanie wykonuje dopiero przeglądarka, gdy przetworzy HTML. MDN Web Docs opisuje też nagłówek HTTP Refresh, który działa tak samo, tylko jest wysyłany w odpowiedzi serwera zamiast w kodzie strony.

Przekierowanie meta refresh a przekierowania 3xx

Przekierowanie meta refresh działa w innym miejscu niż przekierowanie 301 czy przekierowanie 302. Kody 3xx to odpowiedzi serwera z nagłówkiem Location, które przeglądarka i robot obsługują, zanim w ogóle pobiorą treść. Meta refresh wymaga pobrania całego dokumentu HTML, a według MDN przeglądarka wykonuje go na samym końcu, po przekierowaniach HTTP i JavaScript.

Jak Google traktuje przekierowanie meta refresh

Przekierowanie meta refresh Googlebot obsługuje, ale ocenia je według opóźnienia. Natychmiastowy meta refresh dokumentacja Google umieszcza obok 301 i 308, czyli sygnałów, że nowy adres ma stać się kanoniczny. Opóźniony trafia do tej samej grupy co 302 i 307, więc w wynikach zwykle zostaje stary adres, a sygnały nie przechodzą w pełni na nowy.

Google zaleca meta refresh tylko wtedy, gdy platforma nie pozwala ustawić przekierowania po stronie serwera. Jest za to pewniejszy niż przekierowanie w JavaScript, bo kod JS Google wykonuje dopiero przy renderowaniu, a to może się nie udać. Kolejność preferencji wygląda więc tak: przekierowanie serwerowe, potem meta refresh, na końcu JavaScript.

W raporcie indeksowania stron w Search Console strona z działającym meta refresh zwykle pojawia się jako „Strona zawiera przekierowanie”, tak samo jak przy 301. Nie oznacza to jednak, że Google przeniósł wszystkie sygnały, zwłaszcza gdy opóźnienie jest większe niż zero.

Kiedy przekierowanie meta refresh ma sens

Przekierowanie meta refresh stosuję wyłącznie w sytuacjach awaryjnych, gdy nie ma innego wyjścia:

• hosting statyczny, na którym nie da się ustawić reguł serwera ani nagłówków,
• zamknięty kreator stron lub CMS bez menedżera przekierowań,
• pojedyncze stare podstrony, których nie da się przenieść na nowy serwer.

We wszystkich pozostałych przypadkach ustawiam 301 w konfiguracji serwera, w Apache w pliku .htaccess, w Nginx w bloku location, a w WordPressie przez wtyczkę do przekierowań działającą na poziomie PHP. Nigdy nie łączę dwóch metod dla tego samego adresu, bo przekierowanie HTTP i meta refresh naraz potrafią stworzyć pętlę albo łańcuch przekierowań.

Przekierowanie meta refresh a dostępność i ryzyko spamu

Przekierowanie meta refresh z opóźnieniem to według W3C błąd dostępności. Technika F40 wytycznych WCAG uznaje takie przekierowania za niezgodne z kilkoma kryteriami, bo osoba korzystająca z czytnika ekranu może zostać przeniesiona, zanim przeczyta treść. Wersja z zerowym opóźnieniem jest akceptowana, choć W3C również wskazuje przekierowania serwerowe jako lepsze.

Dochodzi do tego ryzyko SEO. Strony, które pokazują robotowi jedną treść, a użytkownika po kilku sekundach przenoszą w zupełnie inne miejsce, przypominają techniki spamerskie znane z dawnych stron przejściowych. Każda taka strona zużywa też crawl budget, choć sama nie wnosi niczego do indeksu. Dlatego w ramach technicznego SEO wypisuję każdy meta refresh znaleziony podczas crawlu i zamieniam go na 301 wszędzie, gdzie pozwala serwer.