RSS Feed Best Practices

Dit zijn technische tips voor het publiceren van een blog. Deze hebben niets te maken met goede inhoud, maar uitsluitend met de manier waarop die inhoud wordt gedeeld. De aanbevelingen staan ruwweg in volgorde van belangrijkheid en bevatten een onderbouwing waarom ze belangrijk zijn.

Formaten

Mensen noemen feeds over het algemeen "RSS-feeds", maar meestal hebben ze het niet specifiek over RSS. RSS is niet het enige, en zelfs niet het beste formaat. Het gebruik van een gestandaardiseerd formaat is essentieel om ervoor te zorgen dat uw feed door de grootste variëteit aan readers en zoekmachines wordt begrepen.

U zou RSS 2 of Atom moeten gebruiken. Deze formaten worden zeer breed ondersteund. Andere veelvoorkomende formaten zijn oudere RSS-standaarden, JSON Feed of Microformats h-feed. Ik zou deze — of nog minder gebruikelijke formaten — vermijden, omdat ze minder breed worden ondersteund.

Als u nog geen feed heeft, raad ik Atom sterk aan. De specificatie is veel minder ambigu, waardoor u minder snel compatibiliteitsproblemen zult hebben met de verschillende readers die in gebruik zijn. De specificatie is over het algemeen ook eenvoudiger en duidelijker. Als u al een RSS 2-feed heeft, is er weinig reden om te upgraden.

Hieronder vindt u een minimaal Atom-sjabloon. Raadpleeg de specificatie voor volledige details.

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>{{FEED_NAME}}</title>
  <id>{{HOMEPAGE_URL}}</id>
  <link rel="alternate" href="{{HOMEPAGE_URL}}"/>
  <link rel="self" href="{{FEED_URL}}"/>
  <updated>{{LAST_UPDATE_TIME in RFC3339 format}}</updated>
  <author>
    <name>{{AUTHOR_NAME}}</name>
  </author>
  <entry>
    <title>{{ENTRY.TITLE}}</title>
    <link rel="alternate" type="text/html" href="{{ENTRY.HTML_URL}}"/>
    <id>{{ENTRY.PERMALINK}}</id>
    <published>{{ENTRY.FIRST_POST_TIME in RFC3339 format}}</published>
    <updated>{{ENTRY.LAST_UPDATE_TIME in RFC3339 format}}</updated>
    <content type="html">{{ENTRY.HTML}}</content>
  </entry>
</feed>

Er is zeer weinig reden om feeds in meerdere formaten aan te bieden. Als u een Atom-feed heeft, hoeft u geen RSS-feed aan te bieden.

Het wijzigen van het feed-formaat is veilig. Zeer weinig readers zullen in de war raken als een feed wisselt tussen Atom en RSS. Dit kan worden gedaan door de feed op dezelfde URL te wijzigen of door door te sturen naar een nieuwe URL (zorg er wel voor dat u het content-type bijwerkt).

Content-type

Zorg ervoor dat u de Content-Type header correct instelt:

  • Atom: Content-Type: application/atom+xml
  • RSS: Content-Type: application/rss+xml
  • JSON Feed: Content-Type: application/feed+json

U zult in de praktijk andere waarden zien, maar dit zijn de standaardwaarden met de breedste ondersteuning.

Absolute URL's

