Migracja witryny pod SEO: jak przenieść ją bez utraty pozycji

TL;DR: Migracja zachowuje widoczność w wyszukiwarce, gdy każdemu wartościowemu staremu URL-owi przypisano odpowiednie miejsce docelowe, trwałe przekierowania po stronie serwera wskazują tam bezpośrednio, a Google może przejść do nowego adresu i go zindeksować. Zanim wystartujesz, zinwentaryzuj i zbadaj starego site’a. Zbuduj mapę przekierowań 1:1, zaktualizuj linki wewnętrzne i tagi canonical, prześlij nowe sitemap, a potem monitoruj moment „przecięcia” indeksowania ze starych URL-i na nowe. Do migracji domen używaj „Change of Address”, a nie HTTP→HTTPS ani zmian hostingu.

Pierwsze pytanie w SEO migracji serwisu nie brzmi, jaki plugin zainstalować. Brzmi ono tak: czy użytkownicy i Google zobaczą po migracji inne URL-e?

Google Search Central dzieli migracje na przeniesienia site’u ze zmianami URL oraz przeniesienia site’u bez zmian URL. To rozróżnienie determinuje większość pracy. Zmiany domeny, przejście HTTP→HTTPS, zmienione ścieżki oraz konsolidacje domen należą do pierwszej grupy. Przełączenie hostingu albo migracja do CDN przy zachowaniu identycznych widocznych URL-i należą do drugiej.

My też przeszliśmy migrację domeny. W styczniu 2026 przenieśliśmy SEOJuice z seojuice.io na seojuice.com, w dwuosobowym zespole — Lida i ja. To nie przenoszenie aplikacji było dla mnie stresujące. Najbardziej ryzykowne było udowodnienie, że każdy stary URL trafia w poprawne miejsce docelowe, że nowy serwis nie polega na wewnętrznych linkach ze starej domeny oraz że Google „podmienia” adresy, a nie tylko je odkrywa.

To rozróżnienie ma znaczenie. „Nowy serwis jest uruchomiony” to kamień milowy infrastruktury. To nie jest dowód, że migracja zadziałała.

Co liczy się jako SEO migracja serwisu?

SEO migracja serwisu to zmiana na tyle istotna, że wpływa na to, jak wyszukiwarki docierają do strony, ją crawlują lub indeksują. Nowa domena to oczywisty przykład, ale kilka mniej spektakularnych projektów wymaga tych samych zabezpieczeń.

• Zmiana domeny: Przejście na inną domenę podczas rebrandingu, przejęcia albo zmiany domeny najwyższego poziomu (TLD).
• HTTP na HTTPS: Protokół jest częścią URL, więc to migracja ze zmianami URL, nawet jeśli hostname pozostaje ten sam.
• Zmiana platformy lub CMS-a: Nowa platforma może zmieniać ścieżki, parametry, paginację, sposób obsługi wielkości liter lub ukośniki na końcu. Traktuj to jak migrację ze zmianą URL, jeśli któregokolwiek z wynikowych adresów nie da się uznać za identyczny.
• Redesign lub restrukturyzacja: Sama zmiana warstwy wizualnej nie oznacza automatycznie migracji. Migracją staje się wtedy, gdy zmieniają się ścieżki, slugi, nawigacja, canonicals, renderowana zawartość albo indeksowalność.
• Konsolidacja domen: Połączenie kilku domen lub hostname’ów w jedną wymaga osobnej inwentaryzacji i planu przekierowań dla każdej domeny źródłowej.
• Migracja hostingu lub CDN: Jeśli widoczne dla użytkowników URL-e pozostają identyczne, to w praktyce bardziej operacja DNS i infrastruktury niż projekt przekierowań.

Unikałbym łączenia tych zmian, chyba że ograniczenie biznesowe jest silniejsze niż ryzyko błędnej diagnozy. Wytyczne Google są bezlitosne: „Zmieniaj tylko jedną rzecz na raz”. Jednoczesna zmiana domeny, CMS-a, designu i taksonomii daje cztery prawdopodobne przyczyny utraty każdej landing page (a tak naprawdę więcej, kiedy do gry wchodzą renderowanie i szablony).

Przed startem: najpierw inwentaryzacja, potem migracja

Zbuduj możliwą do obrony inwentaryzację starych URL-i

