Redesign i zmiana CMS bez strat SEO

Redesign i zmiana CMS to jedna z najbardziej ryzykownych operacji w życiu strony internetowej. Badania z lat 2023–2026 pokazują, że 45% stron traci co najmniej 30% ruchu organicznego w ciągu 3 miesięcy po redesignie, a 15% nigdy nie wraca do poprzedniego poziomu. Ten artykuł to kompletny protokół wykonania redesignu lub migracji CMS bez strat SEO – 6-fazowy framework z 85 checkpointami, listą typowych błędów i realnymi przykładami z wdrożeń polskich i europejskich stron z ostatnich 30 miesięcy.

Nie chodzi tu o „jak zrobić ładniejszą stronę”. Chodzi o to, jak zmienić design, zachować pozycje, konwersję i autorytet domeny, który budowaliście latami. Prawidłowy redesign wymaga 2–4 miesięcy przygotowań, 4–8 tygodni wdrożenia i 3 miesięcy monitoringu – każdy etap z dedykowaną checklist’ą. Skracanie tego harmonogramu to gwarancja utraty ruchu.

Opisujemy redesign klasyczny (zmiana front-endu bez zmiany CMS), migrację CMS (np. z WordPress na Webflow, Shopify lub headless), i najtrudniejszy scenariusz – redesign + migracja CMS + zmiana struktury URL jednocześnie. Każdy scenariusz ma inny ryzyko profile i inne priorytety zabezpieczeń. Po przeczytaniu będziecie mieli pełen plan, jak wykonać to bezpiecznie – i jak przekonać zarząd, dlaczego nie warto tego robić „na szybko”.

Ocena ryzyka — jak oszacować wpływ na SEO

Nie każdy redesign jest tak samo ryzykowny. Macierz decyzyjna oparta na zakresie zmian pomaga przewidzieć skalę potencjalnych strat. Uzupełnieniem jest Migracja domeny krok po kroku — plan bez strat.

Matryca ryzyka redesignu

Zakres zmian	Poziom ryzyka	Typowe straty ruchu	Czas recovery
Tylko wizual (kolory, fonty, layout)	Niskie	0–10%	1–4 tygodnie
Wizual + zmiana struktury nawigacji	Średnie	10–25%	4–8 tygodni
Zmiana CMS (WP → Webflow)	Wysokie	20–40%	2–4 miesiące
CMS + zmiana struktury URL	Wysokie	25–50%	3–6 miesięcy
Headless migration + redesign	Bardzo wysokie	30–60%	3–9 miesięcy
Wszystko naraz + nowa domena	Ekstremalne	40–80%	6–12 miesięcy

Zasada kciuka: każda dodatkowa zmiana zwiększa ryzyko nieliniowo. Zmiana designu + struktury URL + CMS + hosting jednocześnie to nie 4× ryzyko, tylko 10× – bo każda zmiana wchodzi w interakcje z innymi. Rozdzielajcie fazy, nawet jeśli harmonogram się wydłuża.

Faza 1 — Audit pre-launch (4–6 tygodni przed)

Cel fazy: pełne zrozumienie aktualnej strony, co Google „lubi”, co generuje ruch, i co nie może zginąć. Bez tej fazy redesign jest strzałem w ciemno.

Checklist pre-launch (20 punktów)

1. Export sitemap XML aktualnej strony – pełna lista URL.
2. Crawl Screaming Frog – pełny snapshot meta, schema, internal links, canonicals.
3. Export GSC – top 1000 URL z impressions + clicks z ostatnich 16 miesięcy.
4. Export GA4 – top 500 landing pages by traffic + conversions.
5. Ahrefs / Semrush export – wszystkie URL z backlinkami (DR > 0).
6. Lista top 200 keywords – by ranking, z mapowaniem URL → keyword.
7. Snapshot Core Web Vitals – baseline przed zmianą.
8. Export schema markup – co jest, gdzie, w jakich typach.
9. Analiza struktury URL – czy zostaje identyczna? Jeśli nie – full mapping 1:1.
10. Analiza internal linking – graph linków, hub pages, orphan pages.
11. Analiza content – które strony mają unique value, których nie ma gdzie indziej?
12. Listy assets – obrazki, PDFy, wideo z własnymi URL.
13. Backup pełny – baza danych + pliki, przechowywany przez 12 miesięcy.
14. Dokumentacja hosting – dostęp, rekordy DNS, SSL.
15. Lista integracji – Google Search Console, GA4, Tag Manager, Bing, zewnętrzne narzędzia.
16. Lista wtyczek SEO – konfiguracja RankMath/Yoast do replikacji.
17. Redirects istniejące – inwentaryzacja wszystkich obecnych 301/302.
18. Stakeholder map – kto musi zaakceptować zmiany, kiedy, kto monitoruje.
19. KPI baseline – konkretne liczby, które definiują sukces/porażkę po redesignie.
20. Rollback plan – co zrobimy, jeśli wszystko pójdzie źle.

