Dane strukturalne AudioObject

TL;DR — Dane strukturalne AudioObject to kod dodawany do strony, aby oznaczyć fragment audio — „to jest odcinek podcastu”, „tyle trwa”, „tu znajduje się plik”. Warto od razu uczciwie powiedzieć: dodanie tego markupu nie daje specjalnego wyniku audio w Google. Nie odblokowuje karty audio ani plakietki. Jego wartość polega głównie na uporządkowanym osadzeniu audio w innych oznaczonych treściach oraz na wiarygodnym, choć nieudowodnionym, wsparciu rozumienia audio przez wyszukiwarki i narzędzia AI — a nie na zdobyciu widocznej funkcji w wyszukiwarce.

Czym są dane strukturalne AudioObject

Gdy na stronie znajduje się odtwarzacz audio — odcinek podcastu, dźwiękowa wersja artykułu albo krótki klip — człowiek widzi i słyszy, czym jest. Wyszukiwarka widzi głównie zwykły tekst i plik multimedialny, którego znaczenie musi odgadnąć. AudioObject schema opisuje to w kodzie, korzystając ze wspólnego słownika schema.org: oznacza name audio, miejsce pliku (contentUrl), czas trwania (duration) i format (encodingFormat).

Jak większość danych strukturalnych zapisuje się je jako JSON-LD — niewielki blok kodu umieszczony na stronie bez zmiany jej wyglądu.

Uczciwa część: czego to nie robi

Oto rzecz, której większość poradników nie mówi wprost. Niektóre typy danych strukturalnych dają bogatszy wygląd wyniku — Recipe może zapewnić kartę przepisu, a VideoObject miniaturę filmu. AudioObject tego nie robi. Obecnie nie ma dla niego dedykowanego wyniku z elementami rozszerzonymi Google: nie ma go na oficjalnej liście obsługiwanych typów danych strukturalnych Google, a dwie spodziewane strony przewodników (/structured-data/podcast i /structured-data/media-clip) po prostu nie istnieją — zwracają komunikat „nie znaleziono”.

Jeśli jedynym powodem dodania AudioObject jest myśl „dostanę wynik podcastu w Google”, uczciwa odpowiedź brzmi: nie dostaniesz go. To nie powód do paniki — tylko powód, aby wiedzieć, co faktycznie zyskujesz.

Po co więc w ogóle to dodawać?

Pozostają dwa uzasadnione powody:

• Pomoc maszynom w zrozumieniu audio. Silniki odpowiedzi AI i systemy wyszukiwania coraz częściej odczytują dane strukturalne, aby ustalić, co zawiera strona. Czysty markup AudioObject to rozsądny zakład na przyszłość — „ta strona zawiera 42-minutowy odcinek podcastu o nazwie X” — choć nikt nie opublikował bezpośredniego dowodu, że konkretnie AudioObject wpływa na systemy AI. Traktuj to jako możliwą, a nie potwierdzoną korzyść, nigdy jako gwarancję.
• Osadzenie audio w innej treści. Jeśli masz artykuł z jego dźwiękową wersją, możesz zagnieździć AudioObject w markupie artykułu i formalnie połączyć oba elementy.

Trzy rzeczy, które są często mylone

• AudioObject nie jest wynikiem podcastu. Taka funkcja Google obecnie nie istnieje.
• Schema to nie to samo co kanał RSS. Mechanizmem, który faktycznie umieszcza podcast w Apple Podcasts i Spotify, jest kanał RSS, a nie schema na stronie.
• AudioObject nie jest PodcastEpisode. Google ma osobne typy podcastowe — i one również nie dają wyniku z elementami rozszerzonymi.

Chcesz poznać listę właściwości, porównanie AudioObject z PodcastEpisode i RSS oraz prosty schemat decyzji „czy warto”? Przejdź do karty Advanced.

