Your website was built for humans. But can AI understand it?

Most product websites are built for human visitors, and that makes sense. Short headlines, clean sections, feature cards, testimonials, a call-to-action button. A good landing page helps a person quickly figure out what a product does and whether it's worth trying.

While working on TokenBay, though, I kept running into a different problem. People aren't only finding products through Google or Product Hunt anymore. They're asking AI tools things like "what should I use to improve my brand visibility" or "compare these two products for my use case." And I started wondering: if a website reads clearly to a human, does that mean it reads clearly to an AI? My guess is no.

Half the SaaS homepages out there lean on lines like "build smarter with AI," "unlock growth," "supercharge your workflow." They read fine to a human skimming a page. But hand that same page to a system trying to summarize or compare products, and those phrases don't give it much to work with. They don't say what category the product is in, who it's for, what it actually solves, or when it's the wrong choice.

This isn't a brand-new idea, and I don't want to pretend it is. Jeremy Howard's llms.txt proposal already does something adjacent: a markdown file at the root of a site that tells an LLM what content is worth reading, similar in spirit to robots.txt or sitemap.xml. But llms.txt is mostly about which pages matter — it's a reading list. What I kept wanting was something one level more specific: not "here's our content," but "here's who this product is for, and who it's explicitly not for." Closer to what schema.org markup does for search engines, just reframed for how an LLM decides whether to recommend something.

So I started experimenting with a small structured profile alongside TokenBay's site. Here's roughly what that looks like:

{
  "product_name": "TokenBay",
  "one_sentence_pitch": "TokenBay helps brands organize their public information so AI tools can understand and recommend them more accurately.",
  "category": "AI visibility platform",
  "target_users": [
    "startup founders",
    "small businesses",
    "marketing teams",
    "consumer brands"
  ],
  "core_features": [
    "AI-readable brand profile",
    "structured product information",
    "competitor and keyword positioning",
    "recommendation-readiness audit"
  ],
  "best_for": [
    "brands that want to appear in AI-generated recommendations",
    "teams with scattered or unclear public information",
    "products that are difficult to explain in one sentence"
  ],
  "not_best_for": [
    "teams expecting instant guaranteed ranking",
    "companies with no public-facing product",
    "brands that have not defined their positioning yet"
  ]
}

The JSON itself is almost boring, and that's kind of the point. It forces you to actually answer basic questions instead of hiding behind marketing language: what is this, who's it for, what does it help with, when is it useful, and when is it not. Strip the values out and you get a general-purpose template: product_name, one_sentence_pitch, category, target_users, core_features, main_use_cases, best_for, not_best_for, competitors_or_alternatives, proof_points.

The fields that matter most probably aren't the feature list — they're category, target_users, best_for, and not_best_for. AI recommendations are mostly about fit. If someone asks for a tool for a specific situation, the system needs to know not just what a product does, but when it should and shouldn't be suggested.

not_best_for is the one I keep coming back to. Most product pages avoid saying who they're not for — everyone wants to sound like a fit for everyone. But "we're not for teams expecting instant guaranteed ranking" tells you more about a product in one line than most homepages do in five paragraphs.

Where would a file like this even live? I haven't settled on this, but the obvious candidate is something like /.well-known/ai-profile.json, following the same pattern robots.txt and llms.txt already use — a fixed, guessable location so a crawler doesn't have to hunt for it.

I also put together a small checker to catch when a profile is missing the basics:

required_fields = [
    "product_name",
    "one_sentence_pitch",
    "category",
    "target_users",
    "core_features",
    "best_for",
    "not_best_for"
]

def check_profile(profile):
    missing = [f for f in required_fields if not profile.get(f)]
    if missing:
        return {"status": "incomplete", "missing_fields": missing}
    return {
        "status": "ready",
        "message": "This profile has enough structure for an AI system to understand the basics."
    }

Running it against the TokenBay profile above returns:

{
  "status": "ready",
  "message": "This profile has enough structure for an AI system to understand the basics."
}s

I want to be upfront about two problems with this, because I think glossing over them would make the idea sound more solved than it is.

First: no major AI provider has confirmed that it actually reads structured files like this at inference time, and llms.txt — the closer-to-established version of this idea — has so far shown little measurable effect on how AI search crawlers behave in independent testing. So treat everything here as a hypothesis I'm testing, not a proven technique. I'd rather say that plainly than dress it up as a growth hack.

Second: a self-reported JSON file has the same trust problem as meta keywords did twenty years ago. Nothing stops a product from writing a best_for list that's really just marketing copy in a different shape, or showing crawlers a rosier profile than what a human visitor actually sees. Any version of this that matters long-term probably needs some way to check the profile against the real product — reviews, usage data, something outside the vendor's own claims. I don't have a clean answer for that part yet.

With those caveats out of the way, here's why I still think the underlying instinct is right: it's not really about gaming AI answers. It's about reducing ambiguity. A product with scattered, vague, or inconsistent public information is going to get summarized inconsistently by any system trying to parse it — human or AI. Structure doesn't guarantee a recommendation, but it does remove one obvious way to get miscategorized or skipped.

That's the thing I keep coming back to while building TokenBay: AI visibility might not be about producing more content. It might just start with organizing the information you already have so it's easier to classify, compare, and trust.

A good-looking website still matters. A JSON profile won't fix everything on its own, and right now nobody can promise you it moves the needle. But it's a decent starting point, and a good gut-check for whether your product is actually easy to describe in the first place. I'm running a small side-by-side test soon — same set of products, with and without a structured profile, checked against how a couple of different AI tools describe and recommend them — and I'll write up whatever I find, good or bad.