When an AI answers “where to train BJJ in Tokyo,” which dojo does it name?

Open Perplexity or ChatGPT this week and ask where to train BJJ in Tokyo. Six or seven academies get named — the same ones, roughly, that have been named since the model trained. If your dojo is not on that list, the first question worth asking is not whether your SEO is right. It is whether an AI that cannot run JavaScript can read your dojo’s website at all.

Try the sixty-second version first

Open an AI assistant you use. Perplexity. ChatGPT. Claude. Ask it where to train BJJ in Tokyo. Read the answer. Notice which dojos get named, which don’t, and whether yours is in either list.

Then open a new tab. Type your dojo’s URL. Right-click, select “View Page Source.” Hit Command-F (or Control-F) and search for a sentence from your home page — a sentence a prospective member would read first. If you find it in the source as plain text, your website is readable by every AI that reads a page. If you don’t find it — if what you see is mostly <script> tags and a thin <div id="root"> and nothing else — your website is being rendered inside the visitor’s browser, after JavaScript loads, and the AI that pulled your URL for the query above never saw what you wrote.

The sixty seconds above tells you more about why a prospective member landed on another dojo’s name in the AI’s answer than any SEO audit will.

What an AI assistant actually reads

An AI assistant answering a question like where to train BJJ in Tokyo is not browsing the web the way you are. It is reading the versions of dojo websites that live in two places: a training-time index of the open web (what the model saw months or years ago) and a retrieval-time fetch of a short list of URLs the retrieval layer selected as likely to help with the specific query. Both passes read the same artifact — the HTML the server sends back when the URL is requested — and both passes do essentially the same thing with it: parse the HTML, extract text, extract structured data from embedded JSON-LD. The retrieval pass also follows the site’s sitemap and honors what the site itself declares in llms.txt at the root.

What those passes do not do: run the page’s JavaScript. Boot a browser. Wait for a React or Vue bundle to finish rendering content into the DOM. If your dojo’s primary content — the sentence about your lineage, the names of your head instructors, the fact that you run in Tokyo — only appears in the DOM after JavaScript executes, that content is not what the AI reads. The AI reads the pre-JavaScript HTML. If the pre-JavaScript HTML is a shell, the AI sees a shell.

This is not a theoretical concern. Pre-rendered HTML, JSON-LD at build time, and llms.txt at the site root are now the three things an AI retrieval pipeline is actively looking for on a public web page — and the three things most bundled gym management system (GMS) builders and iframe-widget-based website setups do not deliver.

What most bundled builders deliver instead

A bundled builder’s typical shape, from the retrieval side:

Content is often rendered client-side. The HTML the server returns is a shell; the actual content arrives via JavaScript after the browser boots. An AI fetching the URL sees the shell. The AI does not know your dojo is in Tokyo if the sentence saying so is only present after a bundle finishes rendering.

Per-page JSON-LD is usually absent. A dojo’s LocalBusiness schema — the structured data that tells an AI this URL belongs to a jiu-jitsu academy at this address, offering these programs — is what makes a dojo’s website machine-readable at the entity level. Most bundled builders emit none of it on a per-page basis. The AI reading a bundled-builder page sees text (if there is text) but not entity-level structure.

Open Graph images are vendor placeholders. When the retrieval layer picks a share-preview image to render alongside the dojo’s name in an answer, it reads the page’s og:image. If that image is the vendor’s global placeholder — a generic widget icon rather than your dojo’s photo — the AI’s answer surfaces the vendor’s branding where your dojo’s branding should appear.

No llms.txt at the root. llms.txt is a short, plain-text index at a site’s root that tells AI retrieval systems, in a format they are explicitly configured to read, what the site covers and where. Dojos running on a GMS-bundled builder have no way to publish one. The dojo cannot tell the AI, in a format the AI is actively looking for, that the site is about a jiu-jitsu academy in Tokyo.

