A feed update can be visible at the host before every listening service shows it. Services fetch and store information on their own schedules. An older title in one app does not by itself prove that the hosting update failed.
Check the publishing path in order
First reopen the episode in the hosting tool and confirm the saved values. Next inspect the public feed. Find the intended episode using its stable identifier and compare the title, summary and enclosure with the approved version.
If the public feed still has the old value, investigate the hosting workflow. If the feed is correct but one listening app is older, use that service's current update or troubleshooting guidance. These are different places to look.
Avoid changing the title repeatedly while waiting. Several rapid edits make it harder to tell which version a service has fetched. Record the time of the intended change and keep one clear expected value.
Test the user-facing result
Open the normal episode path and check the actual audio as well as the text. A metadata refresh and a media replacement may follow different paths through caches and downloads.
If a listener reports an issue, ask which app and which episode version they see. Do not ask them to delete a library or account as the first troubleshooting step.
Keep a note of the original feed value and the corrected value. If the problem remains, that gives the provider a useful report with a specific item and time. The aim is a focused diagnosis rather than a chain of new edits that creates more versions for services to reconcile.