CMPRESS
Opublikowano: Autor: Sebastian MilerAktualizacja: 28.09.2026

Entity collision po rebrandingu: co zrobić, żeby stara i nowa marka nie funkcjonowały jako dwa różne byty

Infografika przedstawia starą i nową wersję marki oraz porządkuje sygnały strony, organizacji, sameAs i profilu firmowego w jedną encję.
Narzędzia czytania

Po zmianie nazwy firmy problem rzadko kończy się na podmianie logo i domeny. Stara marka potrafi nadal istnieć w indeksie Google, Profilu Firmy, danych strukturalnych, profilach społecznościowych, opisach autorów, katalogach branżowych i linkach zewnętrznych. Jeśli jednocześnie uruchomiona zostanie nowa domena i nowa nazwa, wyszukiwarka dostaje dwa zestawy sygnałów, które nie zawsze potrafi od razu połączyć.

To właśnie można roboczo nazwać entity collision: nie jest to oficjalny komunikat ani błąd Google, lecz sytuacja, w której informacje o jednym biznesie zaczynają wyglądać jak dane dotyczące dwóch różnych podmiotów. Typowy przykład: strona główna przedstawia już Nową Markę, ale część podstron ma stare dane Organization, LinkedIn nadal prowadzi do Starej Marki, Profil Firmy używa dawnej nazwy, a portale branżowe wskazują nieaktualną domenę i numer telefonu. Sposób znalezienia sprzeczności między opisem firmy na stronie a JSON-LD omawia audyt spójności encji.

Najgorszym rozwiązaniem jest mechaniczne „wyczyszczenie wszystkiego ze starej nazwy”. Najpierw trzeba odpowiedzieć na ważniejsze pytanie: czy stara i nowa marka rzeczywiście reprezentują ten sam podmiot? Dopiero potem można decydować, które sygnały połączyć, które przekierować, a które powinny pozostać rozdzielone.

Najpierw ustal, czy stara i nowa marka są tą samą encją

Zmiana nazwy marketingowej nie musi oznaczać powstania nowej organizacji. Ale rebranding połączony ze sprzedażą przedsiębiorstwa, zmianą podmiotu prawnego albo całkowitą zmianą modelu działalności może już oznaczać coś zupełnie innego.

Przed zmianami technicznymi warto przygotować prostą kartę tożsamości encji. Powinna zawierać co najmniej:

  • obecną nazwę marki,

  • poprzednią nazwę marki,

  • nazwę podmiotu prawnego,

  • NIP, KRS lub inne trwałe identyfikatory, jeżeli dotyczą firmy,

  • główną domenę,

  • poprzednią domenę,

  • adres siedziby lub lokalizacji obsługującej klientów,

  • główny numer telefonu,

  • adres e-mail,

  • główne profile społecznościowe,

  • Profil Firmy w Google,

  • główny typ działalności i ofertę.

Jeżeli po rebrandingu podmiot prawny, identyfikatory, działalność i większość danych pozostają te same, mamy mocne podstawy, aby traktować proces jako kontynuację jednej encji pod nową nazwą. W takim wariancie stara nazwa może przez pewien czas pełnić funkcję aliasu, a stara domena powinna przekazywać sygnały do nowej.

Inaczej wygląda sytuacja, gdy marka została sprzedana innemu podmiotowi, część działalności wydzielono albo pod nową nazwą działa nowa spółka. Sam fakt przejęcia klientów, domeny czy logotypu nie wystarcza, aby automatycznie uznać dwie organizacje za ten sam byt.

To szczególnie istotne przy sameAs. Ta właściwość nie oznacza „strona powiązana z firmą”. Jej sens jest znacznie mocniejszy: wskazuje zasób reprezentujący tę samą tożsamość. Wpisanie tam profilu poprzedniej spółki tylko dlatego, że kiedyś prowadziła tę samą markę, może stworzyć dokładnie taki konflikt, jaki próbujemy usunąć.

