Migracja strony a SEO – jak przeprowadzić bez utraty pozycji

Migracja strony to każda istotna zmiana, którą wyszukiwarka musi na nowo przetrawić: zmiana domeny, systemu zarządzania treścią (CMS), struktury adresów URL, protokołu albo głębokiego układu nawigacji. To nie jest pojedyncza operacja techniczna, tylko zaplanowany proces, który bezpośrednio wpływa na widoczność w Google.

Stawka jest prosta: jeśli ruch organiczny generuje zapytania i sprzedaż, każdy błędny krok przekłada się na realne straty. Najważniejsza zasada brzmi tak – skala ryzyka zależy od tego, ile zmiennych ruszasz naraz.

5 typów migracji i ich realne ryzyko

• Zmiana domeny (`marka.pl` na `nowamarka.pl`) – ryzyko WYSOKIE. Przenosisz całą historię, linki i rozpoznawalność adresu.
• Zmiana CMS lub technologii (np. WordPress na rozwiązanie dedykowane) – ryzyko WYSOKIE. Najczęściej zmienia się struktura URL i metadane.
• Redesign na tych samych adresach URL – ryzyko NISKIE do średniego. Najniższe, dopóki nie ruszasz adresów, nagłówków i linkowania.
• Migracja HTTP na HTTPS – ryzyko NISKIE, jeśli zrobiona poprawnie. To dziś standard.
• Łączenie lub podział serwisów (fuzja dwóch witryn, wydzielenie sklepu) – ryzyko BARDZO WYSOKIE. Łączysz lub rozdzielasz wiele źródeł sygnałów naraz.

Kiedy migracja jest naprawdę potrzebna

Powody migracji bywają różne: rebranding wymuszający nową domenę, przestarzały lub niefunkcjonalny CMS, wolne i niestabilne działanie strony, fuzja albo podział firmy. Sama migracja nie jest celem – jest środkiem. Zanim ją zaplanujesz, warto policzyć, ile ruchu organicznego dziś przynosi witryna i jaki to udział w sprzedaży. Im wyższa ta wartość, tym ostrożniej trzeba podejść do przenosin, bo każdy procent utraconej widoczności przekłada się na realne pieniądze.

Wniosek: sam redesign szablonu na niezmienionych adresach to inna liga ryzyka niż jednoczesna zmiana domeny, CMS i struktury. Im więcej rzeczy zmieniasz w jednym wdrożeniu, tym trudniej później ustalić, co poszło nie tak – dlatego, jeśli to możliwe, rozdzielaj duże zmiany na osobne etapy w czasie.

Wbrew obiegowej opinii spadki po migracji rzadko są efektem kary algorytmicznej. Niemal zawsze to zerwana ciągłość sygnałów albo błędy techniczne, które łatwo przeoczyć w pośpiechu wdrożenia.

Utracone lub błędne przekierowania 301

Najczęstszy winowajca. Stary adres z ruchem i linkami zwraca 404 zamiast trafnego 301 – a wraz z nim znika wartość, którą ten URL gromadził latami. Czasem przekierowanie istnieje, ale prowadzi w niewłaściwe miejsce (wszystko na stronę główną), co Google traktuje jak soft 404.

Zmiana lub utrata treści, nagłówków i linkowania

Przy redesignie lub zmianie CMS łatwo zgubić część tekstu, skrócić nagłówki H1/H2 albo wyciąć linkowanie wewnętrzne. To bezpośrednio osłabia trafność strony na frazy, na które wcześniej rankowała. Więcej o tym, jak unikać takich błędów, znajdziesz we wpisie o błędach SEO szkodzących pozycjom.

Pozostawiony noindex lub blokada w robots.txt

Klasyczny killer. Środowisko testowe ma zwykle dyrektywę `noindex` albo blokadę w `robots.txt`, żeby Google nie zindeksował duplikatu. Jeśli zapomnisz ją zdjąć przy wdrożeniu produkcyjnym, cała nowa witryna wypada z indeksu – i nie pomogą żadne przekierowania.

