PrestaShop: adresy URL, canonical i przekierowania

Co byśmy zrobili

Przed wyborem narzędzi określilibyśmy rodzaj zadania: korekta obecnych zasad URL, nowe wymaganie dotyczące routingu czy przeniesienie samego sklepu. Właściwe rozwiązanie zależy od obecnego sklepu: skonfigurowanych wzorców, modułów, motywu, danych katalogowych, integracji, języków i rynków oraz osoby, która będzie później utrzymywać przekierowania. Uwzględnij w ocenie linki generowane przez motyw i moduły, importowane slugi oraz punkty końcowe integracji.

Wprowadź uzgodnioną zmianę na chronionej kopii stagingowej z tymi samymi komponentami routingu i reprezentatywnymi danymi katalogowymi. Odizoluj kopię od produkcyjnych wiadomości do klientów, płatności i eksportów zapasów lub ERP. Przećwicz mapę tras i procesy zakupowe, a następnie zaplanuj przełączenie produkcyjne z wyznaczoną osobą odpowiedzialną, zapisaną konfiguracją i sposobem wycofania zmiany. Przechowuj zatwierdzoną mapę wraz z wynikami testów, aby wdrożenie produkcyjne używało faktycznie przetestowanych reguł.

Jeśli przed wdrożeniem chcesz zweryfikować dowody i priorytety, PrestaShop SEO Audit & Action Plan zapewnia przegląd tylko do odczytu i uporządkowany plan poprawek; wdrożenie jest osobne.

Poznaj natywne URL przed ich zmianą

Przed planowaniem zmiany struktury sprawdź rzeczywiste trasy sklepu. W nowszych wersjach użyj Parametry sklepu > Ruch i SEO. W PrestaShop 1.6 użyj Preferencje > SEO i URL.

• Przyjazny URL: PS_REWRITING_SETTINGS włącza czytelne trasy. Apache potrzebuje działającej konfiguracji przepisywania; Nginx własnych dopasowanych reguł serwera.
• Adresy URL ze znakami diakrytycznymi: PS_ALLOW_ACCENTED_CHARS_URL steruje slugami ze znakami diakrytycznymi. Wybierz spójną politykę znaków i testuj kodowanie zamiast zakładać niepoprawność URL spoza ASCII.
• Przekierowanie kanoniczne: PS_CANONICAL_REDIRECT steruje natywnym przekierowaniem do preferowanych URL dla obsługiwanych stron. Testuj rzeczywistą odpowiedź, a nie tylko ustawienie.

Natywne trasy produktów, kategorii i CMS używają identyfikatorów. Wzorce produktów PrestaShop 1.7/8 mogą zawierać informacje o kategorii. Domyślna reguła produktu PrestaShop 9 to {id}{-:id_product_attribute}-{rewrite}.html, bez kategorii. Zaktualizowane sklepy mogą zachować skonfigurowane wzorce.

Przypisanie produktu do dwóch kategorii nie powoduje automatycznie używania każdej z nich w natywnych linkach. Żądania alternatywnych ścieżek kategorii mogą się rozwiązywać, podczas gdy zwykłe generowanie linków i przekierowanie kanoniczne je konsolidują. Sprawdź generowane linki, tagi canonical HTML i odpowiedzi HTTP przed zmianą struktury.

Zachowanie ID jest poprawnym wyborem projektowym. Jeśli potrzebujesz wzorca bez ID, takiego jak /blue-wallet, potrzebujesz routingu, który go rozwiąże. Samo usunięcie {id} lub przekierowanie do ładniejszej ścieżki nie implementuje tej trasy.

Zmieniaj działającą strukturę, aby rozwiązać konkretny problem, taki jak niedziałający routing lub utrwalone niespójne linki. Nie zakładaj, że samo usunięcie ID, rozszerzeń lub elementu kategorii poprawia pozycje.

Sprawdź slugi, języki, sklepy i kolizje tras

Wartości link_rewrite znajdują się w tabelach językowych, takich jak product_lang, category_lang i cms_lang. Mogą też mieć zakres sklepu. Audyt slugów musi zachować kontekst języka i sklepu.

Ten przykład tylko do odczytu sprawdza powtarzające się slugi produktów w sklepie 1 i języku 1. W razie potrzeby zmień prefiks tabel i zakres.

SELECT id_shop, id_lang, link_rewrite,
       COUNT(DISTINCT id_product) AS distinct_products
