Migracje, redesigny i zmiany struktury serwisu

Inwentaryzacja URL-i przed migracją

Zanim powstanie mapa przekierowań, zbieramy pełną listę adresów, które dziś istnieją w Twoim serwisie. Aktualna mapa witryny zwykle pomija stare podstrony, parametry i adresy z linkami zewnętrznymi. Dlatego łączymy dane z kilku źródeł.

Jak to robimy

1. Crawlujemy cały serwis i eksportujemy adresy z mapy witryny oraz z bazy CMS.
2. Dodajemy adresy z raportów Google Search Console i stron docelowych w Google Analytics 4.
3. Uzupełniamy listę o adresy z logów serwera i o strony, do których prowadzą linki zewnętrzne.
4. Usuwamy duplikaty i opisujemy każdy adres ruchem, liczbą linków oraz statusem HTTP.

Co otrzymujesz

Dostajesz arkusz inwentaryzacji ze wszystkimi znanymi adresami i ich wartością dla SEO. Na tej liście opieramy mapę przekierowań, co ogranicza ryzyko pominięcia ważnej podstrony.

Kiedy i w jakiej formie: Przed migracją

• Screaming Frog
• Google Search Console
• Google Analytics 4
• monitoring linków

Mapa przekierowań 1:1

Każdemu staremu adresowi przypisujemy nowy odpowiednik o najbliższej treści i tej samej intencji. Masowe przekierowanie na stronę główną Google często traktuje jak błąd 404. Stary adres traci wtedy wartość zebraną przez lata.

Jak to robimy

1. Dopasowujemy adresy automatycznie po ścieżkach i tytułach, a potem ręcznie weryfikujemy wyniki.
2. Dla stron bez bezpośredniego odpowiednika wybieramy najbliższą kategorię lub stronę tematyczną.
3. Adresy bez wartości i bez odpowiednika oznaczamy do zwrotu kodu 410 zamiast przekierowania.
4. Sprawdzamy mapę pod kątem pętli, łańcuchów i przekierowań na adresy, które same zwracają błąd.

Co otrzymujesz

Otrzymujesz mapę przekierowań 301 gotową do wdrożenia przez programistów. Każdy stary adres ma w niej przypisany cel albo świadomą decyzję o wygaszeniu.

Kiedy i w jakiej formie: Przed migracją

• Screaming Frog
• Google Search Console

Staging crawl

Przed startem nowej wersji skanujemy staging tak, jakby był już publiczną stroną. Porównujemy wyniki z obecnym serwisem i wychwytujemy różnice, które mogą obniżyć widoczność po premierze.

Jak to robimy

1. Crawlujemy staging z uwierzytelnieniem, pomijając na czas testu jego blokadę indeksacji.
2. Sprawdzamy indeksowalność, canonical, tytuły, nagłówki, statusy HTTP i linki wewnętrzne.
3. Weryfikujemy dane strukturalne, mapy witryny, plik robots.txt i wersję mobilną szablonów.
4. Mierzymy wydajność typowych szablonów i porównujemy ją z wynikami obecnej strony.
5. Zgłaszamy programistom listę błędów z priorytetami i sprawdzamy poprawki kolejnym crawlem.

Co otrzymujesz

Dostajesz raport z testu stagingu z listą błędów do poprawy przed publikacją. Nowa wersja startuje bez problemów, które inaczej zobaczylibyśmy dopiero w spadku ruchu.

Kiedy i w jakiej formie: Przed launch

• Screaming Frog
• Sitebulb
• Lighthouse
• PageSpeed Insights

Zachowanie treści i meta danych

Porównujemy treść starych i nowych podstron, żeby w redesignie nie zniknęło nic, co pracowało na pozycje. Nowy projekt graficzny często skraca teksty, gubi nagłówki albo zmienia tytuły stron bez analizy SEO.

Jak to robimy

