Gdy tekst mówi jedno, a grafika drugie: multimodalny audyt treści pod AI Search

Multimodalna spójność tekst-obraz to problem, o którym mało kto mówi, a który dotyczy 43% stron z elementami wizualnymi. Infografika pokazuje wzrost o 45%. Tekst pod nią mówi o wzroście o 38%. Schema podaje trzecią wartość. Który z tych trzech „faktów” zacytuje AI? Zbadaliśmy 30 stron zawierających wykresy, infografiki i tabele w formie obrazu – i w 43% przypadków znaleźliśmy rozbieżność między danymi w obrazie a danymi w HTML. W 27% alt text opisywał coś innego niż obraz faktycznie pokazywał. Poniżej: pełna metodologia audytu, wyniki, diagnoza 5 typów problemów z before/after, workflow naprawczy i obserwacje po wdrożeniu.

Artykuł jest częścią serii łączącej patenty Google z własnymi danymi audytowymi Semgence. Pokazujemy nie tylko co jest nie tak, ale jak to naprawić – z konkretnymi przykładami, czasem naprawy i wynikami po 30 dniach. Pozostałe materiały z serii znajdziesz w artykule Jak AI wybiera źródła do cytowania.

Parametry badania

Parametr	Wartość
Strony przebadane	30 (10 ecommerce, 10 eksperci/blogi, 10 korporacje)
Elementy wizualne łącznie	127 (wykresy, infografiki, tabele-obraz, etykiety)
Narzędzia	content_answer_evidence_structure_pack, te_render_visibility_check, visual_product_discovery_audit, content_discovery_indexability_pack (GSCGA MCP)
Weryfikacja	Ręczne porównanie obraz vs HTML vs schema per element
Okres	lipiec 2026

Dlaczego te 30 stron i 127 elementów?

Próba została dobrana celowo, nie losowo. Szukaliśmy stron, które aktywnie używają elementów wizualnych do komunikowania danych liczbowych – wykresów, infografik z procentami, tabel zapisanych jako obraz. Kryteria włączenia: strona musi zawierać co najmniej 2 elementy wizualne z danymi liczbowymi, być zaindeksowana w Google i mieć co najmniej 1000 słów treści HTML. Wykluczyliśmy strony z samymi zdjęciami dekoracyjnymi i stockowymi, bo tam problem rozbieżności nie występuje.

Podział 10/10/10 (ecommerce, eksperci, korporacje) nie odzwierciedla proporcji w internecie – jest celowy, żeby umożliwić porównanie typów stron przy zbliżonej liczebności. Jednostką obserwacji jest element wizualny (n=127), nie strona (n=30). Jedna strona mogła mieć od 2 do 8 elementów wizualnych. Mediana: 4 elementy na stronę.

Audyt każdego elementu polegał na trzech krokach: (1) ekstrakcja danych widocznych na obrazie (ręcznie lub OCR), (2) porównanie z odpowiadającymi danymi w HTML i schema, (3) klasyfikacja: spójny, rozbieżny liczbowo, rozbieżny kontekstowo, brak odpowiednika w HTML. Dwa elementy były zawsze weryfikowane przez drugą osobę (kontrola jakości etykietowania).

Dlaczego alt text nie rozwiązuje całego problemu?

Alt text to opis dla użytkowników niewidomych i wyszukiwarek. Ale alt text nie jest transkrypcją treści obrazu – to opis przeznaczenia obrazu. Alt „Wykres wzrostu sprzedaży” mówi, co obraz przedstawia, ale nie podaje wartości z wykresu. Jeśli wykres pokazuje wzrost z 12 mln do 17,4 mln w Q3 2026, te liczby są uwięzione w obrazie i niedostępne ani dla czytnika ekranu, ani dla systemu odpowiadającego na pytania.

Trzy role alt textu – i żadna nie zastępuje HTML

Alt text pełni trzy różne funkcje, z których każda ma inne wymagania. Po pierwsze, jest opisem dostępności (accessibility) – mówi osobie niewidzącej, co obraz przedstawia. Po drugie, jest sygnałem kontekstowym dla wyszukiwarki – pomaga zrozumieć, czego dotyczy sekcja strony. Po trzecie, jest fallbackiem wyświetlanym, gdy obraz się nie załaduje.

Żadna z tych ról nie wymaga, żeby alt text zawierał kompletne dane z obrazu. Wytyczne WCAG 2.1 mówią, że alt text ma być „zwięzły” i opisywać „cel” obrazu. Dla wykresu słupkowego poprawny alt to: „Porównanie sprzedaży Q1-Q4 2025 w podziale na regiony” – nie transkrypcja wszystkich wartości z osi Y. Problem polega na tym, że system odpowiadający na pytania potrzebuje właśnie tych wartości, a jedyne miejsce, w którym może je znaleźć maszynowo, to HTML – tabela, lista lub tekst.

W naszym teście 27% elementów miało alt text opisujący coś innego niż obraz faktycznie pokazywał. Najczęstszy wzorzec: alt generyczny („wykres”, „tabela”, „infografika”) bez jakiejkolwiek informacji o treści. Ale nawet poprawny alt text nie rozwiązuje problemu niedostępności danych – rozwiązuje go wyłącznie duplikacja danych w HTML.

Co mówi patent US20240386247A1 o weryfikacji mediów?

Patent US20240386247A1 (Google LLC, aplikacja) opisuje system oceny zgodności wygenerowanej treści z dokumentem źródłowym. Kluczowe dla naszego tematu: system weryfikujący nie ogranicza się do tekstu. Patent explicite wymienia media – obrazy, wykresy, tabele graficzne – jako elementy wymagające sprawdzenia spójności z treścią tekstową dokumentu.

Mechanizm działa w dwóch kierunkach. Pierwszy: czy informacja z tekstu jest potwierdzona przez media (np. wykres ilustrujący trend opisany w paragrafie). Drugi: czy media nie zawierają informacji sprzecznej z tekstem (np. wykres pokazujący spadek, gdy tekst opisuje wzrost). Dla twórcy treści implikacja jest jasna: jeśli system retrieval zacznie stosować ten mechanizm, rozbieżność tekst-obraz może obniżyć wiarygodność całego dokumentu, nie tylko sekcji z obrazem.

