WordPress 無頭 CMS：開發者指南 [2026]

WordPress 無頭 CMS：開發者指南 [2026]

根據 W3Techs 的數據，WordPress 驅動著 全球 43% 的網站，越來越多的團隊選擇完全移除 PHP 前端，將其用作內容 API。以下是關於以無頭模式運行 WordPress 所需了解的一切，從在 REST API 和 WPGraphQL 之間做出選擇，到在 Vercel 上透過 ISR 部署 Next.js 前端。

什麼是無頭 WordPress？（為什麼你應該關心？）

無頭 WordPress（Headless WordPress）是一種架構設定，其中 WordPress 負責內容管理和儲存，而另一個使用 Next.js、Nuxt、Astro 或任何框架建構的前端應用程式則透過 API 獲取這些內容。WordPress 保留其管理後台、編輯器、外掛生態系統和 MySQL 資料庫。但它不再使用 PHP 主題來渲染頁面，而是透過 WordPress REST API 或 WPGraphQL 暴露內容，由你的前端完全接管呈現層。

可以這樣想：WordPress 變成了廚房，而你的前端框架則是餐廳。廚房準備食物（內容），但餐廳決定如何擺盤、用餐區的樣子，以及客人如何體驗這頓飯。

傳統架構與無頭架構

在傳統的 WordPress 中，一切都是一個單體。訪客請求一個頁面，PHP 處理請求，查詢 MySQL，透過主題的模板文件運行，並傳回渲染後的 HTML。主題控制著佈局、樣式、路由等一切。

在無頭 WordPress 中，你移除了整個渲染層。WordPress 位於 API 之後，通常託管在 WP Engine 或 Kinsta 等受管主機上。你的前端（React、Vue 或 Svelte 應用程式）發出 API 請求以獲取內容，然後按照你想要的方式進行渲染。這兩個系統可以存在於完全不同的伺服器、不同的技術堆疊和不同的部署流程中。

這裡有一個細微差別，90% 的指南都忽略了：**解耦（Decoupled）和無頭（Headless）**並不完全相同。解耦的 WordPress 仍然可以對某些頁面（如管理區域或舊版路由）回退到 PHP 渲染。完全無頭意味著 WordPress 前端被完全禁用，它僅提供 API，沒有任何主題渲染。在本指南中，我們討論的是完全無頭的方法。

何時轉向無頭架構（何時保持傳統）

當你的團隊擁有希望使用現代工具的前端開發人員、你需要跨多個渠道（網頁、移動應用、數位看板）交付內容，或者效能是絕對必要條件時，轉向無頭架構是有意義的。但這並不適合所有人，誠實地面對這一點將為你節省數週的浪費精力。

以下情況請選擇無頭架構...

• 你的團隊已經熟悉 React/Vue/Svelte。 如果你的前端開發人員整天都在寫 JSX，強迫他們進入 PHP 主題就像要求廚師用微波爐做菜一樣。
• 你需要多渠道交付。 一個 WordPress 後端可以透過相同的 API 為你的行銷網站、移動應用和店內資訊亭提供內容。
• 效能是硬性要求。 從 CDN 邊緣提供的靜態頁面永遠會擊敗共享伺服器上的 PHP 渲染。
• 你正在運行無頭 WooCommerce。 複雜的電商前端能從自訂的 React/Next.js 店面中獲益良多。
• 你想要現代的開發者體驗（DX）。 熱模組替換（HMR）、TypeScript、元件庫、CI/CD，完整的前端工具鏈。

以下情況請保持傳統架構...

• 內容編輯者需要即時預覽和頁面建置器。 Gutenberg、Elementor 和 WPBakery 都假設存在傳統主題。轉向無頭架構會破壞大多數視覺化編輯工作流程。
• 你是獨立開發者或小團隊。 無頭架構增加了 40-60% 的設定複雜度。如果只有你一個人維護部落格，傳統主題更簡單。
• 你嚴重依賴前端外掛。 聯絡表單、SEO 外掛（Yoast 在伺服器端渲染 meta 標籤）、Cookie 同意橫幅，這些都假設存在 PHP 渲染。
• 預算緊張。 你需要為 WordPress 和你的前端分別購買主機。這是兩筆帳單而不是一筆。