TL;DR — schema.org/AudioObject (zwykle JSON-LD) opisuje treść audio za pomocą contentUrl, duration, name i encodingFormat. Najważniejsze potwierdzone ustalenie: nie ma dedykowanego wyniku AudioObject w Google. Typu nie ma na oficjalnej liście obsługiwanych danych strukturalnych Google, a obie prawdopodobne strony przewodników (/structured-data/podcast, /structured-data/media-clip) zwracają 404. Jego wartość polega na osadzaniu audio w innych oznaczonych treściach (np. w associatedMedia artykułu) oraz na możliwym, ale niezależnie niezweryfikowanym wsparciu rozumienia encji i treści na powierzchniach AI, a nie na karcie w SERP. Nie myl go z PodcastSeries/PodcastEpisode (osobne typy Google do zarządzania podcastami, również bez wyniku z elementami rozszerzonymi) ani z kanałami RSS (rzeczywisty mechanizm odkrywania podcastów przez Apple/Spotify, niezwiązany ze schemą na stronie). Traktuj go jako jeden z mniej priorytetowych typów w tym klastrze.

Czym są dane strukturalne AudioObject — i jaka jest uczciwa prawda o tym, czego nie robią

schema.org/AudioObject jest podtypem MediaObject służącym do opisania fragmentu audio: odcinka podcastu, dźwiękowej wersji artykułu albo klipu. Słownik jest rzeczywisty i stabilny. Tym, co nie jest rzeczywiste, jest przypisana do niego funkcja Google Search.

Sprawdziłem to bezpośrednio i warto powiedzieć to bez zastrzeżeń: AudioObject nie ma potwierdzonego sposobu prezentacji jako wynik rozszerzony Google. Potwierdzają to trzy konkretne fakty:

• Nie pojawia się wśród pozycji oficjalnej listy obsługiwanych typów danych strukturalnych Google (czyli „search gallery”). Każdy typ, który daje wynik rozszerzony, znajduje się na tej liście. AudioObjecta tam nie ma.
• Obie spodziewane strony przewodników — developers.google.com/search/docs/appearance/structured-data/podcast i .../media-clip — zwracają 404. Nie ma strony dokumentacji, ponieważ nie ma tej funkcji.
• W przewodniku Google po Video markup klipów jest ujednolicony pod VideoObject/Clip/BroadcastEvent. Nigdzie na developers.google.com/search nie udokumentowano równoległej karuzeli, plakietki ani tabeli właściwości wymaganych lub zalecanych wyłącznie dla AudioObject.

Lubię markup schema, gdy zapewnia funkcję wyszukiwarki. To najbardziej wyraźny w całym klastrze danych strukturalnych przykład markupu, który jej nie zapewnia — dlatego warto mówić o nim wprost, zamiast sztucznie tworzyć poczucie pilności.

AudioObject a PodcastSeries/PodcastEpisode i kanały RSS

Ta trójka jest nieustannie mylona, a jej rozdzielenie stanowi dużą część praktycznej wartości tego artykułu.

• AudioObject — ogólny typ schema.org oznaczający „fragment audio”. Nie daje wyniku rozszerzonego Google.
• PodcastSeries / PodcastEpisode — osobne typy Google dotyczące podcastów. Historycznie były związane z powierzchniami zarządzania podcastami, a nie z wynikiem rozszerzonym Search. W słowniku schema.org PodcastEpisode może wskazywać plik multimedialny przez właściwość associatedMedia — AudioObject pozostaje znajdującą się niżej encją na poziomie pliku, powiązaną z odcinkiem, ale niebędącą tym samym węzłem. Warto pamiętać, że Google Podcasts zamknięto w 2024 roku, co usunęło jedną z niewielu powierzchni, gdzie ten markup mógł mieć bezpośredniego odbiorcę — wzmacnia to ujęcie niskiego priorytetu, ale nie tworzy nowej korzyści.
• MusicRecording — częste nieporozumienie, które warto skorygować wprost: MusicRecording jest typem CreativeWork w schema.org, a nie podtypem AudioObject. Jeśli opisujesz utwór muzyczny, modeluj sam utwór jako MusicRecording, a — jeśli chcesz osobno opisać plik audio — dołącz odrębny AudioObject, zamiast zakładać dziedziczenie między typami.
• Kanały RSS — to właśnie trzeba szczególnie podkreślić: mechanizmem, który faktycznie umieszcza podcast na liście Apple Podcasts, Spotify i innych aplikacji, jest kanał RSS przesłany do tych katalogów. To zupełnie inny mechanizm niż schema na stronie. Żadna ilość markupu AudioObject nie umieści programu w aplikacji podcastowej; robi to kanał.

