+1.3score from 99 to 100
Advertise machine-readable resources with typed links
None of the 4 pages read pass. The homepage's links are all ordinary page furniture; none point an agent anywhere.
Read prompt
My website appnary.com scored 99/100 on Good for Bots (Excellent). Good for Bots measures one thing: whether a language model can read a site and cite it.
I need you to: advertise machine-readable resources with typed web links.
The check it fails is "Advertises machine-readable resources with typed links", worth 1.25 points. What the scanner saw: None of the 4 pages read pass. The homepage's links are all ordinary page furniture; none point an agent anywhere.
The scan checked a sample of 4 pages. It does not establish which other pages have the same issues. Use the findings below to locate the responsible templates, components or configuration, and apply the fix wherever the same issue occurs. Pages in the sample with findings:
- https://appnary.com/: The homepage's links are all ordinary page furniture; none point an agent anywhere.
- https://appnary.com/blog/calculate-true-roas: The page at /blog/calculate-true-roas's links are all ordinary page furniture; none point an agent anywhere.
- https://appnary.com/docs: The page at /docs's links are all ordinary page furniture; none point an agent anywhere.
- https://appnary.com/about: The page at /about's links are all ordinary page furniture; none point an agent anywhere.
Add typed discovery links through the site's shared response handling or page
templates. Review all public page types, including those outside the reported
sample, and advertise the resources that apply to each page. Verify the links on
a page from each template and check that their targets exist.
Typed links let an agent find a page's Markdown twin or an index describing it
from the response, without guessing at paths.
Follow RFC 8288. Add these either as `<link>` elements in the document head or as an HTTP
`Link` response header; both are equally valid, and the header also works for responses
that are not HTML.
The two that matter most, named by the llms.txt v2 specification:
```
Link: </page.md>; rel="alternate"; type="text/markdown",
</llms.txt>; rel="describedby"
```
- `rel="alternate"` with `type="text/markdown"` points at the markdown version of the
current page. Emit it per page, pointing at that page's own markdown twin, not at a
single site-wide file.
- `rel="describedby"` points at the `llms.txt` that covers the page.
If this project also exposes any of the following, advertise them the same way: an
OpenAPI description with `rel="service-desc"`, human documentation with
`rel="service-doc"`, an API catalog with `rel="api-catalog"`.
Two rules to respect. A relative URI is resolved against the request URL, so `</x.md>` is
fine and correct. And each link entry needs exactly one `rel` parameter, though one `rel`
may list several relation types separated by spaces.
Do not add `rel="alternate"` for a markdown file that does not exist; a link pointing at a
404 is worse than no link, because it moves the failure from discovery to fetch.
The whole report, as markdown, is at https://goodforbots.com/r/appnary.com.md?scan=cmv6d3ulg009s01qzztzp8ggf. Read it first: this prompt covers one finding, and the report has everything the scan saw.
When you are done, summarise what you changed and how to check it against a running instance. Do not try to run the Good for Bots scan yourself: it only sees what is already deployed, it is rate-limited, and re-running it is the site owner's call once the change ships.