REST API 與 WPGraphQL：選擇你的資料層

WordPress 在無頭設定中提供了兩種獲取內容的方式：內建的 REST API 和 WPGraphQL 外掛。REST API 隨 WordPress 核心一起提供，開箱即用，無需外掛。WPGraphQL 需要安裝外掛，但允許你精確查詢所需的欄位，消除了困擾 REST 的過度獲取（over-fetching）問題。根據我們的經驗，WPGraphQL 在大多數專案中勝出，但 REST 有一個被低估的優勢：原生 HTTP 快取。

WordPress REST API：內建選項

自 4.7 版（2016 年 12 月）以來，每個 WordPress 安裝都提供 REST API。訪問 /wp-json/wp/v2/posts，你就會得到 JSON。簡單、文件齊全，且零配置即可運作。

缺點是什麼？過度獲取。當你請求一篇文章時，WordPress 會返回所有內容：渲染後的內容、原始內容、摘要、作者 ID、特色媒體 ID、分類、標籤、元欄位、GUID、評論狀態、ping 狀態、模板，以及大約 15 個你可能不需要的其他欄位。對於只需要標題、別名和摘要的部落格列表頁面，你傳輸的數據量是必要量的 3-5 倍。

// REST API: Fetch 5 recent posts with author and categories
const res = await fetch(
  'https://your-site.com/wp-json/wp/v2/posts?per_page=5&_embed'
);
const posts = await res.json();

// The _embed parameter includes author and category objects
// But also includes EVERY field on each post -- ~8KB per post
// For 5 posts, you're looking at ~40KB of JSON

你可以使用 _fields 參數來限制返回的欄位（?_fields=id,title,slug,excerpt），但這對嵌入資源沒有幫助，如果你需要相關數據，仍然需要發出多個請求。

WPGraphQL：只查詢你需要的內容

WPGraphQL 是由 Jason Bahl 開發的免費開源外掛（現在由 WP Engine 維護），它為 WordPress 添加了完整的 GraphQL API。你編寫一個指定所需欄位的查詢，然後你會精確地得到這些內容，不多不少。

# WPGraphQL: Same query -- 5 recent posts with author and categories
query RecentPosts {
  posts(first: 5) {
    nodes {
      title
      slug
      excerpt
      date
      author {
        node {
          name
        }
      }
      categories {
        nodes {
          name
          slug
        }
      }
    }
  }
}

# Response: ~2KB of precisely structured JSON
# No extra fields, no bloat

程式碼並排比較

以下是回應負載的實際樣子：

應該選擇哪一個？

在以下情況使用 REST： 你正在快速構建某些東西，你的團隊不熟悉 GraphQL，或者你需要在不使用額外工具的情況下進行積極的 HTTP 快取。

在以下情況使用 WPGraphQL： 你正在構建具有複雜數據需求的生產級前端，你想要更小的負載，或者你的團隊已經在其他地方使用 GraphQL。

大膽結論： 對於使用 Next.js 的嚴肅無頭 WordPress 專案，WPGraphQL 是更好的選擇。負載節省、GraphiQL IDE 帶來的開發者體驗，以及單一請求數據獲取，使其值得依賴此外掛。

將 WordPress 設定為無頭 CMS

將 WordPress 設定為無頭 CMS 需要六個步驟：安裝 WordPress、添加正確的外掛、配置你的內容模型、禁用前端主題、設定身份驗證，並驗證你的 API 是否正常工作。如果你以前做過，整個過程大約需要 30-45 分鐘，如果是第一次，則需要幾個小時。

步驟 1： 在受管主機上開始全新的 WordPress 安裝。Kinsta、WP Engine 和 Cloudways 都提供針對 WordPress 優化的環境。如果你只是實驗，使用 LocalWP 進行本機安裝也可以。