Gdy więc interesariusz pyta „czy powinniśmy dodać schema podcastu dla SEO?”, poprawna odpowiedź zwykle wymaga rozdzielenia trzech pytań: czy chcesz wyniku rozszerzonego Google (takiego wyniku nie ma), dystrybucji w aplikacjach (to RSS, nie schema), czy ogólnej czytelności dla maszyn (tu AudioObject ma umiarkowaną wartość).

Kiedy nadal warto je wdrożyć

Nawet bez wyniku rozszerzonego istnieją rozsądne powody, aby dodać AudioObject:

• Osadzenie audio w artykule. Jeśli strona jest przede wszystkim artykułem z dźwiękową wersją, zagnieżdżenie AudioObject w artykule (np. jako associatedMedia) formalnie łączy oba elementy. Artykuł może mieć własną wartość, a AudioObject jedynie jasno opisuje jego komponent audio.
• Rozumienie encji i treści na powierzchniach AI. AI Overviews i inne systemy skierowane do LLM coraz częściej odczytują dane strukturalne, aby rozumieć treść strony, a kompletny markup AudioObject może wiarygodnie pomóc im rozpoznać, czym jest audio. To rozsądna hipoteza kierunkowa wynikająca z ogólnego użycia danych strukturalnych, a nie twierdzenie poparte badaniem dotyczącym konkretnie AudioObject ani wypowiedzią Google — traktuj ją ostrożnie i nie sprzedawaj jako gwarancji.
• Kompletność schema.org w witrynach, które i tak intensywnie korzystają z danych strukturalnych. Jeśli wszystko inne jest już czysto oznaczone, dodanie AudioObject jest tanim sposobem zachowania spójności grafu — tylko nie oczekuj korzyści w SERP.

Podstawowe wdrożenie — właściwości, których warto użyć

Ponieważ Google nie publikuje tabeli wymagań, oprzyj się na słowniku schema.org. Oto właściwości, które warto opisać nawet bez wyniku rozszerzonego:

Jedną właściwość warto wyróżnić: transcript. To prawdziwe, poprawne pole AudioObject — schema.org opisuje je bezpośrednio — ale nie ustalono, że umieszczenie transkrypcji wyłącznie w JSON-LD sprawia, iż wypowiadane słowa stają się indeksowalne, cytowalne albo kwalifikują się do fragmentu wyróżnionego; ta korzyść po stronie odbiorcy nie została zweryfikowana. Jeśli transkrypcja ma mieć znaczenie dla SEO lub odpowiedzi AI, opublikuj ją również jako widoczny, dostępny tekst strony. Traktuj właściwość schemy jako maszynowo czytelną ewidencję obok tego tekstu, a nie jego zamiennik.

Minimalny blok JSON-LD:

{
  "@context": "https://schema.org/",
  "@type": "AudioObject",
  "name": "Episode 12: Structured Data Myths",
  "contentUrl": "https://example.com/audio/ep12.mp3",
  "encodingFormat": "audio/mpeg",
  "duration": "PT42M30S",
  "uploadDate": "2026-06-01",
  "description": "We separate the schema hype from what actually earns a search feature."
}

A tak wygląda zagnieżdżenie go jako dźwiękowej wersji artykułu:

{
  "@context": "https://schema.org/",
  "@type": "Article",
  "headline": "Structured Data Myths",
  "associatedMedia": {
    "@type": "AudioObject",
    "name": "Structured Data Myths (narrated)",
    "contentUrl": "https://example.com/audio/narrated.mp3",
    "encodingFormat": "audio/mpeg",
    "duration": "PT42M30S"
  }
}

Czy warto? Schemat ustalania priorytetów

Wolałbym, abyś poświęcił wysiłek tam, gdzie się opłaca, więc oto uczciwy triage:

1. Chcesz uzyskać dzięki temu wynik rozszerzony Google? AudioObject jest wtedy niewłaściwym narzędziem — takiego wyniku nie ma. Poświęć czas typowi, który ma udokumentowaną funkcję.
2. Chcesz umieścić podcast w Apple/Spotify? Potrzebujesz kanału RSS, nie schemy. Upewnij się, że kanał jest poprawny i został przesłany.
3. Oznaczasz już wszystko inne i chcesz poprawić rozumienie encji przez AI? Dodanie AudioObject jest rozsądnym, tanim wykończeniem — tylko ustaw oczekiwania na „czytelność maszynową”, a nie „kartę SERP”.

W większości witryn AudioObject znajduje się niemal na końcu listy priorytetów danych strukturalnych. Nie jest to krytyka słownika — tylko trafny odczyt obecnej korzyści. Aby zobaczyć, gdzie markup audio znajduje się względem pokrewnych typów, sprawdź na tej stronie VideoObject, CreativeWork oraz szersze materiały o Schema Markup i Structured Data.

Podsumowanie AI

Skrócona wersja wariantu Advanced:

• Czym jest: markup schema.org/AudioObject (zwykle JSON-LD) opisujący treść audio — odcinki podcastów, dźwiękowe wersje artykułów i klipy — za pomocą właściwości takich jak contentUrl, duration, name i encodingFormat.
• Najważniejsze ustalenie (zweryfikowane): AudioObject nie ma dedykowanego wyniku rozszerzonego Google. Nie ma go na oficjalnej liście obsługiwanych typów danych strukturalnych Google, a dwie prawdopodobne strony przewodników (/structured-data/podcast, /structured-data/media-clip) zwracają 404. Nie odblokowuje karty audio, plakietki ani karuzeli.
• Do czego faktycznie służy: do osadzania audio w innych oznaczonych treściach (np. w associatedMedia artykułu) oraz do możliwego, ale niezależnie niezweryfikowanego wsparcia rozumienia encji i treści na powierzchniach AI. Nie jest widoczną funkcją SERP.
• Cztery rzeczy, których nie należy mylić:
  • AudioObject = ogólny typ audio, bez wyniku rozszerzonego.
  • PodcastSeries/PodcastEpisode = osobne typy Google do zarządzania podcastami, również bez wyniku rozszerzonego (Google Podcasts zamknięto w 2024 roku); PodcastEpisode może wskazywać plik przez associatedMedia, ale AudioObject pozostaje encją na poziomie pliku.
  • MusicRecording = typ CreativeWork, nie podtyp AudioObject — utwór modeluj jako MusicRecording, a plik audio, jeśli trzeba, jako osobny AudioObject.
  • Kanały RSS = rzeczywisty mechanizm umieszczania podcastu w Apple Podcasts / Spotify — niezwiązany ze schemą na stronie.
• Właściwości, których mimo wszystko warto użyć: name, contentUrl, duration (ISO 8601), encodingFormat (typ MIME), a także description / uploadDate. transcript jest poprawnym polem, ale nie potwierdzono, że transkrypcja wyłącznie w JSON-LD czyni słowa indeksowalnymi lub kwalifikującymi się do fragmentu wyróżnionego — jeśli to ważne, opublikuj również widoczny tekst transkrypcji.
• Priorytet: jeden z mniej ważnych typów w klastrze. Dodaj go dla kompletności i rozsądnego, choć niepotwierdzonego założenia o rozumieniu przez AI w witrynach, które już intensywnie korzystają z danych strukturalnych — nie dla nieistniejącej funkcji wyszukiwania.
• Triage: chcesz wyniku rozszerzonego? To złe narzędzie. Chcesz dystrybucji w aplikacjach? To RSS. Chcesz czystości grafu i czytelności maszynowej? AudioObject jest rozsądnym, tanim wykończeniem.

Oficjalna dokumentacja

Referencje źródłowe — i, nietypowo, najważniejsze ustalenie dotyczy tego, czego dokumentacja nie zawiera.

Najważniejsze ustalenie: nie ma strony funkcji AudioObject