Patent US12045278B2 (Google LLC, granted) opisuje wykorzystanie OCR, embeddingów obrazu i bounding boxes do odpowiadania na zapytania wizualne. To mechanizm, który może wydobywać dane z obrazów – ale jego skuteczność zależy od jakości OCR. W naszym teście ręczne porównanie danych z obrazu z danymi rozpoznanymi przez OCR wykazało rozbieżności w 12% przypadków (szczególnie przy małych czcionkach i niskokontrastowych wykresach).

Patent US12536225B2 (Google LLC, granted) opisuje doprecyzowanie zapytań z tekstu rozpoznanego przez OCR. Praktyczny wniosek: nawet jeśli system potrafi „czytać” tekst z obrazu, rozpoznany tekst może być niedokładny, szczególnie przy liczbach z przecinkami, jednostkach i specjalistycznej notacji.

Numer	Tytuł	Właściciel	Status	Związek
US20240386247A1	Content-document source consistency	Google LLC	Aplikacja	direct
US12045278B2	Visual queries with OCR and embeddings	Google LLC	Granted	supporting
US12536225B2	Query refinement from OCR	Google LLC	Granted	supporting
US12332074B2	Local image feature tensors	Google LLC	Granted	context only

Jakie fakty mogą być uwięzione w obrazie?

Typ elementu	Liczba w próbie	Procent z danymi niedostępnymi w HTML
Wykres słupkowy/liniowy	34	56%
Infografika z liczbami	28	46%
Tabela zapisana jako obraz	21	71%
Zdjęcie produktu z etykietą	24	33%
Diagram procesu	20	35%

Analiza: co oznaczają te liczby dla retrieval?

Tabele zapisane jako obraz miały najwyższy wskaźnik niedostępności danych (71%). To zrozumiałe – tabela w formie graficznej wygląda profesjonalnie, ale jej zawartość nie istnieje w DOM i nie może być cytowana, przeszukiwana ani weryfikowana. Problem jest szczególnie dotkliwy, gdy tabela zawiera dane porównawcze – ceny, parametry techniczne, wyniki testów. System odpowiadający na pytanie „który model ma najlepszą baterię” nie ma dostępu do danych porównawczych, jeśli istnieją wyłącznie jako screenshot tabeli.

Wykresy słupkowe i liniowe miały 56% niedostępności. Częsty wzorzec: wykres z wartościami widocznymi tylko na osiach, bez tabeli HTML z danymi źródłowymi. Typowy scenariusz w raportach branżowych: autor wkleja wykres z PowerPointa, ale nie dodaje tabeli z danymi, z których wykres powstał. Efekt: pytanie „o ile procent wzrosła sprzedaż w Q2?” nie może być odpowiedziane na podstawie strony, mimo że odpowiedź jest widoczna na wykresie.

Infografiki z liczbami (46%) to kategoria z najszerszym spektrum problemów. Infografika może zawierać kilkanaście punktów danych (procenty, liczby, daty), z których żaden nie pojawia się w HTML. Zdjęcia produktów z etykietą (33%) i diagramy procesu (35%) miały niższe wskaźniki, bo częściej towarzyszył im tekst opisowy powtarzający kluczowe informacje.

Warto podkreślić: „niedostępny w HTML” nie oznacza „niewidoczny dla użytkownika”. Użytkownik widzi dane na wykresie. Problem dotyczy wyłącznie maszyn – crawlerów, systemów RAG, czytników ekranu. To fundamentalne rozróżnienie: strona może wyglądać kompletnie i profesjonalnie, a jednocześnie być nieprzeszukiwalna pod kątem kluczowych danych. Zagadnienie ekstrahowalności treści szczegółowo opisujemy w artykule o extractability score kart produktowych.

Najczęstsze rozjazdy tekst-obraz-schema

Typ rozjazdu	Liczba	Przykład
Różne wartości liczbowe	18	Obraz: +45%, tekst: +38%, schema: brak
Obraz aktualny, tekst nieaktualny	12	Obraz z danymi Q2 2026, tekst cytuje Q4 2025
Alt text nie opisuje treści obrazu	15	Alt: „wykres”, obraz: tabela porównawcza 5 produktów
Schema opisuje inny produkt niż obraz	8	Schema: model X, zdjęcie: model Y
Obraz niewidoczny po renderze (lazy load)	6	Obraz ładowany po scrollu, crawler widzi placeholder

Anatomia rozjazdu: dlaczego tekst i obraz się rozjeżdżają?

Najczęstszy problem (18 przypadków): różne wartości liczbowe między obrazem a tekstem. Przyczyna w 14 z 18 przypadków: obraz został zaktualizowany, ale tekst nie, lub odwrotnie. Typowy scenariusz: dział analityczny przygotowuje nowy wykres co kwartał i podmienia plik graficzny, ale copywriter nie aktualizuje tekstu pod wykresem. Albo odwrotnie – tekst jest aktualizowany, bo łatwiej zmienić cyfrę w CMS, ale nikt nie generuje nowego wykresu.

W 4 z 18 przypadków rozbieżność wynikała z zaokrągleń lub innej metodologii. Obraz pokazywał wzrost rok-do-roku, a tekst opisywał wzrost kwartał-do-kwartału. Obie wartości były technicznie poprawne, ale bez kontekstu system nie wie, którą wybrać. To nie jest błąd redakcyjny – to problem braku jednoznaczności, który ma konsekwencje dla consensus score i weryfikowalności faktów.

Drugi wzorzec (12 przypadków): obraz aktualny, tekst nieaktualny. To efekt uboczny CMS-ów, w których podmiana grafiki jest osobną operacją niż edycja treści. W WordPressie można podmienić plik w bibliotece mediów bez otwierania edytora wpisu. W Shopifym zmiana zdjęcia produktu nie wymusza aktualizacji opisu. W efekcie dwa źródła danych na tej samej stronie żyją niezależnymi cyklami aktualizacji.

Problem schema-image mismatch (8 przypadków) dotyczył wyłącznie stron ecommerce. Schema Product wskazywała na jeden model produktu (np. przez SKU w schema), a zdjęcie pokazywało inny wariant kolorystyczny lub nowszą wersję. W kontekście Google Merchant Center i Shopping takie rozbieżności mogą prowadzić do odrzucenia produktu. Więcej o jakości danych produktowych w artykule o jakości treści w ecommerce.

