Migracja stron www oraz sklepów internetowych

Chcesz dokonać migracji strony www lub sklepu internetowego lecz nie chcesz stracić dotychczasowych efektów SEO i nie chcesz aby sprzedaż z kanału organic nagle spadła?

Oferujemy profesjonalną, w pełni bezpieczną oraz bezstratną pod kątem SEO. 

Jesteś zainteresowany/zainteresowana? Zapraszamy do kontaktu

Jak przeprowadzić migrację witryny, aby nie utracić efektów SEO

Migracja witryny — czy to zmiana platformy, struktury adresów, marki domenowej, redesign czy zmiana hostingu — to moment, w którym łatwo popełnić błędy i utracić efekty wieloletniej pracy SEO. Nawet jeśli nowa strona technicznie będzie lepsza, to nieumiejętnie przeprowadzona migracja może usunąć lub rozproszyć dotychczasową „moc SEO”. Dlatego migrację należy traktować jak poważny projekt techniczno-marketingowy, wymagający planowania, testów i monitoringu.

Celem migracji SEO jest to, by Google i inne wyszukiwarki jak najbardziej sprawnie „zrozumiały”, że nowa wersja witryny to kontynuacja poprzedniej, a nie zupełnie nowy projekt. Im bardziej struktura, adresy, treści i mechanizmy pozostaną spójne, tym mniejsze ryzyko utraty pozycji czy ruchu.

W kolejnych częściach opiszę pełny proces migracji z perspektywy SEO, krok po kroku, dodając wiele detali, o których w typowych poradnikach się zapomina.

Etap I: Audyt i przygotowanie planu migracji

1. Audyt obecnej witryny — kompletna inwentaryzacja

Pierwszym i kluczowym krokiem jest wykonanie bardzo dokładnej inwentaryzacji obecnej witryny:

• Zbierz wszystkie adresy URL — produkty, kategorie, artykuły, strony informacyjne, strony fan page’y, tagi, archive, itp.
• Ustal, które z tych stron są indeksowane w Google (Google Search Console, logi serwera, narzędzia typu Ahrefs, SEMrush, Screaming Frog).
• Sprawdź historyczne dane: które podstrony generują ruch organiczny, mają linki zewnętrzne, mają wysokie pozycje, jakie są frazy kluczowe przypisane do tych stron.
• Zanotuj metadane (title, meta description), struktury nagłówków, linkowanie wewnętrzne, obrazy i atrybuty alt, pliki multimedialne, dane strukturalne (schema.org), canonicale, hreflangi, itp.
• Przejrzyj logi serwera pod kątem błędów 404, problematycznych zapytań, fragmentów generujących wysokie obciążenie, nieprawidłowe przekierowania.

Cel: mieć pełny obraz tego, co istnieje i co należy zachować.

2. Definiowanie zakresu migracji i jej rodzaju

Migracja może mieć różny charakter. Oto kilka przykładów:

• Zmiana platformy e-commerce (np. z WooCommerce na Magento, czy Prestashop na Shopify).
• Rebranding / zmiana domeny / migracja na nową domenę.
• Zmiana struktury URL (np. uproszczenie ścieżek, usuwanie „/index.php/”, zmiana wersji z http na https, przerzucenie na www lub odwrotnie).
• Redesign i zmiany layoutu strony, które mogą wpłynąć na elementy on-page (nagłówki, struktura treści, kolejność bloków).
• Migracja treści (np. przeniesienie bloga, treści pomocniczych, FAQ).
• Zmiana hostingu, serwera — choć sama w sobie nie zmienia treści, może mieć wpływ na czasy ładowania, konfiguracje serwera, adresy IP.

Dobrze określ, które z tych części obejmie migracja, i jakie zmiany będą dopuszczalne. To pozwoli stworzyć plan milowy (etapowy).

3. Przygotowanie harmonogramu i rollback planu

Plan migracji musi zawierać:

• Terminy poszczególnych etapów (mapowanie URL, konfiguracja środowiska testowego, testy, „go live”, monitoring).
• Podział odpowiedzialności (zespół techniczny, SEO, content, webmaster).
• Okienko migracji (najlepiej w godzinach mniejszego ruchu) i czas rezerwy.
• Plan awaryjny (rollback) — co zrobić, gdy coś pójdzie źle: przywrócenie starego serwera, tymczasowe przekierowania, szybkie działania naprawcze.
• Testy przed migracją (w środowisku staging) i testy po — sprawdzenie, czy przekierowania działają, elementy strony nie są uszkodzone, indeksacja działa poprawnie, canonicale, hreflangi.

