Przejdź do treści
megapromotingPorozmawiajmy

Ekspertyza · AEO

Tłumaczymy stronę na dane, które maszyna odczytuje bez zgadywania, i weryfikujemy wynik narzędziem silnika.

Dane strukturalne, pytania i odpowiedzi w czytelnej formie, okruszki nawigacji, węzeł organizacji. Spośród trzech tematów to ten, w którym wynik można przetestować, a nie tylko założyć.

Już zbudowaneTrzy własne implementacje, wszystkie otwarte na dysku i weryfikowalne z zewnątrz dziś. Pierwsza: strony produktowe tej witryny serwują graf o rozmiarze 1.479 bajtów z `WebPage`, `SoftwareApplication` i `BreadcrumbList` powiązanymi ze sobą, wygenerowany z tych samych danych co widoczny tekst — 23 strony. Druga: własny moduł analizy odpowiedzi bezpośrednich, 51 linii, osiem sprawdzeń z punktami zapisanymi jawnie w kodzie, z wagą 0,10 w ogólnym wyniku analizatora. Trzecia: publiczny generator danych strukturalnych na naszej stronie, pięć typów, który odpowiada 200. Zastrzeżenie, które podajemy w tym samym zdaniu: ten sam moduł analizy daje 30 na 100 naszej własnej stronie produktowej, ponieważ nie potrafi czytać grafu — ograniczenie jest po stronie narzędzia, zapisane niżej i do naprawy.

Silnik, który pokazuje odpowiedź bezpośrednią, nie składa tekstu: wyciąga fragment ze strony i umieszcza go pod pytaniem. Aby wyciągać bez zgadywania, potrzebuje jednoznacznego powiązania między pytaniem a odpowiedzią, między produktem a jego stanem, między stroną a organizacją, która ją publikuje. Dane strukturalne właśnie tym są — nie ozdobą SEO, lecz stroną napisaną drugi raz, dla czytelnika, który nie rozumie wyglądu, tylko strukturę.

Różnica wobec dwóch pozostałych tematów polega na tym, że tutaj wynik się testuje. Nie zakłada się i nie ma się nadziei: bierze się adres, podaje go narzędziu walidacyjnemu silnika i sprawdza, czy blok jest odczytywany, jakie typy rozpoznaje i jakich pól mu brakuje. Dlatego ta strona może cytować więcej niż ta o generowanych odpowiedziach — i dlatego jest napisana jak wykonana praca, a nie jak oferta.

Jak wygląda sytuacja na tej stronie, policzona dziś, nie szacowana: 147 adresów w mapie witryny. Dwadzieścia trzy strony produktu niosą poprawny graf o wielkości 1.479 bajtów. Wszystkie pozostałe niosą dokładnie jeden blok, o wielkości 265 bajtów, z sześcioma polami: kontekst, typ, identyfikator, nazwa, adres, opis. Bez logo, bez adresu pocztowego, bez punktu kontaktowego i bez linków do publicznych profili — choć w konfiguracji strony zapisanych jest sześć. Strona pytań często zadawanych ma dziesięć pytań w HTML, żadnego bloku pytań czytelnego dla maszyny i nie ma jej w mapie witryny.

Część, która zmienia rozmowę, to już napisany inwentarz tekstu. W źródłach treści tej strony są 233 pary pytanie-odpowiedź na stronach usług, 175 na stronach produktów i dziesięć na stronie pytań często zadawanych — 418 łącznie, napisanych, zredagowanych, z realnymi odpowiedziami. Zero z nich jest dziś w formie czytelnej dla maszyny. To zwykle jest praca: nie tworzenie nowej treści, lecz tłumaczenie istniejącej. Strona, która nie ma zapisanych pytań, ma inny, większy problem, i mówimy to z góry.

Co obejmuje

Praca, komponent po komponencie

Inwentaryzujemy, co dziś czyta maszyna z każdego adresu

