Migracja domeny a widoczność marki w AI — jak przenieść encję bez utraty cytowań?

Zmiana domeny jest prosta tylko wtedy, gdy patrzy się na nią jak na zmianę adresu w przeglądarce. Dla wyszukiwarki i systemu generatywnego sytuacja wygląda inaczej: marka ma stary adres zapisany w indeksach, linkach partnerów, katalogach, artykułach, profilach społecznościowych, serwisach opinii i danych opisujących organizację. Samo ustawienie przekierowania nie aktualizuje tych źródeł.

To właśnie dlatego po poprawnej technicznie migracji można zobaczyć dość irytujący efekt: użytkownik pyta ChatGPT, Gemini, Copilot czy Perplexity o firmę, a odpowiedź nadal wskazuje starą domenę. Czasami link działa dzięki przekierowaniu, ale sama odpowiedź pokazuje, że encja marki nie została jeszcze jednoznacznie powiązana z nowym adresem. Przy przejściu z domeny .pl na .com problem jest jeszcze szerszy, bo zmienia się również sygnał geograficzny witryny. Przy łączeniu kilku serwisów dochodzi z kolei pytanie, które stare adresy naprawdę mają odpowiedniki, a które powinny po prostu zniknąć.

Dobrej migracji nie mierzy się więc tym, czy po wpisaniu starego URL-a otwiera się nowa strona. Mierzy się ją tym, czy po kilku tygodniach wyszukiwarki, systemy AI i zewnętrzne źródła opisują tę samą firmę tym samym adresem.

Najpierw mapa adresów, dopiero potem zmiana domeny

Największy błąd pojawia się jeszcze przed uruchomieniem nowego serwisu: firma traktuje domenę jako jeden obiekt. Tymczasem przenosi się nie domenę, lecz setki albo tysiące konkretnych URL-i wraz z ich historią, linkami, tematyką i znaczeniem.

Przy prostym przejściu z firma.pl/oferta/usluga-a na firma.com/pl/oferta/usluga-a sytuacja jest czytelna. Stary adres powinien prowadzić bezpośrednio do odpowiadającego mu nowego URL-a za pomocą stałego przekierowania 301 albo 308.

Znacznie gorzej wygląda częsty wariant po połączeniu kilku stron:

marka-a.pl/produkt-x
marka-b.pl/produkt-x
grupa.pl/rozwiazania/produkt-x

mają zostać zastąpione jedną stroną:

marka.com/pl/produkty/produkt-x

Takie scalenie jest prawidłowe, jeśli nowa strona rzeczywiście przejmuje temat i funkcję poprzednich. Nie ma natomiast sensu przekierowywać kilkuset niepowiązanych podstron na stronę główną tylko po to, aby „nie tracić mocy domeny”. Wyszukiwarka może potraktować takie przekierowania jak soft 404, a użytkownik zamiast materiału, którego szukał, trafia na generyczny homepage.

Przed migracją powinien więc istnieć arkusz zawierający minimum: stary URL, nowy URL, kod odpowiedzi, canonical, wersję językową, liczbę wejść organicznych, liczbę wartościowych linków zewnętrznych oraz decyzję „przekierować / usunąć / scalić”. Przy dużym serwisie pierwszeństwo mają adresy generujące ruch, konwersje i backlinki oraz strony regularnie odwiedzane przez crawlery.

Kolejność prac ma znaczenie:

• Najwyższy priorytet: mapowanie URL 1:1, przekierowania 301/308, nowe canonicale, wewnętrzne linkowanie, sitemap XML, robots.txt, indeksowalność i działający HTTPS.

• Drugi priorytet: hreflang, dane strukturalne, profile marki, najważniejsze linki partnerów, profile społecznościowe i katalogi.

• Trzeci priorytet: mniej istotne stare publikacje, niszowe katalogi, archiwalne materiały PDF i wzmianki generujące niewielki ruch.

Przy przejściu z domeny krajowej .pl na domenę międzynarodową, np. .com, nie należy po prostu przenieść polskiej wersji na stronę główną i później dopisywać tłumaczeń. Domena krajowa jest silnym sygnałem związku serwisu z konkretnym rynkiem. Po zmianie na domenę generyczną ten sygnał trzeba odbudować strukturą serwisu.

