# Make Your Site Agent-Readable: start prompts Paste this into your AI after you get Make Your Site Agent-Readable. There are two prompts. Paste the first one in the session where you start using the journal on your site. Paste the second one at the start of every later session, so your AI picks up where it stopped. ## Prompt 1: first session (read, measure, plan) ```text I bought the journal "Make Your Site Agent-Readable". It is the record of upgrading eight live sites on four different stacks (and building a ninth from day one) so that AI crawlers and assistants can read them, measured against Cloudflare's free public agent-readiness scanner, without breaking a page, a checkout or an ad campaign. It also covers what the scanner never checks (product structured data, sitemaps, canonicals, llms.txt), the search indexes assistants read, how to measure the channel honestly, and the traps of putting a sign-in MCP server on your own site. Your job is to read it, measure my site first, and take it up the pipeline in the journal's order, one step at a time, verifying each step against the live site. WHAT IT IS FOR Making my site legible and quotable to AI agents: robots signals, discovery cards, link headers, markdown versions of key pages, agent skills, structured data, sitemaps and canonicals, llms.txt, Bing and IndexNow, a product feed, and measuring visits that come from assistants. The journal is clear on the limit: this makes you readable, it does not make any assistant recommend you; most citations live on other people's pages. WHEN TO USE IT - When I ask how AI assistants see my site, or want it to show up in their answers. - Before you touch robots.txt, headers, the sitemap, canonicals or structured data. - After any redesign or pricing change (structured data, llms.txt and the machine-facing summaries must be rechecked). HOW TO GET AND READ THE JOURNAL - With the Vibedna connector: call list_library, find the slug make-your-site-agent-readable, then read_journal(slug="make-your-site-agent-readable", part=1), then part=2, 3 and so on until there are no more parts. Read every part before you propose changes. - With Journals DNA paired: journal_get(slug="make-your-site-agent-readable") writes it into ~/.journal/library; read it from there with journal_read (use offset and limit). - Read in this order: "What this is" and "How to read the decisions here" first (these standards are young and moving: where the spec and a passing site disagree, the journal copies the passing site; re-verify with the scanner). Then "The pipeline, end to end" and its "Architecture rules", then the recipe for my stack in "Recipes per stack", then "The shelves the scanner never checks", "AI crawlers, search indexes and the feeds behind assistant answers" and "Measuring the channel honestly". Read "Past level 4" only if I want an MCP server on my site. Before any change, read "Bug to root cause to fix catalog", "Decisions and the reasoning" and "Lessons for the next site". ASK ME FIRST (only what the journal says changes the work) 1. My domain, exactly as it is in my records (the journal once scanned a lookalike domain by mistake). 2. My stack: Next.js on Vercel, static-heavy Astro on Vercel, Astro behind a platform Worker, a hand-written Cloudflare Worker, or something else? (Two of these have an honest ceiling at level 2.) 3. Which pages take money, which pages do my ads and emails send people to, and which legacy redirects carry campaigns? (These stay untouched: no markdown twin, no experiments.) 4. What is my policy for AI use: indexed, quoted in answers, used for training? (The journal's default is search yes, AI input yes, training no; it is my choice.) 5. Do I sell products (then structured data with the real price, and maybe a product feed)? Is any of it paid content that must stay out of the agent surface? 6. Is my product an MCP server, or do I want customers to connect their AI to their account on my site? THE PIPELINE, IN THE JOURNAL'S ORDER (each step assumes the one before it works) 1. Measure before touching anything: scan my site with the scanner's API and record the level and the exact URLs it probed (those probe URLs are the spec). 2. Scan a known level-4 reference site and copy its file formats, not the written spec. 3. Robots with Content Signals: find the robots.txt that is really served and where it comes from, keep every existing line byte for byte, add one Content-Signal line plus its comment block. 4. The discovery cards under /.well-known/: ai-catalog.json (with representative queries), api-catalog (no extension, forced content type), and the MCP server card only if my product is an MCP server. 5. One Link header on every page pointing at the cards and the sitemap, plus Vary: Accept. 6. Markdown negotiation for a handful of pages that explain the site, served only when the request asks for text/markdown, using my stack's recipe (not middleware on Next.js). 7. Agent Skills, only if I have teachable workflows, in the archive layout the scanner passes. 8. Verify like a buyer, then re-scan after propagation. 9. Then the shelves and the indexes: Product and Offer structured data server-rendered with the price checkout charges, Organization on the home page, clean sitemaps (real lastmod only), one host and one URL form with a matching canonical, llms.txt generated from the same source as the pages, Bing Webmaster Tools, IndexNow done right, and a product feed if I sell products. Then measure the channel: assistant referrers in my own event table, joined to the session that bought. HOW TO VERIFY EACH STEP (the journal's own tests) - After each deploy: every page that takes money answers 200, every legacy redirect still redirects, any payment-processor verification file still responds, an unknown URL returns a real 404, and the scanner shows the new level. Wait for propagation before trusting a pass or a failure. Never call it done on "the deploy succeeded". - Check what a crawler really gets: fetch with Accept: text/markdown, fetch a product page with each AI crawler's user agent the journal lists (a 200 and no bot challenge), and fetch with JavaScript off to see the structured data. - Read IndexNow results as "N URLs, X of Y batches accepted"; a 202 is only a receipt. - After a redesign, check the most expensive offer by name for its structured data. WHAT TO CHECK FIRST The live site, not my repo: the scan result, the robots.txt being served and its source, existing headers and middleware, how the site really routes languages if it has several, which caching headers responses carry, and which environment variables exist in production. NEVER - Never deploy, change DNS, submit to a search console, ping an index or send a merchant form without my yes in this session. Show me the exact change first. - Never touch the funnel: ad landing pages and checkout pages get no agent surface and no experiments. - Never rename or delete a URL an assistant may already cite; add new pages next to old ones. - Never gate anything on the new behavior: the cards and markdown views are a parallel, read-only surface. - Never rewrite robots.txt; only add the signal line. And remember a signal is not a block: keeping a crawler out takes a per-bot rule. - Never publish paid content in the cards, skills or markdown views; describe it and link to the store. - Never type a claim by hand into llms.txt or any machine-facing summary: generate it from the same source as the pages, check it against the product itself, and fix the human page in the same change. - Never cache a response whose body depends on a cookie or Accept-Language as public. - Never put keys or tokens in code, a journal or this chat. KEEP MY PROJECT JOURNAL - If I have Journals DNA: after each step, journal_append(name_or_path="", entry="", tag="ship" or "fix"). When I choose something (my AI-use policy, a stack ceiling I accept, which pages get a markdown twin), journal_decision_add(name_or_path="", decision="...", why="..."). When the level or state changes, journal_update_section(name_or_path="", "Current state", new_content, mode="replace"). - If I do not: keep a plain _JOURNAL.md in my project folder with a dated line for each scan, each step done, each decision, and each bug with its root cause. HOW TO REPORT BACK Result first, in plain words: the scanner level before and after, what you changed (file by file), and the live checks that passed. Report small numbers with their sample ("3 of 12"), never only a percentage. Name the journal section you relied on. End with one question if a decision is mine. FIRST TASK NOW Read part 1 of the journal (and the rest before proposing anything). Ask me the six questions above. Then scan my site and one reference site, read my code and my live responses, and give me an audit against the nine pipeline steps: for each step say done, missing or broken, with the evidence, plus my stack's honest ceiling. Change nothing yet. End with the one step you would do first and why. ``` ## Prompt 2: every later session (continue) ```text We are making my site agent-readable with the journal "Make Your Site Agent-Readable". Continue from where we stopped. 1. Read my project journal first (journal_handoff_brief("") if I have Journals DNA, or my _JOURNAL.md). Tell me in five lines the last scanner level, which steps are done, which one is next, and what is waiting on me. 2. Re-scan the site before trusting the level my journal says, and re-open the journal section for the next step (read_journal with the part that holds it, or the copy in ~/.journal/library) and its rows in the bug catalog. 3. Do one step, verify it like a buyer and with the scanner after propagation, log it with journal_append, then stop and show me. 4. Deploys, DNS changes, search console or index submissions and merchant forms wait for my yes. 5. Once a month: run my frozen set of real buyer questions through the assistants twice and log whether I am named and which URLs are cited. 6. At the end of the session, replace the Handoff section of my project journal: what is done, what is next, what is blocked by me. ```