Pytamy każdy adres, wyciągamy każdy blok danych strukturalnych, parsujemy go i zapisujemy typy oraz rozmiar. Wynik jest tabelą, nie wrażeniem. Na tej stronie: strona produktu zwraca dwa bloki, o wielkości 265 i 1.479 bajtów, z czterema typami między nimi; strona główna, katalog, blog, kontakt, pytania często zadawane i strony usług zwracają jeden, o wielkości 265 bajtów, z jednym typem. Tu widać też, co jest cicho zepsute: blok, którego nie da się sparsować, nie daje żadnego widocznego błędu, po prostu nie istnieje dla silnika.

Tłumaczymy już napisane pytania, nie wymyślamy innych

418 par pytanie-odpowiedź już istnieje w źródłach treści tej strony i żadna nie jest w formie czytelnej. Blok pytań generuje się z dokładnie tego samego źródła co widoczny tekst, nie zapisuje się go drugi raz ręcznie. Zasada jest ścisła i to właśnie dlatego: jeśli w danych pojawiają się pytania lub odpowiedzi, których nie ma na stronie, silnik traktuje to jako niezgodność, a skutkiem jest utrata specjalnego wyświetlenia, nie zysk.

Jeden graf na stronie, z węzłami, które się znają

Zamiast oddzielnych bloków, które powtarzają te same dane, graf, w którym strona, główna encja i okruszki nawigacyjne odnoszą się do siebie przez identyfikator, a organizacja jest jednym węzłem dla całej witryny. Tak wyglądają nasze strony produktów: strona odsyła do organizacji jako wydawcy, główna encja odsyła do tej samej organizacji jako autora, okruszki nawigacyjne mają trzy rzeczywiste stopnie. Szczegół, którego nie widać: podczas zapisu znak `<` jest zastępowany swoją sekwencją ucieczki, aby tekst z danych nie mógł zamknąć bloku i trafić jako kod na stronę. To jedna linia, jest w pliku.

Sprawdzamy narzędziem silnika, nie naszym zdaniem

Każdy typ strony przechodzi przez narzędzie walidacyjne silnika, które mówi, co odczytało i jakiego pola mu brakuje. To jedyne miejsce wśród trzech tematów, gdzie istnieje zewnętrzny, natychmiastowy i powtarzalny werdykt. To, co dostarczamy, to zrzut werdyktu dla każdego typu strony, a nie stwierdzenie, że „zaimplementowaliśmy schemę”.

Własny moduł analizy, z punktami zapisanymi w kodzie

Nasz moduł odpowiedzi bezpośrednich wykonuje osiem kontroli z jawną punktacją: istnienie dowolnego czytelnego bloku 20 punktów, często zadawane pytania 20, instrukcje krok po kroku 10, sekcje oznaczone do odczytu głosowego 10, ścieżka nawigacji 10, oceny 10, organizacja 10, artykuł lub produkt 10, z limitem do 100. Ma wagę 0,10 w ogólnym wyniku analizatora. Punkty nie są ukryte w algorytmie; to osiem linii, które można przeczytać.

Ograniczenie własnego narzędzia, powiedziane zanim samodzielnie je znajdziesz

Ten sam moduł odczytuje typ tylko na najwyższym poziomie bloku albo w tablicy. Graf nie ma typu na najwyższym poziomie, więc typy wewnątrz niego nie są widoczne. Skutek, zmierzony na naszej własnej stronie: strona produktu otrzymuje 30 ze 100 od naszego analizatora, mimo że ma trzy poprawne typy, z których dwa są punktowane przez moduł. Liczba jest błędna, strona nie. Napisałem to tutaj, ponieważ narzędzie, którego wadę poznajesz od dostawcy, jest bardziej użyteczne niż to, o którym dowiadujesz się samodzielnie przy drugim uruchomieniu.

Węzeł organizacji, raz dla całej strony

Nazwa prawna, adres, punkt kontaktowy, logo i linki do profili publicznych, w jednym węźle, do którego odsyłają wszystkie strony. To rzecz, która łączy stronę z resztą publicznych śladów. Na tej stronie węzeł ma sześć pól i żadnego z tych linków, chociaż w konfiguracji zapisano sześć profili. To brak, jest liczony i jest pierwszy na liście do naprawy, bo da się go usunąć w jednym miejscu.

