REST API Developer for Hire

Headless WordPress means WordPress handles content management and data storage while a separate JavaScript application handles what visitors see. WordPress publishes content via its API, and the frontend framework fetches and renders it independently.nnIt makes sense for: large-scale content platforms needing CDN-edge performance globally, multi-channel publishing where the same content feeds a website, mobile app, and digital signage, teams with dedicated frontend developers who prefer React or Vue over PHP templates, and applications where the frontend needs capabilities WordPress templates cannot provide.nnIt does not make sense for: most business websites and WooCommerce stores where traditional WordPress with good caching performs excellently at a fraction of the infrastructure cost and complexity. Headless doubles the deployment surface, complicates previewing, and requires more maintenance.

Both expose WordPress content to external applications, but they use different query patterns.nnThe REST API uses URL-based endpoints - /wp-json/wp/v2/posts returns all posts, /wp-json/wp/v2/posts/123 returns a specific post. You get a fixed response shape for each endpoint. To get a post with its author, category, and featured image, you may need multiple requests or custom endpoints.nnWPGraphQL lets you write a single query that specifies exactly which fields you need. One query can fetch a post with its author name, category name, featured image URL, and ACF fields. No over-fetching, no multiple requests.nnFor Next.js or Gatsby: WPGraphQL is generally preferred because of its flexibility. For simpler integrations or server-to-server data sync: the REST API is simpler to configure and debug.

For REST API: in ACF PRO, open each field group, go to Settings, and enable Show in REST API. Fields appear under the acf key in REST API responses. For ACF Free or more granular control, use register_rest_field() to manually expose specific fields.nnFor WPGraphQL: install the WPGraphQL for ACF extension plugin. Then in each ACF field group settings, enable Show in GraphQL and set a GraphQL field name. The fields become queryable in the GraphQL schema.nnField type mapping matters: ACF image fields return an attachment ID by default in the REST API. You may need to register a custom field that returns the full image URL instead, or handle the ID-to-URL resolution in the frontend.

Preview in headless requires a secure connection between WordPress's preview button and the frontend framework.nnIn Next.js: Next.js has a built-in Preview Mode (Pages Router) and Draft Mode (App Router). You register a preview API route in Next.js that receives a secret token from WordPress, validates it, and sets a preview cookie. When the editor clicks Preview in WordPress, it calls this Next.js route, which redirects to the preview URL with the cookie set, telling Next.js to fetch draft content from the API.nnThe WordPress side: the preview redirect URL needs to point to your Next.js domain instead of the WordPress frontend. A custom preview_post_link filter handles this redirect.

Not inherently. SEO quality depends on the implementation, not the architecture.nnHeadless WordPress can be good for SEO when: the frontend is server-side rendered (Next.js SSR or SSG), meta tags are handled correctly via next/head or similar, and the site loads fast from a CDN edge network.nnHeadless WordPress can hurt SEO when: the frontend is a client-side-rendered SPA that Googlebot struggles to index, schema markup is not implemented in the frontend, or canonical URLs are misconfigured between the WordPress backend domain and the frontend domain.nnTraditional WordPress with Rank Math and good caching achieves comparable or better SEO results for most sites with significantly less implementation complexity.

Headless WordPress requires two hosting environments: one for WordPress (the backend) and one for the frontend.nnWordPress backend: any standard WordPress hosting works - SiteGround, Cloudways, Kinsta, or WP Engine. The WordPress installation does not serve pages to visitors directly in a headless setup, so server response time matters only for API response time, not page delivery speed. A mid-tier managed hosting plan is sufficient for most headless WordPress backends.nnFrontend: Next.js and Nuxt sites deploy to Vercel or Netlify (both have generous free tiers). Gatsby deploys to Netlify or Gatsby Cloud. The frontend is served from CDN edge nodes globally, which is the main performance advantage of headless.

Yes. WooCommerce exposes its product, order, and customer data via the WooCommerce REST API, and WPGraphQL has a WooCommerce extension (WPGraphQL WooCommerce) for GraphQL access.nnThe complexity is the checkout. WooCommerce's default checkout is PHP-rendered and does not work headlessly. Options for headless checkout: build a custom checkout flow in the frontend that uses the WooCommerce REST API to create orders, use a payment link service like Stripe Payment Links that bypasses WordPress checkout entirely, or use a separate checkout platform alongside WooCommerce as a product catalog.nnHeadless WooCommerce is significantly more complex than headless WordPress content sites and requires experienced frontend and backend developers working together.

Faust.js is WP Engine's open-source headless WordPress framework built on Next.js. It provides opinionated tooling for common headless WordPress patterns - authentication, preview mode, template hierarchy replication, and WPGraphQL integration.nnIt is worth considering when: you are building a headless WordPress site on Next.js and want a structured starting point that handles the common configuration patterns, or the project is hosted on WP Engine's Atlas headless hosting product.nnIt adds an abstraction layer that simplifies some patterns and complicates others. For projects with specific requirements that do not fit Faust.js's conventions, a custom Next.js plus WPGraphQL setup gives more flexibility.

Redirects in headless WordPress are more complex than traditional WordPress because the frontend framework - not WordPress - serves the pages, so WordPress redirects do not fire for frontend routes.nnThe standard approach: store redirects in WordPress (Rank Math's redirect manager or a custom post type), expose them via a custom REST API endpoint, and fetch them in the Next.js or Nuxt app's middleware or next.config.js redirects array.nnFor high redirect volumes (100+), fetch and cache the full redirect list at build time or use Next.js middleware to query the WordPress API per request and redirect dynamically. Cloudflare Workers can also handle redirects at the edge before the request reaches the frontend.

My specialization is the WordPress backend layer - REST API, WPGraphQL, content model design, authentication, webhooks, and ACF field structure. I configure the WordPress side so a frontend developer has a clean, well-documented API to work with.nnI do not build full Next.js or Nuxt frontends as a primary service. For projects that need both layers, I work best alongside a frontend developer who handles the React or Vue application, with clear API contracts agreed at the project start.nnIf you need a WordPress developer who can set up the headless backend correctly so your frontend team is not blocked by API issues, contact me.