← KodeKid

// behind the site

This site is its own proof.

No client asked for this case — but it's built to the same standard as every other one: fast to load, easy to find, and legible to a person and a machine alike.

95Performance
100Accessibility
100Best Practices
100SEO
100Agentic BrowsingLighthouse CLI only — the hosted API doesn’t return this one yet

Lighthouse 13.4.1 · desktop ·

Or see Google’s own full report, with every detail this page doesn’t show:

Full report — mobile Full report — desktop Check the structured data — Rich Results Test

SEO — the fundamentals

Every page carries its own title, description and canonical URL — none of it inherited from the front page. Every case, guide and page is described as structured data (schema.org / JSON-LD): one Organization and one Person, referenced by the same ID from every page that mentions them, instead of repeating the same facts with a slightly different shape each time. The sitemap only moves a page's lastmod when its content actually changed, not on every deploy — telling a crawler everything changed every time is how it learns to ignore the field.

GEO and AEO — legible to a machine, not just a person

The site ships an llms.txt: a plain-text map for language models, pointing straight at every case and guide with one sentence each. robots.txt explicitly allows AI crawlers rather than blocking them by default. This very page carries its own FAQPage markup, below — the same format Google and AI answer engines use to answer a question directly, without anyone needing to click through.

Chrome recently shipped an entirely new Lighthouse category: Agentic Browsing — whether a page is legible to an AI agent browsing on someone's behalf. Among other things, it checks for exactly that llms.txt file, and whether the page's accessibility tree is well-formed. kodekid.app scores 100 on it.

Speed — measured, not guessed

No buzzwords, just numbers. Images and video served from Supabase Storage cache for a full year — Supabase's own default is one hour, which meant a returning visitor re-fetched every case image on every visit. A handful of security headers (CSP, HSTS, COOP) are set without trading away speed to get them. A tighter target browser list is in place and ready to drop unnecessary JavaScript polyfills the moment two known bugs in Next.js's own bundler are fixed upstream (tracked directly in the code); until then it already benefits the CSS, autoprefixed precisely to the browsers this site actually needs to support.

The three numbers Google's ranking actually looks at — Core Web Vitals — measured 18 September 2026, same runs as the scores above:

Metric Desktop Mobile "Good" is
Largest Contentful Paint 1.5 s 5.7 s ≤ 2.5 s
Cumulative Layout Shift 0.02 0.01 ≤ 0.1
Total Blocking Time 10 ms 150 ms ≤ 200 ms

Mobile LCP is the one weak spot in these numbers — over the "good" threshold, not just slower than desktop. That's a real thing to fix, not something this page pretends isn't there.

Accessibility — 100 on desktop, 96 on mobile, and that's deliberate

The four points are one thing: a text/background contrast ratio kept exactly as designed rather than turned up to hit a rounder number. Everything else — labels, focus order, alt text, video descriptions — is there because it should be, not because a tool demanded it.

Want the same?

This is exactly the kind of work I do for clients — nobody just asked to see it. See what it costs.

Frequently asked questions

What's the difference between SEO, GEO and AEO?
SEO (search engine optimisation) is being found by Google. GEO (generative engine optimisation) is being cited by an AI system that generates an answer from several sources. AEO (answer engine optimisation) is being the direct answer itself — a FAQ block or a clean fact a system can quote without visiting the page. This site is built for all three at once, since they overlap far more than they compete.
How fast is the site, exactly?
Lighthouse's Performance score is the noisiest of the five by design — it simulates a fixed CPU and network profile, and repeat measurements against this exact page have ranged from the high 70s to 100 on mobile, and the mid-90s upward on desktop, depending on network conditions that have nothing to do with the page itself. Run your own test any time at pagespeed.web.dev.
Why isn't accessibility a flat 100?
One deliberate choice: a colour contrast ratio kept as designed rather than adjusted to satisfy an automated check. Everything else Lighthouse and a screen reader can check — labels, focus order, alt text, video descriptions — is there in full.
Can I get this for my own site?
Yes — this is the same SEO, performance and accessibility work every KodeKid project gets. See the services page for what it costs.

ENDA