Is propostas.zionmarketing.com.br AI-agent ready?

Declared vs actual crawler access

What your robots.txt allows, next to what your server actually returned. A mismatch usually means a CDN or firewall rule your application never sees.

We send each crawler's own token followed by our own identifier, so we never fully impersonate another operator. A firewall matching a crawler's exact user-agent string will not react to our probe, so a small number of blocks can go unreported.

• robots.txt is published and parseable Pass

  robots.txt found with 9 user-agent group(s).

• XML sitemap is reachable and lists URLs Pass

  Sitemap found with 5 URL(s).

• llms.txt follows the llmstxt.org specification Pass

  Valid llms.txt with 5 section(s) and 15 link(s).

• Link response headers expose related resources Needs work

  No Link response header. It is optional, but it lets agents discover related resources without parsing HTML.

  Send a Link response header on key pages

  A Link header lets an agent discover related resources — canonical URL, alternates, a Markdown variant — without parsing your HTML first. The canonical URL must be that page's own URL, not a fixed value: generate the header per request, since a header configured once for every response would wrongly declare every page canonical to the same URL.

  HTTP response headers (generated per page)Copy

  Link: <https://propostas.zionmarketing.com.br/PAGE-PATH>; rel="canonical", <https://propostas.zionmarketing.com.br/PAGE-PATH.md>; rel="alternate"; type="text/markdown"
  # Replace PAGE-PATH with the current request's own path on every response.
  # The homepage is the one exception: llmstxt.org's .md convention appends
  # "index.html.md" to URLs with no file name, so its alternate is
  # https://propostas.zionmarketing.com.br/index.html.md, not https://propostas.zionmarketing.com.br/index.md.
  

  Read the spec →

• robots.txt names AI crawlers explicitly Pass

  Explicit rules for GPTBot, ClaudeBot, PerplexityBot, Google-Extended.

• Content Signals declare how content may be used Needs work

  No Content-Signal directive found, so your usage preferences are not stated in a machine-readable way.

  Declare Content Signals in robots.txt

  Content Signals state how your content may be used — training, real-time AI input, or search — separately from whether it may be fetched. Cloudflare's own policy is explicit that this is a stated preference, not a technical countermeasure: "the values of content use signal a website owner's preference, rather than issuing blocks directly" — compliant crawlers should honour it, but nothing forces them to.

  /robots.txtCopy

  User-agent: *
  Allow: /
  # search=yes: may appear in a search index (links + short excerpts)
  # ai-input=yes: may be fed into a model in real time (e.g. RAG, grounding) —
  #   this does not require the answer to cite or attribute this site
  # ai-train=no: may not be used to train or fine-tune a model
  Content-Signal: search=yes, ai-input=yes, ai-train=no
  

  Read the spec →

• AI crawlers can actually retrieve your homepage Needs work

  Your robots.txt allows GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Googlebot, but the server did not serve them the page. Something between your robots.txt and your origin — usually a CDN or WAF rule — is blocking them.

  Stop your CDN or WAF from blocking crawlers your robots.txt allows

  Your robots.txt and your edge configuration disagree: robots.txt invites specific AI crawlers, but the server did not serve them the page. Because the block happens above your application, nothing in your code will reveal it. Find the bot-management or firewall rule matching these user agents and allow the crawlers you intend to allow. On Cloudflare this is usually Security → Bots, or a custom WAF rule matching the user-agent string.

  Read the spec →

• Web Bot Auth key directory is published Needs workBonus

  No Web Bot Auth key directory. This only applies if you operate crawlers of your own, so most sites should ignore it.

  Publish a Web Bot Auth key directory — only if you operate crawlers

  This applies to whoever runs an agent, not to the sites an agent visits. If you do not operate a crawler, there is nothing to do here and it is not counted in your score. If you do, publish your signing keys at the well-known directory so sites can verify your requests. The directory format shipped below is specified by the IETF Internet-Draft draft-meunier-http-message-signatures-directory, not a finalized standard, so treat the exact shape as subject to change.

  /.well-known/http-message-signatures-directoryCopy

  {
    "keys": [
      {
        "kty": "OKP",
        "crv": "Ed25519",
        "kid": "your-key-id",
        "x": "<base64url-encoded-public-key>"
      }
    ]
  }
  

  Read the spec →

