WordPress Headless CMS: Geliştirici Rehberi [2026]

WordPress Headless CMS: Geliştirici Rehberi [2026]

W3Techs verilerine göre WordPress, tüm web sitelerinin %43'ünü çalıştırıyor; giderek daha fazla ekip de PHP frontend'ini tamamen atıp WordPress'i bir içerik API'si olarak kullanmaya başlıyor. İşte headless WordPress çalıştırma hakkında bilmeniz gereken her şey — REST API ile WPGraphQL arasında seçim yapmaktan ISR ile Vercel'e Next.js frontend dağıtımına kadar.

Headless WordPress Nedir? (Ve Neden Önemli?)

Headless WordPress, WordPress'in içerik yönetimi ve depolamasını üstlendiği, ayrı bir frontend uygulamasının — Next.js, Nuxt, Astro veya herhangi bir framework ile oluşturulmuş — içeriği bir API aracılığıyla çektiği bir kurulumu ifade eder. WordPress yönetici panosunu, editörünü, eklenti ekosistemini ve MySQL veritabanını korur. Ancak PHP temaları ile sayfa oluşturmak yerine içeriği WordPress REST API ya da WPGraphQL üzerinden sunar; sunum katmanını tamamen frontend'iniz üstlenir.

Şöyle düşünün: WordPress mutfak, frontend framework'ünüz ise restoran. Mutfak yemeği hazırlar (içerik), restoran ise nasıl servis edileceğine, yemek odasının nasıl görüneceğine ve misafirlerin deneyimine karar verir.

Geleneksel ve Headless Mimari

Geleneksel WordPress'te her şey bir monolittir. Ziyaretçi bir sayfa istediğinde PHP isteği işler, MySQL'i sorgular, tema şablonlarından geçirir ve hazırlanmış HTML gönderir. Tema; düzeni, stilleri, yönlendirmeyi — her şeyi kontrol eder.

Headless WordPress'te ise bu render katmanının tamamını soyutlarsınız. WordPress bir API'nin arkasında, genellikle WP Engine veya Kinsta gibi yönetilen bir barındırma üzerinde çalışır. Frontend'iniz — React, Vue veya Svelte uygulaması — içerik almak için API istekleri gönderir ve istediği gibi render eder. İki sistem tamamen farklı sunucularda, farklı teknoloji yığınlarında, farklı dağıtım pipeline'larında yaşayabilir.

Rehberlerin 10'da 9'unun atlayıp geçtiği ince bir nokta var: decoupled ve headless tam olarak aynı şey değildir. Decoupled WordPress, belirli sayfalar için (yönetici alanı veya eski rotalar gibi) PHP render'ına yine de geri dönebilir. Tamamen headless ise WordPress frontend'inin tamamen devre dışı bırakıldığı anlamına gelir — yalnızca API, hiç tema render'ı yok. Bu rehberde tamamen headless yaklaşımdan bahsediyoruz.

Headless'a Geçmek Ne Zaman Mantıklı? (Ne Zaman Geleneksel Kalmalı?)

Ekibinizde modern araçlarla çalışmak isteyen frontend geliştiriciler varsa, içeriği birden fazla kanala (web, mobil uygulama, dijital tabela) sunmanız gerekiyorsa ya da performans tartışmasız bir gereksinimse headless mantıklıdır. Ama herkes için doğru değildir; bunu dürüstçe kabul etmek size haftalarca boşa harcanan çabadan kurtarır.

Headless'a Geçin...

