During my time on the omg.lol IRC channel (a place I find inspiration for many posts, it seems!), Skippy shared an interesting website, The Website Specification. Now, I have to admit the site has a certain questionable aesthetic, but the checklist is valuable nonetheless. I've always tried to make sure my web development follows good practices and good hygiene, but there were plenty of things I've never really heard of or come across before. It's a big list. Foundations, SEO, accessibility, security, well-known URIs, "agent readiness" (bleh), performance, privacy, resilience, internationalisation. There's around 140 items to check off, each with a one-line justification for why it matters and a `Required` / `Recommended` / `Optional` / `Avoid` tag. Being the maximalist I am (in other words, I enjoy implementing functionality to my site as a means of procrastinating writing) I decided to go through, one-by-one, and see what I would need to change or add to my site. ## A Deliberate Skip Before anything else, I skipped the entire "Agent Readiness" category. I'm not going to add a `llms.txt` to my codebase, or per-page markdown endpoints. It's quite a cruel joke that the generative AI gets simple, readable markdown while the rest of us are stuck with far more complex HTML, isn't it? Instead of figuring out a way to get web browsers to display Markdown directly, we've duct-taped a solution for robots. Anyways, that's enough ranting about that for now. In addition, as I've already written about, I have no AI-crawler-specific `robots.txt` rules. The game of cat-and-mouse writing elaborate blockades is something I'm not interested in. The only winning move is not to play. That said, I did actually add some fun honeypots that you can find if you try to visit high-risk application paths, default CMS/root paths, secrets & configuration file locations, or API & discovery endpoints. Maybe I'll make another post for that if there's interest. Agent readiness, as a category, assumes you _want_ agents reading your site efficiently. Unlike search engine optimization (which is usually snake oil itself), optimization for LLMs just makes your content easier to steal, and doesn't help getting more humans to your website. ## A Silly Bug When you go over an audit like this, it makes you re-examine things you've written ages ago. In the case of my `site.webmanifest`, it made me realize it had empty `name` and `short_name` fields: {"name":"","short_name":"","icons":[{"src":"/android-chrome-192x192.png", ... Any Android user who tried to "Add to Home Screen" would've gotten a shortcut with no label. Even worse, the icon paths were root-relative (`/android-chrome-192x192.png`) when the actual files live at `/assets/images/favicon/android-chrome-192x192.png`. The manifest has been silently erroring and pointing at 404s since whenever I first generated it with some online favicon tool and never looked at the output again. I fixed both: { "name": "brennan.day", "short_name": "brennan.day", "start_url": "/", "scope": "/", "icons": [ {"src": "/assets/images/favicon/android-chrome-192x192.png", "sizes": "192x192", "type": "image/png"}, {"src": "/assets/images/favicon/android-chrome-512x512.png", "sizes": "512x512", "type": "image/png"} ], "theme_color": "#fbf1c7", "background_color": "#fbf1c7", "display": "standalone" } In addition, the `` was embarrassingly set to `#65312fff`. I have no idea when I wrote out this typo—8-digit hex values do actually have utility, with the extra two digits adding alpha channel for transparency, but that wasn't what was happening here. Anyways, I split the hex into a light/dark pair instead, matching my site's palette: ## Security Headers, or: What I'd Been Putting Off A lot of work went into security headers. My `netlify.toml` initially had `X-Frame-Options`, which is an outdated `X-XSS-Protection` header that I removed, as it does nothing in any current browser, and the spec says to avoid using it. I had no Content Security Policy, no HSTS, and nothing about cross-origin isolation. Writing a CSP for a site that embeds webring widgets and uses KaTeX, Mermaid, and has an IndieAuth comment flow took a bit of work: Content-Security-Policy = default-src 'self'; script-src 'self' 'unsafe-inline' 'wasm-unsafe-eval' https://cloud.umami.is https://neatstats.net https://cdn.jsdelivr.net https://webring.fun https://silly.possiblyaxolotl.com https://bubbles.town https://status.lol; style-src 'self' 'unsafe-inline' https://cdn.jsdelivr.net https://silly.possiblyaxolotl.com; img-src 'self' data: https:; font-src 'self' data: https://cdn.jsdelivr.net; connect-src 'self' https://cloud.umami.is https://*.supabase.co https://webring.fun https://neatstats.net https://bubbles.town; frame-src https://www.youtube.com; object-src 'none'; base-uri 'self'; form-action 'self' https://indieauth.com https://buttondown.com https://*.supabase.co; frame-ancestors 'none'; upgrade-insecure-requests; report-to default; I'm not going to pretend that's a _strict_ CSP. It still has `'unsafe-inline'` for both scripts and styles, because my site has inline `

#eleventy

Advanced Webweaving: Auditing Against Specification.Website (brennan.day)