2

Migracje, czyli komplikacje – jak przenieść sklep na nową platformę?

Tytuł tego wpisu nie jest przypadkowy – chodzi o to, że źle przeprowadzona migracja, zwłaszcza w przypadku sklepów internetowych, może zakończyć się bardzo poważnymi problemami, a an w najgorszym razie, doprowadzić do bankructwa.

Wszystkie opisane poniżej problemy, sugestie i rekomendacje bazują na naszych osobistych doświadczeniach, zaczerpniętych z projektów, przy których uczestniczyliśmy, często dołączając w trybie awaryjnym, gdy problemy już się pojawiły i trzeba było ratować sytuację.

Mamy nadzieję, że poniższy opis pomoże wielu osobom uniknąć podobnych kłopotów. Pamiętajcie jednak, że fachowe przeprowadzenie migracji nie jest łatwym zadaniem, więc jeśli macie wątpliwości lub obawy, a stoicie przed takim wyzwaniem, zapraszamy do kontaktu.

1 Grzech śmiertelny – zmiana adresów i brak przekierowań

Jest to problem nr 1 w projektach migracyjnych, do których dołączamy.

Scenariusz zwykle wygląda tak – agencja, freelancer lub inna firma przekonują właściciela sklepu, że jego obecna platforma jest przestarzała i warto ją unowocześnić. Czasami sam właściciel zaczyna odczuwać taką potrzebę.

[info]Zapada decyzja, powstaje nowy sklep, często na nowej platformie.[/info]

Zwykle oznacza to zmianę adresów, ale na to nikt nie zwraca uwagi, w pocie czoła szlifując wygląd, migrując produkty, konfigurując ustawienia.

Potem premiera nowej wersji, nerwowe oczekiwanie, a po kilku dniach ruch z Google drastycznie spada. I zaczyna się panika.

Zastanówmy się zatem, jak ten proces powinien wyglądać prawidłowo. Szczegółowy opis będzie przedmiotem oddzielnego wpisu, ale poniżej kilka wskazówek.

Jeśli stoją Państwo przed migracją swojego serwisu, zwłaszcza sklepu internetowego, na nową platformę, zachęcamy do skorzystania z naszej pomocy. Gdy wypełnią Państwo poniższy formularz, nasz specjalista skontaktuje się z Państwem maksymalnie w ciągu 1 dnia roboczego.

Przede wszystkim, przekierowania należy zaplanować na etapie prac programistycznych nad nową wersją sklepu, a nie po jej uruchomieniu!

Po drugie, należy stworzyć listę stron, które muszą być obsłużone przekierowaniami.

Zwykle są to:

  • strona główna (czasami strona główna to nie sama domena, ale np. mojsklep.pl/pl/)
  • strony kategorii
  • strony produktów
  • główne kombinacje stron kategorii i filtrów

Bardzo dobrym pomysłem jest analiza danych w Google Analytics (strony docelowe z ruchu organicznego) i Narzędzi Google dla Webmasterów (to samo, strony docelowe).

Warto też wykonać pełen crawl starej wersji serwisu, korzystając z jednego z kilku dostępnych narzędzi. My w swoich działaniach posługujemy się aplikacją ScreamingFrog, która jest najlepszym narzędziem na rynku, ale wystarczy też bezpłatny Xenu?s Link Sleuth. Wyniki crawla zapisujemy – będą niezbędne w kolejnym kroku.

Screaming Frog w działaniu

Screaming Frog w działaniu

Linki zebrane z poszczególnych źródeł łączymy (przy czym niekoniecznie idealnym pomysłem będzie uwzględnienie wszystkich linków z crawla – część z nich nie powinna mieć przekierowań) i usuwamy duplikaty.

Następnie oceniamy, jakie metody obsłużenia przekierowań wchodzą w grę.

