Jak wykryć i naprawić błędy 404 w sklepie Magento przy pomocy Screaming Frog

Czy każdy błąd 404 w Magento trzeba od razu naprawiać? Nie. Jeśli jednak niedziałający adres jest linkowany z menu, siedzi w sitemapie XML albo dotyczy ważnego produktu czy kategorii, problem szybko przestaje być „techniczną drobnostką”. W praktyce najwięcej czasu traci się nie na samo znalezienie błędów 404, tylko na odróżnienie tych istotnych od szumu i dobranie naprawy, która nie psuje struktury SEO sklepu.

Magento 404, Screaming Frog crawl, błędy 404 w sklepie, inlinks Screaming Frog, Magento URL rewrite, sitemap XML Magento, przekierowanie 301 Magento, usunięty produkt SEO, błędne linki wewnętrzne, priorytetyzacja błędów SEO, recrawl URL, techniczne SEO sklepu

Które błędy 404 w Magento naprawdę wymagają reakcji

Nie każdy 404 ma ten sam koszt

W sklepie Magento część błędów 404 to naturalny efekt życia katalogu: produkt został wycofany, kampania się skończyła, stary adres zewnętrzny przestał istnieć. Taki URL nie zawsze wymaga pilnego działania. Inaczej wygląda sytuacja, gdy 404 jest aktywnie linkowany wewnętrznie, trafia do mapy strony albo dotyczy adresu, który wcześniej miał widoczność, linki lub sprzedaż. Wtedy problem uderza jednocześnie w użyteczność i SEO.

Największy priorytet mają zwykle trzy grupy adresów:

• 404 obecne w linkowaniu wewnętrznym – bo robot i użytkownik trafiają na nie z działającej części sklepu,
• 404 obecne w sitemapie XML – bo sklep sam wysyła do Google sygnał, że dany adres powinien być crawlowany,
• 404 po ważnych stronach – dawnych produktach, kategoriach i CMS-ach, które miały ruch, linki lub są częścią kluczowej ścieżki zakupowej.

Niżej na liście znajdują się stare, osierocone URL-e bez inlinks, bez ruchu i bez znaczenia biznesowego. Takie przypadki często da się zostawić jako 404 lub 410, zamiast poświęcać czas na ręczne przekierowywanie wszystkiego jak leci.

Priorytet ustawiaj według efektu, nie według długości listy

Raport Screaming Frog potrafi pokazać setki albo tysiące błędów. To jeszcze nie znaczy, że trzeba naprawiać je po kolei. Sensowniejsze podejście to sortowanie według wpływu. Jeden link do 404 w menu kategorii może generować większy problem niż sto starych adresów po sezonowych produktach, do których nic już nie prowadzi.

Dobry prosty porządek pracy wygląda tak:

1. najpierw 404 z internal inlinks,
2. potem 404 z XML sitemap,
3. następnie 404 po ważnych produktach, kategoriach i stronach treści,
4. na końcu reszta, w tym stare osierocone adresy.

Przykład praktyczny: usunięty produkt sezonowy bez zamiennika, bez linków i bez obecności w sklepie może spokojnie zostać 404 albo 410. Z kolei stary URL kategorii po zmianie URL key, który nadal siedzi w menu albo breadcrumbach, wymaga szybkiej reakcji, bo cały sklep wysyła do niego użytkowników i roboty.

Typowe przypadki, które często mylnie wrzuca się do jednego worka

Magento generuje sporo pozornie podobnych problemów, ale ich źródło bywa zupełnie inne. Literówka w bloku CMS, źle odświeżony rewrite po zmianie adresu kategorii i usunięty produkt bez następcy dają ten sam kod 404, lecz wymagają trzech różnych działań. To ważne, bo zła naprawa też jest kosztem. Jeśli przekierujesz wszystko na siłę, zrobisz porządek „na papierze”, ale pogorszysz trafność i doświadczenie użytkownika.

1. Ustaw szybki crawl tak, żeby wyłapać realne problemy, a nie szum

