Artist Website Structured Data: A JSON-LD Specification
Model an artist website with separate connected JSON-LD nodes for the site, artist, releases, and recordings. Choose each type from the real entity, reuse stable @id URLs, mark only accurate visible facts, connect official same-entity profiles, validate syntax and page parity, and document which Google search features actually support the markup instead of treating valid vocabulary as a placement request.
Lead visual
One artist entity graph
@id / node 1
WebSite
name + canonical URL
@id / node 2
Person / MusicGroup
name + URL + sameAs
@id / node 3
MusicAlbum
byArtist + tracks
@id / node 4
MusicRecording
byArtist + inAlbum + ISRC
Audience · Owned web
Entity graph map
Decision
Choose the type that describes the real artist or release, then connect repeated references with one stable identifier.
Evidence
WebSite, Person or MusicGroup, MusicAlbum, MusicRecording, canonical URLs, stable IDs, visible names, accurate identifiers, and same-entity links.
Risk
Valid JSON-LD can still be misleading, contradictory, invisible on the page, or unsupported as a Google rich-result feature.
Good outcome
Truthful machine-readable relationships that can be validated and maintained without promising a search enhancement.
Key takeaways
- Model the site and artist as separate connected entities.
- Choose Person or MusicGroup from the real identity, not the desired search feature.
- Reuse stable IDs whenever a release or recording references the artist.
- Keep every marked-up fact accurate and represented by the page.
- Validate vocabulary and record whether Google documents a matching search feature.
How should the artist entity graph connect?
Velveteen entity graph
Four nodes with stable relationships
- 01
Node 1
WebSite
Use the canonical home URL, preferred site name, and accurate alternate name where useful; keep site identity distinct from the artist node.
- 02
Node 2
Artist identity
Choose the exact type from the real solo or group entity, then use a stable @id, preferred name, canonical URL, image, description, genre, and official profiles.
- 03
Node 3
MusicAlbum
Give the release its own stable @id, name, canonical URL, image, date, and byArtist reference to the established artist node.
- 04
Node 4
MusicRecording
Connect the exact recording to byArtist and inAlbum, then add duration, URL, and verified ISRC only when the visible page supports them.
Which structured-data type belongs on each page?
| Use when | Do not use to | |
|---|---|---|
| WebSite | The crawlable home page states the canonical site name and URL | Replace the Person or MusicGroup artist identity |
| Person | The entity is a real solo person represented by the page | Model a band, collective, fictional label, or every stage name without context |
| MusicGroup | The entity is a band or performing group with accurate artist facts | Treat vocabulary selection as a request for a search placement |
| MusicAlbum | A release page visibly describes the album or release and its artist | Mark up a playlist, unrelated recommendation list, or hidden catalog |
| MusicRecording | A track page identifies the exact recording and its artist or album relationship | Reuse one node for alternate masters, edits, remixes, or recordings with different identifiers |
What must the JSON-LD validation record contain?
Structured-data contract
Syntax, identity, visibility, and maintenance
@id
Use one stable URL identifier for each repeated real-world entity
Prevents several contradictory artist or release nodes from forming.
Type
Choose WebSite, Person, MusicGroup, MusicAlbum, or MusicRecording from the real entity
Keeps the graph descriptive instead of aspirational.
Facts
Match names, URLs, images, dates, credits, genres, durations, and identifiers to verified visible content
Satisfies the truth and page-representation boundary.
sameAs
Link only profiles that identify the same artist entity
Stops unrelated press, collaborators, playlists, or label pages from becoming identity claims.
Validation
Parse JSON-LD, run Schema Markup Validator, inspect rendered HTML, and test only supported Google features
Separates valid vocabulary from search-feature eligibility.
Owner
Record the template, page, source of truth, last check, and triggers for revalidation
Keeps the graph aligned after releases, renames, and URL changes.
Valid schema is not a search promise
Google requires structured data to represent the page and does not guarantee a rich result even for supported features. MusicGroup, MusicAlbum, and MusicRecording are Schema.org vocabulary, not currently documented dedicated Google rich-result types.
verify the release identifiers before publishing them in the graph
Which sources define the artist schema specification?
Frequently asked questions
Which schema type should a musician use?+
Use Person when the page describes a real solo person and MusicGroup when it describes a band or performing group. Model the website separately as WebSite. Use MusicAlbum and MusicRecording only on pages that accurately describe those entities, and connect repeated artist references with the same stable @id.
Does Google support MusicGroup rich results?+
Google's current structured-data feature gallery does not document a dedicated MusicGroup, MusicAlbum, or MusicRecording rich result. Schema.org defines the vocabulary, and accurate markup may help machine understanding, but valid music JSON-LD does not create eligibility for an undocumented search feature or guarantee any visible enhancement.
What should go in an artist sameAs list?+
Use URLs that unambiguously identify the same artist entity, such as official DSP or social profiles. Do not treat sameAs as a general links page, press archive, playlist list, label roster, or collaboration list. Every URL should resolve to the same real-world artist represented by the node.
Should an artist include an ISRC in structured data?+
Schema.org MusicRecording supports isrcCode. Include it only when the track page identifies the exact recording, the code is accurate, and public display fits the site's policy. Do not infer an ISRC, reuse one across different recordings, or publish an identifier the artist has not verified.
How should artist structured data be tested?+
Parse the JSON-LD, validate Schema.org vocabulary, compare every value with the visible page, confirm canonical URLs and stable IDs resolve as intended, inspect the rendered HTML, and test supported Google features only with their documented tools. Recheck after releases, renames, URL changes, or template updates.
Get better release strategy in your inbox
Release planning checklists, royalty explainers, and artist strategy notes from Velveteen. No daily noise.
Was this useful? Send a signal or flag a correction.
Keep reading
Pillar guide
Artist websites and music SEO
A six-page owned-site system with a crawl and index gate, artist identity signals, press delivery, conversion evidence, and a 30-day launch loop.
Related guide
Music SEO for an artist name
A four-layer artist-name diagnosis for collisions, home-page signals, official-profile consistency, indexed canonicals, and branded versus non-branded evidence.
Pillar guide
Release metadata guide
What metadata is, the ℗ vs © copyright lines, ISRC vs UPC, and the title and credit rules that decide whether your release is accepted and your royalties reach you.
Check your metadata before your distributor does
Run your titles, credits, copyright lines, and ISRC and UPC codes through the free checker and catch the rejection-bait errors before you upload. It all runs in your browser.