Żeby przebudować stronę i ograniczyć ryzyko utraty pozycji w Google, nie zaczynaj od nowego wyglądu. Zacznij od listy obecnych URL-i, danych z Google Search Console, mapy przekierowań, decyzji o zachowaniu treści, testów technicznych i monitoringu po wdrożeniu. Przebudowa strony bez tego planu może poprawić design, ale jednocześnie osłabić pozycjonowanie strony w Google.
Nie da się uczciwie zagwarantować, że po dużej zmianie nie będzie żadnych wahań. Google musi ponownie przejść przez adresy, zrozumieć nową strukturę i ocenić sygnały. Da się jednak odróżnić kontrolowaną migrację SEO od ryzykownego wdrożenia, w którym stare adresy znikają, treści są skracane pod layout, a przekierowania powstają dopiero wtedy, gdy ruch już spada.
Najkrótsza odpowiedź: najpierw plan SEO, potem design
Jeśli przebudowa dotyczy tylko warstwy wizualnej, a adresy URL, treści i struktura podstron zostają prawie bez zmian, ryzyko jest mniejsze. Jeśli zmienia się CMS, domena, struktura adresów, menu, treść albo architektura informacji, traktuj projekt jak migrację SEO. To nie jest formalność po stronie wykonawcy strony. To osobny zakres prac, który powinien być wpisany do briefu, harmonogramu i odbioru technicznego.
Najważniejsze pytanie brzmi: czy Google po wdrożeniu znajdzie te same wartościowe informacje pod równoważnymi adresami i czy użytkownik trafi bez problemu z każdego starego URL-a do najlepszego nowego odpowiednika. Jeżeli odpowiedź jest niejasna, projekt nie jest gotowy do publikacji.
Werdykt w 30 sekund
- Nie zmieniaj adresów URL bez powodu: jeśli obecny URL ma ruch, linki i pasuje do nowej struktury, zwykle warto go zachować.
- Każdy stary adres musi mieć decyzję: zostaje, dostaje nowy odpowiednik, łączy się z inną treścią albo świadomie znika jako 404/410.
- Przekierowania muszą być gotowe przed publikacją: przy trwałej zmianie adresu używaj 301 lub 308, unikaj łańcuchów i pętli.
- Po wdrożeniu monitoruj URL-e, nie tylko całą domenę: spadek na kluczowej podstronie może zginąć w ogólnym wykresie ruchu.
Praktyczna decyzja jest prosta: jeżeli strona ma już widoczność, przebudowa bez mapy URL i testów przekierowań jest ryzykiem, a nie oszczędnością. Najpierw porządkujesz sygnały SEO, dopiero potem publikujesz nową wersję.
Jeśli nie masz pewności, czy potrzebna jest pełna przebudowa, oddziel lekkie poprawki od zmian architektury. Czasem wystarczy najpierw zoptymalizować stronę pod SEO, a większy projekt zostawić dopiero na moment, gdy problemem są URL-e, CMS, struktura lub ograniczenia techniczne.
Co spisać przed przebudową strony
Przed rozmową o nowym designie trzeba zebrać stan obecny. Nie chodzi o raport dla samego raportu, tylko o listę elementów, których nie wolno zgubić. Bez tego wykonawca strony może zaprojektować ładniejszy serwis, ale nie będzie wiedział, które podstrony odpowiadają za ruch, zapytania, linki i konwersje.
Minimum to skan obecnej strony, eksport URL-i z sitemap, dane z GSC, dane z GA4 lub innej analityki oraz lista najważniejszych podstron z perspektywy biznesowej. Jeśli strona ma dużo treści, kategorii, produktów, filtrów albo starszych wpisów, sama ręczna lista menu nie wystarczy. Google zna zwykle więcej adresów niż te, które widać w nawigacji.
Przed startem zapisz też punkt odniesienia: kliknięcia, wyświetlenia, zapytania, najważniejsze URL-e, konwersje, status indeksacji i bieżące problemy techniczne. Bez takiego zrzutu po wdrożeniu trudno odróżnić normalne wahanie od błędu migracyjnego.
| Co spisać | Po co to robisz | Czerwona flaga |
|---|---|---|
| Wszystkie obecne URL-e | Żeby żaden stary adres nie zniknął bez decyzji | Wykonawca pracuje tylko na nowym menu |
| URL-e z ruchem organicznym | Żeby chronić podstrony, które już zdobywają wejścia | Nikt nie sprawdza kliknięć i wyświetleń przed zmianą |
| Zapytania i frazy dla kluczowych stron | Żeby zachować dopasowanie do intencji użytkownika | Nowa treść jest pisana bez wiedzy, na co strona się wyświetlała |
| Backlinki do konkretnych URL-i | Żeby nie zgubić wartości linków zewnętrznych | Wszystkie stare adresy mają trafić na stronę główną |
| Konwersje i ważne akcje | Żeby nie usunąć podstron, które dowożą zapytania lub sprzedaż | Decyzje zapadają tylko na podstawie wyglądu |
| Status indeksacji | Żeby wiedzieć, co Google faktycznie ma w indeksie | Brak dostępu do GSC lub brak weryfikacji URL-i |
Warto rozdzielić dwie listy. Pierwsza to lista techniczna: wszystkie URL-e, statusy, canonicale, indeksacja, sitemap XML, przekierowania i błędy. Druga to lista decyzyjna: najważniejsze strony ofertowe, kategorie, produkty, artykuły, landing page'e i adresy z linkami zewnętrznymi. Dopiero po połączeniu tych danych widać, co musi być chronione, a co można zmienić bez dużego ryzyka.
Kiedy nie wdrażać przebudowy
- Nie masz listy starych URL-i: nie wiadomo, co ma zostać zachowane, przekierowane albo usunięte.
- Nie masz dostępu do GSC i analityki: nie odróżnisz ważnych podstron od tych, które tylko wyglądają na ważne.
- Nie ma planu testów: błędy wyjdą dopiero po publikacji, gdy Google i użytkownicy będą już trafiać na nową wersję.
Jeśli kupujesz usługę przebudowy, zapytaj wprost, kto odpowiada za tę inwentaryzację. Jeżeli odpowiedź brzmi "to zrobimy później", ryzyko jest po Twojej stronie.
Mapa URL: co zostaje, co zmienia adres, co znika
Mapa URL to centralny dokument przy przebudowie strony. Powinna pokazywać, co stanie się z każdym starym adresem po wdrożeniu. Najprostszy arkusz ma kolumny: stary URL, nowy URL, typ decyzji, priorytet, status wdrożenia i uwagi. Im większy serwis, tym bardziej ta mapa staje się narzędziem kontroli, a nie dodatkiem dla SEO.
Nie każdy adres musi dostać nowy URL. Czasem najlepszą decyzją jest zostawienie go bez zmian. Dotyczy to zwłaszcza podstron, które mają ruch organiczny, linki zewnętrzne, stabilną widoczność i pasują do nowej architektury. Zmiana adresu tylko dlatego, że nowy CMS generuje inny format, zwykle dokłada niepotrzebne ryzyko.
| Decyzja dla starego URL-a | Kiedy ma sens | Co sprawdzić |
|---|---|---|
| Zostawić bez zmian | URL jest czytelny, ma ruch, linki i pasuje do nowej struktury | Czy nowy CMS pozwala zachować adres |
| Przekierować 1:1 | Treść przechodzi na nowy adres i ma jasny odpowiednik | Czy nowy URL odpowiada tej samej intencji |
| Połączyć z inną treścią | Kilka starych podstron było słabych lub powielało temat | Czy nowa strona przejmuje najważniejsze informacje |
| Usunąć jako 404/410 | Treść nie ma odpowiednika, nie ma wartości i nie powinna wracać | Czy adres nie ma ruchu, linków i konwersji |
| Przebudować treść przed migracją | Stara strona ma potencjał, ale jest nieaktualna lub chaotyczna | Czy warto poprawić ją przed publikacją nowej wersji |
Najgorszym skrótem jest hurtowe przekierowanie wielu starych adresów na stronę główną. Użytkownik trafia wtedy w przypadkowe miejsce, a Google dostaje słaby sygnał tematyczny. Jeśli stary artykuł o konkretnej usłudze nie ma odpowiednika, lepiej wskazać najbliższą tematycznie podstronę niż udawać, że strona główna rozwiązuje każdy problem.
Przy mapowaniu URL trzeba też uważać na podobne intencje. Jeżeli trzy stare podstrony odpowiadały na ten sam problem, przebudowa może być dobrym momentem, żeby je połączyć. Jeżeli jednak każda obsługiwała inną grupę zapytań, mechaniczne sklejenie ich w jedną stronę może osłabić widoczność na długi ogon.
Decyzja krok po kroku
- Zbierz wszystkie stare URL-e z crawla, sitemap, GSC, GA4 lub innej analityki i list od zespołu.
- Oznacz priorytet na podstawie ruchu, konwersji, linków zewnętrznych i znaczenia biznesowego.
- Dopasuj nowy adres tylko tam, gdzie zmiana URL-a jest naprawdę potrzebna.
- Zapisz decyzję dla każdego adresu: zostaje, przekierowanie 1:1, połączenie, 404/410 albo poprawa treści.
- Przetestuj mapę przed publikacją, a nie po pierwszych błędach w indeksowaniu.
Dobra mapa URL odpowiada na pytanie "dokąd trafi użytkownik i Googlebot po wejściu na stary adres?". Jeśli arkusz nie daje tej odpowiedzi, nie jest jeszcze gotowy.
Jeżeli w mapie zostają puste decyzje, nie traktuj ich jako drobiazgów do domknięcia po starcie. To zwykle właśnie takie adresy później generują 404, błędne przekierowania albo utratę treści, którą Google wcześniej widział jako odpowiedź na konkretne zapytanie.
Przekierowania 301 i linki wewnętrzne
Przekierowanie jest potrzebne wtedy, gdy trwałe zmienia się adres podstrony. W takim scenariuszu standardem są przekierowania stałe 301 lub 308. Przekierowania tymczasowe 302 lub 307 nie powinny być domyślnym wyborem przy trwałej migracji, bo komunikują inny charakter zmiany.
Przekierowanie nie jest jednak sposobem na naprawienie słabej architektury. Jeśli stary URL prowadził do konkretnej treści, nowy cel powinien być możliwie najbliższym odpowiednikiem. Jeżeli użytkownik szukał cennika, nie powinien trafić na ogólną stronę "Oferta". Jeżeli Google znał artykuł o jednym problemie, przekierowanie na katalog bloga będzie słabszym rozwiązaniem niż przekierowanie na nową wersję tego samego poradnika.
| Problem z przekierowaniami | Dlaczego szkodzi | Co zrobić zamiast |
|---|---|---|
| Stary URL przez pośredni URL do nowego URL-a | Tworzy łańcuch i utrudnia interpretację | Kierować stary adres bezpośrednio na finalny URL |
| Przekierowanie na stronę główną | Traci dopasowanie tematyczne i frustruje użytkownika | Wskazać najbliższy odpowiednik treści |
| Pętla przekierowań | Użytkownik i robot nie docierają do strony | Testować reguły przed publikacją |
| 302/307 przy trwałej zmianie | Sygnał nie pasuje do charakteru migracji | Użyć 301 lub 308, jeśli zmiana jest stała |
| Linki wewnętrzne do starych URL-i | Strona sama wysyła użytkownika przez przekierowanie | Zaktualizować linki w menu, treści, stopce i breadcrumbach |
Po wdrożeniu przekierowań trzeba zaktualizować linkowanie wewnętrzne. To częsty błąd: technicznie przekierowanie działa, ale menu, stopka, breadcrumbs, artykuły i przyciski nadal prowadzą do starych adresów. Użytkownik tego czasem nie zauważy, bo przeglądarka przeniesie go dalej. Dla techniki i crawl budgetu to jednak niepotrzebny bałagan.
Warto też sprawdzić stare przekierowania, jeśli strona przechodziła wcześniejsze migracje. Nowa przebudowa nie powinna dokładać kolejnej warstwy na starych regułach. Docelowo stare adresy powinny prowadzić bezpośrednio do aktualnych, finalnych URL-i.
Czerwone flagi przy przekierowaniach
- Mapa przekierowań powstaje po publikacji: wtedy błędy są już widoczne dla użytkowników i robotów.
- Wiele adresów kieruje na stronę główną: to zwykle oznacza brak mapowania tematycznego.
- Nikt nie testuje statusów HTTP: przekierowanie "działa w przeglądarce" nie wystarcza do odbioru technicznego.
Praktyczny wniosek: przekierowania mają być gotową częścią wdrożenia, nie listą poprawek na później.
Treść i elementy SEO, których nie wolno zgubić
Przebudowa strony często zaczyna się od chęci uproszczenia komunikacji. To może być dobre, ale tylko wtedy, gdy nie kasuje informacji, dzięki którym podstrona odpowiadała na zapytania użytkowników. Ładniejszy layout nie pomoże, jeśli z nowej wersji znikną odpowiedzi, porównania, parametry, przykłady zastosowań, warunki usługi, ceny orientacyjne, elementy zaufania albo sekcje, które wcześniej budowały widoczność.
Przed skracaniem treści sprawdź, na jakie zapytania wyświetlał się dany URL i które akapity odpowiadały na główne intencje. Nie chodzi o to, żeby bezmyślnie przenieść każdy stary tekst. Chodzi o to, żeby nowa wersja nie była uboższa merytorycznie tylko dlatego, że makieta przewidziała krótszy blok.
| Element do zachowania lub świadomej zmiany | Dlaczego ma znaczenie |
|---|---|
title |
Wpływa na zrozumienie tematu i decyzję o kliknięciu w wynikach |
H1 |
Ustawia główny temat podstrony po wejściu użytkownika |
Ważne H2 i struktura sekcji |
Pomagają uporządkować odpowiedź na intencję |
| Treść główna | Przenosi realną wartość informacyjną i sprzedażową |
| Meta description | Może wspierać komunikat w wynikach wyszukiwania |
| Canonical | Wskazuje preferowaną wersję adresu |
| Dane strukturalne | Pomagają opisać typ treści, produktu, organizacji lub artykułu |
Obrazy i alt |
Wspierają użyteczność, kontekst i dostępność |
| Linkowanie wewnętrzne | Pokazuje relacje między podstronami i prowadzi użytkownika dalej |
| Elementy konwersji | Formularze, CTA i dane kontaktowe nie mogą zniknąć przypadkiem |
Szczególnie uważać trzeba na strony usługowe, kategorie, produkty i poradniki, które już mają ruch organiczny. Jeżeli nowy projekt zamienia długą, konkretną stronę w krótki ekran z hasłem marketingowym, widoczność może spaść nie dlatego, że Google "nie lubi redesignu", tylko dlatego, że zniknęła odpowiedź na pytanie użytkownika.
Nie każda stara treść jest warta zachowania. Przebudowa to dobry moment na usunięcie duplikatów, połączenie podobnych wpisów i aktualizację przestarzałych informacji. Decyzja powinna jednak wynikać z danych i intencji, a nie z samego faktu, że nowy układ jest krótszy.
Szybka decyzja o treści
Jeśli podstrona ma ruch, linki, konwersje albo widoczność na ważne zapytania, nie skracaj jej tylko pod makietę. Najpierw ustal, które informacje trzeba zachować, które poprawić, a które można usunąć bez szkody dla użytkownika i SEO.
Praktycznie: każda ważna podstrona po przebudowie powinna nadal odpowiadać na tę samą albo lepiej dopasowaną intencję użytkownika. Jeśli tego nie robi, sama poprawa wyglądu nie wystarczy.
Testy techniczne przed publikacją
Najtańszy moment na naprawę błędów jest przed publikacją. Po wdrożeniu każdy błąd może już dotykać użytkowników, robotów Google, kampanii reklamowych, formularzy i sprzedaży. Dlatego wersja testowa powinna przejść crawl oraz odbiór techniczny, a nie tylko przegląd wizualny na kilku podstronach.
Na stagingu często celowo blokuje się indeksowanie przez noindex albo robots.txt. To normalne, ale tylko pod warunkiem, że ktoś ma checklistę zdjęcia tych blokad przed startem produkcji. Jedna przeniesiona blokada może sprawić, że nowa strona wygląda dobrze, ale nie powinna być indeksowana.
| Test przed publikacją | Co powinno wyjść |
|---|---|
| Crawl wersji testowej | Lista błędów 404, przekierowań, duplikatów, brakujących metadanych i problemów z linkami |
| Statusy HTTP | Ważne strony zwracają 200, usunięte mają świadome 404/410, przekierowania działają poprawnie |
robots.txt i noindex |
Produkcyjne URL-e nie są zablokowane przez ustawienia ze stagingu |
| Canonicale | Wskazują właściwe, finalne adresy, a nie stare lub testowe URL-e |
| Sitemap XML | Zawiera nowe kanoniczne adresy, bez starych, testowych i zablokowanych URL-i |
| Renderowanie JavaScript | Kluczowa treść, linki i zasoby są dostępne dla robota, nie tylko po interakcji użytkownika |
| Mobile i Core Web Vitals | Strona jest używalna na telefonie i nie ma oczywistych problemów wydajnościowych |
| Formularze i konwersje | Zapytania, kliknięcia, koszyk, rezerwacje lub inne akcje działają po wdrożeniu |
| Analityka i tagi | Pomiar nie znika razem ze starym szablonem |
Jeśli serwis ma wersje językowe, trzeba dodatkowo sprawdzić hreflang. Jeśli ma produkty, warianty, filtry albo paginację, testy muszą objąć również te obszary. Przy e-commerce szczególnie ryzykowne są filtry, parametry i warianty produktów, bo potrafią wygenerować dużą liczbę adresów albo odciąć ważne kategorie od indeksacji.
Test techniczny powinien kończyć się listą poprawek przed go-live. Nie każda drobna rzecz musi blokować publikację, ale błędy indeksacji, przekierowań, canonicali, formularzy i analityki powinny być traktowane jako krytyczne.
Co wpisać do odbioru technicznego
- Crawl stagingu i produkcji po wdrożeniu z porównaniem liczby błędów.
- Test mapy przekierowań dla wszystkich URL-i z arkusza migracyjnego.
- Sprawdzenie blokad indeksacji: `robots.txt`, `noindex`, canonicale i sitemap.
- Test kluczowych ścieżek użytkownika: formularz, koszyk, kontakt, logowanie, wyszukiwarka lub rezerwacja.
- Potwierdzenie działania pomiaru, żeby po starcie nie analizować pustych danych.
Jeżeli projekt ma napięty termin, nie skracaj testów SEO jako pierwszych. To właśnie one łapią błędy, które najczęściej wychodzą dopiero po publikacji.
Dzień wdrożenia i pierwsze kroki po starcie
Dzień publikacji powinien mieć kolejność działań. Najpierw backup i gotowość do cofnięcia krytycznych zmian, potem wdrożenie nowej wersji, przekierowań, sitemap i konfiguracji produkcyjnej, a następnie szybka kontrola najważniejszych adresów. To nie jest moment na odkrywanie, że brakuje reguł przekierowań albo że nowa strona nadal ma noindex.
Po starcie sprawdź najważniejsze adresy ręcznie, w crawlu i w URL Inspection w Google Search Console. Strona główna, główne usługi, kategorie, produkty, artykuły z ruchem i adresy z backlinkami powinny być kontrolowane w pierwszej kolejności. Jeśli te URL-e działają, łatwiej naprawiać mniej istotne problemy w tle.
| Działanie po publikacji | Dlaczego jest ważne |
|---|---|
| Sprawdzenie najważniejszych URL-i w URL Inspection | Potwierdza, że strony zwracają 200 i mają właściwą treść |
| Test przekierowań | Pokazuje, czy stare adresy prowadzą do właściwych nowych odpowiedników |
| Aktualizacja i zgłoszenie sitemap | Pomaga wskazać preferowane kanoniczne URL-e w Google Search Console |
Kontrola robots.txt i noindex |
Wyklucza przypadkowe zablokowanie nowej strony |
| Sprawdzenie canonicali | Zapobiega wskazywaniu starych, testowych lub błędnych adresów |
| Kontrola formularzy i pomiaru | Pozwala uniknąć utraty leadów oraz danych po wdrożeniu |
Jeśli przebudowa obejmuje zmianę domeny lub subdomeny, dochodzi osobny temat: narzędzie zmiany adresu w Search Console. Nie używa się go przy każdej zmianie wyglądu ani przy zwykłym przejściu na nowy layout. Ma sens przy przenosinach między domenami lub subdomenami, po skonfigurowaniu przekierowań i weryfikacji własności.
Przy migracji domeny przekierowania trzeba utrzymać co najmniej 180 dni. Rozsądnie jest też opłacać starą domenę co najmniej rok, żeby nie oddać jej przypadkowo komuś innemu i nie przerwać kontroli nad przekierowaniami. To konkretna decyzja organizacyjna, którą trzeba wpisać do planu, a nie zostawiać księgowości albo wykonawcy "do pamiętania".
Po wdrożeniu nie oceniaj skutku po jednym dniu. Większe zmiany mogą powodować wahania pozycji, bo Google musi ponownie przejść przez stare i nowe adresy. Jednocześnie nie wolno tłumaczyć każdego spadku "normalną migracją". Jeśli błędy techniczne są widoczne od razu, trzeba je naprawiać od razu.
Monitoring po wdrożeniu: co jest normalne, a co alarmowe
Monitoring po migracji nie polega na patrzeniu raz w tygodniu na ogólny ruch organiczny. Trzeba śledzić najważniejsze URL-e, indeksowanie, błędy 404, przekierowania, sitemapę, kliknięcia, wyświetlenia i zapytania. Najlepiej porównywać dane z okresem sprzed wdrożenia, bo bez punktu odniesienia łatwo pomylić sezonowość, kampanię albo normalny szum z problemem migracyjnym.
Jeżeli osobno kontrolujesz ranking najważniejszych fraz, przyda się stały proces, żeby sprawdzać pozycję strony w Google bez wyciągania wniosków z pojedynczego dnia lub spersonalizowanego wyniku.
Pierwsza lista kontrolna powinna obejmować URL-e o najwyższym znaczeniu: strona główna, kluczowe usługi, kategorie, produkty, treści z ruchem organicznym i adresy z linkami zewnętrznymi. To na nich najszybciej widać, czy mapa URL, treść i przekierowania zadziałały.
| Co monitorować | Co może być normalne | Co jest alarmowe |
|---|---|---|
| Kliknięcia i wyświetlenia | Krótkie wahania po większej zmianie | Stały spadek na kluczowych URL-ach bez technicznego wyjaśnienia |
| Indeksacja nowych URL-i | Stopniowe przetwarzanie nowych adresów | Ważne strony nie trafiają do indeksu albo mają błędny canonical |
| Błędy 404 | Pojedyncze stare, nieistotne adresy | Masowy wzrost 404 dla stron z ruchem lub linkami |
| Przekierowania | Stare adresy widoczne jako przekierowane | Pętle, łańcuchy, błędne cele i przekierowania na stronę główną |
| Sitemap XML | Google przetwarza nową mapę z czasem | Mapa zawiera stare, testowe, zablokowane albo niekanoniczne URL-e |
| Zapytania | Część fraz może się przetasować | Strona przestaje odpowiadać na główne intencje, które wcześniej dowoziła |
Warto ustalić rytm kontroli jeszcze przed publikacją. Na początku potrzebna jest częstsza obserwacja kluczowych URL-i i błędów technicznych. Później monitoring można przełożyć na normalny raport SEO, ale przez pierwsze tygodnie po większej migracji ważna jest szybka reakcja, nie estetyczny PDF.
Sygnały wymagające szybkiej reakcji
- Najważniejsze strony mają `noindex` albo są zablokowane w `robots.txt`: to nie jest normalne wahanie po migracji.
- Stare URL-e z ruchem zwracają 404: sprawdź mapę przekierowań i priorytetowe adresy.
- Nowa sitemap zawiera złe adresy: Google dostaje sprzeczny sygnał o tym, które URL-e są właściwe.
- Treść kluczowych stron jest znacznie uboższa niż wcześniej: problem może leżeć w utracie odpowiedzi na intencję, nie tylko w technice.
Jeżeli widzisz spadek, diagnozuj go od techniki do treści. Najpierw sprawdź dostępność URL-a, status HTTP, canonical, indeksację, sitemapę i przekierowania. Dopiero potem oceniaj, czy problem wynika z gorszego dopasowania treści, zmiany struktury linkowania albo konkurencji w wynikach wyszukiwania.
Jak wpisać SEO do zakresu przebudowy
Najbezpieczniej potraktować SEO jako część zakresu projektu, a nie komentarz na końcu umowy. Kupujący powinien widzieć, kto odpowiada za inwentaryzację starych adresów, mapę URL, przekierowania, przeniesienie treści, testy techniczne, wdrożenie sitemap i monitoring po starcie. Jeśli tego nie ma w ofercie, trudno później wymagać, żeby zostało zrobione.
Dobry zakres nie musi być długi, ale powinien być konkretny. Zamiast zapisu "przebudowa z zachowaniem SEO" lepiej mieć listę zadań i odpowiedzialności. Wtedy wiadomo, czy wykonawca strony robi tylko wdrożenie techniczne, czy też bierze udział w decyzjach o URL-ach, treści i indeksacji.
| Obszar w zakresie | Co powinno być jasne |
|---|---|
| Inwentaryzacja | Kto zbiera stare URL-e, dane z GSC, GA4 lub innej analityki, sitemap i crawla |
| Mapa URL | Kto decyduje, co zostaje, co zmienia adres, a co znika |
| Przekierowania | Kto przygotowuje reguły, kto je wdraża i kto testuje |
| Treść | Kto przenosi, skraca, rozbudowuje lub łączy podstrony |
| Technika | Kto odpowiada za statusy HTTP, canonicale, sitemap, robots.txt i noindex |
| Pomiar | Kto sprawdza analitykę, zdarzenia i konwersje po wdrożeniu |
| Monitoring | Kto obserwuje błędy i kluczowe URL-e po starcie |
Jeżeli serwis ma dużo URL-i, ważny ruch organiczny, sklep, rozbudowane filtry, wcześniejsze migracje albo zmianę domeny, warto włączyć specjalistę SEO przed wdrożeniem, nie po spadku. Przy projekcie, w którym przebudowa ma chronić albo rozwijać pozycjonowanie stron, audyt po fakcie często polega na naprawianiu skutków decyzji, które dało się przewidzieć na etapie mapy URL i testów.
Najważniejsza zasada brzmi: przebudowa strony nie powinna kasować dorobku widoczności tylko dlatego, że projekt graficzny i wdrożenie techniczne biegły szybciej niż plan migracji. Nowa strona ma być lepsza dla użytkownika, ale musi też zachować ciągłość adresów, treści i sygnałów, które Google już zna.