Konfiguracja przekierowań 301 w PrestaShop po migracji

Zrozumienie przekierowań i dlaczego 301 to jedyny prawidłowy wybór

Podczas migracji sklepu PrestaShop adresy URL ulegają zmianie. Produkty, które znajdowały się pod jednym adresem, teraz znajdują się pod innym. Kategorie, które miały jeden slug, teraz mają inny. Bez przekierowań każdy stary adres URL staje się ślepą uliczką, zwracając błąd 404 zarówno odwiedzającym, jak i wyszukiwarkom. Skumulowany efekt jest katastrofalny: utracony ruch, utracone pozycje i utracona sprzedaż.

Przekierowanie to instrukcja z Twojego serwera, która informuje przeglądarki i boty wyszukiwarek, że strona została przeniesiona. Kiedy odwiedzający lub Googlebot żąda starego adresu URL, serwer odpowiada nową lokalizacją, a klient automatycznie ją śledzi. Jednak nie wszystkie przekierowania są równe, a użycie niewłaściwego typu może podważyć całą Twoją migrację.

301 vs 302: Kluczowa różnica

Przekierowanie 301 sygnalizuje trwałe przeniesienie. Informuje wyszukiwarki, aby przeniosły skumulowaną wartość linków (wartość SEO zbudowaną dzięki linkom zwrotnym, jakości treści i zaangażowaniu użytkowników) ze starego adresu URL na nowy. Z czasem Google zastępuje stary adres URL w swoim indeksie nowym. To właśnie tego potrzebujesz po migracji.

Przekierowanie 302 sygnalizuje tymczasowe przeniesienie. Informuje wyszukiwarki, że stary adres URL ostatecznie wróci, więc powinny zachować stary adres URL w indeksie i nie przenosić wartości linków. Użycie przekierowań 302 po trwałej migracji oznacza, że Google nadal próbuje indeksować Twoje stare adresy URL, Twoje nowe adresy URL mają trudności z uzyskaniem autorytetu i tracisz pozycje niepotrzebnie.

Istnieje również przekierowanie 307, które jest odpowiednikiem 302 w HTTP/1.1, oraz przekierowanie 308, które jest odpowiednikiem 301 w HTTP/1.1. Dla celów SEO w PrestaShop 301 jest standardowym i powszechnie obsługiwanym wyborem.

Reguła jest prosta: jeśli strona została trwale przeniesiona, użyj 301. Po migracji strona została trwale przeniesiona. Zawsze używaj 301.

Konfiguracja przekierowań w .htaccess (Apache)

Większość instalacji PrestaShop działa na Apache, a plik .htaccess jest miejscem, w którym konfigurujesz przekierowania. Ten plik znajduje się w katalogu głównym PrestaShop obok index.php.

Kolejność ma znaczenie

Plik .htaccess PrestaShop zawiera reguły rewrite obsługujące przyjazne adresy URL, wymuszanie HTTPS i kierowanie żądań do odpowiednich kontrolerów. Twoje reguły przekierowań muszą być umieszczone przed regułami rewrite PrestaShop. Jeśli umieścisz je po nich, reguły PrestaShop mogą przechwycić żądanie jako pierwsze i Twoje przekierowania nigdy nie zostaną wykonane.

Poszukaj komentarza # Dispatcher lub bloku zaczynającego się od RewriteRule ^api. Twoje niestandardowe przekierowania powinny znaleźć się powyżej tej sekcji, ale po RewriteEngine On.

Przekierowania indywidualnych stron

Najprostszą formą przekierowania jest mapowanie jednego konkretnego starego adresu URL na jeden konkretny nowy adres URL:

Redirect 301 /stara-kategoria/stary-produkt.html https://www.example.com/nowa-kategoria/nowy-produkt

Dyrektywa Redirect jest częścią modułu mod_alias Apache. Pierwszy argument to kod statusu HTTP (301), drugi to stara ścieżka (względem katalogu głównego dokumentów), a trzeci to pełny nowy adres URL.

Ważne szczegóły: stara ścieżka musi zaczynać się od ukośnika i nie może zawierać nazwy domeny. Nowy adres URL musi być pełnym adresem URL zawierającym protokół i domenę. Stara ścieżka jest dopasowywana dokładnie, łącznie z końcowymi ukośnikami i rozszerzeniami plików.

Przekierowania oparte na wzorcach z RewriteRule

Gdy wiele adresów URL podlega przewidywalnej zmianie wzorca, indywidualne przekierowania stają się niepraktyczne. Moduł mod_rewrite Apache pozwala pisać reguły oparte na wzorcach z użyciem wyrażeń regularnych:

RewriteEngine On
RewriteRule ^stara-kategoria/(.*)$ /nowa-kategoria/$1 [R=301,L]

Ta reguła przechwytuje wszystko po stara-kategoria/ i dołącza to do nowa-kategoria/. $1 jest odwołaniem wstecznym do pierwszej przechwyconej grupy (części w nawiasach). Flagi [R=301,L] określają przekierowanie 301 oraz że jest to ostatnia reguła do przetworzenia w przypadku dopasowania.

Typowe scenariusze przekierowań opartych na wzorcach podczas migracji PrestaShop:

Usuwanie rozszerzeń .html:

RewriteRule ^(.+)\.html$ /$1 [R=301,L]

Zmiana z adresów URL kategorii opartych na ID na oparte na nazwach:

RewriteRule ^3-stara-nazwa-kategorii(.*)$ /nowa-nazwa-kategorii$1 [R=301,L]

Przekierowanie całego podkatalogu:

RewriteRule ^shop/(.*)$ /$1 [R=301,L]

Przekierowania warunkowe

Czasami potrzebujesz przekierowań, które stosują się tylko w określonych warunkach. RewriteCond zapewnia tę możliwość:

RewriteCond %{HTTP_HOST} ^staradomena\.com$ [NC]
RewriteRule ^(.*)$ https://www.nowadomena.com/$1 [R=301,L]

To przekierowuje wszystkie żądania ze staradomena.com na nowadomena.com, zachowując ścieżkę. Flaga [NC] sprawia, że warunek jest nieczuły na wielkość liter.

Aby przekierować tylko wtedy, gdy żądany plik nie istnieje na nowym serwerze (przydatne podczas stopniowej migracji):

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^stara-sciezka/(.*)$ /nowa-sciezka/$1 [R=301,L]

Konfiguracja przekierowań w Nginx

Jeśli Twój PrestaShop działa na Nginx, przekierowania konfiguruje się w pliku konfiguracji bloku serwera, zazwyczaj znajdującym się pod /etc/nginx/sites-available/twojadomena.conf lub /etc/nginx/conf.d/twojadomena.conf.

Przekierowania indywidualne

location = /stara-kategoria/stary-produkt.html {
  return 301 https://www.example.com/nowa-kategoria/nowy-produkt;
}

Modyfikator = określa dokładne dopasowanie. Bez niego Nginx traktuje lokalizację jako dopasowanie prefiksowe, co mogłoby przekierować więcej adresów URL niż zamierzono.

Przekierowania oparte na wzorcach

location ~ ^/stara-kategoria/(.*)$ {
  return 301 /nowa-kategoria/$1;
}

Modyfikator ~ włącza dopasowanie regex. Przechwycona grupa $1 działa w ten sam sposób jak w Apache.

Przekierowania oparte na mapie dla dużych list

Dyrektywa map w Nginx jest idealna do zarządzania setkami lub tysiącami indywidualnych przekierowań bez zaśmiecania bloku serwera:

map $request_uri $redirect_target {
  /stary-produkt-1.html /nowy-produkt-1;
  /stary-produkt-2.html /nowy-produkt-2;
  /stary-produkt-3.html /nowy-produkt-3;
}

server {
  if ($redirect_target) {
    return 301 $redirect_target;
  }
}

Blok map jest ewaluowany tylko raz na żądanie i jest wysoce wydajny nawet z tysiącami wpisów. Możesz nawet załadować mapę z zewnętrznego pliku za pomocą dyrektywy include.

Pamiętaj, aby przetestować konfigurację za pomocą nginx -t i przeładować za pomocą systemctl reload nginx po wszelkich zmianach.

Masowe przekierowania z CSV

Przy migracjach obejmujących tysiące produktów, ręczne pisanie reguł przekierowań nie jest wykonalne. Podejście oparte na CSV usprawnia ten proces.

Tworzenie pliku CSV

Wyeksportuj swoje stare adresy URL z danych skanowania przed migracją lub bazy danych. Wyeksportuj nowe adresy URL z nowej instalacji. Dopasuj je w arkuszu kalkulacyjnym z dwiema kolumnami: stara ścieżka URL i nowa ścieżka URL. Zapisz jako CSV.

Twój plik CSV może wyglądać tak:

/3-stara-kategoria,/nowa-kategoria
/stara-kategoria/stary-produkt-1.html,/nowa-kategoria/nowy-produkt-1
/stara-kategoria/stary-produkt-2.html,/nowa-kategoria/nowy-produkt-2
/content/5-o-nas,/content/o-nas

Konwersja CSV na reguły .htaccess

