Updated: September 23, 2026
If you’ve ever opened your RSS feed’s raw XML and noticed tags like <ttl>, <skipHours>, or <skipDays> sitting near the top of the channel element, you might reasonably wonder whether they control how often tools like PostRSS check your feed for new content. It’s a reasonable question, since that’s literally what these tags were designed to communicate — but the honest, practical answer in 2026 is that most modern RSS feed automation tools don’t strictly obey them, and understanding why helps set the right expectations for how your automation actually behaves.
This guide explains what these three optional RSS 2.0 tags actually do, why they’ve fallen out of practical relevance, and what actually controls how often your feed gets checked for new content today.
What <ttl> Is Supposed to Do
The <ttl> (time to live) tag is a channel-level element in the RSS 2.0 specification that suggests, in minutes, how long a feed’s content should be cached before a reader or aggregator checks it again. A feed with <ttl>60</ttl> is technically suggesting “don’t bother checking again for at least 60 minutes,” intended originally as a courtesy to publishers who wanted to reduce server load from overly aggressive polling by aggregators.
What <skipHours> and <skipDays> Are Supposed to Do
These two tags let a feed publisher specify times when the feed generally isn’t updated, so a well-behaved aggregator could skip checking during those windows. <skipDays> lists specific days of the week (for example, a feed that never publishes on weekends could list Saturday and Sunday), while <skipHours> lists specific hours of the day (in GMT) when checking isn’t worth the aggregator’s time, such as the overnight hours for a feed that only publishes during business hours.
Why Modern Tools Mostly Ignore These Tags
In practice, these tags are honored inconsistently across the RSS ecosystem, and most dedicated RSS-to-social automation tools use their own polling logic rather than deferring to a feed’s self-reported preferences. There are a few practical reasons for this:
- Publishers rarely maintain them accurately: A feed’s
<ttl>value is often set once when the CMS was configured and never revisited, even as actual publishing frequency changes over time, making it an unreliable signal about current behavior. - Time-sensitive content doesn’t respect a skip window: A breaking news site that normally publishes only during business hours might occasionally have something worth posting immediately outside that window, and a hard-coded skip rule would delay that unpredictably.
- Automation tools need predictable behavior across many feeds: A tool managing thousands of connected feeds benefits from a consistent, centrally controlled polling strategy far more than from honoring each individual feed’s self-reported preferences, which would otherwise vary wildly in reliability from feed to feed.
- Push-based alternatives have largely superseded the need: RSS automation built around WebSub avoids the entire problem these caching tags were meant to address, since the feed actively notifies subscribers of updates instead of relying on a suggested polling interval at all.
What Actually Controls How Often Your Feed Gets Checked
Since these legacy tags aren’t the deciding factor, it’s worth being clear about what is. Most RSS-to-social automation platforms, including PostRSS, use their own polling schedule determined by the platform itself, tuned to balance timely content discovery against reasonable server load across all the feeds they monitor. This means your feed gets checked on a schedule set by the automation tool’s own infrastructure, generally on the order of minutes rather than hours, regardless of what your feed’s <ttl> value happens to say. For feeds that support WebSub, updates can be pushed immediately rather than waiting for the next poll at all, which is the closest modern equivalent to what <ttl> was originally trying to achieve, just implemented in the opposite direction — push instead of a suggested pull delay.
Should You Bother Setting These Tags at All?
There’s little harm in leaving them as your CMS generates them by default, and little benefit in spending time hand-tuning them specifically to influence RSS-to-social automation, since most tools you’d actually use for that purpose don’t prioritize them. If your CMS lets you configure a <ttl> value and you’re curious, a reasonable default reflecting your actual publishing frequency doesn’t hurt and may still be respected by some older or more conservative feed readers, even if it has no bearing on how quickly a dedicated auto-posting tool discovers your content.
A Historical Comparison: What These Tags Were Solving
It helps to understand the era these tags came from. In the early 2000s, feed readers and aggregators were far more numerous and far less centrally coordinated than today’s ecosystem, and a popular feed could genuinely see meaningful server load from dozens of independent readers each polling on their own schedule with no coordination between them. <ttl>, <skipHours>, and <skipDays> were a lightweight, decentralized attempt to let publishers signal their preferences directly in the feed itself, without requiring any special server-side infrastructure beyond adding a few extra XML tags.
That problem has largely been solved differently since then: modern feed consumers, including automation platforms, tend to be a smaller number of larger, more sophisticated services that can afford smarter caching and polling strategies on their own end, using tools like conditional GET requests and ETags rather than relying on a feed’s self-reported suggestions.
How to Actually Read Your Feed’s TTL, skipHours, and skipDays Values
If you’re curious what your own feed currently declares, viewing your feed’s raw XML directly (most browsers will show it if you visit the feed URL, or you can use a “view source” style tool) will show these tags near the top of the <channel> element, before the individual <item> entries begin. A typical WordPress-generated feed might include something like <ttl>60</ttl>, while <skipHours> y <skipDays> are less commonly present unless a specific plugin adds them. Seeing these values doesn’t tell you anything about how your specific automation tool actually behaves — for that, the more useful test is simply publishing new content and timing how long it takes to appear on your connected social accounts, as covered in more detail in guides specifically about diagnosing feed update delays.
A Common Misconception Worth Addressing Directly
A recurring assumption among site owners troubleshooting slow auto-posting is that adjusting these XML tags will speed things up, since the tags are, at face value, exactly about controlling check frequency. This assumption is understandable, but it conflates what the specification allows a feed to suggest with what a given automation platform actually implements. The RSS 2.0 specification is intentionally permissive about how readers handle these optional elements — a compliant reader is free to ignore <ttl> entirely and check more or less frequently based on its own logic, and the vast majority of production RSS-to-social tools do exactly that.
If you find your auto-posting is genuinely slower than expected, the more productive troubleshooting path is checking your feed’s actual server response time, confirming it isn’t being served from an aggressively cached copy, and verifying your automation tool’s stated polling interval or WebSub configuration — not adjusting caching tags that the tool likely isn’t reading in the first place.
Why This Still Comes Up in 2026
Despite their diminished practical relevance, these tags persist in discussions about RSS because they’re still technically part of the RSS 2.0 specification, still generated by default in many CMS platforms, and still occasionally referenced in older tutorials and Stack Overflow answers that predate the shift toward push-based and centrally-polled automation. Anyone researching “how to make my RSS feed update faster” is likely to encounter references to <ttl> fairly quickly, simply because it’s one of the few RSS specification elements that sounds directly related to update timing, even though its practical influence over modern automation has faded substantially.
Comparison: Legacy Caching Tags vs. Modern Discovery Mechanisms
| Mechanism | Cómo funciona | Honored by Most Modern Auto-Posters? |
|---|---|---|
| <ttl> | Suggests a minimum re-check interval | Rarely, inconsistently |
| <skipHours> / <skipDays> | Suggests times not to check the feed | Rarely, inconsistently |
| Conditional GET / ETags | Server tells the poller nothing changed, saving bandwidth | Yes, widely supported |
| WebSub | Feed pushes updates to subscribers immediately | Yes, where the feed supports it |
| Platform-set polling interval | Automation tool checks on its own fixed schedule | Yes, this is the default behavior |
Frequently Asked Questions
Does PostRSS respect my feed’s <ttl> value?
PostRSS uses its own polling schedule designed to discover new content promptly across all connected feeds, rather than deferring to each individual feed’s self-reported <ttl> value, which is common practice among modern RSS-to-social automation tools.
Will setting a very low <ttl> value make my feed get checked more often?
Generally no, since most automation tools use their own polling logic independent of this value. If you want the fastest possible discovery, WebSub support on your feed is a more effective lever than adjusting <ttl>.
Are <skipHours> and <skipDays> still part of the RSS 2.0 specification?
Yes, they remain part of the formal specification and are technically valid to include in a feed, but their practical influence on how modern tools behave has diminished significantly since they were introduced.
Could using these tags incorrectly break my feed?
Generally no, since they’re optional elements that a feed reader can simply ignore if malformed or unrecognized, though it’s still good practice to keep your feed’s XML valid overall regardless of whether every optional tag is used correctly.
Is there any modern equivalent to what these tags were trying to accomplish?
WebSub is the closest modern equivalent, but it works by push rather than by suggesting a pull-delay, which is a fundamentally more efficient approach since the feed only needs to notify subscribers when something has actually changed, rather than subscribers guessing at an appropriate check interval.
Should I remove these tags from my feed since they’re not doing much?
There’s no real need to remove them if your CMS generates them automatically — they’re harmless, and some older or more conservative feed readers may still reference them, even if the automation tools you care about most don’t prioritize them.
Does WordPress set these tags by default?
WordPress includes a basic <ttl> value in its default feed template, generally without <skipHours> o <skipDays> unless a plugin specifically adds them, though exact defaults can vary by WordPress version and active plugins.
Do other CMS platforms like Ghost or Webflow include these tags?
It varies by platform. Some CMS feed generators include a basic <ttl> value while omitting <skipHours> y <skipDays> entirely, since the latter two require more specific configuration around a publisher’s actual schedule that most general-purpose CMS platforms don’t attempt to infer automatically.
What This Means Practically for Feed Owners
The practical takeaway is that these tags belong in the category of “technically part of the spec, largely inert in practice for automation purposes” rather than “essential feed configuration you need to get right.” If your CMS generates them automatically without any input from you, there’s no reason to seek them out and change them. If you’re building or configuring a custom feed generator and deciding whether to include them at all, including a reasonable, roughly accurate <ttl> value costs nothing and provides a small courtesy to any older feed readers that still respect it, while not meaningfully affecting how quickly a modern platform like PostRSS discovers your new content.
The Bottom Line
The <ttl>, <skipHours>, and <skipDays> tags are a genuine, specification-defined part of RSS 2.0, but they’re a relic of an earlier, less centralized era of feed consumption. If you’re trying to influence how quickly your content reaches social media through an automation tool, your time is better spent confirming your feed’s actual reliability, checking whether WebSub is supported, and understanding the platform’s own polling behavior, rather than hand-tuning caching tags that most modern tools don’t prioritize in the first place.
See PostRSS pricing and connect your feed to see how quickly modern automation actually discovers and distributes your content.