Zerwana ciągłość canonical, hreflang i danych strukturalnych

Nowy szablon często gubi tagi canonical, atrybuty hreflang (przy wersjach językowych) lub schema. Wyszukiwarka traci wtedy kontekst, który wcześniej ułatwiał jej rozumienie strony.

Wniosek: zdecydowana większość spadków to nie kara Google, tylko zerwana ciągłość sygnałów plus błędy techniczne. Dobra wiadomość – każda z tych przyczyn jest wykrywalna i odwracalna.

Kolejność działań jest tu święta: audyt zerowy, mapa 301, staging, wdrożenie, monitoring. Pominięcie któregokolwiek etapu zwykle wraca jako problem dwa tygodnie po starcie.

Przed migracją – audyt zerowy

• Pełny crawl starej witryny (Screaming Frog) i eksport wszystkich adresów URL.
• Snapshot pozycji, kliknięć i wyświetleń z Google Search Console jako punkt odniesienia – bez niego nie ocenisz później, co realnie spadło.
• Lista podstron generujących ruch i konwersje oraz tych z linkami zewnętrznymi.
• Kopia zapasowa całej strony i bazy danych.

Solidny audyt to fundament całego procesu – jak go przeprowadzić opisuje wpis audyt SEO krok po kroku.

Mapa URL-i i plan przekierowań 301

Zmapuj każdy stary adres na nowy w układzie 1:1. Tu pojawia się pierwszy twardy fakt: jak podaje dokumentacja Google Search Central, trwałe przekierowania 301 nie powodują utraty PageRank. Innymi słowy poprawnie wdrożona mapa 301 przenosi wartość strony na nowe adresy.

Środowisko staging

Przetestuj całą migrację na zamkniętej kopii, zabezpieczonej przed indeksacją (`noindex` lub blokada dostępu). Sprawdź przekierowania, metadane i linkowanie zanim ruszysz produkcję. Pamiętaj, żeby zdjąć blokadę indeksacji w dniu wdrożenia.

Dzień wdrożenia i pierwsze 48 godzin

• Włącz nową wersję i uruchom przekierowania 301.
• Zweryfikuj kody odpowiedzi crawlerem (czy 301 działają, czy nie ma 404 i łańcuchów przekierowań).
• Zaktualizuj `robots.txt` i upewnij się, że niczego nie blokuje.
• Wgraj nową sitemapę i zgłoś ją w GSC.

Wniosek: święta kolejność to audyt, mapa 301, staging, wdrożenie, monitoring. Skróty na tej liście kosztują najwięcej.

Przekierowania to absolutny rdzeń migracji. To one mówią wyszukiwarce i użytkownikowi, że treść przeniosła się pod nowy adres, i przekazują dalej wartość zgromadzoną przez stary URL.

Dlaczego 1:1, a nie zbiorczo na stronę główną

Kuszące jest skierowanie wszystkich starych adresów na stronę główną, żeby załatwić temat jedną regułą. To błąd. Google traktuje masowe przekierowanie nietrafnych URL jak soft 404 – tracisz wtedy pozycje na frazy, które wcześniej obsługiwały konkretne podstrony. Każdy stary adres powinien trafić na swój tematyczny odpowiednik.

Jak zmapować w arkuszu

Najwygodniej w prostym arkuszu z kolumnami: stary URL, nowy URL, status (gotowe/do ustalenia), priorytet ruchu (z danych GSC i analityki). Priorytet pomaga w dniu wdrożenia naprawiać najpierw to, co generuje najwięcej ruchu.

WordPress – wtyczka Redirection czy reguły w .htaccess

