Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
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.
Zanim cokolwiek naprawię, upewniam się, że rozumiem, co serwer odpowiada.
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.
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.
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.
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.
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.
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.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |