Er marginal.dk 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 1 user-agent group(s).

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

  Sitemap found with 90 URL(s).

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

  Valid llms.txt with 5 section(s) and 0 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://marginal.dk/PAGE-PATH>; rel="canonical", <https://marginal.dk/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://marginal.dk/index.html.md, not https://marginal.dk/index.md.
  

  Læs specifikationen →

• robots.txt nævner AI-crawlere eksplicit Skal forbedres

  No AI crawler is named explicitly, so all of them fall back to your "*" rules.

  State explicit rules for AI crawlers in robots.txt

  Naming specific AI user agents makes your intent unambiguous rather than leaving them to your "*" fallback — but "AI crawler" is not one behaviour. GPTBot (OpenAI) and ClaudeBot (Anthropic) exist only to gather training data; OAI-SearchBot, ChatGPT-User, Claude-SearchBot, Claude-User and PerplexityBot fetch pages to answer live queries with citations and do not train on what they fetch. Allowing one does not imply the other, so decide per name, not per company. Google-Extended is not a crawler at all — Googlebot already fetched the page for Search — but disallowing it costs you two things at once, not one: it opts your content out of both Gemini model training AND grounding (Google using your page from its Search index to make Gemini/Vertex AI answers more factual, including citations back to you). If you want the citations but not the training, there is no separate token for that — disallowing Google-Extended is an all-or-nothing choice for Google specifically, unlike OpenAI and Anthropic's separately-named bots.

  /robots.txtKopiér

  # Allowed: on-demand fetches and citation/search crawlers.
  # None of these train models on what they fetch.
  User-agent: ChatGPT-User
  User-agent: OAI-SearchBot
  User-agent: Claude-User
  User-agent: Claude-SearchBot
  User-agent: PerplexityBot
  Allow: /
  
  # Blocked: crawlers whose stated purpose is training models on this content
  User-agent: GPTBot
  User-agent: ClaudeBot
  User-agent: CCBot
  Disallow: /
  
  # Google-Extended is a control token, not a crawler: Googlebot already
  # fetched this page for Search. Disallowing it opts out of BOTH Gemini
  # training AND grounding (Gemini/Vertex AI citing this page from Search) —
  # there is no way to keep one and refuse the other.
  User-agent: Google-Extended
  Disallow: /
  

  Læs specifikationen →

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

  10,512 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 something that is not Markdown, so agents cannot get a clean text version 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 Bestået

  JSON-LD found: WPHeader, WPFooter, Corporation, WebSite, BreadcrumbList, Person.

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

  Læs specifikationen →