tinder.com

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.

Of everything your server sends for this page, very little is actual readable text. The rest is code, styling, and markup wrapper. Agents fetched a lot of bytes and found few words.

Agents work with retrieval budgets. A page that is 2% text either gets skimmed (and mis-summarised) or skipped. More signal per byte means more of your actual message survives into the agent’s summary.

1. Confirm your real copy is server-rendered. See the JavaScript check; these two usually fail together.
2. Cut boilerplate wrappers: deeply nested divs, inline SVG logos repeated per section, base64 images inlined into HTML.
3. Move large inline styles and scripts into external files.
4. Check how much of the document is inline script: your report now says. If most of it is, that is your framework serializing state for hydration, often a second copy of text already in the HTML. Send only the props a component cannot recompute, and render statically where a page does not need to hydrate.

• Re-scan: "Text-to-markup ratio" improves, and "Page weight" often improves alongside.

• Don’t pad the page with keyword text to inflate the ratio. The ratio is a proxy for substance, and stuffing is the opposite of substance.

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.

WebMCP is a very new browser-side idea: the page itself exposes typed actions (add to cart, submit form) that an in-browser agent can invoke directly, instead of finding your buttons and clicking them like a human. We looked in your served HTML for its signals (an application/mcp+json script block, a navigator.modelContext hook) and found none.

Browser agents that drive your UI break whenever your markup changes and misfire on ambiguous controls. A page that declares its actions gives those agents a stable, typed interface: the action keeps working when the design changes. Adoption is at the earliest stage of anything we measure, which its small weight reflects; on transactional pages it is the most direct "agents can act here" signal that exists.

1. This applies to pages with first-class actions: cart, booking, support, account. Skip it for purely informational pages.
2. Embed a WebMCP declaration in the page: a script block of type application/mcp+json describing the page’s actions, wired to the same handlers your buttons use.
3. Start with your single most valuable action, typically add-to-cart or book, and expand only if agents actually use it.

• View the page source and confirm the declaration block is present in the served HTML, not injected after load.
• Hit Re-scan above: "WebMCP actions" flips to PASS.

• The declared action must do what the visible button does. A machine action that skips a step humans see (a disclaimer, a price confirmation) is the incoherence pattern that erodes trust in every declaration on your page.
• Don’t add an empty declaration just to pass the probe; a manifest of zero working actions is detectable and worse than absence.