Migrację sklepu pod SEO zacznij od spisu starych adresów i przypisania każdemu ważnemu URL nowego odpowiednika. Przed startem przetestuj nowe strony, canonicale i przekierowania trwałe. Po przełączeniu sprawdź odpowiedzi HTTP, linki, mapę witryny oraz raporty Search Console. Taki plan ogranicza ryzyko utraty odkrywalności; nie gwarantuje braku wahań widoczności podczas ponownego skanowania.
Przeniesienie sklepu oznacza więcej niż import produktów. Wyszukiwarka zna stare adresy kategorii, kart, poradników, zdjęć i dokumentów. Klienci mają je w zakładkach, wiadomościach oraz linkach partnerów. Nowa platforma może zmienić ścieżki nawet przy tej samej domenie. Jeżeli stare URL nagle zwracają 404, a nowe nie mają linków i poprawnych sygnałów kanonicznych, robot musi od nowa odkryć relacje między stronami. Dlatego praca SEO powinna rozpocząć się przed dniem przełączenia.
Ten poradnik dotyczy migracji z istotną zmianą adresów. Sama zmiana hostingu przy zachowaniu URL ma inny zestaw ryzyk. W pozycjonowaniu sklepu liczą się także treści i produkty, lecz tutaj głównym artefaktem jest mapa stary URL → nowy URL → oczekiwana odpowiedź → wynik testu. Przygotowaliśmy ją jako przykład, bez udawania danych prawdziwego sklepu.
Jak zrobić inwentaryzację przed migracją?
Zbierz adresy z kilku źródeł. Eksport katalogu pokaże produkty i kolekcje, mapa witryny adresy zgłaszane robotom, crawler linki osiągalne z menu, a Search Console strony z wyświetleniami i linkami. Logi serwera mogą ujawnić stare adresy, które nadal odwiedzają roboty lub użytkownicy, choć nie występują w aktualnym menu. Osobno zapisz ważne obrazy, pliki PDF i landing pages kampanii. Google zaleca uwzględnienie także zasobów, które mają własny ruch lub linki.
Nie ograniczaj listy do URL generujących sprzedaż w ostatnim tygodniu. Sezonowa kategoria może być teraz cicha, ale mieć historię wyszukiwań i linków. Dla każdego adresu zapisz typ strony, stan HTTP, canonical, ruch organiczny w sensownym okresie, linki wewnętrzne i zewnętrzne oraz decyzję: zachować, przenieść, połączyć albo usunąć bez odpowiednika. Wartości liczbowe powinny pochodzić z własnych danych, nie z ogólnych progów w poradniku.
Zrób również bazowy zapis wyników: kliknięcia i wyświetlenia w Search Console dla kluczowych katalogów, udział ruchu kategorii i produktów, strony z błędami, stan indeksowania oraz liczbę konwersji z ruchu organicznego. Ustal, kto ma dostęp do starej i nowej właściwości Search Console. Przy zmianie domeny potrzebujesz danych obu stron; przy zmianie platformy w tej samej domenie wystarczy ciągłość pomiaru, ale i tak sprawdź, czy kod analityczny oraz zdarzenia zakupowe działają po przełączeniu.
Jak przypisać stary URL do nowego?
Mapuj według odpowiednika treści i intencji, nie według najbliższego technicznie wzorca. Stara kategoria lamp biurkowych powinna prowadzić do nowej kategorii lamp biurkowych, jeśli istnieje. Karta konkretnego modelu prowadzi do nowej karty tego samego modelu. Jeżeli produkt ma trwałego następcę, sprawdź, czy jest naprawdę zamiennikiem; sam fakt, że oba są „lampami”, nie wystarcza. Nie kieruj masowo usuniętych produktów na stronę główną, bo użytkownik nie dostanie odpowiedzi na kliknięty link.
Gdy nie istnieje sensowny odpowiednik, rozważ pozostawienie starej strony z informacją o braku dostępności i alternatywami, jeśli wciąż pomaga kupującym. Gdy treść znika bez zastępstwa, kod 404 lub 410 jest prawidłową odpowiedzią. Google opisuje taki stan jako właściwy dla treści usuniętej, której nie przenosisz. Przekierowanie do ogólnej kategorii ma sens tylko wtedy, gdy ta strona rzeczywiście rozwiązuje podobną potrzebę.
Stała zmiana adresu powinna korzystać z serwerowego przekierowania trwałego, zwykle HTTP 301 albo 308. Google traktuje je jako sygnał, że nowy cel ma być kanoniczny. Tymczasowy 302 ma inną semantykę. Nie zamieniaj wszystkich 302 w 301 bez zrozumienia powodu; część może dotyczyć czasowych akcji sklepu. Dla mapy migracyjnej oczekuj jednak jednego jasnego stałego przejścia ze starego adresu do odpowiedniej nowej strony.
Przykładowa mapa przekierowań sklepu
Poniższy rejestr jest demonstracyjny. Domeny i produkty są fikcyjne. W prawdziwej migracji dodaj kompletne adresy z protokołem, identyfikator rekordu, źródło danych, właściciela zadania i wynik automatycznego testu.
| Stary URL | Nowy cel lub decyzja | Uzasadnienie dopasowania | Oczekiwany test |
|---|---|---|---|
/kategoria/lampy-biurowe | /lampy/biurkowe/ | Ta sama grupa produktów | 301 → 200; nowy self-canonical |
/produkt/lampa-a-123 | /products/lampa-a | Ten sam model i wariant | 301 → 200; zgodna karta |
/blog/jak-wybrac-lampe | /poradnik/jak-wybrac-lampe | Ten sam poradnik | 301 → 200; zachowana treść |
/produkt/lampa-stara | decyzja po przeglądzie | Czy istnieje realny następca? | 301 do odpowiednika albo 404/410 |
/foto/lampa-a.jpg | nowy adres obrazu | Ten sam plik lub jego odpowiednik | 301 → dostępny obraz |
W tej tabeli ostatni wiersz decyzyjny jest celowo otwarty. Zespół musi sprawdzić katalog, historię ruchu i potrzeby klienta. Dzięki temu rejestr nie zamienia się w automatyczny generator przekierowań do strony głównej. Oddziel kolumnę „plan” od „wynik po uruchomieniu”; poprawna mapa w arkuszu nie dowodzi, że serwer faktycznie ją realizuje.
Co przetestować na nowym sklepie przed startem?
Na środowisku testowym sprawdź próbki wszystkich typów stron: stronę główną, ważne kategorie, podkategorie, produkty, warianty, poradniki, wyszukiwarkę wewnętrzną, paginację i obrazy. Każda strona, którą chcesz indeksować, powinna zwracać 200, mieć właściwy canonical oraz nie mieć przypadkowego noindex. Upewnij się, że blokada używana do ochrony środowiska testowego zostanie usunięta z produkcyjnej wersji. Osobne hasło do stagingu może być prostszą kontrolą dostępu niż kombinacja sprzecznych dyrektyw dla robota.
Porównaj treść starych i nowych kategorii. Migracja silnika często zmienia szablon i znika opis, H1, schema produktu lub link do podkategorii. Lista produktów może działać wizualnie, ale kolejne strony paginacji być dostępne tylko po kliknięciu skryptu. Testuj rzeczywisty HTML i linki. Dla kart sprawdź cenę, dostępność, zdjęcie, warianty i dane Product/Offer, szczególnie jeśli feed Merchant Center wskazuje nowe URL. Błąd sprzedażowy i błąd SEO mogą pochodzić z tego samego niezsynchronizowanego źródła produktu.
Przekierowania przetestuj przed przełączeniem, jeśli środowisko pozwala zasymulować stare adresy, a po przełączeniu ponownie na produkcji. Test powinien sprawdzić pierwszy status, liczbę kroków, końcową odpowiedź, finalny canonical i zgodność treści. Unikaj pętli oraz łańcuchów stary → pośredni → nowy, skoro możesz skierować stary URL bezpośrednio do celu. Nie polegaj wyłącznie na ręcznym otwarciu strony w przeglądarce, bo ta ukrywa kody pośrednie.
Co sprawdzić w dniu przełączenia?
Ustal kolejność i odpowiedzialnych: publikacja nowego sklepu, aktywacja przekierowań, usunięcie produkcyjnych blokad, test zamówienia, kontrola analityki i szybki crawl najważniejszych adresów. Przy zmianie domeny upewnij się, że stara domena nadal odpowiada i może przekierowywać. Sprawdź warianty z www i bez, HTTP oraz HTTPS, jeśli były używane. Stary serwer nie może zniknąć w chwili, kiedy przekierowania mają zacząć działać.
Nowa mapa witryny powinna wymieniać końcowe, kanoniczne adresy. Menu, opisy i artykuły powinny linkować już bezpośrednio do nowych stron. Przekierowanie chroni stare linki, ale nie powinno być codzienną ścieżką nawigacji własnego sklepu. Zgłoś mapę w Search Console i sprawdź, czy kluczowe URL nie są zablokowane. Przy zmianie domeny wykonaj działania właściwe dla przeniesienia całej witryny zgodnie z dokumentacją Google; nie używaj narzędzia zmiany adresu dla zwykłej zmiany ścieżek w tej samej domenie.
Od razu przejdź kilka pełnych ścieżek kupującego. Wejście ze starego linku, odnalezienie produktu, wybór wariantu, koszyk, płatność i potwierdzenie powinny działać. To sprawdza praktyczny skutek mapy lepiej niż sama odpowiedź 301. Jeśli sprzedajesz przez Merchant Center, porównaj URL produktu, obraz, cenę oraz dostępność z nową kartą. Nie zakładaj, że feed zaktualizuje się równocześnie z przełączeniem.
Jak monitorować migrację po publikacji?
Po uruchomieniu zaplanuj dzienny przegląd najważniejszych błędów i okresowe porównanie danych z bazą. Zwracaj uwagę na 404 starego URL, 5xx nowego serwera, 301 do niepowiązanej strony, nieoczekiwane canonicale, brak strony w mapie i spadek odkrywania produktu. Search Console pokaże zmiany indeksowania i zapytań, ale dane pojawiają się z opóźnieniem. Logi oraz crawler szybciej pokażą część błędów technicznych. Nie interpretuj pojedynczego dnia mniejszej liczby kliknięć jako dowodu, że cała migracja się nie udała.
Google uprzedza, że przy istotnej zmianie adresów pozycje mogą się wahać, kiedy stare i nowe URL są ponownie skanowane oraz indeksowane. Tempo zależy między innymi od skali serwisu i dostępności serwera. Zamiast obiecywać konkretny tydzień powrotu, mierz progres po klasach: kluczowe kategorie, produkty, poradniki i zasoby. Porównuj te same okresy sezonowe oraz udział ruchu z poszczególnych stron. Jeśli jedna kategoria spada, sprawdź jej mapę, treść i linki zanim zmienisz cały sklep.
Utrzymuj przekierowania dla starych adresów tak długo, jak są potrzebne użytkownikom i robotom. Google zaleca co najmniej rok przy przenosinach witryny; wiele cennych starych linków uzasadnia dłuższe utrzymanie. Dokumentuj nowe zmiany katalogu, żeby nie tworzyć kolejnych łańcuchów. Po zamknięciu migracji wykonaj audyt SEO z porównaniem do bazowego stanu, a strukturę nowych kategorii oceń według poradnika o stronach kategorii.
Co sprawdzić dalej?
Temat łączy się z kolejnymi decyzjami w serwisie. Zobacz także seo kategorii produktów, karta produktu seo oraz filtry w sklepie indeksowanie.
