Co sprawdzić przed redesignem strony?

SEO • REDESIGN / MIGRACJA

Redesign może poprawić wygląd, UX, szybkość i strukturę strony.

Może też przypadkowo usunąć:

• URL, które rankują,
• treści generujące ruch,
• backlinki prowadzące do ważnych podstron,
• poprawne canonical,
• linkowanie wewnętrzne,
• dane strukturalne,
• ustawienia indeksacji.

Dlatego przed przebudową warto zrobić jedną rzecz, która nie ma nic wspólnego z nowym layoutem:

zinwentaryzować wartość starej strony.

Najgorszy scenariusz wygląda tak:

projektujemy wszystko od zera → zmieniamy URL → usuwamy „stare” treści → publikujemy → po kilku tygodniach widoczność spada

A potem zaczyna się odtwarzanie tego, co można było zachować od początku.

Dobra kolejność jest odwrotna:

najpierw dane → potem decyzje → potem design → potem migracja.

Krótka odpowiedź: co sprawdzić przed redesignem?

Przed redesignem sprawdź:

1. które URL generują ruch i impressions,
2. które strony mają backlinki,
3. jakie queries są przypisane do poszczególnych URL,
4. które URL powinny zostać bez zmian,
5. które można połączyć,
6. które rzeczywiście trzeba usunąć,
7. jaki będzie mapping stary → nowy URL,
8. canonical,
9. noindex i robots,
10. internal linking,
11. sitemapę,
12. structured data,
13. title i H1,
14. Core Web Vitals i mobile,
15. formularze i konwersje,
16. GA4/GTM/GSC,
17. staging,
18. redirecty,
19. plan testów przed launch,
20. plan monitoringu po wdrożeniu.

Jeżeli redesign zmienia tylko wygląd i dobre URL mogą zostać, nie zmieniaj ich bez powodu.

1. Zrób listę wszystkich istniejących URL

Nie zaczynaj od menu.

Zacznij od pełnej listy adresów.

Źródła:

• sitemap XML,
• crawl,
• CMS,
• Google Search Console,
• analytics,
• server logs, jeśli są potrzebne,
• backlink tools.

Dlaczego sam sitemap nie wystarczy?

Może nie zawierać:

• starych URL,
• stron usuniętych z sitemap, ale nadal mających ruch lub backlinki,
• dawnych landing pages,
• URL z redirectami,
• plików i zasobów.

Google w dokumentacji migracji rekomenduje zaczynać od najważniejszych URL i korzystać między innymi z sitemap, analytics, Search Console i logów.

2. Oznacz URL, które mają wartość SEO

Nie każda stara strona musi zostać.

Ale każda powinna zostać oceniona.

Dla każdego URL warto zebrać:

• kliknięcia,
• impressions,
• średnią pozycję,
• główne queries,
• backlinki,
• internal links,
• konwersje,
• znaczenie biznesowe.

Prosta tabela

Stary URL	Ruch SEO	Backlinki	Biznes	Decyzja
/usluga-a/	wysoki	tak	wysoki	zachować
/stara-promocja/	brak	brak	brak	usunąć
/oferta-old/	średni	tak	średni	301 do nowej
/blog-temat/	wysoki	tak	wspiera usługę	zachować

To jest znacznie bezpieczniejsze niż ocena:

„ta podstrona wygląda staro, więc ją usuwamy”.

3. Sprawdź Google Search Console przed zmianami

GSC pokazuje, jak Google już rozumie stronę.

Przed redesignem eksportuj:

• Queries,
• Pages,
• kliknięcia,
• impressions,
• CTR,
• average position.

Najlepiej za okres wystarczająco długi, aby zobaczyć:

• sezonowość,
• wcześniejsze wzrosty,
• strony, które tylko czasami generują ruch.

Szczególnie ważne

Szukaj stron:

• z dużą liczbą impressions,
• blisko TOP 10,
• z wysokim CTR,
• generujących ruch na ważne usługi,
• które wyglądają niepozornie, ale mają historyczne znaczenie.