1. Eksportujemy z obecnej strony title, meta description, nagłówki, linki wewnętrzne i dane strukturalne.
2. Wykonujemy ten sam eksport na stagingu i zestawiamy oba zbiory dla każdej pary adresów.
3. Oznaczamy strony, na których ubyło treści, obrazów z tekstem alternatywnym albo wezwań do działania.
4. Przekazujemy zespołowi listę brakujących elementów do przywrócenia przed publikacją.

Co otrzymujesz

Masz porównanie starej i nowej wersji dla każdej ważnej podstrony. Treści i metadane, które budowały widoczność, przechodzą do nowego serwisu.

Kiedy i w jakiej formie: Przed launch

• Screaming Frog
• Sitebulb

QA robots/noindex

Najczęstszy błąd po migracji to pozostawiony noindex albo blokada skopiowana ze stagingu. Zaraz po publikacji sprawdzamy, czy nowa strona jest otwarta dla robotów wyszukiwarek.

Jak to robimy

1. Czytamy plik robots.txt na produkcji i szukamy reguł, które blokują cały serwis lub jego sekcje.
2. Crawlujemy stronę i sprawdzamy znacznik meta robots na wszystkich szablonach.
3. Weryfikujemy nagłówek X-Robots-Tag w odpowiedziach serwera, także dla plików PDF i obrazów.
4. Upewniamy się, że produkcja nie wymaga hasła, które chroniło środowisko testowe.
5. Testujemy wybrane adresy narzędziem do sprawdzania adresów URL w Google Search Console.

Co otrzymujesz

Dostajesz potwierdzenie, że nowa strona jest dostępna dla robotów, albo listę blokad do natychmiastowego zdjęcia. Usuwamy je w dniu publikacji, zanim wpłyną na indeks.

Kiedy i w jakiej formie: Tuż przed i po launch

• Google Search Console
• Screaming Frog

Sitemapy po migracji

Po migracji przygotowujemy nowe mapy witryny, które zawierają wyłącznie docelowe adresy zwracające kod 200. Stare mapy z przekierowanymi adresami usuwamy, żeby nie wprowadzały robota w błąd.

Jak to robimy

1. Generujemy mapy z finalnych adresów i sprawdzamy, czy nie zawierają przekierowań ani błędów.
2. Duże serwisy dzielimy na kilka plików, pamiętając o limicie 50 000 adresów w jednej mapie.
3. Zgłaszamy nowe mapy witryny w Google Search Console i w Bing Webmaster Tools.
4. Usuwamy z obu narzędzi stare mapy witryny, które wskazywały nieaktualne adresy.
5. Obserwujemy w raportach, jak szybko nowe adresy są wykrywane i trafiają do indeksu.

Co otrzymujesz

Wyszukiwarki dostają aktualną listę adresów nowego serwisu. W raporcie widzisz postęp indeksacji nowych adresów w kolejnych tygodniach.

Kiedy i w jakiej formie: Po launch

• Google Search Console
• Bing Webmaster Tools
• Screaming Frog

Monitoring po migracji

W pierwszych dniach po migracji codziennie sprawdzamy, jak nowy serwis radzi sobie w wyszukiwarce. Wczesne wykrycie błędu pozwala go naprawić, zanim spadek ruchu się utrwali.

Jak to robimy

1. Każdego dnia przeglądamy raporty indeksowania i błędów w Google Search Console.
2. Wyszukujemy w crawlu i logach serwera adresy zwracające błędy 404 oraz 5xx.
3. Sprawdzamy na próbce adresów, czy przekierowania działają zgodnie z mapą.
4. Porównujemy pozycje, ruch organiczny i konwersje z okresem sprzed migracji.
5. Zgłaszamy wykryte problemy zespołowi i potwierdzamy ich naprawę kolejnym pomiarem.

Co otrzymujesz

Dostajesz codzienne krótkie notatki z monitoringu, a po okresie wzmożonej kontroli zbiorcze podsumowanie migracji. Wiesz, jak zmieniła się widoczność i co zostało naprawione.

Kiedy i w jakiej formie: Pierwsze 2-4 tygodnie

• Google Search Console
• Google Analytics 4
• monitoring pozycji
• Screaming Frog

Aktualizacja linków wewnętrznych