Each of these is a shape decision inside the bundled-builder tier, not a bug the vendor is going to fix on a timeline. They are consistent with the tier’s job — a signup funnel attached to a backend — and they are consequential if the dojo’s growth plan now runs partly through AI-answer surfaces.

The general-fitness GMS tier — the one whose website layer is iframe widgets dropped into whatever host site your dojo runs — has a different AI-retrieval problem.

An AI retrieving your dojo’s URL fetches the host page. The host page’s HTML is whatever your host CMS serves. Inside that HTML there is an <iframe> pointing at the vendor’s subdomain. The AI does not open the iframe. The content inside the iframe — your schedule, your pricing, your signup — is served from the vendor’s URL, which the AI’s retrieval pass for your dojo’s URL did not request.

Which means: if the host page’s HTML outside the iframe says something useful about your dojo, the AI reads that. If the content inside the iframe is where your dojo’s identity, programs, or schedule actually live, the AI reads none of it. The schedule a prospective member asked the AI about is served from a URL the AI never fetched.

The host page’s og:image, title, and meta description still work, within whatever your host CMS gives you. The structured data on the host page still works, if the host CMS emits it. What does not work is the specific content that lives inside the vendor-served iframe.

What a website built for AI readability does

A dojo-specific website partner’s job on this leg is to emit, at build time, what AI retrieval systems are actually configured to read:

Pre-rendered HTML on every URL. Every URL on the site returns HTML with the content already in it — no JavaScript required to see the sentence about your lineage, your location, or your head instructors.
Per-page JSON-LD matching the page’s content. The home page emits LocalBusiness schema; instructor pages emit Person schema; articles emit Article schema. An AI reading any one of these URLs gets a structured, entity-level description of what the page is about.
A sitemap and an llms.txt at the root. Both auto-generate at build time from the content index. The sitemap tells search engines and AI retrievers what the site covers; the llms.txt tells AI retrieval systems the same thing in a format they are explicitly configured to parse.
Open Graph images per page. Your dojo’s images, your dojo’s branding, your dojo’s photos. The share preview the AI surfaces alongside your dojo’s name is your dojo’s — not the vendor’s.
Robots.txt with the AI crawlers explicitly allowed. The three main AI crawlers to allow by name are GPTBot, ClaudeBot, and PerplexityBot; Google-Extended and Bing’s crawler also honor explicit directives if you want them indexing your content. Each needs to be allowed by name, or the site is explicitly off-limits to the AI that would otherwise index it.

None of this is exotic. These are the shape decisions the open web has been publishing for twenty years, extended to a new class of readers that treats pages as data rather than as interfaces.

Where this question doesn’t matter yet

For a dojo whose new members come through word of mouth, physical signage, and local reputation, AI-answer readiness is a question about the next three years, not the current month. If your prospective members are not asking AI assistants where to train — if they are being referred by their training partners, finding you through a flyer at a competition, or walking in because they drove past your storefront — the retrieval pipeline above is not where your growth is being allocated.

The question lands differently for a dojo whose prospective members are new to the city, new to the sport, or new to a bilingual market where English-language search and AI queries are now a primary discovery surface. A dojo in Tokyo whose growth plan includes expatriate members finding it on arrival is a dojo whose answer to the AI-retrieval question has a direct, measurable consequence on who walks through the door over the next three years.

What to carry out

The sixty-second test at the top of this article is the honest first step. Open the AI, run the query, read the answer. If your dojo is not named, do the view-source pass on your own website. If the content a prospective member would read is not in the HTML before JavaScript runs, your website is architecturally not in the room for the conversation your prospective member is already having with the AI.

A dojo that is architecturally in the room is a dojo whose website speaks the two languages the open web now has — the one a human reads, and the one an AI reads.

If this is the question your dojo is working through, write to marc@niolacontentsystems.com — or read how we think about the architecture.

When an AI answers "where to train BJJ in Tokyo," which dojo does it name?