Niezależnie od techniki, zawsze powinno to być przekierowanie 301, czyli stałe.

  1. Najlepiej, gdy jesteśmy w stanie obsłużyć to na poziomie aplikacji. Aplikacja, gdy otrzymuje wywołanie adresu, który nie jest częścią nowego systemu, analizuje URL i próbuje dopasować do aktualnej struktury. Jeśli stare adresy miały unikalne, jednoznaczne identyfikatory, np. liczbowe, wówczas takie przepisanie jest dość proste.
  2. Jeżeli przepisanie na poziomie aplikacji nie jest możliwe, kolejną opcją powinna być próba obsłużenia przekierowań z poziomu pliku .htaccess. Także w tym wypadku, jeśli struktura adresów była zaplanowana logicznie, to często udaje się obsłużyć przekierowania tysięcy adresów jedną, dobrze przemyślaną formułą z użyciem wyrażeń regularnych.
  3. W innych wypadkach, niezbędne jest dopasowywanie adresów 1:1. Jest to, żmudna praca, która zwykle wcześniej wymaga starannej obróbki adresów, np. w Excelu.
  4. Jeżeli adresów do przekierowań jest bardzo dużo, warto sięgnąć po bardziej zaawansowane rozwiązania, jakie oferuje Apache, np. RewriteMap.

Zakładając, że zadbaliśmy o przekierowania, i tak warto zabezpieczyć się przed ewentualnymi kłopotami, wykonując kilka dodatkowych kroków.

  1. Regularnie sprawdzamy Narzędzia Google dla Webmasterów, monitorując je pod kątem wzrostu liczby adresów zwracających kod błędu 404 (nie znaleziono). Jeżeli błędy wynikają z naszego przeoczenia – poprawiamy.
  2. Także w narzędziach Google przestawiamy tempo indeksacji serwisu na maksymalne, aby Google jak najszybciej poznało nowe adresy.
  3. Upewniamy się, że do Google zgłoszona jest najnowsza wersja sitemapy, a sitemapy z poprzedniego serwisu zostały usunięte. Obserwujemy poziom indeksacji adresów zgłoszonych przez sitemapę.
  4. Jeżeli jest taka możliwość, w aplikacji instalujemy moduł, który na bieżąco monitoruje błędy 404 i raportuje je w panelu. W ten sposób dowiemy się o problemach szybciej niż z narzędzi Google, które mają kilkudniowe opóźnienie.
  5. Wczytujemy zapisany wcześniej crawl serwisu i uruchamiamy ponowne sprawdzenie tylko zapisanych wcześniej linków. W przypadku tych, które po migracji zwracają kod 404, analizujemy, czy powinny być przekierowania.
  6. Pobieramy linki zewnętrzne, przychodzące do serwisu (dostępne w narzędziach Google, ale także w komercyjnych serwisach, takich jak ahrefs czy MajesticSEO), tworzymy jedną listę bez duplikatów i uruchamiamy sprawdzenie. Linki, które trafiają na strony z kodami 404, pokazują nam, które strony powinniśmy dodatkowo przekierować.

Przestrzeganie powyższych zaleceń powinno sprawić, że unikniemy najgorszego scenariusza, czyli gwałtownej utraty ruchu organicznego po migracji.

2 Brak audytu SEO nowej wersji serwisu

Właściciele biznesów internetowych często niesłusznie ulegają przekonaniu, że skoro dokonują zmiany ze starszej na nowszą technologię, to wszelkie optymalizacje pod kątem wyszukiwarek będą wykonane prawidłowo.

Praktyka pokazuje, że bywa wręcz odwrotnie, dlatego niezbędny jest staranny audyt nowej wersji przed jej produkcyjnym uruchomieniem.

Poniżej kilka typowych problemów.

2.1 Subtelne zmiany w organizacji linkowania wewnętrznego

Są to często zmiany trudne do wychwycenia, a mogą mieć kolosalny wpływ na ruch, jaki pozyskujemy z wyszukiwarek.

Najbardziej typowy przykład to nieodpowiednie użycie metaznaczników „canonical”.

Wyobraźmy sobie, że uniknęliśmy problemu opisanego w punkcie 1 – zadbaliśmy o zachowanie adresów lub odpowiednie przekierowania w nowej wersji naszego sklepu.

Nie zauważyliśmy jednak, że nowa wersja sklepu dodała znaczniki „canonical”, które wszystkie strony będące kombinacjami „kategoria produktu + cecha”, np. „czarne sukienki”, przekierowują na stronę główną danej kategorii, czyli np. na „sukienki”.