Karta udostępniania, generowana z tytułu strony

Obraz, który pojawia się, gdy ktoś udostępnia adres, jest generowany z tytułu i opisu strony, w kolorach strony, aby podgląd pokazywał stronę, do której prowadzi. Nasze strony produktowe mają własną trasę i zwracają rzeczywisty obraz. Brak, zapisany jako brak: strony usług deklarują w metadanych adres obrazu, dla którego nie istnieje trasa w kodzie — wywołany bezpośrednio zwraca 404. Produkcja serwuje na razie obraz ogólny, więc wada pojawia się dopiero po publikacji, na 25 stronach. Jest wskazana, nie ukryta.

Czego nigdy nie umieszczamy w danych strukturalnych

Notatek i recenzji, których nie można udowodnić publicznym źródłem. Cen, które nie są zapisane na stronie. Terminów dostawy jako gwarancji. Powód nie jest ostrożnością: zadeklarowana w danych ocena bez publicznego źródła to dokładnie to, na co celuje ręczna sankcja, a fałszywe stwierdzenie w formacie czytelnym dla maszyny jest kłamstwem stworzonym po to, by krążyć — to ono trafia do cytowania. Znaleźliśmy coś takiego w naszym własnym repozytorium i poniżej piszemy, co to było i co zrobiliśmy.

Jak to wygląda

Trasa, krok po kroku.

01

Dzisiejszy inwentarz, adres po adresie

Pierwsza dostawa to tabela: każdy adres, każdy blok, rozpoznane typy, rozmiar w bajtach i bloki, które się nie parsują. Od tego momentu każde stwierdzenie ma z tyłu wiersz. To też moment, w którym pojawiają się bloki pozostałe po wcześniejszej wersji strony, sprzeczne ze stroną dzisiejszą.

02

Węzeł organizacji i okruszki nawigacyjne

Są wykonywane raz i stosowane wszędzie: jeden węzeł dla organizacji, z identyfikatorem, do którego odsyłają wszystkie strony, oraz okruszki nawigacyjne zgodne z rzeczywistą strukturą adresów. Kolejność nie podlega negocjacjom — w odwrotnej wersji naprawia się sto stron dla czegoś, co rozwiązuje się w jednym pliku.

03

Istniejące pytania, podane w formie

Blok pytań jest generowany z tego samego źródła co widoczna lista na stronie. Dostarczamy też listę adresów, gdzie pytania istnieją w tekście, ale nie były zadeklarowane — na tej stronie wyszło 418 zapisanych par i żadnej zadeklarowanej.

04

Zewnętrzna walidacja, dla każdego typu strony

Przechodzimy przez narzędzie silnika po jednej stronie każdego typu i dostarczamy werdykt: jakie typy zostały odczytane, jakich pól brakuje, jakie ostrzeżenia się pojawiły. Nie deklarujemy niczego jako zakończonego na podstawie tego, że blok „jest w kodzie”.

05

Kontrola, która pozostaje po nas

Skrypt uruchamiany po każdej publikacji, który pada, jeśli blok przestał się parsować, jeśli typ zniknął z szablonu strony albo jeśli blok pytań odłączył się od widocznego tekstu. Bez niego praca eroduje dokładnie jak każda niepisana konwencja: ktoś dodaje nowy szablon i zapomina, a nikt tego nie zauważa, bo nic nie wygląda na zepsute na ekranie.

1Inwentarz2traducere3validareco dziś czyta maszyna z każdego adresu, co deklarujemy z już istniejącego tekstuscris, ce spune unealta motorului despre rezultat.
Trasa, w 3 krokach

Dane

Czego dotykamy, gdzie to leży i jak długo zostaje

Pytania, które zadaje każdy, kto ma inspektora ochrony danych — postawione tutaj, zanim on je zada.