Efekt fazy 1 – dokument „Pre-Migration Snapshot” (40–80 stron) – absolutny baseline.

Faza 2 — Dev i design z SEO w pętli

Cel fazy: design i kod nowej wersji z SEO jako obowiązkowym reviewerem na każdym etapie. Nie jako akceptujący, tylko jako design input.

Checkpointy designerskie

• Struktura H1-H6 – czy zachowana, czy zmienia się hierarchia? Każda zmiana H1 to ryzyko rankingu.
• Tekst vs grafika – new design often zamienia tekstowe CTA na graficzne → Google nie czyta → ranking spada. Alt text + aria-label obowiązkowy.
• Lazy loading – czy jest? Czy działa z Google rendering?
• Hamburger menu vs widoczna nawigacja – ma znaczenie dla internal link juice na mobile.
• Footer links – czy zachowane? Footer często niedoceniony, a trzyma site-wide linki do kluczowych stron.
• Breadcrumbs – implementacja JS vs HTML ma znaczenie.
• Infinite scroll – Googlebot go nie lubi. Paginacja lepsza dla SEO.

Checkpointy developerskie

• Server-side rendering vs client-side – JS frameworks (React, Vue) potrzebują SSR dla SEO.
• Meta tags dynamic – czy każda strona ma swoje meta, nie jeden globalny?
• Schema markup – replikacja + rozszerzenie. Nie gubcie Article schema na blogach, Product na e-commerce.
• Sitemap XML – regeneracja na nowej stronie.
• Robots.txt – identyczny (lub lepszy) niż stary.
• Canonical tags – pełna konfiguracja self-referencing per strona.
• Hreflang (jeśli wielojęzyczna) – pełna migracja.
• HTTP headers – cache-control, CORS, security headers.
• SSL / HSTS – konfiguracja bez downgrade’u.

Staging environment — warunek konieczny

Wszystko testujecie na staging.domena.pl lub subdomain z noindex. Testujecie tam pełen flow: 200 URL próbek sprawdzonych vs stary stan. Bez staging’u – nie wolno uruchamiać migracji.

Faza 3 — QA SEO przed go-live (2 tygodnie przed)

Cel fazy: wykrycie wszystkich problemów, które migracja wprowadzi przed faktycznym cutover.

15 krytycznych testów SEO na staging

1. Crawling staging’u Screaming Frog’iem – pełen crawl + porównanie z baseline’m produkcji.
2. URL mapping 1:1 – każdy stary URL ma redirect na nowy? Brak ślepych 404.
3. Meta tags check – czy każda strona ma title i description? Czy są identyczne z produkcji dla 95%+ stron?
4. H1 check – identyczny lub equivalent na każdej kluczowej stronie.
5. Schema validation – Google Rich Results Test + Schema.org validator dla top 20 typów stron.
6. Internal links – czy linki wewnętrzne prowadzą do poprawnych nowych URL?
7. External links – czy nie gubimy ważnych outbound links?
8. Images + alt text – czy są wszystkie + alt?
9. Canonical check – czy poprawne self-referencing wszędzie?
10. Hreflang – czy multijęzyk działa po migracji?
11. Page speed – LCP, INP, CLS na kluczowych stronach. Nie gorsze niż produkcja.
12. Mobile rendering – Googlebot Smartphone user-agent test.
13. JavaScript rendering – Mobile-Friendly Test + URL Inspection w GSC (dla staging).
14. Sitemap XML – generuje się poprawnie, zawiera wszystkie URL.
15. Robots.txt – konfiguracja identyczna lub lepsza niż produkcja.

Red flags — kiedy zatrzymać migrację

