Skip to main content
RapidDev - Software Development Agency
bolt-ai-integrationsBolt Chat + API Route

How to Integrate Bolt.new with Yoast SEO

Use Yoast SEO data in a Bolt.new headless frontend by fetching WordPress posts through the REST API — Yoast's meta titles, descriptions, canonical URLs, and schema.org JSON-LD are available in the yoast_head_json field on every post and page response. No standalone Yoast API exists; this integration works through WordPress's built-in REST API.

What you'll learn

  • How to fetch Yoast SEO metadata from WordPress REST API in a headless CMS architecture
  • How to use Yoast's meta titles and descriptions in Bolt's React pages with next/head or react-helmet-async
  • How to inject Yoast's schema.org JSON-LD structured data into the Bolt frontend
  • How to build an SEO-optimized blog or content site in Bolt.new using WordPress as the CMS
  • How the yoast_head_json field structure works and which fields to use for each SEO element
Book a free consultation
4.9Clutch rating
600+Happy partners
17+Countries served
190+Team members
Intermediate14 min read30 minutesSEOApril 2026RapidDev Engineering Team
TL;DR

Use Yoast SEO data in a Bolt.new headless frontend by fetching WordPress posts through the REST API — Yoast's meta titles, descriptions, canonical URLs, and schema.org JSON-LD are available in the yoast_head_json field on every post and page response. No standalone Yoast API exists; this integration works through WordPress's built-in REST API.

Using WordPress + Yoast SEO as a Headless CMS for Bolt.new

Yoast SEO is the most installed WordPress plugin with 10+ million active installations. It handles the SEO metadata layer that makes WordPress sites rank well: custom meta titles and descriptions, canonical URLs, Open Graph and Twitter Card tags, robots directives, and comprehensive schema.org JSON-LD structured data for rich results. When teams build a headless frontend in Bolt.new that fetches content from WordPress, they need to carry over Yoast's carefully configured SEO data to maintain rankings and rich snippet eligibility.

Yoast doesn't have a standalone REST API — but it doesn't need one. When Yoast is installed on a WordPress site, it automatically enriches every WordPress REST API response with a `yoast_head` field (raw HTML) and a `yoast_head_json` field (parsed object with all SEO properties). Any request to `https://yoursite.com/wp-json/wp/v2/posts/{id}` or `https://yoursite.com/wp-json/wp/v2/pages/{id}` includes this data automatically. No additional plugins or configuration are needed beyond having Yoast installed.

The integration pattern in Bolt.new: a Next.js API route fetches posts from the WordPress REST API including `yoast_head_json`, transforms the data into a format the React frontend uses, and passes the SEO metadata as props to page components. The page component then renders the SEO tags in the document head using Next.js's built-in `<Head>` component or react-helmet-async. This gives you Yoast's carefully authored meta titles and descriptions in your Bolt-built frontend rather than defaulting to raw post titles and excerpts.

Integration method

Bolt Chat + API Route

Yoast SEO has no standalone API. When WordPress is used as a headless CMS for a Bolt.new frontend, Yoast's SEO metadata is available through WordPress REST API responses in the yoast_head_json field. A Next.js API route fetches posts with their Yoast SEO data server-side, and the frontend uses that metadata for page titles, meta descriptions, canonical URLs, and JSON-LD structured data injection.

Prerequisites

  • A WordPress site with Yoast SEO plugin installed (free or premium version both expose yoast_head_json)
  • WordPress REST API enabled (enabled by default on WordPress 4.7+, accessible at yourdomain.com/wp-json/)
  • A Bolt.new project using Next.js (recommended for server-side WordPress API calls and SSG/ISR support)
  • Your WordPress site's REST API base URL (e.g., https://yourblog.com/wp-json/wp/v2)
  • Basic understanding of HTML meta tags and how Next.js handles the document head

Step-by-step guide

1

Verify Yoast REST API Data and Understand yoast_head_json

Before building the integration, verify that your WordPress site exposes Yoast data via the REST API. Open your browser and visit: `https://yourwordpresssite.com/wp-json/wp/v2/posts?per_page=1`. In the JSON response, find the `yoast_head_json` field — it should be an object containing Yoast's SEO metadata. If `yoast_head_json` is missing, it means Yoast SEO is not installed or the `yoast_head` field is blocked (some security plugins block REST API field extensions). The `yoast_head_json` object contains: `title` (the SEO meta title), `description` (meta description), `canonical` (canonical URL), `og_title` and `og_description` (Open Graph tags for social sharing), `og_image` (array with image URL for social cards), `robots` (noindex/nofollow settings), and `schema` (the full schema.org JSON-LD object including @context, @graph with Article, BreadcrumbList, and WebPage schemas). The `yoast_head` field contains the same data as raw HTML — a string of meta tags ready to be injected. The `yoast_head_json` field is preferable for programmatic use because it's already parsed into a JavaScript object. Note that to get the yoast_head_json for pages, use `/wp-json/wp/v2/pages/{id}` — pages and posts have separate endpoints.

