URL rewrites w Magento 2: jak naprawic 404 i SEO

Dlaczego adresy URL w Magento 2 nagle generuja 404 i duplikaty?

Wystarczy wiekszy import produktow, masowa zmiana drzewa kategorii, przelaczenie opcji w panelu albo migracja bazy danych, by w Magento 2 rozpetal sie cichy koszmar SEO. Silnik platformy zaczyna gubic mapowanie przyjaznych linkow na sciezki systemowe, a w tabeli url_rewrite pojawiaja sie tysiace osieroconych rekordow, zapetlenia przekierowan 301 lub losowe bledy 404 na stronach kluczowych produktow. Jesli robot Google trafi na taka zawieruche, zaindeksowane pozycje spadaja z dnia na dzien. Zamiast manualnie edytowac setki rekordow w bazie danych, mozesz wykorzystac nasze darmowe narzedzie do regeneracji URL rewrites, ktore bezpiecznie odtwarza cala strukture adresow od zera.

Mechanizm generowania adresow w Magento jest historycznie jednym z najbardziej podatnych na awarie elementow systemu. Gdy silnik dziala poprawnie, tlumaczy adres w stylu /kurtka-zimowa.html na wewnetrzne wywolanie catalog/product/view/id/145. Kiedy jednak cos po drodze peknie — na przyklad przerwany proces reindeksacji lub konflikt kluczy URL miedzy widokami sklepu — klienci zamiast karty produktu ogladaja strone bledu, a budzet indeksowania w Google Search Console jest marnowany na skanowanie martwych linkow.

Dlaczego tabela url_rewrite w Magento tak latwo sie rozrasta i psuje?

Tabela url_rewrite to serce routingu w Magento 2. Kazdy produkt, kazda kategoria i kazda strona CMS maja w niej swoj wpis (lub caly zestaw wpisow dla roznych Store Views). Problem polega na tym, ze domyslna logika Magento jest wyjatkowo nadgorliwa. Jesli przypiszesz jeden produkt do pieciu roznych podkategorii, platforma potrafi wygenerowac osobny wpis rewrite dla kazdej mozliwej kombinacji sciezki, nawet jesli w konfiguracji teoretycznie chcesz zachowac krotkie, plaskie adresy.

Typowe scenariusze, ktore dewastuja te tabele, to:

• Zmiana slugow w plikach CSV: Import zaktualizowanych nazw bez zaznaczenia odpowiednich flag tworzy nowe rekordy, pozostawiajac stare z blednymi flagami przekierowan.
• Przenoszenie kategorii w drzewie: Zmiana polozenia glownej kategorii nadrzednej wymusza przeliczenie sciezek dla wszystkich podkategorii i powiazanych produktow. Przerwanie tego procesu przez timeout serwera zostawia baze w stanie niespojnosci.
• Przelaczanie opcji w konfiguracji sklepu: Manipulowanie ustawieniem Use Categories Path for Product URLs przy duzej bazie asortymentowej powoduje, ze stare wpisy nie zawsze sa usuwane, tworzac kolizje unikalnosci kluczy.

W skrajnych przypadkach w sklepach majacych 30 000 produktow widywalismy tabele url_rewrite przekraczajace 4 miliony wierszy. Taki narzut spowalnia nie tylko zapytania SQL przy kazdym odslonieciu strony, ale kompletnie blokuje codzienne reindeksy.

Dlaczego po przejsciu na Magento 2.4.9 stare moduly rzucaja Fatal Error?

Wielu wlascicieli sklepow i programistow probowalo ratowac sytuacje popularnymi modulami open-source z GitHuba, ktore powstawaly w erze wersji 2.2 czy 2.3. Niestety, srodowisko techniczne Magento mocno poszlo do przodu. W wydaniu Magento 2.4.9, dzialajacym pod kontrola PHP 8.4, zaktualizowano zaleznosci rdzenia do biblioteki Symfony Console 7.4.

Efekt? Wszystkie starsze moduly CLI, w ktorych metoda execute() komendy konsolowej nie posiadala zadeklarowanego scislego typu zwracanego int, powoduja natychmiastowy Fatal Error. Wystarczy wpisac w terminalu dowolne polecenie bin/magento, a caly system odmawia posluszenstwa, uniemozliwiajac nawet wyczyszczenie cache. Do tego dochodza rygorystyczne ograniczenia w plikach composer.json, ktore blokowaly instalacje narzedzi na nowszych wersjach interpretera PHP.

W SISL prowadzimy autorska inicjatywe: bierzemy porzucone, ale uzyteczne moduly spolecznosci Magento, naprawiamy ich architekture, dostosowujemy do wymogow PHP 8.4 i udostepniamy je za darmo jako nowoczesne forki.

Narzedzie 1: Regenerate URL Rewrites — odbudowa bazy bez magii w SQL

Gdy baza danych jest juz uszkodzona, najgorsze co mozna zrobic, to reczne manipulowanie zapytaniami DELETE bez znajomosci powiazan w tabelach EAV. Nasz fork modulu rozwiazuje ten problem kompleksowo na poziomie API Magento.

Repozytorium: github.com/SISL-source/magento2-regenerate-url-rewrites

