Kodaic.
Blog

·9 min czytania

Migracja z WordPressa na Next.js bez utraty pozycji w Google

Najczęstsza obawa przed zmianą technologii brzmi: „stracę to, co wypracowałem w Google”. To uzasadniony strach, ale skierowany pod niewłaściwy adres. Google nie ocenia, w czym napisana jest strona. Ocenia adresy, treść, linki i szybkość. Migracja psuje pozycje dokładnie wtedy, gdy któraś z tych czterech rzeczy zmieni się po cichu.

Krok 1: zinwentaryzuj to, co masz, zanim cokolwiek ruszysz

To najważniejszy i najczęściej pomijany etap. Zanim powstanie pierwsza linijka nowego kodu, potrzebujesz pełnej listy tego, co istnieje dzisiaj:

  • Wszystkie adresy URL z sitemapy i z Google Search Console, łącznie z tymi, o których zapomniałeś.
  • Które podstrony przynoszą ruch. Zwykle 20% adresów odpowiada za 80% wejść i to one są nietykalne.
  • Tytuły i opisy meta każdej podstrony w obecnym brzmieniu.
  • Skąd prowadzą linki zewnętrzne. Każdy taki link wskazuje konkretny adres, który musi dalej działać.
  • Dane strukturalne, jeśli masz: opinie, FAQ, dane firmy, produkty.

Ten spis jest później Twoją listą odbiorczą. Bez niego migrację odbierasz „na oko”, a braki wychodzą dopiero, gdy ruch spada.

Krok 2: adresy zostają takie same. Kropka

Domyślną zasadą migracji jest zachowanie struktury adresów jeden do jednego. Jeśli dzisiaj masz /uslugi/naprawa-lakieru/, jutro też masz /uslugi/naprawa-lakieru/. Zmiana adresów to osobny projekt, którego nie robi się przy okazji zmiany technologii.

Uwaga na drobiazg, który wywraca migracje: końcowy ukośnik. Jeśli WordPress serwował adresy z ukośnikiem na końcu, a nowa strona serwuje bez, dla wyszukiwarki jest to inny adres. To samo dotyczy wielkich liter i wersji z www oraz bez.

Krok 3: przekierowania 301 dla wszystkiego, co się zmienia

Jeśli jakiegoś adresu nie da się zachować, musi prowadzić przekierowaniem stałym (301) do najbliższego odpowiednika. Nie do strony głównej. Masowe przekierowanie wszystkiego na stronę główną Google traktuje jak błąd 404 i pozycje po prostu znikają.

W Next.js przekierowania definiuje się w konfiguracji projektu, więc są częścią kodu i wersjonują się razem z nim. To wygodniejsze niż wtyczka, w której ktoś kiedyś wpisał regułę i nikt nie pamięta, dlaczego.

Krok 4: przenieś warstwę SEO, nie tylko teksty

  • Tytuły i opisy meta w dotychczasowym brzmieniu. Jeśli chcesz je poprawić, zrób to miesiąc po migracji, żeby wiedzieć, co spowodowało zmianę wyników.
  • Nagłówki H1 i hierarchia H2/H3 na każdej podstronie.
  • Teksty alternatywne obrazków.
  • Adresy kanoniczne i, przy wielu wersjach językowych, hreflang.
  • Dane strukturalne: dane firmy, FAQ, opinie, okruszki nawigacyjne.
  • robots.txt i sitemap.xml pod tymi samymi adresami co wcześniej.

Krok 5: testuj na środowisku zamkniętym dla robotów

Nowa wersja przed startem powinna być niewidoczna dla wyszukiwarek, inaczej Google zindeksuje adres testowy i sam sobie zrobi duplikat treści. W dniu przełączenia blokada znika. To brzmi banalnie, a jest jednym z częstszych powodów, dla których po migracji strona konkuruje sama ze sobą.

Krok 6: pierwsze 48 godzin po przełączeniu

  1. 1Prześlij nową sitemapę w Google Search Console i poproś o indeksację najważniejszych podstron.
  2. 2Sprawdź raport „Strony” w Search Console pod kątem nagłego skoku błędów 404.
  3. 3Przeklikaj listę najważniejszych adresów z kroku 1 i potwierdź, że każdy zwraca kod 200 albo poprawne 301.
  4. 4Zweryfikuj dane strukturalne testem wyników z elementami rozszerzonymi.
  5. 5Upewnij się, że analityka i piksele reklamowe zbierają dane, bo o tym przypomina się zwykle po tygodniu.

Pięć błędów, które realnie kosztują pozycje

  1. 1Zostawiona blokada indeksowania ze środowiska testowego. Strona znika z Google w kilka dni, a przyczyna to jedna linijka.
  2. 2Przekierowanie wszystkich starych adresów na stronę główną zamiast na odpowiedniki.
  3. 3Zmiana adresów „przy okazji”, bo nowe wyglądają ładniej.
  4. 4Skrócenie treści. Nowa strona wygląda lepiej, ale ma o połowę mniej tekstu, więc traci frazy, na które się wyświetlała.
  5. 5Zapomniane podstrony, o których nikt nie pamiętał, a które przynosiły ruch z długiego ogona.

Czego się spodziewać po migracji

Nawet przy poprawnie przeprowadzonej migracji przez pierwsze 2-4 tygodnie widać wahania. Google musi ponownie przeskanować stronę i przeliczyć sygnały. Jeśli po miesiącu ruch nie wrócił do poziomu sprzed zmiany, to nie jest naturalne wahanie, tylko coś do naprawienia, i wtedy wracasz do listy z kroku 1.

Dobrze zrobiona migracja jest niewidoczna dla Google i odczuwalna dla użytkownika.

Najczęstsze pytania

Czy migracja z WordPressa na Next.js obniża pozycje w Google?
Poprawnie przeprowadzona migracja nie obniża pozycji. Przez 2-4 tygodnie widać naturalne wahania, po czym wyniki wracają, a często rosną dzięki lepszym Core Web Vitals. Spadki wynikają z błędów wdrożenia: zostawionej blokady indeksowania, braku przekierowań 301 albo skrócenia treści.
Ile trwa migracja strony na Next.js?
Dla strony do 10 podstron zwykle 2-3 tygodnie, dla serwisu z kilkudziesięcioma podstronami 4-6 tygodni. Największą częścią pracy nie jest kod, tylko inwentaryzacja adresów i przeniesienie treści bez gubienia szczegółów.
Czy muszę zmieniać hosting przy migracji?
Tak, ale zwykle na tańszy. Strona w Next.js działa na Vercelu, który przy typowym ruchu firmowej witryny mieści się w darmowym planie. Domena zostaje ta sama, zmieniasz tylko rekordy DNS.
Co się dzieje ze starymi wpisami na blogu?
Przenosi się je razem z treścią i pod tymi samymi adresami. To zwykle najcenniejsza część strony pod kątem długiego ogona wyszukiwań, więc usuwanie starych wpisów przy migracji jest jednym z droższych błędów.