Feed-Validierung: Die typischen Fehler und wie unser Team sie löst

Es war einer dieser Abende, an denen die Bürotür schon lange geschlossen war, aber der Bildschirm noch hell leuchtete. Ein Kunde aus dem Umfeld des Hamburger Sendezentrums hatte uns einen Feed geschickt, der auf den ersten Blick perfekt aussah. Sauber strukturiert, alle Episoden an Bord, das Artwork gestochen scharf. Doch unser Firtz-Validator schlug erbarmungslos Alarm. Was folgte, war eine mehrstündige Detektivarbeit, die uns einmal mehr vor Augen führte, dass selbst erfahrene Podcaster über dieselben Stolpersteine stolpern. Ein fehlender Schrägstrich in der Enclosure-URL, ein winziger Syntaxfehler im XML – Kleinigkeiten, die einen Audiopodcast komplett aus der Distribution kippen können. An diesem Abend lernten wir als Team eine Lektion fürs Leben: Validierung ist kein lästiger Pflichtschritt, sondern die Lebensversicherung eures Podcasts.

Warum die Feed-Validierung im Podcast Publishing so entscheidend ist

Ein invalider RSS-Feed ist wie ein Radiosender, der auf der falschen Frequenz sendet. Eure Inhalte mögen brillant sein, aber sie erreichen niemanden. Im schlimmsten Fall blockiert ein fehlerhafter Feed die Auslieferung an Spotify und Apple Podcasts vollständig. Auch das deutsche Sendezentrum, die zentrale Anlaufstelle für deutschsprachige Podcaster in Hamburg, betont in seinen Workshops immer wieder, dass die technische Basis stimmen muss, bevor man an Reichweite denken kann. Bei Firtz setzen wir deshalb auf strenge Prüfungen, die weit über das oberflächliche Abhaken von Kriterien hinausgehen. Wir wollen nicht nur Fehler finden, sondern sicherstellen, dass eure Hörerinnen und Hörer jede Folge ohne Unterbrechung genießen können. Der RSS-Feed teilt den großen Plattformen mit, welche Episoden existieren, wie sie heißen, wann sie erschienen sind und wo die Audiodatei liegt. Fehlt nur ein einziges Pflichtfeld oder ist die Struktur nicht wohlgeformt, kann der gesamte Katalog unsichtbar werden. Unser Dashboard zeigt euch frühzeitig Warnsignale: Bleibt die Episodenzahl plötzlich stehen? Taucht im Sendezentrum-Log eine kryptische Fehlermeldung auf? All das übersetzen wir in verständliche Hinweise, damit ihr gezielt reparieren könnt.

Fehlerhafte oder fehlende Mediendateien – der Klassiker

Wenn wir im Team die häufigsten Support-Tickets durchgehen, landen wir fast immer bei diesem Thema: Die Audiodatei ist nicht erreichbar. Oft hat unser Team stundenlang nach einem Tippfehler in der mp3-URL gesucht, der sich als fehlender Bindestrich oder ein falscher Unterordner entpuppte. Kaputte Permalinks, falsche Enclosure-URLs oder inkorrekte MIME-Types machen euren Audiopodcast unspielbar. Die gute Nachricht: Diese Fehler sind fast immer hausgemacht und deshalb mit etwas Sorgfalt leicht zu beheben. Für MP3-Dateien muss zwingend audio/mpeg im Enclosure-Tag stehen. Wir sehen immer wieder Feeds, die audio/mp3 oder gar application/octet-stream ausliefern. Unser Firtz-Validator prüft nicht nur den deklarierten MIME-Type, sondern auch den tatsächlich vom Server gesendeten Header. Zusätzlich testen wir Byte-Range-Requests, die für Apple Podcasts zwingend erforderlich sind, um Streaming und nahtloses Vor- und Zurückspulen zu ermöglichen. Gerade bei selbst gehosteten Setups auf deutschen Servern sehen wir oft, dass diese Funktion nicht aktiviert ist.

Probleme mit der Episoden-Struktur und den Metadaten

Metadaten entscheiden darüber, ob eure Episoden in der richtigen Reihenfolge erscheinen oder ob sich ein ganzer Katalog dupliziert. Unser Team erinnert sich an einen besonders kniffligen Fall aus dem Sendezentrum, bei dem ein Podcaster versehentlich identische GUIDs für verschiedene Episoden verwendet hatte. Das Ergebnis: Apple Podcasts zeigte jede Folge doppelt an. Die GUID ist die eindeutige Kennung einer Episode. Viele denken, es sei einfach die URL zur Mediendatei, doch das ist ein gefährlicher Irrglaube. Ändert sich die Datei-URL, gilt die Episode plötzlich als neu. Wir empfehlen, als GUID den Permalink der Episodenseite zu verwenden. Auch das PubDate muss dem RFC-2822-Format entsprechen. In der DACH-Community sehen wir häufig abweichende Formate oder vergessene Zeitzonenangaben. Ohne gültiges PubDate sortieren Podcast-Clients die Episoden willkürlich. Firtz prüft deshalb diese Felder konsequent auf Konsistenz.

Das Cover-Artwork und die iTunes-Namespaces

Apple hat sehr genaue Vorstellungen davon, wie ein Podcast-Cover auszusehen hat: mindestens 1400×1400 und maximal 3000×3000 Pixel, die Dateigröße darf 500 KB nicht überschreiten. Wer diese Regeln missachtet, riskiert, dass der gesamte Audiopodcast im Apple-Ökosystem abgelehnt wird. Wir erleben oft, dass Podcaster riesige TIFF-Dateien einbinden, die den Feed aufblähen. Ein komprimiertes JPEG mit 1400×1400 Pixeln und rund 300 KB erfüllt alle Anforderungen und lädt schnell. Bei Firtz validieren wir nicht nur die Pixelmaße, sondern auch die itunes:summary, itunes:author und itunes:image-Tags. Zudem halten wir unseren Validator stets auf dem aktuellen Stand der offiziellen Apple-Spezifikation und gleichen eure Kategorien mit der gültigen Liste ab, damit euer Podcast nicht in einer nicht mehr existierenden Rubrik verschwindet.

