Zero-Budget Web Dev Part 2 — Mobile Breakpoints & Giving AI a Clean Entry Point

A developer building the Kadmium portal on a zero-budget Google Sites setup fixed mobile layout issues caused by fixed-pixel HTML embeds and launched kadmium.dev/ai-summary, a plain-text Markdown index following the emerging llms.txt pattern. The endpoint gives AI crawlers and answer engines a simplified, structured representation of the site and explicitly marks the boundary between public documentation and non-public internal implementation details.

Welcome back to Part 2. In Part 1, I moved the Kadmium portal away from Discord chaos and onto a $0 Google Sites setup. This part is about what happened afterwards: fixing the mobile layout, dealing with the limitations of embedded HTML, and giving AI crawlers a cleaner way to understand the site. Google Sites handles its native components reasonably well across different screen sizes. Custom HTML embeds are another story. Embedded HTML runs inside sandboxed <iframe elements, which means the embed has its own layout context. My original implementation relied too heavily on fixed pixel widths, so the desktop layout looked fine while smaller screens could end up with horizontal overflow. Basically: desktop-first worked until someone opened it on a phone. 🤣 My bad. The fix is fairly straightforward: width: 100% . max-width values where necessary. rem instead of relying entirely on pixels. For embeds that contain their own HTML document, I also use an explicit viewport declaration: <meta name="viewport" content="width=device-width, initial-scale=1.0" The general rule I'm using now is: Google Sites handles the page layout. Custom HTML handles individual widgets. That keeps the two systems from fighting each other. The mobile issue was annoying. The crawler problem was more interesting. If you're trying to make a technical site discoverable through tools such as ChatGPT, Claude, Gemini or Perplexity, the crawler isn't necessarily interested in the page exactly the way a human visitor is. A rendered website can contain: For a human, that's normal. For an AI system trying to extract technical information, it's additional context that may not be useful. Google Sites also doesn't give me the same level of control over infrastructure that I would have on a conventional web stack. For example, I can't simply treat the site root like a server I fully control and configure everything around the crawler. So instead of trying to make the crawler understand the entire rendered site, I decided to give it another option. I created kadmium.dev/ai-summary https://www.kadmium.dev/ai-summary . The idea is simple: Give AI agents a plain-text representation of the important parts of the site. Rather than forcing a crawler to reconstruct the architecture from rendered pages,give it pieces of candy The endpoint provides a structured Markdown index containing the information I actually want machines to discover. The page includes things such as: It also follows the general direction of the emerging llms.txt pattern: provide machines with a deliberately simplified representation of a website instead of relying entirely on rendered HTML. One part I consider particularly useful is separating known public information from things that aren't actually exposed. For example, the index can explicitly state that internal implementation details are not part of the public documentation. That's important because an AI system should not have to guess. If the public documentation says: This module exists and performs X. That doesn't mean the model should invent the internal C++ implementation of X. The /ai-summary document therefore acts more like an information boundary than just a sitemap. It tells an AI system: That doesn't magically prevent hallucinations, but it gives the model a much cleaner source of truth to work from. I'm not trying to replace the actual website with a giant text dump. Humans still get the normal site. The /ai-summary endpoint is simply another representation of the same information, optimized for machines that don't need the visual UI. So the architecture is roughly: ┌─────────────────┐ │ Kadmium.dev │ │ Human UI │ └────────┬────────┘ │ Public information │ ┌──────────────┴──────────────┐ │ │ Human visitors AI / crawlers │ │ Rendered website /ai-summary │ │ Visual context Plain Markdown It's a small addition, but it means I don't have to rebuild the frontend just to make the underlying information easier for machines to consume. I'm a C++ developer. Given the choice, I'd rather spend 14 hours in Visual Studio working on Network Prediction Plugin rollbacks, SIMD vector math or engine architecture than debugging HTML padding. 😂 The portal exists for practical reasons: The actual engineering work is still where my attention goes. If you want the raw architecture, the public C++ material is available here: The main lesson from this was that a website doesn't necessarily need one representation. And when the platform underneath you limits how much control you have over the rendered frontend, providing a separate machine-readable layer can be a surprisingly simple workaround. The /ai-summary endpoint is still a work in progress, but that's the direction I'm taking for Kadmium. If you're doing something similar with AI indexing, llms.txt , or machine-readable documentation, I'd be interested to hear how you're approaching it in the comments below AI Disclosure: The underlying codebase, architecture, and implementation are developed and tested by Kadmium in C++ / C . AI tools were used to help refine parts of the documentation wording.