Twoja mapa przekierowań może chronić tylko te URL-e, które w niej uwzględnisz. Zcrawl’uj stary serwis, a potem połącz ten crawl z sitemap XML, eksportami z Search Console, stronami wejścia z analityki, danymi o linkach zwrotnych (jeśli są dostępne) oraz logami serwera. Każde źródło widzi inny wycinek site’u.

Crawler znajdzie podlinkowane strony, ale może pominąć osierocone (orphans). Sitemap może nie uwzględniać starych URL-i, które nadal mają pozycje. Analityka nie pokaże stron bez ostatnich wizyt. Logi potrafią ujawnić żądania do plików i starych ścieżek, których nie ma już w aktualnej nawigacji. „Kompletność” to tu niewygodne słowo (zwykle poprzestaję na niezależnie uzgodnionych wersjach).

Trzymaj w zakresie także nie-HTMLowe zasoby, jeśli mają wartość w kontekście wyszukiwania albo linków zewnętrznych. PDF-y, materiały do pobrania, obrazy i stare strony kampanii łatwo pominąć, bo nie pojawiają się w typowym crawlu zwykłych stron.

Ustal bazę wyników poza systemem, który zastępujesz

Wyeksportuj ruch organiczny na landing pages, kluczowe dane o zapytaniach i wydajności stron, informacje o zindeksowanych stronach, topowe URL-e, oraz aktualne wyniki crawlowania. Podziel dane na katalogi lub typy stron. Jedna liczba ruchu „sitewide” jest zbyt ogólna, żeby sensownie diagnozować migrację.

Jeśli ruch spadnie o 12%, ta liczba mówi ci właściwie prawie nic. Jeśli zniknie cały katalog produktowy, a blog pozostanie stabilny, masz użyteczny trop. Najpierw sprawdź przekierowania dla tego katalogu, szablony, tagi canonical i dyrektywy indeksowania.

Pominąłem pracę nad bazą, bo start wydawał się pilny. To mogło zaoszczędzić może godzinę, ale potem diagnozowanie trwało dłużej i było mniej pewne. Nie był to sprytny handel.

Zmapuj każdy stary URL do najbliższego odpowiednika

Google Search Central podaje sedno:

Mapa przekierowań kieruje każdy stary URL do jego realnego nowego odpowiednika — jeden do jednego:

# 1:1 redirect map (Nginx) - old URL to its closest new equivalent
location = /old-blog/why-seo/    { return 301 /blog/why-seo/; }
location = /products/old-widget/ { return 301 /shop/blue-widget/; }

# Anti-pattern: never mass-redirect everything to the homepage
# location / { return 301 /; }   # this creates soft 404s

„Gdy masz już listę starych URL-i, zdecyduj, gdzie powinien przekierować każdy z nich.”

Zbuduj mapowanie z jednym wierszem na każdy stary URL. Dodaj docelowy adres, oczekiwany kod odpowiedzi, typ strony, status migracji oraz ewentualny powód wycofania. Priorytetem są URL-e, które dostają ruch organiczny lub linki zewnętrzne, ale nie traktuj „priorytetu” jako pozwolenia, żeby ignorować long tail.

Miejsce docelowe musi zachować intencję. Stara strona produktu powinna trafić na ten sam produkt albo na jego prawdziwego następcę. Zmigrowany artykuł powinien trafić na ten artykuł. Strona główna nie jest uniwersalnym zamiennikiem.

Zachowuj istniejące ścieżki, jeśli tylko to możliwe. Każdy URL, którego nie ruszasz, eliminuje regułę przekierowania, decyzję w mapowaniu i potencjalne miejsce awarii. Zespoły często przepisują slugi podczas redesignu, bo nowe wersje wyglądają „czyściej”. Zanim zaakceptujesz ryzyko migracji, warto zapytać, jaki mierzalny problem rozwiązuje to sprzątanie.

Zdecyduj, czego nie przekierowywać

Mapowanie 1:1 nie oznacza, że każda usunięta strona musi trafić gdzieś „na siłę”. Jeśli strona nie ma odpowiednika i nie ma sensownego następcy, poprawny 404 lub 410 może być czytelniejszy niż przypadkowe przekierowanie.

To wymaga oceny redakcyjnej, a nie formuły ze спreadsheetu. Przekierowanie wycofanego produktu na model-następnik może być przydatne. Przekierowanie usuniętej strony wydarzenia do niezwiązanego indeksu eventów — może nie mieć sensu. Najpierw relewantność.

Przygotuj nowy odpowiednik do crawlownia