步驟 2： 安裝必要的外掛：

步驟 3： 使用 ACF 建立你的內容模型。定義映射到你前端元件的欄位組。例如，作品集文章類型可能包含 projectUrl、techStack（重複器）、clientName 和 projectYear 等欄位。

必要外掛

WPGraphQL for ACF 值得特別關注。沒有它，你的 ACF 欄位不會出現在 GraphQL 查詢中。安裝後，你可以像這樣查詢自訂欄位：

query PortfolioProjects {
  projects(first: 10) {
    nodes {
      title
      slug
      projectFields {
        projectUrl
        clientName
        techStack
        projectYear
      }
    }
  }
}

禁用 WordPress 前端

步驟 4： 你不希望訪客點擊你的 WordPress URL 時看到損壞的主題。將此代碼添加到主題的 functions.php 或使用 mu-plugin：

// Redirect all frontend requests to the API
add_action('template_redirect', function () {
    if (!is_admin() && !wp_doing_ajax() && !defined('REST_REQUEST') && !defined('GRAPHQL_REQUEST')) {
        wp_redirect('https://your-frontend-domain.com');
        exit;
    }
});

步驟 5： 設定應用程式密碼以進行身份驗證。前往「使用者」>「你的個人資料」>「應用程式密碼」，生成一個密碼，並將其用於經過身份驗證的 API 請求（從外部工具建立/更新內容）。

測試你的 API

步驟 6： 打開瀏覽器並訪問 https://your-site.com/graphql，你應該會看到 GraphiQL IDE。嘗試查詢你的文章。如果你使用的是 REST，導航至 https://your-site.com/wp-json/wp/v2/posts 並驗證你是否收到 JSON 回應。

專業提示：WPGraphQL 附帶的 GraphiQL IDE 對於探索你的結構非常出色。你可以獲得自動完成、文件和查詢歷史記錄。這是找出可用欄位以及你的 ACF 數據如何結構化的最快方法。

使用 WPGraphQL 建構 Next.js 前端

在 2026 年，建構無頭 WordPress 前端最乾淨的方法是使用 Next.js 15 的 App Router 和 React Server Components。Server Components 在伺服器端獲取數據而無需向客戶端發送 JavaScript，而 WPGraphQL 提供精確的查詢，這是一對自然的組合。當我首次將 WPGraphQL 與 Next.js App Router 搭配使用時，最大的陷阱是圖片處理，但我們稍後會談到這一點。

專案設定與環境變數

從全新的 Next.js 專案開始。Vercel 還提供了一個 官方 WordPress 入門模板，如果你想要參考架構的話。

npx create-next-app@latest my-wp-frontend --typescript --app
cd my-wp-frontend

建立 .env.local 並填入你的 WordPress 端點：

WORDPRESS_API_URL=https://your-wordpress-site.com
NEXT_PUBLIC_WORDPRESS_GRAPHQL_ENDPOINT=https://your-wordpress-site.com/graphql

現在建立一個輕量級的 GraphQL 獲取工具。對於 Server Components，你不需要 Apollo 或 urql，普通的 fetch 就能完美運作，因為沒有客戶端狀態需要管理：

// lib/wordpress.ts
const API_URL = process.env.NEXT_PUBLIC_WORDPRESS_GRAPHQL_ENDPOINT!;

export async function fetchGraphQL<T>(
  query: string,
  variables?: Record<string, unknown>
): Promise<T> {
  const res = await fetch(API_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ query, variables }),
    next: { revalidate: 3600 }, // ISR: revalidate every hour
  });

  const json = await res.json();
  if (json.errors) {
    throw new Error(json.errors[0].message);
  }
  return json.data;
}

關於 React 框架選項，請查看我們對 Next.js 與使用 Vite 的純 React 的比較，跳過框架是有合理理由的，儘管對於無頭 CMS 工作來說，內建的 SSR 和 ISR 使 Next.js 成為實用的選擇。如果你在 Next.js 和 Remix 之間猶豫不決，我們在關於為什麼我們推薦在大多數專案中使用 Next.js 的文章中進行了詳細分析。