Podobnie należy traktować alternateName. Pole dobrze nadaje się do zapisania poprzedniej, nadal rozpoznawalnej nazwy tej samej organizacji. Nie powinno jednak stawać się magazynem nazw wszystkich poprzedników, przejętych firm i marek z grupy kapitałowej.

Nie ma też uniwersalnego terminu typu „starą nazwę usuń po 90 dniach”. Jeżeli klienci nadal szukają firmy po starej nazwie, występuje ona w umowach, publikacjach i istotnych wzmiankach, pozostawienie jej jako rzeczywistego aliasu może pomagać w identyfikacji. Gdy staje się wyłącznie historyczną etykietą i nie jest już używana do identyfikacji bieżącej firmy, można ją stopniowo wycofać.

Szczególnej ostrożności wymaga Profil Firmy w Google. Nie każda zmiana nazwy może zostać potraktowana jak zwykły rebranding istniejącego profilu. Google dopuszcza zmianę istniejącego profilu m.in. przy kwalifikującej się, niewielkiej zmianie nazwy, gdy nazwy własne, opisane usługi i kategoria działalności pozostają zasadniczo niezmienione. Jeżeli zmiana nie spełnia warunków rebrandingu, firma może zostać potraktowana jako nowy biznes, co oznacza zamknięcie starego profilu i utworzenie nowego.

To ważne ograniczenie. Nie wolno zakładać, że zawsze należy zachować jeden profil za wszelką cenę. Najpierw trzeba sprawdzić, czy konkretny przypadek spełnia aktualne kryteria Google Business Profile.

Migracja domeny musi przekazać sygnały, a nie tworzyć drugi równoległy serwis

Jeżeli wraz z marką zmienia się domena, warstwa techniczna ma wyższy priorytet niż poprawianie opisów w katalogach. Stara witryna dostępna pod kodem 200, indeksowalna i zawierająca stare logo jest znacznie silniejszym źródłem konfliktu niż pojedyncza nieaktualna wzmianka na stronie partnera.

Podstawą jest mapowanie stary URL → nowy URL. Nie należy przekierowywać setek różnych podstron automatycznie na nową stronę główną. Dla każdej ważnej strony trzeba znaleźć najbliższy nowy odpowiednik.

Przykład:

  • staramarka.pl/oferta/a → nowamarka.pl/uslugi/a,

  • staramarka.pl/kontakt → nowamarka.pl/kontakt,

  • staramarka.pl/o-nas → nowamarka.pl/o-firmie.

Jeżeli stary materiał rzeczywiście został usunięty i nie ma nowego odpowiednika, lepsza jest prawidłowa odpowiedź 404 lub 410 niż sztuczne przekierowanie do przypadkowej treści.

Dla przenoszonych adresów należy stosować stałe przekierowania po stronie serwera, przede wszystkim 301 lub 308. Stary adres powinien prowadzić możliwie bezpośrednio do finalnego nowego adresu. Łańcuch typu:

stary URL → stara wersja HTTPS → domena przejściowa → nowy URL

jest niepotrzebny. Zwiększa opóźnienie, komplikuje diagnostykę i utrudnia migrację innym robotom niż Googlebot. Nawet jeśli crawler potrafi przejść przez kilka przekierowań, nie ma powodu budować takiego łańcucha świadomie.

Na nowej stronie trzeba równocześnie poprawić:

  • canonicale — powinny wskazywać nowe kanoniczne URL-e,

  • linkowanie wewnętrzne — bez linków prowadzących przez stare przekierowania,

  • sitemapę XML,

  • hreflang, jeżeli witryna jest wielojęzyczna,

  • adresy obrazów i dokumentów, jeśli również zmieniły lokalizację,

  • konfigurację Search Console,

  • kampanie reklamowe i feedy produktowe,

  • linki ze stron i profili należących do firmy.

Google wskazuje, że przeniesienie małej lub średniej witryny może być przetwarzane przez kilka tygodni lub dłużej. Nie ma jednej daty, po której stary brand powinien natychmiast zniknąć z wyników. Migracja jest rozpoznawana na poziomie poszczególnych URL-i.