Wariant na start dla mniejszych sklepów

Jeśli celem jest szybkie wykrycie błędów 404 w sklepie Magento przy pomocy Screaming Frog, nie trzeba od razu budować skomplikowanego audytu. Na start wystarcza podstawowy crawl strony, zbieranie kodów odpowiedzi i osobne sprawdzenie sitemapy XML. Taki zestaw daje najwięcej użytecznych danych przy relatywnie małym nakładzie czasu.

Praktyczne minimum to:

• crawl głównego hosta sklepu,
• analiza adresów Internal,
• filtrowanie po kodzie odpowiedzi 404,
• sprawdzenie, czy Screaming Frog widzi źródła linków w kolumnach i raporcie Inlinks,
• oddzielny crawl albo import XML sitemap.

Przy małych i średnich sklepach to zwykle wystarcza, by szybko ustalić, co naprawdę trzeba poprawić. Dopiero kiedy podstawowy raport pokaże większy chaos, ma sens dokładanie kolejnych warstw, na przykład danych z Google Search Console.

Jak ograniczyć szum typowy dla Magento

Magento bywa podatne na zalewanie crawla adresami parametrycznymi: filtrowanie, sortowanie, paginacja, wyniki wyszukiwania, różne warianty ścieżek technicznych. Jeśli ich nie ograniczysz, raport 404 może być pełen adresów, które nie są głównym problemem sklepu, a jedynie skutkiem niekontrolowanego scope crawla.

W praktyce opłaca się sprawdzić, czy crawl nie zasysa masowo URL-i z parametrami typu sortowanie, filtrowanie lub wyszukiwanie. Jeśli tak, najpierw odetnij szum i dopiero wtedy analizuj błędy. Inaczej można spędzić pół dnia na adresach, które nigdy nie powinny znaleźć się w ważnym obiegu SEO.

Jeżeli czasu jest mało, najtańszy wariant operacyjny wygląda tak:

• crawl sklepu bez rozbudowanych integracji,
• crawl sitemapy XML,
• dopiero później weryfikacja danych z GSC jako dodatkowej warstwy priorytetu.

Kiedy prosty crawl jest lepszy niż „idealna” konfiguracja

W praktyce często wygrywa zasada: lepiej mieć raport dziś niż perfekcyjny crawl za tydzień. Jeśli sklep po migracji albo po zmianach w asortymencie ma wyraźny problem z 404, nie ma sensu blokować działań dlatego, że konfiguracja nie jest jeszcze dopięta w każdym szczególe.

Dla mniejszych zespołów sensowny model pracy to dwa przebiegi. Pierwszy służy szybkiemu wyłapaniu najbardziej kosztownych błędów, drugi jest już dokładniejszy i nastawiony na domknięcie mniej oczywistych przypadków. Dzięki temu nie przepala się czasu na fazę przygotowawczą, gdy najpilniejsze naprawy czekają na wdrożenie.

2. Zacznij od raportów, które najszybciej pokazują koszt błędu

Co sprawdzić w pierwszych 15–30 minutach

Po zakończeniu crawla nie warto skakać po wszystkich zakładkach Screaming Frog. Najszybszą wartość daje przejście przez kilka konkretnych miejsc. Najpierw filtruj strony z kodem 404 w sekcji odpowiedzi. Potem od razu sprawdzaj, czy są to adresy wewnętrzne, czy przypadki zewnętrzne albo marginalne.

Kolejny krok to Inlinks. Ten raport odpowiada na najważniejsze pytanie operacyjne: skąd dokładnie prowadzi link do niedziałającego URL-a? Bez tej informacji łatwo naprawić skutek, ale zostawić źródło problemu. A wtedy 404 wróci przy kolejnym crawlu.

W pierwszej kolejności sprawdzaj, czy źródłem jest:

• menu główne lub nawigacja kategorii,
• listing kategorii,
• sekcja produktów powiązanych, podobnych lub polecanych,
• stopka, blok CMS albo strona informacyjna,
• breadcrumbs, bannery lub ręcznie podpięty link w treści.

