How to build a professional website in 2026 — Complete guide

Building a website in 2026 is not the same as in 2020. Google has changed the rules. Users are impatient. And your competitors already have websites that load in under a second.

This article is not about theory. It's about how we actually built kodemagisk.no — from the first technology choice to the day we submitted the sitemap to Google Search Console. Every decision, every tool, and every mistake we avoided along the way.

If you're planning a new website for your business — or considering upgrading the one you have — this is the guide that shows you what actually matters in 2026.

1. Before you write a single line of code: strategy and planning

The most common mistake we see is businesses that start with design. "We want a nice website" is not a strategy. Before you open a single design tool, you need answers to three questions:

Who is the website for? Not "everyone". Who is the one person who will find you on Google, understand what you offer, and get in touch? For kodemagisk.no the answer was clear: entrepreneurs and small businesses in Norway who need their first professional website.

What should the website achieve? Should it generate leads? Sell products? Inform? Our website has one goal: get visitors to book a free conversation. Everything on the site points toward that action.

Which markets do you serve? We operate in Norway, but have clients who speak Norwegian, English, Spanish and Romanian. That meant we needed multilingual support from day one — not as an afterthought.

Only once you have these answers does the technical planning begin.

2. Technology choices: Why we chose Astro + Sanity CMS

The technology choice is the decision that affects everything that follows. Choose the wrong framework, and you'll pay for it for years — with slow performance, difficult maintenance and expensive rebuilds.

Why Astro for frontend

Astro is built for content websites. Unlike React-based frameworks like Next.js, Astro sends zero JavaScript to the browser unless you explicitly ask for it. The result is websites that load faster than almost anything else on the market.

For a business website like kodemagisk.no — where most of the content is text, images and navigation — there's no reason to send hundreds of kilobytes of JavaScript to the user's phone. Astro understands this, and that's why we consistently score 100/100 in PageSpeed Insights, on both desktop and mobile.

Why Sanity CMS for content

Sanity is a Norwegian content management system developed in Oslo. It's headless, meaning your content is stored separately from the website — and can be used anywhere.

For us, Sanity was the natural choice for three reasons: it's flexible enough to handle content in four languages, it lets us build custom editing experiences for each section of the website, and it gives the client the ability to update content themselves without calling the developer.

Every service area, every blog post, and every client review on kodemagisk.no is edited in Sanity Studio — with dedicated fields for SEO title, meta description, and content in all four languages.

Database and hosting

We use MySQL as our database, hosted via domene.no — a Norwegian provider with servers in Norway. For a business website serving the Norwegian market, this gives lower latency than international cloud providers, and the data remains in Europe in compliance with GDPR.

3. Security: Before everything else

Security is not something you add after launch. It's something you configure before writing a single component.

Git strategy with three layers

We set up a GitHub repository with a branching strategy that protects against production errors:

main is production. It's protected — nobody can push directly to it. Code arrives here only through approved pull requests from develop.

develop is the development environment. This is where all finished features and fixes are gathered. When develop is stable and tested, a pull request is created to main.

Feature and fix branches are where the actual coding happens. Each new feature or bug fix gets its own branch. When it's ready, a pull request is created to develop. If all tests pass, it's merged.

This flow means the production website never contains unfinished code. When something is merged to main, it's deployed automatically — both frontend and backend.

.gitignore and sensitive information

Before the first commit, we configured .gitignore to ensure sensitive information never ends up in the repository. Environment variables, API keys, database configurations and local config files — all excluded from version control. It seems obvious, but we regularly see businesses leaking API keys and passwords through public Git repositories.

Server security

In public_html we configured .htaccess and php.ini to secure the server:

Blocking direct file access to configuration files, disabling directory listing, enabling HTTPS redirection, secure HTTP headers (X-Content-Type-Options, X-Frame-Options, Content-Security-Policy), and limiting file sizes for uploads.

These measures cost nothing to implement but protect against the most common attack vectors.

4. CI/CD: Automatic deployment you can trust

Manual deployment is a risk. Forget one step, and you end up with a production site that's different from what you tested locally.

We configured automatic deployment for both frontend and backend. When code is merged to main, the website is built and deployed automatically. No manual steps, no "did I forget to upload that file?" moments.

The same applies to Sanity Studio. Changes to the content structure are deployed automatically, so the editing interface is always in sync with the website.

For a solo developer like me, CI/CD is not a luxury — it's a necessity. When you work alone, you don't have a colleague to double-check that you remembered everything. Automation does that job for you.

5. Project structure and component architecture