Praktyczny wariant wygląda np. tak:

firma.com/pl/ — Polska
firma.com/en/ — wersja międzynarodowa
firma.com/de/ — Niemcy

Każda wersja powinna mieć własny canonical wskazujący na siebie oraz poprawne, wzajemne oznaczenia hreflang, np. pl-PL, de-DE, en czy — jeśli istnieje wersja domyślna — x-default. Nie należy ustawiać canonicala wszystkich tłumaczeń na wersję angielską. Wtedy firma sama sygnalizowałaby, że pozostałe warianty są kopiami.

Równie problematyczne jest automatyczne przekierowywanie każdego polskiego użytkownika na /pl/ wyłącznie na podstawie adresu IP lub języka przeglądarki. Robot może nie zobaczyć wszystkich wersji. Bezpieczniej pozostawić indeksowalne, osobne URL-e i zaoferować użytkownikowi przełącznik języka.

Przy łączeniu kilku domen dochodzi jeszcze jedna decyzja. Nie każda stara strona zasługuje na przekierowanie. Jeżeli podstrona nie ma ruchu, linków, odpowiednika i opisuje usługę, której firma już nie świadczy, prawidłowym rozwiązaniem może być odpowiedź 404 lub 410. Sztuczne przeciąganie takiego adresu na luźno związaną kategorię komplikuje strukturę i zaciera temat nowej strony.

Jak długo pozostawić przekierowania? Absolutne minimum to 12 miesięcy. W praktyce przy migracji marki utrzymywałbym je przez co najmniej 24 miesiące, a dla starej domeny firmowej, która przez lata pojawiała się w publikacjach, umowach, PDF-ach i katalogach — bezterminowo. Koszt odnowienia jednej domeny jest zwykle nieporównywalnie mniejszy niż koszt odzyskiwania ruchu i reputacji po jej przejęciu przez kogoś innego.

Google zaleca utrzymywanie przekierowań przez co najmniej rok, a dokumentacja Bing dotycząca migracji wskazuje okres 1–2 lat, najlepiej dłużej. To istotna różnica względem popularnego jeszcze kilka lat temu podejścia „zostawmy 301 na pół roku i wyłączmy stary hosting”.

Nie trzeba przy tym utrzymywać pełnego starego serwisu. Wystarczy lekka infrastruktura obsługująca domenę, certyfikat TLS i reguły przekierowań.

Informację o poprzednim adresie również dobrze pozostawić, ale nie jako wielki banner na każdej stronie. Przez pierwsze 6–12 miesięcy rozsądna jest krótka adnotacja na stronie „O nas”, „Kontakt” albo dedykowanej stronie wyjaśniającej zmianę: marka X działa obecnie pod adresem firma.com, wcześniej korzystała z firma.pl. Przy marce z dużą liczbą historycznych publikacji taką stronę można pozostawić bezterminowo. Pomaga ona użytkownikom i systemom automatycznym połączyć dwa adresy z jednym podmiotem.

Encję przenosi się również poza własną stroną

Migracja kończąca się na serwerze jest wykonana mniej więcej w połowie. Drugą połowę stanowią zewnętrzne źródła opisujące przedsiębiorstwo.

System AI odpowiadający na pytanie „jaka jest oficjalna strona firmy X?” nie musi opierać się wyłącznie na homepage’u. Może znaleźć profil LinkedIn, katalog branżowy, artykuł prasowy, stronę partnera, profil opinii albo wynik wyszukiwarki zawierający stary adres. Jeżeli piętnaście takich źródeł wskazuje .pl, a tylko sama firma informuje o .com, rozpoznanie zmiany może potrwać znacznie dłużej.

Nie ma sensu aktualizować wszystkiego losowo. Najpierw trzeba znaleźć źródła, które mają największą wagę operacyjną: generują wejścia, pojawiają się wysoko po wpisaniu nazwy marki albo są wielokrotnie przywoływane przez inne strony.

