Migracja na stronę wygenerowaną przez AI bez utraty SEO

TL;DR: Kreatory stron oparte na AI potrafią wygenerować czysty kod, ale często pomijają podstawy SEO. Zmapuj stare URL-e, ustaw przekierowania 301, zachowaj meta tagi i sprawdź indeksację przed oraz po przełączeniu. Wdrażaj zmiany etapami, żeby ograniczyć straty.

Strony generowane przez AI są trochę jak nowe motywy WordPressa. Da się je postawić błyskawicznie, a SEO da się zepsuć jeszcze szybciej.

W ciągu ostatniego roku obserwowałem pięć migracji stron opartych na AI. Dwie poszły gładko. Trzy wykrwawiły ruch organiczny -- jedna straciła 47% kliknięć w mniej niż miesiąc. Schemat był zawsze ten sam: efekt z AI wyglądał świetnie, kod był czysty, ale nikt nie sprawdził, czy Google nadal może znaleźć, zaindeksować i odpowiednio oceniać strony, które realnie generowały przychód.

Sama technologia nie jest problemem. Narzędzia takie jak Lovable, v0 i Bolt potrafią wygenerować funkcjonalny, dobrze uporządkowany kod. Problem zaczyna się przy przekazaniu projektu do wdrożenia. Kreatory stron AI nie przenoszą twoich tagów canonical, map przekierowań, struktury linkowania wewnętrznego ani sygnałów EEAT. To właśnie te niewidoczne elementy utrzymują pozycje twoich stron. Jeśli je zgubisz, to w praktyce uruchamiasz zupełnie nową witrynę bez autorytetu, który budowałeś latami.

To schemat działania, którego używam przy migracjach wspieranych przez AI. Gdy trzymamy się procesu, spadki ruchu zostają poniżej 5%. Gdy zespoły pomijają kroki, średni spadek w branży kręci się w okolicach 40%.

Krok 1: Audyt bazowy

Zanim choćby jeden akapit wygenerowany przez AI trafi na produkcję, zrób szczegółowy zrzut stanu strony, którą zaraz zmienisz. To nie jest opcjonalne -- to twoja grupa kontrolna, dzięki której udowodnisz wzrost ruchu albo odpowiednio wcześnie wyłapiesz tąpnięcie, żeby dało się wycofać zmiany.

Crawl i punkt odniesienia

1. Pełna inwentaryzacja URL-i. Uruchom crawl w Screaming Frog albo Sitebulb, żeby zebrać każdy aktywny URL, kod odpowiedzi, docelowy adres canonical i liczbę linków wewnętrznych. Wyeksportuj to do CSV -- ten plik stanie się twoim głównym arkuszem migracji.
2. Punkt odniesienia dla pozycji i backlinków. Pobierz z Google Search Console najważniejsze zapytania, pozycje, kliknięcia i wyświetlenia. Wyeksportuj też dane z Ahrefs albo Semrush dla każdego URL-a: DR, domeny odsyłające, zróżnicowanie anchorów i wartość ruchu. Oznacz URL-e z backlinkami o wysokim autorytecie -- tych stron nie możesz potraktować po macoszemu, jeśli zależy ci na utrzymaniu pozycji.
3. Migawka wyników Core Web Vitals. Użyj raportu Core Web Vitals w GSC albo PageSpeed Insights API, żeby zebrać wyniki LCP, INP i CLS dla każdego szablonu. Zapisz wszystko, co nie mieści się w progu „good” według Google. Treść z AI cię nie uratuje, jeśli wydajność strony siądzie.

Wyeksportuj te pliki bazowe

Trzymaj to w folderze z datą. To jest twoje zdjęcie „przed”.

Otaguj strony według wartości

Poziomy ruchu:

• Tier 1 (Top 10%): Strony generujące 50%+ kliknięć organicznych
• Tier 2 (Kolejne 30%): Stabilny ruch, umiarkowane konwersje
• Tier 3 (Dolne 60%): Strony long-tailowe albo sezonowe

Role konwersyjne:

• Strony sprzedażowe: Bezpośredni przychód albo generowanie leadów
• Strony wspierające: Wpisy blogowe, poradniki, treści porównawcze
• Strony pomocnicze: FAQ, dokumentacja, strony prawne

