Jak wyeliminować błędy 404 i poprawnie wdrożyć przekierowania 301?

Kiedy przekierować, a kiedy zostawić błąd

Baner wejsciowyParallax

Jak wyeliminować błędy 404 i poprawnie wdrożyć przekierowania 301?

Kiedy przekierować, a kiedy zostawić błąd

Autor nie posiada zdjęcia
Tomasz Piasecki
27 maja 2021

Temat wraca zawsze po przebudowie strony albo migracji sklepu. Ktoś otwiera Search Console, widzi kilkaset adresów oznaczonych jako nieznalezione i wpada w panikę. Potem pojawia się szybkie rozwiązanie: przekierować wszystko na stronę główną i będzie spokój.

To rozwiązanie jest gorsze niż problem. Google traktuje przekierowanie na treść niepowiązaną z oryginałem jak stronę błędu, tylko trudniejszą do zdiagnozowania — a użytkownik, który klika w link do konkretnego produktu i trafia na stronę główną, wychodzi natychmiast.

Sensowne podejście wymaga rozdzielenia dwóch decyzji: co z danym adresem zrobić i jak to technicznie wykonać. Większość szkód powstaje przez pomieszanie ich kolejności.

Co właściwie znaczą kody odpowiedzi

Zanim cokolwiek naprawię, upewniam się, że rozumiem, co serwer odpowiada.

  • 404 — nie znaleziono. Standardowa odpowiedź dla adresu, który nie istnieje. Nie jest błędem w sensie usterki i sama obecność takich adresów nie obniża pozycji serwisu.
  • 410 — usunięto trwale. Mocniejszy komunikat: ta treść była i jej nie będzie. Przyspiesza wypadnięcie z indeksu.
  • 301 — przeniesiono na stałe. Przekazuje wartość starego adresu na nowy i wypada z indeksu na jego rzecz.
  • 302 — przeniesiono tymczasowo. Google zwykle zachowuje wtedy w indeksie stary adres. Przy trwałych zmianach to błąd.
  • Miękki 404 — najbardziej podstępna sytuacja: serwer odpowiada kodem sukcesu, ale strona informuje o braku treści. Google to rozpoznaje i raportuje, a systemy monitorujące — nie.

Rozdzielenie 404 od miękkiego 404 to często pierwsza realna praca. Strony „brak wyników”, „produkt niedostępny” i puste kategorie potrafią generować setki takich przypadków w sklepie.

Skąd biorą się nieistniejące adresy

Warto znać przyczyny, bo od nich zależy sposób naprawy.

Migracja i przebudowa struktury adresów — najczęstsza i najkosztowniejsza. Zmiana platformy sklepowej bez mapy przekierowań potrafi jednorazowo unieważnić cały dorobek serwisu.

Naturalny obrót asortymentem — produkty wycofane, kolekcje sezonowe, wyprzedane egzemplarze. To normalny cykl życia sklepu i nie każdemu takiemu adresowi trzeba szukać następcy.

Literówki w odnośnikach, zarówno własnych, jak i cudzych. Adres, do którego ktoś zalinkował z błędem, będzie odwiedzany latami.

Adresy generowane przez skanery i boty, próbujące trafić na panele administracyjne czy pliki konfiguracyjne. Zapełniają raporty i nie mają żadnego znaczenia.

Ta ostatnia grupa jest istotna, bo pokazuje, dlaczego nie warto dążyć do zera w raporcie błędów. Serwis, który nigdy nie zwraca odpowiedzi o braku strony, jest podejrzany, nie wzorowy.

Jak zebrać pełną listę

Korzystam z kilku źródeł, bo żadne nie pokazuje całości.

Search Console w raporcie indeksowania pokazuje adresy, które Google próbował odwiedzić i dostał błąd. Najważniejsza informacja jest w szczegółach: skąd prowadzi odnośnik. Adresy linkowane z zewnątrz mają zupełnie inny priorytet niż te, o których wie tylko Google z dawnego indeksu.

Crawler przechodzący serwis wskazuje odnośniki wewnętrzne prowadzące w nicość. To błędy do naprawy w treści, nie przez przekierowanie — jeśli link w menu jest błędny, poprawia się link, a nie stawia przekierowanie łatające objaw.

Logi serwera pokazują, co dzieje się w rzeczywistości: które nieistniejące adresy są odwiedzane najczęściej i przez kogo. To najlepsze źródło do priorytetyzacji przy dużych serwisach.