Before you start coding, you need a clear folder structure. A tidy project is easier to maintain, easier to debug, and easier to build on.

Folder structure

We organise the code in a monorepo with two main apps: web (the Astro frontend) and studio (Sanity Studio). Shared resources — like types, queries and configurations — sit in common folders.

Components are organised by responsibility, not by page. There's a folder for fundamental elements (buttons, text, wrapper), one for global components (navigation, footer, head), one for section-specific components (hero, process, services), and one for pages.

Component hierarchy

Every page in Astro follows the same pattern: a BaseLayout that handles head elements (meta, SEO, JSON-LD, Open Graph), followed by global components (navigation and footer), and between them — the sections unique to that page.

This structure means that navigation changes are automatically reflected on all pages, SEO metadata is handled in one place, and new pages can be built quickly by assembling existing sections.

6. Design system: colours, typography and visual language

This is where many projects go wrong. They jump straight into design without building a system first — and end up with a website where every page looks slightly different.

Colour preparation

Before designing a single page, we defined the entire colour palette:

Primary colour — the blue accent used in buttons and links. Secondary colour — for hover states and advanced interactions. Neutral colours — a complete grey scale from white to near-black, with defined roles: background, surfaces, text, and borders. Semantic colours — active, inactive, error, success — for UI states like contact forms and notifications.

All colours were defined as CSS custom properties, so they can be reused consistently throughout the entire website.

Typography with a system

We chose two fonts: Clash Display for headings and Figtree for body text. Both are self-hosted as WOFF2 files — totalling 89 KB. No external dependencies, no requests to Google Fonts.

But choosing fonts is just the beginning. The real work is building a typographic system:

Modular scale (1.25) — Each heading level is exactly 1.25 times larger than the level below. This creates a clear visual hierarchy where the reader instantly understands what's most important. We use eight sizes: from 11px for labels to 64px for the hero heading.

Defined weights — We use only three weights of Figtree (400, 500, 600) and two of Clash Display (400, 500). Each weight has a defined role. 400 for body text, 500 for navigation and labels, 600 for buttons and emphasis.

Line height per level — Large headings have tight leading (1.1), while body text has generous spacing (1.65) for reading comfort. This difference is subtle but noticeable — especially on dark backgrounds where the eyes need more space between lines.

Letter spacing — Large headings are tightened slightly (-0.02em), while uppercase labels are opened up (+0.04em). These are details most people don't consciously notice, but they contribute to the text feeling "right".

Logo, favicons and branding

The logo was prepared in multiple formats: SVG for the website (infinitely scalable, small file size), PNG for social media sharing, and a simplified icon for favicons. Favicons were generated in all necessary sizes — from 16x16 for browser tabs to 512x512 for Progressive Web App icons.

Buttons and interactive elements

We defined a button style with clear rules: the primary button (filled, blue) is used for the main action on a page — never more than one per section. The secondary button (outline) is used for alternative actions. Both have defined sizes for desktop and mobile, with sufficient tap targets (minimum 44x44px) for accessibility.

7. Multilingual support (i18n): Four languages from day one

Kodemagisk.no serves clients who speak Norwegian, English, Spanish and Romanian. Multilingual support was built into the architecture from the start — not added afterwards.

Route structure

Norwegian is the default language. English pages sit under /en/, Spanish under /es/, and Romanian under /ro/. Each route has a localised version:

Norwegian: /tjenester/cms-utvikling-med-sanity English: /en/services/cms-development-with-sanity Spanish: /es/servicios/desarrollo-cms-con-sanity Romanian: /ro/servicii/dezvoltare-cms-cu-sanity

Translation system

All texts that don't come from Sanity (navigation, buttons, section headings, FAQ answers) are stored in a central i18n file with keys per language. Sanity handles content like blog posts and service descriptions — with dedicated fields for each language.

hreflang and x-default

Hreflang tags tell Google that the four language versions belong together. We set nb-NO as x-default — so users who don't match any of the other languages are sent to the Norwegian version.

For booking functionality we chose Cal.com — a European solution compatible with GDPR. Many Norwegian agencies use Calendly, which stores data in the US. For a business serving the European market, this is an unnecessary risk. Cal.com lets us integrate booking directly into the website, with data that stays in Europe.

Contact form

The contact form is connected to our business email at domene.no. When someone fills out the form, we receive an email immediately — without third-party tools like Formspree or Netlify Forms. Fewer dependencies means fewer things that can break.

8. SEO in 2026: It's about speed and authentic content