W WordPressie masz dwie drogi. Wtyczka Redirection jest wygodna i pozwala zarządzać przekierowaniami z panelu, dobra przy mniejszej liczbie adresów. Reguły w `.htaccess` (lub konfiguracji serwera) są wydajniejsze przy dużej skali. Niezależnie od metody po wdrożeniu przepuść całą listę starych adresów crawlerem i potwierdź, że każdy zwraca 301 do właściwego celu.

Mechanikę samych kodów opisuje wpis przekierowania 301 i 302 a SEO.

Wniosek: każdy stary URL z ruchem lub linkami musi mieć trafne 301. Pominięcie jednego adresu to 404 i utrata pozycji na powiązane frazy.

Dwa pytania, które wracają przy każdej większej migracji, a które większość poradników pomija: gdzie umieścić blog oraz co naprawdę przenosisz przy zmianie platformy.

Subdomena (`blog.domena.pl`) czy katalog (`domena.pl/blog`)

Dla większości firm bezpieczniejszy jest katalog. Treść w katalogu wzmacnia autorytet domeny głównej, bo Google traktuje całość jako jeden spójny serwis. Subdomenę wybiera się świadomie – gdy część serwisu jest wyraźnie odrębna technologicznie albo biznesowo (np. osobna aplikacja). Jeśli migrujesz z subdomeny do katalogu, to zwykle dobra zmiana dla SEO, ale i tak wymaga kompletu przekierowań 301.

Migracja z Wix, Joomla czy Google Sites na WordPress

Tu klucz jest taki: treść i adresy URL przenosisz, a sygnały odbudowujesz. Realnie migrujesz teksty, obrazy, strukturę adresów i mapę przekierowań. Od zera często budujesz szablon, linkowanie wewnętrzne, konfigurację schema i metadanych. Zmiana platformy to migracja wysokiego ryzyka, bo prawie zawsze rusza struktura URL – dlatego mapa 301 jest tu jeszcze ważniejsza niż przy zwykłym redesignie. Jeśli przy okazji przebudowujesz całą witrynę, warto potraktować to jako projekt budowy strony internetowej z wbudowanym planem SEO, a nie doraźnie.

Rola hostingu przy migracji

Stabilny, szybki hosting po przenosinach realnie wpływa na to, jak Google odbierze nową wersję – długie czasy ładowania i przestoje w dniu wdrożenia szkodzą. Z rekomendowanych dostawców sprawdza się CyberFolks. Unikaj najtańszych, przeciążonych pakietów, szczególnie przy sklepach.

Wniosek: zmiana platformy to migracja wysokiego ryzyka – treść i URL przenosisz, sygnały odbudowujesz.

Najwięcej migracji nie zabija skomplikowany błąd, tylko jeden zaznaczony checkbox. Środowisko testowe (staging) jest po to, żeby cały ten scenariusz odegrać na sucho, zanim Googlebot zobaczy cokolwiek. Potraktuj staging jak generalną próbę: masz na nim tę samą strukturę URL, tę samą konfigurację serwera i przetestowane przekierowania, zanim ruszysz produkcję.

Jak zablokować indeksację stagingu (auth vs robots vs noindex – i dlaczego nie mieszać)

Środowisko testowe nigdy nie może trafić do indeksu, bo Google zobaczy duplikat całej witryny. Masz trzy warstwy, ale nie są równorzędne:

• Zabezpieczenie hasłem (HTTP Basic Auth / .htpasswd) na całym stagingu – najpewniejsza metoda. Robot w ogóle nie wejdzie, więc nie ma czego zaindeksować. To warstwa główna.
• robots.txt z `Disallow: /` – blokuje crawl, ale nie gwarantuje braku indeksacji. Google potrafi zaindeksować sam adres bez treści, jeśli ktoś do niego podlinkuje. Sam robots.txt to za mało.
• Meta robots `noindex` / nagłówek `X-Robots-Tag: noindex` – blokuje indeksację, ale robot musi móc wejść i przeczytać ten tag. Dlatego `noindex` razem z `Disallow: /` jest sprzeczne: zablokowany robot nigdy nie zobaczy dyrektywy noindex. Wybierasz jedno – albo Basic Auth, albo noindex bez blokady crawl.