Po migracji podmieniamy linki wewnętrzne tak, by prowadziły bezpośrednio pod nowe adresy. Przekierowania 301 działają, ale każdy dodatkowy przeskok spowalnia użytkownika i zużywa zasoby robota.

Jak to robimy

1. Crawlujemy nowy serwis i wyszukujemy linki wewnętrzne kierujące na przekierowane adresy.
2. Grupujemy je według miejsca: menu, stopka, wpisy blogowe, karty produktów i moduły powiązane.
3. Poprawiamy linki w szablonach, a w treściach wykonujemy zbiorczą podmianę w bazie danych.
4. Powtarzamy crawl, żeby potwierdzić, że linki wewnętrzne prowadzą wprost do stron z kodem 200.

Co otrzymujesz

Serwis linkuje wewnętrznie do docelowych adresów bez pośrednich przekierowań. Otrzymujesz raport z liczbą poprawionych linków w każdej sekcji.

Kiedy i w jakiej formie: Po launch

• Screaming Frog
• Sitebulb
• WordPress

Aktualizacja linków zewnętrznych

Kontaktujemy się z wydawcami i partnerami, którzy linkują do Twoich starych adresów, i prosimy o aktualizację odnośników. Przekierowanie przenosi wartość linku, ale bezpośredni odnośnik nie zależy od tego, czy reguła przetrwa kolejne zmiany na serwerze.

Jak to robimy

1. Wybieramy najcenniejsze linki zewnętrzne prowadzące do adresów, które zmieniły się w migracji.
2. Pierwszeństwo dajemy linkom z publikacji PR, stron partnerów i branżowych katalogów.
3. Przygotowujemy dla każdego wydawcy krótką wiadomość z dokładnym nowym adresem.
4. Prowadzimy rejestr kontaktów i sprawdzamy, które linki zostały już zaktualizowane.

Co otrzymujesz

Dostajesz listę linków z ich statusem: zaktualizowany, w toku albo bez odpowiedzi. Najcenniejsze odnośniki prowadzą wprost pod nowe adresy.

Kiedy i w jakiej formie: Po migracji

• monitoring linków
• Ahrefs
• Semrush

Plan rollback

Ustalamy z góry, co robimy, jeśli po starcie nowej wersji pojawi się krytyczny błąd. Plan cofnięcia zmian skraca czas reakcji, bo nikt nie musi improwizować pod presją.

Jak to robimy

1. Zabezpieczamy pełną kopię starej strony i bazy danych gotową do przywrócenia.
2. Spisujemy warunki, przy których cofamy wdrożenie, na przykład masowy noindex lub awarię koszyka.
3. Ustalamy listę osób decyzyjnych i sposób kontaktu z nimi w dniu publikacji.
4. Razem z programistami opisujemy procedurę powrotu do poprzedniej wersji krok po kroku.

Co otrzymujesz

Masz spisany plan awaryjny z kopią starej strony, kryteriami decyzji i listą osób odpowiedzialnych. W razie awarii zespół wie, kto decyduje i jak cofnąć zmiany.

Kiedy i w jakiej formie: Przed launch

• WordPress

Komunikacja z klientem i zespołem

Informujemy dział marketingu, sprzedaży, obsługi klienta i zarząd o przebiegu migracji. Każdy zespół powinien znać ryzyka, terminy i zmiany, które dotyczą jego pracy.

Jak to robimy

1. Przygotowujemy krótki opis migracji z harmonogramem i spodziewanym wpływem na ruch.
2. Ustalamy okres wstrzymania publikacji treści, żeby nie zmieniać serwisu w trakcie przenosin.
3. Przekazujemy obsłudze klienta listę zmienionych adresów, o które mogą pytać klienci.
4. Wyjaśniamy, jak monitorujemy migrację i kiedy zespół dostanie pierwsze podsumowanie.

Co otrzymujesz

Zespoły po Twojej stronie znają plan i wiedzą, czego się spodziewać. Nikt nie uruchamia kampanii ani nie publikuje treści na adresach, które właśnie wygaszamy.

Kiedy i w jakiej formie: Przed migracją