Wyniki audytu per typ strony

Typ strony	Elementy	Spójne	Rozbieżne	% rozbieżności
Ecommerce (n=10)	47	31	16	34%
Eksperci/blogi (n=10)	42	21	21	50%
Korporacje (n=10)	38	21	17	45%
Łącznie (n=30)	127	73	54	43%

Dlaczego eksperci mają najgorsze wyniki?

Strony eksperckie i blogowe miały najwyższy wskaźnik rozbieżności (50%). Hipoteza potwierdzona w danych: treści eksperckie częściej używają własnych wykresów i infografik, tworzonych w Canvie, Figmie lub PowerPoincie. Te grafiki są aktualizowane niezależnie od tekstu, bo autor traktuje je jako osobny deliverable.

Dodatkowo blogi eksperckie rzadziej mają procesy redakcyjne wymuszające spójność. Autor pisze tekst, dodaje wykresy i publikuje. Nikt nie sprawdza, czy liczba w trzecim akapicie zgadza się z wartością na osi Y wykresu w piątym akapicie. W redakcjach korporacyjnych (45%) istnieje zwykle review, ale skupia się on na brandingu i compliance, nie na spójności danych tekst-obraz.

Strony ecommerce miały najniższy wskaźnik (34%), bo ich elementy wizualne to głównie zdjęcia produktów z automatycznym feedem. Gdy system PIM generuje zarówno zdjęcie jak i opis, dane są spójne z definicji. Problem pojawia się przy ręcznych wstawkach – bannerach promocyjnych, infografikach porównawczych, wykresach w content marketingu sklepu. Zagadnienie spójności danych w ecommerce szerzej opisujemy w kontekście architektury kategorii.

Co wybierze AI, gdy tekst i obraz się nie zgadzają?

System retrieval musi podjąć decyzję: zacytować dane z tekstu HTML czy dane rozpoznane z obrazu (jeśli w ogóle przetwarza obraz przez OCR). W praktyce większość obecnych systemów RAG (Retrieval-Augmented Generation) bazuje na tekście HTML, ignorując zawartość obrazów. To oznacza, że dane „uwięzione” w obrazie po prostu nie istnieją dla AI.

Ale sytuacja się komplikuje, gdy tekst i obraz się nie zgadzają i oba są dostępne. Patent US20240386247A1 sugeruje mechanizm weryfikacji krzyżowej – jeśli tekst mówi „+38%”, a OCR z wykresu odczytuje „+45%”, system powinien oznaczyć tę informację jako niespójną i obniżyć jej wiarygodność. Dla autora treści to gorsza sytuacja niż brak danych w obrazie – niespójność może zdyskwalifikować cały fragment.

Praktyczna rekomendacja: lepiej mieć dane tylko w HTML (bez obrazu) niż mieć rozbieżne dane w HTML i obrazie. Obraz powinien ilustrować to, co tekst już mówi, a nie być jedynym lub alternatywnym źródłem informacji. Zasada „single source of truth” sprawdza się także w kontekście multimodalnym. Więcej o tym, jak AI ocenia wiarygodność źródeł, w artykule Jak AI wybiera źródła do cytowania.

Jakie pytania użytkowników dotyczą spójności tekst-obraz?

Analiza query fan-out (GSCGA MCP, query_fanout_production_fast) na domenie semgence.pl wygenerowała 110 unikalnych pod-zapytań w 10 klastrach tematycznych. Zapytania bazowe obejmowały frazy takie jak „multimodalna spójność tekst obraz”, „alt text a AI search”, „rozbieżność obraz tekst SEO”, „audyt multimodalny treści” i „spójność tekst obraz schema”.

Klaster zapytań	Przykładowe zapytanie	Typ intencji	Pokrycie w artykule
Najczęstsze błędy	alt text ai search najczęstsze błędy	informacyjny	pokryty
Na co zwrócić uwagę	multimodalna spójność tekst obraz na co zwrócić uwagę	informacyjny	pokryty
Przykłady zastosowań	przykłady zastosowań spójność tekst obraz schema	informacyjny	pokryty
Audyt – cena i jakość	audyt multimodalny treści cena jakość	komercyjny	częściowo
Narzędzia do audytu	narzędzia do audytu multimodalnego treści	informacyjny	pokryty
OCR vs HTML	czy OCR zastępuje tekst HTML w SEO	informacyjny	pokryty

Specjalistyczny raport wykazał 16 niemapowanych promptów w scenariuszu „audyt multimodalny treści” – żaden z nich nie miał dopasowanego URL-a. Wszystkie 16 zostało oznaczonych jako „needs_new_content” z ryzykiem „high”. Ten artykuł adresuje większość z nich, ale klaster komercyjny (pytania o cenę i dostępność audytu) wymaga odrębnej strony usługowej. Metodologię fan-out production i jej zastosowanie do identyfikacji luk treściowych opisujemy szczegółowo w artykule o pytaniach z treści strony vs popyt GSC.

Weryfikacja twierdzeń: co można potwierdzić, a co jest hipotezą?

Audyt answer_claim_factuality_audit (GSCGA MCP) wyekstrahował z tego artykułu 24 twierdzenia atomowe. Klasyfikacja twierdzeń według typu:

Typ twierdzenia	Liczba	Przykład	Status weryfikacji
Dane z własnego badania	12	43% elementów miało rozbieżność tekst-obraz	Weryfikowalne w danych źródłowych Semgence
Opis mechanizmu patentowego	5	Patent opisuje OCR + embeddings do zapytań wizualnych	Potwierdzone w tekście patentu
Interpretacja / hipoteza	4	Eksperci mają gorsze wyniki bo tworzą grafiki niezależnie	Hipoteza wsparta obserwacją, nie dowód
Stwierdzenie ogólne	3	Alt text to opis przeznaczenia obrazu	Zgodne z WCAG 2.1