Zaimportuj treści, ustaw HTTPS, przygotuj plik robots.txt pod produkcję, zweryfikuj właściwości w Search Console i przejrzyj dyrektywy indeksowania na poziomie strony. Sprawdź tagi canonical, hreflang (tam gdzie używane), URL-e danych strukturalnych, paginację oraz wpisy w sitemap XML względem produkcyjnego hostname’u.

Serwisy stagingowe są często zabezpieczane regułami robots.txt, dyrektywami noindex, uwierzytelnianiem albo ich mieszanką. Te zabezpieczenia nie mogą „przeciekać” na produkcję. Jeśli po starcie strony nadal nie pojawiają się w wynikach, kontrola z Dlaczego moja strona nie jest w Google? obejmuje elementy typu kontrola robots, dyrektywy noindex oraz test URL Inspection.

Dla dużego serwisu migrację sekcji rozważ jako pierwszą, jeśli architektura na to pozwala. Google zaleca „na start przenieść tylko fragment serwisu, by przetestować wpływ na ruch oraz indeksowanie wyszukiwarek”. Taki etapowy ruch nie zawsze jest możliwy, ale warto go rozważyć przed zgodą na przełączenie typu „wszystko albo nic”.

W trakcie wdrożenia: spraw, by wszystkie sygnały mówiły to samo

Używaj bezpośrednich, trwałych przekierowań po stronie serwera

Google rekomenduje: „server side permanent redirects from the old URLs to the new URLs as you indicated in your mapping”. Jeśli mechanika przekierowań jest ci obca, najpierw przeczytaj Co to jest przekierowanie?. Nasze porównanie przekierowań 301 i 302 opisuje dokładniej decyzję „trwałe vs tymczasowe”.

Jak ujmuje to Patrick Stox, autor rozdziału o SEO w Web Almanac:

„Upewnij się, że przekierowania mają status 301 lub 308 zamiast 302 lub 307, jeśli wykonujesz trwałe przeniesienie i chcesz, żeby URL-e były indeksowane w nowej witrynie, a nie w starej.”

Kod statusu nie jest formalnością. Dokumentacja Google na temat przekierowań wyjaśnia, co dzieje się w przypadku trwałego przekierowania: „Googlebot podąża za przekierowaniem, a pipeline indeksowania traktuje przekierowanie jako sygnał, że docelowy adres ma być kanoniczny”.

Każdy stary URL powinien wskazywać bezpośrednio na ostateczny cel. Unikaj łańcuchów: stary → pośredni → final. Testuj pętle wynikające ze współdziałania reguł: HTTPS, www, ukośnika na końcu, CDN, serwera i aplikacji.

A potem sprawdzaj odpowiedzi na żywo, a nie tylko plik konfiguracyjny. Reguła może być poprawna w izolacji i nadal wchodzić w konflikt z inną warstwą. To moment, w którym przestaję ufać arkuszowi migracji (i, żeby było uczciwie, również mojej własnej pamięci) i crawl’uję produkcję.

Nie przekierowuj hurtowo stron na stronę główną

Google mówi wprost:

„Nie przekierowuj wielu starych URL-i do jednego, niepowiązanego adresu docelowego, na przykład na stronę główną nowej witryny.”

Przekierowanie „hurtowo na homepage” maskuje brak pracy mapującej; nie kończy jej. Wyszukiwarki i użytkownicy oczekiwali konkretnego zasobu. Wysyłanie każdego żądania na ogólną podstronę zdejmuje ten kontekst.

Jeśli wiele URL-i ma rzeczywistego następcę, mapowanie wiele-do-jednego może mieć sens. Na przykład kilka zduplikowanych URL-i produktowych może w końcu rozwiązywać się do kanonicznej strony produktu. Problemem nie jest arytmetyka, tylko irrelewantność.

Aktualizuj linki wewnętrzne, canonicals i generowane referencje

Przekierowania są mechanizmem awaryjnym. Nie powinny stać się systemem linkowania wewnętrznego nowego serwisu.

Zaktualizuj nawigację, breadcrumby, linki do artykułów, moduły „powiązane treści”, tagi canonical, referencje hreflang, dane strukturalne, wpisy w sitemap oraz referencje do zasobów tak, aby używały docelowych URL-i bezpośrednio. Instrukcja Google brzmi: „Zmień linki wewnętrzne w nowej witrynie ze starych URL-i na nowe URL-e”.