• > 5% URL mappings niemapowalnych (stary URL nie ma nowego odpowiednika).
• LCP > 30% wolniejsze niż produkcja.
• Schema errors na > 10% kluczowych typów stron.
• Meta tags missing na > 2% stron.
• Internal links prowadzące do 404 w staging’u (wskazuje, że produkcja też będzie zepsuta).

Jeśli choć jeden red flag jest obecny – odraczacie go-live. Koszt opóźnienia o 2 tygodnie < koszt utraty 30% ruchu na 3 miesiące. Szczegóły migracji domeny jako osobnego scenariusza – Migracja domeny krok po kroku — plan bez strat.

Faza 4 — Cutover (go-live)

Cel fazy: przełączenie na nową wersję z minimalizacją downtime’u i maksymalną kontrolą. Ta faza trwa 2–24 godziny, zależnie od skali.

Harmonogram cutover’u (standardowy)

1. T-24h: ostatni backup bazy + plików produkcji. Weryfikacja dostępu do hostingu.
2. T-12h: sitemap nowej strony wgrana do GSC jako „pending” (dla szybszej indeksacji).
3. T-2h: zamrożenie zmian w CMS (żadnych nowych postów, żadnych edycji).
4. T-1h: final diff staging vs production – czy nic się nie zmieniło?
5. T-0: DNS switch lub deployment do produkcji. Odpalajcie w godzinach niskiego ruchu (niedziela 3:00 vs poniedziałek 10:00).
6. T+15 min: smoke tests – top 10 URL ręcznie, GSC URL inspection dla 5 krytycznych.
7. T+1h: full regression test – crawl produkcji, diff z staging.
8. T+4h: submit nowej sitemap do GSC. Request reindex’u dla top 50 URL.
9. T+24h: pierwszy check GSC errors + traffic GA4.

Rollback trigger’y

• Ruch z Google spada o >40% vs ten sam czas poprzedniego tygodnia.
• Kluczowe strony (top 10 by traffic) są 404.
• Server errors (5xx) na >5% requests.
• Core Web Vitals w czerwonym (LCP >4s, INP >500ms).

Jeśli któryś trigger się aktywuje – rollback w ciągu 2 godzin. Nie debatujcie, wracajcie do starej wersji. Analiza przyczyn, naprawa, drugi cutover za tydzień.

Faza 5 — Hypercare (2 tygodnie po go-live)

Cel fazy: intensywny monitoring i szybkie reagowanie na problemy, które zawsze się pojawiają w pierwszych dniach.

Daily checks (pierwsze 14 dni)

1. GSC Coverage – czy errors rosną?
2. GSC URL Inspection – sample 10 URL dziennie. Czy Google renderuje poprawnie?
3. GA4 Traffic – organic traffic vs baseline. Akceptowalne 10–20% spadek w tygodniu 1, wracające w tygodniu 2–3.
4. Ahrefs / Semrush rankings – top 100 keywordów. Spadki powyżej 5 pozycji = investigate.
5. Broken links check – zewnętrzne narzędzia + Ahrefs broken backlinks.
6. Page speed – LCP, INP dla top 20 landing pages.
7. 404 errors – GSC + raport serwera. Każdy 404 do mapowania.
8. Log analysis – crawling Googlebot’a, czy nie ma blokad.

Weekly checks (tydzień 3–4)

• Pełen audit Screaming Frog – porównanie z baseline’em przed migracją.
• Raport dla zarządu – gdzie jesteśmy vs plan.
• Action items na kolejny tydzień.

Faza 6 — Retrospekcja (miesiąc po)

Cel fazy: nauka z procesu, dokumentacja problemów, plan długoterminowy optymalizacji.

Pytania retrospektywne

1. Gdzie byliśmy przewidujący? Gdzie nas zaskoczyło?
2. Które checkpointy były kluczowe? Które były nadmiarowe?
3. Jaka była rzeczywista strata ruchu vs prognoza?
4. Kiedy realistycznie wrócimy do baseline’u?
5. Jakie action items na kolejny kwartał?

Dokumentacja dla następnego redesignu

Każda firma robi redesign raz na 3–5 lat. Zespół, który dziś zrobił migrację, za 3 lata nie będzie pamiętał szczegółów. Dobra dokumentacja – 15–30 stron Notion/Confluence – pozwala następnej operacji być o 50% szybszą i bezpieczniejszą.

Szczególne przypadki — WordPress, Webflow, headless

WordPress → WordPress (rebrand)

