Read the link tag in your own feed
Get your feed address first. Hosted with Spotify for Creators, it's under Settings, then Availability, in the section headed RSS Distribution, and Spotify notes you won't see that section until you've published your first episode. On any other host, Spotify's own instruction is the right one: contact them and ask for it.
Open the feed address in a browser and search the page for the word link. The one that counts is the plain <link> element at the channel level, above your episodes. If you hit an <atom:link rel="self"> first, skip it: that tag is supposed to hold your feed's own XML address, and it is not the one being checked here. Then open the address inside it. If it loads a page a human can read, whether that's your own site or the landing page your host publishes, you're already compliant and there is nothing to do here today.
If it loads raw XML, a parked domain, or nothing, that's the one thing on this page worth fixing now. Fix it in your host's show settings rather than by editing the feed by hand, because a hosted feed is generated from your show settings, so the settings field is the thing that actually controls the tag. If you can't find the field, ask the host, which is the same answer Apple gives: your hosting provider should be able to help you address technical requirements.
Run the feed through the validators Apple names
Apple names two outside tools on its own validation page, and both take a feed address and nothing else. Cast Feed Validator puts a single box on its front page. The box at Podbase Podcast Validator reads Enter podcast RSS feed URL. Paste, run it, and read the warnings yourself before Apple reads them for you.
A clean report is not an approval, and Apple says so in two sentences on the validation page: passing validation doesn't necessarily mean your podcast will be approved. All content must comply with our content guidelines. Validation there is strictly a technical evaluation. A show can pass every check on this page and still be turned down on content.
Ship both required lists, because they don't match
Apple's validator names what it rejects on, in its own error text. Your feed must contain a title. There is no description tag in your feed, or the description tag is empty. There is no language tag in your feed, or the language tag is empty, and it wants a supported ISO value. There is no explicit tag in your feed, or the explicit tag is empty, and it wants true or false. There is no category tag in your feed, or the category tag is empty. That's five tags at the show level, and Apple's list never mentions the link tag at all.
Spotify's list is shorter, different, and the link tag is on it. Its delivery specification marks title, link, description and itunes:author as exactly one each, so all four are mandatory there, while language and itunes:explicit are marked optional, which is the reverse of Apple. Spotify writes that categories aren't mandatory for ingest, though it uses them for recommendations. Every episode needs a guid and a pubDate, one each. The document is reachable through Spotify's podcast specification doc page.
Ship the union and stop thinking about it: title, link, description, language, explicit, author and category at the show level, then a unique enclosure and a permanent globally unique identifier on every episode, both of which Apple requires by name. One trap is left. Apple's categories are case-sensitive, so Kids & Family passes and Kids & family fails on that one letter, and an ampersand inside a category name has to be escaped rather than typed raw.
Look at the show yourself before you submit
Apple lets you load the feed into the Podcasts app before anyone reviews it. On iOS: open Podcasts, tap Library, tap Edit in the upper right corner, then tap Add a Show by URL, enter your feed address and tap Follow. On macOS: open Podcasts, select File, then Add a Show by URL, enter the address and select Follow.
This publishes nothing. Apple's own wording is that adding a show by URL doesn't publish it to the Apple Podcasts directory. If the artwork appears and an episode streams, the feed is working and you can go and submit it. That's the last check worth running, and it costs you nothing.
Now decide about the site, on search alone
Nothing you add to a website changes your standing with either store. Apple's submission bar is an account, required tags, at least one episode and artwork, and a site is not on that list. Spotify publishes Spotify for Creators shows automatically. Every page you write past that point is for the open web, and the open web is the only place it can pay you back.
Your episode page competes as an ordinary web page, on ordinary merits. There's no format bonus for being a podcast, no podcast box in the results to win, and the listening apps run their own internal search that a website never touches. The two honest reasons to build are that you want the show findable outside the two apps, and that you want a page you can edit instead of a directory listing you can't.
If the thin page exists only to fill the link tag, leave it thin. The spec is indifferent to what loads there, neither platform documents a check on it, and pages nobody maintains earn nothing. Build when you're ready to publish something and keep publishing it. Until then, put the money into the show.
Don't pay anyone for podcast schema
The rich result that markup was sold on no longer exists. Google's developer page for podcast structured data now returns a 404, and Podcast doesn't appear in the current gallery of supported types, which runs from Article and Event through Product, Review snippet and Video. There is no podcast-specific result left to earn, so there's nothing to buy.
Any quote or article telling you to add Podcast markup so Google shows your episodes was written before that change. Google Podcasts as a destination is gone as well, so there's no podcast surface for a website to feed. Ordinary markup describing your organization and your pages still does its job. It's the podcast-specific type that stopped paying, and you should not be charged for it.
If you move the feed or the address later
Changing a feed address the wrong way loses your subscribers, and Apple documents the way that doesn't. Set the old feed's server to return an HTTP 301, put the new address in the itunes:new-feed-url tag inside the new feed, and per Apple's instructions keep both in place for at least four weeks. Ask your host whether they set the redirect for you before anyone touches a server; Apple's own line is that your hosting provider should be able to help you address technical requirements.
Don't let the episode identifiers change while you do it. Apple warns that altering a GUID can show listeners duplicate episodes, misrepresent your analytics, and ultimately affect your show's status on Apple Podcasts. Spotify's side of the same job is its Updating an RSS feed link or hosting provider article.
If Spotify shows you a missing elements error while you're uploading or claiming the show, its instruction is to contact your hosting platform and have them fill in what's absent. There's no appeal and no form to file. Go back up to the two lists, work out which tag is empty, and hand your host the name of it.