How to pitch a static website to your clients

Nobody really says ‘Jamstack‘ anymore. Netlify coined the term at SmashingConf in 2016, dropped it from its marketing in 2023 in favor of ‘composable architecture‘, and closed the Jamstack community Discord not long after. The architecture didn‘t go anywhere. It stopped needing a name, because prerendering, content in Git, and delivery from a CDN just … became best practice, and how a lot of new sites get built.

That‘s good news when you‘re pitching. You don‘t have to sell a movement or explain an acronym. You just have to answer the questions your client is actually going to ask, and most of those questions haven‘t changed much since 2016 either.

So here‘s the pitch, in the form of a (stereotypical) client asking the kinds of things that clients tend to ask.

‘Static‘? Doesn‘t that mean a brochure site? We need things that actually change. # Direct link to this section

This is an objection that isn’t hard to answer.

Think of a dynamic site like an on-demand newspaper. Every reader who walks up gets a fresh copy printed for them on the spot, assembled from a database while they wait. Reliable, but slower and resource-intensive, and it means running a printing press around the clock even when nobody‘s asking for anything unusual.

A static site is the printed newspaper that everyone can read. It‘s built once, in advance, and every copy is sitting there ready to hand over. Nobody waits for the press.

Do I need a developer every time I want to change a word? # Direct link to this section

No. With a Git-based CMS like CloudCannon, your team edits on the page. They click a heading and type. They see the change in the actual layout, in the actual typeface, at the actual width, before it goes anywhere. There‘s no separate preview step where they have to cross their fingers.

Editors can also build new pages themselves from components set up in advance. A hero, a testimonial block, a pricing table, a two-column feature: they drag them into place, fill them in, and publish. The components are constrained, so nobody can accidentally produce a page that breaks the design system or ships a 3000px logo. That constraint is the point. It‘s what lets devs hand over the keys without worrying.

And when your team is publishing their own work, agencies aren’t spending their retainers on text swaps. They’re spending their time proactively, on your site.

What about SEO? And how do we show up in ChatGPT, Claude, and Perplexity? # Direct link to this section

Everything you already do still works: Google Analytics 4, Search Console, structured data, sitemaps, canonical tags, redirects. Plausible, Fathom, Matomo, Clarity and Hotjar all drop in the same way they would anywhere else.

The AI search question is perhaps the more interesting one, and prerendering gives you a real advantage here.

In December 2024, Vercel and MERJ published an analysis of crawler traffic across Vercel’s network. They found that none of the major AI crawlers render JavaScript: OpenAI‘s GPTBot and OAI-SearchBot, Anthropic‘s ClaudeBot, PerplexityBot, Meta‘s crawler and ByteDance‘s Bytespider. All of them fetch JavaScript files fairly often (ChatGPT in 11.5% of requests, Claude in 23.8%) and then never run them.

Two crawlers are exceptions. Google‘s Gemini runs on Googlebot‘s infrastructure, so it renders fully, and AppleBot uses a browser-based crawler. Everything else reads the HTML your server returns and moves on.

So if your content gets assembled in the browser after the page loads, it temporarily doesn‘t exist to many of the systems answering your customers‘ questions. Your pricing page has no prices. Your docs have no docs. A model asked about you either guesses from a weaker source or says nothing. A prerendered site doesn‘t have this problem, because the content is already sitting in the HTML the server returns. You can check this yourself on any site in about ten seconds: view source, and search for a sentence from the page. If it‘s there, crawlers can read it.

(The fix isn’t as simple as “avoid JavaScript”: the study does note that anything present in the initial HTML response can be read, including JSON embedded in the page. What’s more important is that your real content ships in the first response, rather than arriving later.)

Will it cost more? # Direct link to this section

Running a static site with CloudCannon costs about the same as running a WordPress site with managed hosting. The difference shows up over the following three years. There‘s no plugin stack to renew, no annual license creep, no month where a security patch breaks the page builder and someone has to fix it. Your maintenance line item gets smaller and stays smaller.

The time a dev would have spent on that goes into the frontend instead, which is the only part of the build your customers will ever see.

How secure is this? # Direct link to this section

A prerendered site isn‘t running application code on every page load, so there‘s dramatically less to attack. No database sitting behind the site. No admin login on a public URL. No plugin with an unpatched CVE from a maintainer who moved on in 2021.

The rendering work happens in your visitor‘s browser rather than on a server somewhere, and the file being served is just a file. It‘s not that static sites are unhackable. It‘s that most of the things that get sites hacked aren‘t present.

How much say do I get over how it looks? # Direct link to this section

All of it. There‘s no theme to fight and no page builder deciding what‘s possible.