使用 Server Components 獲取文章

以下是作為 Server Component 的部落格列表頁面，沒有 useEffect，沒有載入狀態，沒有客戶端水合：

// app/blog/page.tsx
import { fetchGraphQL } from '@/lib/wordpress';
import Link from 'next/link';

interface PostsData {
  posts: {
    nodes: Array<{
      title: string;
      slug: string;
      excerpt: string;
      date: string;
      author: { node: { name: string } };
    }>;
  };
}

const POSTS_QUERY = `
  query AllPosts {
    posts(first: 20, where: { status: PUBLISH }) {
      nodes {
        title
        slug
        excerpt
        date
        author {
          node {
            name
          }
        }
      }
    }
  }
`;

export default async function BlogPage() {
  const data = await fetchGraphQL<PostsData>(POSTS_QUERY);

  return (
    <main>
      <h1>Blog</h1>
      {data.posts.nodes.map((post) => (
        <article key={post.slug}>
          <Link href={`/blog/${post.slug}`}>
            <h2>{post.title}</h2>
          </Link>
          <p>{post.author.node.name} · {new Date(post.date).toLocaleDateString()}</p>
          <div dangerouslySetInnerHTML={{ __html: post.excerpt }} />
        </article>
      ))}
    </main>
  );
}

動態文章頁面

個別文章頁面使用 generateStaticParams 在建置時預渲染所有文章，然後 ISR 會獲取新內容：

// app/blog/[slug]/page.tsx
import { fetchGraphQL } from '@/lib/wordpress';
import { notFound } from 'next/navigation';

const POST_QUERY = `
  query PostBySlug($slug: ID!) {
    post(id: $slug, idType: SLUG) {
      title
      content
      date
      author {
        node {
          name
          avatar {
            url
          }
        }
      }
      categories {
        nodes { name slug }
      }
    }
  }
`;

export async function generateStaticParams() {
  const data = await fetchGraphQL<{
    posts: { nodes: Array<{ slug: string }> };
  }>(`query { posts(first: 100) { nodes { slug } } }`);

  return data.posts.nodes.map((post) => ({ slug: post.slug }));
}

export default async function PostPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const data = await fetchGraphQL<{ post: any }>(POST_QUERY, {
    slug,
  });

  if (!data.post) notFound();

  return (
    <article>
      <h1>{data.post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: data.post.content }} />
    </article>
  );
}

別忘了為 WordPress 圖片配置 next.config.ts：

// next.config.ts
const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'your-wordpress-site.com',
        pathname: '/wp-content/uploads/**',
      },
    ],
  },
};

export default nextConfig;

將無頭 WordPress 部署到生產環境

生產環境的無頭 WordPress 設定使用雙重主機：WordPress 位於受管 WordPress 主機（WP Engine、Kinsta 或 Cloudways）上，而 Next.js 前端部署到 Vercel 或 Netlify 等邊緣平台。這種分離意味著每一層都可以獨立擴展，WordPress 處理內容編輯和 API 請求，而前端從全球 CDN 邊緣節點提供靜態和 ISR 頁面。

主機架構

數據流如下所示：內容編輯者在 WordPress 後台發布，WordPress 將內容儲存在 MySQL 中，Next.js 前端透過 WPGraphQL 獲取內容，Vercel 在邊緣生成靜態 HTML，訪客訪問 CDN，從未直接接觸 WordPress。

對於前端主機，請查看我們的 Vercel 與 Netlify 比較以獲得詳細分解。兩者都非常適合無頭 WordPress。如果你正在考慮基於容器的替代方案，我們的Railway、Render 和 Fly.io 比較也涵蓋了這些選項。

ISR 與按需重新驗證

這是讓無頭 WordPress 在生產環境中真正可行的部分。我們發現按需重新驗證值得投入設定精力，因為沒有它，你只能在陳舊內容（長重新驗證間隔）和緩慢的建置（短間隔會轟炸你的 WordPress API）之間做出選擇。