• Lista obsługiwanych typów danych strukturalnych Google (czyli „search gallery”) jest kanonicznym indeksem typów, które dają wyniki rozszerzone. AudioObject na niej nie występuje.
• https://developers.google.com/search/docs/appearance/structured-data/podcast → 404 (strona nieznaleziona). Nie ma przewodnika Google po funkcji danych strukturalnych podcastu.
• https://developers.google.com/search/docs/appearance/structured-data/media-clip → 404 (strona nieznaleziona). Nie ma przewodnika Google po funkcji „media clip” (audio).

Te dwa kody 404 i brak na liście obsługiwanych typów są najważniejszą informacją. Gdy typ ma funkcję Google Search, ma stronę przewodnika i wpis w galerii. AudioObject nie ma żadnego z nich.

Gdzie faktycznie opisano markup audio/klipów (wideo, nie audio)

• Dane strukturalne Video (VideoObject / Clip / BroadcastEvent) — tutaj znajduje się markup klipów Google, ujednolicony pod VideoObject. Nie ma równoległej tabeli wymagań AudioObject.

Osobna dokumentacja Google dotycząca podcastów (RSS/zarządzanie, nie wynik rozszerzony)

• Przewodniki Google „About podcasting on Google” i dotyczące zarządzania podcastami (obecnie przeniesione do pomocy Podcast Publisher Center) dotyczą przesyłania i zarządzania kanałem RSS, a nie markupu schema.org/AudioObject zasilającego wynik rozszerzony Search. Google Podcasts zamknięto w 2024 roku, co dodatkowo ograniczyło znaczenie tej powierzchni.

Sam słownik

• schema.org/AudioObject — definicja typu i pełna lista właściwości, ponieważ Google nie publikuje przewodnika właściwego dla tej funkcji.

Bing / Microsoft

• Nie istnieją wskazówki Bing dotyczące konkretnie AudioObject ani podcastów — jest tylko ogólny przegląd danych strukturalnych (obsługa schema.org, zalecany JSON-LD, ogólny Markup Validator).

Cytaty ze źródła

Nietypowo jest tu niewiele do cytowania — i właśnie o to chodzi. Google nie publikuje wskazówek dotyczących wyniku rozszerzonego AudioObject, więc nie ma oficjalnego fragmentu obiecującego taką funkcję. Zweryfikowany „cytat” w tym temacie jest w istocie nieobecnością: brak wpisu w galerii obsługiwanych typów i brak strony funkcji (oba kandydackie adresy zwracają 404). Nie będę tworzyć wypowiedzi Google, której nie ma.

Jedno wypowiedziane publicznie zdanie, które warto umieścić na początku tego artykułu, pochodzi ode mnie — dokładnie pokazuje, dlaczego AudioObject ma niski priorytet:

Patrick Stox

• “I’m a fan of schema markup as long as it gets you a search feature.” (tłumaczenie) „Lubię markup schema, gdy zapewnia funkcję wyszukiwarki”. Ahrefs — Strategie SEO dla przedsiębiorstw zapewniające maksymalny wzrost

To jedno zdanie pokazuje całe napięcie. AudioObject jest najbardziej wyraźnym w tym klastrze przykładem schemy, która nie daje funkcji wyszukiwarki — uczciwe podejście polega więc na dodaniu go dla rozumienia encji i AI, jeśli i tak intensywnie pracujesz z danymi strukturalnymi, oraz pominięciu go, jeśli jedyną motywacją jest korzyść w SERP.

Mity i błędy AudioObject, których należy unikać

Mit: „Schema AudioObject daje wynik podcastu w Google”. Fałsz — w aktualnej dokumentacji Google nie ma takiej funkcji. AudioObject nie występuje na oficjalnej liście obsługiwanych typów danych strukturalnych, a obie prawdopodobne strony przewodników (/structured-data/podcast, /structured-data/media-clip) zwracają 404. Dodanie markupu nie tworzy karty audio, plakietki ani karuzeli.

Mit: „Schema podcastu i kanał RSS to to samo”. Nie są tym samym, a pomyłka powoduje realną stratę czasu. Kanał RSS jest mechanizmem, który faktycznie umieszcza podcast na liście Apple Podcasts, Spotify i innych aplikacji. Schema na stronie jest osobną — obecnie mało opłacalną — warstwą markupu encji. Jeśli celem jest dystrybucja w aplikacjach, napraw kanał; schema tego nie zrobi.

