thanks for the report - i can seee how the current process of reuse leads to this. I and others need to research what you describe as a way to cache bust this

Not sure if it'd work, but my first theory was possibly converting the pubDate to an time integer and seeing if I could add that to a cache busting hash (or query param) after the link and guid. Although that assumes that the pubDate updates whenever you update the page contents.

Date.parse("Fri, 13 Oct 2023 13:30:00 GMT").getTime()
// 1697203800000

<item>
  <title>
    <![CDATA[ Friday October 13 2023 Security Releases ]]>
  </title>
  <link>https://nodejs.org/en/blog/vulnerability/october-2023-security-releases#1697203800000</link>
  <guid isPermaLink="false">/blog/vulnerability/october-2023-security-releases#1697203800000</guid>
  <pubDate>Fri, 13 Oct 2023 13:30:00 GMT</pubDate>
</item>

Not sure if it'd work, but my first theory was possibly converting the pubDate to an time integer and seeing if I could add that to a cache busting hash (or query param) after the link and guid. Although that assumes that the pubDate updates whenever you update the page contents.

Date.parse("Fri, 13 Oct 2023 13:30:00 GMT").getTime()
// 1697203800000

<item>
  <title>
    <![CDATA[ Friday October 13 2023 Security Releases ]]>
  </title>
  <link>https://nodejs.org/en/blog/vulnerability/october-2023-security-releases#1697203800000</link>
  <guid isPermaLink="false">/blog/vulnerability/october-2023-security-releases#1697203800000</guid>
  <pubDate>Fri, 13 Oct 2023 13:30:00 GMT</pubDate>
</item>

That sounds like a doable fix. Pretty much appending an unix timestamp to the URL? I believe that can easily be done. Would you be inclined by opening a PR?