Dobry audyt entity reconciliation zaczyna się od prostej tabeli. Nie od narzędzia za kilka tysięcy złotych. Nie od mapowania grafu wiedzy. Od arkusza, w którym każda informacja o marce ma źródło, status i decyzję.
Minimum, które warto zebrać:
Najwyższy priorytet mają dane, które identyfikują firmę wprost: nazwa, adres, telefon, domena, identyfikatory rejestrowe i profile oficjalne. Jeżeli tu jest bałagan, poprawianie opisów produktów albo biogramów autorów można odłożyć. Nie dlatego, że są nieważne, tylko dlatego, że wyszukiwarka najpierw musi rozpoznać główną encję.
W praktyce warto stosować cztery poziomy ważności:
Nie każda różnica jest błędem. „Jan Kowalski” i „Jan A. Kowalski” mogą oznaczać tę samą osobę, ale nie należy tego automatycznie scalać, jeśli w branży działają dwie osoby o podobnym nazwisku. „Brand24” i „Brand 24” mogą być wariantami zapisu, ale dopiero oficjalna strona, regulamin, stopka prawna i profile zewnętrzne pokażą, który zapis jest podstawowy.
Najbardziej zdradliwe są stare źródła o wysokim autorytecie. Dawny artykuł w dużym serwisie, archiwalny profil w katalogu inwestorskim albo stary marketplace potrafią utrzymywać błędny adres przez lata. Google nie musi uznać ich za ważniejsze od strony firmowej, ale jeśli takich śladów jest dużo, robi się szum. I ten szum później widać w panelach wiedzy, sugestiach, wynikach lokalnych albo odpowiedziach generowanych przez systemy AI.
W audycie warto stosować zasadę: nie poprawiamy wszystkiego naraz. Najpierw źródła, które są widoczne w Google po zapytaniach brandowych. Potem profile oficjalne. Następnie katalogi, porównywarki i marketplace’y, które realnie indeksują się w wynikach. Na końcu źródła mało widoczne, chyba że zawierają poważny błąd prawny lub reputacyjny.
Uzgadnianie encji nie polega na tym, że wybieramy najładniejszy wariant nazwy. Potrzebna jest kanoniczna wersja danych — jedna tabela lub dokument, do którego można wrócić przy każdej aktualizacji strony, profilu, kampanii PR, marketplace’u czy danych strukturalnych.
Taki dokument powinien zawierać nie tylko poprawną wartość, ale też decyzję: gdzie wolno stosować skrót, kiedy wymagany jest pełny zapis prawny, które profile są oficjalne i które stare warianty należy traktować jako aliasy.
Przykład dla firmy:
Dla autorów zasada jest podobna. Trzeba ustalić, czy autor występuje jako osoba prywatna, ekspert firmowy, lekarz, prawnik, doradca, redaktor czy przedstawiciel marki. To ważne, bo inny poziom weryfikacji będzie potrzebny przy blogu e-commerce, a inny przy tematach medycznych, finansowych lub prawnych.
Przy autorach warto sprawdzić:
Nie należy automatycznie podpinać każdego tekstu pod „najmocniejszego” eksperta, jeśli faktycznie go nie napisał ani nie zweryfikował. To krótkoterminowo wygląda wygodnie, ale długoterminowo tworzy problem wiarygodności. Jeżeli autor tylko zatwierdził tekst merytorycznie, lepiej napisać „konsultacja merytoryczna” niż udawać autorstwo.
Produkty wymagają osobnego podejścia. Tu najczęściej pojawia się konflikt między SEO, sprzedażą i danymi magazynowymi. System PIM ma jedną nazwę, marketplace drugą, porównywarka trzecią, a Google Merchant Center dostaje jeszcze inny wariant. Efekt: produkt zaczyna wyglądać jak kilka różnych produktów.
Dla produktów trzeba ustalić:
Granica jest prosta: nie wolno scalać produktów tylko dlatego, że są podobne. Jeżeli różnią się składem, pojemnością, generacją, rokiem produkcji albo kompatybilnością, powinny pozostać osobnymi encjami. W przeciwnym razie można poprawić „porządek” w arkuszu, a jednocześnie zepsuć feed, dane produktowe i dopasowanie do zapytań użytkowników.
W przypadku lokalizacji trzeba uważać na firmy wielooddziałowe. Każdy oddział powinien mieć własny zestaw danych: adres, telefon, godziny otwarcia, stronę lokalizacji, profil lokalny i odpowiedni typ LocalBusiness. Jedna centrala nie rozwiązuje problemu, jeśli użytkownik szuka konkretnego punktu w konkretnym mieście.
Tu często pojawia się błąd: firma ma jedną stronę kontaktową, na niej pięć lokalizacji, a dane strukturalne opisują tylko centralę. Albo odwrotnie — każda lokalizacja publikuje te same dane telefonu i adresu, bo ktoś skopiował JSON-LD z jednej podstrony. To nie jest drobna literówka. To sygnał, że system nie rozróżnia oddziałów.
Dobra wersja prawdy powinna być nudna, precyzyjna i łatwa do skopiowania. Jeśli wymaga interpretacji, będzie psuta przy każdej kolejnej aktualizacji.
Po audycie przychodzi etap, na którym najłatwiej stracić czas. Lista błędów rośnie, zespół chce poprawić wszystko, a po dwóch tygodniach nikt nie wie, które zmiany faktycznie weszły. Dlatego wdrożenie trzeba prowadzić partiami.
Najpierw poprawia się źródła kontrolowane:
Dopiero potem źródła półkontrolowane: katalogi, marketplace’y, porównywarki, Crunchbase, Wikidata, profile partnerskie, stare wpisy sponsorowane, wizytówki branżowe. Tu trzeba liczyć się z ograniczeniami. Nie każde pole da się edytować. Nie każda zmiana przechodzi od razu. Niektóre serwisy mają moderację, inne wymagają dowodu, a część po prostu ignoruje zgłoszenia.
W danych strukturalnych nie chodzi o to, żeby wrzucić jak najwięcej właściwości. Chodzi o zgodność z widoczną treścią i stanem faktycznym. Jeżeli strona pokazuje jeden adres, a JSON-LD drugi, problemem nie jest brak schema, tylko brak spójności. Jeżeli organizacja ma kilka lokalizacji, trzeba zdecydować, czy opisujemy organizację nadrzędną, oddział, czy konkretny punkt usługowy. Mieszanie tych poziomów kończy się nieczytelnym sygnałem.
W praktyce dobrze działa taki porządek:
Automatyzować można wykrywanie różnic. Nie decyzje. Narzędzia typu crawler, eksport z GSC, Screaming Frog, Sitebulb, OpenRefine, arkusze z formułami, własne skrypty czy API marketplace’ów pomagają znaleźć powtarzalne rozjazdy. Ale decyzję, czy „ABC Medical” i „ABC Med” to ta sama encja, powinien podjąć człowiek z dostępem do dokumentów, historii marki i kontekstu biznesowego.
OpenRefine dobrze nadaje się do pracy na większych zbiorach: można normalizować nazwy, grupować podobne wartości, porównywać kolumny, wykrywać warianty zapisu i uzgadniać dane z zewnętrznymi bazami. Przy Wikidata trzeba być ostrożnym. To nie jest miejsce na spam SEO ani katalog firm. Jeżeli firma, osoba lub produkt nie spełnia zasad istotności danego projektu, próba dodania wpisu może skończyć się usunięciem. Lepsza decyzja: najpierw sprawdzić kryteria i istniejące źródła, dopiero potem edytować.
Crunchbase ma podobny praktyczny problem: część danych można poprawić, część może wymagać przeglądu lub nie być dostępna do edycji wprost. Dlatego przy profilach zewnętrznych zawsze trzeba zapisywać:
Bez tego po miesiącu zostaje tylko wrażenie, że „coś było poprawiane”. To za mało.
Kontrola po wdrożeniu powinna trwać co najmniej kilka tygodni, bo część źródeł aktualizuje się wolno, a Google może utrzymywać stare dane w wynikach dłużej niż oczekuje klient. Nie ma gwarancji, że poprawienie katalogu natychmiast zmieni panel wiedzy, wynik lokalny albo odpowiedź AI. Można natomiast zwiększyć prawdopodobieństwo, że systemy zaczną widzieć jedną, spójną wersję marki.
Najbardziej praktyczny wskaźnik sukcesu nie brzmi: „czy wdrożyliśmy schema?”. Brzmi: czy po wpisaniu nazwy marki, autora, produktu i adresu widać mniej sprzecznych informacji niż przed audytem. Jeżeli tak, proces działa.
Autor artykułu: https://cmspace.pl.
Czy entity reconciliation to to samo co entity SEO?
Nie. Entity SEO to szersze podejście do wzmacniania rozpoznawalności encji w wyszukiwarkach. Entity reconciliation jest bardziej techniczne i operacyjne: polega na wykrywaniu, porównywaniu i uzgadnianiu danych o tej samej firmie, osobie, produkcie lub lokalizacji w różnych źródłach.
Od czego zacząć, jeśli marka ma dużo starych danych w sieci?
Od zapytań brandowych w Google i od źródeł kontrolowanych przez firmę. Najpierw popraw strona, stopka, kontakt, profile social, Google Business Profile, dane strukturalne i feedy. Dopiero później katalogi, marketplace’y i porównywarki.
Czy schema.org rozwiązuje problem niespójnych danych?
Nie. Schema pomaga opisać dane, ale nie naprawia sprzeczności. Jeśli na stronie jest inny adres niż w katalogach i profilach lokalnych, samo dodanie LocalBusiness nie wystarczy. Najpierw trzeba ustalić poprawną wersję danych.
Czy warto dodawać firmę do Wikidata?
Tylko wtedy, gdy istnieją solidne, niezależne źródła i encja spełnia zasady projektu. Wikidata nie jest katalogiem SEO. Dodawanie wpisu bez podstaw może skończyć się usunięciem i stratą czasu.
Jak często robić audyt reconciliation?
Po każdej zmianie nazwy, adresu, domeny, właściciela, struktury marki, portfolio produktów lub sieci lokalizacji. Dla stabilnych firm wystarczy kontrola raz na 6–12 miesięcy. Dla e-commerce, marketplace’ów i firm wielooddziałowych lepiej robić krótsze kontrole kwartalne.
Czy trzeba poprawiać każdą starą wzmiankę o firmie?
Nie. Priorytet mają źródła widoczne w Google, profile oficjalne, dane lokalne, marketplace’y, porównywarki i katalogi, które realnie wpływają na użytkownika. Stare, niewidoczne wzmianki można zostawić, jeśli nie zawierają poważnego błędu.
Jaki błąd usuwać jako pierwszy?
Ten, który myli tożsamość firmy: zły adres, zła domena, błędny telefon, nieaktualna nazwa albo profil prowadzący do innej organizacji. Dopiero po tym warto poprawiać opisy, aliasy, biogramy i mniej widoczne katalogi.
Nie tylko Google. Jak pozycjonować sklep internetowy za granicą, wykorzystując pozycjonowanie w Seznam?
Producent lamp - na co zwrócić uwagę przy wyborze?
Rynek opakowań premium w Polsce i Europie - trendy 2026
Na tej stronie internetowej znajdują sie notki prasowe od firm korzystających z wirtualnych biur prasowych oraz przesłane przez rzeczników prasowych, pobrane z biur prasowych firm zewnętrznych lub ze źródeł ogólnodostępnych (za zgodą odpowiednich osób).
Zapraszamy dziennikarzy do rejestracji w naszym newsletterze, a firmy i agencje public relations do zakładania darmowych wirtualnych biur prasowych.
Wirtualne biuro prasowe to specjalna strona internetowa, w której firma lub instytucja publikuje informacje przeznaczone dla mediów. Takimi informacjami mogą to być notatki prasowe, wyniki finansowe, ciekawostki oraz artykuły merytoryczne.
Najważniejsza funkcja wirtualnego biura prasowego to automatyzacja wysyłki informacji do dziennikarzy oraz promocja notek prasowych.
Baza wiedzy