Najłatwiejsze. Zachowujecie bazę, ID-ki postów, permalinks. Zmieniacie motyw, może wtyczki. Ryzyko – głównie zmiana designu psująca internal links (np. nowy motyw nie ma widgetu „related posts” na wszystkich stronach). Czas – 4–8 tygodni, budżet 25 000–80 000 PLN.

WordPress → Webflow / Framer

Średnio trudne. Tracicie WordPress-specific funkcje (custom fields, dedykowane wtyczki). Wymaga rebuild contentu w nowym CMS + migracji media. URL struktura musi być kompatybilna z Webflow permalinks (ograniczone). Czas – 3–5 miesięcy, budżet 60 000–200 000 PLN.

WordPress → Headless (Next.js / Astro + WP jako backend)

Trudne, ale ma sens performance’owo. WordPress zostaje jako CMS, frontend to statyczna strona generowana. Pełna kontrola nad SEO metadata, performance, strukturą URL. Czas – 4–7 miesięcy, budżet 100 000–400 000 PLN. Best for enterprise sites z dużą ilością treści.

Shopify → Shopify (rebrand sklepu)

Ograniczenia platformy są silne. URL struktura produktu /products/X niezmienna. Headless Shopify (Hydrogen) dla więcej kontroli, ale znaczny koszt dev. Czas – 6–16 tygodni, budżet 40 000–120 000 PLN.

Magento → Shopify

Jedna z najtrudniejszych migracji. Całkowita zmiana architektury, modeli danych, URL struktury. Wymaga specjalisty e-commerce migration. Czas – 6–12 miesięcy, budżet 200 000–800 000 PLN. Wpływ na SEO – realnie 30–50% strat ruchu w pierwszych 6 miesiącach.

URL mapping — serce migracji SEO

Jeśli robicie choć jedną rzecz w migracji – to mapowanie URL. Każdy stary URL musi mieć zdefiniowany 301 redirect na nowy odpowiednik. Brak mappingu = 404 = utrata ruchu.

Proces mapowania

1. Export wszystkich URL ze starej strony (sitemap + crawl Screaming Frog).
2. Export wszystkich URL nowej strony (staging sitemap).
3. Dla każdego starego URL – znajdźcie nowy odpowiednik (identyczna treść lub najbliższa semantycznie).
4. Dla URL bez odpowiednika – decyzja: redirect do kategorii (bliższa strona) lub 410 Gone.
5. CSV z kolumnami: old_url, new_url, status_code (301 dla 99% przypadków).
6. Wdrożenie redirects – na serwerze (nginx/apache) lub plugin (Redirection WordPress).
7. Weryfikacja – każdy stary URL zwraca 301 → 200 na nowy URL.

Narzędzia do mapowania URL

• Excel / Google Sheets – dla stron do 1000 URL, manual mapping.
• VLOOKUP / regex – dla stron 1000–10000 URL, semi-auto.
• Python script – dla stron 10000+ URL, fuzzy match contenu.
• AI-assisted mapping (OpenAI + content similarity) – dla bardzo dużych migracji.

Szczegóły zmiany struktury URL – Migracja struktury URL: kiedy warto.

Techniczne detale implementacji redirects

URL mapping to jedno, ale techniczna implementacja 301 redirects to osobna dyscyplina. Różnice między implementacjami mogą oznaczać 20% różnicy w efektywności przekazywania link juice’u.

Nginx redirects — standard enterprise

Dla stron high-traffic standardem jest Nginx + plik konfiguracyjny z map directive. Zalety: szybkie (10–50 μs per redirect), skalowalne do milionów reguł, wersjonowalne w Git. Wada: wymaga dostępu do serwera i restarta konfigu przy zmianach.

WordPress Redirection plugin

Dla WordPress z do 10 000 redirects – plugin Redirection (John Godley) jest standardem. Plusy: łatwe UI, import CSV, logi 404, monitoring. Minusy: każdy redirect to zapytanie do bazy WordPress = dodatkowe 5–20ms TTFB. Dla stron powyżej 10 000 redirects – migrujcie do server-level.

Cloudflare Page Rules

Dla projektów używających Cloudflare – Page Rules robią redirects na edge (przed serwerem). Super szybkie, ale ograniczone (100 reguł w starter, 125 w Enterprise). Dobrze dla top-level patterns, nie dla massowej migracji 50 000 URL.

Kluczowe zasady przy redirects

