Pinterest RSS feed auto-publish: what it needs to work

Pinterest can create Pins for you from an RSS feed, which is a good fit for any site with a steady stream of images. Setting up a Pinterest RSS feed looks like a ten-minute job: publish a feed, paste the URL, wait. On Fotobank, a stock photo site built with Next.js, it took several fixes before the feed was in the shape Pinterest expects. This post walks through what the feed needs, the three problems I hit (domain verification, a feed that shipped empty, and missing dates) and how I plan to backfill a whole catalogue without flooding Pinterest at once.

How Pinterest auto-publish from RSS works

Pinterest's auto-publish from RSS feature reads a feed you give it and makes a Pin for each item. The item's image becomes the Pin, its title and description become the Pin text, and its link is where the Pin sends people when they click.

For a photo site that maps cleanly. Fotobank's feed lives at /photos/rss.xml and lists the 30 newest public photos, one item each. Every item links back to that photo's own page, so each Pin becomes a way into the site.

The image goes in the item's <enclosure>. I use the 1024 px medium variant there. The smaller listing thumbnail is too low resolution for a Pin, and the original is the paid file, which should never be in a public feed. If your image pipeline makes several sizes (mine is described in image processing with Sharp and S3), pick the one meant for public display at a large size.

What each item in a Pinterest RSS feed needs

An item for Pinterest is a plain RSS 2.0 item. This is the shape of one Fotobank item:

<item>
  <title>Morning fog over the river</title>
  <link>https://example.com/image/morning-fog-over-the-river</link>
  <guid isPermaLink="true">https://example.com/image/morning-fog-over-the-river</guid>
  <pubDate>Mon, 26 Oct 2026 09:14:00 GMT</pubDate>
  <description>Morning fog over the river, stock photo.</description>
  <enclosure url="https://cdn.example.com/photos/123/medium" type="image/jpeg" length="0" />
</item>

A few details matter here:

• One image per item. Pinterest makes one Pin per item, so a photo page maps to exactly one item.
• The link must be on your claimed domain. Pins link back to the site you verified, which brings me to the first problem.
• A stable guid. The page URL works well, because it never changes for the same photo.
• Escape titles and descriptions. A photo title with an ampersand will break the XML for the whole feed if it isn't escaped.

Claim your domain with the meta tag

Auto-publish from RSS requires a claimed website. Pinterest offers a few ways to claim one, including an HTML tag, an uploaded HTML file and a DNS TXT record.

On Fotobank, the DNS TXT record alone did not verify the domain. The meta verification tag did. If you are on Next.js with the App Router, the metadata API can render the tag for you through the verification field in the root layout, so it appears on every page without a hand-written <meta> element. If you are already routing all metadata through one helper, as I described in fixing missing Open Graph images in Next.js, this is one more field in the same place.

My advice: try the meta tag first. It is quick to add, quick to check in the page source, and it worked where DNS didn't for me.

Why both RSS feeds shipped empty

Once the domain was claimed, I looked at what the feed served in production. Both of Fotobank's RSS feeds were empty: valid XML, a channel with a title, and no items.

The cause was the build. The feeds were Next.js route handlers, and Next.js prerendered them at build time. The build runs in CI, and CI cannot reach the API that lists photos. So the fetch failed during the build, the handler rendered a feed with no items, and that empty file was what got deployed.

The fix was to render the feeds per request, the same way the sitemaps already were, with a 10-minute cache on the API fetch so Pinterest and other readers don't hit the API on every request:

export const dynamic = "force-dynamic";

export async function GET() {
  const res = await fetch(PHOTOS_API_URL, {
    next: { revalidate: 600 },
  });
  const images = res.ok ? (await res.json()).images : [];
  return new Response(buildFeed(images), {
    headers: { "Content-Type": "application/rss+xml; charset=utf-8" },
  });
}

This uses the Next.js 15 route segment config. The general lesson holds on any framework: anything built from live data needs a check on the deployed output. A build that can't reach your data won't fail loudly. It ships an empty file that looks fine.

Add pubDate and lastBuildDate

With items in the feed, Pinterest read it nightly for about a week and made no Pins from about 100 new items.

The feed had no dates. RSS readers usually tell new items from ones they have already seen with pubDate on each item and lastBuildDate on the channel, so I added both: each item's pubDate is the photo's upload time, and lastBuildDate is the newest photo's time. Both use the RFC 822 style format RSS expects, which JavaScript's toUTCString() produces.

I don't know yet whether that was what held Pinterest back. The change is the standard way to mark new items, and it is correct for any reader. I'll know more once Pinterest has read the dated feed for a while.

Backfilling a catalogue gradually, and image sitemaps

A feed of the 30 newest photos only covers new uploads. The catalogue behind it is much larger, and I want all of it on Pinterest eventually.

Putting every photo into the feed in one go would hand Pinterest a large burst of new items at once. The plan instead: from 1 November, the feed reaches 10 photos further back each day, newest first, until it carries the whole catalogue. Pinterest sees a small, steady stream of new items, and the feed grows on a schedule computed from the date, with no job to run or state to store.

Separately, I added blog and news cover images to their sitemaps so Google Images can find them. Google supports an image extension for sitemaps, documented in its image sitemaps guide, and it is a small addition when you already generate sitemaps per request. Fotobank's crawler rules are covered separately in blocking AI training crawlers with robots.txt, and the project itself is on my projects page.

How often does Pinterest check an RSS feed?

In my case Pinterest read the feed about once a night, which you can confirm from your own server logs by filtering for Pinterest's user agent. Expect Pins to appear on that kind of schedule after an item is added. If nightly reads produce no Pins, check that the items have dates, an image in each enclosure and links on your claimed domain.

Where I'd start

• Claim the domain with the meta tag and confirm it in the page source.
• Open the deployed feed URL and check that it has items. Render it per request if your build can't reach your data.
• Give every item a pubDate, the channel a lastBuildDate, and each item one public-size image in <enclosure>.
• Grow the feed gradually if you are backfilling a large catalogue.