• Ekibiniz React/Vue/Svelte biliyor. Frontend geliştiricileriniz gün boyu JSX yazıyorsa onları PHP temalarına zorlamak, bir şefe mikrodalga ile pişirmesini söylemek gibidir.
• Çok kanallı içerik sunumu gerekiyor. Tek bir WordPress backend'i, aynı API üzerinden pazarlama sitenizi, mobil uygulamanızı ve mağaza içi kioskları besleyebilir.
• Performans zorunlu bir gereksinim. CDN edge'den sunulan statik sayfalar, paylaşımlı bir sunucuda PHP render'ından her zaman daha hızlı olur.
• Headless WooCommerce çalıştırıyorsunuz. Karmaşık e-ticaret frontend'leri, özel React/Next.js vitrinlerinden büyük ölçüde yararlanır.
• Modern geliştirici deneyimi istiyorsunuz. Hot module replacement, TypeScript, bileşen kütüphaneleri, CI/CD — tam frontend toolchain.

Geleneksel Kalın...

• İçerik editörleri canlı önizleme ve sayfa oluşturucuya ihtiyaç duyuyor. Gutenberg, Elementor ve WPBakery geleneksel temayı varsayar. Headless'a geçmek görsel düzenleme iş akışlarının çoğunu bozar.
• Tek geliştirici veya küçük ekipsiniz. Headless %40-60 daha fazla kurulum karmaşıklığı ekler. Bir blogu tek başınıza yönetiyorsanız geleneksel tema daha basittir.
• Frontend eklentilerine ağırlıklı olarak bağımlısınız. İletişim formları, SEO eklentileri (Yoast meta etiketleri sunucu tarafında render eder), çerez izin banerleri — bunların hepsi PHP render'ını varsayar.
• Bütçe kısıtlı. WordPress ve frontend için ayrı ayrı barındırma gerekir. Bir fatura yerine iki fatura.

REST API mı WPGraphQL mi? Veri Katmanınızı Seçin

WordPress, headless kurulumda içerik çekmek için iki yol sunar: yerleşik REST API ve WPGraphQL eklentisi. REST API, WordPress çekirdeğiyle birlikte gelir ve kutudan çıktığı gibi çalışır — eklenti gerekmez. WPGraphQL eklenti kurulumu gerektirir ama tam olarak ihtiyaç duyduğunuz alanları sorgulayabilirsiniz; bu, REST'i rahatsız eden over-fetching sorununu ortadan kaldırır. Deneyimlerimize göre çoğu projede WPGraphQL kazanır, ama REST'in küçümsenmemesi gereken bir avantajı var: doğal HTTP önbellekleme.

WordPress REST API: Yerleşik Seçenek

REST API, WordPress'in 4.7 sürümünden (Aralık 2016) itibaren her kurulumda kullanılabilir. /wp-json/wp/v2/posts adresine gidin ve JSON alın. Basit, iyi belgelenmiş ve sıfır yapılandırmayla çalışır.

Sorun? Over-fetching. Bir yazı istediğinizde WordPress her şeyi döndürür: render edilmiş içerik, ham içerik, özet, yazar ID'si, öne çıkan medya ID'si, kategoriler, etiketler, meta alanlar, GUID, yorum durumu, ping durumu, şablon ve muhtemelen ihtiyacınız olmayan 15 başka alan. Yalnızca başlıklara, slug'lara ve özetlere ihtiyaç duyduğunuz bir blog listeleme sayfası için gerekenden 3-5 kat fazla veri aktarırsınız.

// REST API: 5 son yazıyı yazar ve kategorilerle çekme
const res = await fetch(
  'https://siteniz.com/wp-json/wp/v2/posts?per_page=5&_embed'
);
const posts = await res.json();

// _embed parametresi yazar ve kategori nesnelerini dahil eder
// Ama her yazıdaki HER alanı da dahil eder -- yazı başına ~8KB
// 5 yazı için ~40KB JSON alırsınız

Hangi alanların döneceğini sınırlamak için _fields parametresini (?_fields=id,title,slug,excerpt) kullanabilirsiniz, ama gömülü kaynaklar için yardımcı olmaz; ilişkili verilere ihtiyaç duyduğunuzda yine de birden fazla istek yapmanız gerekir.

WPGraphQL: İhtiyacınız Olanı Sorgulayın

