The starting point

dirango.com already served its main content in HTML, published a sitemap and connected its organization and services through structured data. Its public robots rules permitted search crawlers. The missing piece was a maintained Markdown representation and a clear way for compatible agents to discover it.

On October 31, 2026, Cloudflare's agent-readiness scanner assigned the site Level 2, “Bot-Aware.” Its next requirement was Markdown content negotiation. The scanner also classified the agency website as commerce, apparently because of our Shopify service references. We treated its findings as inputs to review, rather than a universal specification.

The first release

After deployment on October 31, 2026, the same scanner reported Level 3, “Agent-Readable,” with passing Markdown negotiation and discovery-link checks. Our release readback verified all 158 public static files, including a Markdown representation for each of the 26 published pages. These figures describe the first release, including this case study; they are not a claim about traffic or recommendations.

What we implemented

  • One content source. Each generated page has a Markdown representation derived from its published HTML. Headings, links, examples and tables stay connected to the human-readable page.
  • A format choice. Compatible clients can request Markdown at the normal page address. Browser requests continue to receive HTML by default.
  • Discoverable alternatives. Pages advertise their Markdown representation. A generated content index lists the pages included in the build.
  • Clear attribution. Our organization and founder have connected identities. Existing article publication dates and editorial attribution remain intact.
  • Publishing controls. Production representations follow the publication ledger. Future articles and private monitoring data are excluded.

Inspect a real response

Request the homepage in Markdown, or open its static Markdown representation. The canonical URL continues to identify the HTML page.

curl -i https://dirango.com/ \
  -H 'Accept: text/markdown'

The response should identify its format as text/markdown. Negotiated responses vary by Accept and use a conservative cache policy to avoid serving Markdown to a browser that requested HTML.

What we verify

  1. Every published page has a matching representation and canonical reference.
  2. Article examples, code, links, dates and meaningful image descriptions survive conversion.
  3. Unpublished articles stay out of production files and the content index.
  4. HTML and Markdown requests return the intended format, including explicit format exclusions.
  5. The inquiry form's validation, review and edit steps remain usable, while private monitoring still requires authentication.

From readable content to a useful workflow

The next step was a task that fits an agency website: help someone identify a service, inspect relevant work and organize a project brief. We added a service finder, two real public agent tools and a guide to using them.

  • Service lookup. A published catalog connects the six services available at that stage to their existing descriptions, platform scope and relevant public work or examples. Matching follows explicit topics rather than invented recommendations.
  • Draft preparation. An assistant can supply project answers and learn which required project details are missing. Browser preparation can fill empty fields on Contact and stops before overwriting a different answer.
  • Human review. The person enters contact details, checks the draft, opens the review and decides whether to consent and send. Agent tools cannot submit an inquiry.
  • Real interfaces. The same validation powers the browser tools and public HTTP/MCP operations. The published OpenAPI contract and API catalog describe those operations. Experimental discovery cards and skill documents point to working capabilities.

Remote preparation returns draft data without storing an inquiry or sending email. It cannot place answers into another browser session. WebMCP availability depends on the browser; the ordinary service finder and project form remain usable.

The second release: Level 5

After the workflow deployment on October 31, 2026, the scanner's browser report displayed Level 5, “Agent-Native,” at 73/100. API Catalog, MCP Server Card, Agent Skills, WebMCP and ARD discovery checks passed. Our own readback verified all 170 public static files and the Markdown representations for 27 published pages, alongside the live lookup and draft-preparation tools. The MCP endpoint also passed an official client SDK connection and tool-call check.

The observed grade is the scanner's highest level, while its remaining checks include DNS discovery and authentication features this public workflow does not use. Commerce checks are optional. This is a dated technical observation, not a certification or a measured increase in leads.

Completing DNS discovery

A follow-up scan on October 31, 2026 reported Discoverability 4/4 (100%) and 80/100 overall, while retaining Level 5. We published a dedicated HTTPS discovery record for the real service host and completed DNSSEC validation. Cloudflare continues to host our DNS; the domain registrar, GoDaddy, publishes the matching DS record that anchors the signatures.

We verified the signing-key match and authenticated discovery responses through validating resolvers. DNS-AID is an emerging draft and support varies between clients. The existing service lookup and project brief preparation remain the actions available to assistants, with human review before an inquiry is sent.

Testing the complete journey

Verification covers service relevance, malformed and oversized requests, missing project answers, budget validation, protocol negotiation, safe handling of literal text, prevention of answer overwrites, keyboard access, and the existing review and edit steps. Runtime release checks exercise lookup and preparation without calling contact delivery. We also test the MCP endpoint with the official client SDK.

Our target is a working journey with a clear review boundary. This services website has no customer checkout or account system, so payment and authentication metadata would describe capabilities it does not offer. A higher readiness grade is useful only when it reflects something people and their assistants can actually use.

From a free scan to a quote

We also built a free homepage readiness scanner using Cloudflare’s URL Scanner API. Visitors can read the report without entering an email address. Cloudflare’s checks and levels are shown separately from our recommendations, which account for whether the site is a content website, online store or application.

A report can open the Contact page with a public scan reference. The visitor chooses whether to add the findings, completes the remaining project details and reviews the brief before sending. Running a scan creates no inquiry, email or marketing signup.

The scanner accepts public homepages, verifies their DNS, uses Cloudflare Turnstile and limits new submissions. It caches a limited report for 24 hours. Provider credentials stay on the server; raw browsing records, cookies and response bodies are excluded from the report we store. Public scan visibility is explained before the visitor submits a URL.

At connection on October 31, 2026, Cloudflare’s URL Scanner API report returned 23 checks and Level 4, “Agent-Integrated,” without a percentage score. Its next-level requirements included Auth.md and an A2A Agent Card. The earlier 80/100 result above came from the isitagentready.com browser report. We keep these observations separately attributed; the free scanner shows the API’s current result.

What this establishes

This is a technical implementation case study. Readability, discovery and tested task completion are observable results. A scanner grade does not establish better rankings, more AI recommendations, increased traffic or additional inquiries. Those outcomes need subsequent observation, and other website changes can affect them.

Google says that its generative search features use established SEO foundations and require no special AI text file, Markdown or schema. Our content index and Markdown support are conveniences for systems that use them. Read Google's guidance on generative AI search.

Applying the approach to your website

We start with the information and tasks your customers need. A public-service website might need clear program details and accessible documents. A store might need complete product information and reliable cart behavior. An application may benefit from dedicated agent tools once the intended action and permissions are defined.

Our review covers discovery, content clarity, technical access and a small set of real journeys. We agree on the implementation scope, make the changes and retest them. Shared SEO and accessibility fixes belong in the same scope so work is counted once.

Sources and implementation context

Start with your website.

Send us the site and the task you want customers or their assistants to complete. We will help identify useful changes and define a testable scope.

Discuss website readiness Explore agent-ready website services