4 Antworten Auf Das RSS-Feed-Dilemma  ## Metadata - Author: [[Torsten Landsiedel]] - Full Title: 4 Antworten Auf Das RSS-Feed-Dilemma - Category: #articles - Document Note: --- tags: [RSS, WordPress, Feedreader] author: Torsten Landsiedel source: torstenlandsiedel.de reference: [https://torstenlandsiedel.de/2025/10/05/das-rss-feed-dilemma/] date created: 2025-10-27 00:00 --- # 🏷️ Title: 4 Antworten auf Das RSS-Feed-Dilemma ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened: The author outlines how modern WordPress blocks break in RSS because feeds lack CSS/JS, laments stagnation around RSS, and proposes practical fixes. - Why it matters: RSS remains an open, algorithm-free distribution channel; broken feeds erode the open web. - Key stakeholders: WordPress core/team, theme/plugin authors, publishers/bloggers, feedreader developers, readers. - Risks and tradeoffs: Feature-rich block UX vs. feed robustness; scraping risk; added complexity in feed standards support. - Bottom line: Treat feed context as first-class; add opt-outs for non-semantic blocks; improve media, discovery, and feedback integration. ## 📖 Main Content - Core issues: - “Basic problem #1: No CSS in the feed” → block columns/buttons/spacers render incorrectly; typography tweaks (drop caps, font sizes) lost. - “Basic problem #2: No Javascript in the feed” → interactive elements (e.g., “Load more”) fail. - Proposed solutions: - Disallow or selectively hide certain blocks in post/feed context; proof-of-concept plugin to exclude blocks from feeds. - Consider reader-side CSS mappings for common WordPress classes (author notes limited traction with NetNewsWire). - Improve discovery: restore visible RSS icons; style feed landing via XSL to explain RSS and link readers. - Enhance media via Media RSS (media:content) for featured images; needs WP and reader support. - Anti-scraping footer text like Yoast’s pattern as core capability. - Feedback loop: integrate comments or email notifications better from feeds. - Context: - RSS adoption waned post–Google Reader; social previews and sharing outpaced feed innovation. - Alternatives (ActivityPub/Webmentions/etc.) add complexity and new operational issues. ### 🗒️ Notes - “WordPress has… not only failed to improve the feed, but is actively breaking it.” - CSS absence → “columns are displayed at 100% width,” causing giant SVGs. - JS absence → “Load More” buttons nonfunctional in feeds. - Hide-from-feed PoC plugin lets authors remove non-semantic blocks from feed output. - Semantic HTML (e.g., blockquotes) degrades gracefully; DIV-based “buttons” collapse to links. - Reader-side CSS mapping proposed; inline styles sometimes work; most readers strip CSS. - Discovery: bring back visible RSS icons; XSL-styled feed pages to educate and link readers. - Media: support Media RSS for featured images; adoption “eher mäßig.” - Scraping: core should append provenance line akin to Yoast’s pattern. - Feedback: better tie-in with WP comments or email; dream: comment directly from reader. - Alternatives: ActivityPub introduces identity/notification pitfalls (e.g., viral post on blog profile). - Closing: Block editor drifted toward page-builder lock-in; open formats should be advanced. ## 📚 References - Hide-from-feed PoC (GitHub): https://github.com/Zodiac1978/hide-from-feed - Media RSS specification (media:content): https://www.rssboard.org/media-rss - NetNewsWire (reader cited): https://netnewswire.com/ - Yoast SEO RSS content settings: https://yoast.com/help/yoast-seo-rss-feed-settings/ - ActivityPub for WordPress: https://wordpress.org/plugins/activitypub/ - Roy Tanck on ActivityPub notifications issue: https://www.roytanck.com/ (search site for ActivityPub post) ## 🗣️ Paraphrase - A: WordPress blocks assume CSS/JS that feeds don’t provide, breaking layout and interaction in readers. - B: Revive RSS by treating feed context explicitly: hide unsuitable blocks, improve media, discovery, anti-scrape lines, and feedback hooks. ## 📰 Newsletter - RSS still rocks: open, algorithm-free, and reader-first. But modern blocks break without CSS/JS. Torsten proposes pragmatic fixes: hide non-semantic blocks in feeds, add Media RSS for featured images, bring back visible RSS icons with XSL-styled landing, and ship an anti-scrape footer in core. Feedreader devs: consider CSS class mappings. WP folks: small changes, big wins for the open web. ## ✅ Action Items #### DevRel - Publish guide: “Designing WP blocks for feed fallback.” - Demos: hide-from-feed plugin + Media RSS featured images. - Collect developer feedback from theme/plugin authors. #### OSPO - Recommend open feed extensions (MRSS) and provenance text policies. - Compliance review for feed output licensing/attribution. #### Community - Maintain “feed-friendly blocks” checklist. - Run “Bring back the RSS icon” campaign. #### WordPress - Core: feed-context API to conditionally omit blocks. - Core Performance: ensure feed generation fast and lean. - Core AI: none. - Core Program Team: coordinate MRSS and comment-feed UX proposals. - Playground: reproduce feed rendering with block fallbacks. - Community: docs on RSS discovery + XSL templates. - Training: lesson “RSS-friendly content patterns.” - Marketing: highlight RSS as “small, local, unidirectional fediverse.” - Support: KB on fixing broken feed layouts. - Design: default styles that degrade gracefully to semantic HTML. - Documentation: codex for feed-context best practices. - Accessibility: ensure feed/XSL pages are accessible. - Meta: .org handbook section on MRSS and provenance lines. - Plugins: review guidelines for feed output safety. #### The WPCC - Fund MRSS core patch and reader-collab prototypes. - Sponsor “feed refurb” sprints. ### FAIR - Technical independence: provenance lines, signatures for feed items. - Policies: transparency on syndication; anti-capture commitments. - Governance artifacts: feed-quality scorecards for themes/plugins. ## 🧪 Hypotheses - Adding a feed-context API reduces broken layouts in >80% of feeds using blocks. - MRSS featured images increase feed click-through by ≥10%. - Visible RSS icons + XSL landing raise subscriptions by ≥20%. - Provenance footers decrease full-content scraping reposts by ≥30%. - Reader-side CSS mapping cuts rendering anomalies by ≥50%. ### 📊 Methodology - A/B test feeds with/without MRSS and provenance lines; measure CTR and scraping detects. - Plugin telemetry (opt-in) on block omissions vs. validation errors in feeds. - Survey feedreader developers on CSS class support feasibility. - Time-series analysis of subscription rates post–RSS icon/XSL rollout. ### ❓ Questions - Which blocks most frequently break in feeds? - Can core expose a standard “exclude-from-feed” block attribute? - What minimal MRSS subset yields the biggest value? ### 🔮 Future Research - Comment sync from readers via WebSub/Webmention bridges. - Lightweight signing/attestation for feed items. - Auto-generated semantic fallbacks for common non-semantic blocks. ### 💡 Implications - Practice: authors choose feed-safe patterns. - Policy: provenance defaults in CMS. - Security: signed feeds deter tampering. - Education: reintroduce RSS literacy. ### 🧠 Learning Styles Assessment - Reading level: ~10–11th grade (Flesch-Kincaid estimate). #### 👀 Visual learners - Improve: diagrams of feed flow, block→fallback mapping. #### 🔊 Aural learners - Improve: 3-minute audio summary. #### 🗣️ Verbal learners - Present: clear definitions; add glossary of feed extensions. #### 🧩 Kinesthetic learners - Improve: lab to enable MRSS and test readers. #### 🧠 Logical learn - Summary: Um die Jahrtausendwende startete der RSS-Feed und im Zuge von Web 2.0 hat er in den folgenden Jahren immer mehr … Weiterlesen → - URL: https://torstenlandsiedel.de/2025/10/05/das-rss-feed-dilemma/ [RSS feeds](https://de.wikipedia.org/wiki/RSS_(Web-Feed)) began around the turn of the millennium , and with the rise of Web 2.0, they became increasingly widespread in the years that followed. However, because they were difficult to monetize, key products like [Google Reader](https://de.wikipedia.org/wiki/Google_Reader) were discontinued. [Feedburner,](https://de.wikipedia.org/wiki/FeedBurner) the feed optimizer acquired by Google , is also neglected. For many older Internet users, the RSS feed, like email and Usenet, may no longer be particularly popular, but it is still an important tool and [indispensable](https://daveverse.org/2025/09/27/rss-is-permanent/) . Unfortunately, WordPress has forgotten its roots and has not only failed to improve the feed, but is actively breaking it. A report on the problems and possible solutions. I first noticed the problem when I was browsing a colleague's blog in my feed reader and was surprised to see that the icons were so huge. At first, I thought it was a problem with the display of SVG images. But I also noticed errors in the feed on a blog belonging to a large WordPress agency, so I started looking for the cause. #### Basic problem #1: No CSS in the feed The problem on my colleague's blog was that the icons were arranged in four columns. Now, columns in WordPress blocks are implemented using CSS. However, CSS isn't included in the feed. Therefore, the columns are displayed at 100% width, which caused the SVG icons to be displayed full screen. Giant icons in the RSS feed This doesn't just apply to columns, of course, but also to all other blocks that only work correctly with CSS. For example, buttons, spacers, ... and probably a few more. Sometimes, not the entire functionality is affected, but only a specific display. Drop caps aren't displayed, and any adjustments to font sizes or alignments aren't implemented because they're based on CSS. #### Basic problem #2: No Javascript in the feed If a button triggers an interaction via JavaScript in the frontend, this interaction is obviously not functional due to the lack of JavaScript in the feed. For example, blog articles loaded via AJAX, as in the case of the large WordPress agency.  “Load More” is not only not translated, but of course has no function here, since the button reloads articles via JavaScript, which of course does not work in the feed. Beide Probleme liegen letztendlich daran, dass der Feed-Kontext nicht bedacht wurde, was in der Anzeige oder in der Funktionalität die Fehler erzeugt. Und das passiert hier einem klugen Kollegen, der sich mit der Materie gut auskennt und einer großen WordPress-zentrierten Agentur. Das liegt unter anderem daran, dass das Core-System uns nicht davor schützt, solche Fehler zu begehen. #### Mögliche Lösungen? ##### Blöcke ausblenden? Nun stellt sich natürlich die Frage, was es für Lösungen gibt (oder geben könnte). Wir könnten manche Blöcke im Kontext von Beiträgen (und somit von Feeds) schlicht nicht erlauben. Wäre es vielleicht zu verschmerzen, wenn wir den Spalten-Block einfach nicht mehr in Beiträgen benutzen könnten? Oder den Abstandshalter? Oder Buttons? ##### Blöcke aus dem Feed entfernen? Und wenn das komplette Entfernen vielleicht doch zu viel ist, bei der riesigen Menge an Use Cases im WordPress-Ökosystem: Wie wäre eine zusätzliche Funktion, die es erlauben würde, einzelne Blöcke aus dem Feed zu entfernen, weil sie dort sowieso nicht funktionieren würden? Dazu habe ich ein „Proof of concept“-Plugin gebaut. Es ist aktuell auf GitHub zu finden und ich freue mich über Feedback! <https://github.com/Zodiac1978/hide-from-feed> Alle semantischen Objekte, die ohnehin durch HTML-Tags gesetzt werden, funktionieren ganz gut. Blockquotes können zum Beispiel im Feedreader vielleicht anders gestylt sein, aber die Verwendung als Zitat, ggf. mit Quelle, ist durch HTML gegeben und stylebar. Nur was ist dann mit Elementen, die keine klare Semantik haben? Buttons, die eigentlich Links sind? Technisch gesehen ist das in WordPress ein DIV mit einer CSS-Klasse, die es zum Button macht. Im Feed wird es nur noch zum einfachen Textlink. ##### CSS hinzufügen, aber wo? Vielleicht ist die Lösung auch nicht in WordPress zu suchen, sondern im Feedreader. Typischerweise entfernen oder ignorieren die meisten Feedreader das CSS allerdings (egal ob als verlinkte Datei oder im Style-Attribut). Am ehesten noch funktionieren Inline-Styles im Inhaltsbereich. Aber vielleicht könnten die Feedreader auch selbst das CSS anbieten, was dann die CSS-Klassen von WordPress interpretiert. Die sind nämlich nach wie vor im Feed enthalten. Mein Versuch bei NetNewsWire (Mac) [diesen Vorschlag anzubringen](https://github.com/Ranchero-Software/NetNewsWire/issues/4634), ist leider nicht besonders erfolgreich gewesen. #### Noch mehr Probleme mit RSS Leider ist das nicht das einzige Problem mit RSS in WordPress und Feedreadern. Ich zähle mal ein paar Probleme und mögliche Lösungen auf. ##### Feeds finden Als RSS-Feeds ihre besten Zeiten hatten, standen die Feed-Icons auf jedem Blog in der Sidebar. Mit der Zeit verschwanden nicht nur die Sidebars, sondern auch die Feed-Icons von den Websites. Unter anderem, weil der Feed nun für die Autodiscovery im Head der Website definiert wurde und die Browser oder Feedreader den Feed automatisch erkannten. Dabei wurde jedoch übersehen, dass neue Generationen an Internetnutzenden das Icon nicht mehr sahen und sich daher auch nicht mehr fragten, was das eigentlich ist, so ein RSS-Feed. Weniger Nutzung führte dazu, dass [RSS-Funktionen aus Browsern verschwanden](https://openrss.org/blog/browsers-should-bring-back-the-rss-button), was wiederum weniger Bekanntheit und Nutzung nach sich zog … was sehr schade ist. ##### Mangelnde Innovation Mit dem Rückgang der Feedreader-Nutzung ging einher, dass die „sozialen“ Netzwerke immer stärker genutzt wurden. Hier gab es Vorschaubilder, Teasertexte und die Möglichkeit zum direkten Weiterteilen. Leider wurden die Feeds nicht wirklich weiter entwickelt. Gerade WordPress hätte hier ja eine treibende Kraft sein können. Ein Feed/Feedreader wird nicht durch Algorithmen verändert, zeigt nur die Autor:innen, denen ich wirklich folgen will – ist somit ein kleines lokales, unidirektionales Fediverse. 😉 Aber viele mögliche Funktionalitäten scheitern an der Integration in WordPress und Feedreadern. ##### Medien in Feeds Warum werden zum Beispiel „featured images“ nicht als Vorschaubild genutzt? Oder eine neue Option dafür eingeführt (meinetwegen auch in einem Plugin)? Nun, dazu müsste WordPress das Bild überhaupt erst einmal einbetten. Und Feedreader müssten diese Media RSS Erweiterung auch umsetzen: > The media:content element is part of the Media RSS (MRSS) specification, which is an extension to RSS that allows embedding richer multimedia metadata (video, audio, images, etc.). > > Leider ist der Support auch hier eher mäßig. ##### Scraping Eine große Sorge war und ist, dass über den RSS-Feed ein kompletter Blog leicht kopiert werden kann, da eine maschinenlesbare Version ja direkt angeboten wird. Im Yoast SEO Plugin gibt es dazu die Erweiterung des Feeds mit dem Satz: *„The post XXX appeared first on YYY.“* Warum ist das nicht so oder so ähnlich im WordPress Core? ##### Feedback-Kanal, anyone? Ein großer Vorteil von Social Media ist das direkte Feedback der Leser:innen. Feeds könnten so ein Feedback ermöglichen, aber es fehlt eine Verzahnung mit anderen Systemen, wie den WordPress-Kommentaren. Ich kommentiere ja nicht jeden Artikel, aber wenn ich kommentiere, möchte ich die weiteren Antworten vermutlich lesen. Für diese Artikel jetzt einzeln noch den Kommentar-Feed in meinen Feedreader einbauen? Das mache ich vermutlich nicht – warum gibt es da keine bessere Integration? Und wenn es nicht das Kommentarsystem ist, dann vielleicht wenigstens eine E-Mail, so wie es [Florian Ziegler vorgeschlagen hat](https://florianziegler.com/journal/add-your-email-address-to-your-rss-feed). Aber das setzt voraus, dass die Feedreader das auch anzeigen … und von dem direkten Kommentieren im Feedreader wage ich gar nicht zu träumen. ##### Verbreitung Und um nochmal auf das Problem mit dem Finden der Feeds zurückzukommen: Lasst uns doch bitte alle wieder das Feed-Icon auf unsere Blogs bringen! Aber diesmal [bohren wir den Feed mit XSL auf](https://shkspr.mobi/blog/2023/06/style-your-wordpress-atom-feed/) und stylen die Seite, die den Besuchern angezeigt wird. So können wir das Prinzip von RSS-Feeds erklären und gleich ein paar Feedreader verlinken. Auch das sollte Teil des Cores sein, damit dieses Feature wieder mehr Verbreitung findet, denn es ist unmittelbar kompatibel mit der Mission „democratize publishing“. Inhalte werden für alle bereitgestellt, nicht durch Algorithmen gefiltert, getrackt und ausgewertet. #### Alternativen? Ja, es gibt Alternativen, aber sie stecken noch in den Kinderschuhen oder wollen zu viel, sind zu kompliziert oder haben noch ganz andere Probleme. RSS-Feeds kann ich noch in einem (recht langen) Satz erklären. Aber wenn ich die Funktionsweisen und Unterschiede zwischen ActivitiyPub, Webmentions, Mastodon, Fediverse, PubSubHubbub und dergleichen erklären müsste, dann müsste ich mir eher eine Woche Urlaub nehmen. Ein Beispiel für ganz neue Probleme mit dem ActivityPub-Plugin: Mit dem Einsatz wird der Blog ja zu einer eigenen Instanz im Fediverse. Ein neuer Artikel löst nun automatisch einen Post des *Blog*-Profils aus. Doch typischerweise bin ich ja in meinem *persönlichen* Profil angemeldet und nicht in meinem Blog-Profil. Wenn jetzt aber der Blog-Tröt viral geht, dann kann es passieren, dass ich das gar nicht mitbekomme, [so wie es Roy Tanck passiert ist](https://roytanck.com/2025/03/08/why-i-removed-the-activitypub-plugin/). #### Fazit Ich finde es unendlich traurig, dass WordPress nicht den Weg gewählt hat, offene Formate wie RSS, Pingback & Co. weiterzuentwickeln und voranzutreiben. Stattdessen wurde mit dem Blockeditor vor allem ein Problem der Hosting-Plattform WordPress.com angegangen, um gegen Squarespace, Jimdo & Wix anzugehen. Für den Blogger oder Website-Builder wurde damit nur [ein weiterer „Standard“ hinzugefügt](https://xkcd.com/927). Das Ziel der gemeinsamen Basis für alle ist eine unerreichbare Utopie. Der Markt zeigt, dass die Hersteller mit ihren eigenen Block-Sammlungen zwar die Lücken des Core schließen, damit aber auch den einfachen Wechsel zwischen Systemen unmöglich machen. Somit ist der Block-Editor auch nur ein weiterer Page Builder mit Lock-In-Effekt geworden, vor dem wir früher immer gewarnt haben. Ich habe ja ein paar Lösungsideen im Artikel genannt und bin gespannt auf eine Diskussion in den Kommentaren. Was haltet ihr für einen guten Weg? Und was nicht? Und warum? Oder nutzt ihr alle keinen Feedreader mehr und es ist euch egal? Dieser Eintrag wurde veröffentlicht in [WordPress](https://torstenlandsiedel.de/category/wordpress/) und getaggt mit [Feed](https://torstenlandsiedel.de/tag/feed/), [RSS](https://torstenlandsiedel.de/tag/rss/). Setze ein Lesezeichen auf den [Permanentlink](https://torstenlandsiedel.de/2025/10/05/das-rss-feed-dilemma/)., 4 Antworten Auf Das RSS-Feed-Dilemma, Torsten Landsiedel, 01k8jyr4y0jgeknk9dpv77m9vp.