Dlaczego Google cofa migracje domeny po 4 miesiącach i jak zabezpieczyć WooCommerce

Zmiana adresu domeny w sklepie internetowym WooCommerce to jedna z najbardziej ryzykownych operacji inżynieryjnych w całym cyklu życia serwisu e-commerce. W październiku 2026 roku na forum Google Search Central oraz w branżowych dyskusjach na Search Engine Roundtable opisano głośny przypadek witryny, w której Google po 4 miesiącach od poprawnego wdrożenia przekierowań 301 i zgłoszenia zmiany adresu w Search Console zaczął masowo cofać ruch organiczny i indeksację z nowej domeny z powrotem na starą.

Wielu właścicieli sklepów i programistów zakłada błędnie, że proces migracji kończy się w momencie, gdy panel Google Search Console zaakceptuje wniosek o zmianę adresu, a pierwsze adresy URL zaczną pojawiać się w wynikach wyszukiwania. W rzeczywistości algorytmy wyszukiwarki nieustannie weryfikują sygnały kanoniczne. Gdy fundamenty techniczne nowej domeny okażą się niestabilne, wyszukiwarka podejmuje autonomiczną decyzję o unieważnieniu migracji.

W tym artykule analizujemy architekturę tego problemu, wskazujemy pułapki w bazach danych WooCommerce oraz pokazujemy procedury inżynieryjne, które chronią sklep przed katastrofalnym spadkiem widoczności.

#Dlaczego Google wraca do starej domeny po kilku miesiącach od migracji

Zjawisko powrotu Google do starej domeny nie wynika z błędu oprogramowania wyszukiwarki, lecz jest bezpośrednią konsekwencją działania algorytmu wyboru adresu kanonicznego (Canonicalization System). Google nie uznaje przekierowania 301 ani narzędzia zmiany adresu za trwałe przeniesienie praw własności sygnałów rankingowych. Traktuje je jako silną sugestię, która musi być bezustannie potwierdzana przez kilkanaście niezależnych parametrów.

Gdy robot Googlebot odwiedza starą domenę i napotyka nagłówek HTTP/1.1 301 Moved Permanently, przekazuje sygnały PageRank do adresu docelowego. Jednak równolegle robot bada nową domenę. Jeżeli w trakcie kolejnych tygodni wystąpi którykolwiek z poniższych czynników:

1. Nowa domena zaczyna zwracać błędy serwera (kody 500, 502, 504) pod wpływem obciążenia ruchem robotów AI lub klientów.
2. Istotna część podstron na nowej domenie odpowiada kodem 200 OK, ale treść jest pusta lub zawiera błąd PHP, co wywołuje automatyczną klasyfikację jako soft 404.
3. Tagi rel="canonical" na nowym serwisie omyłkowo wskazują stary adres z powodu błędu w szablonie motywu lub wtyczce SEO.
4. Struktura linkowania wewnętrznego (menu, stopka, opisy produktów, breadcrumbs) wciąż operuje na adresach starej domeny.
5. Zewnętrzny profil odnośników do nowej domeny pozostaje zerowy, a stare przekierowania zaczynają gubić nagłówki w wyniku błędów w konfiguracji proxy CDN.

W takiej sytuacji wskaźnik zaufania algorytmu do nowego adresu gwałtownie spada. Po przekroczeniu krytycznego progu niepewności Googlebot uznaje, że zmiana adresu była tymczasowa lub błędna, po czym przywraca indeksację pierwotnych adresów URL w indeksie głównym.

#Jak Google ocenia sygnały kanoniczne przy zmianie adresu witryny

Proces kanonizacji w wyszukiwarkach internetowych to wielopoziomowy algorytm decyzyjny. Nie opiera się on wyłącznie na deklaracji w nagłówku strony, lecz zestawia ze sobą sygnały jawne i niejawne.

#Jakie sygnały kanoniczne decydują o wyborze domeny przez algorytm

Poniższa hierarchia obrazuje wagę poszczególnych sygnałów w procesie oceny kanoniczności przez Googlebot:

