Naprawa problemów SEO po migracji WordPressa: zacznij od prawdy o adresach URL

TL;DR: Twoja migracja WordPressa prawdopodobnie nie „zabiła SEO”. Przerwała ciągłość między starymi a nowymi adresami URL, przekierowaniami, canonicalami, mapami witryny, linkami wewnętrznymi i – od niedawna – cytowaniami AI. Naprawę zaczyna się więc od ustalenia prawdy o URL-ach, a nie od kolejnego audytu wtyczek.

To nie migracja zabiła Twoje SEO, lecz rozbita historia URL-i.

Większość osób diagnozuje wordpress migration seo od złej strony. Pytają, czy winny jest WordPress, nowy motyw, hosting czy wtyczka SEO. Czasem rzeczywiście któraś z tych rzeczy maczała palce, najczęściej dlatego, że przerwała ciągłość adresów URL.

W mindnow widziałem migracje WordPressa, w których treść była bez zarzutu, a pozycje i tak spadały, bo 600 starych adresów URL po cichu przekierowano na stronę główną. Teraz sprawdzam to, zanim zajrzę w cokolwiek na seojuice.io czy vadimkravcenko.com.

Najszybsze wygrane są zwykle nudne: stary URL, nowy URL, kod statusu, canonical, indeksowalność, obecność w sitemapie oraz linki wewnętrzne. Właśnie w takiej kolejności — nie tytuły, nie schema, nie Core Web Vitals.

Joost de Valk, założyciel Yoast SEO, stwierdził, że udana migracja domeny to „mniej więcej 90 % przygotowania i 10 % wykonania”. Ta uwaga przydaje się również po nieudanym wdrożeniu. Jeśli przygotowanie nie nastąpiło przed przełączeniem, prace naprawcze są niczym innym jak spóźnionym przygotowaniem.

Naszym zadaniem jest udowodnić, że Google wciąż potrafi połączyć stare zapytania z nowymi adresami. Jeśli nie potrafi, przepisywanie treści to teatr.

Najpierw sklasyfikuj spadek, zanim cokolwiek zaczniesz naprawiać

Nie każdy spadek ruchu po migracji ma tę samą przyczynę. Zmiana hostingu, domeny, permalinków, przebudowa motywu, import z CMS-a czy podmiana wtyczki SEO – wszystko to może wygenerować ten sam wykres: sesje organiczne w dół, nerwy w górę.

Pierwsze rozgałęzienie diagnostyczne jest proste. Czy Google zgubił URL, nie ufa nowemu URL-owi, czy błędnie zrozumiał relację między nimi?

Nie przepisuj treści, dopóki nie będziesz pewny, że Google może dotrzeć do nowego URL-a, zrozumieć go i mu zaufać. Artykuł z tagiem noindex nie potrzebuje lepszego nagłówka. Kategoria produktu skanonikalizowana do starej domeny nie potrzebuje dodatkowego tekstu. Strona docelowa przekierowana na homepage nie potrzebuje znaczników schema.

Najpierw klasyfikuj. Potem naprawiaj.

Odtwórz mapę URL-i, nawet jeśli migracja już się odbyła

John Mueller ujął to najprościej podczas Google SEO Office Hours, co opisał Search Engine Journal:

„Uważam, że najważniejsze jest naprawdę śledzenie poszczególnych URL-i, aby mieć jasną mapę tego, co było wcześniej i co powinno być w przyszłości”.

W WordPressie „pojedyncze URL-e” to nie tylko wpisy i strony. CMS tworzy powierzchnie przez motywy, wtyczki, archiwa, zachowanie mediów, filtry i stare fallbacki permalinków. Jeśli przenieśliście wyłącznie widoczną strukturę menu, prawdopodobnie pominęliście połowę serwisu.

Powierzchnie URL w WordPressie, o których się zapomina

• Wpisy i strony
• Adresy produktów WooCommerce, kategorie produktów oraz baza /shop
• Kategorie, tagi i własne taksonomie
• Archiwa autorów
• Archiwa dat, jeśli były indeksowalne
• Strony załączników i URL-e multimediów
• Archiwa niestandardowych typów wpisów
• Paginowane archiwa
• Adresy feedów
• Stare fallbacki permalinków ?p=123 (tak, w starszych instalacjach wciąż działają)
• Warianty z i bez końcowego ukośnika
• Wersje HTTP i HTTPS
• Wersje www i bez www
• Stare adresy stagingowe lub tymczasowe hosty, które wyciekły