Sitemap XML jako szybki test jakości porządków

Jeśli mapa strony zawiera adresy 404, to nie jest już tylko problem pojedynczych URL-i. To sygnał, że trzeba poprawić generator sitemapy, reguły eksportu albo logikę dodawania adresów. Inaczej nawet po ręcznym usunięciu kilku błędnych stron nowe 404 będą wracały.

To częsta pułapka w Magento: zespół poprawia przekierowanie lub usuwa martwy link z kategorii, ale zapomina o sitemapie. Efekt jest taki, że sklep nadal zgłasza wyszukiwarkom nieistniejące adresy. Naprawa wydaje się wdrożona, a problem technicznie wciąż żyje.

Prosty model sortowania raportu

Żeby nie utknąć w chaotycznej liście, dobrze wyeksportować błędy 404 i posortować je według trzech kryteriów:

1. liczba inlinks,
2. typ strony, której dotyczy URL,
3. obecność w sitemapie XML.

Taki układ pozwala szybko odróżnić przypadki ważne od mało istotnych. Jeden 404 z kilkudziesięcioma linkami z nawigacji sklepu ma większy koszt niż grupa zapomnianych URL-i po starych kampaniach. To właśnie ten etap zwykle oszczędza najwięcej czasu.

3. Oddziel typy 404, bo od tego zależy właściwa naprawa

Najczęstsze scenariusze w Magento

Najbardziej typowy przypadek to usunięte produkty. Tu trzeba rozróżnić, czy produkt zniknął na stałe, czy tylko chwilowo, czy ma bezpośredni następnik, a może wróci do oferty za miesiąc. Jeśli to zwykły brak towaru na krótki czas, usuwanie strony i generowanie 404 bywa strzałem w stopę. Jeśli produkt został definitywnie wycofany i nie ma sensownego zamiennika, przekierowanie na siłę też nie pomaga.

Drugi częsty scenariusz to zmiana URL key produktu lub kategorii. Adres teoretycznie nadal ma odpowiednik, ale dawny URL przestał działać, bo rewrite nie został poprawnie utrzymany albo po zmianach struktury nie ma pełnego mapowania. To bardzo częsty problem po porządkach w drzewie kategorii lub po migracji.

Trzecia grupa to błędne linki ręczne. Dotyczą stron CMS, bloków statycznych, bannerów, stopki, landing page’y i sekcji promocyjnych. Te błędy są często banalne technicznie, ale potrafią długo siedzieć niezauważone, bo nie wynikają z logiki katalogu, tylko z ręcznej edycji treści.

Filtry, paginacja i adresy techniczne

W Magento raport może zawierać również URL-e wygenerowane przez filtry lub parametry, które w ogóle nie powinny być intensywnie crawlowane. Jeśli niedziałający adres powstał jako uboczny efekt niespójnego linkowania fasetowego, problemem nie jest wyłącznie pojedynczy 404. Problemem jest to, że sklep generuje lub udostępnia niepotrzebne ścieżki.

Podobnie bywa z paginacją i różnymi wariantami adresów technicznych. Sam błąd 404 jest wtedy objawem większego bałaganu w strukturze URL. W takich sytuacjach samo ustawienie redirectu nie wystarcza, bo źródło będzie produkowało kolejne błędne adresy.

Dlaczego klasyfikacja oszczędza czas

Bez podziału na typy łatwo wpaść w najdroższą pułapkę: ręczne przekierowywanie wszystkiego. To wygląda na szybkie, ale kończy się stertą mało trafnych 301, które utrudniają diagnostykę i pogarszają logikę sklepu. Znacznie taniej jest najpierw oznaczyć URL jako:

• usunięty produkt,
• zmieniony adres istniejącej strony,
• błędny link wewnętrzny,
• adres z mapy strony,
• adres techniczny lub parametryczny.