Żadne z 24 twierdzeń nie zostało oznaczone jako „contradicted” (sprzeczne ze źródłami). 12 twierdzeń opartych na danych własnych jest weryfikowalnych wyłącznie w zbiorze danych Semgence – zewnętrzny czytelnik musi nam zaufać co do metodologii i uczciwości raportowania. Dlatego podajemy pełną metodologię, liczebnści prób i kryteria klasyfikacji. Podejście do fact-checkingu treści eksperckich opisujemy szerzej w artykule o human-in-the-loop fact-checking.

Czy AI cytuje treści o multimodalnej spójności?

Dane z AI Monitor (system monitoringu widoczności marki w 7 silnikach AI) dla projektu Semgence PL pokazują, że temat multimodalnej spójności tekst-obraz jest niszowy w promptach monitorowanych przez system. Żaden z 60 aktywnych promptów nie dotyczy bezpośrednio audytu multimodalnego – to temat, w którym Semgence buduje pozycję jako pierwsze źródło.

Natomiast powiązane tematy mają ustaloną widoczność. Prompt „Jak AI wybiera źródła do cytowania” generuje cytowania semgence.pl w ponad 78% odpowiedzi AI. Prompt o szkoleniach SEO osiąga avg_score 86.2 z brand_rate 100%. Budowa contentu o multimodalnej spójności rozszerza topical authority Semgence o kolejny wymiar – od tekstu do relacji tekst-media.

Metryka AI Monitor	Wartość	Kontekst
Monitorowane prompthy	60	7 silników AI (ChatGPT, Claude, Perplexity, Gemini, Copilot, Grok, AIO)
Top prompt avg_score	86.2	„Czy Semgence prowadzi szkolenia SEO?” – brand_rate 100%
Own citation rate (top 3)	99.5%, 87.2%, 78.1%	Trzy prompthy z najwyższym wskaźnikiem cytowań własnych
Prompt opportunities	10	Prompty z niską widocznością ale stabilnym wykonaniem
Content hypotheses (GSC)	20+	Długie zapytania GSC (14+ słów) z hipotezami promptów

Content hypotheses z GSC (monitor_content_hypotheses) identyfikują zapytania typu „jak sprawić żeby moja marka pojawiała się w odpowiedziach AI” (confidence 72.9%) i „co to jest techniczne SEO i co należy sprawdzić” (confidence 79.6%). Artykuł o multimodalnej spójności odpowiada na podzbiór tych zapytań – konkretnie na pytanie, jak przygotować media wizualne, żeby były „widoczne” dla AI. Monitoring promptów i hipotezy treściowe opisujemy na smgnc.pl.

Jak przygotować media, które wspierają retrieval?

Zasada	Implementacja	Dlaczego
Dane z obrazu muszą istnieć w HTML	Tabela HTML pod każdym wykresem	System nie może cytować pixeli
Alt text opisuje przeznaczenie, nie dekorację	alt=”Porównanie cen 5 modeli laptopów, Q2 2026″	OCR jest niedoskonały, alt to backup
Daty w obrazie i tekście muszą się zgadzać	Jeden źródłowy dataset per sekcja	Rozbieżność dat = rozbieżność wartości
Schema i obraz opisują ten sam obiekt	Walidacja schema vs zdjęcie per produkt	Google może sprawdzać schema-image match
Lazy load nie ukrywa treści	Prerenderowane fallbacki lub SSR	Crawler może nie wykonać JS

Praktyka: jak wdrożyć duplikację danych obraz-HTML

Zasada „dane z obrazu muszą istnieć w HTML” brzmi prosto, ale wdrożenie wymaga zmiany procesu publikacji. Rekomendowany workflow: (1) przygotuj dane źródłowe jako tabelę lub listę, (2) wygeneruj z nich wykres/infografikę, (3) opublikuj zarówno obraz jak i dane źródłowe na stronie. Kolejność jest kluczowa – dane HTML powinny być tworzone PRZED grafiką, nie jako uzupełnienie po fakcie.

Dla WordPressa: dodaj blok tabeli HTML bezpośrednio pod blokiem obrazu. Dla Shopify/PrestaShop: upewnij się, że parametry produktu widoczne na zdjęciu etykiety istnieją także jako atrybuty w structured data i w tekście opisu. Dla raportów i whitepaperów: każdy wykres powinien mieć pod sobą tabelę „Dane źródłowe”, nawet jeśli wizualnie wygląda to redundantnie.

Redundancja jest celowa. Użytkownik widzi wykres i rozumie trend na pierwszy rzut oka. Maszyna czyta tabelę HTML i może zacytować dokładne wartości. Oba kanały współistnieją i służą różnym odbiorcom. To samo podejście – duplikacja informacji w maszynowo czytelnej formie – stosujemy przy optymalizacji product graph w ecommerce.

Case study: jak wygląda audyt multimodalny w praktyce?

Prezentujemy skrócony przykład audytu jednej strony z naszej próby – strony eksperckiej z branży finansowej, zawierającej 6 elementów wizualnych (2 wykresy, 1 infografika, 2 tabele-obraz, 1 diagram procesu).

Element	Typ	Dane w HTML?	Alt text	Spójność	Ocena
Wykres wzrostu AUM	wykres liniowy	Nie	alt=”wykres”	Tekst: +22%, wykres: +18%	FAIL
Infografika kosztów	infografika	Częściowo	alt=”koszty zarządzania”	Spójne, ale alt nieopisowy	WARN
Tabela porównawcza funduszy	tabela-obraz	Nie	alt=”tabela”	Brak HTML – dane tylko w obrazie	FAIL
Diagram procesu KYC	diagram	Tak (lista kroków)	alt=”proces weryfikacji KYC”	Spójne	OK
Wykres allocation	wykres kołowy	Nie	alt=”allocation”	Brak HTML – dane tylko w obrazie	FAIL
Tabela fees	tabela-obraz	Tak (HTML table)	alt=”tabela opłat”	Spójne	OK

Wynik: 3 z 6 elementów oceniono jako FAIL (dane niedostępne w HTML lub rozbieżne), 1 jako WARN (dane częściowe), 2 jako OK. Strona wygląda profesjonalnie i dobrze rankuje na frazy brandowe. Ale na pytanie „jakie są koszty zarządzania funduszem X” system AI nie jest w stanie odpowiedzieć na podstawie tej strony, mimo że odpowiedź jest widoczna na infografice. Dane po prostu nie istnieją w DOM.

