What a website needs in 2026

I've just rebuilt ryck.dev, and most of the code wasn't typed by me. I worked with an AI coding agent: I said what I wanted, it wrote it, and I read, tested and pushed back on every change before it went anywhere.

That changes where the hard part is. Writing the code is now fast and cheap. Knowing what to ask for isn't. An AI will happily build you a good-looking homepage, but it won't add microformats, a print stylesheet or a security.txt unless you know they exist and ask for them.

So this is my list: the things I think a personal website should have in 2026, now that the typing is the easy bit.

The basics nobody sees#

These are invisible when they work, and embarrassing when they don't.

• A web app manifest (here's mine), with proper icons, including "maskable" ones that phones can crop into circles and squircles without cutting off your logo.
• Security headers: HSTS, X-Content-Type-Options, a Referrer-Policy, a Permissions-Policy that turns off what you don't use, and a rule that stops other sites framing yours. securityheaders.com will grade yours. Plus a security.txt (mine), so anyone who finds a problem knows how to tell you.
• A sitemap, robots.txt and canonical URLs, so search engines index the right pages once.
• An offline page. A small service worker that shows a friendly "you're offline" page beats the browser's dinosaur.
• Real error pages. A 404 that suggests posts matching the URL you mistyped, and a 500 that shows the error so people can report it.

Being understood by machines#

More of your visitors than ever aren't people: they're search engines, feed readers, social networks and AI tools. They all read pages better when you tell them what's what.

• Share images. Every page gets its own Open Graph image, generated from its title, so links look right wherever they're pasted.
• Structured data (JSON-LD). A small block of schema.org data saying "this site belongs to this person" and "this page is a blog post, published on this date". Google's Rich Results Test is picky: it flagged my post dates for having no time zone.
• Microformats. Classes like h-card and h-resume that make your contact details and CV readable by any parser, not just Google's. Mine turned out to be subtly wrong: the summary was attached to the contact card instead of the CV. A parser found it in seconds.
• rel="me" links to your profiles elsewhere, so sites like Mastodon can verify that the account and the website belong to the same person.
• An llms.txt (mine): a plain-text summary of the site for AI tools, built from the same data as the pages so it never goes stale.

Owning your words#

Social networks come and go. Your domain is the one place you control.

• An RSS feed, still the best way to follow a website. Browsers are dropping XSLT, the old way of styling feeds, so mine uses a little CSS and JavaScript instead: open it in a browser and you get a readable page with a button to copy the address, while feed readers see plain RSS.
• A vCard, so people can save your contact details in one tap, with a QR code for the paper version of your CV.
• Comments without a comment system. Each post can point to a Bluesky thread, and the replies show up under the post. No database, no spam filter, and the conversation happens where people already are.

The details#

This is the part I care about most, and the part an AI is least likely to do unprompted.

• Accessibility. Following WCAG: proper headings and landmarks, visible focus, enough contrast, real lists that are actually lists. Not as a checklist at the end, but as part of how every component is built.
• Respecting motion preferences. Everything that animates has a still version for people who turn animation off.
• A print stylesheet. Print my CV, or save it as a PDF, and you get a clean page: light colours even if you browse in dark mode, every role expanded, no navigation, no buttons.
• Small touches. My local time on the CV, so people in other time zones know when I'm likely to reply. A terminal-style heading that types itself out. A hidden surprise if you know the right key sequence.

Proof that it all works#

Here's the thing about building fast: it's easy to build something broken, fast. Tests are what make it safe to move quickly, and they're also what make AI-written code trustworthy.

I ended up with four layers:

1. Unit tests (Vitest) for the plain logic, like working out London's time zone on the days the clocks change. The first version got both days wrong; checking by hand caught it, and now a test makes sure it stays fixed.
2. Browser tests (Playwright) against the real production build: every page loads without errors, has the right title and status code, and passes an automated accessibility scan with axe.
3. Storybook, with stories for every component and every state of every page: a post with code, with a video, with a busy comment thread, with Bluesky down. Network requests in those stories are mocked with MSW, so they look the same every time and work offline.
4. Story tests, which run every one of those stories in a real browser, with their interactions and an accessibility check, all with one command.

The tests paid for themselves straight away. They found lists that screen readers would announce wrongly, a filter button using an attribute that's only valid on real buttons, text on my accent colour with too little contrast, and four of my own old posts that skipped a heading level. None of these were visible by looking at the site.

Where AI fits#

AI did most of the typing here, and it was fast. It also got things wrong: dates that were an hour out on the days the clocks change, a theme that didn't apply to pages that load data, a config that worked by accident. Every one of those was caught because something checked: a test, a validator, a screenshot, or me reading the change.

There's a bigger risk behind those mistakes, though. AI is erasing what I'd call the incompetence barrier. Before, if you weren't sure how to do something, you didn't do it, or at least you went slowly and carefully. Now anyone can ask for a service worker, a security policy or a database migration and get something that looks right in seconds, whether or not they understand it. Nothing stops you any more, so everything goes. That makes understanding what you ship more important, not less.

So this is the balance I've settled on. I use AI every day to move faster, but I treat what it gives me as a first draft. It doesn't know what a good website needs unless I ask, and it doesn't know whether its work is right unless something checks.

In the end, you can't say "Claude did it", the same way you can't say "VS Code did it". It's a tool, a very good one, but the work is yours, and so is the responsibility when it breaks.

And there's one thing AI can't give you: caring about your work. It will write the code, but it won't notice that the contrast is a little low, or wonder how the page sounds in a screen reader, unless you care enough to ask. That part is still yours, so be careful with it.

So, if you're building a website in 2026:

• Know what good looks like, because the AI won't ask.
• Ask for the invisible things: headers, structured data, feeds, accessibility.
• Build in the checks: tests, stories, validators.
• Read everything before it ships. You're the one responsible for it.

The typing is cheap now. The judgement isn't.