• Content is present in the HTML before JavaScript runs Needs work

  Only 40 characters of text are present before JavaScript runs. Most AI crawlers do not execute JavaScript, so they would see almost nothing.

  Server-render your content so it exists before JavaScript runs

  Your HTML arrives essentially empty and the text is assembled in the browser. Most AI crawlers do not execute JavaScript, so they see almost nothing regardless of how well the rest of your setup is configured. This is the single highest-impact change on this page. Enable server-side rendering, static generation, or prerendering for your content routes — in Next.js use Server Components or `getStaticProps`, in Nuxt use SSR or `nuxt generate`, in a plain SPA add a prerender step for public pages.

  Read the spec →

• Server returns Markdown when an agent asks for it Needs work

  The server returned HTTP 403 for a request with "Accept: text/markdown", rather than serving the page, so agents relying on content negotiation get an error instead of your content.

  Return Markdown when an agent asks for it

  When a request carries "Accept: text/markdown", serve a Markdown version instead of HTML. Agents then read your content without stripping markup, which reduces both errors and tokens. Offer both types to `req.accepts()` and check which one won — passing only `'text/markdown'` matches every request whose Accept header is `*/*` or absent (i.e. ordinary browsers), so it would serve Markdown to human visitors too.

  Server middleware (Express 5 example)Copy

  app.get('/{*splat}', (req, res, next) => {
    if (req.accepts(['html', 'text/markdown']) === 'text/markdown') {
      const md = renderMarkdownFor(req.path) // your renderer
      if (md) return res.type('text/markdown; charset=utf-8').send(md)
    }
    next()
  })
  

  Read the spec →

• Markdown versions of pages are published at .md URLs Needs work

  No Markdown version of your pages was found at the ".md" URLs we tried.

  Publish .md versions of important pages

  The llms.txt convention is to serve a clean Markdown copy at the same URL with ".md" appended — /about becomes /about.md. URLs with no file name append "index.html.md" instead, so the homepage's Markdown twin is /index.html.md, not /index.md. It gives agents your prose with no navigation, ads, or markup around it.

  RoutingCopy

  # Serve the Markdown source for each content route
  /about.md         -> markdown source for /about
  /pricing.md       -> markdown source for /pricing
  /index.html.md    -> markdown source for / (llmstxt.org: no file name -> "index.html.md")
  

  Read the spec →

• JSON-LD identifies the site Needs work

  No JSON-LD structured data found, so agents must infer what this site is from prose alone.

  Add Organization and WebSite JSON-LD

  Structured data tells an agent what your site is without inferring it from prose. Organization and WebSite on the homepage are the baseline; add Article, Product or FAQPage on the pages where they apply.

  Homepage <head>Copy

  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@graph": [
      {
        "@type": "Organization",
        "@id": "https://propostas.zionmarketing.com.br/#org",
        "name": "Your organisation",
        "url": "https://propostas.zionmarketing.com.br/"
      },
      {
        "@type": "WebSite",
        "url": "https://propostas.zionmarketing.com.br/",
        "publisher": { "@id": "https://propostas.zionmarketing.com.br/#org" }
      }
    ]
  }
  </script>
  

  Read the spec →

• One h1, and a main or article landmark Needs work

  No <main> or <article> landmark, so there is no machine-readable boundary between content and navigation.

  Use one h1 inside a main or article landmark

  Landmarks tell an agent where your content stops and your navigation starts, and a single h1 makes the page topic unambiguous. Both are cheap to add and improve accessibility at the same time.

  Page templateCopy

  <body>
    <header><nav><!-- navigation --></nav></header>
    <main>
      <article>
        <h1>The one topic of this page</h1>
        <p>Content…</p>
      </article>
    </main>
    <footer><!-- footer --></footer>
  </body>
  

  Read the spec →

