Publishing an episode is not complete when the audio file leaves your editor. The episode still has to travel cleanly through your hosting provider, RSS feed, directories and podcast apps.

A good pre-publish routine catches the small failures that create listener friction: a stale title, missing episode art, an inaccurate transcript, a broken enclosure link or metadata that looks wrong on a phone. The aim is not to inspect every possible setting. It is to verify the handful of things most likely to affect whether a listener can understand, find and play the episode.

Use the checklist below for every regular episode. You can turn it into a copyable template for your team.

A copyable podcast pre-publish checklist

Complete the checks in order rather than jumping between your editor, host and distribution dashboard.

  • The final audio export is ready
  • Episode title and summary are accurate
  • Episode type, number and release date are set
  • A stable episode GUID is assigned
  • Show notes and links are checked
  • Transcript and chapters are reviewed
  • Episode artwork is attached and checked
  • Accessibility details are complete
  • The RSS preview matches the episode
  • The episode works on different devices and apps
  • A backup of the final package is stored
  • The episode is scheduled or published deliberately

The release order matters. Fix content and metadata first, upload the final asset second, inspect the generated feed third, and only then distribute or schedule the episode.

1. Confirm the final audio package

Begin with the episode master, not the latest rough mix.

Check that:

  • the recording is the intended final cut;
  • the beginning and ending contain no unwanted edits or long silent gaps;
  • the host, guests and any sponsor segments are present in the intended order;
  • music, clips and other borrowed material have the permissions your production requires;
  • the exported file opens and plays from start to finish;
  • the filename identifies the episode clearly enough for a human working in the hosting dashboard.

Listen through the full file at least once without editing it. Editing while checking can conceal an abrupt transition, a clipped word or a mistakenly retained take. If your workflow supports a separate master, approval and delivery file, use that distinction rather than uploading different mixes to different services.

Apple’s current creator documentation lists M4A, MP3, MOV, MP4 and M4V for episodes delivered through RSS. Other hosts or workflows may support additional formats, so check the requirements of the host and destination you actually use rather than assuming one format is universal.

2. Review episode metadata as a discovery layer

Episode metadata helps listeners decide whether to press play. Treat it as part of the episode, not as administrative data to fill in after upload.

Review these fields:

  • Title: Does it identify the actual subject without relying on context from a previous episode?
  • Description: Does it explain the episode’s premise and useful details without repeating the title word for word?
  • Episode type: Is this a full episode, bonus material or a trailer?
  • Episode number and season: Are these correct for your show’s system? If the show is serial rather than episodic, is the intended order clear?
  • Release date: Does it match the intended publication schedule and include the relevant time information?
  • Explicit-content setting: Does it accurately reflect the episode?
  • Language: Is the episode language set correctly?

Apple identifies itunes:type as either episodic or serial. Episodic shows usually place the newest episode first, while serial shows usually present episodes in narrative order. If you are just starting, choose the model that reflects how listeners should experience the show rather than copying another creator’s default.

Metadata quality can vary between feeds. A research review of podcast RSS metadata found that fields such as episode type, season number and category were not always used in the expected way, so do not assume that entering a value guarantees the intended presentation everywhere. Preview the result in the feed and at least one listening app.

3. Make show notes useful, not decorative

Show notes should help a listener understand what they will hear, find referenced material and decide whether to share the episode.

A practical structure is:

  1. A short episode summary
  2. Key topics or questions covered
  3. Links mentioned in the episode
  4. Credits, disclosures and relevant sponsor information
  5. A clear call to action, if one is appropriate

Check every link, especially shortened URLs and tracking links. Confirm that names, job titles, quotations and dates match the recording. If a guest mentioned a source, include the direct source when possible rather than sending listeners to a vague homepage.

Keep sponsor language separate from editorial copy. List what was provided, what was paid and any relationship that could affect the episode. If you use AI to help draft the description, retain a manual fact-check and disclosure step. The companion guide AI-Assisted Podcast Episode Descriptions: A Manual or Assisted Workflow? covers that source-grounded editing process.

4. Review the transcript for accuracy and usefulness

A transcript can support accessibility, search, episode summaries and listener navigation. It is not automatically a verbatim record just because software generated it.

Review the transcript for:

  • names, companies, products and technical terms;
  • false starts, repetitions and incomplete sentences;
  • timestamps that match the final edit;
  • speaker labels, where your delivery format uses them;
  • sections that should be removed because they contain sensitive, private or unreleased information;
  • a readable description of meaningful sound effects or visual-only references.

If you publish the transcript, make sure it corresponds to the final cut rather than an earlier edit. If your transcription tool inserts punctuation or labels, verify those decisions instead of treating the output as authoritative.

5. Check chapters against the final timeline

Chapters are useful when a listener can scan, return to a section or jump directly to a resource. They are misleading if a topic change, sponsor break or link appears at the wrong time.

For each chapter:

  • use a descriptive title rather than a vague label such as “Part one”;
  • confirm that the start time matches the final audio;
  • make sure the chapter contains meaningful material;
  • avoid excessive numbers of very short segments;
  • keep titles consistent with the show notes.

If chapters are generated from a transcript, compare them with the final timeline. If you need to build them from scratch, see How to Create Podcast Chapters: A Manual, Transcript or AI-Assisted Workflow.

6. Confirm artwork, title and episode art