Prostym podejściem jest konwersja każdej linii CSV na dyrektywę Redirect. Za pomocą edytora tekstu z funkcją znajdź i zamień lub prostego narzędzia wiersza poleceń:

awk -F',' '{print "Redirect 301 " $1 " https://www.example.com" $2}' redirects.csv >> .htaccess

To odczytuje plik CSV, dzieli każdą linię po przecinku i generuje dyrektywę Redirect dla każdej linii.

Użycie tabeli bazy danych

Dla bardzo dużych list przekierowań (10 000+ wpisów) rozważ przechowywanie przekierowań w tabeli bazy danych i obsługę ich na poziomie aplikacji. Utwórz tabelę z kolumnami dla starej ścieżki i nowej ścieżki, a następnie napisz mały moduł PrestaShop lub override, który przechwytuje błędy 404, sprawdza tabelę i zwraca przekierowanie 301, jeśli znaleziono dopasowanie. To podejście jest łatwiejsze w zarządzaniu przez interfejs administracyjny, ale dodaje małe zapytanie do bazy danych przy każdej odpowiedzi 404.

Rozwiązania przekierowań oparte na modułach

Kilka modułów PrestaShop zapewnia zarządzanie przekierowaniami przez panel administracyjny, eliminując potrzebę bezpośredniej edycji plików konfiguracji serwera.

Zalety przekierowań opartych na modułach

Moduł do przekierowań oferuje przyjazny interfejs użytkownika do dodawania, edytowania i usuwania przekierowań. Zazwyczaj zawiera funkcjonalność importu/eksportu do operacji masowych, logowanie do śledzenia, które przekierowania są używane, oraz możliwość zarządzania przekierowaniami przez członków zespołu bez dostępu do serwera.

Jak działają przekierowania oparte na modułach

Większość modułów do przekierowań działa poprzez podpięcie do procesu obsługi żądań PrestaShop. Kiedy przychodzi żądanie, które normalnie skutkowałoby błędem 404, moduł je przechwytuje, sprawdza swoją bazę danych przekierowań pod kątem pasującego starego adresu URL, a jeśli go znajdzie, wysyła odpowiedź z przekierowaniem 301 na nowy adres URL.

Niektóre moduły idą dalej, automatycznie tworząc przekierowania, gdy zmienisz przyjazny adres URL produktu w panelu administracyjnym. To zapobiega częstemu problemowi łamania starych linków podczas optymalizacji slugów adresów URL.

Kwestie wydajności

Przekierowania oparte na modułach dodają niewielki narzut do każdego żądania 404, ponieważ muszą odpytać bazę danych. Dla większości sklepów jest to pomijalne, ale jeśli masz tysiące przekierowań i znaczny ruch botów trafiający w stare adresy URL, zapytania do bazy danych mogą się sumować. Rozważ użycie warstwy cache lub przeniesienie najczęściej używanych przekierowań do .htaccess dla optymalnej wydajności.

Przekierowania regex: Moc i niebezpieczeństwo

Przekierowania oparte na wyrażeniach regularnych to potężne narzędzia, które mogą obsługiwać złożone transformacje adresów URL za pomocą jednej reguły. Są również najczęstszym źródłem błędów przekierowań i nieskończonych pętli.

Kiedy używać przekierowań regex

Używaj przekierowań regex, gdy zmiana adresu URL jest zgodna ze spójnym, przewidywalnym wzorcem. Dobrymi kandydatami są: usuwanie lub dodawanie rozszerzeń plików we wszystkich adresach URL, zmiana prefiksu adresu URL dla całej sekcji witryny, usuwanie lub dodawanie prefiksów językowych oraz usuwanie parametrów zapytania.

Typowe wzorce regex dla PrestaShop

Usuwanie prefiksu identyfikatora kategorii, który PrestaShop 1.6 dodaje do adresów URL kategorii:

RewriteRule ^([0-9]+)-(.+)$ /$2 [R=301,L]

To dopasowuje adresy URL takie jak /3-buty i przekierowuje do /buty.

Dodawanie prefiksu językowego:

RewriteCond %{REQUEST_URI} !^/(en|de|fr)/
RewriteRule ^(.+)$ /en/$1 [R=301,L]

Usuwanie podwójnych ukośników:

RewriteRule ^(.*)//(.*)$ /$1/$2 [R=301,L]

Bezpieczne testowanie reguł regex

Przed wdrożeniem przekierowań regex na produkcji, dokładnie je przetestuj. Użyj testera wyrażeń regularnych online (takiego jak regex101.com), aby zweryfikować, że Twój wzorzec dopasowuje adresy URL, które zamierzasz, i nie dopasowuje tych, których nie powinien.

