What does a website need technically in 2026?

The technical minimum is four layers: a correct HTML foundation (doctype, the right language, viewport and unique title tags), HTTPS with a valid certificate, a fast, mobile-friendly page that passes Google's Core Web Vitals, and correct indexing through robots.txt and a sitemap. On top of that come two layers of legal requirements – accessibility under WCAG and privacy under GDPR – plus structured data that makes the page readable for both Google and AI agents.

What is llms.txt and does my website need one?

llms.txt is a simple text file at /llms.txt that gives AI models a curated map of your most important content – roughly like a sitemap, but aimed at language models instead of search engines. It is a young, emerging standard and therefore not a requirement. But it is cheap to add and an early signal that your website is built for a web where AI agents read the content. We cover how you actually show up in AI answers in AI SEO 2026.

Does my website have to meet WCAG?

For many companies, yes. Since 28 June 2025, the European Accessibility Act – an EU directive – has required digital services to be usable by people with disabilities as well, with WCAG as the yardstick. In practice it comes down to sufficient colour contrast, alt text on images, full keyboard navigation and semantic HTML. We cover what the law requires in detail in The European Accessibility Act.

What does agent readiness mean for a website?

Agent readiness means your website is easy for AI agents such as ChatGPT, Perplexity and Google's AI answers to read – not just people. Agents often fetch the page without running JavaScript and extract the main content, so what wins is clean semantic HTML, structured data, stable URLs and a clear policy for AI crawlers. Emerging elements such as llms.txt and MCP servers take it a step further. It is the technical foundation beneath AEO – read more in MCP for websites.

Website audit checklist 2026: from SEO to AI

In 2026, a modern business website has to do four things at once: show up in Google, load quickly on mobile, meet legal requirements for accessibility and privacy – and be readable by AI agents such as ChatGPT, Perplexity and Google's AI answers. This website audit checklist brings it all together in one place, clearly marking what is required and what is nice to have.

The starting point is the open web specification that Yoast founder Joost de Valk published at specification.website – an attempt to collect "what a good website actually has to do" in one place, with a primary source for every point. We have taken his platform-agnostic list and added three layers it deliberately leaves out: what actually makes the biggest difference for a company in Sweden, which points your platform already handles for you, and where the EU legal requirements (the European Accessibility Act and GDPR) come in.

What is specification.website and why do we listen to it?

For fifteen years, the advice on "what a website should do" has been spread across half a dozen sources: WHATWG for HTML, WCAG for accessibility, IETF for HTTP headers, schema.org for structured data, plus web.dev and Google Search Central for the rest. There has been no single, opinionated, platform-independent specification. That is the gap Joost de Valk is trying to fill.

The spec covers ten areas – foundation, SEO, accessibility, security, well-known URIs, agent readiness, performance, privacy, resilience and internationalisation – and every point has a status and a primary source. It is built in the open under the MIT licence, so anyone can audit their website against it or contribute corrections.

Our view: it is an excellent starting point, but a list is not a strategy. What decides whether a website performs is the combination – a technical foundation, a business understanding of what the buyer actually needs, and content that both people and machines can cite. Technical work alone produces no citable answers; copy alone structures nothing for machines. So this guide is the spec's list filtered through that lens, for the Swedish market.

Required, recommended, optional, avoid – how the statuses work

Every point in the checklist has one of four statuses. The most important takeaway is that not everything is equally important – there is a difference between a broken foundation and a missing bonus feature.

Required (must) – basic things that must work for the page to behave correctly in browsers, search engines and assistive technology. If they are missing, that is a bug, not a missed optimisation.
Recommended (should) – well-established practice that almost every serious website should have. Most classic SEO belongs here.
Optional (may) – adds value in some cases but is not necessary for everyone. Prioritise according to your situation.
Avoid – patterns that do active harm and should be removed. Soft 404s, accessibility overlays and automatic geo-redirects are the three most common traps – more on them below.

Use the interactive checklist below to check your own website. It saves your ticks locally in your browser, so you can come back and pick up where you left off.

Website audit checklist 2026 – tick it off now

Here is the whole checklist in brief. Each point is covered in the sections below, but this is the tool: go through it, tick what you already have and note the gaps.

The foundation – HTML, metadata and indexing

This is the foundation. Get it wrong and no other optimisation matters, because search engines and AI agents will not even interpret the page correctly.

Doctype, language and character encoding (must) – every page needs <!DOCTYPE html>, a correct lang attribute on <html> (e.g. sv for Swedish) and <meta charset="utf-8">. The wrong language here makes screen readers pronounce Swedish text as English and can make Google misread the audience.
Viewport for mobile (must) – without <meta name="viewport"> the page becomes unreadable on mobile. It is the basis of all responsive design.
Title and meta description (must/should) – a unique, descriptive title tag per page and a meta description that invites the click. They do not rank on their own, but they control what people actually see in the search results.
Canonical tag (should) – state which URL is the original so that the same content at several addresses does not compete with itself. Crucial on websites with filters, campaign parameters or several languages.
Robots.txt and meta robots (must) – control what may be crawled and indexed. A misplaced noindex can wipe out all your visibility overnight – it is one of the most common reasons a website suddenly stops showing up.
XML sitemap (should) – a sitemap helps search engines find all the important pages, especially on larger websites with a deep information architecture.
Open Graph and favicons (should) – control how your link looks when someone shares it on social media, and how the page appears in the browser tab. Small details that affect trust.