Stałych przekierowań nie warto usuwać po miesiącu czy kwartale. Google zaleca utrzymywanie ich tak długo, jak to możliwe, zasadniczo co najmniej przez rok. W przypadku wartościowej domeny brandowej sensowne jest utrzymanie jej rejestracji jeszcze dłużej. Koszt przedłużenia domeny jest zwykle nieporównywalnie mniejszy niż problem po jej przejęciu przez osobę trzecią i wykorzystaniu ruchu, backlinków lub rozpoznawalności starej marki.

Przy zmianie domeny albo subdomeny należy również użyć Change of Address w Google Search Console, o ile konkretny typ migracji kwalifikuje się do użycia tego narzędzia. Nie służy ono do każdej zmiany URL. Nie jest potrzebne przy zwykłym przejściu z HTTP na HTTPS, zmianach ścieżek w obrębie jednej domeny czy przełączaniu www/bez www.

Zgłoszenie zmiany adresu działa przez 180 dni. Samo użycie narzędzia nie zastępuje jednak przekierowań. To dodatkowy sygnał, a nie zamiennik prawidłowej migracji.

Po wdrożeniu trzeba obserwować jednocześnie starą i nową domenę. Prawidłowy kierunek zmian jest prosty: liczba wartościowych starych URL-i w indeksie spada, nowe URL-e są odkrywane, a ruch organiczny przechodzi na nową domenę.

Najpierw naprawia się problemy, które mogą zatrzymać migrację:

  1. stare adresy zwracające 200 zamiast przekierowania,

  2. przekierowania do złych lub nieistniejących stron,

  3. noindex pozostawiony na nowej witrynie po etapie testowym,

  4. canonicale wskazujące starą domenę,

  5. linkowanie wewnętrzne kierujące na stare URL-e,

  6. błędne dane Organization.

Dopiero później warto poświęcać czas pojedynczym, mało widocznym wzmiankom zewnętrznym.

Organization, sameAs, autorzy i zewnętrzne wzmianki trzeba potraktować jak jeden system

Najczęstszy problem z danymi strukturalnymi po rebrandingu nie polega na błędzie składni. Kod może być technicznie poprawny, a jednocześnie opisywać starą firmę na nowej stronie.

W Organization trzeba sprawdzić przede wszystkim:

  • name,

  • alternateName,

  • url,

  • logo,

  • description,

  • telephone,

  • email,

  • address,

  • contactPoint,

  • sameAs,

  • identyfikatory organizacji, jeżeli są rzeczywiście używane.

Po zmianie marki nie powinno być tak, że name podaje nową nazwę, url starą domenę, logo ładuje się ze starego hosta, a sameAs prowadzi do dwóch profili należących do różnych organizacji.

Szkielet danych dla firmy, która pozostaje tą samą organizacją, ale zmieniła nazwę, może wyglądać przykładowo tak:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://nowamarka.example/#organization",
  "name": "Nowa Marka",
  "alternateName": "Stara Marka",
  "url": "https://nowamarka.example/",
  "logo": "https://nowamarka.example/media/logo.png",
  "description": "Aktualny opis działalności firmy po rebrandingu.",
  "telephone": "+48 12 345 67 89",
  "email": "kontakt@nowamarka.example",
  "sameAs": [
    "https://social.example/nowamarka",
    "https://directory.example/nowamarka"
  ]
}

To wyłącznie model edukacyjny. W produkcyjnym wdrożeniu sameAs powinno zawierać rzeczywiste profile jednoznacznie reprezentujące tę organizację, a nie przypadkowe katalogi, artykuły prasowe czy wszystkie miejsca, w których pojawia się nazwa firmy.

Przy rebrandingu sameAs łatwo popsuć na dwa sposoby. Pierwszy to pozostawienie starych profili, które nadal przedstawiają firmę pod dawną nazwą i ze starą domeną. Drugi to utworzenie zupełnie nowych profili i pozostawienie obu kompletów aktywnych bez jasnego związku między nimi.