Sprawia to, że po przeindeksowaniu serwisu, nagle tracimy wypracowany w pocie czoła, świetnie konwertujący ruch z fraz z długiego ogona. Co gorsza, nie od razu zauważymy, co jest przyczyną problemów, bo w Google Analytics nie znajdziemy już informacji o słowach kluczowych, które sprowadzają ruch.

Decyzje dotyczące optymalizacji linkowania wewnętrznego, rozwiązania paginacji, stron generowanych przez tagi czy filtry, powinny być podejmowane bardzo świadomie i ze zrozumieniem skutków.

Zdanie się na to, że w danym skrypcie „tak to działa”, jest najgorszym, co możemy zrobić.

2.2 „Usprawnienia” techniczne wprowadzane bez analizy konsekwencji

Również całkiem niedawno spotkaliśmy się z sytuacją, w której nasz klient zrealizował migrację na nową wersję sklepu, ale firma odpowiadająca za obsługę programistyczną, bez konsultacji z kimkolwiek, już na wersji produkcyjnej, postanowiła włączyć dodatkowe „usprawnienie” w postaci paginacji ajaxowej.

Problem został na szczęście szybko dostrzeżony, ale gdyby tak się nie stało, wówczas taka organizacja nawigacji wewnętrznej mogłaby bardzo niekorzystnie wpłynąć na indeksowanie serwisu i ruch organiczny.

Ogólna zasada brzmi: wszelkie zmiany technologiczne, które mają wpływ na kod strony lub strukturę wewnętrznej nawigacji, powinny być zawsze konsultowane z osobą, która jest w stanie poprawnie ocenić ich wpływ na optymalizację dla wyszukiwarek.

2.3 Ogólna optymalizacja kodu strony, „poprawki” wizualne o negatywnych skutkach SEO

Przy okazji migracji, warto zadbać zarówno o to, aby kod strony był maksymalnie zoptymalizowany i wykorzystywał nowe możliwości (choćby mikroformaty).

Jednocześnie jednak, trzeba się upewnić, że projektanci nie zrobili krzywdy optymalizacji na rzecz estetyki.

Zupełnie niedawny przypadek z naszej praktyki to sklep, w którym projektant uznał, że nagłówki H1, w których zawarte były nazwy kategorii, zakłócały efekt wizualny, dlatego postanowił je schować z pomocą stylu display:none.

Nie trzeba chyba wyjaśniać, że to po pierwsze zabija optymalizację, jaką zapewnia odpowiednie wykorzystanie nagłówków, a po drugie, może wręcz narażać na kary za ukrywanie słów kluczowych.

2.4 Nagły przyrost zduplikowanych treści w obrębie serwisu

Jedną z niepożądanych konsekwencji migracji do nowych systemów bywa gwałtowny przyrost zduplikowanych treści.

Przyczyn tego może być kilka:

  • rozbudowany system filtrów, który nie jest odpowiednio regulowany użyciem znaczników nofollow i noindex oraz canonical
  • niewykorzystanie mechanizmów oferowanych przez robots.txt do blokowania stron, które powinny być poza indeksem
  • wewnętrzna wyszukiwarka, która generuje nieskończoną liczbę podstron
  • zła obsługa adresów URL, które dla dowolnego wpisanego ciągu zwracają kod 200 zamiast 404, gdy nie ma podstrony (nieustająca bolączka polskich skryptów Shoper i ClickShop)
  • generowanie oddzielnych podstron dla każdego komentarza do każdego produktu (casus domyślnej konfiguracji Magento)
  • i wiele innych.

Przetestowanie tych zagadnień przed migracją, odpowiednia optymalizacja, a następnie monitorowanie indeksu Google po migracji, są niezwykle istotne.

Niekontrolowany i niezaplanowany wzrost liczby stron w indeksie bardzo szybko może doprowadzić do znacznego obniżenia ruchu organicznego, choćby z tego powodu, że siła wewnętrznego linkowania rozmywa się między tysiącami podstron, które ze sobą konkurują.

2.5 Zmiana nazewnictwa obrazków

Niektóre sklepy, zwłaszcza ubraniowe, pozyskują dużo ruchu z wyszukiwarki obrazków, do czego niezbędna jest odpowiednia optymalizacja (nazwy plików, znaczniki alt itd.).