ISR 允許你在每個頁面上設定 revalidate 時間。在該間隔之後，下一個訪客會獲得快取頁面，而 Next.js 會在背景中重新生成它。但真正的魔力在於按需重新驗證，即在內容發布的瞬間觸發重建：

// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const secret = request.headers.get('x-revalidation-secret');

  if (secret !== process.env.REVALIDATION_SECRET) {
    return NextResponse.json({ message: 'Invalid secret' }, { status: 401 });
  }

  const body = await request.json();
  const slug = body.post?.post_name;

  if (slug) {
    revalidatePath(`/blog/${slug}`);
    revalidatePath('/blog'); // Also revalidate the listing page
  }

  return NextResponse.json({ revalidated: true });
}

在 WordPress 端，添加一個在 publish_post 時觸發的 webhook，使用像 WP Webhooks 這樣的外掛或簡單的 functions.php 代碼片段來呼叫你的 Vercel /api/revalidate 端點。現在，內容在點擊「發布」後的幾秒鐘內就會上線，無需完整重建，無需等待。有關更多配置選項，請參閱 Next.js ISR 文檔。

成本細分

WordPress 無頭架構與專用無頭 CMS 的比較

在使用過無頭 WordPress 和像 Sanity、Contentful 及 Strapi 這樣的專用 CMS 之後，以下是我的誠實看法：當你擁有現有的 WordPress 網站或內容團隊時，無頭 WordPress 是一個務實的選擇。但在從零開始時，它很少是最佳選擇。

無頭 WordPress 的優勢

• 內容編輯者已經熟悉它。 WordPress 的管理介面經過了 20 年的改進。培訓非技術團隊使用 Sanity Studio 或 Contentful 的介面需要數週時間。
• 外掛生態系統。 60,000+ 外掛。需要多語言？WPML。電商？WooCommerce。SEO 內容分析？Yoast（在後台中仍然有效）。沒有專用 CMS 能匹配這種廣度。
• 招聘。 WordPress 擁有所有 CMS 中最大的開發人員人才庫。尋找 WordPress 開發人員比尋找 Sanity 或 Payload 專家容易得多。
• WooCommerce。 如果你需要結合 WordPress 內容的無頭電商，WooCommerce + WPGraphQL 是一個經過驗證的堆疊。Saleor 和 Medusa 是替代方案，但 WooCommerce 佔據市場份額。

專用 CMS 的優勢

• 內容建模。 Sanity 的 GROQ、Contentful 的內容類型和 Payload 的 TypeScript 結構都是從底層為結構化內容設計的。WordPress 的文章/頁面/自訂文章類型模型感覺像是後來補上去的。
• 即時協作。 Sanity 擁有類似 Google Docs 的即時編輯功能。Contentful 擁有即時協作功能。WordPress？你只會得到一個「這篇文章正被其他人編輯」的鎖定畫面。
• API 優先架構。 WPGraphQL 很棒，但它仍然是坐在 PHP 單體之上的外掛。Contentful 的 API 和 Sanity 的 API 從第一天起就是為 API 優先設計的。
• 媒體處理。 WordPress 媒體庫功能正常但基礎。Sanity 的圖片管道具有自動裁剪、熱點和 CDN 交付，屬於不同層級。Contentful 和 Storyblok 原生整合 Cloudinary。
• 開發者體驗。 Strapi 和 Payload 提供本地開發體驗，結構變更時熱重載。WordPress 需要刷新後台並運行資料庫遷移。

結論：應該選擇哪一個？

在以下情況使用無頭 WordPress： 你擁有一個擁有多年內容的現有 WordPress 網站，你的編輯者拒絕學習新的 CMS，你需要 WooCommerce，或者你需要一個特定的 WordPress 外掛而在其他地方沒有等效品。

在以下情況選擇專用無頭 CMS： 你從零開始啟動新專案，你需要即時協作，你的內容模型複雜且結構化，或者你的團隊重視開發者體驗勝過外掛廣度。