FROM ps_product_lang
WHERE id_shop = 1 AND id_lang = 1
GROUP BY id_shop, id_lang, link_rewrite
HAVING COUNT(DISTINCT id_product) > 1
ORDER BY distinct_products DESC, link_rewrite;

Powtórzony slug nie musi oznaczać kolizji na natywnych trasach opartych na ID. Przy rozwiązywaniu tras bez ID sprawdź pełną generowaną ścieżkę wśród produktów, kategorii, CMS, marek, dostawców i tras modułów. Dwa różne typy encji mogą zajmować tę samą ścieżkę, nawet jeśli żadna tabela nie ma wewnętrznych duplikatów.

Przetestuj wybraną politykę kolizji i dodawany sufiks. Menedżer czytelnych URL może dopisywać ID, licznik, indeks lub inny wyróżnik. Nigdy nie obiecuj, że każdy wynikowy URL będzie bez liczb.

Prowadź inwentarz tras każdego opublikowanego języka i sklepu. Sprawdź puste slugi, alternatywne kodowania, wielkość liter, sufiksy i końcowy ukośnik, prefiksy językowe i ewentualny podkatalog instalacji.

Uzgodnij kanoniczne URL, domeny i parametry

Wybierz jedną preferowaną nazwę hosta i wariant HTTPS. Gdy HTTPS działa z ważnym certyfikatem, sprawdź ustawienia PrestaShop „Włącz SSL” i „Włącz SSL na wszystkich stronach”, także dla żądań przez CDN lub proxy. Przetestuj łącznie warianty domeny bez www i z www oraz HTTP i HTTPS, również przez CDN. Użyj zaufanej, skonfigurowanej nazwy hosta jako celu przekierowania, aby uniknąć pętli lub niebezpiecznego wykorzystania niezaufanego nagłówka Host.

Ustaw natywne przekierowanie kanoniczne na trwałe tam, gdzie to właściwe, następnie testuj żądania produktów i kategorii. W PrestaShop 1.7.8 i 9 PS_CANONICAL_REDIRECT używa 0 dla braku przekierowania, 1 dla tymczasowego 302 i 2 dla stałego 301. Przekierowanie kanoniczne rdzenia dotyczy żądań GET, więc sprawdź rzeczywistą odpowiedź GET. Tag canonical jest sygnałem preferencji; nie uniemożliwia odwiedzającym otwarcia innego URL.

• Generuj linki wewnętrzne w preferowanym formacie.
• Używaj odpowiedniego canonical dla równoważnych wariantów z parametrami śledzenia.
• Sprawdzaj paginację i strony filtrowane według ich rzeczywistej treści i polityki indeksowania.
• Kieruj alternatywy językowe na ich własne poprawne, indeksowalne URL.
• Nie wskazuj wspólnego adresu kanonicznego dla rzeczywiście różnych stron tylko dlatego, że ich adresy wyglądają podobnie.

Nie stosuj ogólnej reguły usuwania ukośnika do plików, katalogów i tras bez sprawdzenia ich znaczenia. Parametry funkcjonalne mogą wybierać kombinację, filtr, język lub akcję sesji. Różnią się od zbędnego śledzenia kampanii.

Sprawdź źródło HTML, nagłówki odpowiedzi, linki wewnętrzne i wpisy mapy witryny pod kątem sprzecznych sygnałów. Zobacz wytyczne Google dotyczące kanonicznych URL.

Jeśli źródło zawiera konkurujące tagi canonical, ustal ich emitentów: motyw, moduł SEO lub własny kod. Uzgodnij, który komponent odpowiada za ten wynik, zamiast dodawać kolejny tag. Jeśli wynik zmienia się dopiero po wyczyszczeniu cache, przed oceną reguły sprawdź cache aplikacji i CDN. Porównaj dotknięty język i sklep z domyślną witryną; poprawna strona w języku domyślnym nie dowodzi poprawności pozostałych kontekstów.

Zbuduj mapę starych i końcowych URL

Zinwentaryzuj obecny katalog i konfigurację tras, przeskanuj dostępne strony, sprawdź mapy witryny i logi serwera oraz dodaj dane skuteczności i linków Search Console i znane linki zewnętrzne. Raport indeksowania Search Console podaje przykłady, a nie pełną listę każdego zindeksowanego URL; zobacz dokumentację raportu.

