Ny hemsida eller uppdatera den befintliga? Beslutsguide för företag 2026

Behöver företaget en ny hemsida – eller räcker det att uppdatera den befintliga? Det är en viktig skillnad. En total ombyggnad kostar mer, tar längre tid och innebär större migrationsrisk. Samtidigt kan små kosmetiska justeringar bli dyrt om den gamla tekniken, strukturen eller CMS:et faktiskt blockerar utvecklingen.

Den här beslutsguiden hjälper företag 2026 att välja mellan optimera, redesigna, bygga om eller byta plattform utan att kasta bort fungerande SEO, innehåll och integrationer. Om beslutet redan är taget och ni ska flytta sajten, använd även vår SEO-checklista för webbplatsmigrering.

Snabbguide: uppdatera eller bygg nytt?

Situation	Trolig väg
Designen känns gammal men teknik och CMS fungerar	Redesign/komponentuppdatering
Innehållet är bra men konverteringen svag	CRO, UX och copy före total ombyggnad
Strukturen är rörig men plattformen fungerar	Informationsarkitektur + innehållsarbete
CMS blockerar redaktörer och vidareutveckling	Större ombyggnad eller plattformsbyte
Många kritiska plugins/integrationer är föråldrade	Teknisk ombyggnad kan vara motiverad
Webben är snabb, säker och konverterar men varumärket ändras	Visuell redesign snarare än ny teknisk plattform
URL-struktur och SEO fungerar bra	Bevara så mycket som möjligt vid förändring

1. Börja med problemet – inte lösningen

”Vi behöver en ny hemsida” är ofta en lösning som formuleras innan problemet är definierat.

Fråga först:

• Har vi för lite relevant trafik?
• Konverterar trafiken dåligt?
• Är sajten svår att uppdatera?
• Är tekniken dyr eller osäker?
• Är designen problemet?
• Har affärsmodellen förändrats?
• Behöver vi nya integrationer?

Olika problem kräver olika investeringar.

2. Gör en nulägesaudit

Innan offert bör ni kartlägga:

• SEO och ranking,
• organiska landningssidor,
• konverteringar/leads,
• CMS och teknisk stack,
• prestanda,
• integrationer,
• innehållskvalitet,
• tillgänglighet,
• förvaltningskostnad.

En audit kan visa att 70 procent bör behållas och 30 procent byggas om – vilket ofta är bättre än att riva allt.

3. När räcker en redesign?

En redesign är rimlig när grundsystemet fungerar men upplevelsen behöver förbättras.

Exempel:

• visuell identitet är daterad,
• komponenter är inkonsekventa,
• mobil layout behöver förbättras,
• CTA/hierarki är otydlig,
• innehållet presenteras dåligt.

Behåll URL:er, CMS och fungerande integrationer om de inte behöver ändras.

4. När räcker en innehållsuppdatering?

Om tekniken och UX fungerar kan det vara content som är problemet.

Vanliga signaler:

• gamla tjänstebeskrivningar,
• otydlig positionering,
• svaga case,
• saknade FAQ,
• ingen SEO-struktur,
• många tunna eller duplicerade sidor.

En strukturerad content- och SEO-uppdatering kan ge större effekt än ett visuellt omtag.

5. När behövs ny informationsarkitektur?

Om sajten vuxit organiskt under många år kan navigationen spegla intern organisation i stället för kundbehov.

Tecken:

• tjänster ligger under ologiska menyer,
• samma ämne finns på många URL:er,
• viktiga sidor ligger flera klick bort,
• blogg och tjänster konkurrerar på samma sökord.

Då kan en ny sitemap och internlänkningsmodell behövas även om plattformen behålls.

6. När behöver CMS:et bytas?

Byt inte CMS för att en utvecklare föredrar en annan teknik. Byt när det löser konkreta problem.

Exempel:

• redaktörer kan inte arbeta effektivt,
• säkerhets-/underhållssituationen är dålig,
• plattformen saknar nödvändiga integrationer,
• licens-/driftkostnaden är orimlig,
• tekniken blockerar prestanda eller utveckling.

7. Teknikskuld

En gammal sajt kan fungera utåt men vara dyr bakom kulisserna.

Inventera:

• föråldrade plugins/moduler,
• specialkod utan dokumentation,
• deprecated API:er,
• svår deployment,
• saknad staging,
• manuella processer,
• beroende av en enda leverantör/person.

Om kostnaden att fortsätta lappa blir hög kan ombyggnad vara ekonomiskt rimlig.

8. Säkerhet

En total ombyggnad är inte automatiskt säkrare. Det avgörs av plattform, uppdateringsrutiner, behörigheter, hosting och utvecklingskvalitet.

Men äldre system som inte längre får säkerhetsuppdateringar är en stark signal att tekniken behöver ersättas.

9. Prestanda

En långsam sida kräver inte alltid ny plattform.

Börja med att identifiera flaskhalsen:

• bilder,
• JavaScript,
• plugins,
• hosting,
• databas,
• third-party scripts,
• rendering.