Mit: „AudioObject i PodcastEpisode są wymienne, a jeden z nich daje wynik rozszerzony”. To odrębne typy i żaden nie daje wyniku rozszerzonego Google Search. PodcastSeries/PodcastEpisode to osobne typy Google do zarządzania podcastami, związane z powierzchniami RSS/zarządzania, a nie z funkcją SERP.

Mit: „Skoro Google Podcasts zamknięto w 2024 roku, schema podcastu jest zupełnie bez sensu”. To przesada. Zamknięcie Google Podcasts usunęło jednego prawdopodobnego odbiorcę markupu, dlatego ten typ ma niski priorytet. AudioObject nadal może wspierać ogólne rozumienie encji i audio przez AI — po prostu od początku nie dawał wyniku rozszerzonego Search, więc zamknięcie nie odebrało funkcji, która istniała.

Błąd: dodawanie AudioObject w oczekiwaniu na wzrost SEO i pomijanie rzeczy, które mają znaczenie. Jeśli interesariusz naciska na „schema podcastu dla SEO”, przekieruj wysiłek: nie ma wyniku rozszerzonego do zdobycia, więc najpierw upewnij się, że kanał RSS jest poprawny (dla dystrybucji w aplikacjach), a treść strony rzeczywiście użyteczna (dla rankingu), zanim poświęcisz czas na markup bez korzyści w SERP.

Błąd: niechlujne wartości właściwości. Jeśli jednak dodajesz ten typ, dopilnuj podstaw — prawdziwego contentUrl wskazującego plik audio, duration w ISO 8601 (PT42M30S, nie „42:30”) oraz poprawnego typu MIME w encodingFormat (audio/mpeg, nie „mp3”). Złe wartości nie pomagają ani ludziom, ani maszynom.

Czy dodać AudioObject do tej strony?

Uczciwa odpowiedź zależy wyłącznie od tego, co naprawdę chcesz osiągnąć za pomocą audio — odcinek podcastu, cel dystrybucji w aplikacji i dźwiękowa wersja artykułu wymagają innych działań, a tylko jedno z nich brzmi „dodaj schema AudioObject”.

Modele mentalne

1. „Czy ten typ daje wynik rozszerzony?” to odczyt z listy, nie zgadywanie. Zanim uznasz dowolny typ danych strukturalnych za wart czasu, sprawdź oficjalną galerię obsługiwanych typów Google. AudioObjecta na niej nie ma, a żaden z oczekiwanych adresów przewodników (/structured-data/podcast, /structured-data/media-clip) nie działa. Gdy typ rzeczywiście nie występuje w galerii, potraktuj tę nieobecność jako ustalenie, a nie lukę w badaniu.

2. Dystrybucja i markup encji to dwa różne zadania. Umieszczenie podcastu w Apple Podcasts lub Spotify jest problemem kanału RSS. Pomoc wyszukiwarce albo systemowi AI w zrozumieniu, czym jest audio, jest problemem schemy. Te mechanizmy się nie zastępują — naprawienie jednego nigdy nie naprawia drugiego, więc zanim sięgniesz po markup, ustal, które zadanie faktycznie masz do wykonania.

3. Zagnieżdżaj audio w treści, której towarzyszy, zamiast traktować je jako samodzielny element. Gdy audio uzupełnia inną treść — na przykład jest dźwiękową wersją artykułu — najcenniejszym ruchem jest zagnieżdżenie AudioObject w markupie tej treści (np. w associatedMedia artykułu), a nie publikowanie go jako odizolowanego bloku bez relacji ze stroną.

4. Priorytet rośnie wraz z zakresem danych strukturalnych już obecnych w witrynie. W witrynie, która i tak inwestuje w szerokie pokrycie schemą, dodanie AudioObject jest tanim i spójnym wykończeniem. W witrynie z ubogim pokryciem i małą ilością czasu jest jedną z najmniej opłacalnych rzeczy, ponieważ na końcu nie czeka żadna funkcja SERP.