Zacznij od dowodów, nie od pamięci. Wyeksportuj strony wejścia z analityki. Wyeksportuj najlepsze strony z Google Search Console. Przeskanuj aktualny serwis. Sięgnij po przedmigracyjny crawl, jeśli go masz. Dodaj URL-e z backlinków z własnego indeksu linków. Połącz wszystko w jedną mapę stary→nowy.

Tak, to ta nudna część w Excelu — właśnie tu zaczynają się prawie wszystkie odzyski (audyty, które ratowałem w mindnow, zawsze wracały do brakującej kolumny w czyimś wcześniejszym arkuszu). Użyj kolumn: stary URL, nowy URL, status HTTP, docelowe przekierowanie, docelowy canonical, indeksowalność, obecność w sitemapie, uwagi. Jeśli brak równoważnej strony, zapisz to wprost. Nie ukrywaj za przekierowaniem na homepage.

W większych serwisach priorytet daj URL-om z backlinkami, przychodami, kliknięciami organicznymi, konwersjami lub cytowaniami AI. Martwe archiwum tagu z 2017 roku może poczekać. Kategoria produktu, która napędzała sprzedaż non-brand, nie może.

Napraw przekierowania, zanim ruszysz tytuły, treść czy schemę

Oficjalna dokumentacja Google dotycząca przenosin witryny mówi:

„Utrzymuj przekierowania tak długo, jak to możliwe, zazwyczaj co najmniej 1 rok.”

To zdanie powinno wisieć nad każdą checklistą migracji WordPressa. Przekierowania znikają w banalny sposób. Ktoś usuwa blok .htaccess. Wtyczka przekierowań zostaje wyłączona przy porządkach. Migracja hostingu gubi reguły Nginx. Reguły Cloudflare są nadpisywane. Stara domena wygasa. Domenę stagingową się kasuje. Nikt nie zauważa, dopóki Search Console nie wygląda jak miejsce zbrodni.

Przekierowanie ma sens tylko wtedy, gdy strona docelowa realizuje tę samą intencję. Stary wpis blogowy → nowy wpis. Stary produkt → równoważny produkt. Stara kategoria → odpowiednia nowa kategoria. Stara usługa → najbliższa żyjąca usługa. Jeśli cel jest nieadekwatny, samo techniczne 301 nie uratuje wartości SEO.

Potrzebujesz procesu? Skorzystaj z tego:

1. Przeskanuj listę starych URL-i i zapisz każdy kod statusu.
2. Oznacz każdą łańcuchową 3xx dłuższą niż jeden przeskok.
3. Oznacz każdy stary URL kończący na stronie głównej.
4. Sprawdź, czy strona docelowa jest indeksowalna.
5. Potwierdź, że finalna strona canonicalizuje do siebie lub zamierzonego canonicalu.
6. Przenieś przekierowania o wysokiej wartości z kruchej warstwy wtyczek do reguł serwera lub edge, jeśli to możliwe.

Jeśli używasz wtyczki, wyeksportuj jej reguły, zanim cokolwiek zmienisz. Redirection, Rank Math, Yoast Premium czy panele przekierowań na hostingu – wszystko może działać. Problemem bywa własność. Nikt nie wie, która warstwa jest źródłowa.

Przekierowanie na homepage to nie siatka bezpieczeństwa

Dokumentacja Google ostrzega przed przekierowaniem wielu starych URL-i na jedno niepowiązane miejsce, np. stronę główną, bo może to zostać potraktowane jako soft 404. W WordPressie to częsty błąd. Administrator widzi setki 404 w wtyczce i ustawia globalny fallback na /. Panel wygląda schludniej — ruch z wyszukiwarki spada.

Naprawa jest wolniejsza, ale bezpieczniejsza. Mapuj stare URL-e na najbliższy odpowiednik. Gdy odpowiednika brak, zwróć prawdziwe 404 lub 410. Pozwól martwym URL-om umrzeć uczciwie. Chroń ważne strony przekierowaniami 1-do-1.

To szczególnie boli przy migracjach e-commerce. Wycofany produkt może zasługiwać na przekierowanie do produktu zastępczego lub kategorii nadrzędnej. Usunięty produkt bez zamiennika – na 410. Usunięty produkt przekierowany na homepage nie uczy Google niczego.

Uważaj na 180-dniowe okno Change of Address