W pierwszej kolejności sprawdziłbym Google Business Profile, LinkedIn, Facebook, YouTube, Apple Business Connect, profile branżowe, profile marketplace’ów oraz wpisy w najważniejszych serwisach opinii używanych przez firmę. W polskich realiach mogą to być np. Trustpilot, Opineo, Ceneo, GoWork lub branżowe katalogi specjalistyczne. Nie chodzi o zakładanie konta w każdym z nich. Jeśli jednak profil już istnieje i wyświetla starą domenę, powinien trafić na listę migracyjną.

Jeszcze ważniejsze bywają profile partnerów. Producent może mieć kilkudziesięciu dystrybutorów, firma technologiczna — integratorów, a kancelaria — profile w organizacjach branżowych. Te strony często mają większy autorytet i dłuższą historię niż przypadkowy katalog. Aktualizacja linku w dziesięciu takich miejscach bywa wartościowsza niż poprawienie stu niskiej jakości wpisów.

Podobnie z publikacjami. Nie trzeba pisać do każdej redakcji, która w 2017 roku wspomniała markę. Najpierw warto zaktualizować artykuły, rankingi, wywiady i strony autorów, które nadal generują wejścia albo znajdują się wysoko na zapytania brandowe. Jeżeli redakcja nie chce zmieniać treści starego artykułu, wystarczy aktualizacja linku albo krótka nota redakcyjna.

Przy połączeniu kilku marek trzeba być bardziej ostrożnym. Jeżeli spółki faktycznie pozostają odrębnymi podmiotami, nie powinno się sztucznie przedstawiać ich w danych jako jednej organizacji wyłącznie dlatego, że korzystają z jednej domeny. Jedna witryna nie zawsze oznacza jedną encję. Struktura organizacji musi odpowiadać temu, co istnieje prawnie i biznesowo.

Na nowej stronie trzeba równolegle uporządkować dane strukturalne Organization lub — dla fizycznych placówek — odpowiednie typy LocalBusiness. Pole url powinno wskazywać nową oficjalną witrynę, logo nowy adres pliku, a sameAs zweryfikowane zewnętrzne profile jednoznacznie odnoszące się do tej samej organizacji. Jeśli marka zmieniła również nazwę, można wykorzystać alternateName, o ile faktycznie jest to nazwa, pod którą firma była rozpoznawana.

Najgorszy wariant to mieszanka danych: JSON-LD wskazuje .com, stopka nadal .pl, profil LinkedIn .com, dokument PDF .pl, a schema na podstronie kontaktowej zawiera jeszcze stary URL logo. Takie drobiazgi łatwo przeoczyć, szczególnie gdy dane strukturalne generuje wtyczka CMS, moduł e-commerce albo osobny system dla oddziałów.

Po wdrożeniu trzeba więc przeszukać kod i bazę treści pod kątem starej domeny. Nie tylko linki <a href>. Również canonical, hreflang, Open Graph, schema.org, adresy obrazów, sitemap XML, pliki PDF, feedy produktowe, dane Merchant Center, podpisy e-mail i szablony newsletterów.

Widoczność w AI trzeba zmierzyć przed migracją, nie dopiero po problemie

Nie istnieje przycisk „przenieś cytowania AI”. Stałe przekierowania, spójne dane i aktualizacja zewnętrznych źródeł zwiększają prawdopodobieństwo prawidłowego rozpoznania nowej domeny, ale żaden operator strony nie może zagwarantować, że konkretny model od określonego dnia przestanie podawać stary adres.

Dlatego przed migracją trzeba zbudować benchmark.

Na 14 dni przed zmianą przygotowałbym zestaw 30–50 stałych promptów. Nie należy ograniczać się do pytania „jaka jest strona firmy X?”. Test powinien obejmować zapytania brandowe, produktowe, porównawcze, reputacyjne oraz takie, w których nazwa firmy nie występuje.

Dla producenta oprogramowania przykładowy zestaw mógłby obejmować pytania o oficjalną stronę, ofertę, kraj pochodzenia, partnerów, alternatywy dla produktu, rekomendowanych dostawców w Polsce i Europie oraz źródła informacji o konkretnej funkcji produktu.

Te same prompty należy uruchomić przynajmniej w kilku środowiskach wykorzystujących wyszukiwanie internetowe, np. ChatGPT Search, Google AI Mode lub innych funkcjach generatywnych Google Search, Microsoft Copilot i Perplexity. Wyniki powinny być sprawdzane osobno po polsku i angielsku. Przy marce działającej na kilku rynkach sensowne są również testy w odpowiednich wersjach językowych.

