Two Albums, Back to Back
In June 2026 I put out two albums back to back. Flight to Vegas first, R2S Greatest Hits right behind it. Two full albums live on streaming, no label, no team.
Here's what nobody tells you about a release like that: the upload is the easy part. Your distributor takes the files, the albums appear, and it looks done. What actually decides whether those albums compound or quietly rot is everything around the audio - the metadata, the identifiers, the pages, the entity records that tell every store, search engine, and AI model on Earth who made this and where the canonical version lives.
I ran the release like a data-integrity operation, and I found real problems in my own catalog while doing it - a forked artist page, duplicate ISRCs, lyrics I didn't control. This is the checklist, in the order I'd run it again. Every step is something I actually did for these two albums.
Step 1: Lock Your Artist Name - Byte for Byte
My artist name is Daj' - with an apostrophe. Auditing my catalog after the drop, I discovered that some of my older releases had been delivered with a curly apostrophe (the typographic U+2019 glyph) while the canonical releases used a straight one ('). To a human, identical. To a store's matching system, two different strings - which means two different artists.
The result: duplicate artist pages on streaming stores, with a couple of my own albums stranded on fork pages my actual fans would never find. Streams split, profile authority split, discography incomplete on the page that matters.
The fix was almost insulting in its simplicity: one distributor ticket. Pick a canonical spelling - I chose the straight apostrophe - and ask the distributor to normalize the artist credit and re-point the stranded releases to the canonical artist page. One ticket. But I only knew to file it because I audited the name byte by byte instead of trusting that the stores had it right.
The checklist item: before anything ships, confirm your artist credit is byte-exact identical across the new delivery and your existing canonical store pages. Apostrophes, accents, capitalization, spacing. If your name contains any punctuation at all, this is where forks are born.
Step 2: Pull the Authoritative Tracklist from the iTunes Lookup API
Once the albums were live, I needed the official tracklists - titles, order, durations - to build everything downstream. Do not scrape the Apple Music web page for this. The page lazy-loads tracks with JavaScript, so a scrape gets you a partial or empty list and you won't notice until something breaks.
The right tool is the iTunes lookup API, which is free, public, and requires no key:
https://itunes.apple.com/lookup?id=<albumId>&entity=song&limit=200
That returns clean JSON: every track name, track number, and duration in milliseconds, exactly as delivered. It also returns the artwork URL - and here's a trick worth stealing: the API gives you a 100x100 thumbnail path, but if you swap 100x100bb for 1200x1200bb in the URL, you get full-resolution cover art from the same CDN.
One more detail that loops back to Step 1: the API returns apostrophes curly. If your canonical name uses a straight apostrophe, normalize what comes back before you reuse it anywhere. The store data itself will happily re-infect your pipeline with the exact glyph problem you just fixed.
For R2S that meant the full tracklist captured in one API call, in canonical order, with durations - the single source of truth for every step below.
Step 3: Give Each Album a Page You Own, with MusicAlbum Structured Data
Both albums got dedicated pages on my own domain: /music/project/flight-to-vegas and /music/project/r2s-greatest-hits. Not link-in-bio pages on someone else's platform - real pages, on a domain I control, each carrying MusicAlbum structured data (JSON-LD) built from the Step 2 tracklist.
The schema does real work: it declares the album name, the artist, the datePublished, every track as a MusicRecording, and - critically - sameAs links pointing at the album's store pages. That's how Google and every AI system learns that the page on my site, the Apple Music album, and the Spotify album are the same object.
One rigor rule I enforce: sameAs on an album only ever points to album-level store URLs. When R2S landed on Spotify, its page got the Spotify album link. Flight to Vegas hadn't landed on Spotify yet at launch - so its page links Spotify at the artist level as a call-to-action only, and asserts nothing false in the schema. Never claim an album lives somewhere it doesn't just to fill out a link row. Search engines remember lies.
Step 4: Audit Your ISRCs Before You Re-Deliver Any Master
A greatest-hits compilation is an ISRC minefield, and R2S taught me this the hard way. The ISRC is the identifier that routes royalties to a recording. The rule: one master, one ISRC, forever. But if the same master gets delivered twice - once on its original release, again on a compilation - a lazy pipeline will mint a fresh ISRC for the second delivery.
Now the same recording exists as two "different" recordings. Royalties split across two identifiers. YouTube Content ID sees two competing claims on identical audio and starts fighting itself. Your streaming counts fragment. Nobody emails you about any of this - it just silently leaks money.
When I audited my catalog after the release, I found exactly this: recordings carrying duplicate ISRCs because the same master had been delivered on more than one release. Contained, fixable - but only because I looked.
Here's how to look without begging your distributor for a spreadsheet: the Deezer public API returns the ISRC for any track, no authentication required. api.deezer.com/track/{id} includes an isrc field; search your catalog, walk your albums, and build an ISRC master list. Any title that appears with two codes is a conflict to raise with your distributor - ask them to reuse the original ISRC on re-deliveries.
The checklist item: before a compilation ships, hand your distributor the existing ISRCs for every previously released master on it. Re-use, never re-mint.
Step 5: Build the Entity Graph - Wikidata and MusicBrainz
This is the step most independent artists skip, and it's the one that makes machines treat you like an established artist instead of a string of characters.
After these albums dropped, I created Wikidata items for both - declaring the artist, the release date, and the store album IDs where each album actually lives (R2S carries its Apple Music and Spotify album IDs; Flight to Vegas carries only its Apple Music ID, because it isn't on Spotify) - and MusicBrainz release groups for both, seeded with the exact tracklists from the iTunes API in Step 2. Then I cross-linked everything: the Wikidata items point at the MusicBrainz release groups, my artist entity carries identifiers for Apple Music, Spotify, YouTube, SoundCloud, Deezer, and MusicBrainz, and the album pages on my own site backlink the Wikidata items through their sameAs.
The result is a closed loop - Apple <-> Spotify <-> Wikidata <-> MusicBrainz <-> my domain - every node confirming every other node. When a search engine, a smart speaker, or a language model asks "who is Daj' and what is R2S Greatest Hits?" - the answer is machine-readable, consistent, and sourced from records I created. This is also your structural defense against the Step 1 problem: a fork can't establish itself when the entity graph unambiguously says which artist page is canonical.
It costs nothing but an evening. Wikidata and MusicBrainz are free and open. The iTunes API tracklist means you're not typing tracklists in by hand.
Step 6: Own a Verified Lyrics Archive
Lyrics sites will transcribe your album whether you participate or not - badly, by strangers, on pages that outrank you for your own bars. So I published the lyrics myself, at /lyrics, with annotations building out at /genius.
The pipeline: transcribe from the actual masters with Whisper for a timed first draft, then hand-correct every line against the audio - the artist confirming the artist's words. Never invent a bar; a line I can't confirm gets flagged, not guessed. The R2S tracks I've personally reviewed carry a verified badge. Lyrics imported from third-party sources are labeled honestly as catalog imports, not verified - because a provenance badge only means something if you refuse to counterfeit it.
Why this belongs in a release checklist instead of an "eventually" pile: release week is when search demand for your lyrics spikes. If your verified page exists on day one, it's the page that gets indexed and cited. If it doesn't, a scraper's guess becomes the record. I've written a full breakdown of the archive philosophy here.
Step 7: Ping IndexNow - Hours, Not Weeks
You built album pages and lyrics pages. Now tell search engines they exist, because waiting for a crawler to wander by can take weeks - an eternity when release-week attention is measurable in days.
IndexNow is the free protocol for this. You host a small key file at your domain root, then POST your new URLs to the IndexNow endpoint. Bing and Yandex (and everything downstream of them) pick pages up in hours. I fired the ping for each page as it went live: both album pages were submitted the day they published, and every lyrics page got pinged the day it went live.
It's maybe twenty lines of code or a plugin, and it converts "the internet will eventually notice" into "the internet was notified."
Step 8: Re-Verify Against the Live Stores a Week Later
Last one, and it's the discipline that catches what everything else misses: after the dust settles, check the live store state - not your distributor dashboard, the actual public pages and APIs.
That verification pass is how I caught that Flight to Vegas had landed on Apple Music but the Spotify delivery hadn't arrived - a real distribution gap I could only chase because I looked. It's how the ISRC duplicates surfaced. It's how the apostrophe fork was pinned down to the exact character. Dashboards tell you what was sent. The stores tell you what exists.
Trust nothing you haven't re-queried. Then fix it while the release is fresh, not three years later when the royalties have already leaked.
The Whole Point
None of this required a label, an API budget, or anyone's permission. One artist, two albums - and a catalog that came out the other side with cleaner identifiers, a stronger entity graph, and more owned pages than it had going in. That's the actual job of a release: the music does the art, the checklist does the compounding.
FAQ
Do I really need my own album pages if the music is already on Spotify and Apple Music?
Yes. Store pages rank for your name at the platform's pleasure and tell search engines nothing you control. A page on your own domain with MusicAlbum structured data is the one node of the graph you fully own - and it's where the sameAs links live that stitch every store page into a single entity.
What causes duplicate artist pages on streaming services?
Metadata mismatches in the artist credit - most often invisible ones. In my case a straight apostrophe versus a curly apostrophe in "Daj'" was enough to fork my artist pages across stores. Stores match on exact strings, so any variation in punctuation, spacing, or accents across deliveries can create a second artist. The fix is one distributor ticket to normalize the name and re-point the stranded releases.
How do I check my ISRCs without access to a distributor spreadsheet?
The Deezer public API returns the ISRC for any track with no authentication: api.deezer.com/track/{id} includes an isrc field. Walk your own albums and tracks through it, build a list, and look for the same title carrying two codes - that's a duplicate to raise with your distributor before it splits royalties or triggers Content ID conflicts.
Is the iTunes lookup API free, and why not just copy the tracklist from the Apple Music page?
It's free and needs no API key: itunes.apple.com/lookup?id=<albumId>&entity=song&limit=200. The web page lazy-loads its tracklist with JavaScript, so scraping it silently returns incomplete data. The API gives you every track name, number, and duration as delivered - plus the artwork URL, which serves full resolution if you swap 100x100bb for 1200x1200bb.
What is IndexNow and does it actually matter for a music release?
IndexNow is a free protocol for telling search engines about new or changed URLs the moment they publish: host a key file on your domain, POST your URLs, done. For a release it matters because lyric and album searches spike in the first days - IndexNow gets your owned pages discovered in hours instead of waiting weeks for a crawl, so your pages are the ones in the index when the demand hits.