Dodaj do głównego arkusza kolumny traffic_tier i conversion_role. Jedna szybka tabela przestawna pokaże ci, których URL-i absolutnie nie możesz zepsuć, a które mogą posłużyć jako niskiego ryzyka poligon testowy dla AI.

(Mała dygresja: u jednego klienta 73% przychodu organicznego pochodziło z zaledwie 8 stron. Tych 8 stron w ogóle nie dotykało AI, dopóki Fale 1 i 2 nie potwierdziły, że proces działa na stronach o niskiej wartości. Ta powściągliwość uratowała ich przed bardzo drogą pomyłką.)

Krok 2: Inwentaryzacja treści i mapa kanibalizacji

Najgorsze historie o migracjach z AI zaczynają się od zdania: „Opublikowaliśmy 5000 nowych stron i skanibalizowaliśmy własne pozycje”. Zmapuj każdy URL, jego intencję i nakładanie się z innymi stronami, zanim AI zacznie cokolwiek pisać.

Zmapuj intencję wyszukiwania i znajdź kanibalizację

• Grupuj URL-e według wspólnego rdzenia słowa kluczowego (np. „ai writing tool”, „ai content generator”)
• Sortuj każdą grupę według kliknięć + konwersji
• Strony o tym samym rdzeniu słowa kluczowego i podobnych sygnałach intencji to twoje klastry kanibalizacji
• Oznacz przypadki nakładania się tam, gdzie dwa URL-e pojawiają się na to samo zapytanie w top 20 -- po migracji jeden z nich oberwie, jeśli nie podejdziesz do tego świadomie

Wykryj duplikaty i thin content

Zdecyduj: zachować, przepisać, zastąpić

Krok 3: Proces build-test-launch

Plan techniczny

• Najpierw kopia 1:1, potem publikacja. Postaw środowisko testowe w subfolderze (/ai-preview/), które odwzorowuje hierarchię URL-i z wersji live. Nigdy nie używaj subdomeny -- subdomeny rozbijają autorytet.
• Zachowaj identyczne slugi. /pricing/ na produkcji powinno być /ai-preview/pricing/ na stage. Gdy przyjdzie moment przełączenia, zamieniasz rooty zamiast przepisywać linki.
• Canonicale wskazujące na samą stronę. Na stronach testowych ustaw canonical na docelowy live URL nawet podczas testów.
• Tymczasowe 302 podczas QA. Gdy strona przechodzi ze środowiska testowego na produkcję, wypuść ją najpierw za 302 na jeden do dwóch tygodni. Jeśli metryki się trzymają, zmień na 301.

Wytyczne do generowania treści przez AI

Proces wygląda tak: generowanie, przepuszczenie przez Grammarly, nadpisanie przez człowieka, fact-check, test detektorem -- wszystko na środowisku testowym.

Bramka kontroli jakości

Próg dla detektora AI: Uruchom GPTZero albo Sapling. Celuj w mniej niż 35% „likely AI”. Wszystko powyżej wraca do mocniejszej redakcji przez człowieka.

Checklista on-page: H1 zawiera główne słowo kluczowe (poniżej 60 znaków), meta title i meta description są unikalne oraz zoptymalizowane, co najmniej 8 kontekstowych linków wewnętrznych z różnorodnymi anchorami, schema markup przechodzi walidację w teście Rich Results.

Tylko strony, które przejdą wszystkie bramki kontroli jakości, trafiają ze środowiska testowego na wersję live.

Krok 4: Wdrożenie etapami

Roll-out 10-10-80

Gdzie tylko się da, rób split-testy: zachowaj oryginalny HTML w wariancie z query parametrem (?v=control) i kieruj tam 10% ruchu przez server-side A/B routing.

Monitoring i rollback

Dashboardy w czasie rzeczywistym:

• Pokrycie indeksacji (GSC): wypatruj skoków w „Crawled -- currently not indexed”
• Zmiany pozycji (Ahrefs/Semrush): monitoruj słowa kluczowe z top-100 pod kątem spadków o 2+ pozycje
• Błędy crawlowania (logi): oznacz nowe 404/500 w ciągu minut