Devs can pick the framework to suit the site. Astro is a common default for most marketing and content sites now, because it ships almost no JavaScript by default and lets devs pull in React or Vue components where a page genuinely needs interactivity. Hugo is hard to beat for sites with thousands of pages and heavy image handling, since it builds them in seconds. Eleventy is a good fit when devs want full control of the output and minimal opinions. And if you’re building something closer to an application, SvelteKit or Next.js make more sense.

CloudCannon supports all of these static site generators, so the choice is about your site rather than about the CMS.

Search, contact forms, e-commerce? Can we sell things? # Direct link to this section

Yes to all of it, and the tools are better than they were.

Site search runs client-side with Pagefind, which builds a search index at the same time it builds your site and works without a server. Forms go through CloudCannon, your host, or a service like Formspree. For e-commerce, we can embed Shopify, Snipcart, or Stripe checkout depending on how much of the store you need. If it‘s a handful of products, that‘s an afternoon. (If it‘s a full catalog that needs a live-stock warehouse behind it, that‘s a different conversation.)

What if we want to leave in three years? # Direct link to this section

Your content is plain files in your Git repository. Markdown, YAML, JSON, images. Your repo, on your GitHub or GitLab account, with a complete history of who changed what and when.

If you want to move to something else, you clone it. There‘s no export process, no API rate limit to work around, no support ticket asking for a database dump in a format only one other product can read. This is the single strongest argument for the Git approach: you are never negotiating with a vendor for access to your own site.

And finally, every change is a saved commit, so you can see the history of any page going back to the day it was created.

If we‘re relying on open source, who supports it? What happens when something breaks? # Direct link to this section

This is a fair question, and it‘s the reason a lot of companies overpay for enterprise software they don‘t need.

Astro, Hugo, and Eleventy are maintained by funded teams and long-running contributor bases, with sponsorship from companies that depend on them. They‘re not weekend projects.

More to the point, you‘re not on your own with them. CloudCannon is a paid service with a support team, and they support their customers. A developer will set up your site and your editing interface, and handle anything underneath it, and you get on with publishing. If something goes wrong, there‘s someone to call, and it‘s me.

The ongoing maintenance burden is genuinely different, though. A WordPress site is a running list of plugin updates, version conflicts, and things that stopped working after a release you didn‘t ask for. A static site built from a repo doesn‘t accumulate that.

(If you want the detail on how the two compare, CloudCannon has a WordPress feature and workflow comparison worth reading.)

Our customers don‘t like change. Is a faster site really worth the disruption? # Direct link to this section

Nobody has ever complained that a website loaded too quickly.

Speed shows up in the numbers you already care about. Google‘s page experience signals include Core Web Vitals, and INP in particular punishes JavaScript-heavy pages. Bounce rates rise sharply as load times climb past a couple of seconds, and on mobile connections that gap is wider than most people assume.

If you want to see the effect before committing to anything, pull your current Core Web Vitals from the public Chrome UX Report alongside two or three of your competitors.

What about downtime? # Direct link to this section

CloudCannon builds and hosts on Cloudflare and AWS, with a global CDN, and there‘s no application server to fall over. Your pages are files on a CDN, which is about the most boring and reliable thing you can put on the internet.

If your team is already committed to a host, CloudCannon can build the site and deploy it wherever you like instead.

What‘s in it for agencies, though? What‘s the catch? # Direct link to this section

There isn‘t one. Devs are still designing and building; you still get a site that‘s yours.

The difference is that you‘ll be able to update it without asking your agency first, and you‘ll be looking at the real page when you do it. After all, you‘re closer to your content than a dev would ever be.

Is anyone serious actually building this way? # Direct link to this section

Static sites stopped being a fringe position years ago. It‘s how most new marketing sites, documentation sites, and content sites get built now, which is exactly why the term for it fell out of use. You don‘t need a name for the default.

Astro alone is used across a huge range of production sites, from small agency work to documentation for major frameworks. Static site generators sit behind government sites, university sites, publishers and product docs. Nobody‘s calling it a movement anymore because it isn‘t one.

Here are a few examples of successful transitions to static:

• Moving to CloudCannon and 11ty saved DX $150,000 a year, tripled developer efficiency on website work, and lifted their PageSpeed score from 63 to 99–100, which fed a 400% increase in leads.
• PaperCut consolidated over 4,000 pages from six systems into one CMS, cutting time-to-publish for non-technical editors from as much as five weeks down to minutes, with aggregate performance scores climbing from around 14 to the low 90s.
• Twitch runs 15+ marketing sites in 27 languages on CloudCannon, replacing a WordPress, Rails and Squarespace sprawl where every content tweak meant a developer ticket and a two-to-three-day wait.

Alright. When can we start? # Direct link to this section

Now, more or less. We can spin up a CloudCannon project on a 21-day trial today and show you a working version of one of your pages before we agree on anything.

There are plenty of ready-made templates if you want to see CloudCannon’s editing experience immediately, and deploying a sample site takes a single click.