Zacznij od przekierowania 302 podczas testowania. To zapobiega cachowaniu nieprawidłowych przekierowań przez wyszukiwarki. Po zweryfikowaniu, że reguła działa poprawnie, zmień ją na 301.

Testuj przypadki brzegowe: adresy URL z parametrami zapytania, adresy URL ze znakami specjalnymi, adresy URL z wieloma pasującymi wzorcami. Każdy z tych przypadków może ujawnić problemy, które nie są oczywiste przy prostych testowych adresach URL.

Testowanie przekierowań

Wdrażanie przekierowań bez dokładnego testowania to przepis na katastrofę. Oto metody, których powinieneś użyć do weryfikacji przekierowań przed i po uruchomieniu.

Testowanie z wiersza poleceń za pomocą curl

Polecenie curl jest najbardziej niezawodnym sposobem testowania przekierowań, ponieważ pokazuje dokładnie, co zwraca serwer:

curl -I https://www.example.com/stary-produkt.html

Flaga -I żąda tylko nagłówków. W odpowiedzi szukaj:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/nowy-produkt

Zweryfikuj, że kod statusu to 301 (nie 302) i że nagłówek Location wskazuje na prawidłowy nowy adres URL.

Aby śledzić łańcuch przekierowań i zobaczyć każdy skok:

curl -IL https://www.example.com/stary-produkt.html

Flaga -L mówi curl, aby śledził przekierowania, pokazując nagłówki na każdym kroku.

Testowanie masowe

Dla dużych list przekierowań zautomatyzuj testowanie za pomocą pętli:

while IFS=, read -r old new; do
  status=$(curl -s -o /dev/null -w "%{http_code}" "https://www.example.com$old")
  echo "$old -> $status"
done < redirects.csv

To odczytuje plik CSV, testuje każdy stary adres URL i wyświetla kod statusu HTTP. Każdy adres URL, który nie zwraca 301, wymaga uwagi.

Testowanie w przeglądarce

Otwórz narzędzia developerskie przeglądarki (F12), przejdź do karty Sieć (Network) i przejdź do starego adresu URL. Karta Sieć pokazuje łańcuch żądań, w tym wszystkie przekierowania. Zweryfikuj kod statusu, cel przekierowania i ostateczną stronę, która się ładuje.

Inspekcja w Google Search Console

Po wdrożeniu użyj narzędzia Inspekcja adresów URL w Google Search Console, aby sprawdzić, jak Google widzi Twoje przekierowane adresy URL. Wprowadź stary adres URL i sprawdź, czy Google rozpoznaje przekierowanie i odkrył nowy adres URL.

Łańcuchy przekierowań i jak ich unikać

Łańcuch przekierowań występuje, gdy jedno przekierowanie prowadzi do kolejnego przekierowania, które może prowadzić do jeszcze jednego. Na przykład: adres URL A przekierowuje na adres URL B, który przekierowuje na adres URL C, który wreszcie serwuje treść. Każdy skok dodaje opóźnienie i rozcieńcza wartość linków.

Dlaczego łańcuchy przekierowań są szkodliwe

Google oświadczył, że będzie śledzić łańcuchy przekierowań, ale z ograniczeniami. Po określonej liczbie skoków (zazwyczaj 5-10) Googlebot rezygnuje i traktuje adres URL jako błąd. Nawet dla krótszych łańcuchów każdy skok opóźnia dostarczenie strony i traci niewielką ilość wartości linków.

Dla odwiedzających każde przekierowanie dodaje 50-200 milisekund opóźnienia, w zależności od warunków sieciowych i czasu odpowiedzi serwera. Łańcuch 3 przekierowań może dodać pół sekundy lub więcej do postrzeganego czasu ładowania.

Najczęstsze przyczyny łańcuchów przekierowań w PrestaShop

Najczęstszy łańcuch występuje, gdy migracja dodaje przekierowania na istniejących przekierowaniach. Na przykład, możesz mieć stare przekierowania z poprzedniej zmiany struktury URL, a nowa migracja dodaje kolejną warstwę. Adres URL A przekierowuje na adres URL B (z pierwszej migracji), a adres URL B przekierowuje na adres URL C (z drugiej migracji).

Kolejną częstą przyczyną jest interakcja między wbudowanym przekierowaniem kanonicznym PrestaShop a Twoimi niestandardowymi przekierowaniami. PrestaShop może przekierować z niekanonicznego adresu URL na wersję kanoniczną, a jeśli Twoje niestandardowe przekierowanie również pasuje, otrzymujesz łańcuch.