在 Techsy，我們為從傳統 WordPress 遷移的客戶建構了無頭 WordPress 前端。我們的典型方法：在 Vercel 上使用 WPGraphQL + Next.js App Router，利用 ISR 提高效能，並使用按需重新驗證確保內容新鮮度。獲取免費諮詢 ->

WordPress MCP 與 Abilities API：AI 的未來

WordPress 6.9 引入了 Abilities API，該 API 正在合併到 WordPress 7.0 核心中（2026 年 4 月）。它建立了一個標準化、類型化、可發現的 WordPress 功能介面，可以將其視為 WordPress 以機器可讀的格式暴露其功能，AI 工具可以理解和使用這些功能。

WordPress MCP Adapter 將此 Abilities API 橋接到模型上下文協議（MCP），這是連接 AI 系統與外部工具的開放標準。這實際上意味著什麼？Claude、Cursor 或 VS Code 中的 AI 代理現在可以發現你的 WordPress 網站能做什麼，然後直接執行這些操作。

這是一個實際場景：Claude 可以建立一篇 WordPress 文章，用結構化數據填充 ACF 欄位，分配分類，設定特色圖片，並觸發你的 Vercel 重新驗證 webhook，所有這些都在一次對話中完成。無需瀏覽器，無需管理面板，無需複製貼上。

這處於早期階段，MCP 適配器仍在發展中。但它表明了一些重要的事情：當專用無頭 CMS 創新時，WordPress 並沒有停滯不前。Abilities API + MCP 的組合可以使 WordPress 成為最容易訪問 AI 的 CMS 之一，以更新、更小的平台無法匹敵的方式利用其龐大的外掛生態系統。閱讀 WordPress 開發者部落格上的官方公告 以獲取完整的技術細節。

效能：無頭 WordPress 與傳統 WordPress

與傳統 PHP 渲染的 WordPress 相比，帶有靜態前端的無頭 WordPress 顯著提高了效能。傳統 WordPress 透過在每個請求上運行 PHP 來提供動態頁面，導致首字節時間（TTFB）較差，根據 2025 年中期的效能數據，只有 31% 的桌面 WordPress 用戶和 24% 的移動用戶看到良好的 TTFB 分數。使用 Next.js 和 ISR 轉向無頭架構意味著頁面是預渲染的並從 CDN 邊緣節點提供，將快取頁面的 TTFB 降低到 100ms 以下。

WP Engine 關於 Android Authority 的案例研究顯示，遷移到無頭 WordPress 後，Lighthouse 效能分數提高了 6 倍。核心網頁指標（Core Web Vitals）數據講述了類似的故事：只有 45% 的 WordPress 網站在移動設備上通過所有三個 CWV 指標，而 Shopify 為 65%，Duda 為 83%。

一個重要的警告：無頭架構無法修復緩慢的 WordPress 後端。如果你的 WordPress API 因為使用廉價的共享主機和 40 個外掛而需要 3 秒才能響應，那麼你的 ISR 重新生成也會很慢。前端不能比它所依賴的 API 更快。投資優質的受管主機，這在無頭設定中更重要，而不是更少。WordPress 效能負責人 Weston Ruter 的部落格 擁有關於什麼真正影響 WordPress 伺服器效能的優秀數據。

常見問題

什麼是無頭 WordPress？

無頭 WordPress 是一種架構，其中 WordPress 僅作為內容管理後端，其 PHP 前端主題被完全禁用。內容透過 REST API 或 WPGraphQL 傳遞給使用 Next.js、Nuxt 或 Astro 等框架建構的單獨前端應用程式。WordPress 管理後台對內容編輯者保持完全功能。

WordPress 作為無頭 CMS 好嗎？

當你擁有現有的 WordPress 網站、熟悉介面的內容編輯者，或需要外掛生態系統（特別是 WooCommerce）時，WordPress 作為無頭 CMS 運作良好。當從零開始時，它不如 Sanity 或 Contentful 等專用無頭 CMS 理想，因為 WordPress 的內容建模和 API 是後期改造的，而不是從 API 優先建構的。