Jeżeli platforma pozwala zmienić nazwę istniejącego profilu i zachowana jest ta sama tożsamość biznesu, zwykle lepiej zaktualizować istniejący profil, zamiast tworzyć jego drugi odpowiednik. Historia, obserwujący, linki i wzmianki pozostają wtedy przy jednym obiekcie. Wyjątkiem są sytuacje, w których regulamin konkretnej platformy wymaga założenia nowego profilu.

Kolejna warstwa to opisy marki. Po rebrandingu strona „O nas” potrafi mówić już o Nowej Marce, ale stopka, meta description strony kontaktowej, opis LinkedIn i Google Business Profile nadal przedstawiają Starą Markę jako aktualną nazwę. To nie jest problem kosmetyczny. Jeśli każdy serwis opisuje organizację trochę inaczej, trudniej ustalić jeden dominujący zestaw danych.

Dobrą praktyką jest przygotowanie krótkiego, kontrolowanego zestawu danych referencyjnych:

  • oficjalna nazwa marki,

  • jedna wersja krótkiego opisu, np. 150–250 znaków,

  • jedna wersja dłuższego opisu,

  • główna kategoria działalności,

  • podstawowy telefon,

  • adres,

  • domena,

  • nazwa używana historycznie,

  • data wejścia nowej marki w użycie.

Nie chodzi o publikowanie identycznego tekstu wszędzie. Chodzi o to, aby fakty identyfikujące firmę były zgodne.

Osobnej kontroli wymagają autorzy treści. Na portalach eksperckich i firmowych artykuły często wskazują autora za pomocą Person, author.url albo sameAs. Po przeniesieniu serwisu zdarza się, że nazwisko prowadzi do profilu na starej domenie albo profil autora nadal podaje zatrudnienie w Starej Marce.

Nie należy usuwać historii autora ani tworzyć nowej osoby tylko dlatego, że firma zmieniła nazwę. Trzeba zachować tożsamość Person, ale zaktualizować aktualne URL-e i — jeśli dotyczy — bieżącą afiliację. W przypadku treści podpisanych organizacją trzeba również sprawdzić, czy author lub publisher nie wskazują dawnej nazwy organizacji.

Najwięcej pracy pojawia się zwykle poza własną stroną. Dlatego potrzebna jest checklista konfliktów encji.

Priorytet 1 — zasoby kontrolowane bezpośrednio przez firmę:

  • nowa i stara domena,

  • wszystkie subdomeny,

  • Search Console,

  • Profil Firmy w Google,

  • Facebook,

  • LinkedIn,

  • YouTube,

  • inne oficjalne profile społecznościowe,

  • profile sklepów i marketplace'ów,

  • stopki e-mail,

  • landing pages kampanii,

  • dokumenty PDF dostępne z wyszukiwarki.

Priorytet 2 — źródła zewnętrzne o dużej sile lub ruchu:

  • profile partnerów,

  • strony producentów i dystrybutorów,

  • katalogi branżowe,

  • portale z opiniami,

  • katalogi izb gospodarczych i organizacji branżowych,

  • serwisy prasowe,

  • strony konferencji,

  • katalogi wystawców,

  • serwisy zatrudnieniowe.

Google wprost zaleca po migracji aktualizację ważnych linków zewnętrznych i rozpoczęcie od tych, które generują najwięcej ruchu. Nie ma sensu wysyłać 300 próśb o zmianę nazwy do przypadkowych katalogów, jeżeli pięć najmocniejszych domen wciąż kieruje użytkowników do starego serwisu.

Priorytet 3 — wzmianki historyczne.

Nie każdą starą publikację trzeba przerabiać. Artykuł prasowy z 2021 roku opisujący firmę pod ówczesną nazwą może być historycznie poprawny. Problem zaczyna się wtedy, gdy publikacja zachowuje funkcję aktualnego profilu: podaje nieczynny telefon, stary adres, dawną domenę jako bieżącą lub jest wysoko widoczna na zapytania brandowe.