Wymuszanie HTTPS dodaje kolejny potencjalny skok. Jeśli Twoje przekierowanie wskazuje na adres URL HTTP, a serwer następnie przekierowuje na HTTPS, to jest dwukrokowy łańcuch.

Naprawianie łańcuchów przekierowań

Regularnie audytuj swoje przekierowania za pomocą narzędzia do crawlowania, które wykrywa łańcuchy. Gdy znajdziesz łańcuch, zaktualizuj pierwsze przekierowanie tak, aby wskazywało bezpośrednio na ostateczny cel. Adres URL A powinien przekierowywać bezpośrednio na adres URL C, omijając adres URL B.

Dodając nowe przekierowania podczas migracji, zawsze sprawdzaj, czy docelowy adres URL sam nie jest przekierowaniem. Jeśli jest, ustaw nowe przekierowanie tak, aby wskazywało na ostateczny cel.

Najczęstsze pułapki i jak ich unikać

Nieskończone pętle przekierowań

Nieskończona pętla występuje, gdy adres URL A przekierowuje na adres URL B, a adres URL B przekierowuje z powrotem na adres URL A. Przeglądarka wykrywa to i wyświetla błąd ERR_TOO_MANY_REDIRECTS. Częste przyczyny obejmują sprzeczne reguły w .htaccess (jedna reguła przekierowuje www na non-www, a druga przekierowuje non-www na www), sprzeczne przekierowania między .htaccess a modułem do przekierowań oraz reguły regex, które są zbyt szerokie i dopasowują swoje własne docelowe adresy URL.

Aby naprawić pętlę, zacznij od wyłączenia wszystkich niestandardowych przekierowań i włączaj je jedno po drugim, aż pętla się pojawi. To identyfikuje konfliktową regułę.

Zapominanie o parametrach zapytania

Domyślnie dyrektywa Redirect Apache przepuszcza parametry zapytania do nowego adresu URL. Jednak RewriteRule nie przepuszcza parametrów zapytania, chyba że dodasz flagę [QSA] (Query String Append). Jeśli Twoje stare adresy URL zawierają ważne parametry zapytania (takie jak ?id_product=123), upewnij się, że są prawidłowo obsługiwane.

Wielkość liter

Na serwerach Linux adresy URL rozróżniają wielkość liter. /Produkt.html i /produkt.html to różne adresy URL. Jeśli Twoja stara strona miała adresy URL z mieszaną wielkością liter, a nowa normalizuje do małych liter, potrzebujesz przekierowań obsługujących oba przypadki. Użyj flagi [NC] w RewriteRule dla dopasowania nieczułego na wielkość liter.

Brak przekierowania wszystkich wariantów URL

Pojedyncza strona produktowa może być dostępna pod wieloma adresami URL: z końcowym ukośnikiem i bez niego, z rozszerzeniem .html i bez niego, z prefiksem ścieżki kategorii i bez niego, z www i bez www. Każdy wariant, który został zaindeksowany, potrzebuje własnego przekierowania na nowy kanoniczny adres URL.

Pozostawianie przekierowań na zawsze

Chociaż przekierowania powinny pozostać na miejscu przez co najmniej 12 miesięcy po migracji (Google zaleca co najmniej rok), nie powinny pozostawać w nieskończoność. Po roku lub dłużej stare adresy URL nie powinny pojawiać się w wynikach wyszukiwania ani generować znaczącego ruchu. Audytuj logi przekierowań, usuń reguły, które nie są już aktywowane, i utrzymuj czystą konfigurację.

Podsumowanie

Prawidłowa konfiguracja przekierowań 301 to najważniejsze zadanie techniczne podczas migracji PrestaShop. Każdy stary adres URL, który miał ruch, linki zwrotne lub widoczność w wyszukiwarkach, musi przekierowywać na swój nowy odpowiednik z kodem statusu 301. Metoda implementacji zależy od Twojego serwera (Apache .htaccess lub konfiguracja Nginx), liczby adresów URL (indywidualne reguły, wzorce regex lub moduły wspierane bazą danych) i kompetencji technicznych Twojego zespołu. Testuj każde przekierowanie przed uruchomieniem za pomocą curl lub narzędzi developerskich przeglądarki. Uważaj na łańcuchy przekierowań, nieskończone pętle i kwestie wielkości liter. Monitoruj Google Search Console po wdrożeniu, aby zweryfikować, że Google prawidłowo przetwarza Twoje przekierowania. I pamiętaj, że 302 tam, gdzie powinno być 301, nigdy nie jest nieszkodliwe. To zawsze zły wybór dla trwałej migracji.