Redesign strony to moment, w którym najczęściej znika ranking SEO. Zła migracja = miesiące pracy odwrócone w jednym deployu. Dobra wiadomość: jeśli postępujesz metodycznie, redesign może wręcz podnieść pozycje (bo szybsza strona = lepsze Core Web Vitals = lepszy ranking). Ten artykuł to checklista, którą przechodzimy na każdej migracji.
Krok 1: Audyt przed redesignem
Zanim cokolwiek zmienisz, zrób snapshot stanu obecnego.
- Eksport listy wszystkich URL-i (Screaming Frog: Crawl → Export → All URLs)
- Eksport pozycji w Google: Search Console → Performance → Export
- Top 50 stron wg ruchu — zaznacz i zachowaj URL-e
- Top 100 fraz wg pozycji — zachowaj listę razem z aktualnymi rankingami
- Backlinki: Ahrefs / SEMrush — które domeny linkują, do których URL-i
Bez tego nie wiesz, co zachować. Ślepa migracja = utracona praca SEO.
Krok 2: Mapa URL — stary → nowy
Najczęstszy błąd: zmienia się struktura URL-i bez planu przekierowań. Każdy URL, który się zmienia, MUSI mieć przekierowanie 301 do nowego adresu.
Excel z dwoma kolumnami: stary URL i nowy URL. Dla wszystkich top 50–100 stron. Plus reguły wzorcowe (np. /produkty/* → /sklep/*).
Czego nie robić: 302 (temporary) zamiast 301 (permanent) — Google nie przekazuje wartości SEO przy 302. 404 zamiast przekierowania — ranking ginie.
Krok 3: Zachowaj strukturę treści
Twój ranking opiera się na:
- Tytułach stron (
<title>) i nagłówkach<h1> - Strukturze treści — nagłówki H2, paragrafy, listy
- Słowach kluczowych w treści
- Linkach wewnętrznych (anchor text)
Redesign UI nie powinien zmieniać tych elementów. Jeśli stara strona o usłudze ma w <h1> „Tworzenie stron WWW” i ma ranking — nowa wersja MUSI mieć ten sam <h1>. Możesz zmienić wszystko inne wokół, ale nie kluczowe SEO elementy.
Krok 4: Środowisko staging
Buduj na osobnym subdomenie typu staging.twojadomena.pl. To środowisko musi mieć:
- `<meta name="robots" content="noindex, nofollow">` — żeby Google nie zaczęło indeksować staging
- Hasło HTTP Basic Auth lub IP whitelisting — staging jest dla Was, nie publiczny
- Pełna kopia treści produkcyjnej — testujesz na realnych danych
Krok 5: Testy przed publikacją
Przed migracją musisz mieć checklistę:
- Lighthouse — Performance, SEO, Best Practices, Accessibility (każdy ≥ 90)
- Wszystkie URL-e ze starej strony otwierają się na stagingu (301 lub bezpośrednio)
- Sitemap.xml zawiera wszystkie nowe URL-e
- Schema.org valid (Google Rich Results Test)
- Mobile-friendly test pass
- Brak broken linków (Screaming Frog crawl)
Krok 6: Migracja — nocą, z planem rollback
Migrację robi się w godzinach najmniejszego ruchu (zwykle 2–6 rano). Plan:
- Backup obecnej strony (kompletny — pliki + baza)
- Włączenie maintenance mode na 5–15 minut
- Deployment nowej wersji
- Sprawdzenie 5–10 kluczowych URL-i (czy się otwierają, czy 301-y działają)
- Wyłączenie maintenance mode
- Submit nowy sitemap.xml w Search Console
Plan rollback: jeśli coś nie działa, wracamy do backupu. Nie ma czasu na panikowanie o 3 nad ranem — to musi być przygotowane.
Krok 7: Monitoring po publikacji
Pierwszych 4 tygodni to zwykle delikatne wahania pozycji. Monitor:
- Search Console — Coverage — czy nowe URL-e są indeksowane, czy nie ma błędów
- Search Console — Performance — pozycje top 100 fraz, dziennie
- Crawl errors — 404, server errors
- Core Web Vitals — czy się poprawiły (powinny)
Typowy pattern: pierwszy tydzień lekki spadek (~5–10% ruchu), drugi tydzień stabilizacja, trzeci-czwarty tydzień powrót do normy + często wzrost (jeśli nowa strona jest szybsza).
Najczęstsze błędy
- Brak 301-ów dla zmienionych URL-i (zamiast tego 404)
- 302 (temporary) zamiast 301 (permanent)
- Zmiana
<h1>i meta title na podstronach z rankingiem - Zapomnienie sitemap.xml po migracji
- Blokada
/_next/(Next.js) lub/wp-content/(WP) w robots.txt — Google nie może renderować - Brak monitoringu po — „wszystko działa, można zapomnieć”