4. Nie oceniaj strony tylko po kliknięciach

URL może mieć:

• mało kliknięć,
• ale dużo impressions,
• pozycję 11–15,
• dobre backlinki.

Taka strona może być dobrym kandydatem do poprawy, a nie usunięcia.

Redesign jest okazją, aby:

• poprawić UX,
• rozbudować treść,
• lepiej linkować,
• zachować ten sam URL.

5. Sprawdź backlinki do konkretnych stron

Nie wystarczy wiedzieć, ile backlinków ma domena.

Trzeba sprawdzić: do jakich URL prowadzą.

Jeżeli zewnętrzna strona linkuje do: /stary-poradnik/

a nowy projekt usuwa ten URL bez redirectu, link trafia na 404.

Co zrobić?

Jeżeli istnieje:

• ten sam content → zachowaj URL,
• nowy odpowiednik → 301/308 do odpowiednika,
• połączona treść → redirect do skonsolidowanej strony,
• brak odpowiednika → 404/410 może być uczciwsze niż przypadkowy redirect.

6. Zachowaj dobre URL, jeśli nie ma powodu ich zmieniać

Redesign nie wymaga nowych slugów.

Jeżeli adres:

• jest logiczny,
• ma ruch,
• ma linki,
• odpowiada tej samej treści,

zwykle najlepiej go zachować.

Nie zmieniaj URL tylko dlatego, że nowy wygląda „ładniej”

Przykład:

stary: /tworzenie-stron-internetowych/

nowy pomysł: /uslugi/strony-www-dla-firm/

Jeżeli stary URL ma już historię i właściwy intent, nowa struktura może nie dać wystarczającej korzyści, aby uzasadnić migrację.

7. Zrób mapping stary URL → nowy URL

Jeżeli URL rzeczywiście się zmieniają, przygotuj tabelę przed wdrożeniem.

Przykład:

Stary URL	Nowy URL	Akcja
/stara-usluga/	/nowa-usluga/	301
/blog/a/	/wiedza/a/	301
/stara-promocja/	—	410
/kontakt-old/	/kontakt/	301

Google oficjalnie rekomenduje przygotowanie mappingu starych i nowych URL jako centralnego elementu migracji.

Mapping powinien być znaczeniowy

Nie:

wszystko → homepage

Tylko:

stary URL → najbardziej odpowiadający nowy URL

Google ostrzega, że masowe przekierowanie niepowiązanych stron na homepage może zostać potraktowane jak soft 404.

8. Używaj permanentnych redirectów przy trwałej zmianie

Dla trwałej zmiany URL Google rekomenduje server-side permanent redirects:

• 301,
• 308.

Nie trzeba bać się, że sam 301 „zabiera moc SEO”.

Google w aktualnej dokumentacji jasno mówi, że permanent redirects nie tracą PageRank tylko dlatego, że są przekierowaniami.

Problemem są raczej:

• brak redirectu,
• redirect do złej strony,
• chain,
• loop.

9. Unikaj redirect chains

Słaby przykład:

A → B → C → D

Lepszy:

A → D

Googlebot potrafi podążać za wieloma redirectami, ale Google zaleca ograniczać chains.

Powód jest praktyczny:

• większe opóźnienie,
• większa złożoność,
• większe ryzyko błędu.

Przed launch

Przetestuj wszystkie stare ważne URL.

Nie tylko nowe menu.

10. Sprawdź canonical

Po redesignie canonical często psuje się przez:

• zmianę CMS,
• nowy template,
• staging,
• plugin SEO,
• automatyczne generowanie adresów.

Każdy ważny nowy URL powinien mieć właściwy canonical.

Jeżeli URL pozostał ten sam:

• canonical powinien nadal wskazywać ten sam właściwy adres.

Jeżeli URL się zmienił:

• nowa strona powinna wskazywać nowy canonical,
• stara powinna redirectować.

11. Zaktualizuj linkowanie wewnętrzne

Po migracji nie zostawiaj struktury:

nowa strona → stary URL → redirect → nowa strona

Linki wewnętrzne powinny od razu prowadzić do nowych adresów.

Google oficjalnie zaleca zaktualizowanie internal links po przygotowaniu mappingu.

Sprawdź:

• menu,
• footer,
• breadcrumbs,
• teksty blogowe,
• CTA,
• related posts,
• obrazy,
• ręcznie wpisane linki.

12. Sprawdź, czy sitemap zawiera nowe URL

Po redesignie sitemap powinna:

• używać nowych canonical URL,
• nie zawierać redirectów,
• nie zawierać 404,
• nie zawierać noindex.

Po wdrożeniu:

• prześlij nową sitemapę w Search Console.

Google zaleca wykorzystanie sitemap do szybszego discovery nowych adresów.

13. Staging: najbezpieczniej nie opierać ochrony tylko na noindex

Nowa wersja strony zwykle powstaje na:

• staging,
• subdomenie,
• osobnym środowisku.

Nie chcemy, aby Google indeksował ją przed launch.

Dobre podejście

Jeśli to możliwe:

• zabezpieczenie hasłem,
• ograniczenie dostępu.

noindex może być dodatkowym zabezpieczeniem.

Największe ryzyko

Po launch nowe production nadal ma: noindex.

Google w dokumentacji site move wprost ostrzega, aby usunąć blokady noindex/robots używane podczas migracji.

14. Nie przenoś stagingowego robots.txt na produkcję

To prosty błąd, ale potrafi zatrzymać cały serwis.

Na staging może istnieć: Disallow: /

Na produkcji — nie.

Przed publikacją sprawdź robots.txt ręcznie.

Nie zakładaj, że „CMS zrobi to dobrze”.

15. Sprawdź title i H1 przed migracją

Redesign często zmienia:

• template,
• heading hierarchy,
• title generation.

Może się okazać, że stara strona miała:

• dobry title,
• jasny H1,

a nowa wersja dostała marketingowy slogan bez kontekstu.

Przykład

Stary H1:

Tworzenie stron internetowych dla firm

Nowy:

Zbudujmy coś wyjątkowego

Design może wyglądać lepiej.

Intencja strony staje się mniej jasna.

Nowy copy nie powinien usuwać informacji, które pomagają użytkownikowi i Google zrozumieć temat.

16. Porównaj stary i nowy content

Nie zakładaj, że krótszy = lepszy albo dłuższy = lepszy.

Sprawdź:

• co generowało ruch,
• które sekcje odpowiadały na queries,
• jakie FAQ miały sens,
• które dane były unikalne,
• co można usunąć.

Redesign często usuwa treści dla „czystości”

To może być dobre UX-owo, jeśli treść była zbędna.

Ale jeżeli usuwasz sekcję, która:

• odpowiadała na ważne pytanie,
• posiadała unikalne informacje,
• generowała long-tail,

przenieś jej wartość w lepszej formie zamiast usuwać w ciemno.

17. Zachowaj treści, które mają własną historię SEO

Artykuły blogowe nie muszą wyglądać „nowocześnie”, aby generować ruch.

Przy redesignie:

• zmieniaj template,
• poprawiaj layout,
• aktualizuj content,

ale nie kasuj wartościowego URL tylko dlatego, że jest stary.

Lepiej

stary URL + lepsza treść + nowy design

niż:

nowy URL + utrata historii + ten sam temat

18. Sprawdź cannibalization przed reorganizacją

Redesign jest dobrym momentem, aby uporządkować kilka stron o tym samym intent.

Na przykład:

• /seo/
• /pozycjonowanie/
• /pozycjonowanie-stron/

Jeżeli wszystkie targetują to samo, można:

• wybrać główny URL,
• połączyć najlepszą treść,
• przekierować pozostałe.

Ale najpierw sprawdź:

• który URL rankuje,
• który ma backlinki,
• który ma historię.

Nie wybieraj głównego adresu tylko dlatego, że brzmi najlepiej.

