A practical guide. How to turn an existing website into a working TAI service — without a language model and without rewriting the site — by reusing the structured data you already publish for search engines.
Why this exists
Display ads don't survive on TAI: the browser owns the surface, so there is no third-party JavaScript, no cookies, and no impressions to sell. But for informational and ad-supported sites — recipes, how-tos, news, reference, catalogs — that revenue is already in structural decline. AI answer engines summarize the content and keep the click; the site is consumed by the answer layer for free and uncredited.
TAI flips that: it makes a site a paid, attributed, first-class participant in the
answer layer. The only thing that ever made this hard was effort — hand-writing an intent
router for every site. site2tai removes that effort by harvesting the structured data
these sites already publish for Google (schema.org JSON-LD: Recipe, Article, Product,
FAQPage, HowTo) and compiling it into a deterministic TAI profile.
- Deterministic — routing is exact-token scoring, fully reproducible. No model.
- Near-zero cost — a static JSON profile plus a fixed runtime. Pennies to host.
- Honest — every answer is the site's own words. The tool never invents content.
- An on-ramp, not a ceiling — start deterministic today; the same profile can later be loaded by a guarded language-model engine, unchanged, when a site outgrows exact routing.
The shape of it
your sitemap.xml
↓ enumerate every page
harvest schema.org JSON-LD (fallback: title + meta description)
↓ map each @type to TAI answer blocks
a deterministic profile.json + a runtime that answers from it
A generated profile answers on the TAI wire contract:
GET / → metadata (who you are, what you can answer)
POST / → {"type":"query","input":"how do I make chocolate chip cookies"} → answer blocks
The runtime is stdlib-only Python — no dependencies to install, nothing to bundle.
schema.org → TAI mapping
| schema.org @type | becomes | notes |
|---|---|---|
Recipe |
one intent: description + ingredients + numbered steps + link | |
FAQPage / QAPage |
one intent per question | the highest-signal deterministic case |
HowTo |
one intent: description + numbered steps + link | |
Product / Offer |
one intent with a native product block (name, price, currency, image) |
flagged as commerce; carries affiliate attribution |
Article / NewsArticle / BlogPosting |
one intent: summary + link | |
| (none) | title + meta description + link | an honest fallback, never fabricated |
The profile is plain JSON. It records the site's name and description, the intents it can answer, and a fallback with suggestions. It also records that no category was assigned — because picking your category and registering your name are always your decisions, made through the getai.click web flow, never by the tool.
Monetization is built in
Both native TAI monetization primitives are emitted by the tool, so a converted site is monetization-ready from day one.
Commerce / affiliate. Product and Offer pages become native product blocks. Stamp
your affiliate token onto all of them and each block carries an opaque attribution marker;
when the browser opens the product link, it credits the sale to you as the source that
recommended it. No redirect chains, no link-cloaking, no third-party pixel.
Sponsored. Attach clearly labeled sponsored blocks to matching answers. The browser renders a non-suppressible "Sponsored · <sponsor>" disclosure — you cannot hide or restyle it, and that is exactly what makes it trustworthy. Sponsorship lives inside your own answer and does not touch the registry's neutrality; the getai.click registry never ranks or sells placement.
Deploying a profile
Serve the runtime behind your TLS proxy on TAI port 710 — the same pattern as any TAI publisher: your proxy (HAProxy, Apache, or nginx) terminates TLS and forwards to the engine. Then register the name at getai.click through the web flow and choose your category. The tool registers nothing and picks nothing; those are the operator's calls.
Limits (by design)
- A profile is only as good as the site's structured data. Rich JSON-LD yields rich answers; bare pages yield title + description. The tool never fabricates to fill gaps.
- Deterministic keyword routing is precise, not fuzzy — it matches what a page actually says. When a site outgrows that, the guarded language-model upgrade path is there.
The point is to make the first step trivial: a site that already publishes structured data can be a live, credited, monetizable TAI participant in an afternoon, at almost no cost, with no model and no lock-in.