Do wykrycia konfliktów nie potrzeba specjalnego „narzędzia do entity collision”. Wystarczy systematyczny audyt:

  1. Wyszukaj dokładną starą nazwę marki.

  2. Wyszukaj starą nazwę razem z nową.

  3. Sprawdź zapytania z dawnym i obecnym numerem telefonu.

  4. Sprawdź indeksację starej domeny.

  5. Przeskanuj nowy serwis pod kątem starej domeny i nazwy.

  6. Wyeksportuj linki prowadzące do starej domeny z Search Console.

  7. Porównaj nazwę, URL, telefon i adres na najważniejszych profilach.

  8. Sprawdź kod Organization, LocalBusiness, Article, Person i profile autorów.

  9. Zweryfikuj, czy stare profile są zaktualizowane, zamknięte czy nadal aktywnie konkurują z nowymi.

  10. Powtórz kontrolę po kilku tygodniach, bo indeks nie aktualizuje wszystkich zasobów jednocześnie.

W arkuszu wystarczą kolumny: źródło, typ danych, stara wartość, nowa wartość, status, priorytet, właściciel zadania, data ostatniej kontroli. Dzięki temu migracja przestaje być chaotycznym polowaniem na stare logo, a staje się zamykanym punkt po punkcie procesem.

Plan rebrandingu: zadania przed zmianą i po uruchomieniu

To plan do wykorzystania w projekcie, a nie opis zakończonej migracji klienta. Terminy są orientacyjne. W modelowym scenariuszu firma Alfa zmienia nazwę na Beta i domenę, zachowując ten sam podmiot prawny. Przejęcie marki przez inną firmę wymaga odrębnej decyzji o tożsamości.

EtapCo przygotować lub wykonaćWarunek zakończenia
Przed zmianą: 2–4 tygodnieWłaściciel projektu potwierdza ciągłość podmiotu. Zespół SEO zapisuje stare nazwy, identyfikatory, domeny, profile, autorów i najważniejsze URL-e; zbiera punkt odniesienia ruchu i indeksacji.Jedna zatwierdzona karta tożsamości oraz lista stary URL → nowy URL.
Przed zmianą: około tygodniaRedakcja przygotowuje informację „Beta, wcześniej Alfa”, stronę o firmie i aktualne podpisy. Programista wdraża mapę przekierowań, canonical, linki wewnętrzne i spójny graf Organization.Test każdej grupy adresów bez łańcuchów, pętli i kierowania wszystkiego na stronę główną.
Dzień uruchomieniaUruchom nowe URL-e i przekierowania stałe 1:1 tam, gdzie istnieją odpowiedniki. Sprawdź robots/noindex, mapę strony, analitykę i formularze. W Search Console wykonaj zmianę adresu, jeśli dany typ migracji ją obsługuje.Kluczowe strony działają; stare adresy prowadzą do właściwych nowych stron; pomiar i kontakt działają.
Pierwsze 48 godzinSprawdź próbkę stron głównych, kategorii, artykułów i plików oraz logi błędów. Porównaj nazwę w treści, stopce, JSON-LD i profilach.Lista wykrytych rozbieżności z właścicielem i terminem naprawy.
Tydzień 1–4Obserwuj błędy 404, canonicale wybierane przez Google, indeksację, zapytania o starą i nową markę oraz ruch. Aktualizuj profile i ważne linki zewnętrzne.Każde odchylenie ma ustaloną przyczynę albo dalszy krok diagnostyczny; sam spadek ruchu nie przesądza o błędzie migracji.
Dalsze utrzymanieUtrzymuj starą domenę i przekierowania co najmniej rok, najlepiej dłużej, gdy prowadzą do nich aktywne linki. Nie usuwaj komunikatu o zmianie nazwy, dopóki pomaga odbiorcom.Okresowe kontrole przekierowań i profili; dokumentacja osoby odpowiedzialnej za utrzymanie.