Niestety, niektóre platformy ecommerce, w domyślnej konfiguracji, wymuszają stosowanie fatalnie zoptymalizowanych nazw obrazków, np. w postaci ciągu cyfr.

Migracja do takiej platformy kończy się bardzo szybko utratą ruchu z wyszukiwania obrazkowego, a to może być znaczący cios w całość ruchu organicznego.

3 Wersja developerska widoczna publicznie i zaindeksowana w Google

Nawet nie jesteśmy w stanie opisać, ile razy spotkaliśmy ten problem. Firmy developerskie z absolutną beztroską umieszczają wersje testowe serwisów pod publicznie dostępnymi subdomenami, często z pełną zawartością, w żaden sposób nie blokując indeksowania. Karygodne!

Co gorsze, najczęściej prośba o zablokowanie dostępu budzi ich wielkie zdziwienie, bo „od zawsze tak robili i wersje testowe wszystkich ich klientów są widoczne”. Spotkaliśmy się z przypadkami, gdzie firmy oczekiwały dodatkowego wynagrodzenia za zablokowanie dostępu do wersji developerskiej.

Dlatego jest niezwykle ważne, aby potwierdzić z wykonawcą sklepu, że nowa wersja nie jest dostępna publicznie pod żadnym adresem testowym. Dostęp do niej powinien być chroniony hasłem.

4 Testowanie w środowisku innym niż produkcyjne

Jest to błąd, który bardzo łatwo popełnić. Polega on na tym, że prace nad nową wersją sklepu są prowadzone w innym środowisku (konfiguracja serwera, bazy danych) niż środowisko produkcyjne, w którym działa sklep dostępny dla klientów.

Staranne testy pokazują, że wszystko działa, następuje przełączenie i… zaczynają się problemy – głównie z błędnym działaniem niektórych mechanizmów.

Najprostszy przykład to mechanizmy cache’ujące, np. Varnish, które często są uruchomione na serwerze produkcyjnym. Podczas prac programistycznych są one najczęściej wyłączone, by nie utrudniać testów, ale z kolei przy większym obciążeniu ruchem i takich skryptach jak Magento, ich użycie jest niemal nieodzowne, by zapewnić odpowiednią wydajność.

Gdy na serwerze testowym nie ma Varnisha (lub podobnego mechanizmu), wszystko zachowuje się poprawnie.

Po przełączeniu na serwer produkcyjny, na którym dochodzi warstwa cache’ująca, nagle przestaje działać wiele istotnych mechanizmów, choćby filtrowanie produktów. A sprzedaż natychmiast spada…

Dlatego należy pamiętać, żeby przed przełączeniem na nową wersję serwisu, jego testy zawsze prowadzić w środowisku, które możliwie dokładnie odwzorowuje środowisko produkcyjne.

5 Współpraca z zewnętrznymi systemami

Większe sklepy (lub mniejsze, ale ambitne) pozyskują ruch z bardzo wielu kanałów, wśród których są też sieci remarketingowe, programy partnerskie, porównywarki czy reklamy produktowe w Google.

Wiele z tych kanałów do poprawnego działania wymaga odpowiedniego wdrożenia po stronie sklepu.

Zwykle chodzi o:

  • podpięcie odpowiednich skryptów, np. zliczających transakcję, rejestrujących przeglądane produkty itd.
  • przygotowanie niezbędnych feedów, które eksportują dane produktowe do zewnętrznych systemów w ściśle określonym formacie

Problemy mogą dotyczyć każdego z tych dwóch punktów.

Po pierwsze, przy migracji bardzo łatwo zapomnieć o przepięciu wszystkich niezbędnych skryptów.

Bardzo dużym ułatwieniem tutaj jest przeniesienie zarządzania wszystkimi skryptami do usługi Google TagManager – temu zagadnieniu poświęcimy cały, oddzielny cykl artykułów.

Jeżeli nie przepniemy skryptów, w najlepszym razie poszczególne usługi przestaną działać, a w najgorszym, mogą nam zacząć naliczać kary umowne (takie zapisy mają prawie wszystkie sieci oferujące ruch rozliczany w modelu CPS, czyli cost per sale – prowizja od sprzedaży).

Jeżeli z kolei zapomnimy o tym, że nowy sklep musi generować feedy produktowe dla każdego z tych zewnętrznych systemów, to również uniemożliwimy ich działanie, ponieważ informacje o ofercie produktowej naszego sklepu są podstawą ich działania.

