When the WordPress REST API times out in a headless build, the cause is almost always a request that asks for too much at once from a backend that is too slow to answer it. Fetching all posts with their embeds and meta in a single call, against a plugin-laden WordPress install, is a reliable way to hit a timeout. The fix is to ask for less per request: page the data, limit the fields, and cache the responses. And for a one-time migration, you can skip the live API entirely with a crawl-based export. WPBuildAI exports the content without hammering a fragile API.
Confirm which core version is answering before you tune timeouts, since WordPress 7.0 shipped on 20 May 2026 and reached 7.0.2 by 17 July, and a REST route that was comfortably fast on the previous release can sit right at your limit after an upgrade you did not schedule.
Why the request times out
A timeout is the symptom of a mismatch between what you asked for and what the backend can deliver in the allotted time. The REST API only exposes what WordPress can produce, and the WordPress REST API Handbook documents endpoints that, queried naively, can ask the database for enormous result sets, every post, with embedded media, taxonomies, and meta, in one response. WordPress then has to assemble all of that through PHP and the database before responding, and a slow backend cannot finish within the request’s time limit, so the connection times out. The 2024 Web Almanac shows how heavy a typical WordPress install becomes with plugins, and that weight is exactly what makes a large query slow. So the timeout is not a bug in the API; it is the predictable result of a big ask meeting a slow responder.
The API is the messenger, the backend is the cause
It is worth being precise about where the problem lives, because it changes the fix. The REST API itself is rarely the issue; it is a thin layer exposing WordPress’s data. The cause is the backend’s speed: a plugin-heavy, under-resourced WordPress install responds slowly to any non-trivial query, and the bigger the query, the slower. Portent’s study of site speed and conversion underlines that this same backend slowness has costs everywhere, not just the API, and it is related to why page builders slow a site. So when the API times out, do not look for an API setting to fix; look at how much you are asking for and how slow the backend is. The two levers are reducing the ask (paging, fewer fields, caching) and, where you control it, making the backend faster or its time limit longer. Treating the API as the messenger keeps you fixing the real cause.
The fixes, smallest first
Work from the cheapest fix to the most involved:
- Page the requests with
per_pageandpage, fetching 20 to 50 items at a time and looping, so each response is small and finishes fast. - Limit fields with
_fields, so each response carries only the data you need rather than every field and embed. - Cache responses, so repeated fetches (in development or in production) do not re-hit the slow backend each time.
- Raise the PHP timeout and memory temporarily, if you control the server, to give large queries more room.
The first two reduce the ask, the third avoids repeating it, and the fourth widens the window. In practice, paging plus _fields resolves the large majority of timeouts on its own, because together they turn one giant request into many small, fast ones. These keep an ongoing headless setup stable, the context in connecting an AI builder to headless WordPress and making a site headless.
Paging in detail
Since paging is the primary fix, it is worth doing right. The posts endpoint accepts per_page (how many items per response, commonly capped at 100) and page (which page of results), so you fetch in batches: request page 1 with per_page=50, then page 2, and so on. The API returns headers telling you the total number of items and pages (commonly X-WP-Total and X-WP-TotalPages), so your code can loop until it has fetched every page rather than guessing. Combine this with _fields to request only the fields you actually render, dropping heavy embeds and meta you do not need, which shrinks each response further. The result is many small, fast requests that each succeed, instead of one massive request that times out. This paging-and-fields pattern is the same completeness discipline as any full extraction: loop through every page so you capture all the content, not just the first batch.
A worked example: fetching 1,000 posts
Picture a headless build that needs all 1,000 posts and times out every time it requests them. The naive call asks for all 1,000 with full content, embedded media, and meta in one response, and the slow backend cannot assemble that in time. The fix: request per_page=50 and loop through 20 pages, reading the total-pages header to know when to stop, and use _fields to fetch only title, slug, date, excerpt, and the content you render, dropping embeds you do not need. Each of the 20 requests returns quickly and succeeds, and the build assembles all 1,000 posts from them. Optionally, cache the results so the next build does not re-fetch. The single giant request that always timed out becomes 20 small requests that always succeed, with no change to the backend at all, just to how much each request asks for. That is the timeout fix in microcosm: same data, many small asks instead of one impossible one.
For a migration, skip the live API
There is an important distinction between an ongoing headless setup and a one-time migration. For an ongoing setup, you need the live API and you stabilise it with paging and caching as above. But for a one-time move, depending on the live API to hold up under the load of fetching the entire site at once is fragile, especially against a slow backend. A more robust approach for a migration is a crawl-based export of the rendered site, which reads the live pages incrementally (like a visitor) rather than hammering the API with large queries, and does not depend on the API surviving a bulk extraction. This is the same reasoning as why XML exports fail: the built-in bulk mechanism strains on large sites, while reading page by page scales gracefully. A migration also needs the URL list for redirects, per Google’s site move guidance, which a crawl provides. WPBuildAI uses a crawl-based export for migrations, so a slow or fragile backend does not block the move.
Ongoing headless: cache aggressively
For a permanent headless setup, the long-term answer to API load is caching, so the slow backend is queried rarely rather than on every request. If your front end calls the WordPress API live on each visitor request, you have coupled your fast front end to the slow backend, and timeouts (and slowness) follow under load. Instead, fetch the content at build time (for a statically generated front end) or cache API responses with sensible revalidation (for a server-rendered one), so visitors hit cached content and WordPress is queried only when content changes or the cache expires. This both eliminates per-request timeouts and keeps the front end fast regardless of backend speed. It is the same principle as caching in any headless WordPress setup: the API is for syncing content, not for serving every visitor, and treating it that way removes the timeout risk from the live path entirely while also protecting performance.
Common mistakes with REST API timeouts
The recurring errors come from fighting the symptom instead of the cause. Requesting all posts in one call against a slow backend guarantees timeouts, when paging would succeed. Fetching every field and embed when you only render a few bloats each response needlessly. Calling the live API on every visitor request, with no caching, couples your front end to the slow backend. Looking for an API setting to fix, instead of reducing the ask, wastes time, since the API is the messenger. And depending on the live API for a one-time bulk migration, rather than a crawl-based export, makes the move hostage to the backend’s load tolerance. Each is avoided by reducing the ask (paging plus _fields), caching so the backend is hit rarely, and using a crawl-based export for migrations, which together turn a timeout-prone setup into a stable one.
Key points to remember
The WordPress REST API times out in a headless build because one request asks for too much, all posts, full embeds, heavy meta, from a slow, plugin-laden backend that cannot respond in time; the API is the messenger, the slow backend is the cause. Fix it by reducing the ask: page requests with per_page and page looping through all pages, limit fields with _fields, and cache responses so the backend is queried rarely, raising the PHP timeout only if you control the server. For an ongoing headless setup, cache aggressively so visitors never hit the live backend; for a one-time migration, skip the live API and use a crawl-based export, which scales gracefully and yields the URL list for redirects. WPBuildAI exports without overloading the API, so a fragile backend does not stop the build; send your site URL for a fixed quote.
Not affiliated with WordPress or Lovable.