Nie wystarczy zapisać „odpowiedź była dobra”. W arkuszu powinny znaleźć się: data testu, dokładny prompt, system, język, wskazana domena, wszystkie cytowane URL-e, poprawność nazwy firmy, opis oferty, adres siedziby, rynek działania oraz błędy rzeczowe. Dobrze zachowywać także zrzut lub pełną treść odpowiedzi, ponieważ wynik tego samego promptu może później wyglądać inaczej.

Praktyczny harmonogram kontroli to T-14, T-7, dzień migracji, T+3, T+7, T+14, T+30, T+60 i T+90. Przy dużym połączeniu kilku marek warto wykonać jeszcze kontrolę po 180 dniach.

Najbardziej użyteczne są cztery wskaźniki: udział odpowiedzi wskazujących nową domenę, udział odpowiedzi nadal cytujących starą domenę, odsetek odpowiedzi z poprawnymi danymi o marce oraz lista źródeł, z których systemy najczęściej korzystają.

Można ustalić wewnętrzny cel, np. co najmniej 90% poprawnych wskazań nowej domeny w bezpośrednich zapytaniach brandowych po 60 dniach, ale nie należy traktować go jako gwarantowanego terminu działania modeli. Pytania niebrandowe są znacznie bardziej zmienne i nie powinny stanowić prostego testu „migracja udana / nieudana”.

Jeżeli po 30 dniach system AI nadal cytuje starą domenę, najpierw trzeba sprawdzić źródło cytowania. Gdy prowadzi ono przez poprawne 301 do właściwej nowej podstrony, sytuacja jest mniej groźna — indeks może być po prostu nieodświeżony. Gorzej, jeśli system opiera odpowiedź na profilu partnera, katalogu lub stronie opinii, gdzie stary adres wciąż występuje jako oficjalny. Wtedy nie ma czego naprawiać na nowej domenie. Trzeba poprawić źródło zewnętrzne.

Dotyczy to również mniejszych serwisów z profilami przedsiębiorstw. Jeśli firma ma wpis w katalogu takim jak darmowe ogłoszenia firm, po migracji należy sprawdzić adres witryny, nazwę marki, opis działalności oraz ewentualne dane kontaktowe tak samo jak w większych platformach. Pozostawienie starego URL-a w aktywnym profilu tworzy kolejny publiczny sygnał, że poprzednia domena nadal jest właściwa.

Trzeba też kontrolować dostęp robotów. Jeżeli polityka firmy zakłada widoczność w wyszukiwaniu generatywnym, przed zmianą warto sprawdzić robots.txt, reguły CDN i WAF. Przypadkowa blokada crawlerów związanych z wyszukiwaniem może sprawić, że nowa domena będzie znacznie trudniejsza do ponownego odkrycia. Szczególnie łatwo o taki błąd po migracji na Cloudflare, nowy system bezpieczeństwa albo nową platformę hostingową, gdzie stare reguły dostępu są kopiowane bez audytu.

W przypadku ChatGPT dodatkowym sygnałem jest ruch polecający: wejścia z wyszukiwania ChatGPT mogą zawierać utm_source=chatgpt.com. Google udostępnia natomiast dane dotyczące widoczności w swoich generatywnych funkcjach wyszukiwania w Search Console. Tych danych nie należy mieszać z ręcznym monitoringiem odpowiedzi. Analityka pokazuje rzeczywisty ruch i ekspozycję, a benchmark promptów pokazuje, co model mówi o marce i jakie źródła wskazuje. Dopiero razem dają użyteczny obraz migracji.

Najbardziej irytująca część całego procesu jest taka, że synchronizacja nie następuje jednocześnie. Search Console może już raportować nową domenę, partnerzy wciąż mają starą, a jeden system AI będzie podawał nowy adres tydzień wcześniej niż drugi. Nie jest to powód do ciągłego zmieniania konfiguracji. Jeżeli przekierowania, indeksacja i dane są poprawne, kolejne chaotyczne poprawki potrafią tylko utrudnić diagnozę.