Etap II: Przygotowanie techniczne i testowanie

4. Środowisko testowe (staging) i testy „sucho”

Zanim dokonasz migracji w środowisku produkcyjnym, stwórz kopię witryny w środowisku testowym (staging) i przeprowadź kompletną migrację tam:

• Skonfiguruj domenę testową (np. dev.twojadomena.pl) i zadbaj o to, by roboty nie indeksowały tej wersji (np. przez meta robots noindex, plik robots.txt lub hasło).
• Przeprowadź pełny test mapowania URL, test przekierowań 301, sprawdź czy strony generują poprawne nagłówki (200 OK, 301, 404 tam, gdzie trzeba).
• Zbadaj dane strukturalne, canonicale i hreflangi, jeżeli używane — czy są poprawnie ustawione.
• Sprawdź, czy wszystkie zasoby (obrazy, CSS, JS, pliki PDF) zostały przeniesione i wywoływane poprawnie.
• Przetestuj poprawność formularzy, linków wewnętrznych, wewnętrznych wyszukiwarek, paginacji itp.
• Monitoruj logi serwera, czy nie pojawiają się nowe błędy (5xx, 4xx).
• Skontroluj szybkość strony, czasy ładowania, kompresję, cache i inne parametry techniczne (np. nagłówki HTTP, gzip, HTTP/2).
• W stagingu możesz też uruchomić limited traffic (np. z pliku hosts lokalnie przekierować domenę na staging) i testować jak wyszukiwarki kucharsko reagują.

5. Mapowanie URL i przekierowania 301

Jeśli migracja obejmuje zmianę adresów URL (lub nie można odwzorować struktury 1:1) — konieczne jest przygotowanie precyzyjnych przekierowań:

• Każdy stary URL, który ma odpowiednik w nowej wersji — przekieruj na dokładny odpowiednik (1:1).
• Jeśli natrafiasz na stare URL-e, które nie mają bezpośredniego odpowiednika (np. stary wpis blogowy, który nie pasuje tematycznie) — przekieruj na najbliższą tematycznie kategorię lub stronę główną.
• Unikaj łańcuchów przekierowań (stary → kompromisowy → docelowy). Staraj się, by każdy przekierowanie było pojedyncze (stary → nowy).
• Używaj statusu HTTP 301 (przekierowanie stałe), nie 302, jeśli celem zmian jest trwała migracja.
• Przekierowania powinny być zapisane na poziomie serwera (Apache, Nginx) lub CDN, a nie tylko w kodzie CMS.
• Stwórz mapę CSV lub arkusz, zawierający stare URL, nowe URL, typ przekierowania, komentarze.
• Po migracji testuj losowo wiele adresów starych — czy są poprawnie przekierowane.
• Monitoruj w GSC (Google Search Console) sekcję „Przekierowania” i ewentualne błędy (np. „soft 404”, błędy przekierowań).

6. Przeniesienie treści i struktury on-page

Podczas migracji musisz zadbać o to, by wszystkie elementy on-page (które wpływają na SEO) zostały przeniesione lub odtworzone:

• Metatagi (title, meta description), tagi alt obrazków, nagłówki (H1, H2, H3…), anchor-text w linkach wewnętrznych.
• Treści, które generują ruch (artykuły, opisy produktów), w tej samej formie (lub bardzo podobnej, jeśli planujesz optymalizacje po migracji).
• Linkowanie wewnętrzne — upewnij się, że wszystkie linki są poprawne, nie prowadzą do błędów 404, nie tracą parametrów.
• Dane strukturalne (schema.org), jeśli używasz (np. Product, Breadcrumb, FAQ, Review) — muszą być przeniesione i poprawnie osadzone.
• Canonicale i rel=“alternate / hreflang” (gdy są stosowane) — muszą wskazywać na odpowiednie nowe adresy.
• Podobnie treści pomocnicze: FAQ, polityka prywatności, regulaminy, strony informacyjne — wszystkie muszą być obecne.
• Możliwość, że zrobisz minimalne optymalizacje (np. drobne korekty tytułów), ale jeśli już to rób to ostrożnie — najlepiej dopiero po migracji, gdy nowa wersja zostanie zaindeksowana.

