Astro’s default model assumes content is known at build time. A page is generated from a stable URL, using a query that returns only publicly visible records, and that HTML is then frozen until the next build. That works perfectly…
Before Astro templates enter the picture, the custom post type should be treated as an API contract inside WordPress. A type that looks fine in wp-admin can still fail headlessly if show_in_rest, public, or publicly_queryable are misaligned. That same discipline…
Astro can mirror WordPress paths in static, SSR, or hybrid mode, but the long-term maintenance cost is very different. Static builds Static output is safest when URLs change rarely and content updates can wait for a rebuild. Every known route…
WordPress content does not arrive in Astro as a finished page. It moves through a pipeline: blocks are stored in the database, turned into HTML by WordPress, sent over an API, then inserted into an Astro template and finally styled…
Astro rendering works best as a three-part pipeline: 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…
Before any Astro page template exists, the content API has already dictated URL discovery, field shapes, pagination logic, and failure modes during astro build. Changing it later usually means rewriting loaders, not just swapping endpoints. REST is the easier first…