Po takim podziale szybciej widać też, kto powinien naprawić problem. Część błędów leży po stronie osoby edytującej treści, część po stronie zespołu wdrożeniowego, a część wynika z ustawień katalogu lub modułów. To ważne z czysto operacyjnego powodu: jeśli wrzuci się wszystkie 404 do jednego worka, zadanie zaczyna krążyć między ludźmi i stoi. Gdy od razu opiszesz typ błędu oraz źródło linku, wdrożenie zwykle przyspiesza bez dodatkowych spotkań.

Praktyczny filtr „na start” jest prosty: najpierw odłóż adresy techniczne i parametryczne, potem wyciągnij URL-e obecne w linkowaniu wewnętrznym oraz sitemapie, a dopiero na końcu zajmij się resztą. To daje lepszy efekt niż ręczne przeglądanie całej listy po kolei. W wielu sklepach największa część pracy nie polega na samej naprawie 404, tylko na odcięciu przypadków, które nie zasługują na pilną uwagę.

Dobry porządek roboczy wygląda tak: jeden arkusz, kilka kolumn i zero zgadywania. Dla każdego adresu zapisz typ błędu, źródło linku, proponowaną akcję i właściciela zadania. Taki prosty rejestr zwykle wystarcza, żeby nie wracać drugi raz do tych samych URL-i. A jeśli po tygodniu crawl nadal pokazuje ten sam błąd, od razu wiadomo, czy nie zadziałał redirect, czy po prostu nikt nie poprawił miejsca, z którego link wychodzi.

Najrozsądniejszy następny krok to nie „naprawić wszystko”, tylko usunąć najdroższe 404 w takiej kolejności, w jakiej naprawdę bolą sklep: najpierw te z linkowania wewnętrznego i sitemapy, później błędy po zmianach URL-i, a na końcu osierocone resztki bez znaczenia. Screaming Frog daje tu przewagę nie dlatego, że pokazuje dużo danych, tylko dlatego, że pozwala szybko oddzielić realny koszt od szumu.

4. Dobierz naprawę według prostych kryteriów: 301, przywrócenie, poprawa linku, 404 albo 410

Kiedy redirect 301 ma sens, a kiedy tylko maskuje problem

Najczęstszy błąd po analizie crawla jest prosty: ustawienie 301 na każdy niedziałający adres. To daje szybkie „odhaczenie zadania”, ale często psuje logikę sklepu. Redirect ma sens wtedy, gdy stary URL ma czytelny i bliski odpowiednik.

• Produkt został zastąpiony nową wersją — 301 do następcy zwykle jest dobrym ruchem.
• Kategoria zmieniła adres po porządkach w strukturze — 301 ze starego URL-a na nowy jest naturalny.
• Zmienił się tylko URL key, a treść strony realnie nadal istnieje — redirect jest wręcz podstawową naprawą.

Nie opłaca się natomiast przekierowywać usuniętego produktu na stronę główną, losową kategorię albo ogólny listing tylko po to, żeby „nie było 404”. Z punktu widzenia użytkownika to słabe doświadczenie, a z punktu widzenia SEO to często sygnał, że sklep nie wie, co zrobić z własnymi adresami.

Praktyczny test jest krótki: jeśli po kliknięciu użytkownik uzna, że trafił tam, gdzie powinien, 301 ma sens. Jeśli będzie musiał od nowa szukać produktu, lepiej wybrać inną akcję.

Kiedy lepiej przywrócić stronę niż przekierowywać

W Magento sporo błędów 404 wynika nie z celowego usunięcia, ale z bałaganu po zmianach. Dotyczy to zwłaszcza produktów wyłączonych omyłkowo, źle ustawionych rewrite’ów albo stron kategorii, które powinny istnieć, ale zniknęły po wdrożeniu.

Przywrócenie strony bywa tańsze niż budowanie sieci redirectów, jeśli:

• adres miał ruch lub był ważny sprzedażowo,
• strona nadal powinna istnieć w ofercie,
• 404 pojawił się przez błąd konfiguracji, a nie decyzję biznesową.