WPGraphQL, Jason Bahl tarafından geliştirilen (şu an WP Engine tarafından desteklenen) ve WordPress'e tam bir GraphQL API ekleyen ücretsiz açık kaynaklı bir eklentidir. Tam olarak hangi alanları istediğinizi belirten bir sorgu yazarsınız ve tam olarak onu alırsınız — fazlası değil.

# WPGraphQL: Aynı sorgu -- yazar ve kategorilerle 5 son yazı
query RecentPosts {
  posts(first: 5) {
    nodes {
      title
      slug
      excerpt
      date
      author {
        node {
          name
        }
      }
      categories {
        nodes {
          name
          slug
        }
      }
    }
  }
}

# Yanıt: ~2KB hassas yapılandırılmış JSON
# Fazladan alan yok, şişkinlik yok

Yanıt Yüklerinin Karşılaştırması

Gerçek yanıt yükleri şöyle görünür:

Hangisini Seçmeli?

REST kullanın: Hızlı bir şeyler yapıyorsanız, ekibiniz GraphQL bilmiyorsa veya ek araç olmadan agresif HTTP önbelleklemeye ihtiyaç duyuyorsanız.

WPGraphQL kullanın: Karmaşık veri gereksinimlerine sahip bir production frontend geliştiriyorsanız, daha küçük yükler istiyorsanız veya ekibiniz başka yerlerde GraphQL kullanıyorsa.

Net karar: Next.js ile ciddi bir headless WordPress projesi için WPGraphQL daha iyi seçimdir. Yük tasarrufu, GraphiQL IDE ile geliştirici deneyimi ve tek istekli veri çekme, eklenti bağımlılığını karşılamaya değer.

WordPress'i Headless CMS Olarak Kurma

WordPress'i headless CMS olarak kurmak altı adım içerir: WordPress'i yükleyin, doğru eklentileri ekleyin, içerik modelinizi yapılandırın, frontend temasını devre dışı bırakın, kimlik doğrulamayı ayarlayın ve API'nizin çalıştığını doğrulayın. Daha önce yaptıysanız sürecin tamamı 30-45 dakika, ilk defa yapıyorsanız birkaç saat sürer.

Adım 1: Yönetilen barındırma üzerinde temiz bir WordPress kurulumundan başlayın. Kinsta, WP Engine ve Cloudways'in hepsi WordPress için optimize edilmiş ortamlar sunar. Sadece denemek istiyorsanız LocalWP ile yerel kurulum da gayet işe yarar.

Adım 2: Temel eklentileri yükleyin:

Adım 3: ACF ile içerik modelinizi oluşturun. Frontend bileşenlerinizle eşleşen alan grupları tanımlayın. Bir portföy yazı türünde projectUrl, techStack (tekrarlayıcı), clientName ve projectYear alanları olabilir.

Temel Eklentiler

WPGraphQL for ACF özel ilgi gerektirir. Bu eklenti olmadan ACF alanlarınız GraphQL sorgularında görünmez. Yükledikten sonra özel alanları şöyle sorgulayabilirsiniz:

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

WordPress Frontend'ini Devre Dışı Bırakma

Adım 4: Ziyaretçilerin WordPress URL'nize gidip bozuk bir tema görmesini istemezsiniz. Bunu temanızın functions.php dosyasına ya da bir mu-plugin olarak ekleyin:

// Tüm frontend isteklerini API'ye yönlendir
add_action('template_redirect', function () {
    if (!is_admin() && !wp_doing_ajax() && !defined('REST_REQUEST') && !defined('GRAPHQL_REQUEST')) {
        wp_redirect('https://frontend-domain-adresiniz.com');
        exit;
    }
});

Adım 5: Kimlik doğrulama için Application Passwords kurun. Kullanıcılar > Profiliniz > Application Passwords bölümüne gidin, bir şifre oluşturun ve kimlik doğrulama gerektiren API isteklerinde (harici araçlardan içerik oluşturma/güncelleme) kullanın.

