Migracja sklepu na własny serwer: krok po kroku, bez przestoju i utraty SEO

Migracja sklepu internetowego na własny serwer bez przestoju jest możliwa, jeśli wykonasz ją w odpowiedniej kolejności. Większość problemów, łącznie z utratą pozycji w Google i godzinami niedostępności sklepu, wynika z pomijania dwóch etapów: przygotowania środowiska przed przenosinami i zarządzania TTL przed przełączeniem DNS. Ten przewodnik prowadzi przez całą sekwencję.

Kiedy warto migrować na własny serwer?

Współdzielony hosting upycha tysiące sklepów na jednej maszynie. Przy nagłym skoku ruchu, np. po kampanii reklamowej, zasoby rozdzielają się między wszystkich najemców. Efekt to wolniejszy TTFB, kolejkowanie zapytań do bazy danych i błędy 503 w newralgicznym momencie.

Sygnały, że czas na migrację:

• Czas ładowania strony przekracza 3 sekundy przy normalnym ruchu
• Hosting nie gwarantuje izolacji zasobów (brak CloudLinux lub odpowiednika)
• Sklep ma ponad 500 unikalnych sesji dziennie
• Dostawca hostingu nie oferuje jasnego SLA na ciągłość działania
• Planujesz skalowanie, integracje z ERP lub wdrożenie konfiguratora produktów

Jak zaplanować migrację, żeby sklep nie przestał działać?

Migracja bez przestoju wymaga uruchomienia nowego środowiska równolegle z obecnym. Nie przenosi się sklepu, wyłączając stary serwer. Sklep działa na starym hostingu aż do momentu, gdy nowe środowisko jest w pełni przetestowane i gotowe do ruchu.

Ogólna sekwencja:

1. Przygotuj nowe środowisko (serwer, baza danych, PHP, LiteSpeed lub Nginx)
2. Sklonuj sklep na nowy serwer i skonfiguruj środowisko identycznie jak na produkcji
3. Przetestuj działanie na tymczasowym URL (np. staging.twojasklep.pl)
4. Obniż TTL domeny do 300 sekund na 48 godzin przed przełączeniem
5. Przełącz DNS na nowy serwer
6. Monitoruj przez 72 godziny, trzymaj stary serwer jako fallback

Checklista przed migracją

Serwer i środowisko: - [ ] PHP w wersji zgodnej z wersją WooCommerce lub Magento - [ ] Baza danych: MySQL 8.0+ lub MariaDB 10.6+ - [ ] LiteSpeed lub Nginx z poprawną konfiguracją cache - [ ] SSL zainstalowany i przetestowany na nowym IP - [ ] Izolacja zasobów (CloudLinux lub VPS z dedykowanym limitem RAM/CPU) - [ ] Kopie zapasowe zautomatyzowane co 24h z retencją minimum 14 dni

Dane i sklep: - [ ] Pełna kopia bazy danych (zrzut SQL ze starego serwera) - [ ] Wszystkie pliki sklepu (media, wtyczki, motywy, konfiguracja) - [ ] Klucze licencyjne wtyczek premium przepisane na nowy serwer - [ ] Konfiguracja płatności przetestowana w trybie testowym - [ ] Maile transakcyjne działają z nowego serwera (SPF, DKIM, DMARC)

SEO przed przełączeniem: - [ ] Crawl sklepu narzędziem Screaming Frog lub Ahrefs (zapisz obecny stan URL) - [ ] Plik robots.txt i sitemap.xml przeniesione bez zmian - [ ] Canonical URL zgodne z nową domeną - [ ] Zaindeksowanie nowego IP w Google Search Console (zweryfikuj własność) - [ ] Redirect 301 z HTTP na HTTPS skonfigurowany po stronie serwera

Jak zarządzać DNS, żeby uniknąć przestoju?

TTL (Time to Live) to czas, przez który serwery DNS cache'ują wpis. Domyślnie wynosi 3600 sekund (1 godzina) lub więcej. Jeśli przełączysz DNS bez wcześniejszego obniżenia TTL, część użytkowników przez kilka godzin nadal trafi na stary serwer, a część na nowy.

Schemat działania:

• 48h przed migracją: obniż TTL rekordu A domeny do 300 sekund
• Moment przełączenia: zmień rekord A na IP nowego serwera
• Po przełączeniu: trzymaj stary serwer aktywny przez minimum 72 godziny jako fallback
• Po 72h: podnieś TTL z powrotem do 3600 sekund

Ten schemat gwarantuje, że ewentualny rollback zajmuje 5 minut, nie 24 godziny.

Jak migracja wpływa na SEO i jak tego uniknąć?

Migracja sama w sobie nie powoduje utraty pozycji, o ile spełnione są trzy warunki: URL pozostają identyczne, przekierowania 301 są poprawne, a nowy serwer odpowiada szybciej lub równie szybko jak stary.

Najczęstsze błędy SEO przy migracji:

1. Zmiana struktury URL Każda zmiana URL to nowa strona dla Google. Jeśli `/produkt/krzeslo-dab` staje się `/shop/krzeslo-dab`, tracisz wszystkie linki i historię indeksowania. Jeśli musisz zmienić URL, wdrożenie 301 to minimum, ale efekt SEO i tak pojawi się po kilku tygodniach.

2. Zablokowanie indeksowania na staging Środowisko staging powinno mieć `robots.txt` z `Disallow: /` lub blokadę hasłem. Jeśli Google zaindeksuje staging, pojawia się problem duplikatów treści jeszcze przed uruchomieniem produkcji.

3. Brak weryfikacji Google Search Console dla nowego IP GSC wiąże weryfikację z domeną, nie z IP, więc technicznie nie tracisz dostępu. Ale po migracji warto sprawdzić, czy nie pojawiły się błędy serwera (kody 5xx) w raporcie Coverage.

4. Różny czas odpowiedzi serwera Jeśli nowy serwer ma gorszy TTFB niż stary (np. przez błędną konfigurację cache), Google odnotuje to jako pogorszenie sygnału Core Web Vitals. Przed przełączeniem DNS uruchom Lighthouse na tymczasowym URL i porównaj wyniki.

Typowe błędy przy migracji sklepu

Przenoszenie bazy bez sprawdzenia kodowania Baza na starym serwerze może używać utf8, nowy serwer może domyślnie ustawić utf8mb4. Przy imporcie bez jawnego określenia kodowania pojawiają się błędy w opisach produktów z polskimi znakami i emoji.

Pomijanie testów płatności Bramki płatności (Przelewy24, PayU, Stripe) często mają konfigurację IP w panelu merchantów. Po zmianie IP serwera webhook powrotu może przestać działać, co oznacza brak potwierdzenia zamówień. Zawsze przetestuj pełny cykl zamówienia na staging.

Brak monitoringu po przełączeniu Przez pierwsze 72 godziny po migracji sklep powinien mieć monitoring dostępności z alertem na email lub SMS. Błąd konfiguracji może pojawić się kilka godzin po przełączeniu, nie natychmiast.

Jak wygląda migracja w praktyce?

Przy wdrożeniu sklepu Sedan Home & Space środowisko docelowe działało równolegle przez dwa tygodnie przed przełączeniem DNS. W tym czasie przeprowadzono pełne testy wydajnościowe na danych produkcyjnych (kopia bazy bez danych osobowych), przetestowano integracje z systemem płatności i zweryfikowano poprawność przekierowań. Przełączenie zajęło 5 minut. Sklep nie miał ani minuty przestoju.

Własna infrastruktura NVMe z LiteSpeed i izolacją zasobów CloudLinux sprawia, że przy skokach ruchu sklep działa stabilnie niezależnie od obciążenia innych serwisów na serwerze. Szczegóły dotyczące infrastruktury opisuję na stronie Infrastruktura i utrzymanie.

Ile kosztuje migracja sklepu?

Koszt migracji zależy od złożoności sklepu i stanu obecnego środowiska.

Zakres	Orientacyjny koszt	Czas
Prosty sklep WooCommerce (do 500 SKU)	1 500–3 000 zł	3–5 dni roboczych
Sklep ze złożonymi integracjami (ERP, płatności, API)	3 000–8 000 zł	1–3 tygodnie
Migracja + optymalizacja wydajności + konfiguracja CDN	5 000–12 000 zł	2–4 tygodnie

W każdym przypadku w zakres wchodzi: konfiguracja środowiska, przeniesienie danych, testy, zarządzanie DNS i monitoring przez pierwsze 72 godziny po przełączeniu.