Narzędzie Change of Address w Search Console pomaga Google przetworzyć przeniesienie witryny, ale nie zastępuje przekierowań. Support Search Console wskazuje, że działania migracyjne trwają 180 dni od uruchomienia procesu (narzędzie przetwarza sygnały tak długo, nie bez końca).

Po tym okresie Google przestaje uważać starą i nową witrynę za powiązane, jeśli stara jest nadal dostępna i możliwa do crawlowania. Wniosek jest prosty: przekierowania muszą przetrwać dłużej niż okno Change of Address. Jeśli stary hosting wyłączyłeś w piątym miesiącu, zbudowałeś przepaść.

Sprawdź ustawienia WordPressa, które po cichu blokują odzysk

WordPress rzadko psuje pojedynczą stronę. Psuje szablony. Diagnozuj według typu strony, nie przez losowe próbkowanie URL-i.

Zacznij od oczywistego ustawienia, bo wciąż robi spustoszenie: Ustawienia → Czytanie → Zniechęcaj wyszukiwarki do indeksowania tej witryny. Na stagingu jest zazwyczaj włączone. Pośpieszne wdrożenie potrafi przenieść je na produkcję. Tak samo z regułami noindex z wtyczek SEO skopiowanymi ze stagingu.

Potem sprawdź canonicale. Przebudowa motywu czy import wtyczki może zostawić tagi canonical wskazujące starą domenę, tymczasowy host lub zły wariant językowy. Sprawdź wyrenderowany HTML, nie tylko pole wtyczki. Cache może podawać stare tagi, gdy ekran admina wygląda już na naprawiony.

Podobnie traktuj sitemapę. Wtyczki SEO WordPressa dzielą mapy po typie wpisu i taksonomii. Po migracji możesz mieć czyste URL-e wpisów w jednej mapie i kategorie ze starą domeną w innej. Prześlij indeks sitemap, a następnie otwórz podmapy ręcznie.

Robots.txt to kolejny cichy zabójca. Blokada /wp-content/ może uniemożliwić Google pobranie CSS, JS lub obrazów potrzebnych do zrozumienia strony. Zablokowanie ścieżki szablonu uderza w całe grupy. Zablokowanie całej witryny wciąż zdarza się po wdrożeniu stagingu. Widziałem to nie raz.

Permalinki są gorsze, bo wyglądają na decyzję treściową. Zmiana z /%postname%/ na /blog/%postname%/ bez przekierowań tworzy migrację URL-i w środku migracji. Modyfikacja baz kategorii, usuwanie końcowych ukośników czy zmiana baz produktów WooCommerce działa tak samo.

Sprawdź też kolejność reguł przekierowań, reguły CDN, output wtyczek wielojęzycznych, cele hreflang, URL-e filtrów WooCommerce, działanie stron załączników, paginację, breadcrumbs i archiwa własnych typów wpisów. Jeden wadliwy szablon potrafi zdusić setki URL-i.

Jeśli to brzmi jak checklista audytu technicznego SEO, bardzo dobrze. Odzysk po migracji to audyt techniczny z datą i listą podejrzanych.

Odzyskaj strony, które wypadły z indeksu Google

Wybierz jedną wartościową stronę, która straciła ruch. Nie dwadzieścia. Jedną.

Najpierw sprawdź stary URL. Czy zwraca 301? Czy tworzy łańcuch? Czy trafia na właściwy nowy URL? Czy strona docelowa ładuje się Googlebotowi? Potem zbadaj nowy URL. Potwierdź kod statusu, canonical, dyrektywy robots, wyrenderowany HTML, linki wewnętrzne, obecność w sitemapie i datę ostatniego crawlu.

Użyj narzędzia Inspekcja URL w Search Console dla wersji live, nie tylko zindeksowanej. Indeksowana pokazuje, co Google zapisał ostatnio. Test live pokazuje, co może pobrać teraz.

Następnie skaluj po szablonie. Jeśli jeden przeniesiony wpis blogowy ma zły canonical, mogą je mieć wszystkie. Jeśli jedna kategoria produktu jest noindex, może być tak ze wszystkimi. Jeśli jedno archiwum autora nagle jest indeksowalne, każde archiwum autora może znów tworzyć thin pages.

Walidacja w Search Console jest wolna (dni lub tygodnie, nie godziny). Lepszym wczesnym sygnałem jest zachowanie crawla. Sprawdź logi serwera, jeśli je masz. Czy żądania do przekierowanych starych URL-i nadal się pojawiają? Czy zapytania Googlebota docierają do celów? Czy liczba 404 spada dla kluczowych starych URL-i?

