Why we migrated our marketing site out of a CMS
And why you might want to consider it too.
About four months ago, I opened Claude Code, fed it our SEO keyword targets, our pillar pages, and our website analytics, and asked it to find pages where we could improve internal linking: one of the strongest signals you can give Google for ranking. Within minutes, it was scanning the website repository, identifying gaps, and opening pull requests across multiple pages. It felt like compressing weeks of SEO agency work into an afternoon.
Then it hit a wall:
For the portion of our site that lived in GitHub without a Content Management System (CMS), the agent ran wild: 18 pages updated in a single PR, for a handful of tokens. But the blog and our highest-value SEO pages were locked behind Contentful, completely inaccessible to the agent.
That moment made me feel dumb, because as early as last year we were actually in the middle of expanding our CMS footprint. We wanted scalability for non-technical team members (me included at that time), guardrails to keep things on-brand, and a foundation for localization. But watching an agent do a month of SEO work in an afternoon and then stop dead at the CMS boundary made the tradeoff painfully clear to me, and others saw the same thing.
We threw out the CMS expansion plan and started migrating the other direction. Today we’re 100% rid of our CMS, and as the AI models have gotten so much better from November last year, the real AI website workflows we’ve been unlocking are very compelling. But I’m getting ahead of myself.
The web is changing, and sites need to change with it
We lost 42% of our organic traffic over the last two years (and everything is actually more than fine).
Our conversions over that same period are more than 3x what they were. We’re not an outlier; Ahrefs found that AI Overviews now reduce click-through rates for top-ranking content by around 58%. Grow & Convert reported the same pattern across multiple SaaS clients, with traffic down 10-40% and conversions holding steady or growing. Zero-click searches now account for roughly 60% of all Google queries.
The website isn’t dead, but its job has changed (I wrote about that here). It’s less of a traffic sponge and more of a conversion machine that also signals to LLMs what you do.
When we moved from Gatsby to Astro in tandem with migrating out of the CMS, our Web Vitals score went from 89 to 97, and our conversion rate is now eclipsing about 4x what it used to be. If you’re going to maintain and optimize something that important, you can’t afford to be clicking through CMS menus when an agent could be doing the work in minutes.
On May 19th, Google announced an AI-powered overhaul of Search, what they called the biggest change to that entry point in 25 years. TL;DR:
Search results now expand into AI conversations
“Information agents” running 24/7 in the background tracking changes for users
Generative UI that builds custom interactive responses in place of links.
AI Overviews already reach 2.5 billion users a month, and Google’s conversational AI Mode tops 1 billion. This turns the dial further in the same direction. The point isn’t that publishers are doomed; it’s that the website’s job has clearly changed. Less traffic sponge, more conversion machine and LLM signal.
Why we migrated out of the CMS
Set aside cost as a reason, even though dropping a CMS can be significant (Cursor’s CMS had cost them nearly $57,000 in one year, and ours was quoting us 10k additional for AI features). The real reason for marketing is velocity.
It lets you deploy agents across your entire site. The Claude Code session I described above was the first taste. Now that we’re fully out of our CMS, the difference is night and day. My team and I point Claude Code at our site and it opens PRs for chunks of the website, tens to hundreds of pages of updates, all at once:
What used to take an SEO expert weeks now happens in one or two prompts. I’m running scheduled tasks for internal linking and blurb updates that surface issues I’d never have caught manually. Four months ago, I could only update a CMS and open a ticket. The fact that I’m now opening PRs, shipping pages, and shipping tools on GitHub (like that SEO tool I mentioned in the intro) is itself evidence that the traditional CMS abstraction layer isn’t necessary anymore.
It lets you ship site-wide changes that actually move conversion. This is the part that surprised me. Once the content was in code, I started making changes I never would have attempted through a CMS: “chat with our docs” widgets across landing pages, code snippet modules at the top of pages to boost conversion, an entirely new solutions page I vibed up in an afternoon. Each of these would have been a cross-functional project tickets before; now they’re something I can prototype and ship the same day. I can point paid media at a page we created with new messaging, partner with PMM, and learn what will resonate before a bigger push. We have 13 active tests running right now, and it’s never been easier to form a hypothesis, ship a test, and learn.
Anyone can fix breakages. When the site is code in a repo, a broken page is just a bug. You don’t need a CMS admin or a specific person with privileged access; anyone with repo access (or an AI agent) can identify the issue and open a PR. We’ve had this happen multiple times during migration: something breaks, someone who isn’t an engineer spins up Claude Code, opens a PR, fixed in minutes. Sentry in this setup is even more overpowered, but I’m biased.
It’s still scalable and safe. The immediate pushback is always: “Won’t everyone break the website?” Not with proper guardrails. Branch protection rules, required reviewers, CI/CD checks: these are the same safeguards engineering teams have used for decades. Frontmatter and YAML give you structured data, which is essentially a CMS without the abstraction layer.
Take it a step further with Skills in Claude (or rules files in Cursor), which function like CMS templates except they’re better, because the agent actually follows them. We have Skills for landing pages, product pages, solutions pages, blog posts, cookbook recipes (tutorials), and workshop templates. Each one encodes the structure, the SEO requirements, the brand patterns, and the component library for that page type. When anyone asks an agent to create a new landing page, it doesn’t start from a blank file; it references the Skill and produces something that’s on-brand and structurally correct by default. Same consistency a CMS template gave you, sitting in your website repo.
Worth noting: you don’t strictly have to ditch a CMS to get this. Anita Kirkovska at Vellum recently wrote about her team doing a version of this inside Sanity (open source pledge member) using agent.md files and per-marketer assistants. That path works too. We chose to leave because at our scale (~2500 pages) the CMS itself was the biggest source of friction, not the absence of agent-readable rules.
It’s a forcing function for your team to learn AI tooling. This might be the most underrated benefit. When your website lives in code, the whole team has to get comfortable with terminals (or Cowork), PRs, and AI coding tools. That’s not a downside; it’s exactly the skill set they’ll need for everything else in marketing that’s moving to code. We’ve gotten team members from every marketing function working in Claude Code, and most are now opening PRs against the website.
How we actually did it
Eli, our Sr. Growth Software Engineer, wrote up the full technical playbook here. It’s the best reference for anyone who wants the deep dive. From my POV, the highlights:
~2500 pages migrated by a team of 2.5 developers in a two-month window.
We did it in stages, one directory at a time. Docs and marketing pages first (easiest to template), then blog content, then the most complex interactive pages.
We moved frameworks at the same time, from Gatsby → Astro. Build times went from 14 minutes to under 6 in the migration itself, and after we shipped a Marketo form cache (the forms had been hitting an external API on every build), we got down to under 4. In a recent 24 hour sample alone, that compounded into 12+ build hours saved across 94 builds.
We consolidated ~200 bespoke pages into 3 templates during the migration, which makes agent-driven changes much more predictable.
Claude Code wrote most of the migration scripts that pulled content from Contentful’s API into our new Markdown files.
Broken staging builds are down ~95%. Web Vitals up from 89 to 97.
I acknowledge that it was an easier decision for us, and that you might not be at a devtools company with a culture that will inherently buy into these type of changes (no marketing software, all in code, sounds like a dream for devtool leaders), but a small marketing team with even one technical person has more to gain from this approach, not less. They can’t afford agencies or CMS admins, and agents close that gap fast. For most growth people I talk to, especially at dev-oriented companies, the agent-accessibility tradeoff wins.
This is all going to get better fast
AI is the worst it will ever be today.
Everything I’ve described, the scheduled SEO tasks, the site-wide page updates, the Skills-as-templates workflow, could probably look quaint in six months. In the next chunk of time, these are what appears to be the most worth paying attention to:
Cloud agent loops that run without prompting. Most of these workflows still start with a human kicking off a session. That’s been shifting, especially for smaller scoped changes. We just shipped a workflow that routes Linear tickets directly to Claude: a ticket gets filed, an agent picks it up, and a PR shows up for review. When that infrastructure is reliable across the board, your site doesn’t just get updated faster; it gets maintained continuously in the background.
AI code review as a safety net. The biggest concern with agent-generated changes at scale is quality control. Tools like Sentry’s Seer or Cursor Bugbot are starting to catch issues in agent-generated PRs that a human reviewer might miss in a batch of 50 changes. As a vibe coder it feels like magic to ask Claude to check the AI code review bots, and fix critical issues. Today it feels like LLMs want to ship MVPs and the bots want to run a production app, and having them compromise in the middle is ideal.
Agent-driven SEO, AEO, conversion optimization, and localization. All of these become possible when your content is in code. The gap between “I can imagine this” and “I can do this” is closing fast, and the teams with their content in code will be able to adopt each of them the moment they’re ready. The teams still in a CMS will have to pay that CMS to ship these features at scale, or be limited by what it offers.
Steps you can take now
If this resonates, here’s how I’d think about getting started:
I’m not saying this is the right call for every team; if you have 50 content editors and complex localization needs, a CMS may have real value. But letting agents run wild on tasks that used to take weeks is a fantastic feeling. LMK what you think. I’m eager to see what people build to run on their website in the next six months: autonomous tasks, self-healing bugs (with Sentry? 👀), big brain SEO/AEO crons. Things are getting fun.
If this was useful, subscribe for more posts like this. I’ll write about other areas we’re migrating to be more agent-ready in the future.
Resources:
Lee Robinson walked through migrating cursor.com from a headless CMS back to raw code and Markdown. He finished in three days, spent $260 in AI tokens, ran 344 agent requests, and removed 322,000 lines of code while adding only 43,000.
Prefect went even further, rebuilding their entire site from scratch during migration; their VP of Product (not an engineer) did it part-time in about a week, using roughly 25 million tokens across 290 commits.