n8n RSS node: RSS Read and RSS Feed Trigger, the complete node guide

Two nodes handle RSS in n8n: RSS Read, which fetches a feed on demand inside a workflow, and RSS Feed Trigger, which starts a workflow whenever a new article is detected. They look interchangeable — they are not, and picking the wrong one explains half the monitoring workflows that either repeat themselves or miss articles. This guide covers the node in documentation format: configuration, returned fields, polling mechanics, deduplication, misbehaving feeds, and finally the pipeline pattern that ties it all together.

RSS Read: fetching a feed on demand

The RSS Read node takes a feed URL (RSS 2.0 or Atom) and returns one n8n item per article. Its configuration fits in a single field:

• URL: the feed address — fixed (https://blog.example.com/feed) or an expression such as {{ $json.feedUrl }} when the URL comes from an upstream item, which is the key to multi-feed setups;
• among the options, you can notably ignore SSL certificate errors, useful for internal or self-signed feeds.

That is all: no credential, no native authentication — an RSS feed is public by design. If a feed requires a header or a token, go through an HTTP Request node and parse the XML yourself (more on that below).

One important point: RSS Read returns whatever the feed contains at that moment, usually the last 10 to 50 articles depending on the publisher. It has no memory: run it again an hour later and it returns mostly the same items. Deduplication is therefore your responsibility — there is a dedicated section below.

The fields returned per item

Each article comes out as JSON with fields that follow the format's conventions. The most reliable ones:

• title: the article title;
• link: the canonical URL — your best deduplication key;
• pubDate: the publication date as provided by the feed, and isoDate, its normalized ISO 8601 version, far more convenient for date comparisons;
• contentSnippet: the plain-text excerpt, stripped of HTML — ideal for keyword filtering or an AI prompt;
• content: the content shipped by the feed, often HTML, sometimes the whole article, sometimes three lines;
• creator: the author, guid: the unique identifier declared by the publisher, categories: optional tags.

None of these fields is guaranteed: RSS is a loosely interpreted standard, and some feeds only publish a title and a link. Guard your expressions with optional chaining — {{ $json.contentSnippet ?? $json.title }} — rather than assuming the field exists.

RSS Feed Trigger: polling and its interval

The RSS Feed Trigger watches one feed and starts the workflow when new articles appear. Its mechanics are polling: at the interval set under Poll Times (every X minutes, hourly, or a cron expression for fine control), n8n re-reads the feed, compares it with what it has already seen and only emits the new entries — one item per new article.

Two practical consequences:

1. The interval is a trade-off, not a cosmetic setting. A study by Hongzhou Liu, Venugopalan Ramasubramanian and Emin Gün Sirer presented at the Internet Measurement Conference 2005 (see on Google Scholar), based on monitoring roughly 100,000 RSS feeds, showed that feed popularity follows a power law and that the vast majority of feeds publish rarely — aggressive polling of feeds that have nothing new wastes most of the system's bandwidth. The operational translation: a blog that publishes twice a week does not need a poll every minute. Hourly is almost always enough; keep short intervals for genuinely critical alert feeds.
2. The trigger's memory is tied to the active workflow. It does its job fine in steady state, but deactivating/reactivating the workflow, re-importing it, or a feed that regenerates its identifiers can produce a burst of "new" articles you have already processed. Hence the safety net below.

The trigger only runs on an activated workflow (the Active toggle); in test mode, the manual execution button simulates one polling pass.

Deduplication: the Remove Duplicates safety net

Whether you start from RSS Read (no memory) or from the trigger (memory that fails on edge cases), the idiomatic fix is the same: a Remove Duplicates node in "Remove Items Processed in Previous Executions" mode, keyed on link (or guid). n8n then keeps a history of values seen across executions and only lets the new ones through — modes, history size and pitfalls are covered in our Remove Duplicates node guide.

Prefer link over guid by default: some publishers generate unstable GUIDs, and a normalized link (UTM parameters stripped) is more robust.

Malformed feeds: don't let one feed break the pipeline

Real-world RSS feeds are messy: invalid XML, exotic encodings, servers returning an HTML error page with a 200 status, expired certificates. Three reflexes:

• On Error: Continue on the RSS Read node, so one broken feed does not stop the others from being read — the error item carries the details and can be routed to an alert;
• a global Error Workflow to be notified of recurring failures, as described in our error handling guide;
• for a structurally painful feed: fetch it with HTTP Request (which accepts custom headers, retries and timeouts), then parse with the XML node or a Code node — you control every step instead of depending on the built-in parsing.

The robust monitoring pipeline: the full pattern

To follow several feeds, forget the trigger (one per feed is unmanageable): the canonical pattern is Schedule Trigger → feed list → loop → RSS Read → Remove Duplicates → Filter.

1. A Schedule Trigger paces the whole thing — one or two reads a day is enough for content monitoring; cron settings and timezones are covered in our Schedule Trigger guide;
2. a Code or Edit Fields node supplies the list of URLs (or better: a Google Sheet or a Data Table);
3. a Loop Over Items loop passes each URL to an RSS Read node whose URL field is {{ $json.feedUrl }};
4. Remove Duplicates (cross-execution mode, link as key) removes what has already been seen;
5. a Filter keeps only the articles that contain your keywords:

{{ ["n8n", "automation", "no-code"].some(k =>
  (($json.title ?? "") + " " + ($json.contentSnippet ?? ""))
    .toLowerCase().includes(k)) }}

A boolean "is true" condition on this expression is all you need; to route instead of discard (priority articles vs archive), swap the Filter for IF or Switch.

Use cases: monitoring, curation, alerts

• Team news monitoring: the pipeline above, extended with scoring and AI summarization then a daily Slack digest — the full build, stage by stage, is our automated RSS monitoring guide. Delivering a digest rather than a stream of notifications is not just taste: the study by Gloria Mark, Daniela Gudith and Ulrich Klocke published at CHI 2008 (see on Google Scholar) shows that interruptions are paid for in increased stress, frustration and time pressure, even when the work eventually gets done;
• Competitive intelligence: plug your competitors' feeds (blogs, changelogs, press releases) into an AI analysis — covered in depth in our article on AI-powered competitive monitoring;
• Curation and publishing: filter the best sources, rewrite with a model, then publish automatically to LinkedIn after human review;
• Targeted alerts: an RSS Feed Trigger on a critical feed (service status page, security advisories), a keyword filter, an immediate notification — the one case where a short polling interval is justified.

Key takeaways

• RSS Read fetches a feed on demand, with no memory; RSS Feed Trigger watches a single feed by polling and only emits new entries;
• the useful fields are title, link, isoDate and contentSnippet — never guaranteed, so guard with ?? and optional chaining;
• set the polling interval to the feed's actual publishing frequency: hourly is almost always enough;
• always add a cross-execution Remove Duplicates keyed on link, even behind the trigger;
• On Error: Continue on the RSS node plus an Error Workflow make the pipeline tolerant of broken feeds;
• multi-feed = Schedule Trigger + loop + RSS Read + Remove Duplicates + Filter — then AI and a digest if you are building a full automated monitoring pipeline.