Gdy sygnały są ze sobą sprzeczne (na przykład przekierowanie 301 kieruje na nową domenę, ale tag kanoniczny w kodzie HTML nowej domeny odsyła do starej), algorytm wchodzi w stan zawieszenia decyzyjnego. Z czasem przewagę zyskuje domena z dłuższą historią i silniejszym profilem linków zewnętrznych.

#Dlaczego błędne tagi rel canonical cofają migrację w Google

W sklepach opartych na WooCommerce bardzo często dochodzi do sytuacji, w której wtyczka SEO (np. Yoast SEO, Rank Math czy The SEO Framework) generuje tagi kanoniczne na podstawie adresu zapisanego w tabeli konfiguracyjnej WordPressa. Jeżeli programista podczas migracji zapomni zaktualizować pole home lub siteurl, albo w kodzie motywu potomnego znajduje się twardo zakodowana stała:

// Błąd w pliku functions.php motywu potomnego
add_filter('wpseo_canonical', function($canonical) {
    return str_replace('nowy-sklep.pl', 'stary-sklep.pl', $canonical);
});

Wówczas każda podstrona nowego sklepu wysyła do wyszukiwarki jednoznaczny sygnał: ta strona jest tylko duplikatem, a jej oryginał znajduje się na starej domenie. Googlebot po przetworzeniu kilkunastu tysięcy takich stron uznaje nową domenę za kopię i wycofuje ją z indeksu.

#Jakie błędy w przekierowaniach 301 niszczą migrację sklepu WooCommerce

Prawidłowa konfiguracja przekierowań to znacznie więcej niż prosta dyrektywa w pliku .htaccess. W wielotysięcznych sklepach internetowych błędy w regułach routingu prowadzą do niewidocznych na pierwszy rzut oka awarii.

#Dlaczego łańcuchy przekierowań i limity CDN powodują powrót do starej domeny

Głównym problemem w architekturze brzegowej (Edge Network) jest ograniczenie wielkości plików konfiguracyjnych. Przykładowo, platforma Cloudflare Pages posiada sztywny limit wielkości pliku _redirects wynoszący 100 KB (około 2000 do 2500 reguł statycznych). W przypadku wgrania pliku o wielkości 400 KB, system nie odrzuca wdrożenia z błędem krytycznym, lecz po cichu obcina reguły powyżej limitu.

W rezultacie pierwsze 2000 produktów przekierowuje poprawnie z kodem 301, natomiast pozostałe 15 000 adresów zwraca kod 404 lub trafia na generyczną stronę główną.

Innym krytycznym zjawiskiem są pętle i łańcuchy przekierowań:

Stary URL -> Nowy URL (HTTP) -> Nowy URL (HTTPS bez www) -> Nowy URL (HTTPS z www i ukośnikiem)

Według dokumentacji Google o błędach HTTP Googlebot przy indeksowaniu treści podąża za maksymalnie 10 przekierowaniami w łańcuchu, a narzędzie do sprawdzania adresów URL nie podąża za przekierowaniami wcale. Przewodnik Google o przenoszeniu witryny zaleca ponadto unikanie łańcuchów i kierowanie każdego starego adresu od razu do docelowego. Każdy pośredni przeskok to dodatkowe żądanie HTTP przed dotarciem do treści, pomnożone przez każdy adres w katalogu.

#Jak poprawnie przekierować nawigację fasetową i parametry filtrowania

Sklepy WooCommerce generują miliony wariantów adresów URL poprzez parametry GET obsługujące filtry:

• ?filter_kolor=czarny
• ?filter_rozmiar=xl&min_price=100
• ?pwb-brand-filter=producent-a

Częstym błędem architektów jest próba zamapowania każdego parametru do nowego formatu w statycznym pliku reguł. Prowadzi to do gigantycznych tablic przekierowań, które zawieszają serwer WWW. Prawidłowe podejście inżynieryjne wymaga dynamicznej reguły w Nginx:

# Konfiguracja Nginx dla starej domeny: zachowanie parametrów zapytania
server {
    listen 443 ssl http2;
    server_name stary-sklep.pl www.stary-sklep.pl;

    ssl_certificate /etc/ssl/certs/stary-sklep.crt;
    ssl_certificate_key /etc/ssl/private/stary-sklep.key;

    # Przekierowanie 1:1 z zachowaniem ścieżki i parametrów
    location / {
        return 301 https://nowy-sklep.pl$request_uri;
    }
}

Zastosowanie zmiennej $request_uri gwarantuje, że zapytanie https://stary-sklep.pl/kategoria/buty/?filter_kolor=czarny zostanie natychmiast przekierowane do https://nowy-sklep.pl/kategoria/buty/?filter_kolor=czarny w dokładnie jednym kroku sieciowym.

#Jak przenieść bazę danych WooCommerce bez utraty relacji taksonomii

Baza danych WordPressa posiada specyficzną architekturę przechowywania informacji. Setki ustawień motywów, wtyczek, metadanych produktów i struktur bloków Gutenberg zapisywane są w postaci zserializowanych obiektów PHP.

#Dlaczego podmienianie adresów w bazie SQL psuje zserializowane dane w WordPressie

Ciąg zserializowany w PHP zawiera dokładną informację o liczbie znaków w tekście. Przykładowy rekord w tabeli wp_options:

s:20:"https://stary-sklep.pl";

Wartość s:20 oznacza string o długości 20 znaków. Jeżeli wykonamy naiwne zapytanie w phpMyAdmin lub konsoli MySQL:

-- NIEBEZPIECZNE ZAPYTANIE: NISZCZY STRUKTURĘ DANYCH ZSERIALIZOWANYCH
UPDATE wp_options 
SET option_value = REPLACE(option_value, 'stary-sklep.pl', 'nowy-sklep-internetowy.pl');

Adres nowy-sklep-internetowy.pl ma 26 znaków, ale wskaźnik długości w bazie nadal wynosi s:20. W momencie, gdy WordPress próbuje odczytać ten rekord za pomocą funkcji unserialize(), parser zgłasza błąd integralności i zwraca pusty wynik. Skutkuje to zniknięciem ustawień bramek płatności, wyzerowaniem opcji wysyłki oraz uszkodzeniem układu stron zbudowanych w edytorze Gutenberg.

#Gotowy skrypt WP-CLI do bezpiecznej podmiany domeny w bazie

Jedyną w pełni bezpieczną metodą aktualizacji domen w środowisku WordPress jest użycie narzędzia wiersza poleceń WP-CLI, które przeprowadza deserializację każdego rekordu w pamięci, dokonuje podmiany tekstu, przelicza sumy kontrolne i ponownie serializuje dane przed zapisem do bazy.

Poniższy skrypt powłoki Bash automatyzuje ten proces wraz z wykonaniem kopii zapasowej i czyszczeniem pamięci podręcznej obiektów:

#!/usr/bin/env bash
# Skrypt bezpiecznej migracji domeny w WooCommerce
set -euo pipefail

OLD_DOMAIN="stary-sklep.pl"
NEW_DOMAIN="nowy-sklep.pl"
WP_PATH="/var/www/nowy-sklep/public"

echo "=== Rozpoczynanie procedury migracji bazy danych ==="

# 1. Zrzut awaryjny bazy danych przed zmianami
wp db export "${WP_PATH}/backup-pre-migration-$(date +%F).sql" --path="${WP_PATH}"

# 2. Próbny przebieg weryfikacyjny (Dry Run)
echo "Weryfikacja wystąpień starej domeny (Dry Run)..."
wp search-replace "https://${OLD_DOMAIN}" "https://${NEW_DOMAIN}" \
    --all-tables \
    --dry-run \
    --path="${WP_PATH}"

# 3. Właściwa podmiana adresów w protokole HTTPS
echo "Wykonywanie właściwej operacji search-replace..."
wp search-replace "https://${OLD_DOMAIN}" "https://${NEW_DOMAIN}" \
    --all-tables \
    --precise \
    --recurse-objects \
    --path="${WP_PATH}"

# 4. Podmiana adresów bez protokołu (dla odnośników względnych i schematów)
wp search-replace "${OLD_DOMAIN}" "${NEW_DOMAIN}" \
    --all-tables \
    --precise \
    --skip-columns=guid \
    --path="${WP_PATH}"

