Beyond the Boilerplate: Scaling Jamstack Deployments || Witty Paws

Beyond the Boilerplate: Scaling Jamstack Deployments

By Elissavet • May 17, 2026

Beyond the Boilerplate: Scaling Jamstack Deployments

Preface

At build time, the Gatsby runner generates placeholder URLs. When a user requests a page, Netlify translates these paths into a managed CDN URL, resizes the image on demand, and caches the result at the edge. The build time drops drastically!

Empowering the Content Editors

A headless architecture is only successful if the content creators love using it. To ensure articles copy-paste perfectly from WordPress to the headless frontend without breaking styles, we established a few ground rules:

Stick to Standard Gutenberg Blocks: We strictly use standard blocks (Paragraphs, Headings, Lists, Images). WPGraphQL processes these blocks into clean, structured HTML that our Gatsby CSS easily targets.
Avoid Builder-Specific Shortcodes: Page-builder shortcodes (like [my_custom_slider]) rely on server-side PHP processing. In a headless setup, these often render as plain, broken text.
Style Globally: We write global CSS in Gatsby that targets default WordPress block classes (like .wp-block-image or .wp-block-quote), ensuring editors can write naturally in WordPress and trust the frontend output.

Real-Time Previews in a Decoupled Stack

Since the frontend is statically generated, editors can’t natively click “Preview” in WordPress and see their draft. We solved this using a Custom Secure Token Preview Engine.

When an editor logs in, WordPress generates a JWT token stored as a hardened, HTTPOnly cookie. We then created a serverless Netlify Function (.netlify/functions/preview.js) that acts as an intermediary, reading the cookie and querying the WordPress GraphQL API securely for unpublished revisions:

// Secure Netlify Function connecting to the hidden CMS
const client = new GraphQLClient('[https://secretcms.yourdomain.com/graphql](https://secretcms.yourdomain.com/graphql)', {
  headers: { Authorization: `Bearer ${token}` }
});

const query = gql`
  query GetRevision($id: ID!) {
    post(id: $id, idType: DATABASE_ID) {
      revisions(first: 1) {
        nodes {
          title
          content
        }
      }
    }
  }
`;

Through Gatsby’s Server-Side Rendering (SSR) API, authorized editors can now view dynamic drafts in real-time, while public visitors see only the hyper-optimized static production site.

SEO and Forms in a Headless World

Operating a headless site means leaving behind traditional PHP-rendered plugins.

Headless SEO: Instead of relying on WordPress to inject meta tags into the <head>, we utilized the Yoast SEO plugin alongside the WPGraphQL Yoast SEO Addon. This exposes a robust seo field on all queried post types. On the frontend, we use the Gatsby Head API to inject title tags, canonical elements, OpenGraph markers, and JSON-LD structured data directly into the compiled static HTML. Zero runtime overhead, perfect crawler compatibility.

Zero-Server Forms: Traditional plugins like Contact Form 7 process submissions via server-side PHP. We replaced this entirely with Netlify Forms. By simply adding data-netlify="true" to our standard HTML/React forms, Netlify’s parsing engine intercepts incoming submissions automatically at the edge. No active database handlers required, drastically improving security.

The Takeaway

Scaling a Jamstack deployment is an exercise in elegant delegation. By offloading image transformations to the CDN, managing previews securely via edge functions, and shifting SEO processing to compile time, we transformed our headless WordPress setup from a cool experiment into an enterprise-grade powerhouse.