7. Konfiguracja serwera, nagłówki HTTP, certyfikat SSL

Aspekty techniczne serwera mają znaczny wpływ na SEO:

• Upewnij się, że nowy serwer obsługuje wszystkie niezbędne funkcje (mod_rewrite, nagłówki, kompresję, HTTP/2 lub HTTP/3).
• Zainstaluj i poprawnie skonfiguruj certyfikat SSL (https). Wszystkie adresy http muszą przekierowywać na https.
• Ustaw poprawne nagłówki HTTP — Cache-Control, Expires, Last-Modified, ETag — by optymalizować cache.
• Ustal canonicale i ewentualne noindexy tam, gdzie trzeba.
• Sprawdź, czy nowy serwer nie generuje błędów 404, 500 itp.
• Jeżeli używasz CDN lub narzędzi typu reverse proxy, upewnij się, że przekierowania i nagłówki działają prawidłowo w tym kontekście.

Etap III: Migracja „w produkcji” i uruchomienie nowej wersji

8. Wprowadzenie wersji produkcyjnej i przekierowania

W ustalionym terminie (najlepiej w nocy lub czasie mniejszego ruchu) przeprowadza się migrację „na żywo”:

• Skieruj ruch domeny produkcyjnej na nową wersję witryny.
• Włącz przekierowania 301 dla wszystkich starych adresów.
• Jeśli dotychczas używałeś wersji z „www” lub bez — upewnij się, że ustawienia domeny są spójne (np. globalne przekierowanie z non-www do www lub odwrotnie).
• Zaktualizuj mapę strony (sitemap.xml) i prześlij ją do Google Search Console.
• Zaktualizuj plik robots.txt (jeśli konieczne) — upewnij się, że dostęp do kluczowych katalogów nie jest zablokowany przez błąd.
• Zgłoś nową wersję do Google (indeksowanie) przez GSC.

9. Monitoring i walidacja pierwszych dni

Po uruchomieniu, bardzo intensywnie monitoruj:

• W Google Search Console — błędy indeksowania, błędy 404, przekierowania, pokrycie indeksu.
• W logach serwera — skany pod kątem 4xx i 5xx.
• W narzędziach SEO — pozycje fraz, spadki lub wzrosty, zmiany ruchu.
• W narzędziach analitycznych (Google Analytics / GA4) — spadek ruchu organicznego, spadek wejść, bounce rate.
• Wydajność — czasy ładowania, błędy zasobów.
• Sprawdzanie losowych adresów starych — czy poprawnie przekierowują do nowych.
• Monitoruj linki zwrotne (backlinki), czy trafiają one na przekierowane adresy lub są odpowiednio dostosowane.

10. Stopniowe wdrożenie zmian pokorelowanych

Po upływie tygodni (lub miesięcy), gdy nowa struktura zostanie prawidłowo zaindeksowana i nie obserwujesz negatywnych trendów:

• Zaczynaj wprowadzać planowane optymalizacje (zmiany w strukturze, nowe funkcje, lepsza architektura menu).
• Wprowadzaj ewentualne poprawki w treściach, optymalizacje szybkości, zmiany układów.
• Dodawaj nowe sekcje, jeśli to konieczne, z zachowaniem ostrożności i testów.
• Regularnie porównuj starą i nową wersję, by wykrywać anomalie i ewentualne błędy.

Dodatkowe, często pomijane aspekty migracji SEO (które wzbogacają plan)

Poniżej znajdziesz zbiór zaawansowanych zagadnień i wskazówek, które często nie występują w prostych poradnikach — a mogą zdecydować o powodzeniu migracji.

1. Migracja danych strukturalnych (schema, JSON-LD)

Jeśli używasz danych strukturalnych (np. Product, Review, Breadcrumb, FAQ, Article), musisz je starannie przenieść:

• Upewnij się, że identyfikatory ID (np. w @id lub @context) są spójne lub odpowiednio zmienione.
• Sprawdź ręcznie kod źródłowy nowej strony, czy w sekcji <head> lub <body> znajdują się poprawne skrypty JSON-LD.
• Przed migracją, zweryfikuj dane strukturalne w narzędziach typu Google Rich Results Test.
• Po migracji sprawdź w GSC raport „Występowanie wyników rozszerzonych” (Rich Results) — czy Google akceptuje nowe dane strukturalne.