19. Nie twórz nowej strony dla każdej odmiany słowa kluczowego

Nowa architektura często prowokuje do mnożenia podstron.

Przykład:

• tworzenie stron,
• tworzenie stron www,
• projektowanie stron,
• strony dla firm.

Jeżeli intent jest ten sam, jedna mocna strona może być lepsza.

Zasada:

jeden główny intent = jeden główny URL

Redesign powinien uprościć architekturę, nie stworzyć nową cannibalization.

20. Sprawdź structured data

Zmiana theme/CMS może usunąć:

• BreadcrumbList,
• Article,
• Product,
• Organization,
• LocalBusiness.

Albo odwrotnie — dodać kilka konkurujących schema.

Po wdrożeniu sprawdź:

• czy markup istnieje,
• czy pasuje do strony,
• czy dane odpowiadają visible content,
• czy nie ma starych adresów URL.

Structured data nie powinno być kopiowane bez kontroli z poprzedniej wersji.

21. Sprawdź obrazy i ważne zasoby

Google w dokumentacji migracji przypomina, aby uwzględnić nie tylko HTML, ale także istotne:

• images,
• video,
• JavaScript,
• CSS.

Szczególnie ważne są obrazy, które:

• mają ruch z Google Images,
• są używane w artykułach,
• mają zewnętrzne linki,
• mają własne stabilne URL.

Nie trzeba zachować każdego starego asset URL.

Ale duża migracja powinna świadomie obejmować również media.

22. Core Web Vitals — mierz przed i po

Redesign często ma poprawić performance.

Żeby wiedzieć, czy tak się stało, potrzebujesz baseline.

Przed zmianą:

• sprawdź LCP,
• INP,
• CLS,
• mobile,
• typowe template'y.

Po zmianie:

• powtórz pomiar.

Nie porównuj tylko Lighthouse na jednym URL

Sprawdź:

• homepage,
• service page,
• blog/article,
• product/category, jeśli to e-commerce.

Nowy hero może wyglądać świetnie, ale jeśli dodaje ciężkie video i trzy biblioteki JS, performance może się pogorszyć.

23. Mobile — przetestuj realne ścieżki

Redesign nie może być oceniany tylko na desktop screenshot.

Sprawdź:

• menu,
• CTA,
• formularz,
• phone/email links,
• sticky elements,
• cookie banner,
• tabs,
• accordion,
• table,
• gallery,
• checkout, jeśli jest sklep.

Ważne SEO

Główna treść powinna być dostępna również na mobile.

Nie chowaj krytycznych informacji tylko dlatego, że desktop ma więcej miejsca.

24. Formularze i konwersje

Po redesignie SEO może być stabilne, ale leady mogą spaść, jeśli:

• formularz przestał działać,
• CTA prowadzi w złe miejsce,
• telefon nie jest klikalny,
• thank-you page zmieniła URL,
• tracking nie rejestruje konwersji.

Dlatego redesign trzeba testować nie tylko pod kątem Search.

Przed launch

Zrób pełny test: wejście → landing → CTA → formularz → wysyłka → e-mail → thank-you → event analytics

25. GA4 i GTM

Zmiana template może usunąć:

• GA4,
• GTM,
• consent signals,
• event tracking.

Przed launch zapisz:

• Measurement ID,
• container ID,
• główne eventy,
• conversion events.

Po launch:

• użyj DebugView / Preview,
• sprawdź realne zdarzenia.

Brak danych po redesignie nie oznacza braku ruchu.

Może oznaczać brak trackingu.

26. Search Console verification

Przy zmianie CMS albo domeny upewnij się, że nadal masz dostęp do GSC.

Google szczególnie zwraca na to uwagę przy site moves.

Jeżeli verification opiera się na:

• HTML file,
• tagu,
• DNS,

sprawdź, czy nowa wersja go zachowuje.

27. Zmiana domeny to osobna kategoria ryzyka

Jeżeli redesign oznacza jednocześnie:

• nową domenę,
• nowy CMS,
• nowy layout,
• nowe URL,
• nowe treści,