# 5. Odświeżenie struktury permalinków WooCommerce
echo "Regeneracja reguł przepisywania adresów URL..."
wp rewrite flush --hard --path="${WP_PATH}"

# 6. Wyczyszczenie pamięci podręcznej Redis / Memcached
wp cache flush --path="${WP_PATH}"

echo "=== Migracja bazy danych zakończona sukcesem ==="

Zwróć uwagę na flagę --skip-columns=guid. Zgodnie ze standardami inżynieryjnymi WordPressa, unikalny identyfikator wpisu w kolumnie guid tabeli wp_posts nie powinien być modyfikowany, aby czytniki RSS oraz agregatory wiadomości nie potraktowały istniejących artykułów jako nowych wpisów.

#Jak długo trzymać mapę witryny XML i serwer starej domeny

Jeden z najczęściej popełnianych błędów organizacyjnych polega na wyłączeniu serwera starej domeny lub nieprzedłużeniu jej rejestracji u rejestratora DNS po 6 miesiącach od migracji.

Oficjalna dokumentacja Google Search Central jasno określa, że minimalny czas utrzymywania infrastruktury przekierowań to 12 miesięcy. Jednak w realiach e-commerce optymalną strategią jest utrzymanie domeny i przekierowań na zawsze. Wygasła domena może zostać przejęta przez konkurencję lub podmioty tworzące farmy linków spamowych, co natychmiast odetnie wartościowe odnośniki historyczne.

Co więcej, na starej domenie powinna nadal działać mapa witryny XML zawierająca wykaz wszystkich starych adresów URL:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Mapa XML na starej domenie stary-sklep.pl wskazująca przekierowywane adresy -->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://stary-sklep.pl/produkt/laptop-biznesowy/</loc>
    <lastmod>2026-10-14</lastmod>
  </url>
  <url>
    <loc>https://stary-sklep.pl/kategoria/elektronika/</loc>
    <lastmod>2026-10-14</lastmod>
  </url>
</urlset>

Tę mapę zgłaszamy w konsoli Google Search Console dla usługi starej domeny. Daje to robotowi Googlebot bezpośrednią listę kontrolną adresów, które musi regularnie odwiedzać, aby upewniać się, że odpowiedź 301 Moved Permanently jest stabilna i niezmienna.

#Jak sprawdzić logi serwera i wykryć cofanie indeksacji w Google Search Console

Wczesne wykrycie anomalii indeksacyjnych pozwala zapobiec załamaniu sprzedaży w sklepie internetowym. Kiedy proces migracji zaczyna się psuć, pierwsze symptomy pojawiają się w logach serwera na kilka tygodni przed widocznym spadkiem pozycji.

#Na jakie anomalie w raporcie stron i skuteczności GSC zwrócić uwagę

W panelu Google Search Console należy monitorować trzy wskaźniki:

1. Raport Indeksacja -> Strony na usłudze nowej domeny: Gwałtowny wzrost liczby stron w stanie Strona zeskanowana, ale jeszcze nie zindeksowana oraz Duplikat, użytkownik nie oznaczył strony kanonicznej. Oznacza to, że Googlebot napotyka opór i odmawia włączania nowych adresów do indeksu głównego.
2. Raport Skuteczność na starej usłudze GSC: Jeżeli po okresie niemal całkowitego spadku wyświetleń do zera, wykres wyświetleń na starej domenie zaczyna piąć się w górę, jest to bezpośredni dowód na to, że algorytm zaczął ponownie serwować stare adresy w wynikach organicznych.
3. Narzędzie Sprawdzanie adresu URL: Przetestowanie kluczowych kart produktów. Jeśli pole Kanoniczny wybrany przez Google wskazuje adres na starej domenie, podczas gdy Kanoniczny zadeklarowany przez użytkownika wskazuje nową, witryna znajduje się w stanie ostrego konfliktu kanonicznego.

#Jak monitorować statusy HTTP w Cloudflare Logpush i na serwerze Nginx