Pozycje zwykle wracają grupami. Jeśli naprawione kategorie produktów zaczynają być crawl-owane i wracają wyświetlenia, zastosuj tę samą poprawkę do reszty kategorii. Nie zmieniaj kolejnych, niepowiązanych rzeczy, gdy pierwsza naprawa jest w toku.

Cytowania AI dokładają dziś drugi problem migracyjny

Joost de Valk ujął nowy problem dosadnie:

„Nie ma formularza Change of Address dla modelu, który zakończył trening rok przed Twoją migracją.”

Google potrafi przejść po przekierowaniach. Search Console obsłuży przenosiny witryny. Modele LLM i silniki odpowiedzi AI mogą jednak wciąż nosić stare hosty albo URL-e w danych treningowych, indeksach wyszukiwania, indeksach partnerów czy warstwach cache’owanych cytatów. Czyste 301 pomaga Google, ale nie nadpisze każdej starej wzmianki gdzieś w sieci.

Tu nie ma magii. Utrzymuj przekierowania. Niech stare URL-e prowadzą do najlepszych nowych odpowiedników. Aktualizuj profile o wysokim autorytecie, kanoniczne strony źródłowe, schemę organizacji, referencje sameAs, mapy XML i linki wewnętrzne. Gdzie to możliwe, odśwież cytowania w platformach, które systemy AI często zasilają.

To ma większe znaczenie dla WordPressa, niż wielu przyznaje (sam myliłem się tu latami). Wiele migracji polega na wtyczkach lub regułach hosta, które po trzech miesiącach się usuwa. Jeśli cytowania AI nadal wskazują stare URL-e, przekierowania są mostem. Zniszcz most, a wzmianka staje się ślepą uliczką.

Dla powiązanych porządków przeczytaj poradniki SEOJuice o łańcuchach przekierowań i 301, najlepszych praktykach map XML oraz błędach tagu canonical.

14-dniowy plan naprawy SEO po migracji WordPressa

Da się odratować chaotyczną migrację, nie naprawiając wszystkiego naraz. Kolejność liczy się bardziej niż zestaw narzędzi.

Dzień 0-1: zatamuj krwawienie

• Potwierdź własność starej domeny, hostingu, DNS, CDN i usług Search Console.
• Przywróć kontrolę nad przekierowaniami przed edycją treści.
• Wyłącz przekierowania zbiorcze na homepage.
• Usuń przypadkowe tagi noindex i blokady robots.
• Wyślij czysty indeks mapy witryny dla nowej strony.
• Ręcznie przetestuj próbkę starych, wartościowych URL-i.

Jeśli nie kontrolujesz już starej domeny, odzysk szybko robi się trudny. Odzyskaj kontrolę, zanim zaczniesz dyskusję o tagach tytułowych.

Dzień 2-4: odbuduj mapę

• Stwórz tabelę stary → nowy URL.
• Priorytetyzuj URL-e z backlinkami, kliknięciami organicznymi, przychodem, konwersjami i cytowaniami AI.
• Rozdziel URL-e według typu: wpisy, strony, produkty, kategorie, tagi, media, archiwa, feedy.
• Naprawiaj przekierowania partiami, zaczynając od grup najwyższej wartości.
• Po wdrożeniu przetestuj każdą partię ponownie.

Nie ufaj komunikatowi „wszystkie przekierowania zaimportowane poprawnie”. Przeskanuj listę.

Dzień 5-7: napraw szablony

• Przeprowadź audyt canonicali według typu strony.
• Sprawdź dyrektywy robots i reguły noindex.
• Przejrzyj tytuły, nagłówki, schemę, breadcrumbs i linki wewnętrzne.
• Kontroluj paginację i szablony archiwów.
• Potwierdź cele hreflang w wersjach wielojęzycznych, jeśli dotyczy.
• Przetestuj działanie kategorii, produktów i filtrów WooCommerce.

Tu właśnie przydaje się przegląd technicznego SEO WordPressa. Szukasz awarii na poziomie szablону, nie pojedynczych dziwactw.

Dzień 8-14: udowodnij odzysk