Co czytamy z Twojej strony
Tylko publiczny HTML i bloki danych, które już tam są. Do inwentaryzacji nie potrzebujemy dostępu administracyjnego. Do walidacji nie potrzebujemy nic więcej: narzędzie motoru działa na publicznym adresie.
Czego potrzebujemy od Ciebie, i czego nie możemy wymyślić
Fakty w węźle organizacji: dokładna nazwa prawna, adres, godziny pracy, numer kontaktowy i rzeczywiste publiczne profile. Dane strukturalne sprzeczne z rzeczywistością są gorsze niż ich brak — są weryfikowalnym i błędnym twierdzeniem, opublikowanym przez Ciebie, w formacie przeznaczonym do automatycznego odczytu.
Czego nigdy nie umieszczamy w danych
Dane osobowe pracowników lub klientów. Oceny bez publicznego źródła. Ceny, które nie pojawiają się na stronie. Pytania i odpowiedzi, których odwiedzająca osoba nie widzi. Praktyczna zasada: jeśli osoba otwierająca stronę nie może tam znaleźć tej informacji, nie ma ona czego szukać w bloku.
Skąd generują się bloki
Z tego samego źródła danych co widoczny tekst, a nie z pliku równoległego. To jedyny sposób, by te dwa elementy się nie rozchodziły: ktoś zmienia odpowiedź na stronie, a blok zmienia się wraz z nią. Blok zapisany ręcznie zostaje w tyle po kilku miesiącach i nikt tego nie zauważa, bo tego nie widać.
Gdzie znajdują się wyniki i jak długo pozostają
Tabela inwentaryzacyjna, wyniki narzędzia walidacji i kontrola po publikacji są wersjonowane w repozytorium projektu, obok kodu. Żyją tak długo, jak żyje repozytorium. Nie zawierają niczego, czego już nie ma na stronie: inwentaryzacja danych strukturalnych to odczyt publicznych stron, a nie ekstrakcja z Twoich systemów.

Przykład

418 zapisanych pytań, ani jedno nie w formie czytanej przez maszynę

Sytuacja

Nasza własna strona, 147 adresów w mapie strony, z tekstem niedawno przepisanym pytanie po pytaniu. Wszystkie strony odpowiadały 200 i wyglądały poprawnie. Początkowe pytanie nie brzmiało „co jeszcze dodajemy”, lecz „z tego, co jest na stronie, co trafia do maszyny”.

Co zbudowaliśmy

Poprosiliśmy o reprezentatywne strony dla każdego typu, wyodrębniliśmy i sparsowaliśmy każdy blok danych strukturalnych, policzyliśmy typy i bajty. Odtworzyliśmy nad żywym HTML-em logikę naszego własnego modułu analizy, aby zobaczyć, jaki wynik sam sobie daje strona. Odczytaliśmy komponenty danych strukturalnych z repozytorium, także te, które nie są nigdzie używane. I policzyliśmy istniejące pary pytanie-odpowiedź w źródłach treści.

Co z tego wyszło

Dwadzieścia trzy strony produktu mają poprawny graf o rozmiarze 1.479 bajtów, z trzema typami powiązanymi ze sobą. Wszystkie pozostałe mają jeden blok o rozmiarze 265 bajtów, z sześcioma polami i żadnym elementem tożsamości — bez logo, bez adresu, bez punktu kontaktowego, bez odnośników do sześciu profili zapisanych w konfiguracji. Strona z najczęściej zadawanymi pytaniami ma dziesięć pytań w HTML, nie ma zadeklarowanego bloku i nie występuje w mapie strony. W źródłach jest 418 zapisanych par pytanie-odpowiedź: 233 na usługę, 175 na produkt, dziesięć na stronie pytań. Zero zadeklarowanych. Nasz własny moduł daje stronie produktu 30 na 100, ponieważ nie czyta typów z grafu. A w repozytorium znaleźliśmy trzy niewykorzystywane komponenty, które deklarowały ocenę zbiorczą z podpisanymi recenzjami, katalog cen oraz przewodnik krok po kroku z terminami — sprawdzone na produkcji, że żaden nie jest serwowany.

