Dane strukturalne i Open Graph: co poprawić w oznaczeniach strony?

Dwie warstwy metadanych i różne cele

Informacje powinny zgadzać się z dokumentem widocznym dla odbiorcy. Artykuł instruktażowy nie staje się produktem przez dodanie typu Product, a prywatna aplikacja nie powinna pozorować publicznej oferty. Zacznij od celu strony i danych, za których aktualność ktoś rzeczywiście odpowiada.

Wprowadzenie Google do danych strukturalnych wyjaśnia ich rolę. Z kolei specyfikacja Open Graph opisuje podstawowe właściwości protokołu. To odrębne zestawy oznaczeń, mimo że mogą korzystać z tego samego tytułu i obrazu.

Co potwierdza kontrola w audycie?

Audyt potrafi wykryć bloki JSON-LD, zgłoszone typy, podstawowe błędy parsowania oraz tagi social w pobranym HTML. Nie jest pełnym walidatorem każdej właściwości słownika i nie zna prawdziwości podanych danych. Obecność pola author nie potwierdza autorstwa, a poprawnie zapisany adres obrazu nie dowodzi, że każda platforma potrafi go pobrać.

Rozwiń dowody i sprawdź, czy wynik dotyczy braku oznaczenia, błędnej składni czy dostępności zasobu. Część serwisów nie potrzebuje rozbudowanych typów danych. Brak JSON-LD sam w sobie nie oznacza blokady indeksowania.

Ważne rozróżnienie: typ dostępny w Schema.org nie musi odpowiadać funkcji widocznej obecnie w wyszukiwarce. Przy konkretnym zastosowaniu sprawdź aktualną galerię obsługiwanych funkcji Google i wymagania wybranego typu.

Jak dobrać i uporządkować dane strukturalne?

1. Wybierz stronę reprezentatywną dla rodzaju treści: artykuł, produkt lub kategoria z nawigacją okruszkową.
2. Spisz informacje, które rzeczywiście widać: tytuł, autor lub organizacja, daty, produkt i jego wariant. Nie dopisuj ocen ani recenzji, których nie ma.
3. Sprawdź, czy CMS lub używana wtyczka już generuje oznaczenia. Kolejny dodatek może utworzyć sprzeczny opis tego samego obiektu.
4. Popraw istniejące źródło i przetestuj jedną stronę przed zastosowaniem wzoru w całym serwisie.

Poniższy fragment jest przykładem składni dla fikcyjnego artykułu, a nie kompletnym zestawem wymagań dowolnej funkcji Google:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Jak przygotować ekspres do przeglądu",
  "mainEntityOfPage": "https://example.org/poradnik/ekspres/"
}
</script>

Wytyczne jakości Google wymagają zgodności oznaczeń z treścią. W sklepie szczególnej uwagi wymagają dane zmienne, np. dostępność i cena: nie kopiuj raz wpisanej wartości do wielu niepowiązanych produktów.

Jak przygotować sensowny podgląd udostępnienia?

Dobierz tytuł, opis i grafikę do konkretnej podstrony. Dla poradnika ilustracja powinna pomagać rozpoznać temat, dla produktu pokazywać rzeczywisty produkt. Obraz z drobnym zrzutem całego panelu zwykle trudno odczytać w małej karcie. Sprawdź czytelność również po zmniejszeniu grafiki.

<meta property="og:type" content="article">
<meta property="og:title" content="Jak przygotować ekspres do przeglądu">
<meta property="og:url" content="https://example.org/poradnik/ekspres/">
<meta property="og:image" content="https://example.org/media/ekspres-poradnik.jpg">
<meta property="og:description" content="Lista czynności przed przekazaniem urządzenia do serwisu.">

To demonstracyjne dane, które trzeba zastąpić własnymi. Używaj stabilnego, publicznie dostępnego adresu obrazu. Dla strony HTTPS wskaż obraz przez HTTPS i sprawdź, czy po drodze nie wymaga logowania. Dopasuj format oraz wymiary do wymagań platform, na których rzeczywiście udostępniasz treść; nie ma jednego podglądu gwarantowanego wszędzie.

Jak sprawdzić składnię, treść i rzeczywisty podgląd?

Rozdziel sprawdzanie na trzy próby. Najpierw użyj walidatora Schema.org, aby zbadać składnię i relacje słownika. Następnie w Rich Results Test sprawdź obsługiwane przez Google typy i komunikaty narzędzia. Poprawny test nie jest obietnicą pojawienia się rozszerzonej prezentacji.

Na końcu otwórz publiczny adres obrazu i użyj narzędzia podglądu wybranej platformy, jeżeli je udostępnia. Karta generowana w raporcie DoSieci jest symulacją z odczytanych tagów. Platforma może mieć wcześniejszą kopię danych lub wybrać inne elementy.

Po zmianie zleć ponowne pobranie metadanych tam, gdzie platforma daje taką funkcję, zamiast bez potrzeby zmieniać adres podstrony. Zapisz datę testu i zaobserwowany wynik, aby później odróżnić błąd wdrożenia od starego podglądu.

Gdzie wprowadzić poprawkę i kto powinien ją utrzymywać?

W CMS metadane mogą pochodzić z ustawień wtyczki SEO, pól podstrony, modułu sklepu albo szablonu. Ustal źródło, zanim dodasz kolejny blok. W aplikacji i witrynie statycznej popraw komponent lub dane źródłowe używane przy budowaniu dokumentu. Zmiana w jednym wygenerowanym pliku nie wystarczy, jeśli kolejne wydanie ją nadpisze.

Po wdrożeniu sprawdź reprezentatywne strony i ponów audyt. Dla danych powtarzalnych ustal prostą odpowiedzialność: kto aktualizuje autora, kto pilnuje cen, kto zatwierdza grafikę? Profesjonalny zestaw oznaczeń to przede wszystkim wiarygodne informacje utrzymywane razem z treścią, nie maksymalna liczba typów.