Pułapka noindex, która jedzie na produkcję

To najczęstsza przyczyna, dla której nowa strona po prostu znika z Google. Ustawienie `noindex` ze stagingu – w WordPress to Ustawienia -> Czytanie -> Zniechęcaj wyszukiwarki do indeksowania tej witryny albo `X-Robots-Tag: noindex` z konfiguracji serwera – potrafi pojechać na produkcję razem z bazą i plikami. Efekt: świeżo wdrożona witryna startuje z globalnym noindex i wypada z indeksu w kilka dni.

Dlatego pierwsza rzecz zaraz po go-live to sprawdzenie, czy pole Zniechęcaj wyszukiwarki jest odznaczone, a produkcyjny nagłówek nie zwraca noindex. Ten jeden check ratuje najwięcej migracji. Jeśli robisz to na stronie na WordPressie, zajrzyj też do praktyk pracy ze stagingiem WordPress.

Test przekierowań przed go-live (301, nie 302, bez łańcuchów)

Mapę 301 sprawdzasz na stagingu z tą samą konfiguracją serwera, a nie na produkcji po fakcie. Wgraj listę wszystkich starych adresów do Screaming Frog w trybie List Mode i zweryfikuj, że każdy stary URL zwraca dokładnie jeden skok: 301 -> 200. Czego nie chcesz zobaczyć:

• 302 zamiast 301 – tymczasowe przekierowanie nie konsoliduje sygnałów tak jak trwałe. Przy migracji zawsze 301.
• łańcuch 301 -> 301 -> 200 – każdy dodatkowy skok to strata mocy i wolniejsze ładowanie.
• pętla przekierowań albo 404 – oznacza dziurę w mapie.

U nas przełączenie zawsze poprzedza crawl całej mapy 301 na stagingu z produkcyjną konfiguracją serwera – to najtańszy sposób, żeby złapać błąd, zanim zobaczy go Google.

Checklista dnia przełączenia (24–72 h monitoringu)

Nie przełączaj w piątek po południu – pierwsze 24–72 godziny wymagają nadzoru. Zaraz po go-live odznacz noindex, sprawdź, czy produkcyjny robots.txt nie został ze stagingu z `Disallow: /`, zgłoś nową sitemap.xml w Google Search Console i przepuść kilka kluczowych adresów przez narzędzie Sprawdzenie adresu URL. Planujesz taką przeprowadzkę i wolisz oddać ją specjalistom? Napisz do nas – zrobimy migrację i audyt powdrożeniowy.

Najbardziej mylący scenariusz po migracji brzmi tak: adres się nie zmienił, treść jest w bazie, a strona zwraca 404. Wbrew pozorom to nie magia – to zwykle konfiguracja serwera i sposób, w jaki nowy system buduje adresy. Poniżej masz zebrane w jednym miejscu przyczyny, które w poradnikach leżą osobno.

Trailing slash i wielkość liter – dwa adresy tam, gdzie myślisz, że jest jeden

Dla serwera `/oferta` i `/oferta/` to dwa różne adresy. Jeśli stary CMS serwował wersję ze slashem, a nowy bez (lub odwrotnie) i nie ma reguły normalizującej, stare URL-e z indeksu Google trafiają na 404 albo na łańcuch przekierowań. Rozwiązanie: wybierasz jeden wariant, wymuszasz go globalnie przez 301 i trzymasz spójnie w linkowaniu wewnętrznym, sitemap i canonicalach.

Druga pułapka to wielkość liter. Serwery Linux (Apache, nginx) traktują `/Oferta` i `/oferta` jako różne zasoby, Windows/IIS zwykle nie. Migracja z hostingu Windows na Linux albo zmiana CMS wymuszająca lowercase w slugach sprawia, że stare adresy z wielką literą zwracają 404. Naprawa: 301 na małe litery plus reguła wymuszająca lowercase.