problemów jest znacznie więcej.

Google rekomenduje — jeśli to możliwe — zmieniać duże elementy etapami.

Przykład

Najpierw:

• migracja domeny z zachowaniem content/URL,

potem:

• większy redesign.

Nie zawsze biznes może tak zrobić.

Ale jeśli może, łatwiej zdiagnozować ewentualne spadki.

28. Change of Address — tylko gdy zmieniasz domenę/subdomenę

Google Search Console ma narzędzie Change of Address.

Używa się go przy:

• zmianie domeny,
• zmianie subdomeny na inną domenę/subdomenę.

Nie jest potrzebne przy zwykłej zmianie ścieżek URL w tej samej domenie.

To ważne, bo redesign bez zmiany domeny nie wymaga tego kroku.

29. Przygotuj serwer na zwiększony crawl po migracji

Google informuje, że po site move może crawlowac nową stronę intensywniej.

Dlatego nowy hosting powinien mieć wystarczające zasoby.

Nie warto przenosić serwisu na słabsze środowisko dokładnie w momencie, gdy Google potrzebuje ponownie odwiedzić wiele URL.

30. Zaplanuj launch w rozsądnym terminie

Jeżeli możesz:

• nie wdrażaj dużej migracji przed największym sezonem,
• nie publikuj w piątek wieczorem,
• zapewnij dostęp developera i SEO po launch.

Google również rekomenduje, jeśli to możliwe, wykonywać migracje przy niższym ruchu.

To pozwala szybciej zauważyć i naprawić problemy.

31. Przygotuj rollback — ale ostrożnie

Powinien istnieć:

• backup,
• kopia kodu,
• lista konfiguracji,
• możliwość wycofania deploymentu.

Ale w aktywnym e-commerce rollback bazy danych może oznaczać utratę:

• nowych zamówień,
• klientów,
• płatności.

Dlatego rollback musi być zaplanowany, a nie improwizowany.

32. Przed launch zrób crawl stagingu

Crawl nowej wersji pozwala wykryć:

• broken links,
• 404,
• złe canonical,
• noindex,
• brak title,
• błędne H1,
• redirect chains,
• stare URL.

Następnie porównaj z production

Najważniejsze pytanie:

Czy każdy wartościowy stary URL ma bezpieczny los w nowej architekturze?

33. Po launch zrób crawl jeszcze raz

Staging i production mogą różnić się:

• domeną,
• konfiguracją,
• cache,
• redirectami,
• robots,
• canonical.

Dlatego po publikacji trzeba sprawdzić realną domenę.

Minimum po launch

• crawl,
• 404,
• redirecty,
• noindex,
• canonical,
• sitemap,
• robots,
• GSC,
• GA4,
• formularze.

34. Monitoruj Search Console przez kolejne tygodnie

Google informuje, że przy znaczących zmianach widoczność może tymczasowo falować.

Przy site move Google musi:

• odwiedzić stare URL,
• zobaczyć redirecty,
• odwiedzić nowe URL,
• przetworzyć sygnały.

Dla małych i średnich serwisów przejście może potrwać kilka tygodni lub dłużej.

Monitoruj:

• Page Indexing,
• 404,
• redirect errors,
• impressions,
• clicks,
• ważne queries,
• ważne pages,
• sitemap.

Nie oceniaj migracji po 24 godzinach.

35. Redirecty zostaw na długo

Google rekomenduje utrzymywanie redirectów co najmniej około roku, a z perspektywy użytkownika często warto trzymać je jeszcze dłużej.

Nie usuwaj starych redirectów po miesiącu dlatego, że:

„Google już chyba wszystko zobaczył”.

Backlink do starego URL może działać przez wiele lat.

36. Zaktualizuj najważniejsze zewnętrzne linki, jeśli możesz

Redirect jest prawidłowym rozwiązaniem.

Ale jeżeli masz kontrolę nad ważnym linkiem:

• profil social,
• kampania reklamowa,
• katalog branżowy,
• partner,