Progi alertów automatycznych:

• Spadek ruchu: 15%+ spadku na dowolnej stronie Tier-1 w ruchomym oknie 7-dniowym
• Skok bounce rate: wzrost o 10+ punktów procentowych na zmigrowanych szablonach
• Pogorszenie INP: INP przekracza 200ms na nowym HTML

Protokół rollbacku: Ponownie włącz stary HTML przez parametr kontrolny, przełącz 302 z powrotem na oryginalny plik, wyślij inspekcję URL w GSC, żeby wymusić ponowny crawl, i zrób audyt przyczyny źródłowej.

(Jeszcze jedna dygresja: miałem klienta, który spanikował, gdy strony z Fali 1 pokazały 12% spadku ruchu po czterech dniach. Sprawdziliśmy to -- okazało się, że spadek był sezonowy i idealnie pokrywał się z tym samym wzorcem z poprzedniego roku. Strony AI działały identycznie jak oryginały. Wniosek: zawsze porównuj do tego samego okresu rok do roku, a nie tylko do zeszłego tygodnia.)

Krok 5: Optymalizacja po migracji

• Comiesięczne odświeżanie promptów. Aktualizuj prompty AI o nowe statystyki branżowe, korekty tonu marki i wnioski z tego, co pomaga ograniczyć wykrywalność.
• Kwartalne odzyskiwanie linków. Sprawdzaj w Ahrefs utracone linki spowodowane zmianami URL-i; odzyskuj je przez outreach albo poprawione przekierowania.
• Strojenie Core Web Vitals. Rób ponowny audyt INP, LCP i CLS po każdej zmianie layoutu albo skryptów wynikającej z szablonów AI.
• Dodawanie treści budujących autorytet. Raz na kwartał planuj głębokie materiały pisane przez ludzi albo wywiady z ekspertami, żeby wzmacniać EEAT na tematach o wysokiej stawce.
• Monitoring detektorów. Utrzymuj mniej niż 35% prawdopodobieństwa AI w skali całej strony; jeśli pojawi się dryf, zwiększ udział ręcznej redakcji przez człowieka.

FAQ

Czy Google karze strony napisane przez AI?

Nie automatycznie. Google karze niskiej jakości albo wprowadzające w błąd treści niezależnie od tego, kto je napisał. Ryzyko polega na publikowaniu mdłego, niskoentropijnego tekstu z AI, który nie przechodzi kontroli EEAT. Rozwiązanie: co najmniej 20% nadpisania przez człowieka, cytowania i wyniki prawdopodobieństwa AI poniżej 35%.

Czy mogę przenieść blog na subdomenę podczas przejścia na AI?

Nie rób tego. Subdomeny dzielą link equity i zmuszają Google do ponownego uczenia się sygnałów zaufania. Migruj w obrębie subfolderów i zachowaj identyczne slugi URL-i.

Nasze wersje robocze z AI cytują źródła, które nie istnieją -- jak zatrzymać halucynacje?

Wymuś etap fact-checku: każ modelowi dołączać URL-e, a potem niech człowiek zweryfikuje każdy link. Każde twierdzenie, którego nie da się podeprzeć źródłem, trzeba przepisać albo usunąć.

Ruch na stronach sprzedażowych spadł o 18% po Fali 2 -- rollback czy czekać?

Wycofaj zmiany, jeśli spadek przekracza 15% przez więcej niż siedem kolejnych dni albo jeśli konwersje spadną o więcej niż 10%. Przywróć stary HTML, sprawdź logi i napraw problem przed ponownym wdrożeniem.

Jak często odświeżać prompty AI po migracji?

Co miesiąc. Aktualizuj ton marki, nowe statystyki i wzorce pomagające ograniczyć wykrywalność. Stare prompty z czasem znowu wprowadzają powtarzalność, obniżają entropię i zwiększają ryzyko wykrycia.

Czytaj dalej

• Naprawianie problemów SEO po migracji WordPressa -- Te same zasady działają przy migracji z dowolnej platformy.
• Darmowe narzędzie do audytu SEO -- Zrób audyt przed i po zmianach.
• Broken Link Checker -- Znajdź luki w przekierowaniach, zanim zrobi to Google.