Cat Names AI

My website catnamesai.com scored 59/100 on Good for Bots (Fair). Good for Bots measures one thing: whether a language model can read a site and cite it.

I need you to: serve markdown through content negotiation on all public HTML routes.

The check it fails is "Serves markdown when asked for it", worth 10 points. What the scanner saw: None of the 4 pages read pass. Asking the homepage for markdown still returns text/html.

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://www.catnamesai.com/: Asking the homepage for markdown still returns text/html.
- https://www.catnamesai.com/blog/5-common-cat-naming-mistakes: Asking the page at /blog/5-common-cat-naming-mistakes for markdown still returns text/html.
- https://www.catnamesai.com/blog: Asking the page at /blog for markdown still returns text/html.
- https://www.catnamesai.com/pricing: Asking the page at /pricing for markdown still returns text/html.

Implement content negotiation across all public HTML routes, including page types
outside the scan's sample. Put it in the shared response handling or the handlers
for each page type, so new pages receive it too. Agents need the content of any
page they follow, including pages the report did not name.

When a request arrives with `text/markdown` in its `Accept` header, the same URL that
serves HTML to a browser should return a markdown rendering of that page's content.
Requests without that header must keep getting the HTML exactly as they do now.

The response must:

- set `Content-Type: text/markdown; charset=utf-8`;
- include `Accept` in the `Vary` header, so shared caches never serve the markdown to a
  browser or the HTML to an agent (RFC 9110 says a server SHOULD send `Vary` whenever
  the representation depends on a request header);
- contain real markdown, not HTML with a different header on it;
- drop `ETag` and `Last-Modified` for the converted response, since a conditional request
  cannot be honoured against a body generated on the fly.

Work out how to do this in whatever stack this project uses. If the site is behind
Cloudflare on a paid plan, the "Markdown for Agents" zone setting does all of the above
and is the least invasive option. Otherwise implement it in the framework: middleware
inspecting the `Accept` header, a route handler that returns the markdown source, or
whatever fits the architecture here.

Strip navigation, headers, footers and cookie banners from the markdown. The point is the
content, without the page furniture around it.

Verify HTML and Markdown responses for each public page type, including URLs
outside the reported sample. Check that each Markdown response contains that
page's content and that ordinary browser requests still receive HTML.

The whole report, as markdown, is at https://goodforbots.com/r/catnamesai.com.md?scan=cmusu2i4m002u01ozgvj2mwn5. 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.

My website catnamesai.com scored 59/100 on Good for Bots (Fair). Good for Bots measures one thing: whether a language model can read a site and cite it.

I need you to: describe the pages with schema.org JSON-LD.

The check it fails is "Describes itself to machines with schema.org JSON-LD", worth 8.47 points. What the scanner saw: 2 of 4 pages read pass. The page at /blog publishes no structured data at all: no JSON-LD, no microdata, no RDFa.

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://www.catnamesai.com/blog: The page at /blog publishes no structured data at all: no JSON-LD, no microdata, no RDFa.
- https://www.catnamesai.com/pricing: The page at /pricing publishes no structured data at all: no JSON-LD, no microdata, no RDFa.

The pages identified as having no structured data need markup added through their
templates. Review the other public page types for the same gap. Use the homepage
example below where it fits, and describe each content page with types that match
its visible content. A passing homepage does not need its markup replaced.

Review structured data across the site's public page types, including those
outside the reported sample. Add or repair it in the templates that generate
each type, using that page's content. Verify a page from each template and keep
existing valid markup. Structured data gives a reader explicit names, types and
relationships for the entities the page describes.

Put a `<script type="application/ld+json">` block in the HTML the server returns. On the
home page describe the organisation and the site; on a content page describe the content
itself: an `Article` for a post, a `Product` for a product, a `BreadcrumbList` for the
trail above it.

Every entity must:

- declare `"@context": "https://schema.org"`;
- declare a `@type` that schema.org defines;
- carry a name: `name`, or `headline` for an article. A type with no name asserts that
  something exists without saying what, which is worth nothing to a reader;
- describe what is on the page. Structured data that disagrees with the visible content
  is worse than none.

A minimal, correct home page block:

```html
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://catnamesai.com/#organization",
      "name": "Example Corp",
      "url": "https://catnamesai.com",
      "logo": "https://catnamesai.com/logo.png"
    },
    {
      "@type": "WebSite",
      "@id": "https://catnamesai.com/#website",
      "name": "Example Corp",
      "url": "https://catnamesai.com",
      "publisher": { "@id": "https://catnamesai.com/#organization" }
    }
  ]
}
</script>
```

