MusicRecording and MusicAlbum Schema Guide

MusicRecording and MusicAlbum schema can describe a track, its artist, the album it belongs to, and the particular release available to listeners. The most reliable implementation is one JSON-LD @graph with stable URL-based IDs: a MusicGroup or Person for the artist, a MusicAlbum for the conceptual album, one MusicRecording per track, and an optional MusicRelease for the issued digital, vinyl, or CD edition.

The markup must match the page. It helps machines interpret entities and relationships, but it does not guarantee indexing, ranking, a knowledge panel, or a rich result. Google’s current structured-data gallery does not list MusicRecording, MusicAlbum, or MusicRelease as dedicated rich-result features.

Choose the type by what the page represents

Use MusicRecording when the main entity is a recorded track. Schema.org defines it as a music recording, usually a single song. Useful specific properties include byArtist, duration, inAlbum, isrcCode, and recordingOf.

Use MusicAlbum for a collection of recordings. It inherits playlist properties including track and numTracks, and adds byArtist, albumRelease, albumReleaseType, and albumProductionType.

Use MusicRelease only when you need to model a particular issued version of the album: for example, the digital release and a later vinyl edition. Its specific properties include releaseOf, catalogNumber, musicReleaseFormat, recordLabel, duration, and track.

Use MusicGroup for a band and, according to Schema.org’s definition, it can also represent a solo musician. A Person remains reasonable when the page consistently models the solo artist as a person. Pick one entity model and reuse its @id across the site.

The distinctions are:

• The song as a composition can be a MusicComposition.
• A performed and fixed track is a MusicRecording.
• The collection of tracks is a MusicAlbum.
• A specific commercial or distributed edition is a MusicRelease.
• The performer is a MusicGroup or Person.

Do not force every page to contain every type. A single page may need an artist and one recording. An album page benefits from the connected graph.

Build stable @id values

An @id identifies an entity inside and across graphs. Use an absolute canonical URL plus a fragment that will stay stable:

• https://www.example.com/artists/aurora-field/#artist
• https://www.example.com/music/night-signals/#album
• https://www.example.com/music/night-signals/#track-1
• https://www.example.com/music/night-signals/#digital-release

The @id does not need to open as a separate page when it contains a fragment, but the base URL should be the canonical public page. Reusing the same artist ID lets an album, a track page, and an artist profile refer to one entity instead of creating three disconnected artists with the same name.

Do not use a streaming-platform URL as the ID for an entity owned on your site. Put official profiles in sameAs and keep the canonical artist or release URL as the local identity.

Complete JSON-LD album graph

This example models one artist, an album, one displayed track, and the digital edition. Replace every value with facts visible on the page or supported by the release metadata. Add the remaining tracks using the same pattern.

{
"@context": "https://schema.org",
"@graph": [
{
"@type": "MusicGroup",
"@id": "https://www.example.com/artists/aurora-field/#artist",
"name": "Aurora Field",
"url": "https://www.example.com/artists/aurora-field/",
"image": "https://www.example.com/images/aurora-field.jpg",
"sameAs": [
"https://open.spotify.com/artist/REPLACE_WITH_REAL_ID",
"https://music.apple.com/artist/REPLACE_WITH_REAL_ID"
]
},
{
"@type": "MusicAlbum",
"@id": "https://www.example.com/music/night-signals/#album",
"name": "Night Signals",
"url": "https://www.example.com/music/night-signals/",
"image": "https://www.example.com/images/night-signals-cover.jpg",
"datePublished": "2026-09-18",
"genre": ["Electronic", "Ambient pop"],
"byArtist": {
"@id": "https://www.example.com/artists/aurora-field/#artist"
},
"albumReleaseType": "https://schema.org/AlbumRelease",
"albumProductionType": "https://schema.org/StudioAlbum",
"numTracks": 8,
"track": [
{
"@id": "https://www.example.com/music/night-signals/#track-1"
}
],
"albumRelease": {
"@id": "https://www.example.com/music/night-signals/#digital-release"
}
},
{
"@type": "MusicRecording",
"@id": "https://www.example.com/music/night-signals/#track-1",
"name": "First Light",
"url": "https://www.example.com/music/night-signals/#first-light",
"position": 1,
"duration": "PT3M42S",
"isrcCode": "QMABC2600001",
"byArtist": {
"@id": "https://www.example.com/artists/aurora-field/#artist"
},
"inAlbum": {
"@id": "https://www.example.com/music/night-signals/#album"
}
},
{
"@type": "MusicRelease",
"@id": "https://www.example.com/music/night-signals/#digital-release",
"name": "Night Signals (Digital Release)",
"url": "https://www.example.com/music/night-signals/",
"datePublished": "2026-09-18",
"catalogNumber": "AF001",
"musicReleaseFormat": "https://schema.org/DigitalFormat",
"recordLabel": {
"@type": "Organization",
"name": "Aurora Field Records"
},
"releaseOf": {
"@id": "https://www.example.com/music/night-signals/#album"
},
"numTracks": 8,
"track": [
{
"@id": "https://www.example.com/music/night-signals/#track-1"
}
]
}
]
}


The fake example identifiers are visibly marked and must never ship unchanged. A production generator should omit unknown optional properties rather than filling them with placeholders.

Property decisions that prevent common errors

name and url

