Canonical Feed URLs: How to Move or Rename a Feed Safely

A canonical feed URL is the preferred address from which a publication expects readers and crawlers to retrieve its feed. It should be stable, use HTTPS, return the feed directly, and appear consistently in website autodiscovery, documentation, directory listings, and internal configuration. Choosing that address is easy on launch day. Preserving its meaning during a domain or hosting migration is the real work.

A feed move affects more than one HTTP request. Subscribers may have stored the old URL for years. Podcast directories may poll on their own schedules. Search crawlers may discover both locations. Analytics platforms may classify them as separate sources. A safe migration therefore treats the old URL as an enduring alias and uses explicit protocol behavior to connect it to the new canonical location.

Canonical does not mean “the only URL ever seen”

One logical feed can be observed at several addresses: an HTTP version, an HTTPS version, a vendor-hosted URL, a branded URL, and one or more redirected paths. The canonical URL is the preferred current locator, not a reason to forget the others. A feed identity record should retain each previously valid address and the evidence that relates it to the publication.

This distinction prevents duplicate records. When a crawler encounters an old URL that permanently redirects to the canonical URL, it can attach that observation to the existing feed rather than create a new feed. When a redirect later fails, the alias history still explains where the subscription originated.

Choose the destination before touching the source

The new URL should be boring and durable. Avoid version numbers, campaign names, technology names, and vendor-specific folders unless they are truly permanent. A path such as https://example.org/feed/ is usually easier to preserve than https://feeds.vendor.example/customer-8472/rss.xml. The destination must return a successful response with the correct feed body and a suitable content type.

Build and validate the new feed before redirecting the old one. Compare the publication metadata and item IDs, not just the visible titles. The new output should preserve established GUIDs or Atom IDs. If the new host cannot import them, resolve that problem first; otherwise the migration can make every archived item appear new.

Use a permanent HTTP redirect

The old feed URL should respond with a permanent redirect to the new canonical URL. HTTP defines the semantics clients use to interpret redirection, and publishers should review HTTP Semantics in RFC 9110 rather than relying on folklore. In practice, a 301 response is broadly understood for feed migrations. A 308 is also permanent but may not be handled identically by older feed software, so compatibility testing matters.

GET /old-feed.xml HTTP/1.1
Host: old.example.net

HTTP/1.1 301 Moved Permanently
Location: https://example.org/feed/
Cache-Control: public, max-age=3600

The Location value should be absolute and use the final destination, not the first hop in a chain. Redirect chains add latency and create more points of failure. If possible, make every historic feed URL redirect directly to the current canonical URL.

Keep the old domain and route under control

A redirect works only while the old host continues to answer. Letting the old domain expire can expose subscribers to takeover risk or simply strand clients that never updated their stored URL. Feed migrations should include a long-term ownership plan for old domains and vendor routes. “Long enough” is measured in years, not days, because some readers poll rarely and some directories preserve source URLs indefinitely.

When leaving a hosting provider, confirm which redirects remain after account closure. A dashboard setting may stop working when billing ends. Test from an external network after the migration, and keep an independent monitor on the old URL. A successful test performed while logged into an administrative account is not sufficient evidence that anonymous clients receive the same response.

Publish the canonical URL everywhere you control

Update the website’s link rel="alternate" feed discovery element, visible subscription links, documentation, app settings, directory profiles, and API responses. Where the feed format supports a self link, publish the canonical URL there as well. Consistency helps new clients start from the preferred location while the redirect protects existing clients.

Do not remove the old URL from historical migration records. Internally, store both the requested URL and the final URL after redirects. That pair is useful for diagnosing reports such as “the feed works in one reader but not another,” because different clients may cache redirects for different lengths of time.

Preserve item identity and ordering

A move should not be combined with an unnecessary rewrite of item IDs, publication dates, and archive depth. Changing many variables at once makes failures difficult to interpret. Preserve GUIDs exactly. Keep the same timezone interpretation for publication dates. Ensure the new host does not truncate the feed so aggressively that a client sees a completely different recent history.

If content corrections are necessary, complete the identity-preserving migration first and make editorial changes afterward. That sequence gives operators a clean baseline. It also helps readers distinguish a location change from a content update.

Test like several different clients

Start with raw HTTP checks: request the old URL without following redirects, inspect the status and Location header, then follow the redirect and inspect the final content type and body. Repeat with common user-agent strings if the host applies special routing. Verify that HEAD and GET behave sensibly, although clients should not be assumed to use HEAD before every fetch.

Next, add both old and new URLs to multiple feed readers in a test account. The resulting subscription should show the same item history. For a podcast, check major directories and at least a few playback apps. Watch server logs for continuing requests to the old URL; they demonstrate why the alias must remain available.

A staged migration sequence

1. Inventory every known feed URL, including HTTP, HTTPS, vendor, and legacy paths.
2. Choose the permanent canonical destination and configure it to return the complete feed.
3. Import and compare stable item identifiers across old and new output.
4. Validate the new feed and test it directly in representative clients.
5. Deploy a direct permanent redirect from each legacy URL.
6. Update autodiscovery, visible links, directories, and internal configuration.
7. Monitor both source and destination, preserving logs and migration notes.
8. Retain control of old domains and keep redirects operational.

This sequence leaves room for rollback before the redirect is widely cached. Once clients have accepted a permanent move, reversing it can be unpredictable, so the destination should be ready before the first production redirect.

What not to do

Do not return an HTML page that says “the feed has moved” and expect feed readers to interpret it. Do not use JavaScript navigation; feed clients are not browsers. Do not place the new feed behind authentication unless the old feed had the same access model. Do not redirect to a homepage, a generic error page, or a route that negotiates different content based on cookies.

Avoid temporary redirects for a permanent move. They tell clients that the old URL remains authoritative and can cause repeated requests through the extra hop. Also avoid blocking the old URL in robots.txt; feed readers may not obey that file consistently, and it does not communicate the new location.

When two live URLs are intentional

Sometimes a publisher intentionally offers separate feeds for all posts, a category, a language, or a media format. Those are distinct publications even when content overlaps. Give each one a clear title, canonical URL, and identity. Do not redirect a specialized feed to a general feed unless the specialized publication is genuinely discontinued.

Mirrors are different again. A mirror may serve the same logical feed for resilience. Systems should record it as an alternate retrieval location rather than a second publication, but only when the publisher declares or verifies that relationship. Similar content alone is not enough.

Conclusion

A canonical feed URL is a promise about the preferred current location, backed by a history of aliases. Safe migrations preserve item IDs, deploy permanent HTTP redirects, update discovery metadata, and keep old routes alive. The goal is not merely to make the new URL work; it is to make every existing subscription continue working without duplicate items or lost history.

Publishers that model identity separately from location can move confidently. Readers can follow redirects while retaining the original alias, registries can merge observations without erasing provenance, and users experience one continuous feed rather than a forced resubscription.