Why GitHub Alone Isn't Enough to Govern Your Marketing Website

GitHub is the right place to version a marketing website, but it is not a governance system for marketing. It records what changed in code and who committed it, not what changed on which page, why, and who approved it. Marketing needs a governance layer on top of the repo, not a replacement for it.

This situation is now common in dev-led companies. The website lives in a GitHub repository, engineers and AI agents ship changes through pull requests, and the marketing team — the people accountable for what the website says — finds out what changed when a prospect mentions it, or when someone pastes a Vercel preview link into Slack. The site has never moved faster. Marketing has never seen less.

This post is not an argument against GitHub. It is an argument about layers: what GitHub genuinely does well, where it goes silent for a marketing organization, and how a governance layer stacks on top of the developer workflow without changing it.

What does GitHub actually do well for a marketing website?

GitHub is the correct system of record for the code, full stop. Every change is a commit with an author and a timestamp. Pull requests force changes through review before they merge. Branch protection, required checks, and CI keep broken work out of production. For engineers, the PR and review model is the gold standard of change management — it is the most battle-tested approval workflow in software, and there is no serious argument for replacing it.

It has also become the natural home for AI-built websites. Coding agents like Claude Code, Codex, and Gemini do their best work against a real repository: they read the actual code, propose changes as commits, and ship through the same pull-request pipeline as any engineer. Vercel and Netlify both build their agent workflows on this foundation — agents open PRs, deploy previews get generated, humans approve before production. Git is the version store, and nothing in this article suggests otherwise.

So if the foundation is this good, why does the CMO feel blind? Because everything GitHub records is expressed in a language exactly one team in your company speaks.

Where does GitHub go silent for marketing teams?

GitHub speaks developer. Every question it answers is code-shaped: which files, which lines, which branch, which build. Marketing's questions are page-shaped and accountability-shaped: which page, which message, whose request, whose sign-off. The data underneath often overlaps, but the interface only serves one of the two audiences.

The gap is starker than it looks in a table. A commit that touches a shared header component may change the message on forty pages; the diff mentions one file. A copy change to your pricing claims looks identical, in git terms, to a dependency bump. Reading a git log to understand your website is like reading a warehouse manifest to understand a store: technically the information is in there, practically nobody outside operations can use it.

This is exactly the problem the CMS solved, and it deserves credit for solving it. A CMS gave marketing a page-shaped view of the website by construction — you edited pages, not files. Webflow's Enterprise tier is the mature version of that model: staging environments, branching, granular permissions, and publishing controls that let a marketing organization govern its own site. That safety net is real, and it is the standard any repo-based setup should be measured against. The repo has all the raw capability, but none of the marketing-facing interface.

What questions can't a CMO answer from a repo?

Hand a CMO read access to the repository — many dev-led companies have done exactly this and called it transparency — and try to answer the questions a marketing leader is actually accountable for:

1. 1What changed on our website last week? Not in the codebase — on the pages prospects actually see.
2. 2Who asked for each of those changes, and who signed off before they went live?
3. 3Did the messaging update we approved on Tuesday actually ship, and to which pages?
4. 4How much of what shipped this month was authored by AI agents, and which agent did what?
5. 5Are the claims on the pricing page still the ones legal approved?
6. 6Which pages lost their meta descriptions, structured data, or canonical tags in the last redesign deploy?
7. 7If a wrong number is live on the homepage right now, which change introduced it and when?
8. 8Can anyone on my team answer any of the above without filing a ticket to engineering?

None of these questions are exotic, and none of them are answerable from the repo by a non-developer. Most are not even convenient for a developer — question six requires crawling rendered pages, which git does not do, and question four requires parsing commit trailers nobody surfaces. The usual result is that the questions simply go unanswered, and marketing operates on faith.

Do developer workflows and marketing governance compete?

No — they stack. This is the point most teams miss when the debate turns into repo versus CMS. A marketing governance layer does not replace pull requests, reviews, or deploys; it reads them. Every commit, PR, and deployment your engineers and agents already produce is raw material. The governance layer's job is to translate that stream into the language of pages, requests, approvals, and accountability — and to add the small number of controls that GitHub never claimed to provide.

Read the two columns as a pair and the relationship is obvious: nothing on the left gets replaced, modified, or slowed down. Engineers keep GitHub exactly as it is. The right column exists for the people the left column was never designed to serve.

Dispatch governs the work; other systems execute the work.