Om problemet kan lösas inom nuvarande stack är en ombyggnad onödig.

10. Core Web Vitals

Mät verkliga sidtyper och fältdata där det finns tillräcklig trafik. En startsida kan vara snabb medan tjänstesidor eller produktmallar är dåliga.

Core Web Vitals är en del av sidupplevelsen, men ska inte ensamt användas som argument för att kasta hela webbplatsen.

11. Konvertering

Om webben får trafik men få leads bör ni först förstå varför.

Granska:

• positionering,
• CTA,
• formulärfriktion,
• trust,
• case,
• mobil upplevelse,
• laddning,
• trafikkvalitet.

Se också vår CRO-guide för landningssidor.

12. SEO – den största risken vid total ombyggnad

En befintlig webb kan ha år av historik, länkar och ranking även om designen är gammal.

Inventera före beslut:

• URL:er med organisk trafik,
• queries och impressions,
• externa backlinks,
• indexerade sidor,
• internlänkar,
• canonical,
• sitemap.

Det ni redan äger organiskt ska behandlas som en tillgång.

13. Byt inte fungerande URL:er i onödan

En ny design kräver inte nya URL:er. Om en tjänstesida behåller samma intent kan samma adress ofta behållas.

URL-byte bör ha ett konkret skäl – inte ske bara för att den nya plattformen använder en annan standard.

14. 301-mappning

När URL:er faktiskt måste ändras behövs en explicit gammal→ny-mappning.

Prioritera:

• trafikdrivande sidor,
• sidor med externa länkar,
• viktiga tjänster,
• kampanj-/content-URL:er med historik.

Läs webbplatsmigrering – SEO-checklista.

15. Backlinks

En gammal sida kan se oviktig ut internt men ha starka externa länkar. Kontrollera backlinkdata innan den tas bort eller slås ihop.

Redirecta till den mest relevanta motsvarigheten när det finns en sådan.

16. Innehåll som ska behållas

Markera innehåll som:

• rankar,
• konverterar,
• har länkar,
• används av sälj/support,
• är juridiskt eller operativt viktigt.

En redesign ska inte radera bra information för att den inte passar den nya visuella mallen.

17. Innehåll som ska konsolideras

Om flera gamla URL:er täcker samma intent kan projektet vara ett bra tillfälle att konsolidera dem.

Välj en tydlig vinnare, slå ihop unikt värde och skapa relevant redirect där det behövs.

18. Innehåll som ska tas bort

Föråldrat, irrelevant eller tunt innehåll behöver inte migreras bara för att det existerar.

Men varje borttagning bör ha ett beslut:

• behåll,
• uppdatera,
• slå ihop,
• 301,
• 404/410.

19. Designsystem

Om problemet är inkonsekvent design kan ett komponent-/designsystem lösa mycket utan att affärslogiken byggs om.

Fördelar:

• återanvändbara komponenter,
• snabbare redaktionellt arbete,
• jämnare UX,
• enklare vidareutveckling.

20. Integrationer

CRM, ERP, bokning, formulär, betalning och andra system kan vara den verkliga kostnaden i ett webbprojekt.

Dokumentera varje integration:

• ägare,
• API/anslutning,
• dataflöde,
• behörighet,
• felhantering,
• testmiljö.

Bygg inte om integrationer som redan fungerar utan anledning.

21. Analytics och tracking

En ny webb får inte nollställa mätningen.

Inventera:

• GA4,
• GTM,
• konverteringar,
• annonsplattformar,
• CRM-attribution,
• consent.

Skapa en före-/efterplan så att resultat går att jämföra.

22. Tillgänglighet

En redesign är ett bra tillfälle att förbättra semantik, kontrast, formulär, tangentbordsnavigation och andra tillgänglighetsproblem.

Men tillgänglighet bör vara en del av komponenterna och QA-processen, inte ett tillägg veckan före lansering.

23. Mobil

Om nuvarande sajt fungerar dåligt på mobil kan en större redesign vara motiverad. Kontrollera dock om problemen främst beror på några komponenter eller hela arkitekturen.

24. Förvaltning efter lansering

Jämför inte bara byggkostnaden.

Räkna på 2–3 års total ägandekostnad:

• hosting,
• licenser,
• support,
• uppdateringar,
• utveckling,
• innehåll,
• SEO.

En billig ny plattform kan bli dyr om varje ändring kräver konsulttid.

25. Redaktörsupplevelse

CMS:et ska stödja de personer som faktiskt arbetar i det.

Testa om redaktörer kan:

• skapa nya sidor,
• återanvända komponenter,
• redigera metadata,
• hantera bilder,
• förhandsgranska,
• publicera utan utvecklare.

26. Kostnad för redesign

En redesign kan vara billigare än total ombyggnad om:

• plattformen behålls,
• integrationer behålls,
• URL:er behålls,
• innehållet till stor del återanvänds.

Men omfattande specialanpassning av en olämplig gammal plattform kan bli falsk ekonomi.

27. Kostnad för ny hemsida

En ny webb kan behöva:

• förstudie,
• ny UX/design,
• utveckling,
• CMS-implementation,
• innehållsmigrering,
• SEO-migrering,
• integrationer,
• tracking,
• QA.

Se vad kostar en hemsida för företag? och vad kostar en webbyrå?.

28. Tidplan

Att uppdatera en befintlig design kan gå snabbare än en total ombyggnad – men inte alltid. En gammal odokumenterad stack kan göra små förändringar långsamma.

För fulla projekt, läs hur lång tid tar det att bygga en hemsida?.

29. När bör ni absolut inte bygga om just nu?

Var försiktig om:

• ingen vet varför projektet görs,
• SEO-data saknas helt,
• innehållet är oförberett,
• integrationer inte är kartlagda,
• deadline drivs av ett godtyckligt datum,
• ingen äger beslut efter lansering.

Gör förstudien först.

30. När är total ombyggnad motiverad?

En ny webb blir mer rimlig när flera av dessa gäller samtidigt:

• tekniken är svår eller riskfylld att underhålla,
• CMS blockerar redaktionen,
• informationsarkitekturen behöver byggas om,
• designsystem saknas,
• nya integrationer kräver annan arkitektur,
• prestanda/säkerhet kan inte lösas rimligt i nuvarande stack.

31. När räcker optimering?

Optimera i befintlig plattform när:

• CMS fungerar,
• URL-strukturen är bra,
• integrationerna fungerar,
• problemen främst är copy, UX, content eller visuella komponenter,
• tekniken fortfarande är underhållen.

32. MVP-redesign

I vissa fall kan ni börja med de viktigaste sidtyperna:

• startsida,
• tjänstesida,
• case,
• kontakt,
• artikel.

Bygg ett komponentbibliotek och migrera resten stegvis istället för big bang.

33. Parallell ny webb

Om en ny webb byggs på staging, skydda staging från indexering och se till att noindex-/robotsblockering inte följer med när sajten går live.

34. Lanseringsplan

Inför lansering behöver ni:

1. URL-mappning,
2. redirects,
3. canonical,
4. sitemap,
5. robots/noindex-kontroll,
6. tracking,
7. formulärtest,
8. prestandatest,
9. backup/rollback,
10. ansvarig för övervakning.

35. Efter lansering

Följ både SEO och affär:

• indexering,
• 404/5xx,
• organiska klick/impressions,
• leads/köp,
• formulär-/integrationsfel,
• Core Web Vitals.

Jämför per viktig sidtyp istället för endast total trafik.

Beslutsmatris

Fråga	Ja	Nej
Är plattformen fortfarande underhållen?	Behåll kan vara rimligt	Överväg byte
Fungerar redaktörsarbetet?	Behåll	Utred CMS-byte
Har sajten stark SEO?	Bevara URL/innehåll noggrant	Större strukturändring kan vara lättare
Är problemet främst design?	Redesign	Utred teknik/content
Är integrationerna fungerande?	Återanvänd om möjligt	Ombyggnad kan motiveras
Är teknisk skuld dyr att bära?	Överväg rebuild	Optimera befintligt

Checklista före beslut

1. Definiera affärsproblemet.
2. Exportera SEO-data.
3. Inventera backlinks.
4. Lista alla viktiga URL:er.
5. Granska konvertering.
6. Dokumentera CMS/teknikskuld.
7. Lista integrationer.
8. Mät prestanda.
9. Bedöm tillgänglighet.
10. Beräkna total ägandekostnad.
11. Jämför optimera/redesign/rebuild.
12. Skapa migrationsplan innan URL:er ändras.

Vanliga misstag

1. Bygga nytt för att designen är tre år gammal.
2. Byta CMS utan dokumenterat problem.
3. Radera SEO-sidor med trafik.
4. Ändra alla URL:er av estetiska skäl.
5. Migrera dåligt innehåll utan granskning.
6. Glömma CRM/tracking.
7. Jämföra bara projektpris istället för 2–3 års kostnad.
8. Lansera utan redirect- och rollback-plan.

Vanliga frågor

Hur ofta behöver företag bygga en ny hemsida?

Det finns ingen fast livslängd. Bygg om när affär, teknik, säkerhet, förvaltning eller användarupplevelse kräver det – inte efter ett visst antal år.

Tappar man SEO när man bygger ny hemsida?

Det behöver inte ske, men stora förändringar innebär risk. Bevara fungerande URL:er där det går och använd en genomarbetad migreringsplan när de måste ändras.

Är det billigare att uppdatera den gamla?

Ofta när teknik och CMS fortfarande är bra. Men om varje ändring kräver speciallösningar kan fortsatt lappning bli dyrare över tid.

Ska man byta från WordPress till en ny teknik bara för prestanda?

Inte automatiskt. Identifiera först verkliga prestandaproblem. Hosting, tema, plugins, bilder och scripts kan vara orsaken snarare än CMS:et i sig.

Välj minsta förändring som löser rätt problem

Kontakta SveaMedia om ni vill göra en nulägesaudit och jämföra optimering, redesign och total ombyggnad innan ni bestämmer budget och teknisk väg.