Open the final episode page where the hosting provider displays it. Confirm that the episode is attached to the correct show and that its artwork is the intended image.

For episode artwork, check:

  • the image is not the previous episode’s artwork;
  • the file is large enough for the host and directories you use;
  • the design remains legible when reduced to a small thumbnail;
  • text is not so small that it disappears on a phone;
  • the file has no accidental crop that hides the title or guest name.

Apple’s documentation allows a 3000 × 3000 pixel image for episode art in Apple Podcasts Connect. Hosting providers and other directories may have different specifications, so use the requirements of the publishing route you choose.

7. Complete the accessibility pass

Accessibility is broader than attaching a transcript. Review whether a listener can understand and navigate the episode without seeing the studio or using a visual display.

For this episode, confirm that:

  • the transcript is present and accurate;
  • verbal references do not depend on “as you can see here”;
  • important visual or sound-only information is described;
  • links have meaningful text;
  • the title and description are understandable in plain language;
  • any accessible media the host offers is connected to the right episode.

Avoid relying on a generic accessibility badge as proof of a complete pass. A useful check is whether each piece of necessary information exists in the audio, transcript, notes or another accessible format.

8. Preview the RSS entry, not just the dashboard

Your hosting dashboard may display a polished form while the generated RSS entry contains missing or malformed information. Inspect the actual feed entry for the episode.

Look for:

  • the correct episode title and description;
  • the correct audio enclosure URL, length and MIME type;
  • a unique, stable episode GUID;
  • the intended publication date;
  • the correct episode image, if supplied;
  • any transcript or chapter fields you chose to publish;
  • properly formed links and characters.

Apple’s feed requirements call for a publicly accessible RSS 2.0 feed, correct XML namespace declarations, unique episode GUIDs and enclosures that include a URL, length and type. The feed URL must remain public and usable for streaming. These are feed-level requirements, not merely cosmetic metadata.

Do not create a second feed or change the show’s feed URL casually. A stable feed URL and stable episode identifiers help directories and listeners recognize the same show and episode. Apple also notes that episodes created through a third-party RSS feed cannot be updated in Apple Podcasts Connect; corrections generally need to be made through the hosting provider.

If the host provides a validation or preview tool, run it. If it does not, open the RSS feed in a feed validator and review the latest episode manually. For the cleanest result, update the feed after all episode fields are complete so that the preview represents the submitted version.

9. Verify the episode across devices and apps

Your editing computer is not a representative listener device. Before release, check the public episode page on a desktop and a phone, then play it in at least one podcast app.

Verify that:

  • the episode appears under the correct show;
  • playback starts without requiring a login;
  • the title, artwork, summary and date look correct;
  • the audio is the expected episode rather than a previous upload;
  • the transcript and chapters appear where the host promises them;
  • links open correctly;
  • the episode ordering is suitable for the show’s format;
  • the episode title is not truncated in a way that changes its meaning.

This is a smoke test, not a claim that every listening platform has been tested. Different apps can interpret optional metadata differently. Keep a small release log with the date, host version, editor version and any known platform-specific issue so that you can reproduce the setup later.

10. Publish deliberately and keep a recoverable copy

Choose between publishing immediately and scheduling. Scheduling is useful when you need coordinated promotion, but it should not hide an unfinished approval step.

Before clicking publish:

  • confirm the episode is public or scheduled at the intended time;
  • verify the date and time zone shown by the host;
  • save the final audio, artwork, notes, transcript and chapters in a dated backup folder;
  • record the public episode URL and the RSS entry;
  • note which hosting and distribution settings were used.

After publication, revisit the episode page once. Hosting dashboards can show a successful upload while the public page still displays an old image or incomplete description.

A simple release record for a small team

Use one record per episode so responsibility is clear:

Episode title:
Episode number / season:
Final audio filename:
Editor:
Metadata reviewed by:
Transcript reviewed by:
Chapters reviewed by:
Artwork checked by:
Feed preview checked by:
Cross-device test completed by:
Release date and time zone:
Backup location:
Public episode URL:
Notes:

For a solo creator, this doubles as a publish log. For a small team, it prevents the common assumption that someone else checked the transcript or feed.

Frequently asked questions

Should I publish the transcript if my host creates one automatically?\n

Treat an automatic transcript as a draft. Review names, terminology, timestamps and the final cut before relying on it as a public transcript. If the host labels it as complete, correct any errors you find.

Is an episode ready to publish as soon as the host says “upload complete”?

No. “Upload complete” confirms the transfer, not the listener experience. Inspect the public page, RSS entry and an actual podcast app first.

Do I need to submit the episode separately to every podcast directory?\n

Usually, a hosting provider generates the RSS feed and distribution systems use that feed. The submission and update process varies by platform, so confirm how your host handles new episodes and whether any directory requires separate action.

What should I fix first if an episode looks wrong after publication?\n

Start with the hosting provider. If the episode is delivered through RSS, Apple notes that it cannot be edited directly in Apple Podcasts Connect; the hosting provider is the source of the episode data.

The final rule: publish the listening experience, not just the file

The final pre-publish check is simple: can a new listener understand what the episode is, find the supporting information, navigate it and play it without friction?

If the answer is yes across metadata, audio, transcript, chapters, notes, artwork, RSS preview and a real device, the episode is ready for distribution.

Sources