Migracja sklepu bez utraty pozycji w Google

Sklep najczęściej traci pozycje przy migracji dlatego, że stare adresy produktów i kategorii przestają działać, a nowe nie mają z nimi żadnego związku. Każda zaindeksowana strona produktu staje się wtedy błędem 404, a wypracowana przez lata pozycja przepada razem z nią.

Przed tym chronią przekierowania stałe, w branży nazywane po prostu przekierowaniami 301. Mówią wyszukiwarce, że strona przeniosła się pod nowy adres i że nowy adres ma zająć miejsce starego w wynikach. Trzeba je przygotować, zanim stary sklep zniknie. Robione po pierwszym tygodniu spadków tylko gonią straty.

Ważne jest to, że mają być stałe. Przekierowanie tymczasowe, oznaczane kodem 302, mówi Google, że zmiana jest chwilowa. Klient trafia pod nowy adres tak samo, ale w wynikach wyszukiwania zostaje stary adres, bo według dokumentacji Google przekierowanie tymczasowe nie wskazuje nowej strony jako głównej.

Mapa adresów powstaje przed migracją

To jest czynność, której nie da się nadrobić później, bo materiał źródłowy przestaje istnieć w momencie przełączenia.

Zanim cokolwiek ruszysz, zbierz listę wszystkich adresów, które wyszukiwarka zna:

Z mapy witryny starego sklepu. Pełna lista produktów, kategorii, podstron treściowych i stron producentów. Od niej zaczyna też instrukcja przenosin w dokumentacji Google.

Z Search Console. Raport indeksowania pokazuje, ile adresów jest w indeksie, i daje listę przykładów. Ta lista ma najwyżej 1000 pozycji i Google zaznacza, że nie musi być kompletna, więc przy większym katalogu traktuj ją jako kontrolę mapy witryny. Raport linków pokaże dodatkowo adresy, do których prowadzą odnośniki z innych stron.

Z raportu ruchu. Adresy, które przyprowadzają wejścia, mają priorytet. Jeśli musisz ograniczyć pracę, rób przekierowania najpierw dla nich.

Zapisz to w arkuszu z dwiema kolumnami: stary adres i nowy odpowiednik. Druga kolumna wypełnia się w trakcie budowy nowego sklepu i to ona jest właściwym produktem tej pracy.

Co się zmienia w adresach między platformami

Każda platforma buduje adresy inaczej i to jest źródło problemu.

Sklep na WooCommerce trzyma produkty pod adresem z przedrostkiem product (albo innym, ustawionym w panelu) i nazwą produktu. PrestaShop dokłada do adresu identyfikator produktu, a strukturę kategorii buduje inaczej. Do tego dochodzą różnice w adresach stron z filtrowaniem, wyszukiwarką i stronicowaniem.

Nawet przy tej samej nazwie produktu adres wychodzi inny. Dlatego odwzorowanie jeden do jednego prawie nigdy nie działa automatycznie i mapa musi powstać ręcznie albo półautomatycznie, ze sprawdzeniem wyników.

Osobna pułapka to produkty, które w nowym sklepie nie mają odpowiednika, bo asortyment się zmienił. Nie przekierowuj ich na stronę główną. Google pisze wprost, że wiele starych adresów skierowanych na stronę główną może potraktować jak miękki błąd 404. Lepszy cel to kategoria, do której produkt należał.

Kolejność, która ogranicza ryzyko

1. Kopia starego sklepu, pełna: baza i pliki. Nie kasuj jej przez kilka miesięcy po migracji.
2. Nowy sklep na adresie tymczasowym, zablokowany przed indeksowaniem hasłem. Samo robots.txt nie wystarczy, wyjaśniam to niżej.
3. Import katalogu i sprawdzenie danych. Ceny, stany, warianty, zdjęcia. Tu wychodzi większość problemów z jakością eksportu ze starego systemu.
4. Uzupełnienie mapy adresów o nowe odpowiedniki.
5. Przełączenie domeny i wgranie przekierowań w tym samym kroku.
6. Zgłoszenie nowej mapy witryny w Search Console.
7. Obserwacja raportu indeksowania przez kolejne tygodnie.

Punkt piąty jest jedynym, w którym sklep bywa niedostępny, i dlatego planuje się go na godziny o najmniejszym ruchu.

Dlaczego robots.txt to za mało na sklep roboczy

Wpis w robots.txt to prośba, żeby robot nie pobierał treści. Adresu w wynikach nie blokuje. Google pisze, że zablokowany adres może trafić do indeksu, jeśli gdziekolwiek prowadzi do niego odnośnik. Pokaże się wtedy w wynikach bez opisu.

Skutek jest dokładnie tym, czego chciałeś uniknąć: masz dwa adresy z tym samym sklepem, konkurujące ze sobą, i trzeba je potem usuwać ręcznie.

Pewniejsza jest blokada hasłem na poziomie serwera, przez uwierzytelnianie podstawowe w pliku .htaccess:

AuthType Basic
AuthName "Sklep - wersja robocza"
AuthUserFile /pelna/sciezka/do/.htpasswd
Require valid-user

Bloku nie obudowuj w <IfModule>. Gdy serwer nie ma modułu uwierzytelniania, taki blok po cichu się nie wykona i sklep roboczy zostanie otwarty. Bez obudowy zobaczysz błąd od razu.