• Publication dates or authors are marked up Needs work

  No publication date or author markup, which makes the content harder for agents to date and attribute.

  Mark up publication dates and authors

  Agents weigh recency and provenance when deciding what to cite. Without a date or author, your content is harder to trust and easier to skip. Keep `dateModified` current — set it from your CMS or file metadata so it updates automatically whenever the page changes, rather than hand-editing a fixed value that will silently go stale.

  Content page <head>Copy

  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Your headline",
    "datePublished": "2026-01-15",
    "dateModified": "2026-03-02",
    "author": { "@type": "Person", "name": "Author name" }
  }
  </script>
  

  Read the spec →

• API catalogue is published (RFC 9727) Needs workBonus

  No API catalogue at /.well-known/api-catalog (RFC 9727).

  Publish an API catalogue (RFC 9727)

  A catalogue at /.well-known/api-catalog points agents at your API descriptions from one predictable place, instead of relying on documentation links. Serve the document itself as `Content-Type: application/linkset+json` (RFC 9727 §3). Each entry's `anchor` is that specific API's own base URL, not your site root — list one entry per API if you have several. "application/openapi+json" is not an IANA-registered media type; RFC 9727's own example labels an OpenAPI description `application/yaml`.

  /.well-known/api-catalog (served as Content-Type: application/linkset+json)Copy

  {
    "linkset": [
      {
        "anchor": "https://propostas.zionmarketing.com.br/api",
        "service-desc": [
          { "href": "https://propostas.zionmarketing.com.br/api/openapi.yaml", "type": "application/yaml" }
        ]
      }
    ]
  }
  

  Read the spec →

• OAuth authorization server metadata (RFC 8414) Needs workBonus

  No OAuth authorization server metadata at the domain root (RFC 8414). If your issuer lives at a sub-path, this probe cannot see it.

  Publish OAuth authorization server metadata (RFC 8414)

  If agents authenticate against your API, this document lets their clients discover your endpoints and supported flows automatically rather than through hard-coded configuration.

  /.well-known/oauth-authorization-serverCopy

  {
    "issuer": "https://propostas.zionmarketing.com.br",
    "authorization_endpoint": "https://propostas.zionmarketing.com.br/oauth/authorize",
    "token_endpoint": "https://propostas.zionmarketing.com.br/oauth/token",
    "response_types_supported": ["code"],
    "grant_types_supported": ["authorization_code", "refresh_token"],
    "code_challenge_methods_supported": ["S256"]
  }
  

  Read the spec →

• OAuth protected resource metadata (RFC 9728) Needs workBonus

  No OAuth protected resource metadata at the domain root (RFC 9728). If your resource lives at a sub-path, this probe cannot see it.

  Publish OAuth protected resource metadata (RFC 9728)

  This tells a client which authorization servers can issue tokens for your API — the piece MCP clients need to complete an auth flow without manual setup.

  /.well-known/oauth-protected-resourceCopy

  {
    "resource": "https://propostas.zionmarketing.com.br",
    "authorization_servers": ["https://propostas.zionmarketing.com.br"],
    "bearer_methods_supported": ["header"]
  }
  

  Read the spec →

• WebMCP registers in-page tools for agents Needs workBonusHeuristic

  No WebMCP tool registration found (heuristic — we look for the call in the page source without executing JavaScript).

  Expose in-page tools with WebMCP

  WebMCP lets a page register tools an agent can call directly in the browser session, reusing the user's existing login rather than requiring separate API credentials. It is an early proposal, so treat it as exploratory.

  Page scriptCopy

  document.modelContext?.registerTool({
    name: 'search',
    description: 'Search this site',
    inputSchema: { type: 'object', properties: { query: { type: 'string' } }, required: ['query'] },
    async execute({ query }) {
      return { results: await siteSearch(query) }
    },
  })
  

  Read the spec →

