Migracja sklepu to jeden z tych projektów, w których łatwo pomylić start nowej wersji z prawdziwym sukcesem biznesowym. I to nie jest frazes. W praktyce chodzi nie tylko o zmianę platformy, szablonu czy domeny, lecz o utrzymanie sprzedaży, widoczności w Google i poprawnego pomiaru danych. Najwięcej kłopotów zwykle nie leży w samym designie, tylko w adresach URL, indeksacji, koszyku, checkoutcie, feedach i analityce. Sama publikacja nowego sklepu nie jest celem — celem jest utrzymanie ciągłości ruchu, konwersji i sygnałów SEO. Dobrze przeprowadzona migracja opiera się na inwentaryzacji starego sklepu, testach na środowisku stagingowym oraz kontroli po starcie. Jeśli któryś z tych elementów wypadnie z planu, spadki rzadko biorą się z pecha, a częściej z błędów wdrożeniowych.
Czym jest migracja sklepu i jakie są jej cele?
Migracja sklepu to kontrolowane przeniesienie sklepu internetowego między platformami, wersjami systemu, motywami, domenami, subdomenami albo strukturami adresów URL. Brzmi technicznie, bo takie jest. Taki projekt obejmuje nie tylko wygląd serwisu, ale też katalog produktów, kategorie, filtry, treści, blog, koszyk, checkout, integracje płatności, dostaw oraz narzędzia marketingowe. W praktyce to operacja na żywym organizmie, który ma nadal sprzedawać i jednocześnie nie zniknąć z wyszukiwarki.
Głównym celem migracji nie jest samo „przeniesienie sklepu”, tylko utrzymanie ciągłości działania. Kluczowe jest to, by użytkownik dalej trafiał na właściwe strony, robot Google mógł poprawnie indeksować nową wersję, a kampanie reklamowe i feedy produktowe nie stanęły z dnia na dzień. Pytanie brzmi, co się dzieje, gdy ten łańcuch pęka. Jeśli po migracji nie działa koszyk, pomiar transakcji albo mapowanie starych adresów, to nawet dobry nowy sklep zaczyna tracić pieniądze od pierwszych godzin.
Od strony SEO najważniejsze jest zachowanie sygnałów, które stary sklep już wypracował. Dane mówią jasno, że najczęściej chodzi o podstawy, a nie o „magiczne” triki. Dotyczy to przede wszystkim adresów URL, przekierowań 301, treści kategorii i produktów, meta danych, linkowania wewnętrznego, canonicali, danych strukturalnych oraz plików robots.txt i sitemap.xml. Samo przekierowanie adresów nie wystarcza, jeśli równocześnie zmienia się treść stron, ich intencja lub sposób renderowania. Problem w tym, że takie zmiany potrafią wyglądać niewinnie, a w indeksie robią zamieszanie.
Od strony sprzedaży i analityki cele są równie konkretne. Nie ma tu miejsca na „jakoś to będzie”. Sklep po migracji powinien poprawnie pokazywać ceny, stany magazynowe, warianty, metody dostawy, płatności i komunikaty transakcyjne, a narzędzia takie jak GA4, GTM, piksele reklamowe czy Merchant Center muszą dalej zbierać spójne dane. Ale uwaga, to nie kończy się na odpaleniu nowego frontu. Dobrze wykonana migracja kończy się nie tylko nowym wdrożeniem, ale też kompletem materiałów roboczych: audytem stanu obecnego, mapą przekierowań, checklistą testów, planem uruchomienia i planem awaryjnym.
Jakie są kluczowe etapy procesu migracji sklepu?
Etapy migracji sklepu są proste na papierze. Najpierw robisz inwentaryzację starego serwisu, potem projektujesz nową architekturę, przygotowujesz przekierowania, testujesz na stagingu, uruchamiasz bezpiecznie i po starcie trzymasz rękę na pulsie w monitoringu. Ta kolejność nie jest dekoracją, tylko szkieletem procesu, bo każdy następny krok stoi na decyzjach i danych z poprzedniego. Gdy zespół startuje od wdrożenia, a dopiero później próbuje „odtwarzać” stare adresy, metadane i logikę kategorii, zwykle kończy się to dziurami, których nie da się szybko połatać.
- Inwentaryzacja starego sklepu: crawl wszystkich ważnych adresów, eksport danych z Search Console, GA4, systemu sklepowego i feedów produktowych.
- Analiza zasobów krytycznych: wskazanie stron, których nie wolno usunąć ani scalić bez decyzji biznesowej, bo generują ruch, przychód lub linki.
- Projekt nowej architektury: porównanie kategorii, filtrów, wariantów, paginacji, breadcrumbs, wyszukiwarki i szablonów.
- Mapa przekierowań 301: przypisanie każdego ważnego starego URL do jednego logicznego adresu docelowego, bez łańcuchów i bez soft 404.
- Migracja treści i meta danych: przeniesienie title, H1, opisów, treści produktowych, FAQ, altów i linkowania wewnętrznego.
- Wdrożenie na stagingu: kontrola kodów odpowiedzi, indeksowalności, canonicali, hreflangów, robots.txt, sitemap.xml i wydajności.
- Walidacja renderowania: sprawdzenie, czy treści, listingi i menu są widoczne dla robotów także przy renderowaniu JavaScript.
- Wdrożenie analityki i integracji: test dataLayer, GA4, GTM, checkoutu, pikseli reklamowych, feedów i Merchant Center.
- Pre-launch QA i uruchomienie: przejście checklisty, publikacja według planu oraz zamrożenie ryzykownych zmian na czas startu.
- Kontrola po starcie i monitoring stabilizacji: śledzenie 200, 301, 404, 5xx, błędów indeksacji, ruchu, przychodu i jakości feedów.
Najważniejsze dzieje się na początku. To wtedy powstaje lista rzeczy, których nie wolno zgubić, bo bez niej migracja jest jak przeprowadzka bez spisu pudeł. Trzeba rozróżnić, które kategorie, produkty, poradniki i landing pages realnie „ciągną” ruch i sprzedaż, zamiast udawać, że każdy adres waży tyle samo. Najczęstsza przyczyna spadków po migracji to nie jeden spektakularny błąd, lecz seria drobnych strat: zniknięte strony z ruchem, podmienione treści kategorii, źle ustawione canonicale i brak pełnej mapy 301.
Środek procesu rozstrzyga, czy nowy sklep zachowa sens starego serwisu w oczach Google i użytkownika. Kluczowe są szablony kategorii, obsługa filtrów, paginacja, dane strukturalne Product i Offer, a także to, czy listingi i nawigacja nie „wyparują” przy renderowaniu JavaScript. Przy sklepach z rozbudowanymi filtrami albo dynamicznym ładowaniem treści trzeba sprawdzić nie tylko to, jak strona wygląda, lecz także to, co faktycznie widzi crawler. Bo właśnie tam najczęściej rodzą się ciche problemy, które wychodzą dopiero po starcie.
Etap analityczny i integracyjny bywa regularnie niedoszacowany. A bez niego trudno uczciwie ocenić, czy migracja faktycznie się udała. Trzeba osobno przetestować page_view, view_item, add_to_cart, begin_checkout i purchase, a do tego źródła transakcji, cross-domain, checkout zewnętrzny oraz przekazywanie danych do systemów reklamowych. W sklepach zależnych od kampanii produktowych dochodzi jeszcze pilnowanie zgodności identyfikatorów produktów, cen, dostępności i adresów landing pages.
Po uruchomieniu praca się nie kończy. Ona po prostu przechodzi z trybu wdrożeniowego w tryb kontrolny. W pierwszych godzinach sprawdzasz statusy odpowiedzi, robots.txt, sitemap.xml, przekierowania i działanie koszyka, a w kolejnych dniach analizujesz indeksację, logi serwera, ruch organiczny per katalog i błędy w feedach. Brak monitoringu po starcie to częsty powód, przez który naprawialne błędy wiszą zbyt długo i zaczynają realnie obniżać widoczność oraz sprzedaż.
Jakie ryzyka i ograniczenia należy uwzględnić podczas migracji sklepu?
Podczas migracji sklepu trzeba uwzględnić ryzyka SEO, sprzedażowe, analityczne i operacyjne. I to nie jest akademicka wyliczanka, bo każdy z tych obszarów potrafi samodzielnie uciąć ruch albo przychód. Najczęstszy błąd polega na założeniu, że skoro nowy sklep działa wizualnie, to migracja jest „zrobiona”. W praktyce problemy zaczynają się wtedy, gdy znikają stare adresy, zmienia się struktura kategorii albo robot Google widzi inną wersję treści niż użytkownik. Największe spadki po migracji zwykle nie wynikają z jednej awarii, tylko z kilku drobnych błędów, które nakładają się na siebie jednocześnie.
Po stronie SEO największym ryzykiem jest utrata ważnych URL-i. Zaraz potem wchodzą błędne przekierowania 301, masowe 404, złe canonicale i przypadkowe blokady indeksacji. Samo przekierowanie adresów nie wystarczy, jeśli zmienisz treść kategorii, usuniesz linkowanie wewnętrzne albo rozbijesz dawną intencję wyszukiwania na kilka słabszych stron. Przy sklepach opartych o JavaScript trzeba też sprawdzić renderowanie list produktów, filtrów, menu i treści ładowanych dynamicznie.
Po stronie sprzedaży ryzyko dotyczy koszyka, checkoutu, płatności, dostaw, rabatów i stanów magazynowych. Tu nie potrzeba katastrofy, wystarczy drobiazg. Nawet niewielki błąd w tych miejscach potrafi obniżyć konwersję szybciej niż spadek pozycji w Google. Jeśli migracja zmienia platformę i checkout jednocześnie, trzeba testować cały proces zakupu od karty produktu do potwierdzenia transakcji, a nie tylko pojedyncze podstrony.
Osobnym obszarem jest analityka i reklama. Na styku GA4, GTM, consent mode, zewnętrznych bramek płatniczych i subdomen zaskakująco łatwo zgubić źródło transakcji albo przerwać ścieżkę eventów e-commerce. Problem w tym, że kampanie mogą dalej wydawać budżet, ale raporty zaczną pokazywać zaniżoną sprzedaż lub błędne atrybucje.
W sklepach opartych o Google Merchant Center szybko pojawiają się ograniczenia związane z feedem produktowym. Wystarczy ruszyć identyfikatory produktów, adresy landing pages, ceny, dostępność albo znaczniki schema.org, by kampanie produktowe i bezpłatne wyniki produktowe zaczęły się rozjeżdżać. I problemem nie jest wyłącznie sam feed. Kluczowe jest, czy dane w sklepie, feedzie i na stronie docelowej są ze sobą naprawdę spójne.
Ryzyko rośnie, gdy dochodzą kolejne języki, waluty, rynki i subfoldery. Wtedy dochodzi pilnowanie hreflangów, kanoniczności między wersjami językowymi oraz tego, czy tłumaczenia i architektura nowego sklepu trzymają się starej logiki kategorii. Co się dzieje, gdy wszystko zmieniasz naraz. Im więcej zmian robisz jednocześnie, tym trudniej ustalić przyczynę spadku, dlatego migracja powinna rozdzielać decyzje techniczne, contentowe i UX-owe tam, gdzie to możliwe.
Trzeba też przyjąć do wiadomości ograniczenia projektu. Nie każda platforma daje wygodną kontrolę nad URL-ami, meta danymi, robots.txt, danymi strukturalnymi czy logiką filtrów, a nie każdy zespół potrafi wyciągnąć pełne dane źródłowe ze starego sklepu. I tu zaczynają się schody. Jeśli brakuje kompletnej listy dawnych adresów, historii ruchu oraz informacji o stronach, które generowały przychód, mapa przekierowań będzie dziurawa już na wejściu.
Ostatnie ryzyko pojawia się po publikacji. Część błędów wychodzi dopiero, gdy wchodzą boty, startują kampanie i spływają pierwsze realne zakupy, więc bez monitoringu nie ma mowy o szybkiej reakcji. Tu nie wygrywa się intuicją. Migracja bez planu rollbacku i bez kontroli pierwszych dni po starcie jest bardziej wdrożeniem “w ciemno” niż kontrolowanym procesem.
Jakie narzędzia i techniki są niezbędne do skutecznej migracji?
Do migracji, która ma się udać, potrzebujesz narzędzi do inwentaryzacji URL-i, testów technicznych, walidacji analityki i monitoringu po starcie. Ich rola nie polega na „robieniu SEO”, tylko na wyłapaniu tego, co może uciąć ruch, sprzedaż albo pomiar. To robi różnicę. Bez takiego zestawu jedziesz na domysłach zamiast na danych.
Podstawą jest crawler techniczny. Zbiera adresy, statusy odpowiedzi, meta dane, nagłówki, canonicale, linki wewnętrzne i elementy indeksacji ze starego oraz nowego sklepu, dzięki czemu widać, co faktycznie się zmieniło. Do tego dochodzi Google Search Console, bo pokazuje adresy realnie indeksowane, zapytania i problemy z pokryciem indeksu. Fakty są takie, że najpierw musisz mieć porządną bazę. Najpierw trzeba zbudować pełną listę starych URL-i i ustalić ich priorytet według ruchu, przychodu, linków i roli w ścieżce zakupowej.
Dane o biznesowej wartości adresów najlepiej spinać z GA4, systemu sklepowego i logów serwera. GA4 pokaże landing pages, ścieżki zakupowe i przychód, a logi ujawnią, które sekcje faktycznie odwiedzają roboty wyszukiwarek. To nie jest akademicka zabawa w raporty. Nie każdy indeksowany adres jest równie ważny, a nie każdy błąd ma ten sam koszt biznesowy.
Kluczową techniką pozostaje mapowanie 301 w arkuszu roboczym albo w dedykowanym dokumencie wdrożeniowym. Prosta zasada. Każdy ważny stary adres powinien dostać jedno, logiczne miejsce docelowe, a nie ogólne przekierowanie na stronę główną czy najwyższą kategorię. Dobrze przygotowana mapa przekierowań rozdziela to jasno: osobno produkty, kategorie, strony CMS, blog, marki, a do tego reguły obsługi parametrów i adresów archiwalnych.
Drugim filarem jest środowisko stagingowe możliwie bliskie produkcji. Bez niego błądzisz po omacku. Na nim weryfikuje się statusy HTTP, robots.txt, sitemap.xml, canonicale, hreflangi, noindex, paginację, breadcrumbs, działanie filtrów, wersję mobilną i wydajność kluczowych szablonów. Staging ma sens tylko wtedy, gdy odwzorowuje rzeczywistą logikę sklepu, a nie sam wygląd frontu.
Przy sklepach z dynamicznym frontendem dochodzą testy renderowania. I to nie jest kosmetyka. Trzeba potwierdzić, że bot widzi treść kategorii, listing produktów, linki w menu, elementy nawigacyjne i zasoby JS/CSS, a lazy loading nie chowa tego, co ma zarabiać. W praktyce sprowadza się to do porównania kodu źródłowego, renderu po załadowaniu oraz efektu w narzędziach do inspekcji adresów i crawlu renderowanego JavaScriptem.
Osobny zestaw dotyczy analityki. Tu potrafi zaboleć najbardziej. Potrzebne są podgląd GTM, walidacja dataLayer, testy eventów GA4 i kontrola cross-domain, jeśli checkout działa na innej domenie lub subdomenie. Trzeba ręcznie przejść zdarzenia page_view, view_item, add_to_cart, begin_checkout i purchase oraz sprawdzić, czy atrybucja źródła nie urywa się po płatności. Bo co z tego, że ruch się zgadza, jeśli sprzedaż „znika” po drodze.
Dla kampanii produktowych niezbędna jest walidacja feedu i danych strukturalnych. Pytanie brzmi: czy wszystkie systemy mówią o tym samym produkcie. Trzeba sprawdzić zgodność identyfikatorów produktów, cen, dostępności, adresów stron docelowych i znaczników Product oraz Offer. Jeśli produkt w feedzie, sklepie i analityce ma różne identyfikatory lub różne URL-e, problemy pojawią się jednocześnie w reklamach, raportach i Merchant Center.
Po publikacji najważniejsze są techniki monitoringu. To etap, na którym wychodzi prawda. Obejmują kontrolę błędów 404 i 5xx, sprawdzenie przekierowań, analizę nowych map witryny w Search Console, obserwację logów, monitorowanie feedów oraz przegląd ruchu i przychodu na poziomie katalogów i landing pages. Pierwsze godziny po starcie służą do wychwycenia błędów krytycznych, a kolejne dni do oceny, czy Google i użytkownicy faktycznie przechodzą na nową architekturę bez utraty ciągłości.
Jakie są krytyczne elementy SEO i analityki podczas migracji?
Krytyczne są te elementy, które decydują, czy Google i systemy pomiarowe zobaczą nowy sklep tak samo poprawnie jak stary. Fakty są takie: najważniejsze są adresy URL, treść stron docelowych, reguły indeksacji, linkowanie wewnętrzne oraz pełny pomiar ścieżki zakupowej. Jeśli któryś z tych obszarów zostanie uszkodzony, spadek obejmie nie tylko widoczność, lecz także realny przychód. Sama poprawna migracja techniczna nie wystarcza, jeśli znikną strony generujące ruch i sprzedaż.
W SEO punkt krytyczny jest jeden: mapa przekierowań 301. Każdy ważny stary adres ma prowadzić do jednego nowego, sensownego odpowiednika, nie do strony głównej, przypadkowej kategorii czy wyniku wyszukiwania. Najwięcej ważą zwykle top kategorie, produkty evergreen, strony marek, poradniki i landing pages kampanii. I właśnie one wymagają ręcznej kontroli, zamiast hurtowych reguł klepanych „na skróty”.
Druga sprawa to intencja i treść strony. Jeśli dawna kategoria rankowała na konkretne zapytania, nowa wersja musi dowozić tę samą odpowiedź na potrzebę użytkownika, nawet gdy zmienił się design albo układ modułów. Zmiana treści kategorii bez analizy często szkodzi bardziej niż sama zmiana platformy. To dotyczy nie tylko tekstu, lecz także H1, title, opisów, FAQ, treści pod długi ogon oraz linków wewnętrznych, które do tych stron prowadzą.
Trzeci obszar to indeksowalność i sygnały techniczne. Należy przejrzeć canonicale, robots.txt, noindex, sitemap.xml, paginację, hreflang i sprawdzić, czy menu, listingi oraz treść są widoczne dla robotów po renderowaniu. W sklepach opartych na JavaScript klasyczny problem wygląda tak: użytkownik widzi produkty, ale crawler nie widzi pełnej treści albo linków do kolejnych podstron. Efekt jest prosty. Ogranicza to odkrywanie adresów i osłabia linkowanie wewnętrzne.
W e-commerce równie ważna jest spójność danych produktowych. Identyfikatory produktów, ceny, dostępność, warianty i adresy landing pages powinny pozostać stabilne tam, gdzie to możliwe, bo jednocześnie pracują na SEO, feedy produktowe i kampanie reklamowe. Jeśli po migracji zmienią się identyfikatory albo struktura wariantów bez nadzoru, dane potrafią się rozjechać w Merchant Center, remarketingu i raportach sprzedaży. Przy sklepach zależnych od kampanii produktowych trzeba osobno sprawdzić feed, schema.org Product i Offer oraz zgodność cen i stanów magazynowych.
W analityce krytyczne jest odtworzenie całego lejka, nie tylko odsłon. Trzeba zweryfikować page_view, view_item, add_to_cart, begin_checkout i purchase, a potem zestawić, czy liczba zdarzeń oraz relacje między nimi trzymają się logiki. Gdy działa tylko purchase, a wcześniejsza część lejka milczy, znika możliwość diagnozy, w którym miejscu sklep zaczyna gubić użytkowników. To nie detal. To ślepa plamka w decyzjach.
Najwięcej błędów wychodzi na styku GA4, GTM, consent mode, zewnętrznego checkoutu i bramek płatniczych. W praktyce trzeba dopilnować, czy źródło wizyty przechodzi przez całą ścieżkę, czy sesja nie urywa się między domenami oraz czy transakcja trafia do właściwego kanału. Jeśli po migracji nie działa cross-domain albo zakup kończy się poza główną domeną bez poprawnej konfiguracji, raport sprzedaży będzie mylący nawet wtedy, gdy sklep realnie sprzedaje. A wtedy problemem nie jest marketing. Problemem jest pomiar.
Na koniec pilnuj spójności między SEO, reklamami i analityką. To nie detal. Ta sama strona produktu musi mieć poprawny URL, prawidłowy canonical, zgodny identyfikator w feedzie, właściwe dane strukturalne i poprawnie raportowaną sprzedaż. Kiedy te warstwy rozjeżdżają się choćby odrobinę, zaczynają się kłopoty z indeksacją, odrzuceniami w Merchant Center, błędną atrybucją i nerwową diagnozą spadków.
Jak monitorować i kontrolować wyniki po migracji sklepu?
Po migracji kontroluj codziennie indeksację, błędy techniczne, ruch i sprzedaż, bo większość problemów wychodzi dopiero po starcie. Pierwsze godziny służą do potwierdzenia, że sklep działa, ale to pierwsze dni pokazują, czy Google, użytkownicy i systemy reklamowe naprawdę przechodzą przez nową wersję bez strat. Monitoring zaplanuj jeszcze przed publikacją, nie dopiero wtedy, gdy na wykresach pojawią się spadki. Najgroźniejsze są nie duże awarie, ale małe błędy powielone na setkach lub tysiącach adresów.
Najpierw idą na stół statusy odpowiedzi i indeksacja. Trzeba potwierdzić, że priorytetowe adresy zwracają 200, stare URL-e przekierowują przez 301 do właściwych stron, a na produkcji nie wylądował przypadkowy noindex ani blokada w robots.txt. Równolegle sensownie jest od razu zgłosić nowe mapy witryny w Google Search Console i sprawdzić, czy Googlebot bez przeszkód pobiera kluczowe zasoby.
Drugi obszar to błędy techniczne, które uderzają w SEO i sprzedaż jednocześnie. To już nie teoria. Należy monitorować 404, 5xx, błędne canonicale, puste listingi kategorii, niedziałające filtry, problemy z paginacją i wolne szablony mobilne. Jeśli sklep korzysta z renderowania JS, warto dodatkowo sprawdzać, czy po wdrożeniu treść i linki są nadal widoczne dla crawlera, a lazy loading nie chowa produktów lub obrazów.
Trzeci obszar to pomiar ruchu i przychodu. I tu łatwo o fałszywy trop. Sam spadek sesji nie mówi jeszcze, czy problem dotyczy SEO, reklam, atrybucji czy samego sklepu, dlatego dane trzeba rozbijać per katalog, landing page i kanał. Najpraktyczniej porównywać nie tylko łączny ruch, ale też przychód z kategorii topowych, liczbę transakcji, współczynnik dodania do koszyka i przejścia do checkoutu. Jeśli ruch wygląda stabilnie, a spada begin_checkout albo purchase, problem zwykle leży w koszyku, checkoutcie lub analityce, nie w SEO.
Warto też trzymać rękę na pulsie w raportach Google Search Console i w logach serwera. Co mówią dane. GSC pokaże, czy rośnie liczba błędów indeksacji, czy zmieniają się kliknięcia i wyświetlenia na ważnych sekcjach oraz które nowe adresy są odkrywane. Logi pomagają ocenić, czy boty wpadają w przekierowania, 404 albo ślepe miejsca architektury, których nie widać od razu w zwykłym raporcie ruchu.
Po migracji sklepu nie ma „świętego spokoju” w reklamach i feedach. Trzeba szybko prześwietlić Google Merchant Center: stan konta, błędy danych produktowych, zgodność cen i dostępności oraz to, czy kampanie faktycznie dowożą ruch na właściwe adresy docelowe. I tu zaczynają się schody. SEO potrafi wyglądać wzorowo, a sprzedaż i tak leci w dół przez odrzucone produkty w feedzie, rozjazd identyfikatorów albo źle podpięte landing pages w kampaniach produktowych.
Monitoring bez progów alarmowych to tylko ładny wykres. Kluczowe jest, by miał właściciela po stronie zespołu i jasne zasady, co uznajemy za odchylenie, a co za pożar. W praktyce oznacza to konkretną listę wskaźników do codziennego przeglądu przez pierwsze dni i tygodnie: błędy 404 i 5xx, liczbę zaindeksowanych stron, ruch organiczny na top katalogach, przychód z najważniejszych landing pages, poprawność eventów zakupowych oraz błędy feedów. Pytanie brzmi: kto reaguje i w jakim czasie. Bez ustalonego planu reakcji nawet poprawnie zebrane dane nie pomogą, bo zespół zbyt późno odróżni zwykłą fluktuację od realnej awarii.
Kontrola wyników ma prowadzić do decyzji, a nie do kolejnej rundy „zobaczymy jutro”. Co poprawić od razu, a co tylko trzymać pod obserwacją. Krytyczne błędy, takie jak masowe 404, brak purchase, problemy z płatnościami czy zablokowana indeksacja, wymagają natychmiastowej poprawki albo uruchomienia planu rollbacku. Mniejsze wahania pozycji czy częściowe przetasowania ruchu są normalne. Ale uwaga: tylko wtedy, gdy równolegle nie siada dostępność sklepu, liczba transakcji i skuteczność najważniejszych stron wejścia.
