Udvikling
Next.js udvikling: sites og apps, der kan findes
Next.js er det, man griber fat i, når et site skal være to ting på én gang: hurtigt og til at finde i Google, og en rigtig applikation bag login. Jeg bygger dem, og jeg retter dem, hvor applikationen er gået ud over hastigheden og synligheden.
Hvornår giver det mening
- I skal have marketingsider, der rangerer, og en applikation, og vil helst ikke drive to kodebaser
- Jeres React-app er usynlig for søgemaskiner og AI-assistenter, og det er begyndt at koste
- Et Next.js-site er langsomt eller dyrt at hoste, og ingen er sikre på hvilken del der gør det
Sådan foregår det
- 01
Beslut hvad der renderes hvor
Hvilke sider er statiske, hvilke server-renderes, og hvilke er rene klientsider. At tage fejl her er årsagen til de fleste Next.js-sites, der er langsomme eller usynlige, og det er billigt at få rigtigt fra start.
- 02
Byg
Sider, API-ruter og datalaget, med teknisk SEO og GEO bygget ind fra dag ét frem for lagt på bagefter — canonical, structured data, sitemap, /llms.txt og hreflang, hvis I kører mere end ét sprog.
- 03
Mål og overdrag
Core Web Vitals på rigtige enheder, Search Console koblet på, og hosting I selv styrer. Tal før og efter, så I kan se, hvad der blev ændret.
Hvad arbejdet dækker
- Server-rendering og statisk generering, valgt per side frem for som standard
- Teknisk SEO og GEO indbygget: canonical-URL’er, structured data, sitemap, hreflang og /llms.txt
- API-ruter og databasen bagved
- Hosting, udrulning og overvågning, som I ejer og kan flytte et andet sted hen
Headless CMS: WordPress, Sanity eller Payload
En Next.js-side skal have et sted, hvor indholdet bliver redigeret, og det er typisk et headless CMS. Har redaktørerne allerede vænnet sig til WordPress, kan WordPress blive som redigeringsværktøj, mens Next.js leverer selve siden, hvilket giver hastigheden uden at skulle lære et nyt system. Starter I forfra, er Sanity eller Payload ofte bedre egnet, fordi de er bygget til at levere indhold til flere steder på én gang, for eksempel både en hjemmeside og en app.
Valget afhænger af, hvem der skal redigere, hvor meget struktureret indhold der er, og om I vil betale for et hostet produkt eller have det hele på egen server. Jeg sætter det op, så redaktørerne kan se en forhåndsvisning af ændringerne, før de bliver udgivet, og så en ændring i CMS’et er ude på siden inden for få sekunder, uden at hele siden skal bygges om.
Flytning fra WordPress uden at miste placeringer
Når en side flytter platform, ligger den største risiko i de gamle adresser. Hver side, der i dag giver trafik fra Google, skal enten beholde sin adresse eller have en 301-viderestilling til den nye, og titler, beskrivelser, strukturerede data og interne links skal med over. Jeg laver en liste over alle adresser fra sitemap, Search Console og serverlogs før flytningen og tjekker bagefter, at hver eneste af dem svarer korrekt.
Efter lanceringen følger jeg indekseringen og placeringerne i Search Console de første uger, så et fald bliver opdaget og rettet, mens det stadig er lille. En flytning, der er lavet ordentligt, giver som regel en hurtigere side og bedre Core Web Vitals, og det er derfor, de fleste gør det. Uden den liste er en flytning en af de hyppigste grunde til, at en side mister sine placeringer.
Ofte stillede spørgsmål
- Hvad koster et Next.js-projekt?
- Det afhænger af, hvor meget af projektet der er sider, og hvor meget der er logik. Et rent site er den mindre opgave, og en applikation bag login er den større. Omfanget og prisen bliver aftalt skriftligt først, så du ved, hvad det koster, før der bliver bygget noget.
- Next.js eller WordPress?
- WordPress, hvis pointen er indhold, I selv retter, og siden mest er sider — det er billigere at bygge og billigere at drive, og det siger jeg gerne. Next.js når det samme produkt både skal være et hurtigt offentligt site og en applikation, eller når siden skal kunne noget, et tema spænder ben for. At vælge den dyre løsning til et brochuresite er en udbredt og undgåelig fejl.
- Er Next.js godt til SEO og til AI-søgning?
- Det afhænger af, hvordan siderne renderes. Server-renderede og statiske sider bliver indekseret fint. Et Next.js-site bygget helt på klientsiden har præcis samme problem som enhver anden single-page-applikation, plus en tungere regning. Valget af rendering per side afgør, hvad Google overhovedet kan indeksere — og det betyder endnu mere for ChatGPT, Perplexity og Googles AI-svar, som for de flestes vedkommende slet ikke kører JavaScript. Er siderne server-renderet, er det samme arbejde, der dækker begge dele.
- Hvor bliver det hostet?
- Hvor I vil, og det valg bør I beholde. Det kører lige så fint i en container hos en almindelig europæisk hostingudbyder som på en administreret platform — jeg driver HostStack, så den opsætning kender jeg godt. Det afgørende er, at I ejer hostingkontoen og kan flytte uden at spørge om lov.
- Kan du overtage et eksisterende Next.js-projekt?
- Ja. Det starter som regel med en teknisk gennemgang, og på Next.js er det første, der er værd at kigge på, næsten altid rendering-strategien, fordi det er dér, både hastigheden og hostingregningen bliver afgjort.
Andre teknologier jeg arbejder i
Ved du ikke, hvad du skal vælge?
Skriv et par linjer om, hvad du gerne vil opnå. Du får svar inden for 24 timer, og et ærligt ja eller nej.