Relative URLs in RSS Feeds: Why Links and Images Break

Short answer: A relative URL such as /blog/my-post/ lub ../images/photo.jpg only works inside your own website, because the browser fills in the missing domain. An RSS feed is read by other programs in other places, so relative links and image paths often break there: readers show dead links, and auto-posted social posts arrive without a working link or picture. The fix is to make every URL in the feed absolute, including the domain and https://, which is usually one template or setting change.

What a relative URL is, and why it works on your site

A URL can be written in full, like https://example.com/blog/my-post/, or in a shortened form that depends on where it appears. The shortened forms are called relative URLs. There are a few common types:

• Root-relative: /blog/my-post/ means “this path on the same domain”.
• Document-relative: images/photo.jpg lub ../photo.jpg means “relative to the current page’s folder”.
• Protocol-relative: //example.com/photo.jpg means “same domain name, same protocol as the current page”.

On a web page, the browser knows the page’s own address, so it can resolve every relative URL into a full one. The rules for doing that are defined in RFC 3986, the standard for URI syntax. Web developers use relative URLs all the time because they are short and survive moving a site between a staging domain and a live domain.

Why relative URLs break inside an RSS feed

An RSS feed is not displayed on your website. It is downloaded by feed readers, aggregators, email tools and auto-posting services, then shown somewhere else entirely. When such a program meets /blog/my-post/, it has to guess which domain to attach. The RSS 2.0 format has no standard way to declare a base address for the HTML inside a description, so different programs guess differently:

• Some resolve against the feed’s own URL, which works only if the feed lives on the same domain as the content.
• Some resolve against the channel <link> or the item <link>, which may give a different answer for document-relative paths.
• Many do not resolve at all and pass the string through unchanged, producing a link that points nowhere.

Atom feeds are slightly better placed, because the Atom specification (RFC 4287) allows an xml:base attribute that sets the base for relative references. Support for xml:base in consumers is uneven, though, so even in Atom the safe choice is absolute URLs everywhere.

Symptoms: how relative URLs show up in auto-posting

Relative URLs rarely produce an obvious error message. Instead, you see strange behaviour downstream:

• Social posts without an image, because the image path in the feed was /wp-content/uploads/photo.jpg and the posting service could not download it.
• Links that open the wrong page or a 404 page, typically when a reader attached the path to its own domain.
• Posts that link to the feed URL instead of the article, when the item <link> itself is relative or empty.
• Podcast episodes that will not play, because an <enclosure> URL was relative. The RSS 2.0 rules expect a full http or https URL there.
• Everything works in your browser but not elsewhere, which is the classic sign: the browser can resolve relative paths, other tools cannot.

Missing images deserve special attention because they are the most visible problem on social networks. Our guide to broken image links in RSS feeds covers what happens when an image URL fails for other reasons too.

How to check your feed for relative URLs in five minutes

You do not need special software. Open the feed address in a browser, then use “View page source” so you see the raw XML rather than a formatted preview. Then search for these patterns:

1. <link>/ or a <link> element that does not start with https://. Every item link must be absolute.
2. href="/ oraz src="/ inside the description or content:encoded. These are root-relative links and images inside the HTML.
3. href="../, src="images/ and similar document-relative paths.
4. url="/ inside <enclosure>, <media:content> lub <media:thumbnail>.
5. src="//, protocol-relative image addresses. Many tools handle them, but some do not, so it is better to write https://.

If the HTML inside your feed is wrapped in CDATA or encoded as < entities, search for the encoded form too, for example href="/. Then run the feed through a validator. Validators do not always flag relative links in HTML content, but they catch structural problems that often appear at the same time. See RSS feed validation before auto-posting for a full checklist.

Common causes, platform by platform

Relative URLs in feeds are almost always produced by a template or a plugin, not by the author of the post. The usual suspects are:

• WordPress: the core feed uses absolute permalinks, but content can contain relative paths if a page builder, a “relative URLs” plugin or a migration tool rewrote them. Images inserted by the block editor are normally absolute; hand-edited HTML may not be.
• Hugo: templates that use .RelPermalink instead of .Permalink, or the site setting relativeURLs = true, produce relative addresses. Custom RSS templates are the usual place where this slips in.
• Jekyll: custom feed templates that print post.url without the absolute_url filter, or a missing url value in the site configuration.
• Eleventy: the official RSS plugin offers a filter that converts relative links in HTML content to absolute ones; feeds that skip it keep relative paths from the Markdown.
• Next.js and other JavaScript frameworks: hand-written feed generators often build links from route paths and forget to prepend the site origin.
• Headless CMS exports: image fields that store only a file path, which the website front end completes but the feed template does not.

If your site is built on a static generator or JavaScript framework, adding an RSS feed to a React or Next.js site explains where the feed is generated and what to check.

How to fix relative URLs for good

The permanent fix is to generate absolute URLs at the source rather than patching them later. In practice:

1. Set the canonical site address in your CMS or generator settings, with https:// and the final domain. Many templates build absolute URLs from this value.
2. Use the absolute helper in templates: permalink rather than relative permalink, an absolute URL filter, or a function that prepends the site origin.
3. Convert HTML content during feed generation. Run the post body through a filter that rewrites href oraz src attributes to absolute URLs before it is written into the feed.
4. Fix enclosure and media fields separately, because they are often built by different code from the main content.
5. Remove or reconfigure “relative URL” plugins that rewrite content for the whole site, or exclude feeds from their rewriting.
6. Clear caches after the change. Feeds are often cached by the CMS, a caching plugin and a CDN, so the old version can linger.

Once the change is live, publish a short test post and read the raw feed again. Confirm that the item link, every in-text link, every image and any enclosure start with https:// and your live domain. Then open the same item in a feed reader and click through, so you test the result the way subscribers experience it rather than the way your templates intend it.

Avoid the temptation to fix only the image in the auto-posting tool. That hides the problem for one channel while feed readers and other consumers still see broken links.

Domain migrations and staging sites make it worse

Relative URLs are sometimes introduced deliberately during a redesign, because they make it easy to copy a site between a test server and production. The side effect only appears later, when the feed starts carrying paths without a domain. The opposite problem is just as common: absolute URLs that still point to the staging domain because the database was copied without a search-and-replace.

After any move, check three things in the feed: that the item links use the live domain, that images load from the live domain or your CDN, and that nothing points to a temporary address. Our article on migrating or changing domains with auto-posting walks through the rest of the checklist, including avoiding a burst of duplicate posts.

Why the problem often goes unnoticed for months

Relative URLs in a feed are easy to miss because the people who run a website rarely read their own feed in a feed reader. They check the site in a browser, where every link works, and assume the feed is a faithful copy. Meanwhile, subscribers in readers click dead links and quietly unsubscribe, and nobody reports it.

Auto-posting can hide the issue in a different way. When a social network builds a link preview, it usually fetches the article page and reads its Open Graph tags, so the preview can look perfect even when the feed’s own image path is broken. The problem then appears only on channels that depend on the feed content directly, such as messaging apps, team chats, email digests or blog-to-blog syndication, where the image or the in-text links come straight from the feed HTML.

A few habits catch relative URLs early:

• Subscribe to your own feed in at least one feed reader and open a new post there after each template change.
• Click the in-text links in that reader, not only the headline, because body links are where relative paths hide.
• Look at one non-social channel, such as a Telegram channel or a team chat, where the feed content is shown with less help from Open Graph data.
• Re-check after plugin updates, page builder changes and theme switches, which are the moments when feed templates change without anyone noticing.

Treat the feed as a public interface of your site, the same way you would treat an API. If it changes, test it.

How PostRSS helps

PostRSS reads your RSS or Atom feed every 5 minutes and posts each new item with its link and image to the networks you connect. For images, it takes the picture from the feed item or from the article page’s Open Graph tags, so an article with correct og:image tags can still carry the right picture even if the feed itself is sparse. It does not rewrite your feed, however, so a relative item link must be fixed at the source. Each post and error is visible in the posting log, which makes it easier to spot items that failed because of a bad address. You can see how feeds, images and formats are handled on the features page.

Related reading

• RSS Feed Broken Image Links: What Happens When Your Auto-Posted Image URL 404s
• RSS Feed Validation: Make Sure Your Feed Works Before You Auto-Post
• Open Graph Meta Tags: Why Your Auto-Posted Links Show the Wrong Image
• RSS Feed XML Anatomy Explained: What GUID and pubDate Actually Do

The bottom line

Relative URLs are convenient on a website and a quiet source of breakage in an RSS feed. Every link, image and enclosure in your feed should be a full https:// address on your live domain. Check the raw feed source once, fix the template that produces relative paths, clear caches, and your feed will work the same in every reader and on every network it reaches.

FAQ

Are relative URLs allowed in RSS feeds?

The RSS 2.0 format expects the channel link, item links and enclosure URLs to be full URLs. Relative paths inside HTML descriptions are not forbidden, but there is no standard way to tell consumers how to resolve them. In practice, absolute URLs are the only reliable choice.

Why do my auto-posted links work on Facebook but not in feed readers?

Social networks usually fetch the article page itself and read its Open Graph tags, which can hide a relative link in the feed body. Feed readers display the feed HTML directly, so relative links inside it break there. Fixing the feed makes both consistent.

Does xml:base solve the problem?

Atom allows xml:base to declare a base address for relative references, and some readers honour it. Support is not universal and RSS 2.0 has no equivalent, so it should be treated as a fallback. Absolute URLs remain the safe option.

Are protocol-relative URLs like //example.com/image.jpg safe?

Many tools resolve them, but some consumers fail because they cannot infer the protocol outside a browser. Since practically every site now uses HTTPS, write https:// explicitly. It removes the ambiguity at no cost.

How do I know which template creates the relative URLs?

Compare the feed with a post’s HTML source. If the post page shows absolute URLs but the feed does not, the feed template is the cause. If both are relative, the content itself or a site-wide rewriting plugin is producing them.