• Zawsze 301 (permanent), nie 302 – 302 nie przekazuje link juice’u, 301 tak.
• Unikajcie redirect chains – A → B → C to strata 10–15% link juice’u. Zawsze A → C bezpośrednio.
• Nie redirectujcie do homepage – strony bez odpowiednika dajcie 410 Gone lub redirect do najbliższej kategorii, nie do /.
• Monitoring 404 – po go-live w GSC zawsze jest kilka 404, które trzeba dopasować. Log requestów 404 przez 4 tygodnie i dodawajcie redirects na bieżąco.
• Trailing slash consistency – decyzja raz: wszystkie URL z lub bez /, konsekwentnie. Redirect dla niezgodnych.

Mobile-first UX a SEO

Od 2019 Google używa mobile-first indexing – mobilna wersja decyduje o ranking’u. Redesign, który zapomina o mobile, jest gwarantowanym spadkiem pozycji.

Mobile checkpointy w redesignie

• Content parity – czy mobilna wersja pokazuje tę samą treść co desktop? Ukryte sekcje na mobile = niewidoczne dla Google.
• Structured data mobile – czy schema.org obecne w mobile, identyczne z desktop?
• Internal linking mobile – hamburger menu ukrywa linki, ale Google je widzi. Ważne, żeby były w HTML, nie wstrzykiwane przez JS.
• Mobile Core Web Vitals – zwykle gorsze niż desktop ze względu na słabsze CPU i wolniejsze połączenia. LCP < 2,5s dla 75 percentyla mobile użytkowników to minimum.
• Touch targets – buttony >48px i min 8px spacing między klikalnymi elementami. Google penalizuje strony z „tap targets too close”.

Responsive vs dedykowana mobilna wersja

W 2026 responsive to standard. Dedykowana m.domena.pl (mobile subdomain) to anti-pattern – powoduje duplicate content, confusion w hreflang, osobne crawl budget. Jeśli macie jeszcze m.domain.pl, redesign to idealny moment na migrację do responsive na głównej domenie z 301 redirects z m.*.

Najczęstsze błędy redesignu

• Skipping audit pre-launch – „zrobimy audyt po go-live”. Nie. Po go-live jest za późno.
• No staging environment – testy tylko na produkcji. Gwarantowana katastrofa.
• URL mapping as afterthought – robiony w ostatnim tygodniu. Za późno, za powierzchownie.
• Ignoring schema markup – nowy design bez schema = utrata rich snippets.
• New design bez mobile-first thinking – mobile-first indexing oznacza, że mobilna wersja decyduje o ranking’u.
• Go-live w poniedziałek rano – maksymalna eksporcja ruchu w momencie problemów. Niedziela nocą lub wtorek wieczorem.
• Zmiana CMS + struktury URL + designu naraz – 10× ryzyko. Rozdzielcie fazy.
• Brak rollback plan’u – co robicie, gdy nowa wersja nie działa? Nie wiedzieć to katastrofa.
• Ignoring internal linking – nowy design zmienia nawigację, internal link graph się rozpada.
• Page speed regression – nowy design ładniejszy, ale 2× wolniejszy. LCP > 3s = ranking spada.

Koszty redesignu SEO-bezpiecznego

Koszt audytu pre-launch + QA SEO + monitoring to zwykle 25–40% kosztu całego projektu redesignu. Firmy, które oszczędzają na tym, tracą 5–10× więcej w zgubionym ruchu.

Budżet wg skali (PLN)

Rozmiar strony	Budżet dev+design	Budżet SEO	Łączny
Mała strona (<100 URL)	15 000–40 000	5 000–12 000	20 000–52 000
Średnia strona (100–1000 URL)	40 000–150 000	15 000–40 000	55 000–190 000
Duża strona (1000–10000 URL)	150 000–500 000	40 000–120 000	190 000–620 000
Enterprise (10000+ URL)	500 000–2 000 000	100 000–400 000	600 000–2 400 000

Zarządzanie treścią podczas redesignu

Redesign to naturalny moment, żeby przejrzeć istniejący content i zrobić porządki. 20–30% starej treści jest zwykle thin content, który nic nie wnosi i obciąża crawl budget. Ale decyzja „usuńcie” vs „zostawcie” wymaga metodyki.

Macierz decyzyjna content audit