Na SEOJuice widzimy, że stare linki w szablonach są istotniejsze niż pojedyncze linki redakcyjne, bo jeden przestarzały komponent potrafi powielić ten sam „dependency” przekierowań na setkach stron. Najpierw sprawdź szablony, potem treść w body.

Prześlij sitemap-y i używaj Change of Address poprawnie

Prześlij nową sitemap XML w Search Console. Google mówi, że pomaga jej poznać nowe URL-e. Trzymanie osobno sitemap dla starych URL-i i osobno dla nowych URL-i daje praktyczny sposób monitorowania wymiany.

Dla migracji domena→domena przekaż Change of Address z poziomu starej właściwości w Search Console. Precyzyjna instrukcja Google: „prześlij prośby dla wszystkich subdomen oraz wariantów www i non-www starej nazwy domeny”. Narzędzie uzupełnia trwałe przekierowania; nie zastępuje ich.

Nie używaj Change of Address w migracjach HTTP→HTTPS. Zmiana HTTPS zmienia URL, ale Google wyraźnie wyłącza ten przypadek z narzędzia. To również niepotrzebne dla migracji samego hostingu ani zmian ścieżek w ramach tej samej domeny.

Po uruchomieniu: obserwuj wymianę, a nie tylko ruch

Migracja nie jest zakończona w momencie, gdy DNS rozwiązuje nazwę i strona główna się renderuje. Jest zakończona wtedy, gdy użytkownicy i crawlowacze konsekwentnie trafiają w docelową treść, a nowe URL-e zastępują stare URL-e w indeksie Google.

Monitoruj raporty indeksowania w Search Console, błędy w crawlowaniu, pozycje oraz ruch organiczny na landing pages w porównaniu do bazy. Google opisuje oczekiwany wzorzec indeksowania dość czytelnie:

„W czasie liczba stron zindeksowanych z sitemap dla starych URL-i spadłaby do zera, wraz z odpowiadającym temu wzrostem liczby zindeksowanych nowych URL-i.”

Ta „wymiana” jest bardziej przydatna niż odświeżanie jednego wykresu ruchu. Jeśli dana sekcja nie rośnie po nowej stronie, sprawdź jej przekierowania, tagi canonical, linki wewnętrzne, obecność w sitemap, renderowaną treść oraz dyrektywy indeksowania. Nasz poradnik o tym, jak działa indeksowanie w Google wyjaśnia proces crawlowania i canonicalizacji stojący za tą podmianą.

Może pojawić się przejściowy spadek, gdy Google recrawluje i przeindeksowuje zmienione URL-e. Nie ma wiarygodnego uniwersalnego procentu ani terminu „kiedy ma wrócić”. Wielkość serwisu, częstotliwość crawlowania, linkowanie wewnętrzne, jakość przekierowań i skala zmian różnią się w każdym przypadku. Zwykle bardziej da się działać na ostrej utracie na poziomie strony lub katalogu niż na „średniej z branży”.

Utrzymuj przekierowania w działaniu

Google mówi: „Keep the redirects for as long as possible, generally at least 1 year.” Utrzymywanie sensownych przekierowań w nieskończoność może też chronić odwiedzających korzystających ze starych zakładek i linków z serwisów, których nie kontrolujesz.

Nie wyłączaj starej domeny ani nie wycofuj przedwcześnie wspierającej infrastruktury. Przekierowanie, które działa podczas crawl’a startowego, ale znika kilka miesięcy później, nie pomoże użytkownikom ani crawlerom, którzy trafią na stary link po tym czasie.

Pierwsze awarie, które bym sprawdzał

Sprawdź dostępność i przekierowania, zanim zaczniesz przepisywać tytuły albo obwiniać aktualizację algorytmu. Porażki migracji są często mechaniczne: strona jest zablokowana, przekierowanie wpada w konflikt z inną regułą albo canonical wskazuje zły host.

Kolejność ma znaczenie. Poprawianie metadanych dla URL-a, którego Google nie może zcrawlować, to jałowa robota.

Migracja wyłącznie infrastrukturalna (hosting-only) to inne działanie

Jeśli każdy widoczny dla użytkowników URL pozostaje taki sam, nie twórz projektu przekierowań. Google definiuje ten przypadek jako przejście między dostawcami hostingu albo przeniesienie do CDN bez wpływu na widoczny URL.

