# Building an Agent-Ready Website: A 4-Week Project Plan

**Author:** John Morabito (Founder, /winston)
**Published:** June 14, 2026
**Reading time:** 15 minutes
**Canonical:** https://www.winstondigitalmarketing.com/playbooks/agent-ready-website-4-week-plan/

An agent-ready website is one an AI agent can read, parse, and act on, not just one a human finds pretty. It takes three layers working together: content an agent can retrieve cleanly, an entity graph it can trust, and an action surface it can call. This is the exact four-week build order to ship all three.

## What "agent-ready" actually means

Most websites are built for one reader: a person with a browser. An agent-ready website is built for a second reader too, an AI agent that arrives without a browser, without patience for client-side JavaScript, and with a job to do. Making a site agent-ready means three layers: content an agent can retrieve cleanly, an entity graph it can trust, and an action surface it can call. Miss any one and the agent either skips you or guesses, and a guessing agent sends its user to a competitor it could parse.

None of this is exotic. It is server-rendered HTML, connected schema, markdown twins, an llms.txt, and a small MCP server. The work is sequencing it so each week ships something usable.

This plan assumes one focused team and a site under a few hundred pages. A large or heavily client-rendered site stretches week one. If you are not sure whether your current site even renders for agents, the 90-minute technical audit (https://www.winstondigitalmarketing.com/playbooks/technical-seo-audit-90-minutes-claude/) includes the rendering-parity check.

## Week 1: audit and the schema rebuild

You cannot make a site agent-ready until you know what an agent currently sees. Week one is diagnosis, then the foundation layer.

- **Rendering parity check.** Fetch every key page the way an agent does (no JavaScript execution) and compare it to what a browser renders. Anything that only appears after client-side hydration is invisible to most agents. Fix that first, usually by moving to server rendering or pre-rendering the critical content.
- **Schema rebuild.** One connected entity graph, not floating fragments: an Organization block, a Person block for each named human, and Article or Product or Service blocks that reference them with stable @id values. The full pattern lives in schema markup for AI engines (https://www.winstondigitalmarketing.com/playbooks/schema-markup-for-ai-engines-2026/).
- **Stable identifiers.** Decide your @id scheme now (we use fragment refs like /#org and /#john) so every later layer points at the same entities.

Ship at end of week one: a site that renders for agents, and an entity graph that validates.

## Week 2: markdown twins and llms.txt

Agents parse clean markdown far more reliably than a styled HTML page wrapped in nav, footer, and tracking. Week two gives them a clean path.

- **Markdown twins.** A plain-markdown version of every page that matters, served at a predictable path (we mirror page content into /content/ as .md files with full URLs). The twin carries the same content as the page, stripped of layout.
- **llms.txt.** One file at the root that lists your important URLs grouped by section, each with a one-line description, pointing agents at the markdown twins where they exist.
- **Serve markdown to agents.** The cleaner setup serves the .md version to known AI user agents and the HTML version to humans, decided at the edge.

Ship at end of week two: every key page has a clean machine-readable twin, and a single file tells agents where to find them. This is the full reading layer, and many sites should stop here on the first pass.

## Week 3: the MCP server

The first two weeks let agents read you. Week three lets them do something. An MCP server is the action layer: a small service that exposes your data and a few safe operations through a standard protocol any compliant agent can call. The plain-language version and three marketing use cases are in MCP servers for marketing teams (https://www.winstondigitalmarketing.com/playbooks/mcp-servers-for-marketing-teams/).

- **Pick two or three operations.** Start narrow. Live inventory or availability, an appointment or quote request, an account or order status. Read-mostly first, writes later and gated.
- **Build and deploy.** Wrap the data sources you already have (your CMS, your booking system, your catalog) behind MCP tools with clear names and descriptions, because the description is what the agent reads to decide whether to call it.
- **Gate the dangerous parts.** Anything that moves money, sends a message, or changes a record needs an explicit confirmation step or stays out of the agent's reach entirely.

Ship at end of week three: an agent can answer a live question about your business by calling your MCP server.

## The 4-week build, at a glance

| Week | What ships | Layer it completes |
|---|---|---|
| Week 1 | Rendering parity + connected schema | Foundation (agents can see you) |
| Week 2 | Markdown twins + llms.txt | Reading (agents can retrieve you cleanly) |
| Week 3 | MCP server with 2-3 operations | Action (agents can do something) |
| Week 4 | Agent simulation + handoff | Verification (it actually works) |

## Week 4: simulation, testing, and handoff

The last week proves the first three. You declare a site agent-ready because an agent ran the gauntlet and succeeded.

- **Agent simulation.** Point a real agent at your site and ask it the questions your customers ask. Does it find the answer? Does it cite the right page? Does it call the MCP tool correctly? Each failure is a fix.
- **Citation spot-check.** Run your top customer questions through the major AI engines and see who gets named. When it is not you, the gap is your next content unit. Measuring this over time is its own discipline, covered in citation share, the metric that replaced Google rankings (https://www.winstondigitalmarketing.com/playbooks/citation-share-replaces-rankings/).
- **Handoff and monitoring.** Document the schema scheme, the twin-generation process, and the MCP tool list. Set a monthly re-check, because agents and engines change and parity drifts.

## What this costs and where it fits

The reading layer (weeks one and two) is mostly content and configuration work and pays back fast. The action layer (week three) is a real build with a real bill, scoped to how many operations you expose and how messy your back-end systems are. We run the whole sequence as a fixed-scope project through the agentic web service, and the pricing reasoning behind productized scopes is in why we publish our pricing (https://www.winstondigitalmarketing.com/playbooks/why-we-publish-our-pricing/). If a vendor quotes "AI-ready website" without naming schema, twins, or an MCP server, they are selling the phrase, not the build.

Service: https://www.winstondigitalmarketing.com/services/ai-marketing/agentic-web/
Audit: https://www.winstondigitalmarketing.com/contact/#audit