Modul dostarcza stabilna, odporna na bledy komende konsolowa:

bin/magento ok:urlrewrites:regenerate

Jak to dziala w praktyce?

• Komenda pobiera rzeczywista strukture kategorii oraz produktow bezposrednio z repozytoriow Magento i generuje poprawne wpisy w tabeli url_rewrite na czysto.
• Pozwala na precyzyjne zawezanie operacji za pomoca przelacznikow — mozesz przebudowac adresy tylko dla wybranego sklepu (--store-id=1) albo wylacznie dla okreslonego typu zasobow (kategorie lub produkty).
• Kod zostal w pelni przepisany pod katem zgodnosci z Symfony Console 7.4 i PHP 8.4, wiec dziala stabilnie na srodowiskach Magento 2.4.9 bez ryzyka wygenerowania bledu fatalnego.

Narzedzie 2: URL Rewrite Optimiser — jak zatrzymac duplikaty u zrodla?

Sama regeneracja tabeli to gaszenie pozaru. Jesli w konfiguracji sklepu (Stores > Configuration > Catalog > Search Engine Optimization) masz wylaczona opcje Use Categories Path for Product URLs, logicznym jest, ze oczekujesz wylacznie krotkich linkow postaci /produkt.html. Niestety, rdzen Magento i tak w wielu sytuacjach generuje nadmiarowe wpisy z pelnymi sciezkami kategorii w tle.

Repozytorium: github.com/SISL-source/module-url-rewrite-optimiser

Nasz fork tego narzedzia dziala jak filtr prewencyjny:

1. Przechwytuje proces zapisu produktu i kategorii w warstwie pluginow/obserwerow.
2. Jesli sciezki kategorii w adresach sa globalnie wylaczone, modul definitywnie blokuje wrzucanie do tabeli url_rewrite wariantow ze sciezkami nadrzednymi.
3. Zmniejsza rozmiar tabeli o 60–80% na duzych katalogach, co bezposrednio przeklada sie na szybsze wykonywanie zapytan w MySQL i brak kanibalizacji adresow w indeksie wyszukiwarek.
4. Usunelismy zaleznosci blokujace instalacje przez Composer na platformach z PHP 8.3 oraz 8.4.

Narzedzie 3: CMS Canonical — brakujacy element technicznego SEO w Magento

Kolejna niedorobka rdzenia Magento, ktora wychodzi podczas audytow SEO, to obsluga stron statycznych CMS (takich jak strona glowna, regulaminy czy strony ladowania). Magento natywnie potrafi dodawac tagi canonical do produktow i kategorii, ale kompletnie pomija ten mechanizm na stronach zarzadzanych przez modul CMS.

Repozytorium: github.com/SISL-source/magento2-cms-canonical

Dlaczego to powazny problem?

• Wielojozyczne sklepy (Multi-Store) czesto wspoldziela identyczne lub blizniacze tresci CMS pod roznymi adresami widokow.
• Strony CMS sa podatne na powstawanie duplikatow wywolywanych parametrami sledzacymi (np. kampanie UTM, parametry sortowania czy paginacji).
• Modul dodaje czysty, poprawny naglowek <link rel="canonical" href="..." /> do kazdej strony CMS, jednoznacznie wskazujacy robotom indeksujacym zrodlowy adres dokumentu.

Jak krok po kroku uporzadkowac routing w sklepie?

Naprawa struktury adresowej wymaga dyscypliny. Zeby nie odciac ruchu organicznego w trakcie prac, zalecamy nastepujacy schemat dzialania na srodowisku stagingowym, a nastepnie wdrozenie na produkcji:

1. Kopia zapasowa: Wykonaj pelny zrzut bazy danych, ze szczegolnym uwzglednieniem tabel url_rewrite oraz catalog_url_rewrite_product_category.
2. Instalacja modulow: Pobierz zoptymalizowane forki przez Composer i aktywuj je komenda bin/magento setup:upgrade.
3. Weryfikacja konfiguracji: Upewnij sie, ze opcja Use Categories Path for Product URLs jest ustawiona zgodnie z Twoja strategia SEO (rekomendujemy wylaczenie jej dla zachowania stabilnych, plaskich URL-i).
4. Pelna regeneracja: Uruchom bin/magento ok:urlrewrites:regenerate i poczekaj na zakonczenie procesu dla wszystkich widokow sklepu.
5. Czyszczenie i reindeksacja: Wykonaj bin/magento indexer:reindex oraz wyczysc pamiec podreczna (Full Page Cache / Varnish).
6. Audyt w Google Search Console: Sprawdz raport Strony pod katem ewentualnych bledow przekierowan lub nieprawidlowych tagow kanonicznych.

Uporzadkowanie routingu w Magento 2.4.9 to nie tylko kwestia higieny bazy danych, ale przede wszystkim zabezpieczenie widocznosci sklepu w organicznych wynikach wyszukiwania. Jesli po wdrozeniu nadal walczysz z nietypowymi petlami przekierowan lub specyficznymi integracjami ERP, ktore niszcza strukture linkow, napisz do nas — sprawdzimy Twoja konfiguracje i pomozemy bezwypadkowo wyprowadzic sklep na prosta.