The addresses in that example are this site's. The names are not. Replace `Example Corp`
with the organisation's real name, which is the one thing here that cannot be filled in
from the outside.

Work out how to generate this in whatever stack this project uses, from the same data
that renders the page, so the two cannot drift apart.

Two mistakes account for most broken structured data in the wild. Avoid both:

1. **Do not let the template escape the JSON.** A templating engine that escapes variables
   by default will turn every `"` into `&quot;`, and the block will look perfectly correct
   in the page source while no consumer on earth can parse it, because HTML entities
   inside a `<script>` are never decoded. Use the raw output form the templating engine
   provides:
   `dangerouslySetInnerHTML` in React, `{{{ }}}` in Handlebars, `| safe` in Jinja or
   Nunjucks, `@Html.Raw` in Razor.

2. **Do not inject the block with JavaScript.** Tag managers and client-side SEO plugins
   add it after the page loads, so a crawler that does not run scripts, which is most of
   them, sees nothing at all. The block belongs in the HTML the server sends.

Several separate blocks on one page are fine; the specification requires consumers to
merge them all. A single `@graph`, as above, is just tidier.

The whole report, as markdown, is at https://goodforbots.com/r/catnamesai.com.md?scan=cmusu2i4m002u01ozgvj2mwn5. 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.

My website catnamesai.com scored 59/100 on Good for Bots (Fair). Good for Bots measures one thing: whether a language model can read a site and cite it.

I need you to: describe the links in llms.txt and open the file with a summary.

The check it fails is "llms.txt is descriptive, not a bare link list", worth 7.5 points. What the scanner saw: /llms.txt is a bare link list: 0 of 2 links have a description.

The file is a wall of links with almost nothing said about any of them. Go through it and
add a `:` note to each line saying what a reader would get by fetching it: the subject,
the shape, and anything that makes it worth choosing over its neighbour. If a link cannot
be given a note worth reading, that is usually a sign the link does not belong in the
index at all.

A file made of `- [Docs](/docs)` and thirty more like it tells a model that this site has
pages, which it already knew. What a model needs from an index is the thing that lets it
choose: what is behind each address, and whether fetching it is worth the tokens. That is
what a note after the link does, and it is the difference between an index and a table of
contents nobody asked for.

There is nothing normative to cite here, and saying so is the honest opening move. The
llms.txt specification makes the note after a link optional and says nothing about how
many links should carry one. This is our judgement about what makes such a file
worth retrieving, and the report says as much.

The file must:

- open with a `>` blockquote summary directly under the H1, before the first `##` heading
  and before the first link line. A summary written lower down is not read as the
  summary, by this scan or by anything skimming the file top-down;
- give each link a `:` followed by a note, on the same line as the link;
- describe what is behind the link rather than restating its name. `Pricing: pricing`
  costs a line and conveys nothing.

Before and after, on the same file:

```markdown
# Acme

## Docs

- [Quickstart](/docs/quickstart.md)
- [Concepts](/docs/concepts.md)
- [Webhooks](/docs/webhooks.md)
```

```markdown
# Acme

> Acme is a hosted billing API for subscription businesses. Everything below is written
> against the v2 API; v1 reaches end of life in March.

## Docs

- [Quickstart](/docs/quickstart.md): create an account and take a first payment in about
  ten minutes, with a runnable curl example
- [Concepts](/docs/concepts.md): customers, subscriptions, invoices and proration, and
  how the four objects relate
- [Webhooks](/docs/webhooks.md): the event list, signature verification, and the retry
  schedule
```

The second file is not longer for the sake of it. A model reading it can answer "where do
I find the retry schedule" without fetching anything, and then fetch exactly one page.

One caution. The summary has to sit above everything else. A blockquote placed after the
first heading, or after the first link, reads as a note about that section rather than
about the project, and is not counted as the file's summary.

Two things about how this is measured, both of which are limits rather than rules. The
thresholds are ours and are judgement, not measurement (a quarter of the links carrying
a note starts earning credit, three in five passes), so treat them as a floor and write a
note wherever a reader would want one. And only the presence of a note is detected, never
its quality: `: docs` counts the same as a sentence that says something. Writing `: docs`
on every link would clear the check and defeat the purpose of doing it, since the file is
for a model and not for us.

One last thing about order. A site with no `/llms.txt` at all fails this check too, and
that is deliberate: marking it inapplicable would drop it out of the denominator and
quietly reward a site for having done nothing. If both this and the llms.txt check are
outstanding, do that one first. There is nothing to describe until the file exists.

The whole report, as markdown, is at https://goodforbots.com/r/catnamesai.com.md?scan=cmusu2i4m002u01ozgvj2mwn5. 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.