Zapisz stary URL, sklep i język, status, obecny canonical, istotny ruch i linki przychodzące, zamierzony końcowy URL i oczekiwaną odpowiedź. Niezmienione URL pozostaw bez zmian. Uwzględnij obrazy, pliki do pobrania i ważne strony modułów, jeśli są przenoszone.

Dodaj źródło dowodu i encję reprezentowaną przez każdy wiersz. Bieżące skanowanie nie odkryje historycznego adresu, do którego nie prowadzi link z żadnej obecnej strony, a logi obejmują tylko zachowany okres. Oznacz nieznane cele do sprawdzenia, zamiast bez śladu je pomijać. Nadaj priorytet wartościowym stronom wejścia i uszkodzonym linkom zakupowym, ale nie traktuj pustej kolumny ruchu jako dowodu, że adres jest nieużywany.

1. Najpierw skonfiguruj i przetestuj routing docelowy.
2. Mapuj zmienione strony bezpośrednio na odpowiadający im końcowy cel.
3. Sprawdź ważne wycofane strony pod kątem odpowiedniego zamiennika lub równoważnej strony zbiorczej.
4. Używaj 404 lub 410, gdy strona zniknęła i nie ma odpowiedniego odpowiednika.
5. Skieruj wcześniejsze łańcuchy przekierowań na końcowy URL.

Kategoria nadrzędna nie jest automatycznie równoważnym celem wycofanego produktu. Ogólne przekierowania na stronę główną lub kategorię mogą wprowadzać użytkowników w błąd i być traktowane jako pozorne 404. 410 nie gwarantuje szybszego usunięcia niż 404; zobacz wytyczne Google dotyczące usuniętych stron.

Używaj 301 lub 308 przy trwałych przeniesieniach i właściwego statusu tymczasowego przy zmianach tymczasowych. 302 nie wyklucza kategorycznie konsolidacji sygnałów; różni się intencją indeksowania. Stałe przekierowania same w sobie nie tracą PageRank przy każdym przejściu. Skracaj łańcuchy dla mniejszych opóźnień, wydajniejszego skanowania i mniejszej liczby punktów awarii. Zobacz wytyczne Google dotyczące przekierowań.

Sprawdź adresy docelowe na przykładach

Produkt ma stare ścieżki kategorii

Załóżmy, że audyt wykrył historyczne adresy /bags/42-blue-wallet.html i /sale/42-blue-wallet.html dla tego samego produktu, a jako końcową trasę zatwierdzasz /42-blue-wallet.html. Potwierdź tożsamość produktu, zanim skierujesz oba aliasy bezpośrednio na ten adres. Późniejsze usunięcie produktu z kategorii Wyprzedaż nie może kierować starego linku z tej kategorii do ogólnej listy wyprzedażowej.

Przetestuj zapisany link wybierający także kombinację produktu. Przejdź nim do strony produktu, dodaj towar do koszyka i sprawdź wynikowy rozmiar, cenę oraz stan magazynowy wybranego wariantu. Przekierowanie, które prowadzi do właściwego produktu, ale po cichu gubi kombinację wybraną przez klienta, nie przechodzi tego testu. Sprawdź ten sam proces z linku w pliku danych lub kampanii, zamiast testować tylko link właśnie wygenerowany przez sklep.

Produkt i strona treści chcą tego samego sluga

Załóżmy, że produkt bez ID i strona CMS chcą używać /summer-sale. Sprawdzenie samych slugów produktów nie ujawni konfliktu. Przed publikacją którejkolwiek zmiany zdecyduj, która encja zachowa adres, a drugiej nadaj osobną trasę. Zapisz to przypisanie w mapie; zmiana priorytetu przekierowań nie sprawi, że jeden adres będzie obsługiwał obie zamierzone strony.

Wdróż dokładne przekierowania Apache

Umieszczaj własne reguły poza generowanym blokiem przepisywania PrestaShop i przed nim. Zachowaj kopię konfiguracji, zweryfikuj serwer i testuj na środowisku testowym przed przeładowaniem produkcji. Używaj jednego świadomie wybranego mechanizmu przekierowań; mieszanie mod_alias i mod_rewrite może zaskakiwać kolejnością.

Te przykłady należą do pliku .htaccess w katalogu głównym sklepu dla instalacji w katalogu głównym domeny. Mapują dokładne stare ścieżki na sprawdzone natywne trasy końcowe w przykładowej domenie.

RewriteEngine On
RewriteRule ^old-wallet\.html$ https://www.example.com/42-blue-wallet.html [R=301,L]
RewriteRule ^old-category/$ https://www.example.com/3-wallets [R=301,L]

