Migracja z Wix na WordPress - jak przenieść stronę krok po kroku i zachować pozycje w Google?

Migracja z Wix na WordPress różni się od zwykłego przeniesienia strony między dwoma systemami. Wix działa w zamkniętym ekosystemie, dlatego nie da się po prostu wyeksportować motywu, kodu czy używanych aplikacji. W praktyce przenosisz treści, adresy URL, meta dane, obrazy oraz logikę działania serwisu, a sam wygląd i funkcje budujesz od nowa już w WordPressie.

Poniżej znajdziesz cały proces na przykładzie firmowej strony z rozbudowaną strukturą, podstronami lokalnymi oraz blogiem liczącym ponad 150 wpisów. Najważniejsze było zachowanie widoczności w Google i uniknięcie spadków ruchu. Nowa strona nie jest kopią starej. Wygląd powstał od zera i jest lepszy, doszły nowe funkcje, a bez zmian zostały treść, adresy i pozycje w wyszukiwarce. Sama procedura jest przy tym identyczna niezależnie od tego, czy odtwarzasz stary wygląd, czy budujesz nowy. Przy wiernej kopii trzymasz się po prostu dotychczasowych wytycznych wizualnych, a kroki techniczne są te same.

Strona na Wixie i po przebudowie na WordPressie: nowy wygląd, ta sama treść i adresy

Co można przenieść z Wix na WordPress, a czego nie?

Nie wszystkie elementy strony da się przenieść z Wix na WordPress w gotowej formie. Treść, adresy, obrazy i metadane można zachować, natomiast wygląd, formularze oraz aplikacje Wixa trzeba odtworzyć na nowo. Ma to jednak swoją zaletę: nowa strona może zyskać lepszy wygląd i funkcje, których wcześniej brakowało.

Element strony	Czy przejdzie automatycznie?	Jak go przenieść?
Wpisy blogowe	częściowo	RSS, wtyczka migracyjna, a następnie ręczne poprawki
Strony statyczne	nie	pobranie treści i odtworzenie podstron w WordPressie
Wygląd i szablon	nie	nowy motyw, builder lub motyw tworzony indywidualnie
Obrazy	częściowo	pobranie i wgranie do biblioteki mediów
Meta title i description	zazwyczaj nie	zebranie ze starej strony i import do wtyczki SEO
Menu i stopka	nie	odtworzenie w panelu lub bezpośrednio w motywie
Formularze	nie	konfiguracja nowej wtyczki i odtworzenie pól
Sklep, rezerwacje i aplikacje Wix	nie	osobna konfiguracja odpowiednich rozwiązań
Struktura URL	tak, po zaplanowaniu	zachowanie identycznych slugów lub przekierowania 301

Aplikacje Wixa (Bookings, Stores, Events) najlepiej traktować jak oddzielne wdrożenia. Na WordPressie stawia się ich odpowiedniki i konfiguruje od zera.

Metody migracji: którą wybrać?

Są cztery drogi, zależnie od wielkości strony:

• Wtyczki automatyczne (CMS2CMS, FG Wix to WordPress) – najszybsze, ale przy większych stronach płatne i zostawiają błędy do ręcznej poprawki.
• Import bloga przez RSS (/blog-feed.xml lub /feed.xml) – przenosi tylko wpisy i część obrazów, resztę trzeba zrobić ręcznie.
• Odbudowa w builderze, takim jak Elementor lub Bricks, będzie wygodna dla osób przyzwyczajonych do wizualnej edycji w Wixie.
• Własny motyw (HTML, CSS, JS + pola edytowalne w panelu) – najwięcej pracy, za to pełna kontrola nad kodem, wydajnością i SEO. Tę drogę wybrano w opisywanym projekcie.

Mały blog ogarnie sam RSS. Rozbudowany serwis z rezerwacjami, sklepem i podstronami lokalnymi zwykle łączy kilka metod.

Wybrana ścieżka: własny motyw i pola ACF

W opisywanym projekcie wybór padł na własny motyw połączony z polami ACF. Dzięki temu treść trafia do uporządkowanych pól w panelu, natomiast motyw odpowiada za sposób wyświetlania konkretnych sekcji.

Hero, zakres usług, FAQ, galerie, bloki tekstowe i inne elementy można edytować bez ingerowania w kod. Jednocześnie użytkownik nie rozwala przypadkowo całego układu podstrony, ponieważ pozostaje on zapisany w motywie.

Takie podejście szczególnie dobrze sprawdza się przy stronach lokalnych, gdzie jeden szablon obsługuje wiele miast bez budowania każdej podstrony od zera.

Panel edycji strony usługi w WordPressie z polami ACF

Krok 1: inwentaryzacja strony na Wix

Pierwszym etapem powinno być stworzenie pełnej listy adresów dostępnych na starej stronie. Bez takiej mapy łatwo pominąć ważną podstronę, stracić meta dane albo zapomnieć o przekierowaniu adresu, który generował ruch lub posiadał wartościowe linki zewnętrzne.

