A player on the page, or a link to it
Embedding a player looks like the generous choice. On a phone it is often the worse one, and the reason has nothing to do with taste.
What an embed actually costs
An embed is not a picture of a player. It is a second web page loaded inside yours, with its own scripts, its own fonts and its own network requests. It arrives after your page does, so the layout settles late. On a slow connection the block sits empty while everything around it is already readable, and the rows below it shift down the moment the frame finally appears.
It also changes who the visitor is dealing with. The moment the frame loads, the service on the other side knows that this person opened your page, and it can recognise them if they are signed in there. You have quietly introduced a third party into something that was, until that moment, between you and your visitor. On a page whose whole appeal is being small and plain, that is a real trade.
What it buys, and for whom
The gain is genuine and worth naming. The visitor can press play without leaving: no app switch, no back button, no risk of losing the page. For a track you want heard right now, or a two-minute video that explains what you do, that immediacy is the entire point. Someone who has to make a second decision often does not make it.
The question is not whether that is valuable. It is whether it is worth paying for on every block, for every visitor, on every kind of device. Usually it is not, because the value sits in one item while the cost is spread across the whole page.
On a phone the app usually wins
A link that opens the real app is often the better outcome on a phone, and this is the part people get backwards. The app has the account. It has the library, the queue, the saved playlists, the subscription that removes the adverts, and the credentials that make a follow or a save take one tap. An embedded player has none of that. It is an anonymous window that plays one thing and then stops.
So a visitor who taps a link on a phone lands somewhere they can act. They can save the album, follow you, and keep listening after they close your page. The visitor who plays the same track inside a frame hears it and leaves with nothing changed.
In-app browsers make it worse
Much of your traffic arrives in the window that opens from Instagram or TikTok, and those windows handle frames poorly. Autoplay is blocked, audio sometimes fails without a message, and a full-screen tap can strand the visitor in a player with no obvious way back. The failure is quiet: nobody writes to tell you the player did not work. tapmy.link opens media in a new tab for exactly this reason, rather than loading a frame that may not run.
Embed the one thing the page is about
The rule of thumb fits in a line. Embed the single item the page exists for, and link everything else. A release page can carry one player. A general bio page usually carries none, because nothing on it is important enough to slow down the other fifteen blocks.
- Embed when the page has one purpose — a release, a trailer, an episode — and the media is that purpose.
- Embed when your audience is mostly on desktop, where the frame is cheap and there is no app to switch to.
- Embed at most once: a second player halves the first one.
- Link when the visitor has an account on that service and would rather be inside it.
- Link when the page is a hub and the media is one item among many.
- Link when most of your traffic comes from social apps and their in-app browsers.
Whichever you choose, write the label so the visitor knows what will happen. Listen on Spotify and Watch the trailer set the right expectation; a bare service name does not. A link that opens in a new tab also leaves your page where it was, so nobody has to find their way back to it.