Plik z hasłami zakłada się poleceniem htpasswd na serwerze albo narzędziem w panelu hostingu, które zwykle nazywa się ochroną katalogu hasłem. Dwie rzeczy, na których łatwo się potknąć. W AuthUserFile wpisz pełną ścieżkę w systemie plików. Adres URL nie zadziała, a ścieżkę względną Apache liczy od katalogu instalacji serwera. Sam plik z hasłami musi leżeć poza katalogiem widocznym dla przeglądarki. Błędna ścieżka kończy się błędem 500, więc po wgraniu zaloguj się raz i sprawdź, czy sklep się otwiera.

Przy robots.txt robot dostaje prośbę. Przy haśle serwer odmawia mu dostępu i robot nie zobaczy strony w ogóle.

Pamiętaj tylko o zdjęciu blokady przy przełączeniu domeny. Sklep, który po migracji wita klientów okienkiem logowania, to najkrótsza droga do zerowej sprzedaży w dniu startu.

Co przenosi się osobno

Katalog to najbardziej widoczna część, ale nie jedyna.

Konta klientów. Hasła są zapisane jednokierunkowo i zwykły import ich nie przenosi. Część narzędzi do migracji ma osobny moduł, który na nowym sklepie przyjmuje stare hasło przy pierwszym logowaniu. Bez takiego modułu klienci ustawiają nowe hasło. Wtedy uprzedź ich mailem przed migracją, inaczej pierwsze dni po przełączeniu to lawina zgłoszeń o niedziałającym logowaniu.

Historia zamówień. Przenosi się osobnym importem i bywa pomijana przy oszczędnym budżecie. Decyzja zależy od tego, czy potrzebujesz jej do obsługi reklamacji i rozliczeń.

Opinie o produktach. Często siedzą w module, który po drugiej stronie nie ma odpowiednika. Sprawdź to przed migracją, bo opinie buduje się latami.

Treści blogowe i strony informacyjne. Łatwo o nich zapomnieć, a bywają najlepiej pozycjonowanymi adresami w całym sklepie.

Co wychodzi dopiero po miesiącu

Migracja ma opóźnione objawy i to jest jej najbardziej podstępna cecha.

Google zapowiada, że w trakcie przenosin widoczność w wynikach może się chwilowo wahać. Przeniesienie większości adresów małego albo średniego serwisu trwa według Google kilka tygodni, a większego dłużej. Przekierowania zalecają trzymać jak najdłużej, zwykle co najmniej rok.

Dlatego kopię starego sklepu trzyma się długo po przełączeniu. Jeśli w szóstym tygodniu okaże się, że brakuje przekierowań dla całej gałęzi kategorii, będziesz potrzebował starej bazy, żeby odtworzyć adresy.

Drugą rzeczą wychodzącą z opóźnieniem są integracje. Porównywarki cen, kanały produktowe i systemy magazynowe pobierają dane w swoim rytmie. Sklep działa, a produkty znikają z porównywarki, bo plik eksportowy zmienił strukturę.

Częste pytania

Ile trwa migracja sklepu? Najbardziej zależy od stanu danych w starym systemie. Liczba produktów ma mniejsze znaczenie. Katalog z sensownym eksportem przenosi się szybko. Katalog, w którym warianty siedzą w nazwie produktu, a opisy mają wklejone formatowanie z edytora tekstu, wymaga ręcznej pracy i to ona decyduje o terminie.

Czy stracę pozycje w Google? Przy poprawnych przekierowaniach 301 możesz spodziewać się chwilowych wahań. Google podaje, że przeniesienie większości adresów małego i średniego serwisu trwa kilka tygodni. Bez przekierowań stare adresy stają się błędami 404 i ich pozycje przepadają.

Czym różni się przekierowanie 301 od 302? Kod 301 oznacza przeniesienie na stałe i Google pokazuje wtedy w wynikach nowy adres. Kod 302 oznacza zmianę tymczasową, więc w wynikach zostaje stary adres. Przy migracji sklepu potrzebujesz 301. Przekierowanie 302 wygląda na działające, bo klient trafia tam, gdzie trzeba, ale Google nie traktuje nowego adresu jako następcy starego.

Czy wystarczy zablokować sklep roboczy w robots.txt? Nie. To prośba o niepobieranie treści. Adres może trafić do indeksu, bez opisu, jeśli gdziekolwiek pojawi się do niego odnośnik. Pewniejsza jest blokada hasłem na serwerze, bo wtedy robot nie zobaczy strony w ogóle.

Czy da się przenieść opinie klientów? Zależy od modułu po obu stronach. Sprawdź to przed migracją. Jeśli odpowiednika nie ma, czasem da się zaimportować opinie jako treść, tracąc powiązanie z kontem klienta.

Co z hasłami klientów? Hasła są zapisane w sposób uniemożliwiający odczytanie i zwykły import ich nie przenosi. Część narzędzi do migracji ma moduł, który przyjmuje stare hasło przy pierwszym logowaniu w nowym sklepie. Bez niego klienci ustawiają nowe, więc uprzedź ich o tym mailem przed przełączeniem.

Czy mogę zrobić migrację sam? Import katalogu przy prostym asortymencie tak. Trudna część to mapa adresów i przekierowania, bo błąd nie daje żadnego widocznego objawu od razu, a jego skutki wychodzą tygodniami.

Jeśli planujesz przeniesienie sklepu, napisz, z czego i na co przechodzisz oraz ile pozycji ma katalog. Powiem, gdzie w tym konkretnym przypadku jest największe ryzyko i co trzeba przygotować przed startem. Migracjami zajmuję się w ramach pracy nad sklepami. O przenoszeniu samej domeny w WordPressie piszę osobno, w tekście o aktualizacji bazy po zmianie adresu.