Dane analityczne z opisanej stroną błędu wizyty pozwalają zobaczyć, ilu prawdziwych użytkowników na to trafia. Jeśli setki osób miesięcznie widzą stronę błędu, sprawa jest pilna niezależnie od tego, co mówi teoria.

Kiedy przekierowuję, a kiedy nie

Decyzję podejmuję według jednego kryterium: czy istnieje treść, która realnie zastępuje tę usuniętą z punktu widzenia użytkownika.

Przekierowuję, gdy produkt ma następcę, kategoria została przeniesiona pod nowy adres, artykuł zastąpiono nowszą wersją albo adres zmienił się przy zmianie struktury. Przekierowuję również wtedy, gdy stary adres ma odnośniki zewnętrzne albo mierzalny ruch — nawet jeśli treść zniknęła, warto skierować to na najbliższą tematycznie stronę.

Nie przekierowuję, gdy nic nie zastępuje usuniętej treści. Wyprzedany model bez odpowiednika, kategoria, której firma już nie prowadzi, wpis usunięty z powodu nieaktualności — tam właściwą odpowiedzią jest kod braku strony i przyzwoita strona informacyjna z wyszukiwarką oraz odnośnikami do głównych działów.

W sklepach stosuję jeszcze jeden wariant, o którym rzadko się mówi: zostawienie strony produktu z informacją o niedostępności. Jeśli produkt ma ruch z wyszukiwarki i może wrócić na stan, kasowanie go jest marnotrawstwem. Strona zostaje, informuje o braku, proponuje alternatywy i zbiera zapisy na powiadomienie.

Wdrożenie bez łańcuchów i pętli

Technicznie przekierowania ustawia się w konfiguracji serwera, w warstwie aplikacji albo we wtyczce, jeśli serwis stoi na systemie zarządzania treścią. Wybór ma znaczenie dla wydajności, ale nie dla skutków w wyszukiwarce.

Znaczenie mają natomiast trzy zasady.

Przekierowanie prowadzi bezpośrednio do celu. Łańcuchy, w których adres A prowadzi na B, B na C, a C na D, powstają warstwami przy kolejnych przebudowach. Każde ogniwo to dodatkowe opóźnienie, a przy dłuższych łańcuchach Google przestaje je śledzić. Po każdej migracji warto przejść starą listę i skrócić ścieżki do jednego kroku.

Nie może być pętli. Adres przekierowany na siebie albo dwa adresy wskazujące na siebie wzajemnie unieruchamiają stronę całkowicie, a przy błędach w regułach z wyrażeniami regularnymi zdarza się to łatwiej, niż się wydaje.

Przekierowanie musi wskazywać treść odpowiadającą tematycznie. To wraca do początku tekstu: hurtowe kierowanie wszystkiego na stronę główną nie przenosi wartości i psuje doświadczenie.

Migracja: mapa przed wdrożeniem

Przy zmianie struktury adresów cała praca musi być wykonana przed publikacją, nie po.

Kolejność, którą stosuję: pełna lista starych adresów z crawlera i z Search Console, uzupełniona listą adresów mających ruch i odnośniki. Do każdego przypisany nowy adres w arkuszu — ręcznie tam, gdzie trzeba, i regułą tam, gdzie zmiana jest systematyczna. Testy na środowisku przygotowawczym. Publikacja. Ponowny crawl następnego dnia i sprawdzenie, ile adresów wypadło z mapy.

Po migracji obserwuję raport indeksowania i pozycje przez kilka tygodni. Przejściowe wahania są normalne, bo Google musi ponownie odwiedzić i przeliczyć cały serwis. Niepokojące jest utrzymujące się kilkutygodniowe pogorszenie — wtedy zwykle okazuje się, że część adresów została pominięta albo trafiła w łańcuch.

Sitemapę aktualizuję na nową strukturę, ale starą wersję warto na chwilę zachować dostępną, żeby przyspieszyć odwiedzenie przekierowanych adresów. Wewnętrzne odnośniki natomiast przepisuję na nowe adresy od razu — utrzymywanie w treści linków, które przechodzą przez przekierowanie, jest niepotrzebnym obciążeniem i sygnałem niedokończonej pracy.

Podziel się tym artykułem z innymi!

Twitter Facebook Linke.din
Autor nie posiada zdjęcia
Tomasz Piasecki
Specjalista Google Ads / SEM
Zajmuję się kampaniami Google Ads i widocznością stron w wyszukiwarce. Na blogu UDI Group piszę o tym, jak ustawienia kampanii i decyzje techniczne przekładają się na realne wyniki. Staram się tłumaczyć mechanizmy, a nie tylko podawać gotowe przepisy.