6 Przetestuj możliwe wszystkie kombinacje płatności i trybów dostaw

Parę dni temu jeden z naszych klientów wdrożył, zupełnie udanie, nową wersję swojego sklepu.

Pomimo wszystkich testów, pojawił się jednak jeden istotny problem w bardzo newralgicznym punkcie sklepu – nie działała jedna kombinacja trybu dostawy i płatności za pobraniem. Choć była dostępna, to jej wybranie generowało brzydki komunikat błędu.

Problem został wykryty przypadkiem, przy okazji innych testów.

Dlatego warto ten test wpisać na listę testów prowadzonych przed uruchomieniem nowej wersji sklepu na żywo, aby nie ryzykować, że rozczarowani klienci zrezygnują z zakupów, a my będziemy zastanawiać się, dlaczego konwersja spada.

7 Wydajność, a raczej jej brak

W przypadku skomplikowanych wdrożeń, osiągnięcie odpowiedniej wydajności bywa jednym z największych problemów.

Sklep, który dobrze działa w czasie testów, gdy jest używany przez kilka czy kilkanaście osób, zaczyna działać fatalnie, gdy musi funkcjonować w rzeczywistych warunkach, pod obciążeniem generowanym przez tysiące użytkowników.

Problem jest tym większy, im:

  • większy ruch
  • większa baza produktów
  • większa liczba filtrów, atrybutów i elementów generowanych dynamicznie

Ostatnia rzecz, której byśmy pragnęli po uruchomieniu nowej wersji sklepu, to znaczne wydłużenie czasu wczytywania się stron, bądź – co jeszcze gorsze – komunikaty o błędach przeciążonego serwera.

Dlatego przed uruchomieniem produkcyjnym, koniecznie musimy przetestować sklep pod obciążeniem i wyeliminować wąskie gardła.

Jest to temat wysoce techniczny i projekt sam w sobie, ale podsuniemy kilka wskazówek.

Po pierwsze, znakomitym pomysłem jest uruchomienie na serwerze narzędzia monitorującego wydajność New Relic.

Jest to płatne rozwiązanie, ale oferuje w pełni funkcjonalny, 14-dniowy okres testowy – wystarczający do rozwiązania większości początkowych problemów. Dzięki temu narzędziu zobaczymy dokładnie, które części aplikacji czy jakie zapytania do bazy powodują problemy.

Jest to podstawowe narzędzie, które wykorzystujemy w pracy z naszymi klientami, gdy konieczna jest optymalizacja wydajności – wygoda i błyskawiczny dostęp do informacji są nieocenione.

Gdy New Relic będzie uruchomiony na serwerze, warto pomyśleć o narzędziach, które wygenerują odpowiednie obciążenie.

W najprostszym przypadku, będzie to Apache Benchmark, czyli ab. Niezwykle łatwy w obsłudze, pozwala jednym poleceniem zasymulować obciążenie generowane przez wielu użytkowników.

Bardziej skomplikowane testy, obejmujące testowanie różnych mechanizmów sklepu, są możliwe do realizacji z użyciem np. programu Apache JMeter.

Co na pewno warto testować:

  • działanie strony głównej, stron kategorii i produktowych
  • działanie stron kategorii w kombinacji z różnymi filtrami
  • działanie wyszukiwarki
  • działanie logowanie / wylogowania
  • działanie koszyka

8 Działanie wewnętrznej wyszukiwarki

W dużych sklepach, o rozbudowanym asortymencie, sprawna wyszukiwarka wewnętrzna jest jednym z najważniejszych elementów nawigacyjnych, mających bardzo duży wpływ na skuteczność sprzedaży.

Potwierdza to analiza danych praktycznie każdego większego sklepu.

Dlatego przy ewentualnych migracjach, należy dołożyć wszelkich starań, aby przynajmniej nie zepsuć tego, co działało wcześniej, a najlepiej – znacznie to usprawnić.