SEO has fundamentally changed. In 2026, it's no longer about stuffing keywords into text. Google is smarter than that. What actually counts is three things: speed, structure, and authentic content.

Core Web Vitals: The three numbers that matter most

Google measures your user experience with three metrics:

LCP (Largest Contentful Paint) — how quickly the main content becomes visible. The target is under 2.5 seconds. Kodemagisk.no loads in under one second.

INP (Interaction to Next Paint) — how quickly the page responds to clicks and keystrokes. The target is under 200 milliseconds. With Astro we send minimal JavaScript, so interactions are nearly instantaneous.

CLS (Cumulative Layout Shift) — how much the content "jumps" while the page loads. The target is under 0.1. By defining fixed dimensions for images and fonts, we avoid layout shifts entirely.

Kodemagisk.no scores 100/100 in Google PageSpeed Insights — on both desktop and mobile. That's not luck. It's the result of deliberate technology choices: Astro that sends minimal JavaScript, self-hosted fonts that eliminate external requests, images in WebP format, and a server in Norway that minimises latency for Norwegian users.

Images: Format matters

All images on kodemagisk.no are in WebP format. WebP delivers 25-35% smaller file sizes than JPEG at comparable quality. For an image-heavy website, this alone can reduce loading time by several seconds.

We also use lazy loading — images outside the viewport don't load until the user scrolls to them. And we define width and height in the HTML, so the browser knows exactly how much space the image needs before it's loaded. This eliminates layout shifts.

Structured data (JSON-LD)

Google doesn't only understand the text on your website — it also reads structured data in JSON-LD format. On kodemagisk.no we've implemented:

Organization — tells Google who we are, where we're based, and what services we offer. WebSite — links the website to the organisation. Service — describes each service with name, description and provider. BlogPosting — gives Google metadata about each blog post: title, date, author, categories. BreadcrumbList — shows Google the site structure. AggregateRating — displays customer reviews directly in search results.

This structured data is why Google can show rich search results with stars, breadcrumbs and supplementary information — things that significantly increase click-through rates.

Heading hierarchy: H1 → H2 → H3

Every single page on kodemagisk.no has exactly one H1 heading. Sections on the homepage have H2 headings. Subsections have H3. This hierarchy is never broken.

Google uses heading hierarchy to understand what the page is about. And for business websites, Google uses the H2 headings on the homepage to generate Sitelinks — the sub-links that appear under the main result in search. An error here (like using H3 where H2 should be) can mean losing Sitelinks.

Meta title and description: One per page

Every page has a unique SEO title and meta description — never copied from another page. For service pages we use the format "[Service name] — [Value proposition] | Kodemagisk", such as: "Websites for businesses — Fast, professional web design | Kodemagisk".

robots.txt and sitemap

robots.txt tells Google which pages should and shouldn't be indexed. We block template pages like /team/, /signin/ and /signup/ (leftovers from the template we started with), while all real pages are open.

The sitemap is generated automatically and includes all pages in all four languages. It's submitted to Google Search Console after launch.

9. Accessibility: Not just a requirement — an advantage

WCAG accessibility is not optional in 2026. The EU's European Accessibility Act (EAA) is taking effect, and Norwegian businesses are expected to follow the WCAG 2.1 AA standard.

On kodemagisk.no this means in practice: sufficient contrast between text and background (minimum 4.5:1 for body text), skip link for keyboard navigation, semantic HTML (correct heading levels, navigation landmarks, ARIA attributes where necessary), all images have alt text, and all interactive elements are accessible by keyboard.

Accessibility is not just ethics and legal requirements — it's also SEO. Google rewards websites that follow accessibility standards, because the same principles (clear structure, semantic HTML, readable text) are what Google itself needs to understand your content.

10. Content strategy: Copywriting that sells without shouting

The technical infrastructure is the foundation. But what the user actually reads is the text. And here most agencies and businesses make the same mistake: they write for themselves, not for the customer.

Write like you speak

Our first version of the text on kodemagisk.no was full of words like "digital logic", "scale your business" and "strategic technology partner". It sounds impressive — but nobody googles "strategic technology partner Oslo".

People google "website for business", "how much does a website cost", and "web agency Oslo". Your text needs to use the words people actually use.

We rewrote everything. The hero heading became "Your business deserves a website that works as hard as you do." Services were organised by what the customer needs (website, online store, CMS, web app), not by technology (frontend, backend, CMS).

SEO titles and meta descriptions

Every single page has a hand-written SEO title and meta description. Not automatically generated from the content — but written with thought about what someone would click on in a Google search.

