The 7 Things Your Website Needs Before You Let AI Manage It

Before you let AI manage your website, it needs seven things: a real codebase on modern infrastructure, version control as the source of truth, deploy previews for every change, organizational context the AI can draw from, an approval workflow with roles, attribution for every change, and a restore path. Miss one, and you are trusting AI rather than managing it.

If you lead a marketing team in 2026, you have watched this category move fast. Webflow now calls itself the agentic web marketing platform. Netlify lets you prompt agents straight from its dashboard. Vercel publishes reference architectures where AI agents do the marketing work and humans approve it. The question has quietly shifted from whether AI can run a website to whether your organization is set up to let it.

The tools to build and run your website with AI already exist. Dispatch makes them manageable for your organization. But no tool can retrofit readiness. The seven prerequisites below are the difference between an AI-managed website your team operates with confidence and an experiment nobody can account for. For each one, this post covers why it matters, what good looks like, and a quick self-check you can run today.

What are the seven requirements, at a glance?

1. 1A real codebase on modern infrastructure — not a database-locked CMS
2. 2Version control as the single source of truth for the entire site
3. 3Deploy previews, so every change can be seen before it ships
4. 4Organizational context the AI can draw from — voice, claims, personas
5. 5An approval workflow with real roles and separation of duties
6. 6Attribution — knowing which changes were made by AI and who requested them
7. 7A restore path that is fast, complete, and rehearsed

Notice what is not on the list: a specific AI tool. These prerequisites are agent-agnostic. Whether your team ends up using Claude Code, Codex, Gemini, or whatever ships next, the foundation is the same — which is exactly why it is worth building properly once.

1. Does your website live in a real codebase on modern infrastructure?

AI agents do their best work against a real codebase — files in a repository, built and deployed on infrastructure like Vercel or Netlify — not against pages locked inside a CMS database. Coding agents operate on files. They read a component, understand how it relates to the pages that use it, and make a change that respects the whole. When your site is rows in a proprietary database, an agent can only touch whatever the vendor's API chooses to expose.

The market has converged on this conclusion from every direction. Builder.io built its entire product around collaborative AI development against real codebases — understanding your repo, reusing your components and design tokens, editing production code visually. Netlify's Agent Runners have agents create projects and modify code, shipping the results as pull requests. Even Webflow, the most polished visual platform in the category, launched MCP 2.0 to give agents deeper programmatic access to sites inside its walls. Everyone building for the agentic web is trying to get agents closer to the code, because that is where their leverage lives.

What good looks like: your site is built on a modern framework your team can actually run — Next.js, Astro, whatever your developers or agency ship — with every page, template, component, and configuration file living in a Git repository, deployed automatically on push by a host like Vercel or Netlify. Nothing about the site exists only inside a vendor's editor.

• Self-check: could a developer clone your entire website and run it on a laptop this afternoon?
• Self-check: does every page on your site exist as a file someone can open, or as a database record only one vendor's editor can render?
• Self-check: if your CMS vendor shut down tomorrow, would you still have your website?

2. Is version control the source of truth for your site?

Version control — in practice, Git — must be the single canonical record of what your website is, because it is the only system that captures every change with who made it, when, and why. The moment AI starts making changes, the question you will ask most often is not can it do the work. It is what exactly changed. Git answers that question completely, permanently, and for free.

CMS revision histories are partial by design. They usually track content edits but not template changes, redirect rules, or configuration — and they live inside the vendor's system on the vendor's terms. Git tracks everything, and GitHub layers on pull requests and code review. Be clear-eyed about what GitHub is, though: a superb developer-facing system, not a marketing-team management layer. Your engineers will live in it happily. Your content lead should never have to.

What good looks like: the repository is canonical, and nothing on the production site can change without a commit. Every change — human or AI — arrives as a commit with real authorship, and AI-authored commits carry agent trailers identifying which agent produced them. That single convention is what makes requirement six, attribution, possible at all.

• Self-check: is there any part of your website — a page, a template, a redirect — that could change today without leaving a permanent record?
• Self-check: could you reconstruct exactly what your homepage said on any given date last quarter?