Typowy przykład: produkt jest dalej w katalogu, ale po zmianie atrybutu albo importu przestał odpowiadać pod starym adresem i nie ma poprawnego przepięcia. W takiej sytuacji nie naprawiasz „404 produktu”, tylko problem z logiką adresów.

Kiedy wystarczy poprawić link źródłowy

Jeżeli niedziałający URL jest podlinkowany z menu, bannera, CMS blocka albo opisu kategorii, najczęściej najtańszą naprawą jest po prostu korekta linku w źródle. Bez tego nawet najlepiej ustawiony redirect zostawia bałagan i wydłuża ścieżkę przejścia.

Tu dobrze działa prosta zasada:

1. najpierw popraw źródło linku,
2. potem zdecyduj, czy stary adres potrzebuje jeszcze 301,
3. na końcu sprawdź, czy URL nie siedzi dodatkowo w sitemapie lub kanonikalu.

To ważne szczególnie przy linkach z elementów stałych, takich jak stopka czy menu. Jeden błędny URL w takim miejscu potrafi generować dziesiątki albo setki inlinks i sztucznie pompować skalę problemu.

Kiedy zostawić 404 lub użyć 410

Nie każdy martwy adres wymaga ratowania. Jeśli URL dotyczy trwale usuniętego produktu bez sensownego zamiennika, nie ma linkowania wewnętrznego, nie występuje w sitemapie i nie prowadzi do niego ważna ścieżka użytkownika, zostawienie 404 jest całkowicie akceptowalne.

410 bywa lepszym wyborem, gdy masz pewność, że strona została usunięta definitywnie i nie wróci. To szczególnie przydatne po migracjach albo po sprzątaniu starych adresów kampanijnych, których nie chcesz dalej utrzymywać. Nie trzeba jednak robić z tego osobnego projektu. Jeśli zespół nie ma prostego sposobu wdrożenia 410, zwykłe 404 po usunięciu źródeł linków też rozwiązuje sporą część problemu.

Krótka matryca decyzji

• Jest odpowiednik 1:1 — ustaw 301.
• Strona powinna nadal istnieć — przywróć URL lub popraw rewrite.
• Błąd wynika z linkowania wewnętrznego — popraw źródło linku.
• URL jest zbędny i bez znaczenia — zostaw 404 albo wdroż 410.
• Adres siedzi w sitemapie — usuń go z mapy niezależnie od pozostałych działań.

5. Szukaj źródła problemu tam, gdzie Magento najczęściej je ukrywa

Menu, bloki CMS i ręcznie edytowane sekcje

Najwięcej czasu zabierają zwykle nie trudne błędy, tylko te rozproszone. Magento często „chowa” źródło 404 w miejscach, których nikt nie kojarzy z problemem technicznym. Klasyczny przykład to stary link w bloku promocyjnym na stronie kategorii albo banner podpięty w CMS.

Jeśli w Screaming Frog widzisz 404 z niewielką liczbą inlinks, ale wszystkie prowadzą z jednej strony CMS lub jednego szablonu, naprawa jest zwykle szybka. Gdy tych samych 404 jest dużo i mają wspólne źródło, szukaj elementu współdzielonego: bloku, widgetu, komponentu w builderze albo modułu promocyjnego.

XML sitemap, canonicale i hreflangi

Nie każdy niedziałający URL jest widoczny z poziomu samego linkowania wewnętrznego. Część wyjdzie dopiero wtedy, gdy porównasz crawl z sitemapą lub sprawdzisz adresy zgłaszane jako canonical. Jeśli sklep wskazuje 404 jako canonical, problem robi się poważniejszy niż pojedyncza martwa podstrona.

Przy ograniczonym czasie kolejność kontroli może być prosta:

• najpierw 404 obecne w sitemapie,
• potem 404 wskazywane w canonicalach,
• na końcu pozostałe przypadki techniczne.

To podejście jest tańsze niż ręczne przeklikiwanie całego sklepu, bo od razu uderza w miejsca, z których sklep sam komunikuje wyszukiwarce błędne adresy.

Rewrites po zmianie URL key i porządkach w katalogu