Kilka podstawowych elementów, na które koniecznie trzeba zwrócić uwagę, to:

  • czy wyszukiwarka jest w stanie obsłużyć odmianę; niedawno wykryliśmy u naszego klienta, że zapytanie „sukienka” zwracało kilka tysięcy wyników, ale zapytanie „sukienki” – zero.
  • czy wyszukiwarka jest w stanie obsłużyć popularne literówki. Jeśli sprzedajemy ubrania „Troll”, to czy jak klient wpisze „trol”, to znajdzie oczekiwane wyniki, czy nie. Często okazuje się, że bez odpowiednich poprawek – nic nie znajdzie.
  • czy wyszukiwarka jest w stanie obsłużyć zapytania kilkuwyrazowe, uwzględniające atrybuty. Przykładowo, jeśli użytkownik wpisuje „czerwone sukienki”, to szuka właśnie tego – czerwonych sukienek, a nie wszystkich czerwonych ubrań i wszystkich sukienek – a wiele wyszukiwarek w taki sposób interpretuje zapytania wielowyrazowe, rozbijając je na pojedyczne słowa.

Temat jest znacznie szerszy, bo sprytnie wykorzystana wyszukiwarka wewnętrzna to też doskonałe narzędzie do pozyskiwania ruchu z długiego ogona – ale to temat na oddzielny wpis.

9 Podsumowanie

Jak widać z powyższego opisu, migracja na nową platformę to nie jest łatwy proces.

Migracja przeprowadzona nieumiejętnie może zakończyć się utratą ruchu, kłopotami we współpracy z partnerami, a w ostatecznym rozrachunku, znacznym zmniejszeniem sprzedaży.

Dlatego proces ten powinien być bardzo starannie zaplanowany i uwzględniony w harmonogramie prac nad nową wersją serwisu, najlepiej z co najmniej 2-miesięcznym wyprzedzeniem przed planowanym terminem uruchomienia nowej wersji.

Przy odpowiednim planowaniu, ryzyko problemów zostaje ograniczone do minimum, a jednocześnie zyskujemy szansę na wprowadzenie optymalizacji, które wyniosą sklep (lub inną witrynę) na znacznie wyższy niż wcześniej poziom.

Jeżeli stoją Państwo przed takim wyzwaniem i mają wątpliwości, jak zrealizować ten proces, zapraszamy do kontaktu.

Shares 0
Marcin Lejman
 

Jestem współwłaścicielem Critical.pl. Prowadzę przede wszystkim projekty związane z analityką internetową, optymalizacją konwersji i budową strategii online, a nadzoruję działania SEO i PPC prowadzone przez naszą firmę. Jeśli czujesz, że Twój biznes ma niewykorzystany potencjał i chcesz go rozwinąć, skontaktuj się ze mną - chętnie porozmawiam o możliwościach.

Click Here to Leave a Comment Below 2 comments
Paweł K. jak Krzywy - 19/12/2013

Witam.
Świetny wpis. Rzadkość w sieci, poważnie. Rewelacyjnie wypunktowane zagadnienie. Trzeba przyznać, że umiejętnie się promujecie. Bo dla zwykłego „zjadacza e-chleba” procedura wygląda na kosmicznie trudną (nie ma co ukrywać – jest to kawał roboty, a i wiedza jest konieczna), więc chyba każdy, kto stanie przed takim wyzwaniem i trafi na ten artykuł, zapragnie współpracy z Wami. Sam bym tak zrobił ;-)

Faktycznie, chyba większość zapomina o wyliczonych w artykule zagadnieniach. Oczywiście największy problem stanowi zmiana adresów URL. Google dostaje świra, są gigantyczne zawirowania. I najczęściej „łatanie” po fakcie.

Zaraz podeślę ten artykuł jednej Klientce, bo ma właśnie tego typu problem.

Raz jeszcze dzięki za ten art.
Paweł

Reply
Michał W. - 15/01/2016

Sam zwracam uwagę wszystkim znajomym na to, że przeniesienie sklepu na inny silnik jest bardzo ryzykowne. Wszyscy myślą, że przeniosą sklep na inne oprogramowanie, dadzą nową grafikę i sprzedaż automatycznie się zwiększy. Często jest jednak odwrotnie i wtedy jest wielka panika.

Sam bym się chyba na takie posunięcie nie zdecydował, no chyba że przekazałbym to specjalistom takim jak wy, bo widać że wiecie o czym piszecie.

Reply

Leave a Reply:

0 Shares