Po wdrożeniu rekomendacji (dodanie tabel HTML pod wykresami, poprawa alt textów, aktualizacja liczby w tekście z 22% na 18% zgodnie z aktualnym wykresem) strona przeszła audyt ze wynikiem 5/6 OK, 1/6 WARN. Czas wdrożenia: ok. 2 godziny pracy redaktora.

Diagnoza i naprawa: 5 typów problemów ze spójnością

Audyt 127 elementów wizualnych ujawnił powtarzalne wzorce problemów. Poniżej opisujemy każdy z pięciu najczęstszych typów: co dokładnie było nie tak, dlaczego to problem dla retrieval, i jak to naprawiliśmy. Każdy przypadek pokazujemy w formacie before/after z konkretnym kodem lub treścią.

Problem 1: Dane liczbowe istnieją tylko w obrazie (38 elementów)

Najczęstszy problem w audycie. Wykres, infografika lub tabela-obraz zawiera wartości liczbowe (procenty, kwoty, liczby klientów), ale żadna z tych wartości nie pojawia się w HTML strony. Dla użytkownika strona wygląda kompletnie – widzi liczby na wykresie. Dla maszyny te liczby nie istnieją.

Przykład z audytu (strona ekspercka, branża fintech): Infografika prezentuje 4 metryki: „wzrost użytkowników +340%”, „czas onboardingu -62%”, „NPS 78”, „retencja 91%”. Żadna z tych wartości nie pojawia się w tekście pod infografiką ani w żadnym innym miejscu w HTML. Alt text: alt="infografika wyniki".

	Przed naprawą	Po naprawie
HTML pod infografiką	Brak – tylko <img>	Tabela HTML z 4 wierszami: metryka, wartość, okres
Alt text	alt=”infografika wyniki”	alt=”Wyniki wdrożenia: wzrost użytkowników 340%, czas onboardingu -62%, NPS 78, retencja 91%”
Tekst w paragrafie	Brak odniesienia do liczb	„W badanym okresie platforma odnotowała wzrost bazy użytkowników o 340% przy jednoczesnym skróceniu czasu onboardingu o 62%.”
Czas naprawy	–	15 minut

Dlaczego to ważne: Pytanie użytkownika „jaki NPS osiąga platforma X” jest pytaniem faktograficznym. System RAG przeszukuje HTML, nie piksele. Jeśli odpowiedź istnieje wyłącznie w obrazie, strona nie może być źródłem odpowiedzi – nawet jeśli użytkownik ją widzi. Dodanie tabeli HTML trwa 15 minut, a zmienia status strony z „niezdolnej do odpowiedzi” na „cytowalną”.

Problem 2: Tekst i obraz podają różne liczby (18 elementów)

Drugi najczęstszy problem: ta sama metryka ma różną wartość w tekście HTML i na obrazie. Przyczyna w 14 z 18 przypadków: jedno z dwóch źródeł zostało zaktualizowane, drugie nie. W 4 przypadkach rozbieżność wynikała z innej metodologii (rok-do-roku vs kwartał-do-kwartału) bez wyjaśnienia.

Przykład z audytu (blog korporacyjny, branża HR): Paragraf pod wykresem stwierdza: „rotacja spadła o 28% w porównaniu z rokiem poprzednim”. Wykres słupkowy nad nim pokazuje słupki 2024: 18.3% i 2025: 14.1%. Różnica to 22.9%, nie 28%. Tekst pochodzi z wcześniejszej wersji raportu (kiedy dane obejmowały inny okres). Wykres został zaktualizowany, tekst nie.

	Przed naprawą	Po naprawie
Tekst pod wykresem	„rotacja spadła o 28%”	„rotacja spadła z 18.3% do 14.1% (spadek o 4.2 p.p., czyli 22.9% względem wartości bazowej)”
Tabela HTML	Brak	Tabela: rok | wartość rotacji – dwa wiersze z danymi z wykresu
Źródło danych	Nieokreślone	„Dane: wewnętrzny raport HR za okres styczeń-grudzień 2024 vs 2025”
Czas naprawy	–	20 minut (w tym weryfikacja poprawnej wartości)

Kluczowa lekcja: Naprawa nie polega na „wybraniu jednej wartości”. Polega na sprawdzeniu, która wartość jest poprawna (tu: dane z wykresu), zaktualizowaniu tekstu, dodaniu tabeli HTML z danymi źródłowymi i podaniu okresu. Bez okresu i źródła nawet spójne dane nie mają kontekstu weryfikowalności. O zasadach weryfikowalności faktów piszemy w artykule o consensus score.

Problem 3: Alt text opisuje coś innego niż obraz (15 elementów)

Trzeci wzorzec: alt text sugeruje jeden typ treści, obraz pokazuje inny. To gorsze niż brak alt textu, bo wprowadza w błąd zarówno czytnik ekranu, jak i system indeksujący. W 8 z 15 przypadków alt text był generyczny („wykres”, „tabela”, „grafika”) – co technicznie nie jest błędne, ale jest bezużyteczne. W 7 przypadkach alt text aktywnie mylił.

Przykład z audytu (sklep internetowy, branża elektronika): Zdjęcie produktu z naklejką energetyczną „A++” i ceną 2 499 zł. Alt text: alt="laptop". Schema Product opisuje inny model (SKU w schema wskazuje na starszą wersję bez klasy energetycznej A++). Trzy źródła – obraz, alt, schema – opisują trzy różne stany produktu.

	Przed naprawą	Po naprawie
Alt text	alt=”laptop”	alt=”Laptop [model] – klasa energetyczna A++, cena 2 499 zł, widok frontu z otwartą klapą”
Schema Product.image	Wskazuje na stock photo starszego modelu	Wskazuje na aktualne zdjęcie produktu z etykietą
Schema Product.sku	SKU starszego modelu	SKU aktualnego modelu widocznego na zdjęciu
Czas naprawy	–	10 minut (aktualizacja alt + schema)

Zasada: Alt text nie musi być transkrypcją każdego piksela. Ale musi być prawdziwy. Jeśli obraz pokazuje konkretny model z ceną, alt „laptop” jest nieprawdziwy przez niedopowiedzenie. A schema wskazująca na inny model niż na zdjęciu to bezpośrednia sprzeczność, którą system weryfikujący (por. patent US20240386247A1) może wykryć i potraktować jako sygnał niskiej wiarygodności.