zaktualizuj go do nowego URL.

To zmniejsza:

• redirect hops,
• zależność od starych adresów.

37. Nie zmieniaj rzeczy, których nie musisz

Redesign nie musi jednocześnie zmieniać:

• domeny,
• CMS,
• URL,
• copy,
• całej struktury,
• hostingu.

Im więcej zmieniasz, tym trudniej ustalić przyczynę problemu.

Jeżeli nowy wygląd można wdrożyć na:

• tej samej domenie,
• tych samych wartościowych URL,

ryzyko jest niższe.

38. Kiedy warto zmienić URL mimo ryzyka?

Gdy obecna struktura rzeczywiście jest problemem.

Na przykład:

• przypadkowe parametry,
• nieczytelne slugi,
• stare nieaktualne kategorie,
• duplikaty,
• rozproszona cannibalization,
• zła architektura po latach zmian.

Wtedy migracja ma sens.

Ale musi mieć:

• mapping,
• redirect,
• aktualizację links/canonical/sitemap.

39. Co z usuniętymi stronami bez odpowiednika?

Nie każda stara strona musi redirectować.

Jeżeli treść:

• została trwale usunięta,
• nie ma logicznego zamiennika,

poprawny 404 albo 410 może być właściwy.

Google oficjalnie rekomenduje zwracać 404/410 dla usuniętych treści, które nie są przenoszone.

To lepsze niż redirect do przypadkowej usługi.

40. Redesign bez zmian URL — też wymaga SEO kontroli

Nawet jeśli URL pozostają identyczne, można stracić SEO przez:

• usunięcie contentu,
• błędne H1,
• noindex,
• canonical,
• JS rendering,
• brak internal links,
• wolniejszy frontend,
• usunięcie schema.

Dlatego „URL się nie zmieniają” nie oznacza:

„SEO nie trzeba sprawdzać”.

Zmienia się dokument pod tym URL.

41. Checklista przed redesignem

Dane

• ☐ GSC export
• ☐ GA4
• ☐ top landing pages
• ☐ ważne queries
• ☐ konwersje
• ☐ backlinki

URL

• ☐ lista wszystkich starych URL
• ☐ decyzja: keep / redirect / delete
• ☐ mapping stary → nowy
• ☐ lista wartościowych 404 do odzyskania
• ☐ brak niepotrzebnych zmian slugów

Content

• ☐ ważne treści zachowane
• ☐ content gaps
• ☐ cannibalization
• ☐ H1/title
• ☐ usługi i blog mają jasny intent

Technika

• ☐ canonical
• ☐ robots
• ☐ noindex
• ☐ sitemap
• ☐ redirecty
• ☐ internal links
• ☐ schema
• ☐ media
• ☐ HTTPS

UX/performance

• ☐ mobile
• ☐ LCP
• ☐ INP
• ☐ CLS
• ☐ formularze
• ☐ CTA
• ☐ checkout, jeśli istnieje

Tracking

• ☐ GSC verification
• ☐ GA4
• ☐ GTM
• ☐ consent
• ☐ conversion events

Launch

• ☐ crawl staging
• ☐ backup
• ☐ redirect test
• ☐ noindex removed
• ☐ production crawl
• ☐ sitemap submitted
• ☐ GSC monitoring
• ☐ GA4 test
• ☐ formularz test
• ☐ monitoring 404

Z praktyki FreenetPro: redesign zaczyna się od mapy tego, czego nie wolno zgubić

Przy przebudowie istniejącej strony najpierw sprawdzamy:

• co już działa,
• które URL mają wartość,
• które treści rankują,
• jakie linki prowadzą do serwisu,
• co można poprawić bez zmiany adresu.

Dopiero potem planujemy nową strukturę.

To pozwala uniknąć dwóch skrajności:

„Nic nie zmieniajmy, bo SEO”

To blokuje potrzebny rozwój.

„Zmieniamy wszystko, bo będzie nowocześniej”

To ignoruje historię domeny.

Dobra przebudowa robi coś trzeciego:

zachowuje sygnały, które mają wartość, i usuwa ograniczenia, które blokują dalszy rozwój.

FAQ

Czy redesign strony może pogorszyć SEO?

Tak, jeśli podczas przebudowy zmienią się wartościowe URL, treści, internal links, canonical, indexability albo performance. Sam redesign wizualny nie musi powodować spadków, jeśli struktura SEO zostanie zachowana.

Czy przy redesignie trzeba zmieniać URL?

Nie. Jeżeli URL jest logiczny, ma ruch i nadal opisuje tę samą treść, często najlepiej go zachować.

Co zrobić, jeśli URL musi się zmienić?

Przygotować mapping stary → nowy i wdrożyć permanentny server-side redirect, zwykle 301 lub 308, do najbardziej odpowiadającej nowej strony.

Czy 301 powoduje utratę SEO?

Google oficjalnie informuje, że permanent redirects nie tracą PageRank tylko dlatego, że są redirectami. Problemem może być natomiast zły target, brak redirectu albo długi chain.

Czy można przekierować wszystkie stare strony na homepage?

Nie jest to dobra praktyka. Google ostrzega, że masowe nieadekwatne redirecty do homepage mogą być traktowane jak soft 404.

Jak długo trzymać redirecty po redesignie?

Google rekomenduje co najmniej około roku. W praktyce dla ważnych starych URL często warto pozostawić je jeszcze dłużej.

Czy sitemapę trzeba zmieniać po redesignie?

Jeżeli zmieniły się URL — tak. Nowa sitemap powinna zawierać nowe canonical, indeksowalne URL i zostać przesłana do Search Console.

Czy noindex na stagingu wystarczy?

Może być jednym z zabezpieczeń, ale staging lepiej dodatkowo ograniczyć dostępem. Najważniejsze jest, aby stagingowy noindex nie przeszedł na produkcję.

Czy przed redesignem potrzebny jest audyt SEO?

Jeżeli obecna strona ma ruch, backlinki lub historię w Google — warto przynajmniej przeprowadzić migracyjny audyt SEO. Jego celem jest ustalenie, co zachować i jak przenieść wartość.

Czy zmiana CMS wpływa na SEO?

Sama zmiana CMS nie musi szkodzić. Ryzyko pojawia się, gdy zmienia ona URL, content, canonical, internal links, rendering albo performance.

Czy zmiana domeny i redesign jednocześnie to dobry pomysł?

Jeżeli można rozdzielić te zmiany, Google zaleca wykonywać duże zmiany etapami. Nie zawsze jest to możliwe biznesowo, ale zmniejsza złożoność diagnostyki.

Jak długo trwa stabilizacja SEO po redesignie?

Nie ma stałego terminu. Przy większych zmianach Google może potrzebować kilku tygodni lub więcej na ponowny crawl i przetworzenie URL. Wielkość serwisu i wydajność serwera mają znaczenie.

Czy po redesignie trzeba ponownie zgłaszać stronę do Google?

Nie „całą stronę” ręcznie. Warto przesłać aktualną sitemapę i monitorować Search Console. Request Indexing można użyć dla kilku kluczowych URL po ważnej zmianie.

Co jest najważniejsze przed redesignem?

Pełna lista wartościowych URL i jasna decyzja dla każdego z nich: zachowujemy, przekierowujemy czy usuwamy. To fundament bezpiecznej migracji.

Redesign bez utraty SEO nie zaczyna się od redirectów

Redirecty są ważne.

Ale pojawiają się dopiero po wcześniejszej decyzji:

co ma zostać, co się zmienia i dlaczego.

Jeżeli zrobisz:

• inventory,
• GSC,
• backlinki,
• mapping,
• content plan,
• test staging,

same redirecty stają się prostym elementem większej, uporządkowanej migracji.

Jeżeli tego nie zrobisz, redirecty stają się próbą ratowania projektu po fakcie.

Zobacz audyt SEO

Przeczytaj: Redesign strony — kiedy jest potrzebny?