Radixia

How this site is built

radixia.ai is a small site, but we build it the way we build for clients. It is static, served from the edge, decoupled from its CMS, and made to work well for human readers, for assistive technology and for AI agents. This page explains the reasoning behind those choices. At the bottom you will find independent tools that let you check the results on the live site.

Built as static files

Every page is rendered once, at build time, and served as plain files from a global edge network. There is no application server at runtime, so there is nothing to slow down, crash or attack while you browse. The few features that really need a server, such as the contact form, run as small edge functions next to the static assets.

The result is a fast site with very little that can break. It is also cheap to run, in money and in energy, because serving prebuilt files costs a fraction of keeping servers warm.

Performance

Speed comes mostly from decisions made before the first byte is served. The CSS each page needs is embedded in the page itself, so the first paint does not wait for a stylesheet download. Fonts are variable WOFF2 files reduced to the character set the site actually uses; we host them ourselves and preload the two that appear above the fold. Assets whose filename contains a content hash, such as scripts, blog images and datasets, are cached for a year as immutable, so a returning visitor downloads almost nothing.

The page shell ships without a client-side framework. JavaScript appears only as small islands on the pages that need it, and heavier code loads on demand. The semantic search in Radixia Labs runs its language model directly in your browser, served from this domain, so even the heaviest feature on the site adds no server load and sends no data anywhere.

Content from a headless CMS

The blog is written in a headless CMS. At build time the site downloads every post, fetches and optimizes every image, and bakes the result into the static output. The published site never talks to the CMS: if the CMS goes down, readers never notice.

This separates writing from shipping. Authors publish, and the site rebuilds itself. It also keeps content independent from presentation, so the same posts could feed a different design, a feed or an API without changing the editorial workflow. Internally we keep a strict split between engine (logic), skin (presentation) and copy (text), and each layer can change without touching the others.

The same build turns every article into audio. A language model writes a short podcast style recap of the post, explaining the code instead of reading it aloud, and a synthetic narrator records it. The result is stored in object storage keyed by a hash of the article, so an unchanged post costs nothing to rebuild and a revised one regenerates under the same address. You will find the player at the top of each post.

Security

Most of the security posture is produced by the build pipeline rather than maintained by hand. Every response carries a strict Content-Security-Policy. The hashes that allow our few inline scripts are recomputed from the built pages on every build, which keeps the policy tight without letting it go stale. The other headers you would expect are in place too: Strict-Transport-Security, protection against framing and MIME sniffing, a restrictive Permissions-Policy and a conservative Referrer-Policy.

Cross-origin access is disabled by default and enabled only on the machine-readable discovery files that agents legitimately fetch from other origins. Public artifacts do not disclose software versions. A security.txt file tells researchers where to report problems. Fonts, search indexes and machine-learning models are all served from our own domain. The only runtime exceptions are two small cookieless analytics scripts, and each one is allowed individually by the Content-Security-Policy rather than through a blanket rule.

Accessibility

A skip link is the first focusable element of every page. The mobile menu can be opened and closed entirely from the keyboard, with a visible focus indicator, which is rare for menus built without JavaScript. Form fields have labels that assistive technology can read, and decorative graphics are hidden from screen readers. The site respects the reduced-motion preference and keeps its contrast in both the light and the dark theme.

Ready for AI agents

A growing share of visits comes from AI agents acting on behalf of a person, and we treat those agents as legitimate visitors. The site publishes llms.txt, a curated map of its content written for machines. Every page can also be requested as Markdown through standard content negotiation, which gives an agent the text without the layout. Structured data connects each page to the organization behind it.

For deeper access there is a public, read-only MCP (Model Context Protocol) server that lets any compatible agent search and read our published content programmatically. Pages that host interactive tools expose them to browser-based agents through WebMCP. An agent that arrives here on your behalf finds documented interfaces instead of having to scrape.

The design

The visual identity grows from a single idea: roots. The root system on the home page is hand-drawn SVG, mirrored around its axis and rendered by the browser as vectors. It stays sharp at any size, weighs a few kilobytes and involves no image CDN. The rest of the design system follows the same discipline, with design tokens for color and type and automatic light and dark themes.

Privacy is part of the same design. Analytics are cookieless and collect no personal data, so there is no consent banner because there is nothing to consent to. Fonts are served from our own domain. The only thing a visit produces elsewhere is an anonymous page-view count in a privacy-first analytics service that cannot follow you across sites.

Check for yourself

The claims on this page are easy to test. These independent tools measure the live site; the first three links already point at www.radixia.ai.

  • PageSpeed InsightsGoogle's measurement of loading performance and Core Web Vitals, on mobile and desktop.
  • Security HeadersGrades the HTTP security headers, from HSTS to the Content-Security-Policy.
  • Is It Agent-Ready?Tests the emerging standards for AI agents: llms.txt, Markdown negotiation, MCP and others.
  • Cookie CheckerLooks for cookies and trackers. Enter www.radixia.ai; the expected result is none.
  • Web Accessibility CheckerRuns a WCAG audit of labels, landmarks, ARIA and keyboard access. Enter www.radixia.ai.

Curious about the details? The agent-facing surface starts at /llms.txt, and the MCP server card lives under /.well-known/. Or just ask your favourite AI assistant to look for itself.