Problem 4: Tabela porównawcza zapisana jako screenshot (15 elementów)

Tabela porównawcza (ceny, parametry, funkcje) zapisana jako obraz PNG lub JPG zamiast tabeli HTML. Wygląda identycznie dla użytkownika, ale dla maszyny to prostokąt pikseli bez struktury, bez sortowania, bez przeszukiwania.

Przykład z audytu (strona korporacyjna, branża SaaS): Tabela porównawcza trzech planów cenowych (Basic, Pro, Enterprise) z 12 funkcjami i cenami miesięcznymi. Zapisana jako screenshot z Figmy. 21 komórek z danymi – żadna niedostępna w HTML. Strona nie ma też schema Product/Offer z cenami. Na pytanie „ile kosztuje plan Pro” strona nie może odpowiedzieć maszynowo, mimo że odpowiedź jest na niej widoczna.

	Przed naprawą	Po naprawie
Element na stronie	<img src=”pricing-table.png”>	<table> HTML z 3 kolumnami i 12 wierszami + obraz nad nią jako ilustracja
Dostępność danych	0 z 21 komórek dostępnych	21 z 21 komórek dostępnych
Schema	Brak	Schema Offer dla każdego planu z ceną i walutą
Alt text (jeśli obraz zachowany)	alt=”cennik”	alt=”Porównanie planów Basic, Pro i Enterprise – tabela z cenami i funkcjami, dane dostępne w tabeli HTML poniżej”
Czas naprawy	–	45 minut (odtworzenie tabeli HTML + dodanie schema)

Rekomendacja: Nie usuwaj obrazu – użytkownicy mogą preferować wizualną wersję. Dodaj tabelę HTML jako „maszynowo czytelną” wersję tych samych danych. To redundancja celowa: obraz dla człowieka, HTML dla maszyny. Jeśli tabela jest generowana z CMS/PIM, ustaw automatyczny eksport do HTML – wtedy aktualizacja cennika automatycznie aktualizuje obie wersje.

Problem 5: Obraz z danymi niewidoczny po renderze (6 elementów)

Obraz z danymi (wykres, infografika) ładowany przez lazy load lub intersection observer. Crawler widzi placeholder lub pusty <div>. Dane z obrazu nie tylko nie istnieją w HTML – sam obraz też nie istnieje w momencie crawlowania.

Przykład z audytu (blog ekspercki, branża marketing): Infografika „5 kroków strategii content marketingowej” ładowana przez JavaScript intersection observer. Googlebot (w trybie rendering) może ją zobaczyć po scrollu, ale crawlery AI (Perplexity, ChatGPT) prawdopodobnie nie wykonują JS ani nie scrollują. Efekt: infografika nie istnieje dla systemu retrieval.

	Przed naprawą	Po naprawie
Ładowanie obrazu	Intersection observer, brak src w początkowym HTML	loading=”lazy” (natywny atrybut) z pełnym src od początku
Fallback	Brak	<noscript> z pełnym <img> + tabela HTML z danymi
Dane z infografiki	Niedostępne (ani obraz, ani HTML)	Lista HTML z 5 krokami i opisami – dane identyczne jak na infografice
Czas naprawy	–	25 minut

Kluczowe rozróżnienie: Natywny atrybut loading="lazy" jest bezpieczny – pełny URL obrazu jest w src od początku, przeglądarka po prostu opóźnia pobieranie. Niebezpieczny jest pattern, w którym src jest pusty lub wskazuje na placeholder, a prawdziwy URL jest w data-src i podmeniany przez JS. W tym drugim przypadku każdy crawler bez JS widzi pusty element.

Wyniki napraw: ile udało się poprawić i jakim kosztem?

Dla 10 stron z najwyższą liczbą problemów przeprowadziliśmy pełny cykl naprawczy. Poniższe dane pokazują efekt przed i po wdrożeniu rekomendacji.

Metryka	Przed naprawą (10 stron)	Po naprawie	Zmiana
Elementy wizualne łącznie	52	52	0 (nie usuwaliśmy obrazów)
Elementy z danymi w HTML	18 (35%)	47 (90%)	+161%
Rozbieżności tekst-obraz	24	3	-88%
Alt texty generyczne lub błędne	19	2	-89%
Schema-image mismatch	5	0	-100%
Elementy niewidoczne po renderze	4	0	-100%
Średni czas naprawy per strona	–	1h 40min	–
Pozostałe WARN (rozbieżności zaokrągleń)	–	3	Dopuszczalne

Trzy pozostałe ostrzeżenia (WARN) dotyczą zaokrągleń – obraz pokazuje 33.3%, tekst mówi „jedna trzecia”. Uznaliśmy to za dopuszczalne, bo znaczenie jest tożsame. Pięć elementów wizualnych nie wymagało tabeli HTML (zdjęcia dekoracyjne, logo, ikony), dlatego docelowy wskaźnik to 47/47 (100% elementów z danymi pokrytych HTML), nie 52/52.

Koszt naprawy per typ problemu

Typ problemu	Średni czas naprawy	Wymagane kompetencje	Czy można zautomatyzować?
Dane uwięzione w obrazie	15-45 min	Redaktor + dostęp do danych źródłowych	Częściowo – jeśli dane są w PIM/CRM
Rozbieżność liczbowa	20 min	Redaktor + analityk (weryfikacja poprawnej wartości)	Nie – wymaga decyzji, która wartość jest poprawna
Błędny alt text	5-10 min	Redaktor	Częściowo – AI może zaproponować alt, człowiek weryfikuje
Tabela jako screenshot	30-45 min	Redaktor + frontend (jeśli potrzebny styling)	Tak – OCR + konwersja do HTML table
Lazy load ukrywa treść	15-25 min	Frontend developer	Tak – zmiana na natywny loading=”lazy”

Najdroższy do naprawy jest problem „tabela jako screenshot” – wymaga odtworzenia całej struktury tabeli w HTML. Ale to jednorazowy koszt. Jeśli tabela jest generowana z systemu (cennik, porównanie, specyfikacja), warto zainwestować w automatyczny eksport do HTML, żeby każda przyszła aktualizacja propagowała się na oba kanały.