3. Do you get a deploy preview for every change?

Every proposed change to your site should automatically build into a preview URL that anyone — including your least technical stakeholder — can open and judge before it goes live. Deploy previews are the single mechanism that turns AI supervision from trust me into see for yourself. Reading a diff requires an engineer. Clicking a link and looking at the rendered page requires nobody special.

This is a solved problem on modern infrastructure, and it is worth crediting the platforms that solved it. Vercel and Netlify both generate a preview deployment for every pull request as a matter of course. Notably, when Netlify launched Agent Runners, it routed agent work through deploy previews and pull requests rather than straight to production — even the platforms most bullish on autonomous agents treat the preview as the checkpoint where a human belongs.

What good looks like: previews are automatic, not requested; approval happens against the rendered preview, not against a summary of what the change is supposed to do; and the preview link travels with the change through your review process, so the person approving is always one click from the evidence.

• Self-check: when a change to your site is proposed today, does a shareable preview URL exist before it ships?
• Self-check: could your general counsel review a proposed pricing-page change without asking an engineer for help?

4. Can the AI draw on your organizational context?

An AI agent without your organizational context produces generic competence — clean, plausible pages that could belong to any company in your industry. Before AI manages your website, your brand voice, messaging, approved claims, personas, and standard procedures need to exist as maintained, approved assets the agent can actually load. Context is the difference between an agent that writes for the web and an agent that writes for you.

The failure modes run in both directions. No context yields bland output that erodes the brand one page at a time. Stale or unapproved context is worse: an agent that confidently repeats a claim legal retired last quarter has turned a writing problem into a liability problem. This is why context must be governed, not just collected — somebody approves what goes in, and the agent only ever sees the approved version. The platforms have noticed the same need. Builder.io supports org-level AI instructions, and Webflow's MCP 2.0 explicitly feeds agents context. The principle is now table stakes; the question is whether your context lives somewhere every tool can reach.

What good looks like: a single context library — brand voice, messaging, SOPs, personas, approved claims — that is versioned, reviewed, and served to any agent your team uses. In Dispatch, the context module feeds AI work directly, and an MCP server serves only approved assets to any MCP client, so every agent in your stack draws from the same governed source of truth rather than from whatever document someone last pasted into a chat window.

• Self-check: if a new agency writer started Monday, is there one document that would tell them your voice, your claims, and your audience?
• Self-check: would three different people on your team point to the same source of truth for approved product claims?
• Self-check: when a claim is retired, is there any mechanism that stops AI tools from continuing to use it?

5. Is there an approval workflow with real roles?

AI-made changes need an approval workflow with enforced roles — and the non-negotiable rule is separation of duties: the person who requested or produced a change cannot be the one who approves it. This is the oldest control in publishing, and it exists because the requester is precisely the person least likely to spot the problem in their own work. When the producer is an AI agent working at machine speed, the rule matters more, not less.

Here is the honest version of the CMS story: the safety net your CMS gave you was mostly workflow. Drafts, review states, publishing permissions, staged releases. Webflow Enterprise remains the model of this done well — staging, branching, granular permissions, publishing controls, rollback. That layer is genuinely valuable, and losing it is the legitimate fear behind most hesitation about AI-managed websites. The answer is not to stay put. It is to rebuild that layer on infrastructure you own. Keep the safety net. Remove the dependency on the CMS.

What good looks like: defined roles — in Dispatch, owner, admin, and editor — with a review queue that covers everything AI touches: prompts, context, agents, workflows, images. Editors cannot approve their own work, and critically, that rule is enforced in the database, not just the interface. A control that lives only in the UI is a suggestion. A control enforced at the data layer is a policy. Policies themselves carry acknowledgment tracking, and an approved-tool registry defines which AI tools are sanctioned for website work in the first place.

• Self-check: can anyone on your team publish to production without a second person signing off?
• Self-check: is your approval rule enforced by the system, or by everyone remembering to behave?

6. Can you tell which changes were made by AI — and who asked for them?

You need to be able to look at any change on your website and answer three questions in under a minute: was this made by a human or an AI, which agent made it, and who requested it. Attribution is what makes every other control auditable. Without it, your approval workflow is a ritual and your activity history is a guess.