• Monitoruj pokrycie i statystyki crawla w Search Console.
• Sprawdzaj logi pod kątem aktywności Googlebota na starych przekierowaniach.
• Śledź pozycje według grup URL, nie tylko słów kluczowych.
• Porównaj w analityce strony wejścia sprzed i po naprawie.
• Notuj każdą zmianę przekierowania, szablonu i mapy witryny.

Jeśli ruch rośnie w naprawionych grupach URL, skaluj tę samą poprawkę. Jeśli nic się nie zmienia, przestań wprowadzać losowe zmiany i ponownie sprawdź mapę.

Czego nie robić po nieudanej migracji WordPressa

Nie instaluj trzech kolejnych wtyczek SEO. Stworzysz nakładające się canonicale, zduplikowane sitemapy i reguły przekierowań, za które nikt nie odpowiada.

Nie przekierowuj każdego 404 na homepage. Google jasno mówi, że nieistotne masowe przekierowania mogą stać się soft 404.

Nie zmieniaj ponownie struktury permalinków tylko dlatego, że obecna „wygląda czyściej”. Czyste URL-e są bezużyteczne, jeśli ciągle się zmieniają.

Nie przepisuj treści, zanim nie naprawisz dostępu, przekierowań, canonicali i indeksowalności. Jakość treści nie zrekompensuje zerwanej ścieżki.

Nie usuwaj starych przekierowań, bo „Google pewnie już to ogarnęło”. Google radzi trzymać je tak długo, jak to możliwe, zwykle co najmniej rok.

Nie ufaj pozycji strony głównej jako dowodowi, że migracja jest w porządku. Odzysk brandu może ukryć upadek szablonu. Sprawdź strony wejścia, które wcześniej przynosiły ruch non-brand.

Jeśli stare URL-e nie potrafią wyjaśnić, dokąd trafiły, Google nie ma powodu zgadywać za Ciebie.

FAQ

Ile trwa odzysk SEO po migracji WordPressa?

Drobne poprawki mogą przynieść zmiany w crawlach i wyświetleniach w ciągu kilku dni. Odzysk pozycji trwa zwykle dłużej, bo Google musi ponownie przeskanować stare URL-e, przetworzyć przekierowania, zaktualizować canonicale i odbudować zaufanie do nowego zestawu adresów. Przy większych serwisach licz w tygodniach, nie godzinach.

Czy po migracji WordPressa powinienem ponownie wysłać sitemapę?

Tak, ale dopiero gdy mapa jest czysta. Wysłanie sitemap pełnego starych domen, URL-i z noindex czy rozbieżności canonicali utrudni diagnostykę. Otwórz indeks sitemap i podmapy ręcznie przed wysyłką.

Czy same przekierowania 301 wystarczą, by zachować pozycje?

Są niezbędne, ale to nie całe zadanie. Strona docelowa musi być trafna, indeksowalna, zalinkowana wewnętrznie, poprawnie skanonikalizowana i obecna w czystych sitemapach. 301 do słabej lub nieadekwatnej strony nadal może tracić ruch.

A co, jeśli zmieniłem strukturę permalinków w WordPressie?

Traktuj to jak migrację URL-i. Zbuduj mapę z każdego starego permalinku do nowego miejsca docelowego. Uwzględnij bazy kategorii, zachowanie ukośników końcowych, bazy produktów, paginację i stare fallbacki ?p=123, jeśli działają.

Czy mogę usunąć stary hosting po migracji?

Tylko jeśli przekierowania są obsługiwane gdzie indziej i przetestowane. Wiele witryn traci ruch, bo stary hosting był jedynym miejscem istnienia przekierowań. Zanim coś wyłączysz, przeskanuj stare URL-e i potwierdź, że nadal działają poprawnie.

Wnioski: plan naprawczy powinien być checklistą startową

Odzysk po migracji WordPressa nie jest widowiskowy. To księgowość URL-i, dyscyplina przekierowań, kontrola szablonów i cierpliwość. Ta sama checklista, która naprawia spadek, powinna istnieć przed startem.

W seojuice.io obowiązuje ta sama zasada. Nudna ciągłość URL bije bohaterskie sprzątanie. Użyj tego artykułu dwa razy: raz, by naprawić obecną migrację, i raz przed następną.

Potrzebujesz pomocy w znalezieniu przerwy?

Jeśli po migracji WordPressa ruch organiczny spadł i wciąż nie wiesz dlaczego, zacznij od mapy URL-i i audytu przekierowań. SEOJuice może zamienić panikę w kolejkę napraw, a następnie w checklistę dla kolejnej migracji.