Migracja kończy się komunikatem „przenieśliśmy wszystko”. Potem stare linki prowadzą na stronę główną, eksport nie ma wersji, a asystent odpowiada z mieszanki dwóch systemów. Użytkownika nie obchodzi, że nowa platforma jest szybsza. Chce otworzyć dokument i kontynuować pracę.
Migracja AI wymaga mapy treści, danych, relacji i przekierowań. SEO jest częścią procesu, nie zadaniem na ostatni dzień. Test kończy się na publicznym adresie, źródle i skutku, nie na zaimportowanym liczniku.
Zacznij od inwentarza
Wypisz strony, artykuły, dokumentację, obrazy, pliki, wersje językowe, API, webhooki i konta. Dodaj ruch, linki, właściciela i zależności. Nie migruj tylko tego, co widać w menu CMS.
Zachowaj adres, canonical, status, datę, format i powiązania. Przy modelu zapisz prompt, źródła, indeks i historię. Eksport tekstu nie obejmuje automatycznie całego systemu.
Nie kopiuj poufnych danych do arkusza inwentarza. Wystarczą identyfikatory i kategorie. Migracja nie powinna tworzyć nowej bazy sekretów.
Zdecyduj, co przenosisz
Nie każda strona musi przejść do nowego systemu. Możesz zachować, zaktualizować, połączyć, wycofać lub zastąpić. Decyzja wymaga intencji i dowodu, nie tylko wieku dokumentu.
Przy usuwaniu przygotuj odpowiedni status lub przekierowanie do rzeczywistego odpowiednika. Nie kieruj wszystkiego na stronę główną. Użytkownik szuka konkretnej odpowiedzi, nie początku nawigacji.
Przy audycie treści stosuj zasady z artykułu o aktualizacji SEO. Migracja jest dobrym momentem porządkowania, ale nie wymiany wszystkiego bez analizy.
Mapa URL jeden do jednego
Dla każdego starego adresu zapisz nowy lub decyzję o wycofaniu. Zachowaj intencję i wersję językową. Nie mapuj artykułu technicznego na ogólną ofertę, bo temat jest podobny.
Przekierowania powinny być trwałe zgodnie z typem zmiany, prowadzić bezpośrednio i działać także dla parametrów wymaganych przez proces. Nie twórz łańcuchów przez kilka systemów.
Test obejmuje wielkość liter, ukośniki, polskie znaki, www i apex. Jedna reguła może przechwytywać za dużo i przekierowywać aktywne strony na przypadkowe odpowiedniki.
Canonical i indeksacja
Po wdrożeniu sprawdź canonical, robots, noindex, sitemapę i statusy. Nowa strona nie powinna wskazywać starego adresu ani wersji testowej. Sitemap zawiera tylko aktualne kanoniczne adresy.
Nie blokuj starego systemu przed sprawdzeniem przekierowań. Wyszukiwarka musi je zobaczyć. Jednocześnie ogranicz dostęp do danych i zapisu zgodnie z planem wyjścia.
Zgłoszenie nowej sitemapy jest informacją dla wyszukiwarki, nie gwarancją natychmiastowej indeksacji. Monitoruj błędy i ruch po zmianie zamiast ogłaszać sukces w dniu przełączenia.
Treść musi opisywać nowy proces
Nie przenoś starych zrzutów, limitów i instrukcji bez przeglądu. Artykuł może zachować intencję, ale wymaga aktualnych kroków i wersji. Zmiana daty bez zmiany treści jest kosmetyką.
Przy case study oznacz okres i wersję, której dotyczy wynik. Nie przedstawiaj starego rezultatu jako dowodu nowego narzędzia. Historia pozostaje prawdziwa w swoim kontekście.
Przy funkcjach stosuj zasady z artykułu o stronie funkcji AI. Migracja powinna aktualizować obietnice, nie tylko adresy.
Dane i relacje przed eksportem
Otwórz rzeczywisty eksport przed zakupem nowego procesu. Sprawdź pola, typy, wersje, obrazy, relacje i identyfikatory. „Eksport JSON” nie mówi, czy import zachowa sens.
Zapisz mapę pól i źródło prawdy. Nie zamieniaj pustych wartości w zero ani nowych statusów w aktywne. Przy semantyce pomocny jest artykuł o mapowaniu pól AI.
Porównaj liczbę obiektów i relacji przed oraz po. Sprawdź duplikaty i osierocone rekordy. Sam import bez błędu nie jest dowodem kompletności.
Uprawnienia i tokeny po zmianie
Nadaj nowe role od minimalnego zakresu. Nie przenoś pełnych praw starego administratora dla wygody. Integracje testowe i produkcyjne powinny mieć osobne konta.
Przy planowej migracji odwołaj stare tokeny po sprawdzeniu nowego procesu i rekonsyliacji. Przy podejrzeniu kompromitacji oceń natychmiastowe odcięcie dostępu oraz uruchomienie planu awaryjnego. Po zamknięciu sprawdź brak nowych operacji.
Przy rolach stosuj zasady z artykułu o przeglądzie uprawnień AI. Migracja jest momentem ograniczania dostępu, nie kopiowania go.
Wersja źródeł i odpowiedzi asystenta
Nie zasilaj nowego asystenta mieszanką starego i nowego eksportu. Oznacz wersję, datę i status źródeł. Archiwum powinno odpowiadać tylko w kontekście historycznym.
Przygotuj pytania kontrolne o cenę, funkcję, błąd i usunięty dokument. Sprawdź, czy odpowiedź korzysta z właściwej wersji i nie cytuje starego cache.
Po usunięciu źródła sprawdź indeks, cache, odpowiedzi i restore. Przy retencji pomocny jest artykuł o usuwaniu kopii AI. Migracja często wskrzesza dane, których nikt nie spodziewał się w nowym systemie.
Test przed przełączeniem
Wykonaj migrację próbną na ograniczonym zakresie. Sprawdź adresy, treści, relacje, role, formularze, obrazy, RSS, sitemapę i API. Nie ograniczaj się do strony głównej.
Otwórz stare linki z zewnętrznych źródeł i kampanii. Sprawdź przekierowanie do właściwej treści. Test powinien obejmować telefon, desktop i bezpośrednie wejście bez logowania.
Porównaj sumy kontrolne i błędy krytyczne. Nie przechodź dalej, jeżeli brakuje źródeł lub relacji. Lepszy krótki postój planowany niż długi detektyw po publikacji.
Przełączenie w małych etapach
Jeżeli proces pozwala, migruj jeden typ treści lub zadania. Zachowaj poprzedni kanał tylko do odczytu z jasnym statusem. Nie pozwól na równoległy zapis w dwóch systemach bez źródła prawdy.
Po każdym etapie sprawdź skutki i zależne adresy. Nie zwiększaj zakresu przy nierozstrzygniętych błędach krytycznych. Harmonogram powinien przewidywać zatrzymanie i powrót.
Przy procesie pomocny jest artykuł o migracji między narzędziami AI. SEO jest jedną warstwą tej samej decyzji, nie osobnym projektem po fakcie.
Monitoring po migracji
Sprawdzaj błędy 404, przekierowania, canonical, indeksację, ruch, formularze i zgłoszenia. Nie mierz tylko dostępności nowej strony. Użytkownik może trafiać na niewłaściwe odpowiedzi.
Porównuj podobne okresy i uwzględnij sezon. Spadek lub wzrost nie zawsze wynika z migracji. Zapisz daty zmian i wersje dla analizy.
Przy linkach i canonical stosuj zasady z artykułu o automatycznych testach SEO. Testy powinny obejmować cały stan po zmianie, nie tylko listę planowanych adresów.
Plan wyjścia od starego dostawcy
Wykonaj wymagany eksport, odwołaj integracje, ogranicz konta i zleć usunięcie zgodnie z umową. Nie zamykaj dostępu przed zakończeniem odbioru danych. Nie zostawiaj publicznych linków do starych raportów.
Sprawdź, czy backup i synchronizacja nie przywracają usuniętych obiektów. Zachowaj dowody operacji bez poufnych treści. Data zakończenia powinna być zgodna z procesem i właścicielem.
Przy dostawcy pomocny jest plan wyjścia Aeneia Signal. Aeneia Audit pomaga zmapować dane, role i skutki przed przełączeniem.
Przykład: przekierowanie wszystkiego na stronę główną
Stary przewodnik o integracji trafia na nową ofertę ogólną. Technicznie nie ma 404, ale użytkownik nie znajduje odpowiedzi. Wyszukiwarka również dostaje inny dokument.
Naprawa wymaga odtworzenia właściwej treści lub przekierowania do konkretnego odpowiednika. Jeżeli treść została wycofana, zastosuj właściwy status i zaktualizuj linki. Nie zastępuj każdej intencji stroną sprzedażową.
Po zmianie sprawdź stare kampanie, cytowania i linki wewnętrzne. Jedna reguła mniej w .htaccess nie wystarczy. Odbiór dotyczy rzeczywistej ścieżki użytkownika.
Odbiór przez osobę spoza projektu
Poproś kogoś o wykonanie trzech zadań: otwarcie starego dokumentu, znalezienie aktualnej instrukcji i kontynuowanie procesu. Nie pomagaj. Zapisz, gdzie trafia i jakich informacji brakuje.
Technik sprawdza relacje, tokeny i API. Redakcja ocenia treść i wersje. SEO sprawdza przekierowania, canonical, sitemapę i indeksację. Właściciel procesu akceptuje skutek.
Nie zamykaj migracji na podstawie listy zadań bez dowodów. „Wszystko przeniesione” powinno oznaczać działające strony, dane i procesy z odbiorem.
Po migracji usuń tymczasowe obejścia
Wyłącz debug, testowe przekierowania, publiczne eksporty i konta konsultantów. Sprawdź, czy nie zostawiono danych w logach i starych panelach. Tymczasowe rozwiązania lubią stać się architekturą.
Zachowaj dokumentację wersji i decyzji. Przy następnej zmianie nie powinieneś zaczynać od zgadywania, dlaczego jakiś adres działa inaczej.
Raz po pewnym czasie powtórz test krytycznych linków i procesów. Migracja nie kończy się w dniu przełączenia. Kończy się, kiedy nowy proces jest stabilny, a stary nie wraca przez tylne wejście.
Lista kontrolna przed usunięciem starego adresu
Sprawdź ruch, linki zewnętrzne, zależne artykuły, wersje językowe i rzeczywistą intencję. Adres bez ostatnich wejść może nadal być używany w dokumentacji lub przez klientów. Nie usuwaj go wyłącznie na podstawie pustego raportu z krótkiego okresu.
Jeżeli treść jest zastępowana, porównaj odpowiedzi na główne pytania. Nowa strona powinna zachować wymagane szczegóły lub prowadzić do nich. Nie przekierowuj na artykuł, który tylko zawiera to samo słowo w tytule. Podobieństwo tematu nie jest tym samym co ta sama decyzja.
Pomiar przed i po przełączeniu
Zapisz bazowy ruch, indeksację, błędy i zachowanie krytycznych procesów. Bez stanu początkowego trudno ocenić, czy problem powstał przy migracji. Zachowaj daty poszczególnych etapów i wersje treści.
Po zmianie sprawdzaj zarówno błędy techniczne, jak i jakość przejść. Użytkownik może trafiać na poprawny adres, ale nie znajdować wymaganego pola. Właściciel procesu powinien ocenić skutek obok raportu SEO. Nie przypisuj każdej zmiany ruchu samej migracji bez porównania okresu i kanału.
Komunikat dla stałych użytkowników
Poinformuj o zmianie adresów, funkcji, kont i wymaganych działaniach przed terminem. Nie wysyłaj samego „przenosimy się na lepsze”. Użytkownik potrzebuje konkretu: co zachować, co zniknie, kiedy i gdzie znaleźć pomoc.
Po przełączeniu zaktualizuj wiadomości automatyczne, podpisy, linki w dokumentach i odpowiedzi asystenta. Stara komunikacja potrafi prowadzić do starego systemu długo po jego zamknięciu. Odbiór obejmuje wszystkie kanały, także te mniej widoczne w głównym planie.
Aeneia Audit pomaga zaplanować migrację i odbiór. Przy wyjściu od dostawcy pomocny jest przewodnik Aeneia Signal.
Przekierowanie warto odebrać razem z treścią docelową: stary adres powinien prowadzić do odpowiedzi na to samo pytanie albo jasno wyjaśniać zmianę. Zanotuj przypadki bez odpowiednika i decyzję o ich obsłudze. Sama lista kodów odpowiedzi nie pokaże, czy po przeprowadzce użytkownik znalazł właściwą instrukcję.
Przed zamknięciem projektu wybierz losowo kilka starych adresów i otwórz je bez listy roboczej. Jeżeli prowadzą do właściwych treści, sprawdź procesy i adresy dobrane do zakresu oraz ryzyka migracji. Kilka losowych prób pomaga znaleźć błędy, lecz nie wystarcza jako dowód odbioru całości. Mapa w arkuszu jest pomocna, lecz użytkownik nie porusza się po komórkach. Porusza się po linkach, które muszą działać również po tygodniach i po kolejnej zmianie szablonu.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
