Bag om simonij.com: sådan byggede jeg en hurtig og SEO-venlig freelancer-hjemmeside

Min egen freelancer-hjemmeside, simonij.com, er kodet fra bunden i Next.js og Tailwind CSS. Den findes på dansk og engelsk, sætter ingen cookies og har derfor intet cookiebanner, og blogindlæggene ligger som filer i stedet for i et CMS. Her er valgene bag stack, hastighed, SEO og konvertering, og hvornår de ikke passer til andre end mig.

Det er en case om mit eget projekt, så der er ingen kunde der bekræfter resultatet. Læs det som en udviklers valg og ikke som en opskrift alle skal følge.

Den korte version

Siden er lille sammenlignet med de platforme jeg bygger for kunder. Et større projekt fra bunden har jeg beskrevet i fra idé til SaaS: valg og prioriteringer. Her handler det om én ting: en hjemmeside der skal få en virksomhed til at skrive til mig.

Udgangspunktet: en pæn skabelon der ikke skaffede opgaver

Den gamle simonij.com var en købt Tailwind UI-skabelon i Next.js 13. Den så ordentlig ud, men den var kun på engelsk, og forsiden handlede mest om mig som person. Ingen sider forklarede hvad jeg laver, hvad det koster, eller hvordan et samarbejde foregår. Kontakt foregik via en mailadresse på om-siden, og skabelonens nyhedsbrevsformular var slået fra.

Det er et udbredt problem på freelancer-sider: siden bliver et visitkort i stedet for et salgsværktøj. Den besøgende kan se at du findes, men ikke om du passer til opgaven. Den nye side fik derfor tre krav:

1. Den skal forklare ydelser og priser, så en beslutningstager kan vurdere mig uden at ringe først.
2. Den skal kunne findes på de ord virksomheder søger på, både på dansk og engelsk.
3. Den skal gøre det let at skrive og give mig nok information til at svare præcist.

Designet er bevidst enkelt: lys baggrund, få farver, god luft og to skrifttyper (Bricolage Grotesque til overskrifter og Inter til brødtekst). Det er hurtigt at indlæse, nemt at læse på en telefon og lader indholdet gøre arbejdet.

Stack: hvorfor Next.js og ikke WordPress

Jeg arbejder med Laravel og React til kunder, så valget handlede om hvad jeg kan vedligeholde i årevis uden besvær.

Siden kører på Next.js med App Router og React Server Components. Det meste bliver bygget som færdig HTML på serveren, og kun de interaktive dele, fx kontaktformularen, kører i browseren. Koden er TypeScript i strict-tilstand, og i Tailwind CSS v4 ligger farver og skrifttyper som tokens i én CSS-fil.

Hvorfor ikke WordPress? For mig ville det betyde plugins der skal opdateres, en database der skal sikkerhedskopieres, og et administrationspanel jeg aldrig ville åbne. Til mange virksomheder er WordPress det rigtige valg, og jeg har skrevet en ærlig sammenligning af WordPress og en custom-kodet hjemmeside til dig der står med netop det valg.

Blogindlæggene er MDX-filer (Markdown med mulighed for komponenter) i samme kodearkiv som resten af siden. Titel, beskrivelse, dato og sprog bliver tjekket med valideringsbiblioteket Zod. Mangler et indlæg en beskrivelse, fejler bygget, og intet bliver udgivet. Det fanger præcis de fejl der ellers ender som tomme felter i Googles søgeresultater. Resten af mit værktøj har jeg samlet i listen over de værktøjer jeg bruger som freelance udvikler.

Hastighed: det meste handler om fravalg

En langsom hjemmeside skyldes sjældent frameworket. Det skyldes typisk det der bliver lagt ovenpå: cookiebanner, chat-widget, en tag manager med sporingsscripts og skrifttyper fra flere servere. Jeg har fravalgt det meste:

• Ingen cookies. Vercel Web Analytics genkender ifølge Vercels dokumentation om privatliv besøg via en hash af forespørgslen i stedet for cookies og kasserer den efter 24 timer. Uden cookies er der intet at bede om lov til, og intet banner der dækker siden.
• Skrifttyper fra eget domæne. Inter og Bricolage Grotesque indlæses med next/font, som ifølge Next.js-dokumentationen hoster Google Fonts sammen med siden. Browseren kontakter ikke Google, og teksten hopper ikke.
• Sider bygget på forhånd. Sider og indlæg genereres på forhånd og fornyes én gang i døgnet. Et indlæg med en fremtidig dato dukker op af sig selv.
• Ingen tunge tredjepartsscripts. Ingen chat og ingen indlejrede opslag fra sociale medier. Spambeskyttelsen på formularen er et skjult felt som robotter udfylder og mennesker aldrig ser, med Cloudflare Turnstile som ekstra mulighed kun på kontaktsiden.

Jeg måler med Googles tre Core Web Vitals: det største element (LCP) bør være indlæst inden for 2,5 sekunder, reaktionen på klik (INP) bør være højst 200 millisekunder, og layoutskift (CLS) bør højst være 0,1. Grænserne gælder for 75 % af sidevisningerne ifølge Googles gennemgang på web.dev. Derfor følger jeg Speed Insights, der måler på rigtige besøg, frem for en Lighthouse-score fra min egen computer.

SEO bygget ind i koden

SEO på en lille side handler om to ting: at Google forstår hvad hver side handler om, og at der findes indhold nogen søger efter. Det første kan kode løse. Det andet kræver en blog.