Kotwice zapewniają dokładność tych dopasowań ścieżek. RewriteRule w tym kontekście nie widzi początkowego ukośnika i dopasowuje ścieżkę bez argumentów zapytania. Reguły domyślnie zachowują istniejące argumenty. Używaj QSD tylko przy celowym odrzucaniu ich i po potwierdzeniu, że nie zawierają wymaganego stanu.

Dla sklepu w /shop/ dostosuj zarówno kontekst reguł, jak i ścieżki docelowe. Stare żądanie index.php?id_product=42&controller=product wymaga obsługi uwzględniającej parametry zapytania lub przetestowanego natywnego zachowania kanonicznego; reguła dopasowująca tylko ścieżkę index.php pasowałaby do wielu niepowiązanych stron.

Zwykła dyrektywa Redirect dopasowuje prefiks ścieżki i dopisuje niedopasowane informacje o ścieżce. Dla dokładnych map używaj zakotwiczonego RedirectMatch lub sprawdzonej zakotwiczonej reguły przepisywania. Zobacz dokumentację Apache Redirect.

Nie używaj ogólnej reguły „usuń prefiks liczbowy” lub „usuń .html”, dopóki nie wiadomo, że każda trasa docelowa działa. Takie reguły mogą wpływać na produkty, kategorie i niepowiązane endpointy oraz tworzyć łańcuchy przy uruchamianiu kolejno.

Wdróż mapę ścieżek w Nginx

Dla większej mapy opartej tylko na ścieżkach zdefiniuj map w kontekście http i użyj jej z właściwego bloku server. Przykład używa zakotwiczonych wyrażeń regularnych rozróżniających wielkość liter i celowo zachowuje argumenty zapytania.

# http context
map $uri $migration_target {
    default "";
    ~^/old-wallet[.]html$ /42-blue-wallet.html;
    ~^/old-category/$ /3-wallets;
}

# inside the intended server block
if ($migration_target != "") {
    return 301 https://www.example.com$migration_target$is_args$args;
}

$uri to znormalizowana bieżąca ścieżka bez parametrów; $request_uri zawiera pierwotny ciąg zapytania. Mapa z kluczami ścieżek dopasowywana do $request_uri nie objęłaby /old-wallet.html?utm_source=email. Wybierz dopasowanie całego żądania tylko wtedy, gdy samo zapytanie stanowi część zamierzonego klucza. Zobacz zmienne URI w Nginx.

Jeśli cel świadomie zastępuje lub usuwa parametry, odpowiednio zmień konstrukcję instrukcji return. Przetestuj znaki zapisane z użyciem sekwencji ucieczki i powtarzające się ukośniki względem zasad normalizacji. Umieść logikę tak, aby widziała właściwą ścieżkę, zanim inne wewnętrzne przepisywanie zmieni $uri.

Uruchom nginx -t, sprawdź wynik, przeładuj zamierzoną instancję i testuj reprezentatywne żądania. Przykładowe domeny i ścieżki opisują konkretną mapę; wygeneruj własną z zatwierdzonych celów zamiast kopiować przykład do innego sklepu.

Przenieś domeny i zachowaj trasy wielojęzyczne

Zmiana hostingu przy zachowaniu tej samej publicznej domeny i ścieżek pozwala zachować URL. Przed zmianą DNS przetestuj nowy serwer z docelową publiczną nazwą hosta i certyfikatem HTTPS. Zaplanuj, jak żądania nadal trafiające na stary serwer podczas propagacji DNS dotrą do aktywnego sklepu. Nowa domena lub katalog bazowy wymagają też aktualizacji konfiguracji URL w samym sklepie, gotowych certyfikatów i utrzymania routingu ze starych adresów na nowe.

1. Skopiuj spójne pliki i bazę do nowego środowiska oraz chroń kopię podczas testów.
2. Zaktualizuj URL zamierzonego sklepu przez obsługiwane ustawienia panelu. Sprawdź shop_url.domain, domain_ssl, physical_uri i ewentualny wirtualny URI multistore.
3. Sprawdź właściwe wartości PS_SHOP_DOMAIN i PS_SHOP_DOMAIN_SSL w odpowiednim kontekście.
4. Jeśli zmienia się dostęp do bazy, zaktualizuj app/config/parameters.php w nowszych wersjach. Ta ścieżka to nie config/parameters.php. Starszy 1.6 używa config/settings.inc.php.
5. Wyczyść lub odbuduj pamięci podręczne i wygeneruj właściwe reguły Apache albo wdróż dopasowane reguły Nginx.
6. Zainstaluj i przetestuj przekierowania każdej starej strony do jej końcowego odpowiednika. Utrzymuj działanie starej domeny i jej certyfikatu HTTPS.
7. Zaktualizuj callbacki płatności, zadania cron, linki pocztowe, feedy, analitykę i cele reklam.

