Is alugantia.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 5 user-agent group(s).

• XML sitemap is reachable and lists URLs Pass

  Sitemap found with 3 URL(s).

• llms.txt follows the llmstxt.org specification Pass

  Valid llms.txt with 4 section(s) and 8 link(s).

• Link response headers expose related resources Pass

  Link header present: <https://alugantia.com.br/wp-json/>; rel="https://api.w.org/", <https://alugantia.com.br/wp-json/wp/v2/pages/7>; rel="alternate"; title="JSON"; type="application/json", <https://alugantia.com.br/>; rel=shortlink

• robots.txt names AI crawlers explicitly Pass

  Explicit rules for GPTBot, ClaudeBot, OAI-SearchBot, Google-Extended.

• Content Signals declare how content may be used Pass

  Content-Signal directives: ai-train=no, search=yes, ai-input=yes.

• AI crawlers can actually retrieve your homepage Pass

  All 5 AI crawlers that answered received the same page a browser does.

• 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 Pass

  7,589 characters of text are present in the HTML before any JavaScript runs.

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

  The server ignores "Accept: text/markdown" and returns HTML, so agents must parse markup to read 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 Pass

  JSON-LD found: WebPage, BreadcrumbList, WebSite, Organization.

• One h1, and a main or article landmark Pass

  A single <h1> inside a content landmark.

• Publication dates or authors are marked up Pass

  Publication date and/or author signals are present.

• 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://alugantia.com.br/api",
        "service-desc": [
          { "href": "https://alugantia.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://alugantia.com.br",
    "authorization_endpoint": "https://alugantia.com.br/oauth/authorize",
    "token_endpoint": "https://alugantia.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://alugantia.com.br",
    "authorization_servers": ["https://alugantia.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://alugantia.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://alugantia.com.br/images/product.jpg",
    "offers": {
      "@type": "Offer",
      "url": "https://alugantia.com.br/products/product-name",
      "price": "49.00",
      "priceCurrency": "EUR",
      "availability": "https://schema.org/InStock"
    }
  }
  </script>
  

  Read the spec →