Jak zapobiegać rozbieżnościom? Workflow redakcyjny

Naprawa istniejących problemów to połowa zadania. Druga połowa to proces, który nie dopuści do ponownego rozjazdu. Poniżej workflow, który wdrożyliśmy w projektach po audycie.

Zasada: jedno źródło danych, dwa kanały prezentacji

Każdy element wizualny z danymi liczbowymi powinien powstać z jednego datasetu (arkusz, baza, PIM). Z tego datasetu generowana jest zarówno grafika jak i tabela HTML. Aktualizacja datasetu = automatyczna aktualizacja obu. Jeśli automatyzacja nie jest możliwa (bo grafika jest tworzona ręcznie w Canvie), dataset powinien być linkowany w komentarzu w CMS, żeby redaktor wiedział, skąd wzięły się liczby.

Krok	Działanie	Kto odpowiada	Narzędzie
1. Przygotowanie danych	Zebranie danych źródłowych w jednym arkuszu/tabeli	Analityk	Google Sheets, Excel, PIM
2. Generowanie grafiki	Utworzenie wykresu/infografiki Z danych źródłowych	Grafik/redaktor	Canva, Figma, Datawrapper, PowerBI
3. Generowanie HTML	Utworzenie tabeli HTML z tych samych danych	Redaktor	CMS, ręcznie lub skrypt
4. Napisanie tekstu	Paragraf z kluczowymi liczbami – identycznymi jak w datasecie	Redaktor	CMS
5. Alt text	Opisowy alt z najważniejszymi wartościami	Redaktor	CMS
6. Schema (jeśli dotyczy)	Schema Product/Offer z danymi zgodnymi z obrazem i tekstem	SEO / developer	Plugin schema lub JSON-LD
7. Audyt przed publikacją	Porównanie: obraz vs HTML vs schema vs alt	QA / druga osoba	Checklista z tego artykułu

Co sprawdzać przy aktualizacji treści?

Większość rozbieżności w naszym audycie powstała nie przy tworzeniu, lecz przy aktualizacji. Redaktor podmienił wykres, ale nie zaktualizował tekstu. Albo analityk poprawił dane w tabeli, ale nie wygenerował nowej grafiki. Dlatego każda aktualizacja elementu wizualnego powinna uruchamiać mini-checklistę:

Aktualizujesz…	Sprawdź również…
Obraz/wykres	Tekst pod obrazem, tabela HTML, alt text, schema
Tekst z liczbami	Obraz nad/pod tekstem, tabela HTML, schema
Tabelę HTML	Obraz (jeśli istnieje graficzna wersja tabeli), tekst, schema
Schema (cena, SKU)	Zdjęcie produktu (czy to ten sam model?), tekst opisu
Plik w bibliotece mediów	Wszystkie strony, które go używają (WordPress: sprawdź „attached to”)

Ta checklista wydaje się oczywista – ale 43% rozbieżności w naszym audycie powstało właśnie dlatego, że ktoś zaktualizował jedno źródło i zapomniał o drugim. Automatyzacja (np. hook w CMS, który oznacza stronę jako „do przeglądu multimodalnego” po podmiance mediów) eliminuje ten problem systemowo.

Case study 2: sklep internetowy z feedem produktowym

Drugi case study pochodzi z ecommerce (branża AGD/RTV, sklep na platformie z integracją PIM). Strona kategorii „Pralki automatyczne” zawiera 8 produktów z feedu i 3 elementy redakcyjne (banner, infografika porównawcza, tabela „jak wybrać”).

Elementy z feedu: spójność wymuszona przez system

Produkty z feedu PIM miały pełną spójność: zdjęcie, nazwa, cena, parametry i schema Product pochodzą z jednego źródła (feed XML). Gdy zmienia się cena w PIM, zmienia się wszędzie – w tekście, na etykiecie cenowej w obrazie, w schema. To wzorzec, który eliminuje rozbieżności z definicji. Dlatego ecommerce ma najniższy wskaźnik problemów (34%).

Elementy redakcyjne: tu zaczyna się problem

Trzy elementy redakcyjne na tej samej stronie miały 2 problemy z 3 możliwych:

Element	Problem	Przed	Po	Czas naprawy
Banner „Tydzień Pralek -30%”	Banner pokazuje -30%, ale promocja dotyczy 3 z 8 modeli, nie wszystkich. Tekst „do -30% na wybrane modele” jest poprawny, ale banner sugeruje -30% na wszystko.	Banner: duży napis „-30%”, tekst: „do -30% na wybrane”	Banner: „do -30% na wybrane pralki”, tekst: „rabat do 30% na 3 modele: [lista]”	10 min (zmiana grafiki + tekst)
Infografika „Jak wybrać pralkę”	Infografika z 6 kryteriami (pojemność, obroty, klasa, wymiary, hałas, cena). Żadne dane w HTML. Alt: „jak wybrać pralkę”.	Obraz + alt generyczny, 0 danych w HTML	Obraz + tabela HTML z 6 kryteriami i zakresami wartości + alt opisowy	25 min
Tabela „3 najlepsze pralki do 2000 zł”	OK – tabela HTML z danymi, spójna z resztą strony	Tabela HTML, dane z feedu	Bez zmian (spójna)	0 min

Wniosek: W ecommerce problem multimodalnej spójności nie dotyczy feedu produktowego (tam jest OK), ale elementów redakcyjnych – banerów, infografik poradnikowych, porównań tworzonych przez marketing. To właśnie te elementy wymagają procesu opisanego w sekcji workflow. Więcej o audycie elementów wizualnych w ecommerce w artykule o SEO ecommerce w erze AI Search.

Co się zmieniło po naprawach? Obserwacje po 30 dniach

Dla 10 stron, na których wdrożyliśmy pełen cykl naprawczy, obserwowaliśmy metryki przez 30 dni po zmianach. Zastrzeżenie: 10 stron to zbyt mała próba do twierdzeń przyczynowych. Poniższe obserwacje pokazują korelację, nie udowodnioną przyczynowość.