API'nizi Test Etme

Adım 6: Tarayıcınızı açın ve https://siteniz.com/graphql adresine gidin — GraphiQL IDE'yi görmelisiniz. Yazılarınızı sorgulayın. REST kullanıyorsanız https://siteniz.com/wp-json/wp/v2/posts adresine gidin ve JSON aldığınızı doğrulayın.

İpucu: WPGraphQL ile birlikte gelen GraphiQL IDE, şemanızı keşfetmek için gerçekten mükemmel. Otomatik tamamlama, belgeler ve sorgu geçmişi ile hangi alanların mevcut olduğunu ve ACF verilerinizin nasıl yapılandırıldığını anlamanın en hızlı yolu.

WPGraphQL ile Next.js Frontend Oluşturma

2026'da headless WordPress frontend'i oluşturmanın en temiz yolu, Next.js 15'in App Router ve React Server Components'idir. Server Components, JavaScript'i istemciye göndermeden sunucuda veri çeker ve WPGraphQL hassas sorgular sunar — doğal bir birleşim. WPGraphQL'i Next.js App Router ile ilk kurduğumda en büyük engel görüntü işlemeydi — ama oraya geleceğiz.

Proje Kurulumu ve Ortam Değişkenleri

Yeni bir Next.js projesiyle başlayın. Vercel ayrıca referans mimari için resmi WordPress başlangıç şablonu sunuyor.

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

WordPress endpoint'lerini .env.local dosyasına ekleyin:

WORDPRESS_API_URL=https://wordpress-siteniz.com
NEXT_PUBLIC_WORDPRESS_GRAPHQL_ENDPOINT=https://wordpress-siteniz.com/graphql

Hafif bir GraphQL fetch yardımcı programı oluşturun. Server Components için Apollo veya urql gerekmez — düz fetch mükemmel çalışır çünkü yönetilecek istemci tarafı durum yoktur:

// 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: saatte bir yeniden doğrula
  });

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

React framework seçenekleri için Next.js ile Vite kullanan saf React karşılaştırmamıza bakabilirsiniz — framework'ü atlayıp devam etmek için geçerli nedenler var, ama headless CMS çalışması için yerleşik SSR ve ISR, Next.js'i pratik tercih haline getiriyor. Next.js ile Remix arasında karar veriyorsanız çoğu proje için Next.js'i neden önerdiğimizi açıkladığımız yazımıza bakın.

Server Components ile Yazı Çekme

Blog listeleme sayfası Server Component olarak — useEffect yok, yükleme durumu yok, istemci tarafı hidrasyon yok:

// 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>
  );
}

Dinamik Yazı Sayfaları

Tek tek yazı sayfaları, build sırasında tüm yazıları önceden render etmek için generateStaticParams kullanır; yeni içerik ISR tarafından alınır:

// 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 görselleri için next.config.ts yapılandırmasını unutmayın:

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

export default nextConfig;

Headless WordPress'i Production'a Dağıtma

Production headless WordPress kurulumu çift barındırma kullanır: WordPress, WP Engine, Kinsta veya Cloudways gibi yönetilen WordPress barındırma üzerinde çalışırken Next.js frontend'i Vercel veya Netlify gibi bir edge platformuna dağıtılır. Bu ayrım, her katmanın bağımsız olarak ölçeklendirilmesi anlamına gelir — WordPress içerik düzenlemesini ve API isteklerini karşılarken frontend, dünya genelinde CDN edge düğümlerinden statik ve ISR sayfaları sunar.

Barındırma Mimarisi

Veri akışı şöyle işler: içerik editörleri WordPress yönetiminde yayınlar, WordPress içeriği MySQL'de saklar, Next.js frontend'i WPGraphQL üzerinden içerik çeker, Vercel edge'de statik HTML oluşturur ve ziyaretçiler CDN'e ulaşır — WordPress'e hiç dokunmadan.