That division of labor is the whole doctrine. GitHub executes version control better than anything else ever built. Vercel and Netlify execute deployment. Coding agents execute the changes themselves. What no system in that stack owns is the organization-facing question: is this work visible, approved, attributed, and on-standard? That is the layer a management system owns — and only that layer.

How do you know who — or what — changed your website?

Attribution used to be a one-column answer: the commit author. AI changes that. On an AI-powered website there are now three kinds of authorship — a human wrote it, a human directed an agent that wrote it, or an agent wrote it autonomously inside an approved workflow. The commit author field alone no longer tells the story, and for a marketing team deciding how much scrutiny a change deserves, the difference matters.

The good news is that the convention already exists. Well-behaved coding agents append trailers to the commits they author — structured metadata lines, such as a Co-Authored-By trailer naming the agent — that identify AI involvement in a machine-readable way. The trailer travels with the commit forever. It is honest, it is standard, and it is completely invisible to anyone who does not read raw git logs, which is to say: invisible to your entire marketing team.

This is where a management layer earns its keep. Dispatch detects agent trailers on every commit that lands in the activity feed and turns them into badges — a plain visual mark showing that a change was AI-authored and which agent made it. A marketer scanning the feed can see at a glance that Tuesday's pricing page update came from Claude Code under an approved workflow, while the homepage hero rewrite was human-authored. No git knowledge required.

Attribution is not about distrusting AI work. It is about reviewing work at the right level: agent-authored changes to high-stakes pages might route through an extra approval, while low-risk agent housekeeping flows straight through. You cannot tier your scrutiny if you cannot see who — or what — did the work.

How do you add a marketing governance layer on top of GitHub?

Connect, don't migrate. The defining property of a governance layer is that adopting it changes nothing about how the website is built — it observes the existing workflow and adds organization-facing structure around it. In practice the process looks like this:

1. 1Leave the repo where it is. Git stays the version store; engineers keep their branching, review, and CI untouched.
2. 2Connect the repo and the host. Dispatch connects a site's GitHub repository plus Vercel or Netlify, reading the exhaust of the existing workflow rather than inserting itself into it.
3. 3Let the activity feed translate. Every commit, pull request, and deployment lands in a live feed the whole organization can read.
4. 4Turn on agent attribution. AI-authored commits are detected through their agent trailers and badged with the agent that made them.
5. 5Set roles and approval rules. Owners, admins, and editors — with editors unable to approve their own work, enforced in the database rather than by convention.
6. 6Inventory and score every page. Sitemap sync builds the page inventory; each page is crawled and scored 0 to 100 for AEO readiness across eight weighted checks, from title and meta description to structured data, with a site-level rollup of top issues.
7. 7Feed agents approved context. Brand voice, messaging, personas, and approved claims live in a context module, and an MCP server serves only approved assets to whatever agent your team uses.

Notice what step seven implies: the governance layer is not just a rear-view mirror. Once approved context flows to agents through MCP, governance becomes proactive — the AI doing the work draws on the same approved claims and brand voice that marketing already signed off on, which shrinks the review burden on the back end. Dispatch gives marketing teams the visibility, context, approvals and control they need to operate a website built and managed by AI.

And because the layer sits above execution, it is deliberately agnostic underneath: GitHub for version control, Vercel or Netlify for hosting, and whichever coding agent your engineers prefer today or adopt next year. The tools to build and run your website with AI already exist. Dispatch makes them manageable for your organization.

Does your marketing team have real visibility today? A checklist

Run your current setup — repo, CMS, or hybrid — against this list. Each item is a test of whether visibility actually exists for the people accountable for the website, not whether it theoretically could.

If most of these boxes are empty, the problem is not your engineers, and it is not GitHub. Both are doing exactly the jobs they were designed for. The problem is that an entire layer of your website operation — the organizational layer — currently has no system, so it runs on Slack threads, standing meetings, and trust.

Frequently asked questions

The repo stays. The silence goes.

The companies getting the most out of AI-powered websites have stopped framing this as a choice between developer speed and marketing control. The repo-plus-agents stack is the fastest way anyone has ever operated a website, and it is not going back in the box. The visibility gap it created is real, but it is a missing layer, not a flawed foundation.

So keep GitHub at the center. Keep the pull requests, the reviews, the deploy previews — the safety net engineers built is the best one available. Then give the rest of the organization what the repo was never going to give them: a live feed they can read, approvals they can enforce, attribution they can trust, and a score for every page they are accountable for. Move beyond the limitations of your CMS without giving up the visibility, control and governance your team depends on.