# glokki --- Source: https://glokki.com/ [Developer docs are live — SDK, blocks, APIs & MCP](https://glokki.com/docs) # Build, translate, and test web pages — visually. The multi-tenant CMS that puts a visual page builder, multilingual content, A/B tests and AI insights in one place — on top of blocks your developers write in TypeScript. - [Create free account](https://app.glokki.com/register?utm_source=home-hero) - [Read the integration guide](https://glokki.com/docs/integration) ```bash npm i @glokki-cms/sdk @glokki-cms/react ``` ## Built for teams who ship ### Visual builder + i18n Drag-and-drop blocks, real-time preview, and built-in translations across every page. ### A/B testing Run experiments on copy and layout. Measure conversion lift without leaving the editor. ### AI insights Catch SEO, accessibility, and performance issues before publish — automatically. ## One CMS for everyone who touches the site. Marketers edit, agencies manage clients, developers own the code. Nobody waits on anybody. ### Marketers - Visual editing — no code needed - Instant publish + scheduled releases - A/B variants on any page or section - Translate pages into any language [Start editing →](https://app.glokki.com/register?utm_source=home-marketers) ### Agencies - Multi-tenant — manage many clients - White-label branding per tenant - Clients host their own published sites - Scoped permissions per workspace [Set up your agency →](https://app.glokki.com/register?utm_source=home-agencies) ### Developers - Block SDK in TypeScript - Headless delivery API - Zod-validated block schemas - Bring your own Postgres + S3 [Browse the docs →](https://glokki.com/docs) For developers ## Your React components. Your schema. Our editor. Define blocks in TypeScript; Zod schemas drive the props panel, your components render in production. No proprietary templating language — and every step is documented. ```ts import { defineBlock } from "@glokki-cms/sdk" import { z } from "zod" import { Hero } from "./hero" export const heroBlock = defineBlock({ type: "hero", label: "Hero", category: "content", icon: "Sparkles", propsSchema: z.object({ title: z.string(), subtitle: z.string().optional(), }), defaultProps: { title: "" }, component: Hero, }) ``` [Integrate with Next.js](https://glokki.com/docs/integration) [Build your first block](https://glokki.com/docs/block-development) ### Everything is in the docs - [Getting started](https://glokki.com/docs/integration) — Integration guide and troubleshooting for Next.js. - [Blocks & layouts](https://glokki.com/docs/block-development) — Custom blocks, components, header/footer layouts, preview route. - [APIs & SDK](https://glokki.com/docs/api-reference) — SDK reference, asset import and data model write APIs. - [AI & automation](https://glokki.com/docs/mcp-server) — MCP server and Markdown for agents. - [Infrastructure](https://glokki.com/docs/page-analytics) — Analytics, asset CDN proxy, Postgres caching. Agent-ready ## Let your AI agents edit the site too. Connect Claude or any MCP client to create pages, add blocks and publish. Every page — docs included — is also served as Markdown, with llms.txt for discovery. ```bash # any page, as Markdown curl -H "Accept: text/markdown" https://glokki.com/docs # site map for LLMs curl https://glokki.com/llms.txt ``` - [MCP server guide](https://glokki.com/docs/mcp-server) - [Markdown for agents](https://glokki.com/docs/markdown-for-agents) ## Everything you need to ship ### Forms Capture leads with branded forms. ### Collections Define structured content models per tenant. ### Media library Optimize and serve images automatically. ### Workflows Draft → review → publish, with custom states. ### Webhooks Notify external systems on every change. ### Performance dashboard Real-time core web vitals per page. ## Questions Something missing? Get in touch through the contact page — we usually reply within one business day. ### Is Glokki free? Yes — Glokki is free during the beta. Create an account to get your own workspace; paid plans will follow after the beta. ### Can I self-host? The editor runs only on glokki.com — it is not self-hostable. Your published site is always hosted by you, on the infrastructure of your choice. ### How does multi-tenancy work? By default, each tenant gets isolated data via row-level security on Glokki's shared Postgres, plus white-label branding. You can optionally bring your own Postgres database and S3 bucket — Glokki will write your content and assets to the storage you control. ### Can I import from WordPress or Contentful? There is no automated importer in v1. Manual content migration is straightforward via the delivery API; an importer is a candidate follow-up. ### What about GDPR? Glokki only collects data you provide (account email, content). The Glokki editor runs in a single EU region; you choose where your published site is hosted. Data processing agreements are available on request. ### Do you offer support? During the beta, reach us through the contact page — you'll typically hear back within one business day. ### Is the source open? No. Glokki is closed-source and will remain so. The Block SDK and headless delivery API give you everything you need to integrate without access to the editor's source. ## Start building today. Free during beta · No credit card required [Create free account](https://app.glokki.com/register?utm_source=home-cta) [Read the docs](https://glokki.com/docs) --- Source: https://glokki.com/blog # Blog Engineering notes, guides and product news from the team building glokki, including what we learn running our own site on it. ## Build your site with glokki Free during beta · No credit card required [Create free account](https://app.glokki.com/register?utm_source=blog) [Read the docs](https://glokki.com/docs) --- Source: https://glokki.com/blog/adding-a-blog-with-glokki-collections # How we added a blog to our Next.js site with glokki collections glokki team · Oct 26, 2026 One collection, two blocks and an RSS route. How the glokki.com blog is built, what we reused from the docs section, and the two limits we hit. The blog you are reading was added to glokki.com in an evening. It is not a separate app or a Markdown folder in the repo: posts are entries of a glokki collection, rendered by two blocks, edited in the same visual editor as the rest of the site. This post walks through how it fits together. ## A collection is the data model A collection in glokki is a set of pages that share fields and a URL prefix. The docs on this site are one (`/docs`), the blog is another (`/blog`). We created it over MCP with one call: | Field | Type | Used for | |---|---|---| | `content` | textarea | Markdown body | | `summary` | textarea | lead under the title, card text, RSS description | | `category` | select | Engineering, AI & agents, Product, Guides, Comparisons | | `cover` | image | card and header image | | `author` | text | byline | | `featured` | boolean | the large card at the top of `/blog` | | `updated` | date | "Updated" line on revised posts | The post date and topics are not fields: every entry already has `publishedAt` and tags. Because every post is a page, the things the site already does for pages apply to posts with no extra routes: ISR, preview links, the visual editor, `/sitemap.xml`, and a Markdown version of every page for agents (`/blog/.md`). ## Block one: the post `blog-post` renders a single entry. Its props are not typed in by an editor; they are bound to the page and to the collection fields: ```ts const blogPostSchema = z.object({ title: pageField("title"), slug: pageField("slug"), publishedAt: pageField("publishedAt"), summary: collectionField("summary"), content: collectionField("content"), category: collectionField("category"), cover: collectionField("cover"), author: collectionField("author"), showCover: z.boolean().default(true), }) ``` The component draws the byline (author, date, reading time computed from the body), the cover, the Markdown body with the same renderer and outline rail as the docs, and a `BlogPosting` JSON-LD script. The block also declares how it renders to Markdown, so the agent-facing version of a post is the title, byline, summary and body, without the page chrome. ## Block two: the list `blog-list` shows posts newest first, in two variants: - `grid` for `/blog`: a featured card, then a card grid, with category filters. - `compact` for under a post ("More from the blog") or the home page: date and title, three rows. Lists are the part that is easy to get slow. A naive block fetches entries in the browser after hydration, and fetches every field, including every post's full body. We had already solved this for the docs sidebar, so the blog reuses the pattern: 1. Before rendering, the page walks its block tree and collects one query per `blog-list` it finds. 2. The server fetches those entries (`sortBy: "published_at"`, newest first) and trims them to the fields a card shows — never `content`. 3. A context provider hands them to the blocks, so the list is in the HTML. Inside the visual editor the page renders client-side, so the block falls back to fetching through a small same-origin proxy, with the same trimming. ## RSS in one route `/blog/rss.xml` is a plain Next.js route handler: list the latest 30 entries, map them to ``s, return `application/rss+xml`. The only detail worth knowing is routing. The site serves every CMS page from one catch-all route, and a static segment under `app/blog/` only claims `/blog/rss.xml`, so `/blog` and the posts still go through the catch-all. Blog pages advertise the feed with ``, and only pages that exist: our first version also put it on the 404 page under `/blog`. ## Publishing a post refreshes the index Pages are cached with ISR and purged by a signed webhook when something is published. The webhook purges the path that changed — which is the post, not the `/blog` index that lists it. One line fixes that: when the published slug starts with `/blog/`, purge `/blog` too. ## Writing posts Posts can be written in the editor, but ours start as Markdown files in the repo, with front matter for the fields. A script imports them over the MCP server: it matches entries by slug, creates missing ones as drafts, fills in the fields and seeds the three blocks a post uses. Nothing is published until someone publishes it. ## Two limits we hit - **Tags can't be set over MCP yet.** `create_page` takes collection fields but not tags, so the import script prints them and we add them in the editor. - **A post page doesn't know its own tags.** Tags come back on list entries, not on the delivered page, so the post shows its category but not its topics. Both are on our list for the CMS. Neither stopped us from shipping. ## Build your own Everything here uses the public SDK: collections, `defineBlock()` with `pageField()` / `collectionField()` bindings, and the delivery API. The [block development guide](/docs/block-development) covers bindings, and the [integration guide](/docs/integration) covers the catch-all route, ISR and the revalidation webhook. [Create a free account](https://app.glokki.com/register?utm_source=blog&utm_campaign=blog-with-collections) and add a blog to your own site. # More from the blog ## Add a blog to your own site Free during beta · No credit card required [Create free account](https://app.glokki.com/register?utm_source=blog&utm_campaign=blog-with-collections) [Read the block guide](https://glokki.com/docs/block-development) --- Source: https://glokki.com/blog/cookieless-page-analytics # Cookieless page analytics: what you can measure without a consent banner glokki team · Oct 26, 2026 Views, daily unique visitors, referrers and devices, with nothing stored in the browser. How glokki page analytics works, what it deliberately leaves out, and the two files it takes to set up. Most cookie banners exist because of analytics. A script sets an identifier in the browser so it can recognise a visitor tomorrow, and storing that identifier is what needs consent. glokki ships a page counter that doesn't store anything in the browser, which is why glokki.com has no banner. This post covers what it measures, how it gets away without cookies, what it deliberately leaves out, and the setup. ## What you get The **Analytics** dashboard in the CMS shows, for 7, 30 or 90 days: - **Views**: total page views, with a trend chart. - **Unique visitors**: distinct visitors, counted per day. - **Referrers**: where the traffic came from. - **Devices**: desktop, mobile and tablet, worked out on the server from the User-Agent. There's no separate analytics account and no third-party script tag. If the site renders glokki pages, the data appears as soon as the two pieces below are deployed. ## How it works There are two parts: a component in the page and a route on your own domain. ```text browser ── POST /_e { path, referrer } ──► your app (same origin) │ + visitor IP, User-Agent ▼ glokki ingest ──► hash, count, discard IP ``` **The beacon.** `` from `@glokki-cms/react` renders nothing. After the page loads, and on every client-side navigation, it sends one request with exactly two fields: ```ts JSON.stringify({ path: pathname, referrer: document.referrer || undefined }) ``` It uses `navigator.sendBeacon` (or a `keepalive` fetch where that is missing), so the request never blocks rendering and still goes out if the visitor clicks away straight after. **The proxy.** The beacon doesn't talk to a third-party domain. It posts to `/_e` on your own site, a route that `createInsightsRoute()` from `@glokki-cms/sdk` creates. The route holds the API key on the server, adds the visitor's IP address and User-Agent, and forwards the beacon to glokki. It replies `204` immediately and ignores upstream errors, so analytics can't break or slow down a page. **Unique visitors without an identifier.** glokki computes a SHA-256 hash of IP + User-Agent with a salt that changes every day. The raw IP is used for that hash and then discarded, not stored. Since the salt changes daily, today's hash can't be matched to yesterday's. That's what "unique per day" means, and why nothing has to be kept in the browser. ## Why there is no banner The consent requirement for cookies (in the EU, the ePrivacy rules) is about **storing or reading information on the visitor's device**. This setup does neither: there are no cookies, nothing in `localStorage` and no fingerprint script. You can check glokki.com yourself. Its pages send no `Set-Cookie` header, and the analytics request carries only a path and a referrer. We're not your lawyers, though. An IP address is still personal data while it is being processed, so describe the analytics in your privacy policy, and ask someone qualified if your situation is unusual. ## What it doesn't measure These are choices, not missing features: - **Returning visitors.** No identifier survives the day, so "came back on Tuesday" can't be recorded. - **Sessions, funnels and events.** It counts page views. It doesn't track clicks, scroll depth or sign-ups. - **Campaign tags.** The beacon sends the path without the query string, so `?utm_source=…` doesn't reach the stats. The referrer usually tells you enough. For campaign attribution, look where the conversion happens: on glokki.com the sign-up links carry UTM tags, and the sign-up app is the place to count them. - **Every last visitor.** A same-origin route on a neutral path avoids most blocklists aimed at third-party analytics, but any client-side counting can be blocked. Expect a small undercount. Bots are filtered out in the CMS. If you need funnels or product analytics, use a tool built for that, and ask for consent. For "which pages do people read and where do they come from", this is enough. ## It counts cached pages glokki.com pages are static and served from the CDN with ISR. Counting on the server would miss every cache hit. The beacon runs in the browser after the HTML arrives, so a page served from the edge counts the same as a fresh render. ## It doesn't count you Editors open a page dozens of times while working on it. Since `@glokki-cms/react` 0.10, the beacon does nothing when the page is opened by the CMS: inside the visual editor (`?_editor=1`), on the block-template editor route, and in draft previews (`?preview=true`). Earlier versions counted those views, and the referrer pointed at the CMS. If your numbers look higher than your traffic, check the version first. On glokki.com we went one step further. `` lives in the component that renders public CMS pages, not in the root layout, so preview and editor routes never include it. ## Setup: two files The route: ```ts // app/_e/route.ts — use the folder name %5Fe: Next.js treats _e as private import { createInsightsRoute } from "@glokki-cms/sdk" export const { POST } = createInsightsRoute({ baseUrl: process.env.CMS_BASE_URL!, tenantSlug: process.env.CMS_TENANT!, apiKey: process.env.CMS_API_KEY!, // delivery:read, server-side only }) ``` The component, rendered once on public pages: ```tsx import { PageAnalytics } from "@glokki-cms/react" // …inside your page or layout ``` If you mount the route somewhere other than `/_e`, pass the same path as ``. The [Page Analytics guide](/docs/page-analytics) covers IP headers behind Cloudflare or Fastly, older SDK versions and troubleshooting. [Create a free account](https://app.glokki.com/register?utm_source=blog&utm_campaign=cookieless-analytics) and see your traffic without adding a banner. # More from the blog ## See your traffic without a cookie banner Free during beta · No credit card required [Create free account](https://app.glokki.com/register?utm_source=blog&utm_campaign=cookieless-analytics) [Read the guide](https://glokki.com/docs/page-analytics) --- Source: https://glokki.com/blog/edit-your-website-from-claude-code # Edit your website from Claude Code with the glokki MCP server glokki team · Oct 26, 2026 Connect Claude Code to your glokki workspace in two minutes, then let it create a page, fill it with your own blocks, check it and publish it — with you approving each step. glokki ships with an MCP server. Any client that speaks the Model Context Protocol, such as Claude Code or Cursor, can use it to read and edit your site with the same blocks and permissions your editors have. This guide connects Claude Code and walks through one page, from empty to published. ## What you need - A glokki workspace with your site connected (the [integration guide](/docs/integration) covers this). - Your blocks deployed, and the visual editor **opened once after that deploy**. The MCP server works from a snapshot of your block registry that refreshes when the editor loads, so a block it has never seen doesn't exist for the agent yet. - [Claude Code](https://claude.com/claude-code) installed. ## 1. Create an API key In the dashboard, open **Settings → API Keys** and create a key. Pick only the scopes the agent needs: | Scope | Lets the agent | |---|---| | `mcp:connect` | connect at all (required) | | `admin:pages:read` | list and read pages, blocks, collections, layouts | | `admin:pages:write` | create pages, add and edit blocks, SEO, layouts | | `admin:pages:publish` | publish and unpublish | Start without `admin:pages:publish`. The agent can then build drafts, and publishing stays a button you press — you can add the scope later. The key is shown once. Copy it. ## 2. Connect Claude Code ```bash claude mcp add --transport http glokki https://app.glokki.com/api/mcp/mcp \ --header "Authorization: Bearer ek_live_…" ``` Then, in Claude Code, run `/mcp`. It calls `whoami` and shows your workspace. Check `blockRegistry.schemaSyncedAt` while you're there: if it is older than your last deploy, open the visual editor once. ## 3. Ask for a page Describe the page the way you'd brief a colleague: > Create a draft page at /pricing-faq using our existing blocks: a hero with > the heading "Pricing questions", then an FAQ with these five questions, then > the CTA band pointing at sign-up. Don't publish. What the agent does with that, tool by tool: 1. **`list_block_types`** and **`get_block_schema`** — to learn which blocks your site has and what fields each takes. It works with *your* blocks, not generic ones. 2. **`create_page`** — a draft at `/pricing-faq`. It returns an `updatedAt` token. 3. **`add_block`** for each section, passing the token from the previous call each time. The token is an optimistic lock: if someone edits the page in the dashboard meanwhile, the agent's next write is refused instead of overwriting their work. 4. **`update_seo`** — title and description. 5. **`validate_page`** — a dry run of the same checks publishing runs. Any problem comes back as a field path, so the agent can fix it. Open the draft in the visual editor and look at it. Change a word by hand if you like — the agent's next edit will notice, because the token moved. ## 4. Publish If the key has `admin:pages:publish`, say "publish it" and the agent calls **`publish_page`**. Otherwise publish from the dashboard. ## Editing what's already live The same loop works on existing pages, and this is where an agent saves the most time: changes that touch many places. On glokki.com we switched every "Request access" button to self-serve sign-up — header, footer, hero, segment cards, the CTA band and an FAQ answer — in one request. The agent found them with `get_page` and `get_layout`, changed them with `update_block_props` and `set_layout_field`, validated, and published. Two behaviours worth knowing: - **Editing a published page makes it a draft.** The live version stays up, but nothing changes for visitors until the page is published again. - **Lists are replaced, not merged.** To change one FAQ answer, the agent reads the whole list, edits it, and sends it back. ## What it can't do (yet) - Open the visual editor to sync new blocks — a person has to. - Set tags on collection entries, manage redirects, or add JSON-LD; those are done in the dashboard. The full tool list, rate limits and error codes are in the [MCP server guide](/docs/mcp-server). [Create a free account](https://app.glokki.com/register?utm_source=blog&utm_campaign=claude-code-mcp) and connect your first agent. # More from the blog ## Connect your first agent Free during beta · No credit card required [Create free account](https://app.glokki.com/register?utm_source=blog&utm_campaign=claude-code-mcp) [Read the MCP guide](https://glokki.com/docs/mcp-server) --- Source: https://glokki.com/blog/how-visual-editing-works-in-a-headless-cms # Visual editing in a headless CMS: how it works glokki team · Oct 26, 2026 Your real Next.js pages in an iframe, a postMessage handshake that sends the CMS your block schemas, and a proxy that keeps public pages static. How glokki's visual editor works, and what we got wrong on our own site. A headless CMS usually comes with a trade-off. Developers own the frontend, and editors fill in forms and press "preview" to see what they did. Visual editing removes the second half of that: editors click a heading on the real page and change it in place. The hard part is doing it without the CMS owning the frontend. glokki's editor doesn't have its own renderer or a copy of your components. It shows **your** site, running **your** code, and talks to it. Here's how. ## Your page, in an iframe In the CMS settings you set a **Frontend URL**, the address of your app. To edit a page, the CMS loads that page in an iframe with three extra parameters: ```text https://glokki.com/about?_editor=1&_editorToken=&_editorOrigin=https://app.glokki.com ``` Your app sees `_editor=1` and renders an editor shell instead of the published page: ```tsx ``` Both components come from `@glokki-cms/react`. Everything in the iframe is your app: your blocks, your Tailwind classes, your fonts. If a block looks wrong in the editor, it looks wrong on the site too. ## The handshake The iframe and the CMS are on different origins, so they talk through `postMessage`: ```text iframe (your app) CMS │── handshake: block registry ──────────►│ schemas, defaults, metadata │◄───────────── page tree + editor state ─│ │◄───────────── tree:update ──────────────│ on every edit in the props panel │── selection, hover, drag ─────────────►│ ``` 1. **The app introduces itself.** The provider sends its block registry: every block's type, Zod props schema, defaults and metadata. 2. **The CMS builds the forms.** The props panel is generated from those schemas. `z.string()` becomes a text field, `z.enum()` a select, `z.boolean()` a toggle, `z.array(z.object())` a repeatable list. Nobody configures block types in the CMS. 3. **The CMS sends the page.** The iframe gets the current component tree and renders it with ``, which adds the overlays: selection, hover outlines, drag handles and the "insert here" gaps. 4. **Edits stream in.** Each change in the props panel arrives as a `tree:update` and the iframe re-renders. Nothing is saved to your app. The draft lives in the CMS. So a new block needs no CMS-side setup: deploy it, open the editor, and the handshake announces it. The catch is in the word *deploy*. The editor loads your Frontend URL, which is usually production. A block that exists only on a preview branch doesn't exist as far as the editor is concerned. We found that out on our own blog: the new blocks didn't appear in the editor until we merged to `main`. ## Keeping public pages static Editor and preview requests need per-request rendering: they read query parameters and draft content. Public pages shouldn't pay for that. glokki.com serves pages through one catch-all route with ISR, and that route never reads `searchParams`. Reading them would make every page dynamic. The split happens in `proxy.ts` (Next.js 16's middleware), before routing. Requests with `?_editor=1`, or `?preview=true` plus a token, are rewritten to a separate, dynamic route. The browser URL doesn't change: ```ts if (isEditorMode || isPreviewMode) { const url = request.nextUrl.clone() url.pathname = `/_cms${url.pathname}` // force-dynamic route, noindex response = NextResponse.rewrite(url) } ``` The same check decides who may frame the page. You can see both behaviours on glokki.com with `curl -I`: | Request | Framing | Caching | |---|---|---| | `/` | `X-Frame-Options: SAMEORIGIN` | public, served by ISR | | `/?_editor=1` | `frame-ancestors 'self' https://app.glokki.com` | `private, no-store` | A public page can't be embedded by anyone. An editor view can be embedded, but only by the CMS. Setting `tenantSlug` on the provider adds a second check: if a Frontend URL ever points at the wrong tenant's app, the handshake is refused before any draft content is sent. ## Drafts and templates The same route covers two more cases. - **Preview links.** `?preview=true&token=…` fetches the draft through a client with `preview: true` and `cache: "no-store"`, renders the normal page with a "draft" banner, and is marked `noindex`. This is the link you send to someone who should see a page before it's published. - **Block templates.** Templates are saved block trees with no page behind them, so there's no URL to load. A small passive route, `/_editor-preview`, renders whatever tree the CMS sends it. Outside the editor it renders nothing, so it can't be indexed or used as an open renderer. It's the one editor URL the proxy must **not** rewrite, but it still needs the framing header. The docs didn't mention that when we built our site, so it went on our list of gaps. The [Editor Preview Route guide](/docs/editor-preview-route) now shows the condition. ## Three things to get right - **Keep the editor and the published page on the same components.** It sounds obvious, but a separate "editor version" of a block is how visual editors drift from the real site. With one registry used by both routes, they can't drift. - **Don't count editors as visitors.** Editing reloads pages constantly. An analytics script that runs in the iframe inflates your numbers. glokki's own beacon skips editor and preview views since `@glokki-cms/react` 0.10. Check any other scripts you add. - **Prefer flat schemas.** The props panel is generated from Zod, and arrays of objects work well. A nested `z.object()` field is currently stored as plain text and can't be set as an object. Our header's mobile menu couldn't be configured until we flattened it, as told in [our rebuild write-up](/blog/rebuilt-glokki-com-with-an-ai-agent). ## Set it up The [integration guide](/docs/integration#7-enable-visual-editing) walks through the editor shell, the CSP proxy, the Frontend URL setting and preview mode. The [block development guide](/docs/block-development) covers how schemas become editor fields. [Create a free account](https://app.glokki.com/register?utm_source=blog&utm_campaign=visual-editing) and open your own site in the editor. # More from the blog ## Open your own site in the visual editor Free during beta · No credit card required [Create free account](https://app.glokki.com/register?utm_source=blog&utm_campaign=visual-editing) [Read the docs](https://glokki.com/docs/integration) --- Source: https://glokki.com/blog/make-your-site-discoverable-by-ai # How to make your website discoverable by AI: llms.txt, Markdown and JSON-LD glokki team · Oct 26, 2026 AI assistants read your site differently from a browser. Four things that help them — a site map for LLMs, Markdown versions of pages, structured data and honest crawl rules — and how glokki.com does each. More and more people ask an assistant instead of a search engine. The assistant fetches a few pages, reads them and answers — often without the person ever seeing your site. Whether your page ends up in that answer depends on how easy it is to read for a program that has a limited budget of tokens and no patience for cookie banners. There is no single switch for this, and nobody can promise you a place in an AI answer. But a few things make a site much easier for agents to read, and none of them hurt the site for people. Here is what glokki.com does. ## 1. A site map for LLMs: `llms.txt` [`llms.txt`](https://llmstxt.org) is a proposed convention: a Markdown file at the root of the site with its name, a one-line summary and a list of links to the pages that matter, each with a short description. It tells an agent where to look without crawling the whole site. Ours is generated from published pages on every request, so it can't go stale: the docs grouped like the docs sidebar, blog posts newest first, then the other pages. It is about 4 KB. Pages marked `noindex` are left out. There is also `/llms-full.txt`, every page's content in one file (about 420 KB for this site), for agents that would rather read everything at once. ## 2. Markdown versions of every page HTML is a poor format to hand to a model. A typical page is mostly navigation, scripts and class names, and the content is spread across components. So every page on glokki.com is also available as Markdown, two ways: ```bash # append .md to any URL curl https://glokki.com/docs/mcp-server.md # or ask for Markdown on the normal URL curl -H "Accept: text/markdown" https://glokki.com/docs ``` The second form answers with `Content-Type: text/markdown`, `Vary: Accept` so caches keep the HTML and Markdown versions apart, and a `Link` header pointing at the HTML page as canonical. The Markdown is not scraped from the HTML. Each block on the site declares how it renders to Markdown, next to its React component — a FAQ block becomes questions as headings with their answers, a feature grid becomes a heading per card, and links that only jump within the HTML page (`#faq`) are dropped. That keeps the Markdown short and keeps it in step with the page. ## 3. Structured data with JSON-LD JSON-LD is a `