Going static made our site readable to AI engines. Getting recommended took different work.

Moving off a CMS to static HTML makes your pages easier for an AI engine to fetch, parse, and quote. It won't make an engine recommend you. We know because we did it, we measured after, and the topic we care about most still reads zero.

Here's the honest version of our own story, including the part that doesn't flatter the decision.

What did we actually change, and when?

pitchkitchen.com ran on Wix. In April 2026 we rebuilt it as a statically exported site. There's no CMS in the request path now, no database call, no rendering layer deciding what a crawler sees. Every page, including all 251 blog posts, gets pre-rendered to HTML at build time and served as a file.

That's a real architectural change, and it's the kind of thing a vendor will happily sell you as an AI visibility fix.

We can't tell you it lifted our AI visibility, because we weren't measuring AI visibility in April. We started tracking with Peec on July 27, roughly three months after the migration shipped. There's no before-and-after read across that change, and inventing one would be the easiest lie in this whole category.

What does static HTML actually buy you?

It buys retrievability. An engine that wants to answer a question has to fetch your page, parse it, and find a passage worth lifting. Static HTML removes the failure modes in that chain: no client-side rendering that hands a crawler an empty shell, no CMS template burying the answer under interface furniture, no inconsistent markup between what a browser sees and what a bot gets.

That's genuinely worth having. It's also the floor, not the ceiling. Being fetchable is a prerequisite for being quoted the way having a phone number is a prerequisite for getting a call.

What it fixed for us was consistency. Before, the answer a crawler got depended on how the platform decided to render that page on that request. Now the file on disk is the answer, and it's the same answer for a browser, a bot, and us when we're debugging. That's a smaller win than it sounds like in a pitch deck and a larger one than it sounds like on a spreadsheet.

The same logic applies to schema markup, which is why marking up every page doesn't get you cited either. Both moves tell a machine how to file you. Neither tells it you're worth naming.

Then why are we at 0% on our own category?

This is the receipt that changed how we think about it.

Our latest Peec read covers 1,928 AI chats across ChatGPT, Google AI Overview, Gemini and others, in a field of 13 tracked brands. PitchKitchen sits at 19.2% visibility, second by visibility, first by share of voice at 24.7%, and first by raw mentions at 1,068.

On the topic "AEO and AI visibility," we measure 0% across 39 chats.

We have 11 live pages on that subject. They're statically served, fast, schema-marked, internally linked, and sitting on the same domain as everything that does get cited. Brand identity reads 0.78% across 383 chats, our largest absolute gap, and it has live pages too.

Architecture can't explain a result where identical architecture produces 56% in one topic and 0% in another. Health tech reads 56.4% for us. Cybersecurity 53.9%. Same stack, same build pipeline, same everything a re-platform would touch.

“If the same architecture wins one category at 56% and loses another at 0%, the architecture was never the variable.”

The difference is what those pages say and who else says it about us. In health tech we've got years of specific, earned language and a track record engines can corroborate. In AEO we're a newer voice making claims that read like everyone else's claims.

What's the difference between being read and being recommended?

There are two surfaces, and they move at different speeds.

The grounded surface is an engine searching the web and answering from what it finds. That's where we sit at 19.2%, and that's the surface static HTML affects. Retrieval is a plumbing problem, and plumbing responds to plumbing fixes.

The parametric surface is an engine answering from memory, with search switched off. We measure 6% there. That number doesn't move because of your build tooling. It moves when enough people write about you, name your frameworks, and cite you on pages you don't own.

Re-platforming touches the first surface and does nothing to the second. If you want the longer version of that split, we wrote it up in the difference between being used and being cited.

Should you re-platform or not?

Do it if your current setup is actually breaking retrieval. Signs it is:

• Your pages render client-side and a raw fetch returns an empty shell.
• Your CMS templates wrap every answer in navigation, promo blocks, and interface furniture.
• Your markup differs between what a browser sees and what a bot gets.
• Your pages are slow enough that crawlers time out before they finish.

Skip it if you're re-platforming because a deck told you static sites rank better in AI. You'll spend two quarters and a budget line rebuilding the delivery of a message that wasn't earning citations in the first place. You'll then have a very fast site that engines read and don't repeat.

Watch what the rebuild quietly costs you beyond the invoice. A re-platform consumes the attention of the two or three people who actually know what the company stands for, and it consumes it on templates and redirects. Those are the same people you'd need in a room to sort out what your positioning should say. Most companies only get that group's focus once a year, and spending it on delivery is the expensive part, not the agency fee.

The diagnostic is cheap. Ask an engine what your company does and who it's for. If it describes you accurately and still recommends someone else, retrieval already works and your problem sits upstream of the stack. That's the case for most companies we see. It's also the case we ran into ourselves.

What actually moves the recommendation?

Engines recommend what they can distinguish and corroborate. Distinguishing you is a narrative identity problem: whether your pages state a position specific enough that a model can tell you apart from the category average. Corroborating you is a citation problem: whether anyone besides you says it.

Neither one is a build-tooling decision. Both are messaging decisions that happen to get delivered by build tooling.

That's why our fix for the 0% topic isn't another migration or another eleven posts. It's earning third-party citations on domains engines already trust, and sharpening what our pages claim so there's something quotable to lift. We tried the volume answer first. Volume is what produced eleven pages and zero percent.

If you want to see what your own pages are signalling before you spend anything on a rebuild, run your homepage through the Brand Signal Score. It scores the 19 signals engines actually read, and it'll tell you in a few minutes whether your problem is delivery or message.

And if you'd rather work through it live, the AI Workforce Clinic covers this exact diagnosis with a room full of founders asking the same question. The first Clinic is free.

The part worth keeping

Static HTML is good engineering and we'd make the same call again. It removed a class of problems we no longer think about.

It also didn't make a single AI engine recommend us. What we say, and who repeats it, did that. This is just truth.