Bolt.new Prompt

Set up WordPress + Yoast integration. Create a .env file with NEXT_PUBLIC_WP_API_URL=https://yoursite.com/wp-json/wp/v2 and NEXT_PUBLIC_SITE_URL=https://yourboltapp.com. Create lib/wordpress.ts with a typed interface for the WordPress post response including the yoast_head_json fields, and an async getPosts() function that fetches from the WP API.

Paste this in Bolt.new chat

lib/wordpress.ts
1// lib/wordpress.ts
2export interface YoastHeadJson {
3 title?: string;
4 description?: string;
5 canonical?: string;
6 og_title?: string;
7 og_description?: string;
8 og_image?: Array<{ url: string; width?: number; height?: number }>;
9 og_type?: string;
10 robots?: Record<string, string>;
11 schema?: {
12 '@context': string;
13 '@graph': unknown[];
14 };
15 article_published_time?: string;
16 article_modified_time?: string;
17}
18
19export interface WPPost {
20 id: number;
21 slug: string;
22 date: string;
23 modified: string;
24 title: { rendered: string };
25 excerpt: { rendered: string };
26 content: { rendered: string };
27 yoast_head_json: YoastHeadJson;
28 _embedded?: {
29 author?: Array<{ name: string }>;
30 'wp:featuredmedia'?: Array<{ source_url: string }>;
31 };
32}
33
34const WP_API = process.env.NEXT_PUBLIC_WP_API_URL
35 ?? process.env.WP_API_URL
36 ?? '';
37
38export async function getPosts(perPage = 10, page = 1): Promise<WPPost[]> {
39 const res = await fetch(
40 `${WP_API}/posts?per_page=${perPage}&page=${page}&_embed=true`,
41 { next: { revalidate: 3600 } }
42 );
43 if (!res.ok) throw new Error(`WP API error: ${res.status}`);
44 return res.json();
45}
46
47export async function getPostBySlug(slug: string): Promise<WPPost | null> {
48 const res = await fetch(
49 `${WP_API}/posts?slug=${slug}&_embed=true`,
50 { next: { revalidate: 3600 } }
51 );
52 if (!res.ok) return null;
53 const posts: WPPost[] = await res.json();
54 return posts[0] ?? null;
55}

Pro tip: Add `_embed=true` to WordPress REST API requests to get the featured image and author data in a single call. Without it, these fields are empty and require additional requests. The `next: { revalidate: 3600 }` enables Next.js ISR — posts are re-fetched from WordPress every hour without a full rebuild.

Expected result: The lib/wordpress.ts module fetches WordPress posts with Yoast SEO data. The YoastHeadJson TypeScript interface provides autocomplete for all Yoast metadata fields when used in page components.

2

Build a Next.js API Route for WordPress Posts

Create a server-side API route that proxies WordPress REST API calls. While WordPress's REST API is public and could technically be called client-side, using a Next.js API route provides several advantages: you can transform the response shape to match your frontend's needs (renaming verbose WordPress fields, stripping unused data), add caching headers to reduce load on your WordPress server, handle authentication for password-protected posts or private content, and avoid exposing your WordPress backend URL in client-side code (important if you're using a separate WordPress install that shouldn't be crawled by search engines). The route fetches posts with `_embed=true` to get featured images and author data in a single request, extracts the Yoast metadata from `yoast_head_json`, and returns a clean JSON structure. For ISR (Incremental Static Regeneration) — the recommended caching strategy for blog pages in Next.js — the WordPress API calls happen at build time and on scheduled revalidation, not on every user request. This means your Bolt frontend serves fast static pages while WordPress content stays current.

Bolt.new Prompt

Create a Next.js API route at app/api/wp/posts/route.ts that fetches posts from the WordPress REST API using WP_API_URL env var. Return a cleaned version of each post with: id, slug, title, excerpt, publishedAt, featuredImage (from _embedded wp:featuredmedia), and seo (from yoast_head_json with title, description, canonical, ogImage). Limit to 10 posts by default.