Czego nie mówi ten przypadek

Nic z powyższej listy nie było naprawione w dniu, w którym to napisano. Inwentaryzacja i ustalenia są rezultatem tego etapu; naprawy są etapem następnym i mają swoją kolejność — najpierw to, co można rozwiązać w jednym pliku, potem to, co wymaga pracy w każdym szablonie. I jeszcze raz, bo to ważne: poprawny blok nie kupuje specjalnego wyświetlania. Umożliwia je. Resztę decyduje dokumentacja motoru, a ona się zmienia.

Pytania

O co pytają ludzie, zanim zadzwonią

Czy dane strukturalne gwarantują mi wzbogacony fragment w wynikach?

Nu. Afișowanie specjalne daje motor, nie znacznik. Prawidłowe dane są warunkiem wejścia, nie kupnem wyniku. Widać to wyraźnie nawet po typie znacznika, który sprzedaje się wszędzie: dokumentacja Google pisze, że wynik rozszerzony dla często zadawanych pytań jest pokazywany tylko dla znanych i autorytatywnych witryn rządowych oraz zdrowotnych — ograniczenie, które weszło w życie we wrześniu 2023. Więc dostawca, który dziś sprzedaje ci „fragmenty rozszerzone z FAQ”, albo nie przeczytał dokumentacji, albo liczy, że to ty jej nie przeczytałeś.

To po co w ogóle deklarować pytania, skoro nie pojawiają się jako fragment?

Bo specjalne wyświetlanie to tylko jeden z konsumentów formatu. Prawidłowo zadeklarowany blok pytań jednoznacznie mówi, który tekst jest pytaniem, a który odpowiedzią — informacja używana przez wyszukiwarki do wyciągania fragmentów, przez asystentów czytających stronę na żądanie użytkownika i przez każdy system, który pobiera treść bez oglądania wyglądu. Jest też inny, mniej omawiany efekt: obowiązek deklarowania par zmusza do posiadania prawdziwych odpowiedzi na prawdziwe pytania. Strony, które nie potrafią wypełnić formatu, zwykle nie mają czego deklarować.

Do czego to służy, w porównaniu z SEO i widocznością w generowanych odpowiedziach?

Do formy, nie do inwentarza i nie do kompozycji. SEO odpowiada na pytanie: „czy silnik może dotrzeć do każdej strony i czy wie, która jest wersją oficjalną”. Widoczność w generowanych odpowiedziach odpowiada na „czy mogę być użyty jako źródło”, gdzie wyniku nie da się obiecać. Tutaj odpowiada się na „czy maszyna może wziąć dokładną informację ze strony bez zgadywania”, i to jedyne z tych trzech z zewnętrznym werdyktem: podajesz adres narzędzia do walidacji i od razu dostajesz odpowiedź.

Czy mogę w danych umieścić pytania albo informacje, których nie ma na stronie?

Nie, i to błąd, który często znajdujemy. Znacznik opisujący coś innego niż widoczna treść jest traktowany jako niezgodność, a skutkiem jest utrata wyświetlania, czasem ręczna kara. Reguła, którą stosujemy, jest mechaniczna, nie opiera się na zdrowym rozsądku: blok jest generowany z tego samego źródła co tekst na stronie, więc nie może zawierać czegoś, czego nie widać. Gdy ktoś prosi, żeby dodać do danych odpowiedź, której nie chce napisać na stronie, rozmowa kończy się tam.

Konkurencja ma gwiazdki w wynikach. Czemu my nie?