FAQ

Czy przekierowanie 301 gwarantuje zachowanie cytowań w odpowiedziach AI?
Nie. 301 informuje roboty i użytkowników, że zasób został trwale przeniesiony, ale system AI może nadal korzystać z wcześniejszego indeksu albo ze źródła zewnętrznego zawierającego stary adres. Przekierowanie jest fundamentem migracji, nie mechanizmem bezpośredniego zarządzania odpowiedziami modeli.

Lepiej użyć 301 czy 308?
Oba kody oznaczają trwałe przekierowanie i mogą służyć do migracji. 301 jest najbardziej typowym wyborem przy zmianie adresów stron, a 308 jest przydatne m.in. wtedy, gdy trzeba zachować metodę HTTP. Ważniejsze od wyboru między nimi jest to, aby przekierowanie było serwerowe, trwałe i prowadziło bezpośrednio do docelowego URL-a.

Jak długo utrzymywać przekierowania ze starej domeny?
Minimum 12 miesięcy. Przy migracji ważnej marki rozsądniejszym standardem operacyjnym są 24 miesiące, a domenę firmową z dużą historią linków najlepiej odnawiać bezterminowo. Nie trzeba utrzymywać starego CMS-a — wystarczy infrastruktura obsługująca przekierowania.

Jak długo informować użytkowników o poprzedniej domenie?
Widoczna informacja na stronie „O nas”, „Kontakt” lub stronie dotyczącej migracji przez 6–12 miesięcy zwykle wystarcza. Jeżeli stary adres występuje w wielu publikacjach i dokumentach, stronę opisującą historię zmiany można zostawić na stałe.

Czy podczas przejścia z .pl na .com polska wersja powinna trafić na stronę główną?
Nie musi. Przy serwisie międzynarodowym czytelniejsza jest struktura typu /pl/, /en/, /de/, połączona prawidłowym hreflang. Pozwala ona zachować wyraźne wersje regionalne i językowe bez uzależniania ich od lokalizacji użytkownika.

Czy przy łączeniu kilku serwisów wszystkie stare URL-e powinny dostać 301?
Nie. Przekierowanie ma sens wtedy, gdy istnieje nowy materiał odpowiadający staremu. Strony bez wartościowego odpowiednika lepiej zakończyć kodem 404 lub 410 niż masowo kierować na stronę główną albo przypadkową kategorię.

Czy warto dodawać starą domenę do sameAs w danych Organization?
Po zakończeniu migracji głównym adresem organizacji powinien być nowy URL, a sameAs lepiej wykorzystać do jednoznacznych profili organizacji w zewnętrznych serwisach. Stary adres domeny można opisać tekstowo na stronie dotyczącej zmiany. Nie należy tworzyć sztucznego zestawu URL-i tylko po to, aby „wzmocnić encję”.

Czy plik llms.txt rozwiąże problem widoczności po migracji?
Nie należy traktować go jako mechanizmu migracyjnego. Google nie wymaga specjalnego pliku dla swoich generatywnych funkcji wyszukiwania. Znacznie wyższy priorytet mają indeksowalne strony, poprawne przekierowania, canonicale, dane organizacji i spójne źródła zewnętrzne.

Kiedy uznać migrację za zakończoną?
Nie w dniu uruchomienia nowej domeny. Sensownym punktem kontrolnym jest 60–90 dni, gdy większość ważnych adresów jest już indeksowana pod nową domeną, stary ruch maleje, główne profile zewnętrzne zostały zmienione, a testy AI przestają regularnie wskazywać poprzedni adres. Same przekierowania pozostają aktywne znacznie dłużej.

Pierwszą rzeczą do zrobienia nie jest więc zmiana DNS ani publikacja komunikatu o nowej domenie. Najpierw trzeba przygotować i przetestować mapę stary URL → docelowy URL dla wszystkich stron mających ruch, linki lub znaczenie biznesowe. Jeżeli choć najważniejsze adresy nadal mają trafić „na razie na homepage”, migrację lepiej przesunąć. To właśnie błędne mapowanie powoduje problemy, których później nie naprawi ani schema.org, ani katalogi, ani dodatkowe działania pod widoczność w AI.