Paste this in Bolt.new chat

app/api/wp/posts/route.ts
1// app/api/wp/posts/route.ts
2import { NextRequest, NextResponse } from 'next/server';
3import { getPosts, WPPost } from '@/lib/wordpress';
4
5function transformPost(post: WPPost) {
6 const yoast = post.yoast_head_json ?? {};
7 return {
8 id: post.id,
9 slug: post.slug,
10 title: post.title.rendered.replace(/<[^>]+>/g, ''),
11 excerpt: post.excerpt.rendered.replace(/<[^>]+>/g, '').trim(),
12 publishedAt: post.date,
13 modifiedAt: post.modified,
14 featuredImage: post._embedded?.['wp:featuredmedia']?.[0]?.source_url ?? null,
15 author: post._embedded?.author?.[0]?.name ?? 'Anonymous',
16 seo: {
17 title: yoast.title ?? post.title.rendered.replace(/<[^>]+>/g, ''),
18 description: yoast.description ?? post.excerpt.rendered.replace(/<[^>]+>/g, ''),
19 canonical: yoast.canonical ?? '',
20 ogImage: yoast.og_image?.[0]?.url ?? null,
21 robots: yoast.robots ?? {},
22 jsonLd: yoast.schema ?? null,
23 },
24 };
25}
26
27export async function GET(request: NextRequest) {
28 const page = parseInt(request.nextUrl.searchParams.get('page') ?? '1');
29 const perPage = Math.min(
30 parseInt(request.nextUrl.searchParams.get('per_page') ?? '10'),
31 50
32 );
33
34 try {
35 const posts = await getPosts(perPage, page);
36 return NextResponse.json(
37 { posts: posts.map(transformPost) },
38 { headers: { 'Cache-Control': 's-maxage=3600, stale-while-revalidate' } }
39 );
40 } catch (error) {
41 const message = error instanceof Error ? error.message : 'Unknown error';
42 return NextResponse.json({ error: message }, { status: 500 });
43 }
44}

Pro tip: The .replace(/<[^>]+>/g, '') regex strips HTML tags from the title and excerpt — WordPress REST API returns these fields with HTML entities and tags by default. Always sanitize WordPress content fields before rendering them in React to prevent XSS.

Expected result: Visiting /api/wp/posts returns a JSON array of posts with clean titles, excerpts, and structured seo objects containing Yoast's configured titles, descriptions, and canonical URLs.

3

Inject Yoast SEO Metadata in React Pages

With the WordPress + Yoast data flowing into the Bolt frontend, implement the SEO metadata injection in the React page components. In Next.js App Router, metadata is defined using the `generateMetadata` async function exported from page.tsx — it's the correct way to set page-level SEO tags that search engines read. The function receives the route params (including the post slug), fetches the post data (including Yoast SEO fields), and returns a Next.js Metadata object. The Metadata object accepts title, description, canonical, and openGraph properties that map directly to Yoast's fields. For schema.org JSON-LD structured data — which Yoast generates as a `@graph` array with Article, BreadcrumbList, and WebSite schemas — use a `<script type='application/ld+json'>` tag rendered in the page component. Next.js doesn't inject JSON-LD via the Metadata object, so it must be included as a script element directly in the JSX. Search engines read both HTML head meta tags and in-page JSON-LD script tags, so this approach maintains full schema compatibility from Yoast.

Bolt.new Prompt

Create a dynamic Next.js blog post page at app/blog/[slug]/page.tsx. Add a generateMetadata function that fetches the post by slug and returns Next.js Metadata with title and description from yoast_head_json. In the page component, fetch the post content and render: title as h1, content with dangerouslySetInnerHTML, and a JSON-LD script tag from yoast_head_json.schema if it exists.

Paste this in Bolt.new chat

