Er alugantia.com.br klar til AI-agenter?

Erklæret adgang kontra faktisk adgang

Hvad din robots.txt tillader, side om side med hvad din server faktisk svarede. En uoverensstemmelse skyldes normalt en CDN- eller firewallregel, som din applikation aldrig ser.

Vi sender hver crawlers eget token efterfulgt af vores egen identifikation, så vi aldrig udgiver os helt for at være en anden udbyder. En firewall, der matcher en crawlers præcise user-agent-streng, reagerer derfor ikke på vores forespørgsel, så vi kan komme til at overse enkelte blokeringer.

• robots.txt er offentliggjort og kan læses Bestået

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

• XML-sitemap kan hentes og indeholder URL'er Bestået

  Sitemap found with 3 URL(s).

• llms.txt følger llmstxt.org-specifikationen Bestået

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

• Link-headere viser relaterede ressourcer Bestået

  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 nævner AI-crawlere eksplicit Bestået

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

• Content Signals erklærer, hvordan indhold må bruges Bestået

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

• AI-crawlere kan faktisk hente din forside Bestået

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

• Web Bot Auth-nøglekatalog er offentliggjort Skal forbedresBonus

  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-directoryKopiér

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

  Læs specifikationen →

• Indhold findes i HTML'en før JavaScript kører Bestået

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

• Serveren returnerer Markdown, når en agent beder om det Skal forbedres

  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)Kopiér

  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()
  })
  

  Læs specifikationen →

• Markdown-versioner af sider findes på .md-URL'er Skal forbedres

  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.

  RoutingKopiér

  # 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")
  

  Læs specifikationen →

• JSON-LD identificerer sitet Bestået

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

• Én h1, og et main- eller article-element Bestået

  A single <h1> inside a content landmark.

• Udgivelsesdato eller forfatter er angivet i sidens markup Bestået

  Publication date and/or author signals are present.

• API-katalog er offentliggjort (RFC 9727) Skal forbedresBonus

  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)Kopiér

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

  Læs specifikationen →

• OAuth authorization server-metadata (RFC 8414) Skal forbedresBonus

  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-serverKopiér

  {
    "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"]
  }
  

  Læs specifikationen →

• OAuth protected resource-metadata (RFC 9728) Skal forbedresBonus

  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-resourceKopiér

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

  Læs specifikationen →

• WebMCP registrerer værktøjer på siden til agenter Skal forbedresBonusSkøn

  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 scriptKopiér

  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) }
    },
  })
  

  Læs specifikationen →

• Ingen forældet ai-plugin.json-manifest Ikke relevantBonus

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

• Universal Commerce Protocol-manifest er offentliggjort Skal forbedresBonus

  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 documentKopiér

  {
    "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"
      }
    ]
  }
  

  Læs specifikationen →

• schema.org Product- eller Offer-markup findes Skal forbedresBonus

  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>Kopiér

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

  Læs specifikationen →