1. Obsługa przejściowa (soft launch, monitorowany ruch)

Jeśli to możliwe, zastosuj technikę canary release lub soft launch:

• Przełącz tylko część ruchu na nową wersję (np. 5-10 %) i monitoruj zachowanie, błędy i utratę ruchu.
• Stopniowo zwiększaj ruch (np. przez DNS, load balancing) w miarę potwierdzania poprawności działania.
• Jeśli coś pójdzie źle, możliwy jest szybki rollback dla części użytkowników, zamiast całkowitego cofnięcia migracji.

1. Monitorowanie zachowań użytkowników jako sygnał jakości

Po migracji obserwuj metryki użytkownika — one mogą szybciej wskazać problemy niż same narzędzia SEO:

• Współczynnik odrzuceń (bounce rate) — nagły wzrost może sugerować, że design lub układ strony odstrasza użytkowników.
• Czas spędzony na stronie, liczba stron / sesja — spadki mogą sygnalizować problemy z UX lub indeksacją.
• Wskaźniki konwersji (złożone zamówienia, zapis do newslettera itp.) — jeśli spadają, może to efekt błędów w formularzach lub trasach przepływu użytkownika.
• Mapy cieplne (heatmaps), analizy scrollowania — czy użytkownicy docierają do kluczowych treści.
• Formularze błędów – czy nagle pojawiają się komunikaty lub brak działania formularzy (kontakt, zamówienia).

1. SEO internacjonalizacja i hreflang

Jeśli witryna działa w wielu językach lub regionach:

• Upewnij się, że tagi hreflang są poprawnie odtworzone — każda strona ma poprawne hreflangi wskazujące do właściwych wersji językowych.
• Zadbaj, by wersje regionalne były dobrze przekierowane (np. stary adres /en/ powinien prowadzić do nowej wersji en).
• Sprawdź reguły kanoniczne w kontekście języków — nie dopuść do konfliktów canonical + hreflang.
• Uwaga na adresy z parametrami językowymi — mogą powodować duplikację treści.
• W GSC zbadaj sekcję „Targeting geograficzny” i „Lokalizacja” po migracji.

1. Względne zmiany adresów w mediach i linkach zewnętrznych

Po migracji zadbaj o poprawienie odnośników zewnętrznych (jeśli to możliwe):

• Skontaktuj się z autorami stron, które linkują do Twoich kluczowych stron, i poproś o aktualizację linków (by kierowały do nowych URL).
• W przypadku kampanii PPC, social media, katalogów — zaktualizuj adresy.
• W plikach sitemap lub RSS wyślij nowe linki, by przyśpieszyć indeksację.
• Dla adresów, które pozostały stare (ze względu na SEO lub historię) — w razie potrzeby zostaw przekierowania.

1. Uwaga na parametry i duplicate content

Często spotykanym problemem są parametry w URL (filtry, sortowanie, paginacja). Podczas migracji:

• Ustal, które parametry są istotne, a które można ignorować (np. ?sort=price-asc, ?page=2).
• W pliku robots.txt lub w Google Search Console (parametry URL) ustaw reguły ignorowania nieistotnych parametrów.
• Używaj canonicali, by wskazać oryginalną wersję strony, gdy generujesz paginację czy filtrowanie.
• Pilnuj, by nie powstawały nowe wersje tych samych treści z różnymi kombinacjami parametrów (duplicated content).

1. Uwzględnienie treści dynamicznych, AJAX, infinite scroll

Jeśli Twoja witryna korzysta z dynamicznego ładowania treści (AJAX, infinite scroll, lazy loading):

• Upewnij się, że treść krytyczna jest dostępna dla robotów (np. w kodzie HTML lub w progresywnym rendereringu).
• Dodaj fallbacki (np. paginacje, klasyczne linki) dla robotów, jeśli dynamiczne ładowanie ukrywa zasoby.
• Sprawdź, czy lazy loading obrazów obsługuje atrybuty loading=”lazy” i czy elementy mają atrybuty alt.
• Jeśli stosujesz prerendering lub serwerowe renderowanie (SSR), kontroluj, czy części dynamiczne są prawidłowo renderowane dla robotów.

Etap IV: Po migracji — utrzymanie, optymalizacja i korekty

11. Faza stabilizacji (pierwsze tygodnie / miesiące)

Po migracji:

• Obserwuj trendy pozycji fraz, ruchu organicznego, błędów w Search Console.
• W pierwszym miesiącu zmiany i optymalizacje wprowadzaj bardzo ostrożnie — każda większa zmiana może zaburzyć działanie migracji.
• Regularnie (np. co tydzień) przeglądaj logi, błędy 404 i przekierowania.
• Sprawdzaj mapę strony, upewnij się, że wszystkie kluczowe strony są zgłoszone i indeksowane.
• Powoli odblokowuj zmiany UX, redesign elementów, ulepszenia layoutu i nowe sekcje.

12. Audyt porównawczy: stara vs nowa wersja

W miarę stabilności:

• Porównaj stare i nowe wartości KPI (ruch organiczny, pozycje, współczynniki konwersji).
• Zrób analizę porównawczą podstron, które straciły najwięcej — może tam są błędy (złe przekierowania, usunięte treści, niepoprawne canonicale).
• Sprawdź, które strony mają największy potencjał wzrostu i zoptymalizuj je (np. ulepsz opisy, dodaj linki wewnętrzne).

13. Ciągłe optymalizacje i rozwój

Kiedy nowa wersja jest dobrze zaindeksowana i stabilna:

• Wprowadzaj SEO w warstwie optymalizacji (np. lepsze nagłówki, rozszerzenia treści, prędkość ładowania).
• Rozbudowuj blog, sekcje poradnikowe, content marketing — z większym naciskiem na nowe frazy.
• Monitoruj zmiany algorytmów wyszukiwarek i dostosowuj praktyki SEO.
• Rozważ testy A/B w UI/UX, by zobaczyć, które elementy wpływają na czas spędzony na stronie lub współczynnik konwersji.

Przykładowy scenariusz migracji krok po kroku (case study w skrócie)

1. Audyt obecnej witryny: zidentyfikowano 12 000 adresów URL, z czego 8 000 zaindeksowanych, 4 000 generujących duży ruch.
2. Zdefiniowanie zakresu migracji: migracja platformy + redesign + uproszczenie struktury URL.
3. Mapowanie URL i plan przekierowań: stworzono arkusz z parami stary→nowy adres.
4. Staging: wykonano pełną migrację na serwerze testowym, testowano przekierowania, błędy, dane strukturalne, canonicale.
5. Soft launch: 10 % ruchu skierowano na nową wersję, monitorowano błędy i KPI.
6. Go Live: cały ruch przekierowano na nową wersję, przekierowania 301 zostały aktywowane.
7. Monitoring: przez pierwsze 14 dni codziennie analizowano GSC, logi i ruch.
8. Optymalizacje: po miesiącu wprowadzono niewielkie zmiany SEO, po trzech miesiącach wdrożono redesign bloków treści.
9. Rezultat: początkowy spadek ruchu organicznego o ~5 % (normalny efekt migracji), do kolejnego miesiąca nastąpił powrót do poziomów sprzed migracji, a po pół roku — wzrost o 15 % dzięki optymalizacjom i lepszej wydajności.

Typowe błędy migracji SEO i jak ich unikać

Poniżej lista najczęstszych potknięć i wskazówki, jak ich unikać:

Wnioski i najlepsze praktyki (podsumowanie kluczowych rekomendacji)

1. Migracja 1:1 jest złotym standardem — jeśli możesz odwzorować strukturę starej strony (URL, menu, nagłówki, linkowanie) bez zmian — to zazwyczaj najbezpieczniejsza metoda.
2. Plan i testy są Twoim ratunkiem — każda migracja powinna być traktowana jak projekt techniczny: planuj, testuj, analizuj.
3. Przekierowania 301 to fundament migracji — każda stara strona musi mieć odpowiedni przekierowany adres lub być obsłużona.
4. Monitoring i analityka to podstawa — rozpadający się ruch lub błędy muszą być wykryte jak najwcześniej.
5. Zmiany optymalizacyjne wprowadzaj ostrożnie i etapami — unikaj wielkich zmian tuż po migracji.
6. Dane strukturalne, hreflangi, canonicale, dynamiczne treści — nie zapomnij o nich — nawet najlepsza migracja bez uwzględnienia tych elementów może się nie powieść.
7. Utrzymanie, analiza i korekty po migracji są tak samo ważne jak sama migracja — migracja to nie jednorazowy akt, lecz proces adaptacji i optymalizacji przez kolejne miesiące.