Permalinki i reguły przepisywania (WordPress, .htaccess, nginx)

To najczęstszy realny powód 404 przy tej samej treści. Po migracji WordPress ma inne ustawienie Bezpośrednich odnośników (Ustawienia -> Bezpośrednie odnośniki) albo uszkodzone reguły przepisywania. Treść jest w bazie, ale system nie potrafi jej powiązać z adresem. Szybki fix: wejdź w Ustawienia -> Bezpośrednie odnośniki i kliknij Zapisz zmiany bez żadnej zmiany – to regeneruje reguły rewrite i .htaccess, nie ruszając treści.

Po stronie serwera:

• Apache – uszkodzony, nadpisany albo zablokowany `.htaccess` sprawia, że strona główna działa, ale podstrony zwracają 404 (brak obsługi przyjaznych adresów).
• nginx – w ogóle nie czyta `.htaccess`. Reguły przepisywania muszą być w konfiguracji serwera (`try_files`, bloki `location`). Migracja z Apache na nginx bez przeniesienia reguł to klasyczne źródło masowych 404.
• Błędne uprawnienia i właściciel plików po przeniesieniu (chown/chmod) potrafią dać 403 albo 404.

Soft 404 i 410 – kiedy 200 OK jest gorsze niż czysty błąd

Soft 404 jest groźniejszy niż zwykły błąd: serwer zwraca kod 200 OK, ale treść jest pusta, to komunikat błędu albo duplikat innej strony (np. wszystko renderuje się jako strona główna). Google marnuje na to budżet indeksowania i dostaje mylny sygnał. Po migracji pojawia się, gdy nowy CMS renderuje komunikat nie znaleziono z kodem 200 zamiast 404.

Przy stronach, które usuwasz świadomie i nie mają odpowiednika, rozważ 410 Gone zamiast 404 – Google deindeksuje je szybciej. Jeśli strona ma odpowiednik, zawsze 301, nigdy 404 czy 410.

Paginacja, parametry i polskie znaki w URL

Adresy paginacji (`/blog/page/2/`) i URL-e z parametrami (`?filter=`, `?sort=`) często nie mają odpowiednika w nowym systemie – zmapuj ich wzorce. Uważaj też na procentowe kodowanie: stary adres z polskimi znakami zakodowany jako `%C5%9B...` po przejściu na ASCII-slug daje 404, jeśli nie ma przekierowania z wersji zakodowanej.

Jak to wykryć – Screaming Frog List Mode plus raport Strony w GSC

Wgraj eksport wszystkich starych adresów do Screaming Frog w trybie List Mode i sprawdź kody odpowiedzi na nowej domenie: filtruj 404, łańcuchy 3xx i podejrzane 200 (soft 404). Równolegle w Google Search Console otwórz Indeksowanie -> Strony i przejrzyj raporty Nie znaleziono (404), Strona z przekierowaniem oraz Soft 404 – tam widać, co realnie łapie Googlebot. Więcej o tych raportach w tekście o błędach w Google Search Console oraz o tym, jak crawlowanie przekłada się na pozycje. Nie ufaj temu, co widać w przeglądarce – soft 404 wygląda jak zwykła strona, a zwraca 200. Jeśli po przebudowie strony sypią się setki 404, warto zacząć od pełnego crawla listy.

Zaskakująco często ta sama treść po migracji ładuje się wolniej niż przed. Nie zmieniłeś ani jednego zdjęcia, a Core Web Vitals spadły. Powód nie leży w treści, tylko w tym, na czym ona teraz stoi: nowy serwer, nowy stack i konfiguracja wydajności, która po przeprowadzce często się gubi.

TTFB nowego serwera – fundament, o którym się zapomina