Przygotuj i przetestuj nową infrastrukturę, obniż (tam gdzie ma to sens) time-to-live dla DNS, zmień DNS i monitoruj żądania obsługiwane przez oba środowiska. Google radzi wyłączyć starą infrastrukturę dopiero wtedy, gdy masz pewność, że wszyscy użytkownicy — włącznie z Googlebotem — dostają poprawną treść z nowej konfiguracji.

Nie ma mapy przekierowań i nie ma wniosku Change of Address, bo URL-e się nie zmieniały. Główne ryzyka dotyczą dostępności, wydajności, konfiguracji DNS, odpowiedzi serwera oraz różnic w tym, co nowa infrastruktura podaje crawlerom.

Jak SEOJuice pasuje po migracji

Po przeniesieniu seojuice.io na seojuice.com potrzebowaliśmy powtarzalnego sprawdzenia wyniku na żywo. Nie kolejnego arkusza startowego do migracji.

Narzędzie SEOJuice free SEO audit weryfikuje obszary szczególnie wrażliwe na migracje, w tym robots.txt, sitemap-y, tagi canonical, konfigurację HTTPS, przekierowania i linki wewnętrzne. Potrafi wykryć linki, które nadal wskazują na starą domenę, przekierowania prowadzące do błędów, pozostałe dyrektywy noindex oraz niezgodności w canonical albo HTTPS.

Granica jest ważna. Ten audyt wskazuje, co jest nie tak i gdzie. Nie zapisuje za ciebie reguł przekierowań na serwerze ani nie składa Change of Address. Te kroki nadal są po twojej stronie (co pewnie oznacza, że zmiany na poziomie domeny powinny tam pozostać).

Często zadawane pytania

Co to jest SEO migracja serwisu?

SEO migracja serwisu to zmiana wpływająca na to, jak wyszukiwarki docierają do strony, crawlują ją lub indeksują. Przykłady obejmują przenoszenie domen, przejście z HTTP na HTTPS, zmianę platformy CMS albo struktury URL, konsolidację domen oraz przenoszenie hostingu. Kluczowe rozróżnienie brzmi, czy zmieniają się widoczne URL-e, bo zmienione URL-e wymagają mapowania i przekierowań.

Czy stracę pozycje, gdy przeniosę mój serwis?

Nie musi tak być. Trwałe przekierowania pomagają Google uznać docelowy adres jako kanoniczny i zastąpić stary URL. Podczas recrawlowania i ponownego indeksowania może pojawić się pewna fluktuacja. Utrzymujące się spadki zwykle uzasadniają sprawdzenie brakujących przekierowań, niepowiązanych celów, pętli, tymczasowych przekierowań, zmienionej treści, canonical oraz zablokowanego indeksowania.

Czy stare URL-e muszą mieć przekierowania 1:1?

Każdy wartościowy stary URL powinien zostać oceniony osobno i przekierowany do najbliższego, relewantnego odpowiednika. Nie wysyłaj niezwiązanych stron na homepage. Jeśli nie istnieje relewantny odpowiednik, poprawny 404 lub 410 może być dokładniejszy niż mylące przekierowanie.

Kiedy powinienem użyć narzędzia Change of Address Google?

Użyj go przy przenosinach z jednej domeny na inną. Złóż wymagane zgłoszenia dla subdomen oraz wariantów www lub non-www starej domeny. Nie używaj go do zmian HTTP→HTTPS, zmian ścieżek w ramach jednej domeny ani do migracji hostingu i CDN. Change of Address nie zastępuje trwałych przekierowań.

Jak długo przekierowania migracyjne powinny być aktywne?

Google rekomenduje utrzymywanie przekierowań jak najdłużej, zazwyczaj przynajmniej przez rok. Utrzymywanie przydatnych przekierowań w nieskończoność może chronić stare zakładki i linki zewnętrzne, o ile docelowe adresy pozostają relewantne.

Jak zweryfikować, że migracja się udała?

Porównaj ruch po starcie, pozycje, zindeksowane URL-e oraz wyniki crawla z bazą. Crawluj stare URL-e, aby potwierdzić bezpośrednie trwałe przekierowania, crawl’uj nowy serwis pod kątem starych linków wewnętrznych i przejrzyj dyrektywy robots, canonicals, sitemap-y oraz odpowiedzi serwera. W Search Console liczba zindeksowanych adresów dla starej sitemap powinna spadać, podczas gdy liczba dla nowej sitemap powinna rosnąć.