WordPress RSS feed and REST API

WordPress feed URLs

WordPress serves a feed at /feed/ appended to the home page and to most archive URLs: a category, a tag, an author or a single post. On a subdirectory install such as wordpress.org/news, the paths start at https://wordpress.org/news, so the releases category feed is https://wordpress.org/news/category/releases/feed/.

The 28 October 2026 tests used the releases category, the security tag, the author matt and the search term release.

Each site sets its own feed length under Settings, Reading in the WordPress admin. In our tests, wordpress.org/news and nasa.gov returned 10 posts per feed request, techcrunch.com returned 20, and ma.tt returned 25.

Which WordPress endpoints work cross-origin

WordPress core handles CORS differently for RSS feeds and the REST API. Core's rest_send_cors_headers() function runs on REST API routes, where it echoes the browser's Origin header in Access-Control-Allow-Origin and adds Access-Control-Allow-Credentials: true. It doesn't run on feed URLs, so unless a site adds its own headers at the web server or CDN layer, browser fetch() calls to /feed/ from another origin get blocked.

We tested 6 WordPress sites on 28 October 2026 by sending an Origin header to both /feed/ and /wp-json/wp/v2/posts.

Of the 5 live feeds, 4 couldn't be read cross-origin from the browser directly: wordpress.org/news, ma.tt, and css-tricks.com sent no Access-Control-Allow-Origin header at all, while techcrunch.com sent Access-Control-Allow-Origin: https://techcrunch.com, which only lets its own pages read the response. Only nasa.gov sent Access-Control-Allow-Origin: *.

On the REST side, 4 of the 6 sites answered 200 with the caller's origin echoed back. css-tricks.com answered 401 (rest_authorization_required, because REST is limited to logged-in users there) with CORS headers, so your JavaScript can inspect the status code and fall back. whitehouse.gov answered 403 (REST disabled) without CORS headers, so a direct fetch() rejects with a TypeError instead.

Use the REST API first

Because WordPress enables CORS on /wp-json/wp/v2/posts by default, your browser code should try the REST API directly before touching the RSS feed. On sites without pretty permalinks, swap /wp-json/wp/v2/posts for /?rest_route=/wp/v2/posts (which also returned 200 on wordpress.org/news).

The endpoint takes query parameters to trim and filter the payload:

• _fields: return only the JSON fields you name. 10 posts from wordpress.org/news with _fields=date_gmt,link,title came to 1,823 bytes, against 114,896 bytes for the same 10 posts without _fields and 87,418 bytes for /feed/.
• _embed: include linked resources like authors and featured images in the same response.
• per_page, page, offset, search, categories, tags, author, orderby: control paging, filtering, and sort order.

To filter by category through REST, you need the numeric category ID rather than the slug:

1. Look up the category ID

   Request /wp-json/wp/v2/categories?slug=releases&_fields=id,name,count (which returned a 41-byte payload in our test) and read the id field.

2. Fetch the posts

   Pass that ID to /wp-json/wp/v2/posts?categories=<id>.

Watch out for two quirks in the JSON response. First, title.rendered contains HTML entities like –, so decode it before rendering it into text nodes. Second, date_gmt comes back without a time zone suffix, so append Z to the string before passing it to new Date().

Fall back to the RSS feed through cors.dev

When a site locks down /wp-json/wp/v2/posts like css-tricks.com does, fall back to /feed/ through https://proxy.cors.dev/. Put the target feed URL right after the proxy base URL, such as https://proxy.cors.dev/https://ma.tt/feed/. Every live feed in our tests returned 200 through https://proxy.cors.dev/ with the caller's origin in Access-Control-Allow-Origin.

The wordpressPosts(site, page) helper below tries /wp-json/wp/v2/posts directly with _fields=date_gmt,link,title and per_page=10, reads X-WP-TotalPages, and only fetches /feed/?paged=N through proxy.cors.dev if the REST request fails or returns an error status.

const PROXY = 'https://proxy.cors.dev/';
const decode = (html) => new DOMParser().parseFromString(`<body>${html}`, 'text/html').body.textContent;

async function wordpressPosts(site, page = 1) {
  // The REST API sends CORS headers by default, so we try it first without the proxy
  const api = await fetch(`${site}/wp-json/wp/v2/posts?per_page=10&page=${page}&_fields=date_gmt,link,title`).catch(() => null);
  if (api?.ok) {
    const posts = await api.json();
    return {
      totalPages: Number(api.headers.get('X-WP-TotalPages')),
      posts: posts.map((p) => ({ title: decode(p.title.rendered), link: p.link, date: new Date(`${p.date_gmt}Z`) })),
    };
  }

  // REST is disabled or locked, so we read the RSS feed through the proxy
  const res = await fetch(`${PROXY}${site}/feed/?paged=${page}`);
  if (!res.ok) throw new Error(`REST API unavailable and the feed answered ${res.status}`);
  const doc = new DOMParser().parseFromString(await res.text(), 'text/xml');
  const text = (item, tag) => item.querySelector(tag)?.textContent ?? '';
  return {
    totalPages: null,
    posts: [...doc.querySelectorAll('item')].map((item) => ({
      title: text(item, 'title'),
      link: text(item, 'link'),
      date: new Date(text(item, 'pubDate')),
    })),
  };
}

console.log(await wordpressPosts('https://wordpress.org/news'));

We tested wordpressPosts() against 4 sites: wordpress.org/news used REST and reported 112 pages of 10 posts, techcrunch.com used REST, css-tricks.com got a 401 from REST and fell back to the feed, and whitehouse.gov threw an error because it had neither REST nor a feed. For more on parsing the XML response or turning it into JSON, see fetching and parsing RSS feeds in JavaScript and our rss2json alternative guide.

Paging, search and feed size

Paging works differently depending on which endpoint succeeded. On the WordPress REST API, you control page size with per_page from 1 to 100 (passing per_page=101 returned 400 rest_invalid_param). WordPress returns the total post count in X-WP-Total (wordpress.org/news reported X-WP-Total: 1114), the page count in X-WP-TotalPages, and next and previous URLs in the Link header, and it lists all three in Access-Control-Expose-Headers so cross-origin JavaScript can read them.

On RSS feeds, you can't pick the page size; you get whatever the site configured (10, 20, or 25 items in our tests). To load older posts, append ?paged=2 (and higher) to the feed URL, or query /?s=<term>&feed=rss2 to search.

If you ever route REST requests or large feeds through https://proxy.cors.dev/, the proxy preserves upstream status codes and also exposes Link, X-WP-Total, and X-WP-TotalPages. The largest feed in our tests (/feed/?paged=2 on wordpress.org/news) was 302,869 bytes, well under the free tier's 6 MiB (6,291,456 bytes) response limit.

Good questions.