Analiza logów dostępowych pozwala sprawdzić zachowanie robota Googlebot w czasie rzeczywistym. Do filtrowania zapytań robota na starym serwerze wykorzystujemy proste polecenie powłoki:

# Analiza logów Nginx pod kątem nieprawidłowych odpowiedzi dla Googlebota
awk -F'"' '$6 ~ /Googlebot/ { print $1, $2, $3 }' /var/log/nginx/stary-sklep.access.log \
  | awk '{ print $1, $6, $7 }' \
  | sort | uniq -c | sort -nr | head -n 30

Prawidłowy wynik powinien wykazywać wyłącznie kod odpowiedzi 301. Wszelkie wystąpienia kodów 200, 302, 404 czy 502 dla żądań kierowanych na starą domenę wymagają natychmiastowej interwencji inżynieryjnej.

#Co zrobić z linkami wewnętrznymi w blokach Gutenberg i polach ACF

Jedną z najczęstszych przyczyn cofnięcia migracji w witrynach opartych na WordPressie jest ukryte linkowanie wewnętrzne. Mimo poprawnego wykonania komendy wp search-replace, część odnośników może pozostać nienaruszona, jeśli dane były zapisane w formatach niestandardowych (np. zakodowane w base64, zagnieżdżone w polach JSON w tabeli wp_termmeta lub wygenerowane dynamicznie przez wtyczki buforujące).

Poniższa lista kontrolna wskazuje miejsca, które wymagają weryfikacji:

• Menu nawigacyjne WordPress: Należy sprawdzić w panelu Wygląd -> Menu, czy pozycje menu typu Własny odnośnik (Custom Links) nie posiadają twardo wpisanego adresu stary-sklep.pl.
• Szablony blokowe (Full Site Editing): Pliki HTML motywu w katalogu /templates oraz /parts mogą zawierać statyczne odnośniki do polityki prywatności, regulaminu lub podstron kontaktowych.
• Pola ACF Flexible Content: Złożone układy stron głównych często przechowują relacje do innych podstron jako identyfikatory ID, ale w polach tekstowych edytora WYSIWYG linki wprowadzane są jako statyczny kod HTML.
• Wtyczki koszyka i kasy: Wtyczki takie jak WooCommerce Checkout Blocks lub niestandardowe moduły one-step-checkout mogą posiadać skonfigurowane adresy URL w swoich panelach administracyjnych.

Aby zweryfikować obecność starych adresów na renderowanych stronach nowego sklepu, warto uruchomić crawler konsolowy:

# Przeskanowanie nowego sklepu w poszukiwaniu odnośników do starej domeny
wget --spider --recursive --no-verbose --output-file=wget-scan.log https://nowy-sklep.pl || true
grep "stary-sklep.pl" wget-scan.log || echo "Brak bezpośrednich odnośników do starej domeny."

#Jak w 7 krokach naprawić stronę jeśli Google cofnął migrację do starej domeny

Jeżeli Twój sklep padł ofiarą zjawiska cofnięcia migracji, a w wynikach wyszukiwania ponownie wyświetlają się adresy starej domeny, konieczne jest wdrożenie natychmiastowego planu naprawczego.

+-------------------------------------------------------------------+
|            PROCEDURA NAPRAWCZA PRZY COFNIĘTEJ MIGRACJI            |
+-------------------------------------------------------------------+
                                  |
                                  v
         [ KROK 1: Audyt nagłówków HTTP i usunięcie pętli 301 ]
                 (Upewnij się, że stary URL daje czyste 301)
                                  |
                                  v
        [ KROK 2: Weryfikacja tagów rel canonical na nowej ]
               (Żadna podstrona nie może wskazywać starej)
                                  |
                                  v
       [ KROK 3: Naprawa błędów soft 404 w nowym katalogu ]
               (Karty wyprzedane muszą mieć poprawny status)
                                  |
                                  v
      [ KROK 4: Ponowna podmiana linków wewnętrznych w SQL ]
               (Weryfikacja menu, ACF, widgetów i stopek)
                                  |
                                  v
         [ KROK 5: Aktualizacja i wysłanie map XML sitemap ]
               (Zgłoś sitemap na starej i nowej usłudze GSC)
                                  |
                                  v
       [ KROK 6: Ponowne zgłoszenie zmiany adresu w GSC ]
               (Zweryfikuj stan narzędzia Change of Address)
                                  |
                                  v
      [ KROK 7: Zewnętrzny impuls linkowania do nowej domeny ]
               (Zaktualizuj profile social media, Google Moja Firma)