To sprog uden at forvirre Google

Adresserne er oversat: /ydelser på dansk og /en/services på engelsk. Hver side henviser til sin anden sprogversion med hreflang-tags, og en x-default peger på den engelske som standard for besøgende der hverken bruger dansk eller engelsk i browseren. Google kræver at hver version henviser til både sig selv og de andre, ellers ignoreres taggene, jf. Googles vejledning om lokaliserede versioner. Et blogindlæg får kun hreflang når begge sprog er udgivet.

Siden sender heller ikke folk videre ud fra browserens sprog. Google fraråder det i sin vejledning om flersprogede sider, fordi det kan skjule versioner for både brugere og søgemaskiner.

Det tekniske grundarbejde

• Et sitemap med alle sider og deres sprogversioner, genereret ud fra indholdet.
• Structured data om mig (Person), mine ydelser (ProfessionalService og Service) og hvert indlæg (BlogPosting og brødkrummer).
• Et automatisk delingsbillede på 1.200 x 630 pixels til hvert indlæg.
• Permanente 301-redirects fra gamle adresser, fx /about til /om, så gamle links stadig virker.
• Et RSS-feed til bloggen.

Intet af det er avanceret. Det er bare den slags der bliver glemt, når en side er bygget på en skabelon og aldrig bliver kigget efter igen.

Konvertering: gør det let at skrive

En hurtig side der ligger godt på Google, er ligegyldig hvis ingen tager kontakt. De her valg skal gøre et besøg til en henvendelse:

• Én side pr. ydelse, fra hjemmesider og platforme til SaaS-udvikling og vedligehold. Den besøgende finder det de leder efter, og Google har én tydelig side pr. emne.
• Åbne priser. På min prisside kan du se hvordan jeg prissætter, inklusive et betalt forprojekt til fast pris før større opgaver. Jeg går ud fra at de fleste hellere vil fravælge mig på prisen end bruge et møde på at finde den.
• En formular der stiller de rigtige spørgsmål. Den spørger om projekttype, budget og tidsramme, så jeg kan svare konkret i stedet for med modspørgsmål. Bagefter får du en automatisk kvittering.
• Ingen popups. Hvert indlæg har én opfordring i teksten der passer til afsnittet, og én i bunden.
• Direkte kontakt. Det er mig der svarer, og mig der skriver koden. Det er den største forskel på mig og et bureau.

Hvad der sker efter den første besked, har jeg beskrevet i sådan foregår et projekt med mig, fra første opkald til lancering.

Hvornår en side som min ikke passer til dig

Opsætningen passer til mig, fordi jeg er både udvikler og eneste redaktør. Det er ikke nødvendigvis rigtigt for din virksomhed:

• Skal flere redigere indholdet, er filer i et kodearkiv det forkerte valg. Her er WordPress eller et headless CMS bedre, og det kan sagtens kobles på en kodet frontend.
• Har du brug for en simpel side hurtigt og billigt, er en sidebygger som Webflow eller Squarespace ofte nok. En kodet side koster mere og betaler sig først når hastighed, SEO eller integrationer betyder noget for forretningen.
• Skal siden håndtere login, betaling eller booking, er det en platform og ikke en hjemmeside.

Mine egne valg har også en pris: den dag en anden end mig skal skrive på bloggen, skal der et CMS til.

Næste skridt

Tre ting fra simonij.com kan du bruge på din egen side uden at kode: fjern de scripts ingen bruger, lav én side pr. ydelse med et prisniveau, og spørg om budget og tidsramme i kontaktformularen.

Vil du have en side der er hurtig, kan findes på Google og skaffer henvendelser, kan du læse om hvordan jeg bygger hjemmesider for virksomheder. Skal siden have login, data eller betaling, er min MVP-proces uge for uge et bedre sted at starte.

Ofte stillede spørgsmål

Hvad koster en hjemmeside bygget som simonij.com?+

Det afhænger mest af antal sider, antal sprog og om du selv skal kunne redigere indholdet. En kodet side med to sprog, blog og kontaktformular er mere arbejde end en skabelonløsning og koster typisk mere. Mine aktuelle priser står på prissiden, og større opgaver starter med et forprojekt til fast pris, så du kender rammen først.

Kan jeg selv redigere teksterne på en side bygget på samme måde?+

Ja, hvis siden får et CMS. På min egen side retter jeg direkte i filerne, fordi jeg er udvikler. Til en kundeside kan der kobles et headless CMS eller et simpelt administrationspanel på, så du kan rette tekster, priser og sider uden at vente på en udvikler. Det koster lidt mere at sætte op, men det kan hurtigt betale sig hvis indholdet ændres tit.

Skal en freelancer-hjemmeside være på både dansk og engelsk?+

Kun hvis du vil have kunder der ikke læser dansk. Et ekstra sprog er mere end en oversættelse: hver version skal have sine egne søgeord og tekst der lyder naturlig på sproget. Ellers klarer den sig dårligt på Google og virker utroværdig. Sælger du kun i Danmark, er én god dansk side bedre end to halve.

Hvor lang tid tager det at bygge en hjemmeside som denne?+

For en side af denne størrelse er det typisk uger og ikke måneder. Det der oftest trækker ud, er teksterne og ikke koden: ydelsessider, priser og cases skal skrives, godkendes og måske oversættes. Har du teksterne klar fra start, går resten hurtigere, og lanceringen bliver lettere at planlægge.