SSL-Zertifikate und Server-Konfiguration für den Feed

Unser Team teilt die Frustration über gemischte Inhalte und fehlerhafte Weiterleitungen. Ein Podcast-Feed, der selbst per HTTPS ausgeliefert wird, aber auf HTTP-Episoden-URLs verweist, erzeugt Mixed-Content-Warnungen und wird von modernen Clients blockiert. Gerade in der deutschen Podcast-Landschaft sehen wir häufig Setups, bei denen Let’s Encrypt für gültige SSL-Zertifikate genutzt wird – eine solide Basis, aber die Konfiguration muss durchgängig sauber sein. Unser Firtz-Validator scannt sämtliche URLs im Feed und meldet jede einzelne, die nicht mit dem Protokoll des Feeds übereinstimmt. Auch zu aggressives Caching kann dazu führen, dass neue Episoden stundenlang nicht in den Verzeichnissen auftauchen. Wir prüfen die von eurem Server ausgelieferten Header wie Cache-Control und ETag und geben Empfehlungen zur Optimierung der Aktualisierungsintervalle.

Unser Workflow zur Fehlerbehebung mit Firtz

Im Laufe der Jahre hat sich bei uns ein pragmatischer Dreischritt etabliert, den wir jedem Podcaster ans Herz legen:

• Firtz-Validator nutzen: Unser Tool analysiert den Feed auf podcast-spezifische Fehler und gibt menschenlesbare Hinweise mit konkreten Korrekturvorschlägen.
• Logs im Sendezentrum prüfen: Die detaillierten Protokolle zeigen serverseitige Auffälligkeiten und helfen, Probleme bei der Auslieferung einzugrenzen.
• W3C-Validator gegenchecken: Als markenunabhängiges Prüftool testet er die allgemeine XML- und RSS-Konformität und ergänzt unsere Ergebnisse.

Wichtig ist uns dabei ein eiserner Grundsatz: Wir testen niemals im Live-System. Jede Änderung wandert zuerst in einen Staging-Feed, den wir gefahrlos durch unsere Prüfwerkzeuge jagen können. Unser Validator liefert keine kryptischen Codes, sondern zeigt genau an, in welcher Zeile des XML der Fehler steckt und schlägt konkrete Korrekturen vor. Nicht jede Warnung ist ein Showstopper. Fehlende optionale Tags wie itunes:keywords mögen gelb aufleuchten, verhindern aber nicht die Auslieferung. Echte Fehler hingegen – etwa ein nicht erreichbarer Server oder ein ungültiges XML – müssen sofort behoben werden. Wir haben die Ausgaben unseres Tools bewusst in diese zwei Kategorien getrennt, damit ihr Prioritäten setzen könnt.

Eine saubere Feed-Validierung ist kein Hexenwerk, sondern eine liebevolle Routine, die euren Audiopodcast für die Hörer im gesamten deutschsprachigen Raum zuverlässig macht. Mit den richtigen Werkzeugen und einem wachsamen Blick auf die Details stellt ihr sicher, dass jede Episode genau dort ankommt, wo sie hingehört: in den Ohren eurer Community.

Häufig gestellte Fragen

Warum schlägt der Firtz-Validator Alarm, obwohl mein Feed in Apple Podcasts funktioniert?

Apple Podcasts ist oft toleranter als andere Verzeichnisse. Ein Fehler, den Apple stillschweigend ignoriert, kann bei Spotify oder Podcast Addict zu Problemen führen. Unser Validator prüft streng nach den offiziellen RSS- und Apple-Spezifikationen, um plattformübergreifende Kompatibilität sicherzustellen.

Welche Bildgröße ist für mein Podcast-Cover wirklich optimal?

Apple verlangt mindestens 1400×1400 und maximal 3000×3000 Pixel. Wir empfehlen 3000×3000 Pixel für gestochen scharfe Darstellung auf Retina-Displays, aber mit einer Dateigröße unter 500 KB. Ein gut komprimiertes JPEG erreicht diese Balance problemlos.

Kann ich meinen Feed auch ohne SSL-Zertifikat betreiben?

Technisch möglich, aber nicht ratsam. Die großen Plattformen bevorzugen HTTPS-Feeds, und viele Clients warnen vor unsicheren Verbindungen. Let’s Encrypt wird von vielen deutschen Podcastern für gültige SSL-Zertifikate genutzt – eine kostenlose und unkomplizierte Lösung.

Wie oft sollte ich meinen Feed validieren lassen?

Mindestens nach jeder größeren Änderung: neue Episoden, Wechsel des Hosters, Anpassungen am Artwork. Wir empfehlen eine monatliche Routineprüfung, denn auch serverseitige Änderungen können unbemerkt Fehler einschleusen.

Was tun, wenn der W3C-Feed-Validator andere Ergebnisse zeigt als der Firtz-Validator?

Der W3C-Feed-Validator dient als zusätzliches, markenunabhängiges Prüftool, das allgemeine XML- und RSS-Standards testet. Unser Firtz-Validator geht darüber hinaus und prüft podcast-spezifische Anforderungen wie Byte-Range-Requests und Apple-Namespaces. Unterschiede sind normal und helfen euch, das vollständige Bild zu sehen.