Elke URL in uw feed moet absoluut zijn. Hoewel Atom duidelijk heeft gespecificeerd hoe relatieve URL's moeten worden opgelost, worden deze zelden correct geïmplementeerd. Om ervoor te zorgen dat uw feed door alle readers kan worden begrepen, gebruikt u alleen absolute URL's (beginnend met https://).

Dit geldt voor alle <link>-elementen en de samenvatting en body van berichten (inclusief in de HTML).

Ontdekking (Discovery)

Op al uw blogpagina's en waarschijnlijk op elke pagina van uw site, moet u metadata opnemen om uw feed aan te kondigen. Hierdoor kunnen readers en zoekmachines zich abonneren en op de hoogte blijven van uw nieuwe inhoud. Dit is zo eenvoudig als het volgende toevoegen aan uw HTML:

<link rel=alternate title="Blog Posts" type=application/atom+xml href="/feed.atom">

Als u meerdere feeds heeft, kunt u deze allemaal aankondigen met passende titels:

  • <link rel=alternate title="All Posts" type=application/atom+xml href="/feed.atom">
  • <link rel=alternate title='Posts in the "Social" category' type=application/atom+xml href="/feeds/social.atom">
  • <link rel=alternate title="Comments on this Post" type=application/atom+xml href="/post/hello-world/comments.atom">

Zorg ervoor dat u het juiste type voor uw feed gebruikt. De gegeven voorbeelden zijn voor Atom-feeds.

Geef bij voorkeur de "belangrijkste" feed bovenaan. Veel clients behouden de volgorde bij het presenteren van feeds aan de gebruiker. Dit is subjectief, maar gewoonlijk is dat een feed voor de hele site, gevolgd door categorie-feeds en vervolgens een commentaarfeed voor de specifieke pagina.

Als u uw feeds in meerdere formaten aanbiedt, raad ik aan om er slechts één aan te kondigen (of Atom of RSS 2). Het opnemen van meerdere links naar dezelfde inhoud in verschillende formaten kan potentiële abonnees in verwarring brengen of leiden tot keuzestress (hoe weten ze dat de inhoud hetzelfde is?).

U kunt controleren of dit correct werkt door uw website-URL in de W3C Feed Validation Service te plaatsen. Als uw links correct zijn ingesteld, zou de service uw feed moeten detecteren en valideren. Test een paar verschillende pagina's om er zeker van te zijn dat de ontdekking overal werkt: probeer uw homepage, de pagina met berichtenlijsten en een individuele berichtenpagina.

Als het moeilijk is om de HTML te wijzigen, kan een Link header in de HTTP-respons worden gebruikt. Dit wordt echter minder breed ondersteund. Het gebruik van HTML <link>-tags heeft de voorkeur voor een bredere compatibiliteit:

Link: /feed.atom; rel="alternate"; type="application/atom+xml"

U zou ook een link met een RSS-logo moeten toevoegen voor gebruikers die geen andere feed-indicator hebben.

HTTPS

HTTPS is essentieel voor de beveiliging en privacy op internet. Het aanbieden van feeds via HTTPS waarborgt de privacy van de gebruiker en voorkomt dat uw feed door een kwaadaardige actor wordt gewijzigd.

  • Verwijs naar alle ingebedde media (zoals afbeeldingen) via HTTPS. Veel readers draaien in een beveiligde context waar HTTP-verzoeken niet zijn toegestaan.
  • Bied de feed aan via HTTPS.
  • Zorg ervoor dat uw self-link HTTPS is.
  • Stuur HTTP-verzoeken door naar HTTPS.
  • Overweeg het gebruik van Strict-Transport-Security.

Volledige inhoud

Het wordt over het algemeen aanbevolen om de volledige inhoud van uw berichten in de feed aan te bieden. Dit is wat de meeste readers prefereren. Voor RSS en Atom moet het <content>-element het volledige artikel bevatten. Atom heeft ook een <summary>-element waarin een kortere samenvatting kan worden opgenomen voor readers die dat prefereren.

Natuurlijk is het delen van volledige inhoud in feeds voor sommige publicaties onacceptabel vanwege de moeilijkheid om deze weergaven te monetiseren. Overweeg echter dat sommige readers kunnen vertrekken als ze de volledige inhoud niet in hun feedreader kunnen bekijken. Zelfs als ze uw advertenties niet zien, kunnen ze uw inhoud delen met vrienden of op nieuwsaggregators. Waarschijnlijk is het voor u waardevoller om deze reader te behouden dan ze te verliezen.

Als uw inhoud betaald is, overweeg dan om gebruikers toe te staan private links te genereren via een auth-token. Bijvoorbeeld: /feed.atom?user=peruserauthtoken. U kunt ook basic auth gebruiken, zoals https://fred:peruserauthtoken@blog.example/feed.atom, maar dit wordt door minder readers ondersteund dan het aanbieden van een token in het URL-pad of de query-string.

Entry-ID's

Entry-ID's zijn de primaire manier om items in uw feed te identificeren en te onderscheiden. Als uw entry-ID's veranderen of herhaald worden, ontvangen readers duplicaten of missen ze berichten.

  • Wijzig nooit de ID van een bestaand artikel.
  • Als u uw ID-schema wijzigt, zorg er dan voor dat dit alleen geldt voor nieuwe berichten.
  • Hergebruik nooit Entry-ID's voor verschillende artikelen.
  • Geef de voorkeur aan artikel-permalinks voor Entry-ID's.
  • Probeer uw Entry-ID's wereldwijd uniek te maken over alle bestaande feeds.

Sommige readers voegen feeds samen; unieke ID's helpen om problemen te voorkomen. De eenvoudigste manier om dit te bereiken is door een URL op een domein dat u beheert te gebruiken. Als dat niet mogelijk is, kunt u een UUID gebruiken, zoals urn:uuid:f4a3ca5b-5799-44e8-aaaa-e40728f037d3.

Datums

Zowel Atom als RSS maken onderscheid tussen het tijdstip van publicatie (het moment dat het bericht voor het eerst in de feed verscheen) en het tijdstip van de laatste update (het moment dat het bericht voor het laatst is gewijzigd). Zorg ervoor dat u deze correct beheert.

  • Neem een publicatietijd op.
  • De publicatietijd mag nooit veranderen. Een bericht kan slechts één keer worden gepubliceerd.
  • Zorg ervoor dat de publicatietijd ongeveer overeenkomt met het moment dat het bericht in de feed verscheen. Sommige readers negeren berichten die in het verre verleden zijn gepubliceerd.
  • Vermijd ten zeerste dat berichten in de feed verschijnen in een andere volgorde dan hun publicatietijd suggereert. (Vermijd bijvoorbeeld dat een item met een publicatietijd van 14:00 verschijnt om 14:00, waarna een item met een publicatietijd van 13:00 pas om 15:00 verschijnt. Sommige clients zullen wantrouwig zijn dat ze het item van 14:00 al kennen, maar het "vroegere" item van 13:00 nog niet.) Een andere manier om dit te bekijken is dat elk nieuw item dat in een feed verschijnt, een publicatietijd moet hebben die later is dan alle items die al in de feed stonden. Sommige clients negeren deze "teruggedateerde" berichten, zelfs als de publicatietijd vrij recent is.
  • Vermijd publicatietijden in de toekomst. Als een publicatietijd te ver in de toekomst ligt, negeren veel readers dit als een bug.
  • De updatetijd moet groter zijn dan of gelijk zijn aan de publicatietijd. Bij nieuwe berichten moeten deze twee gelijk zijn.
  • De updatetijd zou alleen moeten veranderen bij significante updates. Kleine wijzigingen in opmaak of het herstellen van typfouten zouden de laatste updatetijd waarschijnlijk niet moeten veranderen. De meeste readers negeren de updatetijd, sommigen zullen uw artikel opnieuw tonen als "bijgewerkt".

Titel van de feed

De titel van uw feed wordt waarschijnlijk standaard gebruikt in de reader van de gebruiker. Veel readers hebben opties om de titel te overschrijven, maar dat is extra werk voor de gebruiker en wordt niet universeel ondersteund. Probeer een goede titel voor uw feed te kiezen.

  • Voeg context toe. De titel is waarschijnlijk één van vele feeds in hun reader. Noem het bijvoorbeeld "Blog van Kevin Cox" in plaats van "Blogberichten".
  • Houd het beknopt. De gebruiker is al geabonneerd, er is geen reden voor verdere reclame. Bijvoorbeeld "John Smith" of "Fotografieblog van John Smith", en niet "John Smith — Overwegingen over Fotografie elke dinsdag en vrijdag, Camera's, Film en Ontwikkeling — Exclusieve Inhoud".
  • Vermijd HTML-speciale tekens zoals < > en &. In RSS is het niet volledig duidelijk of u styling zoals <b>-tags in uw feedtitel kunt opnemen. Zeer weinig readers parsen HTML in de titel en zullen deze bijna altijd letterlijk behandelen.

U kunt de titel van uw feed op elk moment bijwerken, maar het kan verwarrend zijn voor gebruikers als dit te vaak gebeurt.

Styling

Voel je vrij om CSS in je feed te gebruiken! Houd er echter rekening mee dat veel feedreaders geen moderne browser-engines gebruiken en beperkt zijn in wat ze kunnen renderen. Bovendien saniteren veel feedreaders uw feed, waardoor ongebruikelijke elementen en aangepaste CSS gedeeltelijk of volledig kunnen worden verwijderd. Laat u hierdoor niet tegenhouden; het gebruik van HTML en CSS kan de ervaring voor gebruikers met goede readers aanzienlijk verbeteren. Overweeg de volgende tips:

  • Denk na over wat er gebeurt als bepaalde CSS niet wordt toegepast. Als u bijvoorbeeld background: black; color: white instelt en een van de twee regels wordt verwijderd, is de tekst onleesbaar. Geef over het algemeen de voorkeur aan kleine aanpassingen in plaats van te vertrouwen op CSS voor dramatische veranderingen.
  • Geef de voorkeur aan inline CSS-style-attributen boven aparte <style>-blokken. Deze hebben een bredere compatibiliteit.
  • Geef de voorkeur aan semantische elementen zoals <p>, <h1>, <pre> en <code> boven het nabootsen van hun stijl met <div>s en <span>s.
  • Vertrouw niet op JavaScript; vrijwel geen enkele reader ondersteunt dit.
  • Bied fallbacks aan voor <audio>, <video> en <iframe>-tags. Ondersteuning hiervan is niet gebruikelijk.
  • Vermijd formulier- en input-elementen. Ondersteuning is zeldzaam en incompatibel.

Helaas is er geen alternatief voor het testen in verschillende readers om te zien wat werkt.

Self-link

Zorg ervoor dat de self-link voor uw feed nauwkeurig is:

<link rel="self" href="https://kevincox.ca/feed.atom"/>

Dit biedt de volgende voordelen:

  • Het stelt u in staat uw feed te verplaatsen. Sommige readers werken de feed-URL bij als ze een permanente redirect ontvangen en het redirect-doel een self-link bevat die naar zichzelf wijst.
  • Verbetering van cache-hits. Het komt vaak voor dat gebruikers kleine variaties van uw feed-URL vinden (bijvoorbeeld http: in plaats van https:, /feed vs /feed/, www.example.com vs example.com). Door een gecanoniseerde self-link aan te bieden, kunt u deze samenvoegen om variantie te verminderen en uw cache-hitrate te verhogen.
  • Vereist voor WebSub.
  • Abonneren via bestand. Als de gebruiker een kopie van het feedbestand heeft, kunnen ze zich erop abonneren. Sommige feedreaders fungeren als bestandshandlers voor feeds. Als het bestand een self-link bevat, kunnen ze die URL gebruiken om zich te abonneren en updates op te halen. Zonder self-link is dit niet mogelijk.

Caching

Feeds worden gevolgd via constante polling. Dit kan een aanzienlijke belasting op uw server veroorzaken. Het instellen van cache-headers kan helpen om de readers te sturen. Als u geen richtlijnen geeft, kiest elke client zijn eigen waarde, wat te snel of te langzaam kan zijn voor uw feed.

Probeer een redelijke waarde te kiezen op basis van wanneer u post. Als uw blog maandelijks wordt bijgewerkt, is caching voor een uur logisch. Als u echter vele malen per dag post, is een cache van vijf minuten geschikter.

Voorbeelden van cache-headers:

  • 5 min: Cache-Control: max-age=300
  • 15 min: Cache-Control: max-age=900
  • 1 uur: Cache-Control: max-age=3600

Als u geplande berichten gebruikt, kunt u de cache-tijd variëren op basis van wanneer het volgende bericht live gaat, maar een statische cache-tijd is voldoende.

Waarschuwing: Hoewel sommige readers uw cache-headers respecteren, doen velen dat niet. Als u zich zorgen maakt over de belasting, moet u uw eigen caching implementeren, bijvoorbeeld via een CDN of binnen uw applicatie.

Conditionele verzoeken

Ondersteun conditionele verzoeken voor uw feed. Dit maakt polling efficiënter voor zowel u als uw gebruikers.

Return een ETag en/of Last-Modified header. Geef vervolgens een 304-respons terug als de feed niet is gewijzigd. Zie HTTP conditional requests op MDN voor meer details.

WebSub

WebSub is een standaard voor real-time feed-updates. Het versnelt niet alleen uw updates, maar vermindert ook de belasting op uw server.

U kunt een publieke hub gebruiken of uw eigen hub draaien. Let op dat een hub inhoud in uw feed kan wijzigen of injecteren, dus zorg dat u de hub die u kiest vertrouwt. (De Google hub heeft basisinstructies op hun homepage).

Toegang voor bots

Als u technologie gebruikt om bots te blokkeren, zorg er dan voor dat u dit uitschakelt (of sterk vermindert) voor uw feeds. Feeds zijn juist bedoeld om door bots te worden geconsumeerd! Anders hebben gebruikers problemen met het openen van uw feed en zullen ze niet op de hoogte zijn van uw nieuwe inhoud.

Categorieën

Categorieën zijn een betrouwbare manier om items in feeds te filteren. Het is veel beter om iemand de mogelijkheid te geven zich aan te melden voor één categorie — of alle categorieën behalve één — dan een abonnee te verliezen omdat ze geërgerd waren door een subset van uw inhoud.

Voor Atom-feeds is het toevoegen van categorieën zo eenvoudig als één element: <category term="RSS"/> <category term="Guide"/>

Voor RSS 2 is de syntaxis net iets anders: <category>Rant</category>

Sommige readers ondersteunen geen categorieën. U zou kunnen overwegen om verschillende feeds voor verschillende categorieën te genereren of een URL-parameter aan te bieden om op categorie te filteren, maar persoonlijk zou ik me hier geen zorgen over maken.

De URL wijzigen

Vermijd het wijzigen van de URL van uw feed zoveel mogelijk. Maar als u het moet doen, is dit de manier om het te doen zonder veel abonnees te verliezen:

  1. Maak de feed beschikbaar op de nieuwe URL, in aanvulling op de oude URL.
  2. Zorg ervoor dat de self-link van de nieuwe feed naar de nieuwe URL wijst.
  3. Als u WebSub gebruikt, begint u uw hub voor beide URL's te pingen wanneer u post.
  4. Stuur de oude URL door naar de nieuwe met een 308 Permanent Redirect.
  5. Als u WebSub gebruikt, moet u de oude URL minstens 3 maanden blijven pingen, of tot de maximale abonnementsduur van uw hub (welke het langst is).

Houd er rekening mee dat sommige abonnees niet zullen overstappen. Probeer de redirect zo lang mogelijk actief te houden. Na een langere periode kunt u overwegen de redirect te vervangen door een feed met een bericht waarin de nieuwe locatie wordt gemeld.

CORS

CORS (Cross-Origin Resource Sharing) is een oplossing voor mazen in het oorspronkelijke beveiligingsmodel van het web. Het voegt beperkingen toe aan welke verzoeken webpagina's kunnen maken en controleert wat ze van de respons kunnen zien.

Dit is relevant voor feeds, omdat browser-gebaseerde readers die feeds aan de client-zijde ophalen, geen toegang zullen hebben tot uw feed zonder de juiste CORS-instellingen.

Voor feeds zijn de volgende headers voldoende en veilig: Access-Control-Allow-Origin: *

Dit betekent dat uw feed als een publieke bron kan worden opgevraagd (er worden in dit geval geen cookies verzonden).

Om dit te testen, kunt u naar een willekeurige externe webpagina gaan (zoals https://example.com) en de volgende Javascript in de developer console uitvoeren: fetch("https://UWFEEDHIER").then(r => r.text()).then(console.log, console.error)

Als de inhoud van uw feed wordt gelogd, bent u klaar. Als u een foutmelding krijgt, is er iets misgegaan.

Prestaties

Terwijl kleine en lokale feedreaders eenvoudige poll-rates gebruiken, maken grotere diensten gebruik van diverse heuristieken om te bepalen wanneer ze uw feed controleren. Als u WebSub niet ondersteunt, moet u ernaar streven om op feed-verzoeken in minder dan 1 seconde te reageren. Als uw feed trager is, vooral als hij trager is dan 3 seconden, zal de polling waarschijnlijk worden vertraagd en krijgen uw readers hun updates minder snel binnen.

***

De onderstaande punten zijn relatief onbelangrijk. Ze zijn een goed idee als u een product of feed-generator maakt, maar waarschijnlijk de tijd niet waard als u alleen een feed voor uw eigen blog maakt.

Samenvattingen

Sommige readers tonen korte snippets als een voorproefje van een artikel. Het aanbieden van een samenvatting in uw feed geeft hen hoogwaardige inhoud voor een goede gebruikerservaring. Als u geen expliciete samenvatting aanbiedt, zullen ze waarschijnlijk uw eerste alinea of de eerste paar zinnen van uw hoofdinhoud gebruiken.

Paginering

Paginering is een nuttig instrument om uw feed-archief beschikbaar te houden terwijl de grootte van de recente items klein blijft. Dit is gespecificeerd in RFC 5005: Feed Paging and Archiving. Helaas hebben weinig clients ondersteuning hiervoor. Het toevoegen van ondersteuning in uw feed heeft echter geen nadelen.

Paginering is zeer eenvoudig. Voeg de volgende link toe aan uw feed: <link href="https://kevincox.ca/feed/2022-03-05.atom" rel="next"/>

Op daaropvolgende pagina's voegt u ook een prev link toe. De laatste pagina heeft natuurlijk geen next link: <link href="https://kevincox.ca/feed.atom" rel="prev"/> <link href="https://kevincox.ca/feed/2022-01-21.atom" rel="next"/>

Houd bij het bepalen van de paginagrootte rekening met het feit dat niet alle clients paginering ondersteunen; u wilt nieuwe berichten dus niet te snel van de eerste pagina verwijderen. Hier zijn enkele algemene richtlijnen:

  • Zorg dat uw nieuwste items op de eerste pagina staan.
  • Probeer items minstens een dag in de feed te houden. Sommige clients controleren zeer onregelmatig. Indien redelijk, houd items minstens een week vast.
  • Voorkom dat de feed te groot wordt; een grootte ruim onder de megabyte wordt aanbevolen.