Dla wielojęzycznych katalogów mapuj każdy język na odpowiadający mu język, zachowaj niezbędne rozróżnienie językowe i sprawdź canonical oraz wzajemne odwołania hreflang. Nie przekierowuj wszystkich języków na angielski.

Katalog z 5000 produktów i czterema językami może mieć około 20 000 par URL produkt-język przed aliasami, kategoriami i starą historią. Generuj inwentarz z rzeczywiście opublikowanych kombinacji zamiast zakładać, że każdy produkt ma każde tłumaczenie.

W kwestiach związanych z platformą i danymi podczas tej zmiany skorzystaj z poradnika migracji.

Używaj modułów URL i SEO do routingu i metadanych

SEO Revolution zapewnia zarządzanie przekierowaniami, przegląd błędów 404, obsługę łańcuchów stałych przekierowań, reguły canonical/hreflang i procesy map witryny; pomoc modułu opisuje konfigurację i obsługiwane dopasowania.

Smart SEO Friendly URL Manager zapewnia wzorce URL encji, polityki kolizji i historię przekierowań, w tym warunek, że stara ścieżka nie może należeć do obecnej trasy; użyj pomocy modułu do konfiguracji i współdziałania z SEO Revolution.

Product Canonical Manager zapewnia kontrolę canonical dla poszczególnych produktów; sprawdź pomoc modułu przed zmianą preferowanych celów.

Hreflang Tags Manager zapewnia zarządzanie alternatywami językowymi; pomoc modułu omawia konfigurację.

Testuj trasy modułów, dopasowanie dokładne i zapytań, reguły prefiksów, zakończenia łańcuchów, kwalifikację językową i pierwszeństwo obecnych tras na kopii. Moduł przekierowań nadal potrzebuje sprawdzonej mapy celów; nie może bezpiecznie wybrać semantycznego odpowiednika dla każdej brakującej strony.

Sprawdź uruchomienie i monitoruj wyniki

Zaktualizuj wewnętrzne odwołania do końcowych URL: nawigację, treści CMS i produktów, sprzedaż krzyżową, szablony e-mail, feedy i dane strukturalne. Przekierowania powinny przechwytywać stare odwołania zewnętrzne zamiast dodawać przejścia do każdego nowego linku wewnętrznego.

Generuj mapy witryny zawierające zamierzone indeksowalne kanoniczne URL zwracające poprawne odpowiedzi. Sprawdź wszystkie sklepy i języki. Usuń cele przekierowane, brakujące i noindex. Mapa witryny jest sygnałem odkrywania i kanonizacji, a nie gwarancją indeksowania; zobacz wytyczne Google dotyczące map witryny.

Testuj odpowiedź i końcową treść zwykłą przeglądarką oraz żądaniem z wiersza poleceń. Niektóre aplikacje obsługują HEAD inaczej, więc potwierdzaj też przez GET.

curl -sS -D - -o /dev/null 'https://www.example.com/old-wallet.html?utm_source=email'
curl -sS -L -o /dev/null -w '%{http_code} %{url_effective}\n' 'https://www.example.com/old-wallet.html'

• Zmienione URL: oczekiwany status stałego przekierowania, poprawne Location, brak pętli i końcowa strona 200 z odpowiadającą treścią.
• Niezmienione URL: bezpośrednie 200, poprawna treść i canonical.
• Usunięte strony: zamierzone 404/410, bez mylącej strony sukcesu.
• Warianty: host, protokół, sufiks, wielkość liter, kodowanie, argumenty, język i podkatalog instalacji.
• Kluczowe procesy: kombinacje, wyszukiwanie i filtry fasetowe, zamówienia, konto i callbacki płatności.

Zweryfikuj stare i nowe usługi Search Console, prześlij aktualną mapę witryny i użyj Zmiany adresu przy obsługiwanej zmianie domeny. Sprawdzaj raporty skanowania i indeksowania, logi, organiczny ruch stron wejścia i konwersję. Zachowuj stałe przekierowania migracyjne co najmniej rok i dłużej, dopóki korzystają z nich linki lub odwiedzający.