無頭 WordPress 的缺點是什麼？

主要缺點包括：複雜性增加（兩個主機環境而不是一個）、失去視覺化編輯和頁面建置器功能、前端外掛停止工作（Yoast meta 渲染、聯絡表單、Cookie 橫幅）、沒有即時內容協作，以及 GraphQL API 是外掛依賴項而不是核心功能。預算也會增加，因為你需要支付 WordPress 主機和前端主機的費用。

如何將 Next.js 連接到 WordPress？

在你的 WordPress 網站上安裝 WPGraphQL，然後建立一個帶有 App Router 的 Next.js 專案。將你的 WordPress GraphQL 端點設定為環境變數，編寫一個簡單的基於 fetch 的 GraphQL 工具函數，並在 Server Components 中使用它來查詢文章、頁面和自訂內容類型。不需要 Apollo 或 urql，普通的 fetch 就能運作，因為 Server Components 在伺服器端運行。

WPGraphQL 與 REST API，哪個更好？

WPGraphQL 更適合生產前端，因為它只返回你請求的欄位（減少 60-80% 的負載大小），支援在單一請求中進行嵌套查詢，並提供 GraphiQL IDE 進行結構探索。REST API 更適合快速原型設計、不熟悉 GraphQL 的團隊，或者在不需要額外工具的情況下原生 HTTP 快取至關重要的場景。

無頭 WordPress 的成本是多少？

最小的無頭 WordPress 設定每月成本約為 $14，Cloudways 用於 WordPress 主機加上 Vercel 的免費 Hobby 層級用於前端。帶有 WP Engine 和 Vercel Pro 的生產設定每月運行成本為 $40-70。為 ACF Pro 和 WPML 等高階外掛增加 $0-50/月。專用無頭 CMS 通常有慷慨的免費層級，因此僅憑成本並不是選擇無頭 WordPress 的理由。

我可以將 WooCommerce 與無頭 WordPress 一起使用嗎？

可以。WPGraphQL 有一個 WooCommerce 擴充功能（WPGraphQL WooCommerce 或 "WooGraphQL"），透過 GraphQL 暴露產品、訂單、購物車和結帳功能。這讓你能夠建構具有完整電商功能的自訂 React 店面。與傳統 WooCommerce 主題相比，結帳流程需要額外的工作，但對於高流量商店來說，效能和 UX 的提升是顯著的。

我需要開發人員來設定無頭 WordPress 嗎？

是的，無頭 WordPress 設定需要前端開發技能，特別是 React（或 Vue/Svelte）和對 API 的熟悉。你需要從頭開始建構整個前端或自訂入門模板。這不是無代碼解決方案。內容編輯者仍然可以正常使用 WordPress 後台，但初始設定和持續的前端維護需要開發人員參與。

無頭 WordPress 的必要外掛有哪些？

必要的外掛是 WPGraphQL（GraphQL API）、Advanced Custom Fields 或 ACF（結構化內容建模），以及 WPGraphQL for ACF（透過 GraphQL 暴露自訂欄位）。強烈建議：Custom Post Type UI 用於透過後台註冊文章類型，以及像 WP Webhooks 這樣的 webhook 外掛用於在內容發布時觸發前端重建。避免依賴前端的外掛，如 Yoast SEO 的 meta 渲染或表單外掛。

無頭 WordPress 對 SEO 有好處嗎？

如果正確實施（使用 Next.js 或 Nuxt），無頭 WordPress 對 SEO 非常有利，因為你可以獲得伺服器端渲染、更快的頁面載入速度（改善核心網頁指標），以及對 meta 標籤、結構化數據和 URL 結構的完全控制。風險是你會失去自動 SEO 外掛功能，如 Yoast 的 meta 標籤渲染，你需要在前端代碼中手動處理 meta 標籤、站點地圖和結構化數據。