Przykład decyzji w scenariuszu Alfa → Beta: profil osoby zatrudnionej w firmie aktualizuje worksFor, ale zachowuje tożsamość tej osoby. Zmiana nazwy organizacji nie uzasadnia tworzenia nowej osoby. Jeżeli identyfikator organizacji zawiera starą domenę, zaplanuj konsekwentną migrację odwołań i utrzymaj dostępność starej domeny; nie zmieniaj identyfikatorów przypadkowo w różnych szablonach. Zakończ etap audytem spójności encji.

FAQ: najczęstsze pytania po rebrandingu

Czy po zmianie nazwy trzeba całkowicie usunąć starą nazwę z Organization?
Nie. Jeśli to ta sama organizacja, a poprzednia nazwa nadal funkcjonuje jako realny publiczny identyfikator, może mieć sens jako alternateName. Nie ma jednak powodu utrzymywać jej bezterminowo tylko dlatego, że kiedyś była używana.

Czy starą domenę można wyłączyć po kilku miesiącach?
To zbyt wcześnie w typowej migracji. Google zaleca utrzymywanie stałych przekierowań zasadniczo co najmniej przez rok. Dla wartościowej domeny firmowej rozsądne może być dalsze jej opłacanie również z powodów ochrony marki.

Czy sameAs powinno wskazywać starą domenę?
Nie jako automatyczna reguła. sameAs służy do wskazywania zasobów jednoznacznie reprezentujących tę samą tożsamość. Stara domena, która prawidłowo przekierowuje do nowej, nie musi być utrzymywana jako osobny element sameAs.

Czy po przejęciu firmy zawsze trzeba scalić stare i nowe profile?
Nie. Zmiana właściciela, zmiana marki i zmiana podmiotu prawnego to trzy różne zdarzenia. Najpierw trzeba ustalić, czy profile nadal opisują ten sam biznes zgodnie z zasadami konkretnej platformy. W Google Business Profile istotny jest także zakres rebrandingu i to, czy firma spełnia warunki aktualizacji istniejącego profilu.

Jak długo może być widoczna stara marka w Google?
Nie ma stałego terminu. Przy migracji witryny średniej wielkości przetwarzanie zmian może trwać kilka tygodni lub dłużej, a poszczególne URL-e są aktualizowane w różnym czasie. Dodatkowo stare informacje mogą pochodzić ze źródeł zewnętrznych, nad którymi firma nie ma bezpośredniej kontroli.

Jeżeli trzeba zacząć od jednego działania, najpierw sporządź tabelę wszystkich źródeł, w których występuje stara nazwa, domena, telefon i profil firmy, a następnie usuń konflikt na poziomie własnej domeny. W pierwszej kolejności napraw stare URL-e zwracające 200, błędne przekierowania, canonicale i Organization. Dopóki własny serwis wysyła sprzeczne sygnały, poprawianie dziesiątek zewnętrznych katalogów jest pracą wykonywaną w złej kolejności.

Przejdź do części artykułu

Opublikowane w kategorii: SEO techniczne

Jak powstał ten materiał

Materiał przygotowano przy wsparciu AI na podstawie dokumentacji Google Search Central, Search Console, Google Business Profile i Schema.org. Opisuje migrację domen, identyfikację Organization, sameAs i dane autorów. Plan dodany 28.09.2026 jest scenariuszem modelowym; nie przedstawia wyników rzeczywistej migracji klienta. AI wykorzystano do analizy źródeł i opracowania tekstu. Za publikację odpowiada autor.

O autorze

Sebastian Miler

Autor treści CMPRESS o content marketingu, SEO oraz widoczności w wyszukiwarkach i systemach AI. Związany z wydawcą serwisu PageSEO – Miler Sebastian. Więcej o autorze →

Źródła i weryfikacja

Data weryfikacji źródeł:

Zapisane artykuły

Lista jest zapisana tylko w tej przeglądarce.

Ostatnio czytane

Szukaj artykułu