Ruch organiczny / mc	Backlinks	Decyzja
>100 UU	Nie ma znaczenia	Zachować, odświeżyć
10–100 UU	>3 linki jakości	Zachować, rozbudować
10–100 UU	0–2 linki	Rozbudować do 2500+ słów lub skonsolidować
<10 UU	>5 linków	301 do powiązanej strony
<10 UU	0–2 linki	410 Gone lub noindex

Konsolidacja thin content

3 krótkie artykuły po 800 słów na powiązany temat? Skonsolidujcie w jeden 2 500-słów pillar. Powody: lepszy ranking (pełne pokrycie tematu), więcej internal link juice w jednym miejscu, lepsze user experience. Proces: wybrać „zwycięski” URL (najwięcej ruchu lub najlepszy link profile), 301 redirects z pozostałych, merge treści ze stylem jednolitym.

Odświeżanie starszych artykułów

Artykuły 3–5 lat stare często mają statystyki z epoki pre-COVID, referencje do narzędzi, które zniknęły, przykłady z 2019. Redesign to moment na refresh: aktualne dane, nowe screenshoty, zaktualizowany CTA. Artykuły po refresh zwykle notują 20–40% wzrost ruchu w 3 miesiące.

Komunikacja ze stakeholderami

Redesign to nie tylko projekt techniczny. To projekt zarządzania oczekiwaniami zarządu, klientów zewnętrznych, zespołu sales. Brak komunikacji = panic dla spadku ruchu w tygodniu 1.

Co komunikować przed go-live

• Zarząd – 4 tygodnie przed. Pełna prezentacja ryzyk, oczekiwanych spadków, timeline’a recovery. Decyzja „tak/nie” należy do zarządu.
• Sales team – 2 tygodnie przed. Ostrzeżenie o możliwych spadkach leadów, plan komunikacji do klientów, telefon awaryjny do SEO team’u.
• Klienci (agencja) – 1 tydzień przed. Email informacyjny z timelineem i KPI monitored. Set expectations.
• Cały zespół – 3 dni przed. Konkretny harmonogram go-live i rola każdej osoby.

Co komunikować po go-live

• Daily standup w pierwsze 2 tygodnie – 15-minutowy update dla wszystkich stakeholderów.
• Weekly report w tygodniach 3–8 – pełen dashboard z KPI.
• Monthly executive summary w miesiącach 2–6 – ROI updates.
• Alerty real-time – gdy aktywują się rollback trigger’y, cały zespół wie w 5 minut.

Jak zarządzać paniką zarządu

Tydzień 1 po redesignie zwykle traci 10–20% ruchu – to normalne. Zarząd widzi liczby, panikuje. Przygotowane materiały komunikacyjne: baseline oczekiwań („10–20% spadku to normalne, wracamy w 4 tygodnie”), porównanie z case’ami z branży („Google zrobił redesign w 2022, stracił 30% na 8 tygodni, potem wrócił z boost’em”), konkretne action items („monitorujemy daily, mamy dwie wykryte i naprawione issues”). Bez tych materiałów zarząd chce rollback, który czasem wcale nie jest potrzebny.

Case study — redesign agencji marketingowej

Polska agencja B2B, 8 000 UU/mc organic, 450 URL. Redesign w 2025 – zmiana designu + konsolidacja blogów + dodanie landing pages per service.

Wykonane kroki

• Audit pre-launch: 6 tygodni, znaleziono 23 issues krytyczne w starej wersji (brak hreflang na EN wersji, duplicate content z sub-sites, wolny LCP).
• URL mapping: 450 URL → 380 URL (70 skonsolidowane przez merge). 100% redirects 301.
• Nowy CMS: WordPress → headless Next.js + WP backend.
• Go-live: niedziela 4:00 rano, cutover trwał 6 godzin.
• Hypercare: 2 tygodnie daily checks, 2 rollback triggers aktywowane i rozwiązane bez rollback’u.

Wyniki po 3 miesiącach

Organic traffic – spadł o 12% w pierwszym tygodniu, wrócił do baseline’u w tygodniu 4, przekroczył go o 18% w tygodniu 12. Rankings – 85% keywords wróciło do starej pozycji w 4 tygodnie, 15% wymagało rebuild’u content’u. Page speed – LCP poprawiony z 3,2 s do 1,4 s. Konwersje – +28% dzięki lepszemu UX.

Lekcje z case’u