W Magento dużo problemów z 404 nie bierze się z usunięcia strony, tylko z niepełnej obsługi przepisań adresów. Dotyczy to szczególnie sytuacji, gdy:

• zmieniono URL key produktu lub kategorii,
• przebudowano drzewo kategorii,
• przenoszono sklep między środowiskami,
• migrowano dane z innej platformy.

Jeżeli dawny adres powinien prowadzić do nowego odpowiednika, a tego nie robi, nie kończ analizy na „ustawić redirect”. Sprawdź, czy problem nie jest szerszy: czy podobne URL-e z tej samej grupy też nie zniknęły. Czasem jedna reguła lub poprawka w procesie generowania rewrite’ów rozwiązuje kilkadziesiąt przypadków naraz.

Filtry i parametry, które produkują śmieciowe adresy

Jeżeli lista 404 jest pełna URL-i z parametrami, najpierw ustal, czy sklep sam je aktywnie linkuje. Jeśli tak, kłopot nie polega na tym, że kilka adresów zwraca 404. Kłopot polega na tym, że warstwa filtrów lub nawigacji generuje niepotrzebne ścieżki.

W praktyce oszczędza czas taki podział:

• parametry bez inlinks i bez znaczenia — nisko w kolejce,
• parametry linkowane z kategorii lub filtrów — do sprawdzenia w warstwie frontu i konfiguracji,
• parametry obecne w sitemapie lub feedach — wysoki priorytet, bo błąd jest systemowy.

Tu często nie potrzeba skomplikowanej diagnozy. Wystarczy zobaczyć, czy źródłem jest moduł filtrów, paginacja albo źle zbudowany link relacyjny. Jeśli jeden komponent generuje serię podobnych 404, naprawa jednostkowa nie ma sensu.

6. Sprawdź, czy naprawa naprawdę zadziałała

Krótki retest zamiast pełnego audytu od zera

Po wdrożeniu poprawek nie trzeba od razu uruchamiać wielkiego crawla całego sklepu. Szybciej i taniej jest zrobić retest wyłącznie na liście naprawianych URL-i. W Screaming Frog wystarczy tryb listy i ponowne sprawdzenie, czy adresy:

• zaczęły zwracać 200,
• przekierowują tam, gdzie powinny,
• zniknęły z linkowania wewnętrznego, jeśli miały zostać usunięte.

To etap, na którym wychodzą typowe wpadki: redirect działa, ale prowadzi przez łańcuch; poprawiono produkt, ale stary link dalej siedzi w CMS; usunięto URL z frontu, ale nadal widnieje w sitemapie.

Co zweryfikować poza samym kodem odpowiedzi

Samo zniknięcie 404 z raportu nie zawsze oznacza, że temat jest zamknięty. Przy każdej ważniejszej poprawce dobrze jeszcze potwierdzić:

• czy źródłowy link wewnętrzny wskazuje już poprawny adres,
• czy nie powstał redirect chain,
• czy nowy URL nie ma przypadkiem noindex lub błędnego canonicala,
• czy stary adres został usunięty z XML sitemap.

To kilka minut więcej, ale oszczędza drugi obieg zadania. Zwłaszcza po szybkich wdrożeniach, gdy różne osoby poprawiają różne miejsca niezależnie od siebie.

7. Ogranicz nawracanie błędów 404 prostą procedurą operacyjną

Minimum procesu, które daje efekt bez rozbudowanego projektu

Duża część sklepów nie potrzebuje skomplikowanego systemu kontroli jakości URL-i. Wystarczy krótka procedura przy zmianach w asortymencie i strukturze:

1. przed usunięciem produktu sprawdź, czy ma ruch, linki i sensowny zamiennik,
2. przy zmianie URL key od razu zaplanuj mapowanie starego adresu,
3. po wdrożeniu aktualizuj sitemapę i krytyczne linki wewnętrzne,
4. po większej zmianie uruchom szybki crawl kontrolny.

To nie jest ciężki proces. Bardziej lista pytań kontrolnych, która chroni przed seryjnym produkowaniem błędów po migracji, zmianie menu albo porządkach w katalogu.

