esportnow.pl

Time to first byte is how long your server thinks before it starts answering: the gap between an agent asking for the page and the first byte of HTML arriving. Yours crossed our threshold (under 200ms scores full marks, over 2 seconds fails).

Agents fetch with tight timeouts and many pages in parallel. A server that takes seconds to start answering gets cut off mid-queue, and a page that times out is a page that was never read. Speed here is not polish; it decides whether the content gets fetched at all.

1. Cache the HTML itself. Marketing and docs pages rarely change per visitor; serve them from a CDN or static cache so no application code runs per request.
2. If you are on serverless hosting, cold starts are a common cause: keep the function warm or pre-render the page.
3. Move slow work (database queries, third-party API calls) out of the first response; render the shell fast and fill personalised details after.

• Run: curl -o /dev/null -s -w "%{time_starttransfer}\n" https://yoursite.com and watch the number drop.
• Hit Re-scan above: "Time to first byte" improves a bucket at a time (under 500ms passes).

• Don’t answer fast with an empty shell that loads content by JavaScript. That trades this warning for the much worse "content requires JavaScript" failure, since most agents never run your scripts.
• Don’t special-case known crawler user agents onto a faster path. Serving different performance to different audiences is the pattern crawlers penalise when they detect it.

HTTP responses can carry a Link header: the same canonical and alternate-language information your HTML declares, but delivered in the response envelope itself. Agents that only send a HEAD request, or that decide what to do while the page is still streaming, read the header without parsing any HTML. Yours is missing (or carries none of the relations agents use: canonical, alternate, describedby).

An agent triaging fifty URLs doesn’t want to download and parse fifty pages to learn which are duplicates of which. The Link header answers at the cheapest possible layer. Sites that provide it get correctly de-duplicated and correctly language-routed even by the most minimal fetchers.

1. Emit a Link header alongside each page, mirroring what your HTML head already declares. Example: Link: <https://yoursite.com/page>; rel="canonical".
2. Most stacks set this in one place: Next.js headers() config, an nginx add_header line, or a CDN response-header rule.
3. If you serve translations, add rel="alternate" entries with hreflang, matching your HTML.

• Run: curl -sI https://yoursite.com | grep -i "^link:" and confirm the relations appear.
• Hit Re-scan above: "Link response headers" flips to PASS.

• The header must AGREE with the HTML. A Link header pointing one place while the in-page canonical points another gives machines two contradictory answers, which is worse than one missing answer.
• Don’t inject the same site-wide canonical on every page via a blanket CDN rule; each page names its own clean URL, exactly as in the HTML tag.

Headings (H1, H2, H3…) are the page’s outline. Yours skip levels, repeat H1s, or use styled text instead of real heading tags, so the outline machines extract is scrambled.

Agents use the heading tree to navigate long pages and to decide which section answers a question. A broken tree means quotes get attributed to the wrong section, or sections are missed entirely.

1. Exactly one H1 per page: the page’s actual title.
2. Nest without skipping: H2 for sections, H3 for subsections. Never jump H1 to H4 for visual size.
3. If a heading looks right but is a styled <div>, make it a real <h2> and adjust CSS. Machines only see tags.

• Re-scan: "Heading hierarchy" flips to PASS.

• Don’t pick heading levels for their font size; style with CSS and keep levels semantic.

Content-Signal is a newer robots.txt directive (pushed by Cloudflare) that lets you state a granular AI policy: for example "don’t train on my content, but summarising it in answers is fine". Classic robots.txt only offers all-or-nothing per crawler; this adds the middle ground. We looked for a Content-Signal line in your robots.txt and response headers and found none.

Without a granular signal, crawlers infer your intent from blunt allow/block rules, and sites often block more than they mean to just to avoid training use. A declared signal lets you keep answer visibility (summaries, citations) while opting out of what you object to. This is an emerging standard: honoring is voluntary and adoption is early, which is why it is flagged as emerging and weighs little.

1. Decide your actual policy first: are you fine with AI training on your content? With summarisation in answers? With search indexing?
2. Express it as one line in robots.txt, for example: Content-Signal: ai-train=no, ai-summarize=yes.
3. Keep your existing User-agent rules; the signal adds nuance on top, it doesn’t replace them.

• Open yoursite.com/robots.txt and confirm the Content-Signal line is live.
• Hit Re-scan above: "Content-Signal directives" flips to PASS.

• Don’t declare signals that contradict your User-agent rules, such as ai-summarize=yes while blocking every AI crawler; conflicting instructions get you treated as unreliable.
• Don’t add the line just for the score. It is a public policy statement; say what you mean, because compliant crawlers will act on it.

MCP (Model Context Protocol) is how AI assistants call tools. A server card is a small JSON file at /.well-known/mcp/server-card.json that announces "this site offers these tools" so an assistant can find them without scraping your pages. We requested that file from your site and found none.

Assistants that support MCP look for the card at that exact address. With one, "book an appointment on yoursite.com" can become a tool call instead of screen-driving your UI. This is an emerging standard, so it weighs little today; publishing early costs one static file and makes you visible to the assistants adopting it.

1. If you already run an MCP server, describe it: name, description, and endpoint URL in the card.
2. If you don’t, a minimal truthful card naming your site and linking your API docs is still valid. The generated starter in the Fix it section below is filled in for this site.
3. Serve it at exactly /.well-known/mcp/server-card.json with content type application/json.

• Open yoursite.com/.well-known/mcp/server-card.json and confirm it returns your JSON, not a 404 page.
• Hit Re-scan above: "MCP server card" flips to PASS.

• Don’t advertise tools that don’t exist. An assistant that calls a declared endpoint and gets a 404 learns to skip your card entirely.
• Don’t let your framework rewrite /.well-known/* to your single-page app; the file must return raw JSON, not your HTML shell.