• Audyt pre-launch zapłacił za siebie 3× w uniknięciu błędów.
• Konsolidacja blogów (usunięcie thin content) dała boost SEO długoterminowo.
• Hypercare 2 tygodnie – za krótkie. Następnym razem 4 tygodnie daily + 8 weekly.
• Headless Next.js dał +200% page speed, ale wymaga stałego utrzymania dev’a.

Metodykę audytu, która jest częścią fazy pre-launch, znajdziecie w Audyt SEO 2026: metodyka, która znajduje problemy.

FAQ — najczęstsze pytania

Czy można zrobić redesign bez strat SEO?

Tak, ale wymaga 2–4 miesięcy przygotowań i dedykowanego SEO resource. Straty 0–5% są normalne (krótka turbulencja), 5–15% akceptowalne dla redesignu ze zmianą CMS, powyżej 20% – błąd procesu. Największe ryzyko – strony, które próbują „zmienić wszystko naraz” w 4 tygodnie. Podzielcie na fazy.

Ile kosztuje redesign z pełną ochroną SEO?

Dla małej strony 20 000–50 000 PLN, dla średniej 55 000–190 000 PLN, dla dużej 190 000–620 000 PLN. Komponent SEO to 25–40% całkowitego budżetu (audyt + URL mapping + QA + monitoring). Oszczędność na SEO kończy się zawsze utratą ruchu, która kosztuje więcej niż oszczędność.

Kiedy najlepiej zrobić go-live redesignu?

Niedziela 3:00–5:00 rano czasu polskiego. Minimum ruchu organicznego (weekend noc), pełny zespół dostępny poniedziałek na hypercare. Unikajcie: piątek (brak support przez weekend), wtorek–czwartek rano (peak traffic), miesiące Black Friday / Święta (reklama płatna spięta z organic, spadek tamże drogo kosztuje).

Jak długo trwa powrót do baseline’u ruchu po redesignie?

Zależnie od skali zmian. Tylko design – 2–4 tygodnie. Design + CMS – 6–10 tygodni. Design + CMS + URL – 3–6 miesięcy. Redesign enterprise z pełną migracją – 6–12 miesięcy. To „normalny” powrót. Jeśli nie wracacie w tym czasie, problem jest głębszy i wymaga re-audytu.

Czy zachowanie identycznej struktury URL jest konieczne?

Dla maksymalnego bezpieczeństwa – tak. Dla pragmatycznego projektu – nie zawsze. Jeśli stara struktura jest zła (np. /?p=123, długie URL-y, brak hierarchii), nowa struktura z 301 redirects jest lepsza długoterminowo. Koszt – spadek ruchu 5–15% przez 2–4 miesiące, potem zwrot + lepsze CTR. Planujcie to świadomie.

Co zrobić, gdy po redesignie ruch spada o 40%?

Krok 1 – analiza przyczyn (GSC errors, 404s, page speed, indexation). Krok 2 – priorytetyzacja napraw. Krok 3 – decyzja o rollback’u vs naprawy in place. Jeśli można naprawić w 2 tygodnie – naprawcie. Jeśli nie – rollback jest często właściwy. Najlepiej mieć decyzję rollback’u przygotowaną przed go-live, nie po panice.

Czy można migrować WordPress na headless bez strat SEO?

Tak, ale wymaga specjalisty Next.js/Astro + SEO z headless knowledge. Kluczowe: server-side rendering dla wszystkich stron indeksowanych, dynamic meta tags per URL, poprawne schema generation, sitemap z pełną listą URL. Headless bez tych elementów daje 50%+ spadek ruchu. Ale z nimi – headless może poprawić SEO (lepsze Core Web Vitals).

Ile osób potrzebuje zespół redesignu dbającego o SEO?

Minimum 3 – designer, developer, SEO specialist. Dla średnich projektów 5 – dodatkowo PM i QA engineer. Dla dużych 8–12 – zespół z osobnymi rolami front/backend, content strategist, testerzy wydajnościowi. Krytyczne – SEO specialist nie może być part-time’owym konsultantem, musi być obecny na wszystkich daily meetingach.

Co dalej

Jeśli chcesz pogłębić temat, sprawdź SEO 2026: kompletny przewodnik po technicznym, contentowym i międzynarodowym SEO. Przydatne będzie też Migracja domeny krok po kroku — plan bez strat — oba materiały dobrze uzupełniają powyższy artykuł.