Frontend barındırma için ayrıntılı karşılaştırma amacıyla Vercel ve Netlify karşılaştırmamıza bakın. Her ikisi de headless WordPress için iyi çalışır. Konteyner tabanlı alternatifleri düşünüyorsanız Railway, Render ve Fly.io karşılaştırmamız bu seçenekleri ele alır.

ISR ve İsteğe Bağlı Yeniden Doğrulama

Bu, headless WordPress'i production'da gerçekten kullanılabilir kılan kısım. İsteğe bağlı yeniden doğrulamanın kurulum çabasına değdiğini gördük; çünkü olmadan iki seçenek arasında sıkışıp kalırsınız: bayat içerik (uzun yeniden doğrulama aralıkları) ya da yavaş build'ler (WordPress API'nizi çökertecek kadar kısa aralıklar).

ISR her sayfaya bir revalidate süresi ayarlamanıza olanak tanır. Bu aralıktan sonra, bir sonraki ziyaretçi önbelleğe alınmış sayfayı alırken Next.js arka planda yeniden oluşturur. Asıl sihir ise isteğe bağlı yeniden doğrulama — içerik yayınlanır yayınlanmaz bir yeniden build tetikleme:

// 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: 'Geçersiz gizli anahtar' }, { status: 401 });
  }

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

  if (slug) {
    revalidatePath(`/blog/${slug}`);
    revalidatePath('/blog'); // Listeleme sayfasını da yeniden doğrula
  }

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

WordPress tarafında, WP Webhooks gibi bir eklenti veya Vercel /api/revalidate endpoint'inizi çağıran basit bir functions.php snippet'i kullanarak publish_post üzerinde tetiklenen bir webhook ekleyin. Böylece içerik "Yayınla"ya basıldıktan saniyeler içinde yayına girer — tam yeniden build yok, bekleme yok. Daha fazla yapılandırma seçeneği için Next.js ISR belgelerine bakın.

Maliyet Dökümü

Headless WordPress ile Amaca Yönelik Headless CMS Karşılaştırması

Hem headless WordPress hem de Sanity, Contentful ve Strapi gibi amaca yönelik CMS'lerle çalıştıktan sonra dürüst değerlendirmem şu: headless WordPress, mevcut bir WordPress siteniz veya içerik ekibiniz varken pragmatik bir seçimdir. Sıfırdan başlarken nadiren en iyi seçimdir.

Headless WordPress'in Kazandığı Durumlar

• İçerik editörleri zaten biliyor. WordPress'in yönetici arayüzünün 20 yıllık bir işleme geçmişi var. Teknik olmayan bir ekibi Sanity Studio veya Contentful arayüzünde eğitmek haftalar alır.
• Eklenti ekosistemi. 60.000'den fazla eklenti. Çok dilli içerik mi gerekiyor? WPML. E-ticaret mi? WooCommerce. SEO içerik analizi mi? Yoast (yönetimde hâlâ çalışır). Hiçbir amaca yönelik CMS bu genişliğe ulaşamaz.
• İşe alım. WordPress, herhangi bir CMS'in en büyük geliştirici havuzuna sahip. WordPress geliştiricisi bulmak, Sanity veya Payload uzmanı bulmaktan çok daha kolay.
• WooCommerce. WordPress içeriğiyle headless e-ticaret istiyorsanız WooCommerce + WPGraphQL kanıtlanmış bir yığındır. Saleor ve Medusa alternatiftir ama WooCommerce pazar payına sahip.

Amaca Yönelik CMS'lerin Kazandığı Durumlar

