To get a knowledge panel for a podcast, you need Google to recognize the show as a distinct entity, separate from its host, its network and every other show with a similar name. You do that by publishing the same core facts about the show in five places Google trusts, then waiting for its Knowledge Graph to reconcile them. There is no application form and no button to request a panel. Google decides, and your job is to make that decision easy.
The rest of this guide covers what the panel shows, the five sources I check for every show, the markup that ties them together, and what to do once the panel appears.
What does a podcast knowledge panel actually show?
Google describes knowledge panels as information boxes that appear when you search for entities in the Knowledge Graph: people, places, organizations and things. A podcast falls under things. To be exact, it is a creative work series, the same broad family that covers TV shows and book series.
When a show has its own panel, a search for its name returns a box on the right side of the results on desktop, or near the top on mobile. It usually carries the show’s cover art, a short description, the host or hosts, the launch date, the genre and links to where people can listen. Some panels also show a list of recent episodes or a link to the show’s YouTube channel.
The more common situation is worse, and most podcasters never notice it. Search the show name and Google shows the host’s personal panel, or the panel for the production company, or nothing at all. Sometimes it shows the panel for a book, a film or a band that shares the name. In each case Google has decided the show is not a separate thing worth describing, or it cannot tell your show apart from something it already knows.
That distinction matters more since Google Podcasts shut down in 2024 and pointed listeners toward YouTube Music. Google no longer runs a dedicated podcast directory that feeds it clean data about every show. It now leans on the open web, YouTube and structured sources such as Wikidata to understand what a podcast is. Shows that publish clean, consistent facts get described. Shows that rely on a feed alone get folded into their host.
There is also an AI search angle. The same entity understanding that powers the panel shapes how Google’s AI Overviews and other assistants describe your show. If the Knowledge Graph does not know your podcast exists as its own thing, an assistant asked for “the best podcasts about supply chain finance” has less reason to name it.
Google needs five sources that agree
I use a checklist with every show I work on that I call the Five-Source Lock. The idea is simple. Google gains confidence in an entity when several independent sources state the same facts in the same way. One source is a claim. Five matching sources are a fact. The lock closes when all five line up on the show’s exact name, its host, its launch year and its official website.
Source one is the show’s own website. Not a page buried inside the host’s personal site, but a home for the show at a stable URL, its own domain if you can. This becomes the canonical reference that every other source points back to.
Source two is Apple Podcasts. It remains the directory of record for the industry, and its show IDs appear in many databases, including by Wikidata. Your Apple listing title must match the website title character for character.
Source three is the rest of the listening platforms, with Spotify and YouTube at the front of the line. YouTube matters most here because Google owns it and because it is one of the accounts Google accepts for verifying a knowledge panel later.
Source four is Wikidata, the structured database that Google and most AI systems draw from. A Wikidata item for the show gives Google a machine-readable record with typed properties instead of prose it has to interpret.
Source five is independent coverage. Reviews, interviews, best-of lists and news stories from publications that have no stake in your success. This is the source that turns a self-described show into a show the rest of the world agrees exists.
Most podcasts I audit have two or three of these locked and the others broken in small ways. The Apple title has a subtitle the website does not. The Spotify listing names a co-host who left in season two. The website lists a launch year that differs from the first episode date. Each mismatch gives Google a reason to doubt, so fix them before you build anything new.
Build the structured data layer first
Start with the show website, because every other source will link to it. Add schema.org markup using the PodcastSeries type, which schema.org defines as an episodic series of digital audio or video files that a user can download and listen to. Put it in JSON-LD in the head of the show’s home page.
At a minimum, the markup should declare the show’s name, a description, the URL, the image used as cover art, the author or host as a Person with their own URL, the webFeed pointing to the RSS feed, and the start date. Then add a sameAs array listing the show’s Apple Podcasts page, Spotify page, YouTube channel and, once it exists, its Wikidata item. That sameAs list is the thread that ties the five sources together in a format Google reads without interpretation.
Give individual episode pages PodcastEpisode markup with a partOfSeries property pointing back to the series. That tells Google the episodes belong to one show and stops each episode page from looking like a separate, unrelated thing.
Next, create or improve the Wikidata item. Wikidata has notability rules, and a show with no independent coverage at all may be deleted, so do this after you have at least a couple of credible third-party mentions. Set the item as an instance of podcast. Add the official website, the host as a linked item if one exists, the language, the genre, the start date, and the identifiers for the major directories. Wikidata has a dedicated property for the Apple Podcasts podcast ID, P5842, and similar identifier properties exist for other platforms. Each statement should carry a reference, preferably to a third-party source rather than to your own site.
Last, put the Wikidata URL into the sameAs array on your website. The loop is now closed: the site points to Wikidata, Wikidata points to the site, and both point to the same directory listings.
A common mistake is building all of this for the host and none of it for the show. If the host is better known than the podcast, Google will default to the host unless the show has its own complete record. Treat them as two entities with two sets of markup that reference each other.
Why independent coverage is the source you cannot fake
The first four sources are within your control. You can build the website, fix the directory listings and write the markup in an afternoon. That is exactly why Google does not rely on them alone. Anyone can describe their own show. What Google wants is evidence that other people talk about it.
Independent coverage comes in a few forms. A review of the show in a trade publication for its niche. A feature about the host that names the podcast and describes it. A best-of list from a credible outlet. A news story that cites an episode as a source. Each one is a third party stating that the show exists, what it is about and who makes it.
Quality matters more than volume. Three pieces in publications with real editorial standards will do more for your entity than thirty mentions on podcast directory sites that list every feed automatically. When the coverage names the show exactly as it appears everywhere else and links to the official website, it reinforces the lock. When it uses a nickname, an old title or a link to the host’s personal site, it splits your signals.
This is the slowest part of the process and the one most podcasters skip. It is also where the work pays off twice. Coverage that helps Google recognize your show is the same coverage that persuades listeners, guests and sponsors to take it as a real show. If your show has been running for a while, look at what you already have: past guest appearances on other shows, mentions in newsletters, local press. Contact those outlets and ask them to use the show’s exact name and link to its official site. Small corrections to existing coverage are free and fast.
Claim the panel once it appears
When a panel finally shows up for the show’s name, claim it. At the bottom of the panel, click Claim this knowledge panel. Google will ask you to sign in with an account it can tie to the entity. Its help documentation lists options such as YouTube, Search Console and certain social profiles. For most podcasts the cleanest route is the show’s own YouTube channel or the Search Console property for the show’s website, which is one more reason to keep both under the show’s name.
Once verified, you can suggest changes to the panel directly and add other people from your team as authorized representatives. Suggestions are reviewed, not applied on the spot, and Google will still compare them against the sources it trusts. If you ask for a change your website and Wikidata do not support, expect it to be rejected. Update the sources first, then request the edit.
If the wrong panel appears, such as the host’s panel on a search for the show name, you cannot claim your way out of it. The fix is to strengthen the show’s own record until Google splits the two. Use the feedback link on the existing panel to report the mix-up, and keep building the five sources.
How long does this take, and what slows it down?
Expect weeks to months, not days. Google has to recrawl your website, process the Wikidata item, see the directory listings and find the coverage, then decide that all of it describes one thing. Shows with an existing audience and some press history tend to see a panel sooner. A brand new show with no coverage may need a full season before Google takes notice.
Three things slow the process more than anything else. The first is a name collision. If your show shares a name with something better known, Google needs far more evidence to separate them, and you may want to search the name before you launch, not after. The second is inconsistency, the mismatched titles and stale host names described above. The third is a show that lives only on a host’s personal site, with no home of its own for Google to anchor to.
The panel will not arrive on a schedule you set. What you can control is whether your five sources agree on the day Google comes looking.
Your next step is a single audit. Open a spreadsheet, list the five sources across the top, and list the show name, host, launch year and official URL down the side. Fill in exactly what each source says today, then fix every cell that does not match before you add anything new.