If your website already has problems with indexing or visibility, this is where you start troubleshooting. We have a separate walkthrough of the most common causes in Website not showing on Google? The 10 most common causes – this checklist is the preventive counterpart.

Technical SEO and structured data

Once the foundation is in place, technical SEO is about making the content easy to understand and to rank. This is where most Swedish companies have the most to gain, because competition on well-structured pages is still low.

Heading hierarchy (should) – one <h1> per page, followed by logical <h2> and <h3>. It helps both search engines and AI understand the page's structure and extract answers.
Clean URL structure (should) – short, readable addresses without unnecessary parameters. A good URL structure signals hierarchy and is easier to link to.
Well-planned internal linking (should) – link between related pages with descriptive anchor text. It spreads authority and shows which pages belong together.
Correct redirects (must) – use 301 for permanent moves. And avoid soft 404s – pages that say "not found" in the text but return status code 200. They confuse search engines and waste crawl budget. The spec explicitly marks them as something to avoid.
Structured data / schema markup (should) – JSON-LD describing what the page is about (organisation, product, article, FAQ). It matters even more in the AI era, because it lets agents extract facts without guessing. It is an easy win in the Swedish market – few competitors do it properly.

Performance and Core Web Vitals

A fast website is not a luxury – it is a ranking criterion and a conversion factor. Google measures the real loading experience with Core Web Vitals, and the thresholds are concrete.

According to web.dev, the benchmarks are: LCP (loading time of the largest content element) under 2.5 seconds, INP (response time to interaction) under 200 milliseconds, and CLS (unexpected layout shifts) under 0.1. If you pass all three on mobile, the performance foundation is sound.

Image optimisation (should) – modern formats (WebP/AVIF), the right dimensions and loading="lazy" on images below the fold. Images are the most common cause of slow pages.
Caching and compression (should) – set sensible cache headers and compress responses. It makes return visits almost instant.
Well-planned font loading (should) – load fonts so that text appears immediately instead of flashing or jumping. A classic source of poor CLS.
Mobile-friendliness (must) – most visits happen on mobile, and Google indexes the mobile version first. A website that only works on desktop is in practice half a website.

Security – HTTPS, headers and security.txt

Security is partly about trust and rankings, partly basic hygiene. Much of it is invisible to visitors but obvious to browsers, search engines and security researchers.

HTTPS with a valid certificate (must) – all traffic should be encrypted. Browsers now flag insecure pages, and HTTPS is a confirmed ranking signal.
HSTS (should) – a header that forces the browser to always use HTTPS, even if someone types the http address.
Content Security Policy (should) – limits which scripts may run and protects against a large class of attacks. Takes some tuning but is worth it.
security.txt (may) – a small file at /.well-known/security.txt that tells security researchers how to report vulnerabilities. Standardised in RFC 9116, almost free to add and a sign of maturity. Few Swedish websites have one – an easy way to stand out.
Permissions-Policy and cookie attributes (should) – limit which browser APIs the page may use and set Secure/HttpOnly/SameSite on cookies.

Accessibility and legal requirements (WCAG)

As of 28 June 2025, accessibility is no longer optional for many companies. The European Accessibility Act – an EU directive – requires digital services to be usable by people with disabilities as well, with WCAG as the yardstick.

Sufficient colour contrast (must) – text must have enough contrast against the background to be readable. One of the most common shortcomings, and one of the simplest to fix.
Alt text on images (must) – descriptive alternative text so that screen readers can convey what the image shows.
Keyboard navigation and visible focus (must) – everything should be usable without a mouse, and it should always be clear where the focus is.
Semantic HTML and form labels (must) – use real buttons, links and <label> instead of clickable divs. Assistive technology depends on it.
Avoid accessibility overlays (avoid) – the widgets that promise to "make the website accessible" with one line of code. The spec explicitly marks them as something to avoid, and we agree: they rarely solve the real problems and can make the experience worse for people who use real assistive technology. Build accessibility into the website instead.

This section is a summary – we cover the legal requirements and what they mean in practice in depth in The European Accessibility Act – how the law affects your website.

Privacy is the second layer of legal requirements. GDPR has been in force for years, but compliance on Swedish websites is still uneven – especially around cookie consent and third-party scripts.

