Przekierowania 301/302 PrestaShop po migracji: bezpieczne mapowanie URL
Zmiana adresu URL w PrestaShop jest prosta. Zachowanie wartości starego adresu wymaga planowania.
Aktualizacja platformy, przebudowa kategorii, zmiana nazwy produktu, przeniesienie domeny lub porządkowanie katalogu mogą sprawić, że wyszukiwarki, klienci, zakładki i linki zewnętrzne będą prowadzić do ścieżek, które już nie istnieją. Jeśli takie żądania kończą się po prostu odpowiedzią 404, użytkownicy tracą oczekiwany cel, a wyszukiwarki muszą ponownie odkryć nową strukturę bez jasnego mapowania.
Najbezpieczniejszy proces migracji polega na przygotowaniu jednoznacznego mapowania każdej ważnej starej ścieżki na najbardziej odpowiedni nowy cel, świadomym wyborze typu przekierowania, przetestowaniu odpowiedzi przed uruchomieniem i po nim oraz dalszym monitorowaniu pominiętych adresów.
1. Przygotuj mapę przekierowań przed zmianą adresów URL
Nie zaczynaj od reguły przekierowania. Zacznij od inwentaryzacji.
Przed migracją wyeksportuj lub zapisz ważne obecne adresy. Uwzględnij:
- adresy URL produktów;
- adresy URL kategorii;
- strony CMS;
- artykuły blogowe lub strony docelowe z dużym ruchem;
- adresy kampanii nadal otrzymujące ruch zewnętrzny;
- adresy z wartościowymi linkami przychodzącymi;
- ścieżki zmieniane z powodu nowej konwencji nazewnictwa lub routingu.
Następnie przypisz cel każdemu adresowi, który zniknie.
Celem zwykle powinna być najbliższa równoważna strona. Wycofany produkt może prowadzić do bezpośredniego zamiennika albo ściśle powiązanej kategorii. Przekierowanie wszystkich brakujących produktów na stronę główną jest technicznie poprawne, ale pogarsza ścieżkę użytkownika i często gubi pierwotną intencję.
2. Używaj 301, gdy przeniesienie ma być trwałe
Przekierowanie 301 informuje, że stara lokalizacja została trwale przeniesiona pod nowy adres. To zwykle właściwy wybór, gdy migracja, zmiana nazwy lub trwała przebudowa katalogu zastępuje stary URL.
Przekierowanie 302 informuje o przeniesieniu tymczasowym. Używaj go, gdy pierwotny adres ma ponownie stać się główną lokalizacją lub zmiana routingu jest celowo tymczasowa.
Nie wybieraj 302 tylko dlatego, że obawiasz się migracji. Kod statusu powinien opisywać zamierzoną relację między starą a nową lokalizacją.
3. Spójnie normalizuj ścieżkę źródłową
Menedżer przekierowań potrzebuje przewidywalnego sposobu rozpoznawania przychodzącego żądania. W URL Redirect Migration Helper Lite reguły Lite używają dokładnych ścieżek źródłowych.
Na przykład źródło może reprezentować starą ścieżkę sklepu:
/old-category/blue-notebookNajważniejsza jest spójność. Nie twórz kilku inaczej sformatowanych wersji tego samego źródła, chyba że naprawdę odpowiadają różnym żądaniom.
Oddzielnie zdecyduj o zachowaniu ciągów zapytania. Żądanie takie jak:
/old-page?utm_source=newslettermoże wymagać zachowania przychodzącego ciągu zapytania pod nowym adresem, podczas gdy parametry śledzenia lub nieaktualne parametry aplikacji lepiej usunąć. Potraktuj to jako świadomą decyzję migracyjną, a nie przypadkowy efekt uboczny.
4. Preferuj dokładne mapowania ważnych adresów
Dokładne reguły łatwo przeglądać, ponieważ jedno znane źródło ma jeden znany cel. Są szczególnie przydatne dla:
- najważniejszych stron docelowych;
- produktów z zewnętrznymi linkami przychodzącymi;
- kategorii ze zmienionymi nazwami;
- starych stron CMS;
- adresów, które wcześniej miały dobre pozycje lub generowały konwersje.
Szerokie reguły z symbolami wieloznacznymi mogą być przydatne w większych migracjach, ale łatwiej zastosować je zbyt szeroko. URL Redirect Migration Helper Lite celowo koncentruje się na dokładnych regułach 301/302; reguły z symbolami wieloznacznymi są funkcją Pro.
Nawet gdy istnieje szeroki wzorzec, zachowaj najważniejsze wyjątki jako jawne reguły, aby łatwo je audytować.
5. Wyświetl podgląd importu CSV przed zapisem reguł
Duże migracje zwykle łatwiej przygotować w arkuszu niż ręcznie dodawać setki reguł. Ryzyko polega na masowym zaimportowaniu błędnego mapowania.
Bezpieczny proces CSV ma dwie fazy:
- parsowanie i walidację pliku;
- pokazanie, co zostanie dodane lub zmienione, zanim cokolwiek zatwierdzisz.
Sprawdź co najmniej:
- nieprawidłowe wiersze;
- zduplikowane ścieżki źródłowe;
- puste cele;
- konflikty z istniejącymi regułami;
- zamierzony typ 301/302;
- czy istniejącą regułę należy pominąć, czy zaktualizować.
URL Redirect Migration Helper Lite oferuje podgląd przed importem oraz obsługę konfliktów. Może też wyeksportować reguły przekierowań bieżącego sklepu do CSV na potrzeby kopii zapasowej lub przeglądu.
6. Unikaj łańcuchów przekierowań
Migracja może przypadkowo utworzyć łańcuchy takie jak:
/old-a → /old-b → /new-cBardziej uporządkowany wynik to zwykle:
/old-a → /new-c
/old-b → /new-cKażdy dodatkowy krok oznacza kolejne żądanie i kolejną okazję do błędu konfiguracji.
Przed uruchomieniem kieruj stare cele do ich zamierzonej ostatecznej lokalizacji, gdzie jest to praktyczne. Narzędzia Pro mogą automatyzować analizę łańcuchów i pętli, ale użytkownicy Lite również mogą zapobiec większości problemów, przeglądając mapę przed importem i testując końcową odpowiedź.
7. Nigdy nie twórz pętli przekierowań
Pętla może być bezpośrednia:
/a → /b
/b → /alub pośrednia, przez kilka reguł. Przeglądarki ostatecznie przestają śledzić taką sekwencję, ale użytkownik nigdy nie dociera do przydatnej treści.
Zmieniając istniejące mapowanie, przetestuj stare źródło i nowy cel. Ostateczny cel powinien zwracać treść, a nie kolejną trasę, która w końcu prowadzi z powrotem do źródła.
8. Testuj odpowiedź HTTP, nie tylko ekran przeglądarki
Przeglądarka może sprawić, że wadliwa konfiguracja wygląda na poprawną, ponieważ automatycznie podąża za przekierowaniami. Podczas kontroli migracji sprawdzaj rzeczywistą odpowiedź.
Dla każdej ważnej reguły potwierdź, że:
- stary adres zwraca zamierzone 301 lub 302;
Locationwskazuje oczekiwany cel;- cel zwraca oczekiwaną końcową odpowiedź;
- nie ma niepotrzebnego łańcucha;
- zachowanie ciągu zapytania odpowiada planowi;
- przekierowanie jest aktywne we właściwym sklepie.
Użyj prywatnej sesji przeglądarki lub narzędzia kontroli HTTP, aby zapisane w cache przekierowania nie ukrywały zmian podczas testów.
9. Aktualizuj również linki wewnętrzne
Przekierowanie jest warstwą zgodności dla starych odwołań. Nie powinno stać się normalnym sposobem nawigowania po Twoim sklepie.
Po migracji zaktualizuj:
- menu;
- opisy kategorii;
- opisy produktów;
- linki CMS;
- wewnętrzne linki bloga;
- adresy generowane w mapie witryny XML;
- szablony e-maili i cykliczne kampanie, gdy ma to zastosowanie.
Linki wewnętrzne powinny prowadzić bezpośrednio do ostatecznego URL, aby klienci i roboty nie wykonywali możliwego do uniknięcia przekierowania przy każdej wizycie.
Szerszą listę kontrolną SEO znajdziesz w naszym przewodniku SEO dla PrestaShop 9.
10. Traktuj 404 po uruchomieniu jako informację zwrotną o migracji
Żadna inwentaryzacja migracyjna nie jest idealna. Stare linki mogą istnieć w indeksach wyszukiwarek, zapomnianych e-mailach, serwisach partnerów, zakładkach przeglądarki i treściach zewnętrznych, nad którymi nie masz kontroli.
Po uruchomieniu przeglądaj ruch 404 i pytaj:
- Czy brakująca ścieżka jest rzeczywistym starym adresem?
- Czy nadal otrzymuje istotny ruch?
- Czy istnieje jednoznaczny równoważny cel?
- Czy należy dodać przekierowanie, czy prawdziwa odpowiedź 404 jest właściwym wynikiem?
Nie przekierowuj automatycznie każdego 404. Adresy z literówkami, ścieżki generowane przez boty i żądania treści, która nigdy nie istniała, często powinny nadal zwracać 404.
11. Wykorzystuj dane trafień zamiast zgadywania
Liczniki trafień przekierowań i znaczniki ostatniego trafienia pomagają odróżnić reguły nadal otrzymujące rzeczywiste żądania od reguł przygotowanych, lecz nigdy nieużytych.
URL Redirect Migration Helper Lite zapisuje liczbę trafień i informacje o ostatnim trafieniu dla reguł. Dzięki temu tabela przekierowań staje się przydatniejszym operacyjnym rejestrem migracji zamiast statyczną listą, do której nikt nie wraca.
12. Ograniczaj przekierowania do właściwego sklepu w multistore
W środowisku multistore ta sama ścieżka może mieć inne znaczenie zależnie od aktywnego sklepu lub domeny. Powiąż mapę migracji ze sklepem będącym właścicielem struktury URL i testuj każdy sklep osobno.
Udane przekierowanie w jednym sklepie nie dowodzi, że inny ma tę samą regułę lub cel.
Lista kontrolna bezpiecznych przekierowań migracyjnych PrestaShop
- Wyeksportuj ważne stare adresy przed migracją.
- Przypisz każdy znikający adres do najbliższego przydatnego celu.
- Używaj 301 do trwałych zmian i 302 do rzeczywiście tymczasowych.
- Zdecyduj, jak obsługiwać ciągi zapytania.
- Wyświetl podgląd masowego importu lub CSV przed zapisem reguł.
- Usuń niepotrzebne łańcuchy, kierując do ostatecznego celu.
- Przetestuj kod statusu i nagłówek Location.
- Zaktualizuj linki wewnętrzne do ostatecznych adresów.
- Monitoruj 404 po uruchomieniu.
- Przeglądaj trafienia przekierowań i dodawaj pominięte ważne mapowania.
Używaj URL Redirect Migration Helper Lite do dokładnych reguł migracji
URL Redirect Migration Helper Lite to bezpłatne rozwiązanie PrestaSuite do dokładnych przekierowań w PrestaShop 8/9. Zapewnia dokładne reguły 301/302, włączanie i wyłączanie, obsługę ciągów zapytania, liczniki trafień, podgląd, import i eksport CSV oraz diagnostykę działania.
Lite celowo koncentruje się na dokładnych przekierowaniach. Wersja Pro dodaje reguły z symbolami wieloznacznymi, harmonogramy, działania masowe, testy symulacyjne, narzędzia do łańcuchów i pętli oraz śledzenie 404 dla większych migracji.
Najczęściej zadawane pytania
Czy każdy usunięty produkt powinien przekierowywać do swojej kategorii?
Nie. Użyj najbliższego odpowiedniego celu. Bezpośredni zamiennik może być lepszy niż kategoria nadrzędna, a produkt bez sensownego zamiennika może zasadnie pozostać niedostępny.
Czy przekierowywać każde 404 na stronę główną?
Nie. Ukrywa to różnicę między przeniesioną stroną a adresem, który nigdy nie miał prawidłowego zamiennika. Przekierowuj tylko wtedy, gdy możesz wskazać przydatny cel.
Czy mogę użyć 302 podczas trwałej migracji i zmienić go później?
Możesz, ale jeśli już wiadomo, że przeniesienie jest trwałe, 301 lepiej opisuje zamierzoną relację od początku.
Czy zawsze zachowywać parametry zapytania?
Nie. Zachowuj je, gdy nadal mają znaczenie pod nowym adresem. Stare parametry aplikacji, które już nie obowiązują, mogą tworzyć mylące lub zduplikowane żądania.