Crawl wykonany w Screaming Frog pozwala zebrać adresy URL, typy podstron, tytuły, meta description, statusy odpowiedzi oraz linki wewnętrzne. Wyeksportowane dane warto przenieść do arkusza, który stanie się później główną mapą migracji i przekierowań 301.

Do każdego adresu należy dopisać jego typ, na przykład:

• strona usługi,
• podstrona miasta,
• artykuł blogowy,
• strona kontaktowa,
• podstrona informacyjna.

W tym samym arkuszu dobrze jest również oznaczyć ruch organiczny, liczbę linków zewnętrznych, planowany nowy adres i status migracji. Warto też przygotować zrzuty ekranu wszystkich unikalnych typów podstron. Przydadzą się później podczas odtwarzania layoutu i kontroli kompletności nowej wersji serwisu.

Arkusz z mapą adresów z crawla: stary URL z Wixa, nowy URL w WordPressie, typ strony i status przekierowania

Meta title i meta description trzeba zebrać jeszcze przed migracją. W opisywanym projekcie po przeniesieniu aż 238 z 263 adresów miało puste pola. Dane ze starej strony trzeba było odzyskać dodatkowym skryptem, ponieważ nie przeszły razem z treścią.

Krok 2: pobranie treści 1:1

Wix nie udostępnia pełnego eksportu wszystkich treści strony w wygodnym formacie. Poszczególne podstrony można jednak pobierać przy użyciu narzędzi takich jak Jina Reader, które zwracają zawartość w uporządkowanym Markdownie.

W ten sposób można przejść przez strony usług, treści informacyjne oraz rozbudowany blog. W opisywanym projekcie do przeniesienia było ponad 150 wpisów. Obrazy pobiera się osobno na podstawie adresów znajdujących się w kodzie źródłowym.

Na tym etapie najważniejsza jest jedna zasada: najpierw przenieś treść możliwie wiernie, a poprawki zostaw na później. Jeżeli naraz zmienisz system, strukturę, teksty i adresy, a ruch spadnie, nie będzie wiadomo, co go zbiło: technika, treść czy linkowanie.

Przy blogu warto stworzyć dokładne mapowanie między wpisami i przypisanymi do nich grafikami. Bez tego podczas masowego importu łatwo pomieszać zdjęcia wyróżniające oraz obrazy umieszczone wewnątrz artykułów.

Krok 3: budowa motywu i porządkowanie treści

Na podstawie wcześniej wykonanych zrzutów ekranu można rozpocząć budowę nagłówka, stopki, strony głównej, szablonów usług, bloga, kontaktu i podstron informacyjnych. Zrzuty są punktem odniesienia dla treści i układu informacji, ale sam wygląd projektuje się od nowa i lepiej niż na starej stronie.

Treść pobrana z Wixa zazwyczaj nie jest od razu gotowa do importu. Może zawierać komunikaty platformy, informacje o plikach cookies, powtórzone menu, fragmenty stopki, zdublowane sekcje oraz elementy znajdujące się w niewłaściwej kolejności.

Dlatego surowy materiał trzeba najpierw uporządkować. Parser rozdziela go na akapit wprowadzający, sekcje, listy i FAQ, i dopiero wtedy treść trafia do odpowiednich pól ACF.

Ta sama podstrona usługi: wersja na Wixie i przebudowana we własnym motywie WordPressa

Krok 4: tworzenie stron lokalnych z jednego szablonu

Przy większej liczbie lokalizacji ręczne budowanie każdej podstrony miasta szybko przestaje mieć sens. Jeżeli wszystkie strony mają podobną strukturę, znacznie lepiej przygotować jeden szablon i zestaw pól ACF.

W opisywanym projekcie adresy były budowane według schematu /oddzialy/usluga-miasto/, a pozycjonowane frazy opierały się na połączeniu nazwy usługi z nazwą miasta.

Dodanie kolejnej lokalizacji wygląda tak:

1. Powstaje nowa strona jako podstrona sekcji oddziałów.
2. W atrybutach wybiera się szablon „Strona miasta”.
3. Uzupełnia się hero, treść lokalną, zakres usług i FAQ.
4. Szablon pobiera nazwę miasta z tytułu i na tej podstawie renderuje odpowiednie elementy podstrony.

Dzięki temu nie trzeba za każdym razem układać wszystkich sekcji od początku. Zmieniają się głównie dane lokalne, nagłówek, adres i treść, natomiast układ pozostaje spójny.

Dwie strony miast wygenerowane z tego samego szablonu: zmienia się nazwa miasta w H1, adresie i treści lokalnej

Automatyzacja stron lokalnych wymaga jednak ostrożności. Polskie znaki, odmiana nazw miejscowości oraz nietypowe formy językowe mogą powodować błędy. Przy generowaniu slugów konieczna była transliteracja polskich znaków, a niektóre nazwy wymagały dodatkowej obsługi.

Krok 5: obrazy i pozostałe media

Po migracji obrazy nie powinny pozostawać na serwerach Wixa. Jeżeli w kodzie nowej strony nadal znajdują się odwołania do domeny static.wixstatic.com, witryna pozostaje zależna od starej platformy.

Na początku zdjęcia działają, bo stare konto wciąż żyje. Po jego zamknięciu grafiki znikną z artykułów i podstron, mimo że strona stoi już na WordPressie.