• İçerik modelleme. Sanity'nin GROQ'u, Contentful'un içerik türleri ve Payload'ın TypeScript şeması, yapılandırılmış içerik için sıfırdan tasarlanmıştır. WordPress'in yazı/sayfa/özel-yazı-türü modeli sonradan eklenmiş gibi hissettiriyor.
• Gerçek zamanlı işbirliği. Sanity'nin Google Docs tarzı gerçek zamanlı düzenlemesi var. Contentful'un canlı iş birliği var. WordPress? "Bu yazı başkası tarafından düzenleniyor" kilit ekranı alırsınız.
• API-first mimari. WPGraphQL mükemmel ama yine de bir PHP monoliti üzerine oturmuş eklenti. Contentful ve Sanity API'leri, başından beri API-first olarak tasarlandı.
• Medya işleme. WordPress medya kütüphanesi işlevsel ama temel. Sanity'nin otomatik kırpma, sıcak nokta ve CDN teslimatiyle görüntü pipeline'ı farklı bir sınıf. Contentful ve Storyblok Cloudinary ile yerel entegrasyon sunar.
• Geliştirici deneyimi. Strapi ve Payload, şema değişikliklerinde hot-reload ile yerel geliştirme deneyimi sunar. WordPress, yönetici panelini yenilemeyi ve veritabanı migrasyonlarını çalıştırmayı gerektirir.

Karar: Hangisini Seçmeli?

Headless WordPress kullanın: Yıllarca içerik birikmiş mevcut bir WordPress siteniz varsa, editörleriniz yeni bir CMS öğrenmek istemiyorsa, WooCommerce'e ihtiyaç duyuyorsanız ya da başka bir yerde eşdeğeri olmayan belirli bir WordPress eklentisine ihtiyacınız varsa.

Amaca yönelik headless CMS seçin: Sıfırdan yeni bir proje başlatıyorsanız, gerçek zamanlı iş birliğine ihtiyaç duyuyorsanız, içerik modeliniz karmaşık ve yapılandırılmışsa ya da ekibiniz eklenti genişliğinin önünde geliştirici deneyimine değer veriyorsa.

Techsy olarak, geleneksel WordPress'ten geçiş yapan müşteriler için headless WordPress frontend'leri geliştirdik. Tipik yaklaşımımız: WPGraphQL + Next.js App Router, Vercel üzerinde, performans için ISR ve içerik güncelliği için isteğe bağlı yeniden doğrulama. Ücretsiz danışmanlık alın ->

WordPress MCP ve Abilities API: Yapay Zeka Geleceği

WordPress 6.9, WordPress 7.0 çekirdeğiyle birleşen Abilities API'yi tanıttı (Nisan 2026). Bu API, WordPress işlevselliği için standartlaştırılmış, türlendirilmiş ve keşfedilebilir bir arayüz oluşturuyor — yapay zeka araçlarının anlayabileceği ve kullanabileceği makine tarafından okunabilir bir formatta WordPress'in yeteneklerini sunduğunu düşünün.

WordPress MCP Adapter, bu Abilities API'yi Model Context Protocol'e (MCP) — yapay zeka sistemlerini harici araçlara bağlamak için açık standarda — köprüler. Bu pratik olarak ne anlama geliyor? Claude, Cursor veya VS Code'daki yapay zeka ajanları artık WordPress sitenizin ne yapabileceğini keşfedebilir ve bu eylemleri doğrudan gerçekleştirebilir.

Pratik bir senaryo: Claude tek bir konuşmada WordPress yazısı oluşturabilir, ACF alanlarını yapılandırılmış verilerle doldurabilir, kategoriler atayabilir, öne çıkan görsel belirleyebilir ve Vercel yeniden doğrulama webhook'unuzu tetikleyebilir. Tarayıcı yok, yönetici paneli yok, kopyala-yapıştır yok.

Bu erken aşamada ve MCP adapter hâlâ gelişiyor. Ama önemli bir sinyal veriyor: WordPress, amaca yönelik headless CMS'ler yenilik yaparken sadece beklemeyip oturmayacak. Abilities API + MCP kombinasyonu, WordPress'i mevcut platformların hiçbirinin karşılayamayacağı şekilde devasa eklenti ekosistemini kullanarak en yapay zeka erişilebilir CMS'lerden biri yapabilir. Tam teknik detaylar için WordPress Developer Blog'daki resmi duyuruyu okuyun.

