Own your website: full code ownership in the age of AI-read sites

I built my first website in 1992. Fewer than 20,000 of them existed on the whole internet, and every one was a folder of files somebody owned. You wrote the code, you put it on a server, and that was the site. There was no vendor to rent it from, because there was no vendor.

Thirty-three years later I have watched every era of the web from the inside: hand-coded HTML, the first content systems, the streaming boom (we ran the first live music broadcast out of a club on 6th Street here in Austin, Texas), the rise of the page builder, and now the era where the most important reader of your website is a machine. These machines are not a rounding error. Cloudflare, which sits in front of a large share of the web, reported that over the year to mid-2025 the crawler feeding ChatGPT grew from 4.7% to 11.7% of the AI bot activity on its network, with Claude's close behind. In every one of those eras, the same question decided who was in control: do you own the code, or do you rent it? The answer matters more today than it ever has, and I want to explain why in plain terms.

What does it mean to own your website?

Owning your website means the source code, the Git repository (the versioned record of every file and every change), the hosting account, and the domain are all yours, registered to your accounts, from day one. Not a login to someone else's system. The actual code, the actual server, the actual domain name, and the keys that unlock them.

The test is plain. If you can read every line, change any of it, and hand the whole thing to another team tomorrow without asking permission or paying to leave, you own it. If you cannot, you own an account, and the website belongs to whoever can switch that account off. That distinction sounds like a lawyer's point until the day you want to move, and then it is the only point that matters.

On the old web, you owned your site because there was nobody to rent it from. Somewhere along the way, that stopped being true.

The layers you did not know you were renting

Most websites are not owned. They are rented back to their owners one layer at a time. Start with the CMS, the content management system that sits between you and your own pages: WordPress alone runs 41.2% of all websites as of mid-2026, a 59.1% share of the whole CMS market. On top of that go the theme, the plugins, and the page builder. Each layer is a monthly fee and a place to break.

The breaking is not theoretical. Patchstack, which tracks security holes across the WordPress world, found that 97% of new vulnerabilities live in plugins, 3% in themes, and only 0.2% in the core software itself. Read that again. The parts you bolt on to get around what the builder cannot do are almost the entire attack surface. And the deepest cost is not a fee or a patch. It is the sentence a web team says when you ask for something reasonable: "the builder can't do that." That is the ceiling you paid to stand under.

Renting the layers

A hosted builder or CMS keeps the engine. You get a login and an editor. The templates, the plugins, and often the content itself live in the vendor's private format, on the vendor's servers. Leaving means rebuilding, so mostly you do not leave.

Owning the code

The source code, the repository, the hosting, and the domain sit on your accounts. You can read it, change it, move it, or hand it to any developer. There is nothing to leave behind, because nothing is being held for you.

Why the AI era makes ownership matter more

Here is the part that is genuinely new. The most consequential reader of your website is now a machine, and machines read code, not screenshots. Vercel studied how the AI crawlers actually behave and found that the ones feeding ChatGPT and Claude fetch your JavaScript files but, in their words, "don't execute them. They can't read client-side rendered content." ChatGPT's crawl is 57.70% raw HTML. If your content only appears after a builder's script runs inside a visitor's browser, the AI engine never sees it. The server-rendered code is the only version these readers get.

There is a second layer to it. The machines now look for surfaces that only exist if you can touch the code. One example is llms.txt, proposed by Jeremy Howard of Answer.AI in September 2024: a markdown file that "outlines the information that a model may want to retrieve (with links) when assembling context for LLM prompts relevant to a website." Add structured data, entity markup, a signed identity a bot can verify, and you have a site built for both readers at once. None of it is possible if your site is sealed behind a builder that will not let you near the code. Owning the code is simply what lets you answer to the human reader and the machine reader in the same breath.

I learned this instinct the hard way, long before AI. For a decade I owned the code behind a Texas state agency's public sites, including disaster-recovery sites people relied on during an emergency. When a site is that important, you do not want it one vendor policy change away from breaking, on a platform you cannot open up and fix. That was true for accessibility law then. It is true for AI readers now. Ownership is not a preference. It is how you stay able to fix your own site.

What full ownership actually looks like

This is the standard we build to, so let me be concrete about it. An agentic website is built straight to code: no themes, no plugins, no page builder. It is built on your own accounts from the start, and the published promise is exact: your hosting, your domain, your repository, your keys, from day one, with nothing living with us, so there is nothing to migrate away from later.

Because the whole site is versioned in Git, there is a full audit trail of how every page came to be, and a known-good version of the entire site can be redeployed in minutes if anything ever goes wrong. New capabilities, a dashboard, an approval queue, an integration, are built into the site through APIs instead of rented from a stack of third-party providers that each add a fee and a point of failure. When you approve a change, it publishes to your live site within seconds through an automated deploy. And when you want to run it yourself, the handoff is a training session, not a migration, because it already lives on your accounts.

Set that against a template platform or a hosted site builder. Those tools are fast to start, and for a simple brochure site they can be a reasonable choice, I will grant that plainly. But the code, the templates, and often the content stay in the vendor's system. The one question settles it.

If you cannot be handed the whole repository and walk, you do not own a website. You own a login.

41.2%

of all websites run on WordPress alone

W3Techs, mid-2026

97%

of new WordPress vulnerabilities live in plugins, not core

Patchstack, State of WordPress Security

Seconds

from an approved change to the live page, via automated deploy

published Trinzik /agentic-websites claim

Where this is heading

The durable asset in front of you is not a dashboard or a subscription. It is the authority of your own domain and the code that carries it, and both of those belong to nobody but you when they are built right. The AI engines are reading that code every day, in growing numbers, and they act on what they can read. The businesses that will do well are the ones who own the thing being read.

Our own published case studies hold the working method to verified numbers, including a client whose AI recommendations grew a verified 480% in eleven weeks. That kind of result comes from running a loop, measuring how the AI describes your category, then engineering the content that changes the answer, with a human in control of every piece, not just in the loop. A loop like that runs best inside code you own, because every fix it finds is a direct change to your own site, deployed and verified in one step. Own the code, and you own the compounding. That is the whole case for ownership, in the AI era and every era before it.

Questions this raises

What does it mean to own your website code?

Owning your website code means the source code, the Git repository, the hosting account, and the domain are all registered to you, not to a platform you rent. You can read every line, change it, move it, or hand the whole thing to another team without asking permission or paying an exit fee. If a vendor holds any of those pieces, you own a login, not a website.

What is vendor lock-in in a website builder?

Vendor lock-in is when your site only runs inside one company's system, so you cannot take it with you. Template builders and hosted platforms often keep the code, the templates, and even the content in their own private format on their own servers. Leaving means rebuilding from scratch. The tell is simple: ask for your full source code and repository. If the answer is no, you are locked in.

Can you move an existing website to full code ownership?

Yes. The move starts by capturing everything on your current site, every page, image, and PDF, and holding it as the build source so nothing is lost. The new site is then built straight to code on your own hosting, domain, and repository, with your content migrated into it. Because it all lives on your accounts from day one, a later handoff is a training session, not a migration.

Sources

← All dispatches