TTFB (Time To First Byte) to czas, po którym serwer zaczyna odpowiadać – fundament wszystkich metryk ładowania. Nowy hosting oznacza nowy TTFB. Słabszy lub przeciążony serwer, gorszy stack PHP, brak OPcache czy Redis, dalsza lokalizacja serwera od użytkowników – każdy z tych czynników podnosi TTFB, a przez to pogarsza LCP przy identycznej treści. Dlatego wybór hostingu to nie detal; więcej w tekstach o wyborze hostingu pod WordPress i o tym, jak przyspieszyć hosting.

Co gubi się po przeprowadzce (cache, kompresja, CDN, WebP)

Migracja często cofa stronę do stanu goły CMS. Ustawienia, które robiły robotę na starym serwerze, po prostu znikają:

• cache stron i OPcache – nieskonfigurowane po migracji, każde żądanie renderuje się od zera,
• kompresja gzip/brotli – wyłączona, transfer rośnie,
• CDN – odpięty, zasoby wracają na jeden, dalej położony serwer,
• formaty obrazów – jeśli stary serwer serwował WebP/AVIF, a nowy setup wrócił do JPG/PNG bez kompresji, waga strony rośnie i LCP idzie w górę.

LCP, INP, CLS – co realnie mierzysz (i dlaczego INP, nie FID)

Core Web Vitals to trzy metryki, oceniane na 75. percentylu danych realnych użytkowników. Progi Google (web.dev):

• LCP (Largest Contentful Paint) – ładowanie głównego elementu: dobry <= 2,5 s, słaby > 4 s.
• INP (Interaction to Next Paint) – responsywność: dobry <= 200 ms, słaby > 500 ms. INP zastąpił FID 12 marca 2024 jako oficjalna metryka CWV, więc jeśli poradnik wciąż straszy FID-em, jest nieaktualny.
• CLS (Cumulative Layout Shift) – stabilność wizualna: dobry <= 0,1, słaby > 0,25.

Ten wpis nie jest kursem optymalizacji – jak realnie poprawić te wartości, opisujemy w poradniku o Core Web Vitals oraz w tekście jak poprawić Core Web Vitals na stronie.

Benchmark przed i po plus pułapka danych polowych (28 dni CrUX)

Zmierz CWV zanim przełączysz produkcję. Przed migracją zapisz dane polowe ze starej wersji (raport Core Web Vitals w GSC plus PageSpeed Insights) dla kluczowych szablonów: home, kategoria, wpis. Po migracji porównaj te same szablony tymi samymi narzędziami.

Uwaga na dwie pułapki. Po pierwsze, dane polowe CrUX w raporcie CWV to okno kroczące około 28 dni – po migracji nie zobaczysz efektu nowego hostingu od razu, bo raport wciąż miesza stare i nowe pomiary. Do natychmiastowej oceny użyj danych laboratoryjnych (Lighthouse, PSI lab), a na dane polowe poczekaj kilka tygodni. Po drugie, wynik 100/100 w PageSpeed to dane laboratoryjne, nie werdykt CWV – te ocenia realnych użytkowników. Nie goń setki, celuj w progi na danych polowych. Jeśli po migracji pozycje spadły razem z wydajnością, audyt powdrożeniowy i pozycjonowanie pomoże odróżnić problem hostingu od problemu przekierowań.

Google Search Console to główne narzędzie kontroli po migracji. To tutaj najwcześniej zobaczysz, czy roboty poprawnie odnajdują nową wersję i czy ciągłość sygnałów została zachowana.

Change of Address tool

Przy zmianie domeny użyj narzędzia zmiany adresu (Change of Address) w GSC – przyspiesza ono migrację sygnałów między domenami. Ważny niuans potwierdzony przez dokumentację Google Search Central: narzędzia zmiany adresu używa się przy zmianie domeny, ale NIE przy migracji HTTP na HTTPS (to wciąż ta sama domena).

Co śledzić po wdrożeniu