1. Audyt nagłówków HTTP: Za pomocą narzędzia cURL upewnij się, że każda testowana ścieżka na starej domenie zwraca natychmiastowy kod 301 do swojego dokładnego odpowiednika na nowej domenie. Wyeliminuj wszelkie przekierowania pośrednie do protokołu HTTP lub wersji z innym formatem adresu.
2. Korekta tagów rel canonical: Skontroluj źródło strony na nowej domenie. Upewnij się, że tag kanoniczny jest w 100% zgodny z bieżącym adresem URL, zawiera poprawny protokół HTTPS oraz prawidłowy format ukośnika końcowego (trailing slash).
3. Eliminacja błędów soft 404: Sprawdź w Search Console listę stron zgłaszających błąd pozornego braku treści. W WooCommerce produkty wyprzedane powinny nadal zwracać kod 200 OK z jasnym komunikatem o braku w magazynie oraz linkami do produktów alternatywnych, zamiast pustej strony z informacją o błędzie.
4. Czyszczenie linków w bazie: Wykonaj pełną procedurę wp search-replace z flagami --precise i --all-tables, upewniając się, że w bazie nowego sklepu nie występuje ani jedno odwołanie do starego adresu.
5. Obsługa podwójnych map XML: Upewnij się, że na nowej domenie mapa witryny zawiera wyłącznie aktywne, kanoniczne adresy odpowiadające kodem 200 OK, a na starej domenie mapa XML zawiera wykaz przekierowywanych adresów.
6. Weryfikacja narzędzia zmiany adresu: Jeśli w Search Console minęło 180 dni od pierwszego zgłoszenia zmiany adresu, zgłoś procedurę ponownie po upewnieniu się, że wszystkie błędy techniczne zostały usunięte.
7. Aktualizacja ekosystemu zewnętrznego: Zaktualizuj adres strony internetowej w profilu Google Moja Firma (GBP), w systemach płatności, w mediach społecznościowych oraz na portalach partnerskich. Zapewni to algorytmom Google silny zewnętrzny sygnał potwierdzający autentyczność i pierwszeństwo nowego adresu.

#Podsumowanie techniczne dla inżynierów i właścicieli sklepów e-commerce

Cofnięcie migracji domeny przez Google to jednoznaczny sygnał ostrzegawczy: algorytmy wyszukiwarki wykryły rozbieżność pomiędzy deklarowanym celem migracji a rzeczywistym stanem infrastruktury technicznej serwisu.

W nowoczesnym środowisku e-commerce sukces zmiany domeny nie zależy od szczęścia, lecz od dyscypliny inżynieryjnej:

• Przekierowania muszą być bezpośrednie (dokładnie jeden przeskok sieciowy) i zachowywać pełną strukturę parametrów filtrowania.
• Baza danych WordPress i WooCommerce wymaga operacji z poszanowaniem zserializowanych obiektów PHP za pośrednictwem WP-CLI.
• Tagi kanoniczne oraz linkowanie wewnętrzne muszą bezwzględnie wskazywać nowy adres od pierwszej sekundy po przełączeniu serwerów DNS.
• Stara domena wraz z certyfikatem SSL i dedykowaną mapą XML musi pozostać aktywna przez minimum 12 miesięcy.

Przed wdrożeniem zmian warto przeprowadzić kompleksowy audyt migracji WordPress, który pozwala wykryć pułapki przekierowań i niespójności bazodanowe przed przełączeniem domen produkcyjnych.

Wdrażając te zasady, eliminujesz ryzyko powrotu indeksacji do starej domeny i zabezpieczasz ciągłość przychodów swojego sklepu internetowego.