30% more organic traffic. 3,000 programmatic pages.

The situation

A website that cannot generate pages programmatically is a ceiling on SEO. Webflow let us build and design, but it could not support a pSEO strategy at scale: launching thousands of pages based on structured data, without manual editorial work for each one. Content updates required developer involvement. Plugin restrictions blocked advanced SEO customization. The platform was not designed for what we needed to do next.

We migrated to Sanity CMS with Gatsby and Next.js. The goal: a headless architecture where structured content feeds programmatic page generation, non-technical team members can manage content without developer support, and Core Web Vitals stay strong as page volume grows. Per our internal records, we launched 3,000+ pages with zero downtime, moved 12,000 monthly visitors without traffic loss, and grew organic traffic 30% in year one.

The failure mode is well documented: 100,000 thin pages get deindexed while 500 quality pages rank. Google ranks pages, not page counts. If you can swap one modifier for another and the page is 85% identical, you fail. The migration was built as a quality-gated system, not a page factory: structured content with a real trust anchor, server-rendered output Googlebot could read from day one, and a rollout that never risked the traffic we already had.

What we had to solve

• Migrating 12,000 monthly visitors to a new architecture without disrupting rankings or causing downtime

  A website migration that causes even a brief downtime or URL restructure can set organic rankings back months. With 12,000 monthly visitors and an established link profile, we could not afford a cutover that broke existing URLs, dropped pages from the index, or created a traffic gap while search engines recrawled the new domain. The migration ran in phases: URL structure was preserved across the transition, redirects were audited before the cutover, and the new platform was validated in staging against real crawler behavior before any traffic moved.

• Building a content model that generates programmatic pages without per-page editorial work

  Programmatic SEO only works if the content model is designed for it from the start. Generating 3,000+ pages requires a schema structure where each page's unique content (headline variations, location or category modifiers, structured data) derives from a set of base records rather than individual entries. Building that schema in Sanity so it was both editorially manageable and technically capable of feeding Gatsby's build pipeline at scale was the design challenge at the core of the project.

1. 12,000 monthly visitors moved to the new platform, no URLs broke, no rankings dropped

   The migration ran in phases with URL structure preserved throughout. Existing pages, redirects, and canonical signals were audited before any traffic moved. Search engines recrawled the new platform before the cutover completed. The 12,000 monthly visitors moved to the new platform without service disruption; no URLs broke, no rankings dropped during the transition.

   

2. Pages load in under one second: performance gains came from the architecture, not patches

   Static site generation eliminated server render time. Pages load in under one second across mobile and desktop. Core Web Vitals scores improved across LCP, CLS, and FID, metrics that directly affect how search engines rank and feature pages. The performance gains came from the architecture, not post-launch patches.

   

3. Marketing team publishes content changes in minutes, no development ticket needed

   Content changes go through a staging environment before they reach the live site. The marketing team reviews updates, checks rendering, and approves changes in Sanity Studio, then deploys with one action. No developer is in the loop for routine content updates. The workflow that previously required a development ticket now takes minutes.

   

4. 3,000+ pages generated from one schema set, no per-page editorial entry required

   The Sanity content model defines the base records from which programmatic pages derive. Service, industry, technology, and location combinations generate distinct pages at build time from a single schema set. No per-page editorial entry. The system supports 3,000+ pages, processes 30,000+ API requests, and manages 966 MB of assets through 75 GB bandwidth without performance degradation under load.

   

How it runs

Sanity CMS

Programmatic page generation at 3,000+ pages needs a content model where structured records feed the build pipeline directly, not one-by-one editorial entries. Sanity's schema-first approach let us define content types that Gatsby could consume at build time. The Studio interface gave non-technical team members a clean editing experience without exposing the underlying schema complexity.

Gatsby

Static site generation at scale required a build pipeline that consumed Sanity content via GraphQL and produced pre-rendered pages with no server overhead. Gatsby's build system handled the 3,000+ page volume without runtime latency and kept load times sub-second across the full pSEO page set.

Next.js

Marketing and campaign pages needed server-side rendering for dynamic metadata, real-time content updates, and ISR revalidation: patterns that static generation alone cannot support. Next.js handled those surfaces while Gatsby owned the high-volume pSEO routes, each doing the job it was designed for.

Vercel

Deploying both Gatsby and Next.js on one platform with edge CDN delivery, preview environments for every pull request, and zero-configuration SSL. Vercel's global edge network kept the site fast across the US, UK, and Australia (the primary traffic regions) without a separate CDN configuration layer.