• Raport Indeksowanie stron – czy nowe adresy wchodzą do indeksu, a stare z niego znikają.
• Skuteczność – kliki, wyświetlenia i średnia pozycja porównane ze snapshotem sprzed migracji.
• Kody odpowiedzi i błędy 404 – rosnąca liczba 404 to sygnał alarmowy.
• Sitemapa – czy została odczytana i przetworzona.

Pełny przewodnik po narzędziu znajdziesz we wpisie Google Search Console krok po kroku.

Obok GSC zadbaj o ciągłość pomiaru w analityce. Po migracji łatwo zgubić kod śledzący Google Analytics, Google Tag Managera czy piksel Meta – a bez nich tracisz dane porównawcze dokładnie wtedy, gdy są najpotrzebniejsze. Sprawdź, czy wszystkie skrypty śledzące działają na nowej wersji już pierwszego dnia, zanim ruch zacznie płynąć przez nieoznaczone strony.

Ile czasu potrzebuje Google

Według dokumentacji Google Search Central przeniesienie większości podstron małej i średniej witryny zajmuje zwykle kilka tygodni, a większe serwisy potrzebują więcej czasu. Google podaje wprost, że należy spodziewać się przejściowych wahań pozycji w trakcie przenosin, a rankingi z czasem się ustabilizują.

Wniosek: wahania w pierwszych tygodniach są normalne. Alarmujący jest dopiero trwały spadek połączony z rosnącą liczbą 404.

Najczęstszy scenariusz, w którym ludzie w panice szukają pomocy: migracja za nami, a widoczność leci w dół. Zanim założysz najgorsze, przejdź przez szybką diagnostykę – w większości przypadków przyczyna jest techniczna i odwracalna.

Szybka diagnostyka w 5 krokach

1. Przekierowania – przepuść listę starych URL crawlerem. Szukaj 404 zamiast 301, łańcuchów przekierowań i przekierowań na stronę główną.
2. noindex – sprawdź, czy ze stagingu nie został `noindex` w nagłówkach lub w metatagach na produkcji.
3. robots.txt – upewnij się, że nie blokuje kluczowych sekcji ani całej witryny.
4. Canonical – zweryfikuj, czy nowe strony nie wskazują canonicalem na stare albo nieistniejące adresy.
5. Sitemapa – potwierdź, że nowa sitemapa została wysłana i odczytana w GSC.

Ten protokół wyłapuje zdecydowaną większość spadków. Pamiętaj też, że – jak podaje Google – część wahań w pierwszych tygodniach jest naturalna i nie wymaga natychmiastowej reakcji.

Kiedy zrobisz samodzielnie, a kiedy potrzebujesz specjalisty

Prosty redesign na tych samych adresach URL bywa wykonalny samodzielnie. Poważnie rozważ wsparcie specjalisty, gdy:

• zmieniasz naraz domenę, CMS i strukturę URL,
• masz dużą liczbę podstron (setki lub tysiące adresów),
• prowadzisz e-commerce (przekierowania produktów, kategorii, wariantów),
• ruch organiczny jest Twoim głównym kanałem sprzedaży.

W tych sytuacjach koszt błędu – utrata ruchu, który płaci za sprzedaż – bywa znacznie wyższy niż koszt usługi.

Jak pracuje KC Mobile przy migracji

Prowadzimy migracje procesowo: audyt zerowy, kompletna mapa przekierowań 301, testy na środowisku staging i monitoring widoczności po wdrożeniu. Jeśli planujesz zmianę domeny, CMS albo redesign i zależy Ci na zachowaniu pozycji, sprawdź naszą usługę pozycjonowania SEO albo umów bezpłatną konsultację – przeanalizujemy Twoją sytuację i zaproponujemy bezpieczny plan.

Wniosek: im więcej zmiennych i im wyższa wartość ruchu, tym bardziej opłaca się migracja prowadzona przez specjalistę.