Bo nie możemy udowodnić oceny. Zagregowana ocena zadeklarowana w danych musi odpowiadać rzeczywistym, publicznie weryfikowalnym recenzjom. Bez tego jest to fałszywe stwierdzenie w formacie czytelnym maszynowo. Jesteśmy tu kategoryczni z konkretnego powodu: we własnym repozytorium znaleźliśmy komponent, który deklarował ocenę 4,9 z 87 recenzji i sześć recenzji podpisanych imionami i nazwiskami, oraz drugi, który deklarował katalog czterech ofert z cenami. Żaden z nich nigdzie nie jest renderowany — produkcja dziś obsługuje jeden blok, zweryfikowany — ale istniały o jeden import od wdrożenia. Zaznaczyliśmy to w dzienniku decyzji zespołu, nie usuwaliśmy po cichu.

Jakich typów używacie w praktyce?

Tych, które uruchamiamy: strona, główny byt strony, okruszki nawigacyjne, organizacja i blok pytań. Nasz publiczny generator obejmuje pięć typów — lokalny biznes, organizacja, artykuł, produkt, najczęściej zadawane pytania — i jest dostępny na stronie. Każdy inny typ omawiamy na życzenie, po sprawdzeniu zgodności z tym, co silnik faktycznie pokazuje dla twojej domeny. Czego nie robimy: nie dodajemy typów tylko dlatego, że istnieją w specyfikacji. Blok, którego żaden silnik nie używa dla twojej strony, to ciężar, nie zaleta.

Jak sprawdzacie, że działa?

W trzech miejscach, bo jedno kłamie. Narzędzie walidacyjne silnika daje werdykt zewnętrzny. Nasz moduł analizy daje wynik z ośmioma kontrolami i punktami zapisanymi w kodzie, żeby dało się porównywać między uruchomieniami. A skrypt uruchamiany po każdej publikacji pada, jeśli blok przestał się parsować albo typ zniknął. Dodajemy też ograniczenie naszego modułu, żebyś nie musiał odkrywać go sam: jeszcze nie czyta typów z grafu, więc daje niższy wynik niż rzeczywistość poprawnie zbudowanych stron — w tym naszych.

Co psuje się z czasem?

Powiązanie między blokiem a stroną. Ktoś zmienia odpowiedź w tekście, blok zostaje ze starą, i nic nie wygląda zepsute na ekranie — dlatego miesiącami pozostaje to niezauważone. Drugą rzeczą, która się psuje, są bloki zostawione po wcześniejszej wersji strony, opisujące ofertę, która już nie istnieje. Obydwie rzeczy mają to samo rozwiązanie: bloki generują się ze źródła tekstu, a to, co się nie generuje, usuwa się.

Co dokładnie dostarczacie?

Tabelę inwentarza z każdym adresem, każdym blokiem, typami i bajtami. Zaimplementowane bloki, generowane ze źródła treści. Werdykt narzędzia walidacyjnego dla każdego typu strony. Skrypt sprawdzający uruchamiany po publikacji. I listę pozostałych braków, zapisanych jako braki — na tej stronie na przykład węzeł organizacji bez linków do profili, strona pytań nieobecna w mapie witryny oraz zadeklarowana w metadanych ścieżka obrazu udostępniania, której nie ma w kodzie.

Na czym opierają się powyższe stwierdzenia (13 źródeł)
  1. Dokumentacja Google pisze, że wzbogacony wynik dla najczęściej zadawanych pytań pokazywany jest tylko dla znanych i wiarygodnych witryn rządowych i medycznych, ograniczenie ogłoszone we wrześniu 2023https://developers.google.com/search/docs/appearance/structured-data/faqpage · 2026-09-06
  2. Mapa strony zawiera 147 adresówhttps://www.megapromoting.com/sitemap.xml · 2026-09-06

11 z nich to kod i pliki z naszych repozytoriów. Nie publikujemy ich nazw ani numerów linii: razem, na jednej stronie, opisałoby to zbyt dokładnie, jak zbudowane są systemy, które nie należą tylko do nas. Przechodzimy je razem z Tobą, w repozytorium, na życzenie — weryfikacja pozostaje możliwa, tylko odbywa się w rozmowie.

Co chcesz, żeby działało lepiej?

Opowiedz nam o swoim procesie. Wspólnie ustalimy, co warto zbudować, co da się połączyć i jak sprawdzimy wynik.

Porozmawiajmy