Privacy policy (must) – a clear, easily accessible policy describing what data you collect and why.
Correct cookie consent (must) – consent must be obtained before non-essential cookies and tracking are activated, not after. Many Swedish websites have a banner that technically comes too late. This is an area where carelessness actually costs money in the form of fines.
Control of third-party scripts (should) – every external tag (analytics, ads, chat widgets) is a potential data leak and slows the page down. Take stock of what is actually needed.
Data minimisation (should) – collect only what you actually use. Less data is less risk.

Agent readiness – is your website ready for AI agents?

This is the section that separates the 2026 checklist from the 2023 one. AI agents read the same HTML as browsers, but they read it differently: they often fetch the page without running JavaScript, extract the main content and ignore the rest. The pages that win in AI answers are the ones that are easy to fetch, easy to interpret and easy to trust.

This is our home ground as an MCP agency for websites. Several of the points are still emerging standards, but the direction is clear – and being early costs little.

Clean, semantic HTML and structured data (should) – the same JSON-LD that helps Google helps agents extract facts without guessing. This is the single most important agent readiness measure, and it overlaps with ordinary SEO.
Stable URLs (should) – when an agent caches an answer, the link still has to work later. Do not change addresses unnecessarily.
Explicit robots policy for AI crawlers (should) – actively decide which AI bots may read your website, rather than leaving it undefined.
llms.txt (may, emerging) – a simple /llms.txt file that gives AI models a curated map of your most important content, roughly like a sitemap but for language models. A young standard, but cheap to add.
Markdown versions of the pages (may) – being able to serve a clean markdown mirror of a page makes it as easy as possible for agents to interpret.
MCP server and WebMCP (may, emerging) – for websites that want to expose tools or actions (book, search, fetch data) directly to AI agents. This is the frontier the web is heading towards, and something we build together with our sister brand AI Partner.

Note that agent readiness does not replace an AEO strategy – it is the technical foundation for one. We cover how you actually show up and get cited in ChatGPT, Perplexity and Google's AI answers in AI SEO 2026.

Internationalisation – if your website is in several languages

This section is only relevant if you have content in more than one language – but then it is all the more important, because misconfigured internationalisation can make the wrong language version rank in the wrong country.

hreflang (should) – tell Google which language version belongs to which audience, so that Swedish speakers get the Swedish page and English speakers the English one.
Localised metadata (should) – translate the title and meta description, not just the body text.
Avoid automatic geo-redirects (avoid) – do not force a visitor to a particular language version based on IP address. It traps both users and search engines in the wrong version. Offer a clear language choice instead.

Which platform handles what for you?

Here is the point the spec deliberately skips: how much of the checklist you actually have to do yourself depends entirely on your platform. Some platforms handle the foundation for you; others give you full control but leave the work to you. The table below shows how much built-in support you get from the platforms we work with most – the more stars, the more is handled for you.

How much of the website checklist your platform handles for you – degree of built-in support (1–5)
Area	Visual editingWebflow	Max controlNext.js / Astro + headless	E-commerceShopify	Plugin-dependentWordPress
Technical foundationHTML, metadata, canonical
PerformanceCore Web Vitals
Structured dataschema / JSON-LD
Security headersHTTPS, HSTS, CSP, security.txt
AccessibilityWCAG support in output
Cookie consent & GDPR
Agent readinessllms.txt, markdown, MCP
Internationalisationhreflang, localisation

In short: Webflow provides a strong foundation with clean code, fast hosting and built-in localisation – ideal for a marketing website where you want to control the content without developers. A coded website with a headless CMS (Next.js or Astro) gives maximum control over performance, security headers and agent readiness, but needs development capacity. Shopify is the obvious choice for e-commerce and has good product schema built in. WordPress can do everything through plugins, but every plugin is a piece of technical debt and a potential security and performance risk. If you want to compare the platforms as part of a buying decision, we go into more depth in What does a professional website cost in 2026?.

What we would prioritise first

A complete checklist can feel overwhelming. But not everything is equally urgent. If we were setting the priorities for a typical Swedish growth company, this is the order we would choose.

First: the foundation and the legal requirements. Indexing, mobile-friendliness, HTTPS, accessibility and cookie consent. Gaps here mean either technical bugs or legal risk – these simply have to be in place.
Then: technical SEO and performance. Structured data, a clean heading hierarchy and Core Web Vitals. This is where visibility is built, and competition is still low for well-structured websites.
In parallel: agent readiness. The structured data does double duty, and the emerging points (llms.txt, MCP) are cheap to add early.

And this is where our basic stance comes in: a checklist tells you what should be there, but not what is worth most to your business. That is decided by the combination – strategy, copy that people and AI want to cite, business understanding and a technical foundation underneath. Want us to run the checklist against your website and point out the three things that will make the biggest difference? Get in touch.

Website audit checklist 2026 – what a modern business website must handle technically, from Core Web Vitals to llms.txt

What is specification.website and why do we listen to it?

Required, recommended, optional, avoid – how the statuses work

Website audit checklist 2026 – tick it off now