Use the official displayed artist and release names. url should point to the canonical page for the entity, not a search query or tracking redirect. If one album page contains track anchors, those anchors can identify visible track sections.

byArtist

Reference the established artist @id. Do not repeat a partial artist object with slightly different spellings in every track. For a featured performance, model the people or groups actually credited by the release metadata and visible page.

duration

Schema.org expects ISO 8601 duration format. Three minutes and forty-two seconds becomes PT3M42S; one hour, two minutes, and five seconds becomes PT1H2M5S. Do not enter 3:42 as a structured duration even if that readable form appears in the track list.

isrcCode

Use the International Standard Recording Code for the exact recording, not the UPC for the product and not an ISWC for the composition. Different recordings or versions may have different ISRCs. Verify them against label or distributor metadata.

inAlbum, track, albumRelease, and releaseOf

These links create the graph. A recording points to its album with inAlbum; an album lists recordings with track. An album can point to an edition with albumRelease; that edition points back with releaseOf. Stable IDs prevent each reference from duplicating the whole object.

dates and edition facts

Use ISO dates such as 2026-09-18. A MusicRelease can inherit datePublished from CreativeWork, even though it is not one of the properties unique to the music type. Model a reissue as a separate release node when its date, catalog number, label, format, or track list differs.

sameAs

Use sameAs for authoritative profiles that represent the same artist or entity. Do not list every playlist, press story, store search page, or fan account. Check the URLs periodically because platform IDs and public profiles can change.

Single-track page example

A single does not need to pretend to be a full album. Use one recording and its artist. If the single is officially released as a one-track product, add MusicAlbum or MusicRelease only when the distinction provides accurate, maintained data.

{
"@context": "https://schema.org",
"@type": "MusicRecording",
"@id": "https://www.example.com/music/first-light/#recording",
"name": "First Light",
"url": "https://www.example.com/music/first-light/",
"datePublished": "2026-09-18",
"duration": "PT3M42S",
"isrcCode": "QMABC2600001",
"byArtist": {
"@type": "MusicGroup",
"@id": "https://www.example.com/artists/aurora-field/#artist",
"name": "Aurora Field",
"url": "https://www.example.com/artists/aurora-field/"
}
}


This compact graph is better than a large object containing guessed label, composition, offer, review, and rating data.

Match structured data to visible content

Google’s structured-data policies require markup to represent the page it appears on. Even when a type has no dedicated rich result, the same principle protects data quality.

Make the following facts visible near the release content:

• Artist and release title.
• Cover artwork.
• Release date.
• Track names and order.
• Durations when marked up.
• Credits and featured performers.
• Label and format when included.
• Links or embeds represented by URLs.

Do not mark up an album that receives only a passing mention in a news article as that article’s main entity. An editorial page can use Article and refer to the release through about or mentions; the canonical album page should carry the detailed album graph.

Doldur Music’s AI music trends guide is editorial content, while its AI and music industry analysis discusses companies and platforms. Neither should be relabeled as an album merely because music is the subject.

Generate markup from the CMS

Store release facts once, then generate both visible HTML and JSON-LD from the same fields. This reduces drift between the page and graph.

A sensible content model includes:

• Canonical artist reference and public profiles.
• Release title, slug, type, date, artwork, and description.
• Ordered tracks with title, duration, ISRC, credits, and optional page anchor.
• Edition records with format, label, catalog number, date, and track order.
• A canonical-host helper used by HTML, sitemap, Open Graph, and JSON-LD.

Omit empty values at render time. Do not output empty arrays, null identifiers, placeholder URLs, or a duration of zero. Escape CMS strings with the framework’s JSON serializer instead of building a script block through string concatenation.

Validate in the correct tools

First parse the JSON itself. A trailing comma, unescaped quote, or duplicated key can invalidate the script before vocabulary validation begins.

Next, use the Schema Markup Validator linked from Schema.org. It can recognize general Schema.org types and properties, including music vocabulary. Resolve misspelled properties, incorrect expected types, malformed enum URLs, and broken ID references.

Then use Google’s Rich Results Test for any separate Google-supported markup on the page, such as breadcrumb or article data. It may not report MusicRecording or MusicAlbum as an eligible enhancement because Google does not currently list those types in its rich-result gallery. That absence is not proof that the JSON-LD is invalid; it means the test and gallery serve a narrower Google feature set.

Finally, deploy the page and use Search Console URL Inspection to confirm that the live HTML is crawlable and that rendered scripts are present. Validation does not guarantee indexing or ranking.

Maintenance checklist

• Use the canonical www hostname in every @id and url.
• Keep one stable artist ID across the site.
• Use MusicRecording for recorded tracks and MusicAlbum for collections.
• Add MusicRelease only for a real issued edition.
• Use ISO 8601 dates and durations.
• Verify ISRC, catalog number, label, credits, and track order.
• Connect nodes with IDs instead of duplicating inconsistent objects.
• Make marked-up facts visible to users.
• Omit unknown values instead of guessing.
• Parse JSON and validate the Schema.org vocabulary.
• Test Google-supported markup separately.
• Recheck the live page after every template change.
• Update the graph when a deluxe edition, reissue, or corrected credit changes the visible release.

Good music schema is a maintained data graph, not an SEO decoration. When the artist, album, recordings, and editions use stable identities and verified facts, the same model can support release pages, archives, internal search, feeds, and future machine-readable features without promising a search display that no platform guarantees.