Getting Started

Architecture Overview

How the two systems connect and communicate.

The system is split into two parts that communicate via the WordPress REST API.

System Diagram

┌─────────────────────────────────┐      ┌──────────────────────────────────┐
│  WordPress (Headless CMS)       │      │  Next.js Frontend                │
│  cms.yourdomain.com             │      │  yourdomain.com                  │
│                                 │ REST │                                  │
│  wp-admin  ──────────────────────────► Pages & Components (React)         │
│  Posts, Pages, CPTs             │  API │  src/lib/wordpress.ts            │
│  Media Library                  │      │  (All API fetch functions)        │
│  WP REST API /wp-json/wp/v2/   │      │                                  │
│                                 │      │  Deployed on:                    │
│  Hosted on: Hostinger           │      │  Vercel / Cloudflare Pages       │
└─────────────────────────────────┘      └──────────────────────────────────┘
         ▲
         │  Webhook (fires on publish)
         └──────── triggers ISR revalidation in Next.js

Data Flow

  1. Editor publishes a post in wp-admin
  2. WordPress fires a webhook to your Next.js app
  3. Next.js revalidates only the affected cached pages
  4. Visitors always see fresh content — no full rebuild needed

DNS Pattern

yourdomain.com       →  Next.js frontend  (Vercel / Cloudflare Pages)
cms.yourdomain.com   →  WordPress backend (Hostinger)
💡

This DNS split means visitors only ever see your Next.js site. You manage content at cms.yourdomain.com/wp-admin as usual.

PreviousIntroductionNextCost Breakdown