We make the fixes, in your codebase or your CMS

Wherever possible we work directly in your repository and deliver pull requests, scoped small enough to review properly. Your team keeps ownership and veto; nothing lands without your approval. For CMS-driven sites we work in the CMS and document every change we make.

We do not take over your site, we do not install an overlay, and we do not add a script tag that promises to fix things at runtime. Runtime patches are exactly the kind of client-side dependency that causes agent readiness problems in the first place.

At the cheap end: llms.txt, robots directives, security.txt, canonical hygiene, meta and Open Graph coverage, alt text. These are hours of work and they move the score immediately.

In the middle: structured data across templates, heading and landmark structure, form labelling and input types, navigation that uses real anchors, and search that an agent can drive by URL.

At the deep end: rendering architecture. If your content only exists after hydration, no amount of schema will help; the fix is server rendering or prerendering for the routes that matter. This is the most expensive work and the one with the largest score movement, which is why we scope it against your architecture rather than your page count.

Most sites score zero on machine endpoints today, because almost nobody publishes one. That makes it the cheapest available differentiation: an agents.json, a documented read-only API with an OpenAPI spec, or an MCP server exposing your catalogue or documentation.

This is genuinely new territory, and we would rather be honest that the standards are still moving than sell it as settled. We build to what is actually being consumed today, and we tell you which parts are a bet.