Read the link tag in your own feed
Get your feed address first. If you're hosted with Spotify for Creators, it's under Settings, then Availability, in the section headed RSS Distribution, though 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, because that tag is supposed to hold your feed's own XML address, and it isn't the one being checked here. Then open the address inside the plain one. 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, not by editing the feed by hand, because a hosted feed is generated from your show settings and the settings field is what actually controls the tag. Can't find the field? Ask the host. That's 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, and the box at Podbase Podcast Validator reads Enter podcast RSS feed URL, so paste your address, run it, and read the warnings yourself before Apple reads them for you.
A clean report isn't 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 get 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. Apple's list never mentions the link tag at all.
Spotify's list is shorter and 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. Language and itunes:explicit are marked optional, the reverse of Apple, and 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. You can reach the document 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, not 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 submit it. That's the last check worth running. 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 isn't on that list, while 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 and no podcast box in the results to win, and the listening apps run their own internal search, which 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, so 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 too, so no podcast surface is left for a website to feed, though ordinary markup describing your organization and your pages still does its job. Only the podcast-specific type 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, since 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, so go back up to the two lists, work out which tag is empty, and hand your host its name.