Obserwacja	Liczba stron	Szczegóły
Wzrost liczby zaindeksowanych passage	7 z 10	Średnio +3.2 passage per strona w Google Search Console (raport Coverage)
Nowe zapytania w GSC po naprawach	6 z 10	Zapytania zawierające wartości liczbowe, których wcześniej nie było w HTML
Poprawa CTR na istniejących zapytaniach	4 z 10	Średnio +0.8 p.p. – prawdopodobnie efekt lepszych meta/snippet
Cytowanie w odpowiedzi AI (AI Monitor)	2 z 10	Dwie strony pojawiły się w odpowiedziach Perplexity na zapytania z liczbami
Brak zmian	3 z 10	Strony z niskim autorytetem domeny – naprawa spójności nie kompensuje braku linków

Najciekawsza obserwacja: 6 z 10 stron zaczęło pojawiać się na nowe zapytania zawierające konkretne wartości liczbowe. Przykład: strona z dodaną tabelą HTML z cenami zaczęła rankować na „ile kosztuje [usługa] miesięcznie”. Wcześniej te dane istniały wyłącznie w infografice – Googlebot ich nie widział w HTML.

Trzy strony bez zmian miały niski autorytet domeny (DR poniżej 15). Naprawa spójności multimodalnej poprawia jakość treści, ale nie zastępuje innych sygnałów rankingowych. Spójność jest warunkiem koniecznym, nie wystarczającym. Podobną zależność obserwujemy przy optymalizacji local SEO – poprawa danych POI działa tylko w połączeniu z autorytetem i linkami.

Checklista multimodalnej spójności

Pytanie	OK	Ryzyko
Czy wartości z obrazu są dostępne w HTML?	Tabela HTML lub tekst z tymi samymi danymi	Dane tylko w obrazie
Czy alt text opisuje treść, nie dekorację?	alt=”Porównanie cen: Model A 2999 zł, Model B 3499 zł”	alt=”wykres” lub alt=””
Czy daty w obrazie i tekście się zgadzają?	Ta sama data lub brak daty w obu	Obraz: 2026, tekst: 2025
Czy schema opisuje ten sam obiekt co obraz?	Schema Product.image = faktyczne zdjęcie tego produktu	Schema wskazuje stock photo lub inny model
Czy obraz jest widoczny bez JavaScript?	SSR lub noscript fallback	placeholder, wymaga scroll + JS
Czy infografika ma HTML-ową wersję danych?	Tabela pod infografiką	Infografika jako jedyne źródło
Czy proces aktualizacji obejmuje oba kanały?	Zmiana danych = zmiana tekstu + zmiana grafiki	Grafika i tekst aktualizowane niezależnie
Czy OCR mógłby poprawnie odczytać dane z obrazu?	Duża czcionka, kontrast, brak nakładek	Mała czcionka, niska rozdzielczość, watermark

Każdy element wizualny powinien mieć „lustrzane” dane w HTML. Obraz dodaje atrakcyjność wizualną, ale HTML jest kanałem, przez który systemy AI pobierają i cytują fakty. Checklista jest rozszerzeniem zasad opisanych w artykule o budowaniu topical authority w dobie AI.

Ograniczenia badania

Badanie ma kilka istotnych ograniczeń, które należy uwzględnić przy interpretacji wyników. Po pierwsze, próba 30 stron i 127 elementów jest wystarczająca do identyfikacji wzorców, ale zbyt mała do generalizacji na cały internet. Wyniki mogą wyglądać inaczej dla stron w innych językach, branżach (np. medycyna, prawo) lub z innymi CMS-ami.

Po drugie, klasyfikacja „spójny” vs „rozbieżny” jest binarna, podczas gdy w rzeczywistości istnieje spektrum. Niewielka rozbieżność zaokrąglenia (38.2% vs 38%) to nie to samo co fundamentalna sprzeczność (wzrost vs spadek). W tej analizie traktowaliśmy każdą rozbieżność liczbową jako „rozbieżną” – bardziej konserwatywna klasyfikacja mogłaby dać niższe wskaźniki.

Po trzecie, nie mamy dowodu, że Google aktualnie stosuje mechanizm z patentu US20240386247A1 do weryfikacji spójności tekst-obraz. Patent opisuje możliwość, nie potwierdzone wdrożenie. Nasze rekomendacje opierają się na logice: jeśli dane są niespójne, niezależnie od mechanizmu weryfikacji, ryzyko dezinformacji jest realne. Więcej o podejściu Semgence do patentów w artykule o kalibracji scoringu SEO.

Źródła i narzędzia

Dane z audytu 30 stron i 127 elementów wizualnych, lipiec 2026. Domeny zanonimizowane, typy stron zachowane.

Narzędzie	Zastosowanie
content_answer_evidence_structure_pack	Struktura dowodów i treści
te_render_visibility_check	Widoczność elementów po renderze
visual_product_discovery_audit	Audyt wizualny produktów
content_discovery_indexability_pack	Indeksowalność treści odkrytej
ecom_visual_product_discovery_audit	Wizualna spójność w ecommerce
query_fanout_production_fast	Analiza fan-out zapytań i luk treściowych
answer_claim_factuality_audit	Weryfikacja twierdzeń atomowych
AI Monitor (smgnc.pl)	Monitoring widoczności marki w 7 silnikach AI

Zagadnienie multimodalnej spójności wiąże się z weryfikacją danych z wielu źródeł, budowaniem cytowalnych encji oraz szkoleniami SEO, w których uczymy rozróżniać treść widoczną od treści dostępnej maszynowo. Powiązane zagadnienia techniczne omawiamy w artykule o błędnym mapowaniu GSC do GA4, które ilustruje inny przypadek rozbieżności między źródłami danych.

Zastrzeżenie dotyczące patentów

Patenty przywołane w tym artykule – US20240386247A1, US12045278B2, US12536225B2 i US12332074B2 – opisują problemy techniczne i proponowane sposoby ich rozwiązania. Samo zgłoszenie lub udzielenie patentu nie dowodzi, że opisany mechanizm działa obecnie w wyszukiwarce Google ani że jest bezpośrednim czynnikiem rankingowym. W tym materiale patenty służą do budowy testowalnych hipotez, które zestawiamy z własnymi danymi i obserwacją działania systemów.