Performans: Headless WordPress ile Geleneksel WordPress Karşılaştırması

Statik frontend ile headless WordPress, geleneksel PHP render'lı WordPress'e kıyasla performansı dramatik biçimde artırır. Geleneksel WordPress, her istekte PHP çalıştırarak dinamik sayfalar sunar; bu da kötü Time to First Byte (TTFB) sonuçlarına yol açar — 2025 ortası performans verilerine göre yalnızca masaüstü WordPress istemcilerinin %31'i ve mobilde %24'ü iyi TTFB skorları elde ediyor. Next.js ve ISR ile headless'a geçmek, sayfaların CDN edge düğümlerinden önceden oluşturulup sunulduğu anlamına gelir; önbelleğe alınmış sayfalarda TTFB 100ms'nin altına düşer.

WP Engine'in Android Authority üzerindeki vaka çalışması headless WordPress'e geçişten sonra Lighthouse performans puanlarında 6 kat iyileşme gösterdi. Core Web Vitals verileri de benzer bir tablo ortaya koyuyor: WordPress sitelerinin yalnızca %45'i mobilde üç CWV ölçütünü de geçiyor; bu oran Shopify için %65, Duda için %83.

Önemli bir uyarı: headless yavaş bir WordPress backend'i düzeltmez. WordPress API'niz 40 eklentili ucuz paylaşımlı barındırma yüzünden 3 saniyede yanıt veriyorsa ISR yeniden oluşturmanız da yavaş olur. Frontend, bağımlı olduğu API'den daha hızlı olamaz. Kaliteli yönetilen barındırmaya yatırım yapın — headless kurulumda önemi azalmak yerine artar. WordPress Performance Lead Weston Ruter'ın bloğunda WordPress sunucu performansını gerçekten neyin etkilediğine dair mükemmel veriler var.

SSS

Headless WordPress nedir?

Headless WordPress, WordPress'in yalnızca içerik yönetimi backend'i olarak hizmet verdiği, PHP frontend temasının tamamen devre dışı bırakıldığı bir mimaridir. İçerik, Next.js, Nuxt veya Astro gibi framework'lerle oluşturulmuş ayrı bir frontend uygulamasına REST API veya WPGraphQL aracılığıyla iletilir. WordPress yönetici paneli, içerik editörleri için tamamen işlevsel kalmaya devam eder.

WordPress iyi bir headless CMS midir?

WordPress, mevcut bir siteniz, arayüzü bilen içerik editörleriniz ya da kullanmanız gereken eklenti ekosistemi (özellikle WooCommerce) varsa headless CMS olarak iyi çalışır. Sıfırdan başlarken Sanity veya Contentful gibi amaca yönelik headless CMS'lere kıyasla daha az idealdir; çünkü WordPress'in içerik modelleme ve API'si API-first tasarlanmak yerine sonradan eklendi.

Headless WordPress'in dezavantajları nelerdir?