Zachowaj wyniki bazowe sprzed zmiany według strony wejścia, języka i sklepu oraz porównaj zmapowane cele z ich starymi odpowiednikami. Wyniki całego sklepu mogą ukryć niedziałający język lub brak ważnej kategorii. Oddziel awarię żądania od zmiany wyników wyszukiwania: pętla, niewłaściwy produkt lub zablokowany cel wymagają poprawki technicznej, a działający URL z mniejszą liczbą wizyt wymaga zbadania indeksowania, treści i popytu. Zapisz czas zmiany oraz równoległe kampanie lub zmiany katalogu, aby nie przypisać ich skutków niewłaściwej przyczynie.

Czas przetwarzania i wyniki wyszukiwania różnią się. Przekierowania nie gwarantują odzyskania wyników ani nie rekompensują utraty treści, ograniczeń indeksowania lub zmienionej konkurencji. Zobacz wytyczne Google dotyczące przenoszenia witryn.

O co zapytać programistę lub agencję

Poproś o dokumentację przekazania przydatną przy kolejnym imporcie, zmianie nazwy lub aktualizacji modułu.

• Który komponent odpowiada za przekierowania hosta, routing stron, historyczne przekierowania, adresy kanoniczne i hreflang oraz w jakiej kolejności działają?
• Które wiersze mapy pozostają nierozstrzygnięte, kto zatwierdza ich cele i gdzie są wyniki żądań oraz kontrole stron końcowych?
• Czy import katalogu może nadpisać ręczne slugi lub stworzyć nowe kolizje i kto sprawdza wynik?
• Które linki motywu, pliki danych, powiadomienia zwrotne i zaplanowane zadania przetestowano z docelową domeną produkcyjną i językami?
• Kto może przywrócić poprzednią konfigurację, co uruchamia tę decyzję i jak zostaną zachowane nowe zamówienia oraz zmiany zapasów?
• Kto odpowiada za monitorowanie i przychodzące zgłoszenia uszkodzonych linków po przekazaniu projektu?

Pytania właścicieli sklepów

Czy możemy odtworzyć kopię bazy, aby cofnąć zmianę URL?

Nie nadpisuj nowych zamówień, zmian klientów ani ruchów zapasów bazą sprzed uruchomienia. Zaplanuj odzyskiwanie wokół konfiguracji routingu, mapy przekierowań i konkretnych zmian danych. Przeglądarki i pośrednicy mogą zapamiętywać stałe przekierowania, więc przetestuj odzyskiwanie dla odwiedzających nadal podążających do opublikowanych nowych celów. Utrzymaj dostępność tych celów podczas odzyskiwania. Jeśli wycofanie wymaga naprawy danych, programista musi uzgodnić zapisy powstałe od uruchomienia, zamiast ślepo odtwarzać cały sklep.

Czy możemy użyć adresu wycofanego produktu dla innego produktu?

Przed zatwierdzeniem sprawdź historyczne użycie. Stare zakładki, kampanie i linki zwrotne otwierałyby teraz nowy produkt, a historyczne przekierowanie może przestać działać, jeśli bieżąca trasa przejmie ścieżkę. Zachowaj osobny adres, gdy produkty nie odpowiadają na tę samą potrzebę; zarezerwuj ważne aliasy w inwentarzu tras, aby import nie mógł ich przypadkowo użyć ponownie.

Czy zmiana domeny musi wstrzymać zamówienia?

Próba przekierowań tego nie rozstrzyga. Jeśli przenosisz też bazę danych, uzgodnij, które środowisko przyjmuje zapisy, jak działa końcowa synchronizacja danych i czy trzeba wstrzymać realizację zamówień. Zamówienia, powiadomienia o płatnościach i aktualizacje zapasów nie mogą rozdzielić się między niezależne kopie podczas przełączenia.

Kto utrzymuje mapę po uruchomieniu?

Wyznacz konkretną osobę odpowiedzialną za zatwierdzone cele i uzasadnienie każdej zmiany. Przechowuj konfigurację przekierowań z dokumentacją wdrożeń i przeglądaj ją po importach katalogu lub aktualizacjach routingu. Uwzględniaj zgłoszenia brakujących stron od obsługi klienta: uszkodzony link zakupowy może być istotny nawet przy małym ruchu z wyszukiwarek.