5. Bez tabeli wymagań Google poprawność wynika ze słownika, a nie z checklisty. Google nie publikuje tabeli właściwości wymaganych ani zalecanych konkretnie dla AudioObject, więc miarą poprawnego wdrożenia są definicje schema.org: duration w ISO 8601 (PT42M30S, nie "42:30"), encodingFormat jako prawdziwy typ MIME (audio/mpeg, nie "mp3") oraz contentUrl, który faktycznie prowadzi do pliku.

Narzędzia do sprawdzania i generowania markupu AudioObject

Ponieważ nie ma wyniku rozszerzonego Google, o który trzeba zabiegać, najważniejsze jest poprawne przygotowanie JSON-LD i uczciwe zrozumienie tego, do czego kwalifikuje, a do czego nie — te trzy moje bezpłatne narzędzia obejmują cały proces.

• Schema Markup Validator — wklej JSON-LD AudioObject (samodzielny albo zagnieżdżony w associatedMedia artykułu), aby uzyskać walidację według słownika schema.org z poziomami ważności, w tym kontrolą grafu @id między blokami. To właściwe narzędzie do potwierdzenia, że duration jest poprawnym ISO 8601, encodingFormat prawdziwym typem MIME, a contentUrl prawidłowym adresem — czyli rzeczy, które mają znaczenie, skoro Google nie publikuje tabeli wymagań.
• Rich-Result Eligibility Checker — przepuść przez niego JSON-LD strony i sprawdź, do czego kwalifikuje poszczególne typy, a do czego nie. W przypadku AudioObject powinien potwierdzić uczciwe ustalenie tego artykułu: typ nie ma powiązanego wyniku rozszerzonego Google, więc nie oczekuj werdyktu kwalifikacji/niekwalifikacji takiego jak przy markupie Product lub Recipe.
• Schema Markup Generator — zbuduj blok JSON-LD AudioObject (albo pokazane wyżej zagnieżdżenie Article z associatedMedia) w formularzu zamiast pisać właściwości ręcznie, a następnie wyeksportuj go do wklejenia.

Sprawdź się: AudioObject Schema

Pięć krótkich pytań o rzeczywiste zastosowanie markupu AudioObject i rozróżnienia, które często wprowadzają w błąd. Wybierz odpowiedź na każde, a następnie sprawdź wynik.

Zasoby warte uwagi

Moje teksty na ten temat

Nie opublikowałem osobnego przewodnika o AudioObject — i szczerze mówiąc, biorąc pod uwagę, jak mało ten typ robi dla Search, nie ma też wielu wartościowych zewnętrznych materiałów, których warto szukać. Większość zestawień „typów schemy” nie wymienia nawet AudioObject jako osobnego typu, co samo mówi coś o jego priorytecie. Zamiast sztucznie rozbudowywać ten fragment, uczciwiej odesłać do samego słownika i powiązanych danych strukturalnych na tej stronie. Aby zobaczyć, gdzie markup audio znajduje się wśród pokrewnych typów, sprawdź rodzeństwo VideoObject i CreativeWork oraz szersze centra Schema Markup i Structured Data, pod które podlega ten artykuł; ujęcie AI znajdziesz w Schema Markup for AI.

Ze źródeł pierwotnych

• schema.org/AudioObject — definicja typu i pełna lista właściwości. Ponieważ Google nie publikuje przewodnika właściwego dla tej funkcji, jest to autorytatywne źródło dla słownika.
• Obsługiwane typy danych strukturalnych (search gallery) (Google) — kanoniczny indeks typów dających wyniki rozszerzone. Jest przydatny właśnie dlatego, że AudioObject nie znajduje się na tej liście.
• Dane strukturalne Video (Google) — tutaj faktycznie znajduje się markup klipów, ujednolicony pod VideoObject; nie ma odpowiednika AudioObject.
• Pomoc Podcast Publisher Center (Google) — część podcastów dotycząca kanałów RSS i zarządzania nimi, odrębna od schemy na stronie i od każdego wyniku rozszerzonego Search.

Dziennik zmian