Ana dezavantajlar şunlar: artan karmaşıklık (bir yerine iki barındırma ortamı), görsel düzenleme ve sayfa oluşturucu işlevselliğinin kaybı, frontend eklentilerinin çalışmayı durdurması (Yoast meta render'ı, iletişim formları, çerez banerleri), gerçek zamanlı içerik iş birliğinin olmaması ve GraphQL API'sinin çekirdek işlevsellik yerine eklenti bağımlılığı olması. WooCommerce ve Yoast gibi önde gelen eklentilerin headless modda sınırlı işlevselliği olduğunu da belirtmek gerekir.

Next.js'i WordPress'e nasıl bağlarım?

WordPress sitenize WPGraphQL'i yükleyin, ardından App Router ile yeni bir Next.js projesi oluşturun. WordPress GraphQL endpoint'inizi ortam değişkeni olarak ayarlayın, basit bir fetch tabanlı GraphQL yardımcı fonksiyonu yazın ve yazıları, sayfaları ve özel içerik türlerini sorgulamak için Server Components'ta kullanın. Apollo veya urql gerekmez — Server Components sunucuda çalıştığı için düz fetch yeterli.

WPGraphQL mi REST API mi — hangisi daha iyi?

WPGraphQL, production frontend'leri için daha iyi çünkü yalnızca istediğiniz alanları döndürür (%60-80 yük boyutu azalması), tek istekte iç içe sorgular destekler ve şema keşfi için GraphiQL IDE sunar. REST API, hızlı prototipler, GraphQL bilmeyen ekipler veya ek araç olmadan yerel HTTP önbelleklemenin kritik olduğu durumlar için daha iyidir.

Headless WordPress ne kadar maliyetli?

Minimal bir headless WordPress kurulumu aylık yaklaşık 14 dolara mal olur — WordPress barındırma için Cloudways artı frontend için Vercel'in ücretsiz Hobby katmanı. WP Engine ve Vercel Pro ile production kurulumu aylık 40-70 dolardır. ACF Pro ve WPML gibi premium eklentiler için aylık 0-50 dolar ekleyin. Amaca yönelik headless CMS'lerin sık sık cömert ücretsiz katmanları vardır; dolayısıyla maliyet tek başına headless WordPress seçmek için bir neden değil.

WooCommerce'i headless WordPress ile kullanabilir miyim?

Evet. WPGraphQL'in ürünleri, siparişleri, sepeti ve ödeme işlevselliğini GraphQL üzerinden sunan bir WooCommerce uzantısı var (WPGraphQL WooCommerce veya "WooGraphQL"). Bu, tam e-ticaret kapasitesine sahip özel React vitrinleri oluşturmanıza olanak tanır. Ödeme akışı, geleneksel WooCommerce temalarına kıyasla daha fazla çalışma gerektirir; ama yüksek trafikli mağazalar için performans ve kullanıcı deneyimi kazanımları önemlidir.

Headless WordPress için geliştirici gerekmez mi?

Evet, headless WordPress kurulumu frontend geliştirme becerileri gerektirir — özellikle React (veya Vue/Svelte) ve API'lere aşinalık. Tüm frontend'i sıfırdan oluşturmanız ya da bir başlangıç şablonunu özelleştirmeniz gerekecek. Bu bir no-code çözümü değil. İçerik editörleri WordPress yönetimini normal şekilde kullanmaya devam edebilir, ancak ilk kurulum ve süregelen frontend bakımı geliştirici katılımı gerektirir.

Headless WordPress için hangi eklentiler zorunlu?

Zorunlu eklentiler: WPGraphQL (GraphQL API), Advanced Custom Fields veya ACF (yapılandırılmış içerik modelleme) ve WPGraphQL for ACF (özel alanları GraphQL üzerinden sunar). Kesinlikle önerilen: yönetim üzerinden yazı türleri kaydetmek için Custom Post Type UI ve içerik yayınlandığında frontend build'lerini tetiklemek için WP Webhooks gibi bir webhook eklentisi. Yoast SEO'nun meta render'ı veya form eklentileri gibi frontend bağımlı eklentilerden kaçının.

Headless WordPress SEO için iyi mi?

Headless WordPress, Next.js veya Nuxt ile doğru uygulandığında SEO için mükemmel olabilir; çünkü server-side rendering, daha hızlı sayfa yüklemeleri (Core Web Vitals'ı iyileştirir), meta etiketler, yapılandırılmış veri ve URL yapısı üzerinde tam kontrol elde edersiniz. Risk şu: Yoast'ın meta etiket render'ı gibi otomatik SEO eklentisi özelliklerini kaybedersiniz — meta etiketleri, site haritalarını ve yapılandırılmış veriyi frontend kodunuzda manuel olarak ele almanız gerekecek.