Najbardziej opłacalny rytm kontroli

Jeśli sklep często zmienia ofertę, sensowny jest prosty rytm: krótki crawl po większym wdrożeniu i pełniejsza kontrola cyklicznie. Bez przesady z częstotliwością. Lepiej zrobić jeden sensowny przegląd z priorytetyzacją niż trzy pobieżne analizy, po których nikt nic nie wdroży.

Dobrze też trzymać osobną listę „powracających źródeł” — na przykład konkretnych bloków CMS, modułów filtrów albo typów importu, po których 404 pojawiają się regularnie. To daje szybszy efekt niż kolejne czyszczenie objawów, bo pozwala uderzyć w miejsca, które generują koszt cyklicznie.

Najrozsądniejszy kolejny ruch po pierwszej serii napraw to zestawić trzy rzeczy: które 404 wróciły, skąd wróciły i czy źródło leży w procesie, czy w pojedynczym błędzie. Właśnie tam zwykle zaczyna się realna oszczędność czasu przy pracy ze Screaming Frog i Magento.

Kluczowe Wnioski

• Nie każdy błąd 404 w Magento wymaga naprawy od razu — priorytet mają adresy linkowane wewnętrznie, obecne w sitemapie XML oraz strony, które wcześniej miały ruch, linki albo znaczenie sprzedażowe.
• Najwięcej zysku daje sortowanie błędów według wpływu, a nie według liczby pozycji w raporcie; jeden 404 w menu kategorii bywa groźniejszy niż dziesiątki starych, osieroconych URL-i po wycofanych produktach.
• Usunięte adresy bez inlinks, bez ruchu i bez wartości biznesowej często można zostawić jako 404 lub 410, zamiast tracić czas na masowe przekierowania 301, które tylko „czyszczą raport”, ale nie rozwiązują realnego problemu.
• Ten sam kod 404 nie oznacza tej samej przyczyny — literówka w linku, problem z Magento URL rewrite i usunięty produkt bez zamiennika wymagają różnych działań, więc naprawa „jednym schematem” łatwo psuje trafność SEO i UX.
• Na start wystarcza prosty, tani setup w Screaming Frog: crawl głównego hosta, filtr 404 w sekcji Internal, analiza raportu Inlinks oraz osobne sprawdzenie sitemap XML; rozbudowane integracje można dołożyć dopiero później.
• Przed analizą trzeba odciąć szum typowy dla Magento, zwłaszcza URL-e z parametrami filtrowania, sortowania, paginacji i wyszukiwania, bo inaczej raport 404 szybko zamienia się w listę mało istotnych technikaliów.
• W praktyce lepszy jest szybki crawl wykonany dziś niż idealna konfiguracja za tydzień — sensowny model to dwa przebiegi: najpierw wyłapanie najdroższych błędów, potem dokładniejszy recrawl i domknięcie mniej oczywistych przypadków.

Źródła

• HTTP Semantics. IETF (2022) – Definicje kodów 404, 410 i przekierowań 301 w standardzie HTTP.
• Search Central Documentation: HTTP status codes, and network and DNS errors. Google Search Central – Wpływ kodów 404/410/301 na indeksowanie i przetwarzanie przez Google.
• Search Central Documentation: Manage your sitemaps with a sitemap index file. Google – Zalecenia dla XML sitemap i jakości adresów zgłaszanych do crawlowania.
• Sitemaps XML format. sitemaps.org – Specyfikacja formatu XML sitemap i wymagania dla adresów URL.
• Screaming Frog SEO Spider User Guide. Screaming Frog – Opis crawla, raportów Response Codes, Inlinks i recrawl w narzędziu.
• Adobe Commerce and Magento Open Source User Guide. Adobe – Dokumentacja Magento dotycząca URL rewrites, kategorii, produktów i sitemap.
• Google Search Console Help: Page indexing report. Google Search Console Help – Weryfikacja błędów indeksowania i statusów stron w GSC.