app/blog/[slug]/page.tsx
1// app/blog/[slug]/page.tsx
2import type { Metadata } from 'next';
3import { getPostBySlug } from '@/lib/wordpress';
4import { notFound } from 'next/navigation';
5
6interface Props {
7 params: { slug: string };
8}
9
10export async function generateMetadata({ params }: Props): Promise<Metadata> {
11 const post = await getPostBySlug(params.slug);
12 if (!post) return { title: 'Not Found' };
13
14 const yoast = post.yoast_head_json;
15 const siteUrl = process.env.NEXT_PUBLIC_SITE_URL ?? '';
16
17 return {
18 title: yoast.title ?? post.title.rendered,
19 description: yoast.description ?? undefined,
20 alternates: {
21 canonical: yoast.canonical
22 ? yoast.canonical.replace(
23 new URL(yoast.canonical).origin,
24 siteUrl
25 )
26 : `${siteUrl}/blog/${params.slug}`,
27 },
28 openGraph: {
29 title: yoast.og_title ?? yoast.title,
30 description: yoast.og_description ?? yoast.description,
31 images: yoast.og_image?.map((img) => ({ url: img.url })) ?? [],
32 type: 'article',
33 publishedTime: post.date,
34 modifiedTime: post.modified,
35 },
36 robots: yoast.robots ?? undefined,
37 };
38}
39
40export default async function BlogPost({ params }: Props) {
41 const post = await getPostBySlug(params.slug);
42 if (!post) notFound();
43
44 const yoast = post.yoast_head_json;
45
46 // Rewrite canonical URL to point to Bolt frontend, not WordPress
47 const siteUrl = process.env.NEXT_PUBLIC_SITE_URL ?? '';
48 const schema = yoast.schema
49 ? JSON.stringify(yoast.schema).replace(
50 /https?:\/\/[^"]+\/wp-json/g,
51 siteUrl
52 )
53 : null;
54
55 return (
56 <article>
57 {schema && (
58 <script
59 type="application/ld+json"
60 dangerouslySetInnerHTML={{ __html: schema }}
61 />
62 )}
63 <h1 dangerouslySetInnerHTML={{ __html: post.title.rendered }} />
64 <div
65 className="prose"
66 dangerouslySetInnerHTML={{ __html: post.content.rendered }}
67 />
68 </article>
69 );
70}

Pro tip: The canonical URL rewrite is important: Yoast generates canonical URLs pointing to the WordPress backend (yourwordpresssite.com/post-slug). In a headless architecture, the canonical must point to the Bolt frontend URL instead. The string replacement swaps the WordPress origin for the NEXT_PUBLIC_SITE_URL.

Expected result: Blog post pages render with Yoast's configured meta titles and descriptions in the HTML head. Google sees proper canonical URLs pointing to the Bolt frontend. JSON-LD structured data enables rich results in search.

4

Deploy and Configure URL Rewriting for SEO

Deploying a headless WordPress + Yoast Bolt app requires coordinating two critical SEO configurations: the canonical URL rewriting mentioned above, and ensuring search engines discover and crawl the Bolt frontend rather than the WordPress backend. For canonical URLs, every page in Bolt must have a canonical pointing to the Bolt frontend URL — not the WordPress URL. The generateMetadata function handles this with the NEXT_PUBLIC_SITE_URL replacement. The WordPress site itself should be configured to discourage search engine indexing (WordPress Dashboard → Settings → Reading → Discourage search engines from indexing this site) so Google doesn't index both the WordPress backend and the Bolt frontend for the same content. WordPress robots.txt can also be configured to block crawlers from the wp-json endpoints. Deploy to Netlify or Bolt Cloud: connect via Settings → Applications → Netlify or click Publish to Bolt Cloud. After deploying, set these environment variables: `WP_API_URL` (your WordPress REST API URL without the public prefix — used server-side), `NEXT_PUBLIC_WP_API_URL` (same URL but public, for client-side preview functionality if needed), and `NEXT_PUBLIC_SITE_URL` (your deployed Bolt app URL for canonical generation). Bolt's WebContainer cannot receive incoming connections, so WordPress webhook notifications (for cache invalidation when posts are published) require the deployed URL.

Bolt.new Prompt

Add ISR revalidation to my blog. In the Next.js route handler at app/api/revalidate/route.ts, accept a POST request with a secret token and post slug. Call Next.js revalidatePath for /blog/[slug] to clear the ISR cache when WordPress publishes or updates a post. I'll register this URL as a webhook in WordPress.

Paste this in Bolt.new chat

app/api/revalidate/route.ts
1// app/api/revalidate/route.ts
2import { NextRequest, NextResponse } from 'next/server';
3import { revalidatePath } from 'next/cache';
4
5export async function POST(request: NextRequest) {
6 const { slug, secret } = await request.json();
7
8 if (secret !== process.env.REVALIDATION_SECRET) {
9 return NextResponse.json({ error: 'Invalid secret' }, { status: 401 });
10 }
11
12 if (!slug) {
13 return NextResponse.json({ error: 'slug is required' }, { status: 400 });
14 }
15
16 revalidatePath(`/blog/${slug}`);
17 revalidatePath('/blog');
18
19 return NextResponse.json({ revalidated: true, slug });
20}
21
22// Register this as a WordPress webhook:
23// In WordPress, use a plugin like WP Webhooks or custom code:
24// POST https://yourboltapp.com/api/revalidate
25// Body: { "slug": "post-slug", "secret": "your-secret" }
26// Trigger: on_post_publish, on_post_update

Pro tip: The revalidation webhook only works on the deployed site — Bolt's WebContainer cannot receive incoming POST requests during development. Add REVALIDATION_SECRET to your hosting platform's environment variables. In WordPress, use a plugin like WP Webhooks to POST to this endpoint whenever a post is published or updated.

Expected result: When a WordPress post is published or updated, WordPress sends a webhook to the deployed Bolt app's /api/revalidate endpoint, which clears the ISR cache for that page. New visitors see the updated content within seconds.

Common use cases

Headless WordPress Blog with Full Yoast SEO

Build a Bolt.new blog frontend that fetches posts from WordPress, displays content with Yoast's meta titles and descriptions in the page head, includes schema.org Article markup for rich results, and passes canonical URLs to avoid duplicate content issues. The Bolt frontend handles the rendering; WordPress handles content management and Yoast handles the SEO metadata.

Bolt.new Prompt

Build a headless WordPress blog using Next.js. Create a Next.js API route at /api/wp/posts that fetches posts from my WordPress REST API at NEXT_PUBLIC_WP_API_URL/wp/v2/posts?_embed=true. Each post page at /blog/[slug] should set the page title and meta description from the yoast_head_json fields title and description. Include the Yoast schema field as a JSON-LD script tag.

Copy this prompt to try it in Bolt.new

SEO Meta Tag Preview Component

Build an admin preview component that shows how any WordPress post will appear in Google Search results and social media sharing, using Yoast's configured metadata. Useful for content editors reviewing posts before publishing — they can see the search snippet preview without leaving the Bolt frontend admin.

Bolt.new Prompt

Create an SEO preview component that accepts a yoast_head_json object and displays a Google Search result preview (title in blue, URL in green, description in gray) and a social media card preview using og_title, og_description, and og_image. Fetch the Yoast metadata from /api/wp/posts/{id} and show the preview below the post content in my admin view.

Copy this prompt to try it in Bolt.new

Dynamic Sitemap from WordPress + Yoast

Generate an XML sitemap for the Bolt.new frontend based on WordPress posts, using Yoast's canonical URLs and sitemap priority settings. Yoast automatically generates a sitemap for WordPress, but for headless frontends you need to generate one that points to the Bolt frontend URLs, not the WordPress backend.

Bolt.new Prompt

Create a Next.js API route at /api/sitemap.xml that fetches all published posts from the WordPress REST API, gets their slugs and modified dates, and generates a valid XML sitemap with entries pointing to my Bolt frontend URL (NEXT_PUBLIC_SITE_URL/blog/{slug}). Output the response as text/xml content type.

Copy this prompt to try it in Bolt.new

Troubleshooting

yoast_head_json field is missing from WordPress REST API responses

Cause: Yoast SEO is not installed, or a security plugin (like Wordfence or WP Cerber) is stripping non-core fields from REST API responses.

Solution: Verify Yoast SEO is installed and activated on the WordPress site. Test by visiting your-site.com/wp-json/wp/v2/posts?per_page=1 and searching for 'yoast' in the response. If missing, check your WordPress security plugin settings for REST API field filtering options.

typescript
1// Fallback to title and excerpt if yoast_head_json is missing
2const seoTitle = post.yoast_head_json?.title ?? post.title.rendered;
3const seoDesc = post.yoast_head_json?.description ?? post.excerpt.rendered.replace(/<[^>]+>/g, '');

Canonical URLs in the HTML head point to the WordPress backend URL instead of the Bolt frontend

Cause: The NEXT_PUBLIC_SITE_URL environment variable is not set, or the canonical URL rewriting logic in generateMetadata is not running.

Solution: Set NEXT_PUBLIC_SITE_URL to your Bolt frontend's deployed URL (e.g., https://myblog.netlify.app). Verify the rewriting logic in generateMetadata replaces the WordPress origin correctly. After deploying, inspect page source to confirm the canonical tag shows your Bolt URL.

typescript
1// Ensure the rewrite replaces the WP origin
2const wpOrigin = new URL(process.env.WP_API_URL ?? '').origin;
3const frontendUrl = process.env.NEXT_PUBLIC_SITE_URL ?? '';
4const canonical = yoast.canonical?.replace(wpOrigin, frontendUrl) ?? `${frontendUrl}/blog/${slug}`;

JSON-LD script tag renders but contains WordPress backend URLs instead of frontend URLs

Cause: Yoast's schema.org data references the WordPress backend domain in @id fields and URL properties. These must be rewritten to the Bolt frontend domain for correct structured data.

Solution: After fetching the schema from yoast_head_json.schema, stringify and replace all occurrences of the WordPress origin with the Bolt frontend URL before injecting as JSON-LD.

typescript
1const wpOrigin = new URL(process.env.WP_API_URL ?? 'https://wordpress.example.com').origin;
2const frontendOrigin = process.env.NEXT_PUBLIC_SITE_URL ?? '';
3const cleanSchema = JSON.stringify(yoast.schema ?? {})
4 .replaceAll(wpOrigin, frontendOrigin);
5// Then: <script type='application/ld+json' dangerouslySetInnerHTML={{ __html: cleanSchema }} />

Best practices

  • Always rewrite canonical URLs from the WordPress backend domain to the Bolt frontend domain — duplicate canonical URLs will cause Google to prefer one domain over the other
  • Block WordPress backend from search engine indexing (Settings → Reading) when using it as a headless CMS — search engines should only index the Bolt frontend
  • Use the generateMetadata function in Next.js App Router (not react-helmet-async) for SEO tags — it handles SSR/SSG correctly and is the canonical Next.js approach
  • Add ISR revalidation webhooks from WordPress to clear Bolt's page cache when content is published or updated
  • Include Yoast's schema.org JSON-LD in pages — it enables rich results (article dates, breadcrumbs, site search) that can significantly improve click-through rates
  • Sanitize WordPress HTML content fields before rendering — use DOMPurify client-side or strip tags server-side to prevent XSS from malicious WordPress content
  • Test your SEO implementation with Google's Rich Results Test (search.google.com/test/rich-results) after deploying to verify schema.org structured data is parsed correctly

Alternatives

Frequently asked questions

Does Yoast SEO have its own REST API I can call from Bolt.new?

No. Yoast SEO does not have a standalone REST API. It extends the WordPress REST API by adding a yoast_head_json field to post and page responses. This means you access Yoast data through WordPress REST API endpoints, not through any Yoast-specific endpoint. Having WordPress installed with Yoast active is the only way to get programmatic access to Yoast metadata.

Will my Bolt frontend's Yoast SEO metadata be indexed correctly by Google?

Yes, with proper configuration. Next.js's generateMetadata function renders SEO tags server-side in the HTML that Google's crawler receives. The key requirements are: correct canonical URLs pointing to the Bolt frontend (not WordPress), schema.org JSON-LD injected as a script tag, and the WordPress backend blocked from being indexed. After deploying, verify with Google Search Console and the Rich Results Test.

What's the yoast_head vs yoast_head_json difference?

Both fields contain the same data. yoast_head is a raw HTML string of meta tags, link tags, and script tags ready to be injected into the HTML head. yoast_head_json is the same data parsed into a JavaScript object, which is much easier to work with programmatically. Use yoast_head_json for building React-based frontends in Bolt — it gives you typed access to individual fields like title, description, canonical, og_image, and schema.

Can I test the headless WordPress integration in Bolt's WebContainer preview?

Yes for most functionality. The WordPress REST API calls are outbound HTTPS requests from the Next.js API routes, which work fine in Bolt's WebContainer. You can fetch posts, see Yoast SEO data, and verify the content rendering in the preview. The one exception is the ISR revalidation webhook — Bolt's WebContainer cannot receive incoming POST requests, so cache invalidation webhooks from WordPress must be registered with the deployed URL.

What if my WordPress site is private or requires authentication for the REST API?

If your WordPress site restricts REST API access, add WordPress application passwords: in WordPress Dashboard, go to Users → Your Profile → Application Passwords → Add New. Use the generated username and password in HTTP Basic Auth headers in your Next.js API route. Store the credentials in environment variables (WP_USERNAME and WP_APP_PASSWORD) — never in client-side code.

RapidDev

Talk to an Expert

Our team has built 600+ apps. Get personalized help with your project.

Book a free consultation

Need help with your project?

Our experts have built 600+ apps and can accelerate your development. Book a free consultation — no strings attached.

Book a free consultation

We put the rapid in RapidDev

Need a dedicated strategic tech and growth partner? Discover what RapidDev can do for your business! Book a call with our team to schedule a free, no-obligation consultation. We'll discuss your project and provide a custom quote at no cost.