Er propostas.zionmarketing.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 9 user-agent group(s).

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

  Sitemap found with 5 URL(s).

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

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

• Link-headere viser relaterede ressourcer Skal forbedres

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

  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.
  

  Læs specifikationen →

• robots.txt nævner AI-crawlere eksplicit Bestået

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

• Content Signals erklærer, hvordan indhold må bruges Skal forbedres

  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.txtKopiér

  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
  

  Læs specifikationen →

• AI-crawlere kan faktisk hente din forside Skal forbedres

  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.

  Læs specifikationen →

• 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 Skal forbedres

  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.

  Læs specifikationen →

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

  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)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 Skal forbedres

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

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

  Læs specifikationen →

• Én h1, og et main- eller article-element Skal forbedres

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

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

  Læs specifikationen →

• Udgivelsesdato eller forfatter er angivet i sidens markup Skal forbedres

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

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

  Læs specifikationen →

• 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://propostas.zionmarketing.com.br/api",
        "service-desc": [
          { "href": "https://propostas.zionmarketing.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://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"]
  }
  

  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://propostas.zionmarketing.com.br",
    "authorization_servers": ["https://propostas.zionmarketing.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://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"
      }
    ]
  }
  

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

  Læs specifikationen →