ブログの記事に大幅な更新 (タイプミスの修正だけでなく) を行った場合、更新された記事が読者のニュース フィードに再び表示されるようにしたいと考えています。私が読んだことから、ここに私が見るいくつかのオプションがあります：
だから、私が何かを見逃していない限り、良い選択肢はないようです。
RSS アイテムの GUID または Atom エントリ ID を変更すると、どのような影響がありますか? フィード ポリスは、記事 ID を変更するために私のドアに現れますか?
この時点で両方の答えが述べているように、完璧な方法はありません。GUID を変更すると、コンテンツが真新しいものであると誰もが信じてしまうため、重複したコンテンツが作成される可能性があります。また、要素だけを変更しても、必ずしも完全な更新がトリガーされるとは限りません。
PubSubHubbubを使用すると、ファット ping になるため、役立つ場合があります。これは、サブスクライバーが更新されたデータをすぐに取得し、以前のバージョンと同じキー/一意の ID で保存できることを意味します。
RSS<guid>またはAtom<id>は、その親アイテムを一意に識別するために使用される要素です。フィード リーダーとアグリゲーターは、このフィールドを使用して、アイテムが既にダウンロードまたはフェッチされているかどうかを判断します。
RSS<guid>または Atomを変更する<id>と、以前に保持されていた GUID または ID がデータベースまたはルックアップにあるものと一致しなくなるため、リーダーとアグリゲーターはアイテムが再度ダウンロードされることを示す信号またはフラグとしてこれを使用する可能性があります。
GUID または ID の変更は、更新を強制する方法ではありません。これは、「ダウンロード/フェッチする新しいものがあります」という言い方です。
RSS では?fake=parameter、GUID に追加すると、新しいダウンロードを強制する代わりの方法になります。ただし、GUID を共有していないため、フェッチされた古いアイテムはそのまま残ります。
発行日または更新日を使用して、RSS または Atom 経由で確実にダウンロードを強制することはできません。
あなたができる最善の方法は、アイテムのコンテンツを変更し、リーダーまたはアグリゲーターが必要に応じて更新できるようにすることです。これは、既にあるアイテムに対してこのようなコンテンツの変更が見られたときに、すべてが同じように機能するとは限らないためです.
そのエントリの「更新された」フィールドを更新することは正しいはずです。フィード自体の「更新済み」フィールド、Etags/最後に変更された HTTP ヘッダー (存在するが自動生成されていない場合) も更新し、リーダーが実際に更新を行うのを待つ/強制することを忘れないでください。
一部のリーダーでまだ問題がある場合は、フィード読み取りソフトウェアの作成者に確認して、それが意図的なものかどうかを確認してください。
2 番目の部分については、ID を変更してもフィード ポリスがあなたのドアに来ることはありませんが、頻繁に発生すると、重複として表示されるそのような記事は、フォロワーを苛立たせてフィードを無視/削除する可能性があります。