Proces przenoszenia mediów powinien obejmować:

1. pobranie wszystkich obrazów ze starej strony,
2. wgranie ich do biblioteki mediów WordPressa,
3. uzupełnienie nazw, tytułów i tekstów alternatywnych,
4. podmianę wszystkich starych adresów w treści,
5. ponowny crawl i wyszukanie odwołań do static.wixstatic.com.

Samo wgranie plików nie wystarczy. Trzeba się upewnić, że wpisy, galerie i zdjęcia wyróżniające korzystają z nowych adresów.

Krok 6: odzyskanie meta title i description

Po zakończeniu importu warto od razu sprawdzić pokrycie meta danych w całym serwisie. Nie należy ograniczać się do kilku losowo wybranych podstron, ponieważ problem może dotyczyć całej grupy adresów albo jednego szablonu.

W opisywanej migracji spośród 263 stron tylko 25 miało kompletne meta title i description. Po odzyskaniu i zaimportowaniu danych komplet posiadało już 258 adresów. Pozostałe strony miały charakter techniczny albo były przeznaczone do usunięcia.

Naprawa polegała na pobraniu title i description ze starej wersji serwisu, dopasowaniu ich do nowych adresów na podstawie slugów, a następnie zaimportowaniu do pól używanych przez wtyczkę SEO.

Dodatkowego mapowania wymagał blog. Wix trzymał w części adresów polskie znaki, a WordPress robił transliterację, więc proste porównanie adresów nie zawsze wystarczało do dopasowania wpisów.

Krok 7: poprawa linkowania wewnętrznego

Po przeniesieniu treści w artykułach i podstronach często pozostają stare linki. Mogą to być na przykład adresy blogowe zawierające /post/, które po zmianie struktury WordPressa zaczynają prowadzić do błędu 404.

Przy kilkunastu linkach można poprawić je ręcznie. Przy setkach wpisów i odnośników znacznie rozsądniej jest przygotować skrypt, który podmieni stare adresy na nowe na podstawie wcześniej opracowanej mapy URL-i.

Kontrolą należy objąć nie tylko główną treść. Stare odnośniki mogą znajdować się również w menu, stopce, sekcjach „zobacz też”, modułach z polecanymi artykułami, przyciskach i polach ACF.

Po podmianie uruchom crawl i wyeksportuj linki prowadzące do 404. Wyłapiesz tak pominięte adresy i literówki z importu.

Krok 8: przygotowanie przekierowań 301

Przekierowania 301 powinny powstać na podstawie arkusza przygotowanego już podczas inwentaryzacji. Każdy stary adres musi mieć jasno określony los.

Jeżeli slug i pełny adres pozostają bez zmian, dodatkowe przekierowanie nie jest potrzebne. Jeżeli struktura URL się zmienia, stary adres powinien prowadzić do możliwie najbardziej zbliżonego odpowiednika na nowej stronie.

Przeczytaj także: Jak tworzyć przyjazne adresy URL w linkach SEO?

Najbezpieczniejsza kolejność pracy wygląda tak:

• umieszczenie starego i nowego adresu w jednym arkuszu,
• nadanie priorytetu podstronom generującym ruch i posiadającym backlinki,
• zachowanie identycznych slugów wszędzie tam, gdzie jest to możliwe,
• ustawienie przekierowania 301 dla każdego zmienionego adresu,
• pozostawienie 404 lub zastosowanie 410 dla stron bez odpowiednika,
• wygenerowanie nowej mapy XML i zgłoszenie jej w Google Search Console,
• monitorowanie błędów, indeksacji i kliknięć po uruchomieniu nowej strony.

Nie warto przekierowywać wszystkich usuniętych podstron na stronę główną. Takie działanie nie rozwiązuje problemu, ponieważ adresy nie prowadzą do treści odpowiadającej wcześniejszej zawartości. W wielu przypadkach Google potraktuje je jak miękkie 404 (soft 404), a sygnały zgromadzone przez stare podstrony nie zostaną prawidłowo przeniesione.

Krok 9: testy i przepięcie domeny

Nowa wersja strony powinna działać na środowisku testowym, podczas gdy dotychczasowy serwis na Wix pozostaje aktywny aż do dnia uruchomienia. Pozwala to spokojnie porównać obie wersje i wykryć błędy bez wpływu na użytkowników oraz widoczność w wyszukiwarce.

Przed przepięciem domeny warto porównać kluczowe podstrony ze zrzutami ekranu, sprawdzić wersję mobilną, formularze, meta dane, obrazy, linki wewnętrzne, przekierowania i mapę XML.

Crawl nowej strony powinien przejść bez błędów 404, nieprawidłowych przekierowań i odwołań do zasobów Wixa. Sprawdź też, czy środowisko testowe nie blokuje elementów potrzebnych po starcie oraz czy po uruchomieniu zostanie wyłączona ewentualna blokada indeksowania.

Dopiero po wykonaniu testów można skierować domenę na nowy hosting, uruchomić certyfikat SSL i zgłosić nową mapę witryny w Google Search Console.