• No deprecated ai-plugin.json manifest Not applicableBonus

  No legacy ai-plugin.json — correct for a modern site; nothing to do.

• Universal Commerce Protocol manifest is published Needs workBonus

  No Universal Commerce Protocol manifest.

  Publish a Universal Commerce Protocol manifest

  UCP (Google, co-developed with Shopify and other retail and payment partners) tells shopping agents what you sell, how to transact, and which transports you support. Google describes it as an evolving, community-driven open standard rather than a finished spec, and it competes with other agentic-commerce proposals such as OpenAI/Stripe's Agentic Commerce Protocol (ACP). The document is version-stamped (the skeleton below targets 2026-04-08), and every service and capability entry requires a `spec` URL — capabilities additionally require a `schema` URL. For any `dev.ucp.*` name specifically, both must resolve under the matching `https://ucp.dev/<version>/...` authority; a platform is told to reject the entry otherwise. Those URLs are exact and change with the spec version, so the skeleton below does not fill them in — do not paste invented values there, and do not reuse ours from an old version of this fix. Open the current spec (currently `https://ucp.dev/2026-04-08/specification/overview/`) and copy its own worked example for `services`, `capabilities` and `payment_handlers` verbatim, adapting only `endpoint` (your domain), your own payment processor's handler, and your own `signing_keys`.

  /.well-known/ucp — skeleton only; do not paste as a finished documentCopy

  {
    "ucp": {
      "version": "2026-04-08",
      "services": {
        "<your reverse-domain service name — copy the exact name from the spec>": [
          {
            "version": "2026-04-08",
            "transport": "rest",
            "endpoint": "https://propostas.zionmarketing.com.br/ucp/v1",
            "spec": "<REQUIRED — a ucp.dev URL for this spec date; copy from the current spec>"
          }
        ]
      },
      "capabilities": {
        "<your reverse-domain capability name — copy the exact name from the spec>": [
          {
            "version": "2026-04-08",
            "spec": "<REQUIRED — a ucp.dev URL for this spec date; copy from the current spec>",
            "schema": "<REQUIRED — a ucp.dev URL for this spec date; copy from the current spec>"
          }
        ]
      },
      "payment_handlers": {
        "<your payment processor's own reverse-domain name>": [
          {
            "id": "<your-handler-id>",
            "version": "2026-04-08",
            "spec": "<REQUIRED — your processor's own published spec URL>",
            "schema": "<REQUIRED — your processor's own published schema URL>"
          }
        ]
      }
    },
    "signing_keys": [
      {
        "kid": "<your-key-id>",
        "kty": "EC",
        "crv": "P-256",
        "x": "<your-base64url-encoded-public-key-x>",
        "y": "<your-base64url-encoded-public-key-y>",
        "use": "sig",
        "alg": "ES256"
      }
    ]
  }
  

  Read the spec →

• schema.org Product or Offer markup is present Needs workBonus

  No schema.org Product or Offer markup on the homepage, so shopping agents cannot read your catalogue structurally.

  Add schema.org Product and Offer markup

  Structured product data is what lets a shopping agent read your price, availability, and identifiers instead of scraping them out of your layout. Add it to every product page, not only the homepage.

  Product page <head>Copy

  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Product",
    "name": "Product name",
    "sku": "SKU-123",
    "image": "https://propostas.zionmarketing.com.br/images/product.jpg",
    "offers": {
      "@type": "Offer",
      "url": "https://propostas.zionmarketing.com.br/products/product-name",
      "price": "49.00",
      "priceCurrency": "EUR",
      "availability": "https://schema.org/InStock"
    }
  }
  </script>
  

  Read the spec →