{"slug": "zero-budget-web-dev-part-2-mobile-breakpoints-giving-ai-a-clean-entry-point", "title": "Zero-Budget Web Dev Part 2 — Mobile Breakpoints & Giving AI a Clean Entry Point", "summary": "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.", "body_md": "Welcome back to Part 2.\n\nIn Part 1, I moved the Kadmium portal away from Discord chaos and onto a $0 Google Sites setup.\n\nThis 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.\n\nGoogle Sites handles its native components reasonably well across different screen sizes. Custom HTML embeds are another story.\n\nEmbedded 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.\n\nBasically: desktop-first worked until someone opened it on a phone. 🤣\n\nMy bad.\n\nThe fix is fairly straightforward:\n\n`width: 100%`.` max-width` values where necessary.`rem` instead of relying entirely on pixels.\nFor embeds that contain their own HTML document, I also use an explicit viewport declaration:\n\n```\n<meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0\">\n```\n\nThe 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.\n\nThe mobile issue was annoying. The crawler problem was more interesting.\n\nIf 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.\n\nA rendered website can contain:\n\nFor a human, that's normal. For an AI system trying to extract technical information, it's additional context that may not be useful.\n\nGoogle 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.\n\nSo instead of trying to make the crawler understand the entire rendered site, I decided to give it another option.\n\nI created [kadmium.dev/ai-summary](https://www.kadmium.dev/ai-summary).\n\nThe idea is simple: **Give AI agents a plain-text representation of the important parts of the site.**\n\nRather 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.\n\nThe page includes things such as:\n\nIt 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.\n\nOne part I consider particularly useful is separating known public information from things that aren't actually exposed.\n\nFor 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.\n\nIf the public documentation says:\n\n*This module exists and performs X.*\n\nThat doesn't mean the model should invent the internal C++ implementation of X.\n\nThe `/ai-summary` document therefore acts more like an information boundary than just a sitemap. It tells an AI system:\n\nThat doesn't magically prevent hallucinations, but it gives the model a much cleaner source of truth to work from.\n\nI'm not trying to replace the actual website with a giant text dump. Humans still get the normal site.\n\nThe `/ai-summary` endpoint is simply another representation of the same information, optimized for machines that don't need the visual UI.\n\nSo the architecture is roughly:\n\n```\n                    ┌─────────────────┐\n                    │   Kadmium.dev   │\n                    │   Human UI      │\n                    └────────┬────────┘\n                             │\n                    Public information\n                             │\n              ┌──────────────┴──────────────┐\n              │                             │\n        Human visitors                AI / crawlers\n              │                             │\n       Rendered website                 /ai-summary\n              │                             │\n        Visual context                 Plain Markdown\n```\n\nIt'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.\n\nI'm a C++ developer.\n\nGiven 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. 😂\n\nThe portal exists for practical reasons:\n\nThe actual engineering work is still where my attention goes.\n\nIf you want the raw architecture, the public C++ material is available here:\n\nThe main lesson from this was that a website doesn't necessarily need one representation.\n\nAnd 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.\n\nThe `/ai-summary` endpoint is still a work in progress, but that's the direction I'm taking for Kadmium.\n\n*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!*\n\n**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.", "url": "https://wpnews.pro/news/zero-budget-web-dev-part-2-mobile-breakpoints-giving-ai-a-clean-entry-point", "canonical_source": "https://dev.to/kadmium/zero-budget-web-dev-part-2-mobile-breakpoints-giving-ai-a-clean-entry-point-3jcd", "published_at": "2026-09-18 01:51:06+00:00", "updated_at": "2026-09-18 02:22:56.370248+00:00", "lang": "en", "topics": ["ai-crawlers", "agent-protocols", "generative-engine-optimization", "ai-search", "developer-tools"], "entities": ["Kadmium", "Google Sites", "kadmium.dev", "ChatGPT", "Claude", "Gemini", "Perplexity"], "alternates": {"html": "https://wpnews.pro/news/zero-budget-web-dev-part-2-mobile-breakpoints-giving-ai-a-clean-entry-point", "markdown": "https://wpnews.pro/news/zero-budget-web-dev-part-2-mobile-breakpoints-giving-ai-a-clean-entry-point.md", "text": "https://wpnews.pro/news/zero-budget-web-dev-part-2-mobile-breakpoints-giving-ai-a-clean-entry-point.txt", "jsonld": "https://wpnews.pro/news/zero-budget-web-dev-part-2-mobile-breakpoints-giving-ai-a-clean-entry-point.jsonld"}}