FAQ with internal links

Our FAQ section does double duty. It answers the questions people actually ask ("How much does a website cost?", "How long does it take?"), and it naturally links to relevant pages on the website. Every link in a FAQ answer is a signal to Google that that page is important.

11. Blog: Structured for Google

Blog posts on kodemagisk.no are not just articles — they're structured documents that Google understands.

Each post has: a unique SEO title and meta description (from Sanity), a publication date and update date (Google uses the latter to prioritise updated content), categories that are clickable links (internal linking strategy), a table of contents with anchors (improves user experience and can generate Sitelinks in search), Open Graph metadata for social media sharing, and BlogPosting JSON-LD schema that gives Google all the metadata it needs.

Images in blog posts are in WebP format with descriptive alt text and defined dimensions.

12. After launch: Google Search Console and visibility

Launching the website is not the end — it's the beginning of the SEO work.

Google Search Console

After deploy, we submitted the sitemap to Google Search Console. Then we used the "Inspect URL" feature to ask Google to index the most important pages manually: the homepage, service page, project page, blog, reviews and contact page.

This doesn't force indexing, but it puts the pages in Google's queue — instead of waiting for Google to discover them on its own.

Google Tag Manager and Analytics

We created accounts in Google Tag Manager (GTM) and Google Analytics 4 (GA4). GTM is implemented in the website and handles all tracking scripts — so we can add and remove tracking without changing the code.

GA4 gives us insight into how visitors use the website: which pages they visit, how long they stay, and which actions they take.

Google Business Profile

For local visibility, we created a Google Business Profile (formerly Google My Business). This gives us visibility in Google Maps and local search results — a website in Oslo that appears in "web agency Oslo" searches in combination with a Business Profile has a significantly higher chance of getting clicks.

The Business Profile contains address, opening hours, website link, service categories, and customer reviews that match the AggregateRating data on the website.

Checklist: Everything you need (in the right order)

This checklist summarises the process in the order things should actually be done.

Phase 1 — Strategy and security

Define target audience, goals and markets
Choose technology stack (frontend, CMS, database, hosting)
Create GitHub repository with branch protection (main/develop/feature)
Configure .gitignore to protect sensitive information
Set up server security (.htaccess, php.ini, HTTPS, security headers)
Configure CI/CD for automatic deployment

Phase 2 — Design system

Define colour palette (primary, secondary, neutral, semantic)
Design logo and generate favicons in all sizes
Choose and self-host fonts (WOFF2)
Build typographic system (scale, weights, line height, letter spacing)
Define button styles, sizes and states
Document everything as CSS custom properties

Phase 3 — Technical foundation

Set up project structure and folder organisation
Install dependencies (pnpm)
Build base components (layout, navigation, footer, head)
Configure multilingual routes (i18n)
Set up robots.txt
Configure sitemap generation

Phase 4 — Content and CMS

Build Sanity schemas with SEO fields (seoTitle, seoDescription)
Build section-specific components for each page
Configure GROQ queries to fetch content
Write content for each page (copywriting with SEO mindset)
Write SEO titles and meta descriptions for all pages
Fill in content in Sanity Studio

Phase 5 — SEO and structured data

Implement JSON-LD (Organization, WebSite, Service, BlogPosting, BreadcrumbList)
Verify heading hierarchy (H1 → H2 → H3) on all pages
Optimise images (WebP, lazy loading, defined dimensions)
Verify WCAG AA contrast (minimum 4.5:1 for body text)
Run PageSpeed Insights and fix any issues
Verify Open Graph and Twitter Card metadata

Phase 6 — Launch and visibility

Deploy to production
Submit sitemap to Google Search Console
Inspect and request indexing of key pages
Implement Google Tag Manager and Analytics 4
Create Google Business Profile with complete information
Monitor Core Web Vitals and search results in the following weeks

Conclusion

Building a professional website in 2026 is not about choosing the right template or the prettiest design. It's about making hundreds of small, thoughtful decisions — from the branching strategy in Git to the letter spacing in headings — that together create a website that's fast, secure, accessible, and visible in search.

Kodemagisk.no is built to be exactly that example. Not because it's perfect, but because every choice is deliberate. And that's the real difference between a website that "works" and a website that works for your business.

If you want your website to follow the same principles — get in touch for a free conversation. We'll tell you what it will cost and how long it will take, with no strings attached.

Kodemagisk is a web agency in Oslo that builds websites, online stores and web applications for small and medium-sized businesses in Norway. We speak Norwegian, English, Spanish and Romanian.