How to Fetch WordPress Posts in Astro That Actually Render

Astro rendering works best as a three-part pipeline:

• Fetch data from WordPress
• Create routes from that data with getStaticPaths()
• Output templates from a stable, render-ready object

That separation matters because a raw WordPress post is a poor view model. It usually contains mixed concerns: REST metadata, embedded relations, rendered HTML, dates in multiple formats, and optional fields that appear or disappear by endpoint.

Before templating, map each post into a smaller shape such as:

• slug
• title
• html
• excerpt
• date
• featuredImage

Once normalized, routing becomes deterministic and templates stop depending on WordPress response quirks. Astro pages can then render from one dependable contract instead of reaching deep into _embedded, guessing at missing media, or repeating fallback logic in multiple files.

In practice, normalization is the real boundary between “API data exists” and “pages actually render.”

REST is usually the quickest route to pages that render. Astro still needs the same three pieces either way: a list query for routes, a detail query for content, and a template that outputs sanitized HTML or mapped fields. Switching to GraphQL does not remove getStaticPaths(), pagination work, or image handling.

WPGraphQL earns its keep when schemas get wide or inconsistent. It can request only needed fields, compose nested data cleanly, and make refactors safer across templates. For a practical comparison, see choosing between WPGraphQL and REST in Astro.

• Choose REST for speed, simpler debugging, and broad plugin support.
• Choose GraphQL for query control, reusable fragments, and complex content models.

A reliable Astro integration starts with one data function, not scattered fetch() calls. It should read the WordPress origin from an environment variable, request _embed so featured media arrives in the same payload, and return a small, stable post shape.

const WP = import.meta.env.WORDPRESS_URL?.replace(/\/$/, '');

export async function getPosts(page = 1) {
  const url = `${WP}/wp-json/wp/v2/posts?_embed&per_page=10&page=${page}`;
  const res = await fetch(url);
  if (!res.ok) throw new Error(`WP ${res.status}: ${await res.text()}`);

  const totalPages = Number(res.headers.get('X-WP-TotalPages') || 1);
  const posts = (await res.json()).map((p: any) => ({
    slug: p.slug,
    title: p.title?.rendered ?? '',
    excerpt: p.excerpt?.rendered ?? '',
    content: p.content?.rendered ?? '',
    date: p.date,
    featuredImage: p._embedded?.['wp:featuredmedia']?.[0]?.source_url ?? null,
  }));

  return { posts, totalPages };
}

Details that prevent breakage

• Base URL via env avoids hard-coded domains across local, preview, and production.
• Header-aware pagination prevents silent truncation after the first page.
• Null-safe mapping stops missing excerpts or media from crashing builds.
• Explicit error messages make bad routes, auth blocks, and malformed responses obvious during SSR or static generation.

A successful fetch only proves that WordPress responded. Astro still needs a static path for every post and a matching data lookup for each generated page.

The reliable mental model is simple:

• List page fetches many posts and renders links.
• getStaticPaths() turns that same post set into route params.
• Post page receives one post through props, then renders it.

Where rendering usually fails

The first common failure is a working archive with broken detail pages. That usually means the list fetched posts, but getStaticPaths() returned nothing, returned the wrong param name, or generated /posts/[slug] paths while links point somewhere else.

The second failure is subtler: routes build, but each page shows the wrong content or no content at all. That happens when route params are based on slug, while page data is looked up by id, or when the lookup re-fetches without using the same normalization rules as the list.

A safer pattern is to generate paths from normalized posts and pass the full post forward:

export async function getStaticPaths() {
  const posts = await getPosts();
  return posts.map((post) => ({
    params: { slug: post.slug },
    props: { post }
  }));
}

This keeps listing, route generation, and rendering on one data shape, which removes most empty-page bugs.

WordPress post fields are rarely uniform. In REST responses, title.rendered, excerpt.rendered, and content.rendered are typically HTML strings. Printing them as {post.title} or {post.excerpt} often exposes tags or entities instead of real markup.

In Astro, those fields need set:html at the point of output. That is the missing piece when a correct fetch still fails to display WordPress content in Astro properly.

• Use normal interpolation for plain data: slug, date, IDs, author names, custom booleans.
• Use set:html for editor-produced markup: headings, links, emphasis, lists, embeds, and formatted excerpts.
• Prefer normalized names like post.titleHtml and post.contentHtml so the template signals intent.

The trust boundary matters. set:html injects raw HTML into the page, so it should only receive content from a trusted CMS workflow or a sanitization step. If content can come from untrusted users, sanitize before rendering and allow only the tags and attributes the design actually needs.

A post can render and still feel unfinished: missing hero images, broken /wp-json domain links, empty author names, or taxonomies that only exist as IDs. Those are data-shaping problems, not template problems. Astro components should receive a stable object, not negotiate WordPress quirks on every render.

Map related data once

During normalization, extract a featured image from _embedded["wp:featuredmedia"] or the GraphQL equivalent, then store a compact object such as src, alt, width, and height. Resolve author data the same way: flatten name, slug, avatar, and URL into one predictable field.

For taxonomies, convert category and tag arrays into label/slug pairs immediately. Templates should loop over ready-made terms, not chase relationship IDs or mixed response shapes.

Rewrite links before rendering

WordPress content often contains absolute links back to the CMS origin. Rewrite internal href and image src values during normalization so production pages point to Astro routes and public assets. Leave external URLs untouched.

• Keep custom fields behind a mapper, even when using ACF.
• Coerce nullable values to null, empty arrays, or defaults.
• Strip unused fields so templates stay small and type-safe.

That single normalized contract prevents dozens of tiny production regressions.