Attribution earns its keep in unglamorous moments. Legal asks who changed the language on the pricing page. A page regression appears and you need to know whether to fix a prompt or coach a person. Leadership asks how much of the site AI is actually producing, and whether that should be exciting or alarming. Teams with attribution answer from a record. Teams without it answer from memory, and memory is not an audit trail.

What good looks like: every commit, pull request, and deployment lands in a live activity feed the whole team can see. AI-authored commits are detected through their agent trailers and badged with the agent that made them — Claude Code, Codex, Gemini, or whatever your team adopts next. The review queue ties each piece of work to the person who requested it and the person who approved it, so the full chain — requested by, produced by, approved by — is a lookup, not an investigation.

• Self-check: pick any change your site shipped last month — can you say within a minute whether a human or an AI made it?
• Self-check: if AI made it, do you know which agent, at whose request, under whose approval?

7. Do you have a restore path?

Before AI manages your website, you need a known, fast, rehearsed way to put the site back the way it was. Approval workflows reduce mistakes; nothing eliminates them. The teams that move fastest with AI are not the ones that never ship a bad change — they are the ones for whom a bad change costs minutes. Confidence is a function of how cheap reversal is.

This is where the modern stack quietly outclasses the systems it replaces. With Git as the version store, every state your site has ever been in is preserved: revert the commit, or redeploy the previous build. Vercel and Netlify both make restoring a prior deployment a routine operation, and Webflow Enterprise offers rollback within its platform too — the capability is not exotic. What separates teams is not whether a restore path exists but whether anyone has actually used it before the day it matters.

What good looks like: any previous deployment can be restored in minutes; the restore does not depend on the person who made the mistake being available; and your team has rehearsed it at least once on purpose, so the first rollback under pressure is not also the first rollback ever.

• Self-check: do you know, specifically, who can roll back your site at 5pm on a Friday?
• Self-check: has anyone on your team ever actually performed a rollback, or is it a theory?

How do the seven requirements fit together?

The seven are not a menu; they are a system. The codebase gives agents something real to work on. Version control records what they did. Previews let humans see it. Context makes the work yours. Approvals decide what ships. Attribution proves who did what. The restore path makes the whole arrangement survivable. Here is each one with the signal that tells you where you stand.

Dispatch governs the work; other systems execute the work.

What happens to teams that skip these — versus teams that have them?

The prerequisites feel abstract until something goes wrong, which it eventually will on any website, AI-managed or not. The difference shows up in how the same ordinary incidents play out.

Where does Dispatch fit in?

Dispatch is the management layer for AI-powered websites — built for companies moving from CMS-managed websites to AI-managed websites. It does not build your site, host it, or run the agents; Vercel, Netlify, GitHub, and your coding agents do that well already. Dispatch connects your site's GitHub repo plus Vercel or Netlify, and from that vantage point governs the work: the live activity feed with agent-badged commits, the review queue with roles and database-enforced separation of duties, the context module and MCP server that feed agents only approved assets, and page-level AEO scoring across every URL in your sitemap.

Dispatch gives marketing teams the visibility, context, approvals and control they need to operate a website built and managed by AI. It is agent-agnostic and host-agnostic on purpose — Git is the version store, and the governance layer should survive every tool change beneath it. Move beyond the limitations of your CMS without giving up the visibility, control and governance your team depends on.

Readiness checklist: are you prepared to let AI manage your website?

Run through this honestly. Every unchecked item is a specific, fixable gap — and fixing it is worth doing even if AI never touches your site, because each item below is simply good website operations.

Frequently asked questions

Start with the gap, not the agent

The tempting first move is to pick an AI tool and point it at the website. The durable first move is to run the checklist above, find your gaps, and close them in order — codebase and version control first, previews next, then context, approvals, attribution, and a rollback drill. None of it is wasted work; every item makes your website operation better whether or not an agent ever commits a line.

Then, when you do hand real work to AI — and the platforms are making that easier every quarter — you will be managing it, not marveling at it. The execution layer is ready today. The question these seven requirements answer is whether your organization is.