Renovera eller bygga om webbplatsen? Sju signaler som avgör

En långsam eller svårredigerad webbplats behöver inte alltid ersättas. Med sju konkreta kontrollpunkter kan ni avgöra om renovering eller ombyggnad ger bäst affärsnytta.

Tre separata ingrepp – en ändring i CMS:et, specialskriven kod och manuell utvecklarhjälp – för att publicera ett enda kampanjformulär är en tydlig varningssignal. Då sitter problemet sannolikt inte i webbplatsens färger, typografi eller startsida, utan i en struktur där innehåll, design och funktioner har vuxit ihop. För ett mindre eller medelstort företag innebär det att även enkla marknadsinitiativ kan bli långsamma, svåra att prissätta och beroende av en viss leverantör.

Många företagswebbplatser går fortfarande att förbättra stegvis, särskilt om fungerande integrationer kan lämnas orörda medan navigation, mallar och frontend byts ut. Andra har äldre WordPress-teman, sidbyggare och tillägg som skapar följdfel så snart någon uppdaterar PHP, ändrar ett formulär eller lägger till ett språk. Skillnaden syns sällan i en skärmdump; den framträder först när ni granskar beroenden, informationsstruktur och kostnaden för de förändringar verksamheten planerar de kommande två åren.

Ett detaljerat beroendediagram över en äldre SME-webbplats där CMS, WordPress-tema, sidbyggare, formulär, CRM, affärssystem, betalning och analysverktyg är sammankopplade; röda linjer visar odokumenterade eller föråldrade beroenden bakom ett till synes enkelt kampanjformulär

Beslutet bör därför inte börja med frågan om webbplatsen ser gammal ut, utan med frågan om dess svagaste delar kan bytas utan att resten påverkas. En tekniskt frisk men visuellt föråldrad webbplats kan ofta renoveras till rimlig kostnad. Om både publiceringsflödet, sidstrukturen och integrationerna motarbetar verksamheten riskerar däremot en kosmetisk renovering att bli ett dyrt lager ovanpå samma begränsningar.

Kan webbplatsens svagaste delar bytas utan att resten går sönder?

Börja med en teknisk genomgång av CMS-version, PHP- eller servermiljö, tema, mallar, formulär, tillägg, externa API:er och kopplingar till exempelvis CRM, orderflöden och inloggning. I en beroendekarta ska det gå att se vilka funktioner som använder egna tillägg, särskilda databasfält eller kod som saknar dokumentation och tydlig ägare. Stegvis förbättring är rimlig när navigation, sidmallar och frontend kan ändras separat, samtidigt som affärskritiska flöden kan testas och lämnas intakta. När en normal uppdatering av CMS eller PHP bryter kritiska tillägg, eller när samma kontaktuppgifter måste ändras manuellt på tiotals sidor eftersom de är hårdkodade i temat, har den tekniska skulden blivit systemisk. Be leverantören visa vilka beroenden som kan behållas, ersättas eller avvecklas och hur varje val påverkar testning, drift och framtida uppdateringar.

När informationsstrukturen motarbetar företagets affärsmål räcker inte en ny design

Granska hur en besökare går från landningssida till rätt erbjudande, bevis och kontaktväg, inte bara hur enskilda sidor ser ut. Om menyn använder interna avdelningsnamn som ”Process”, ”Solutions” och ”Advisory” medan kunderna söker efter ett konkret problem eller en viss tjänst behöver navigationen byggas om kring verkliga sök- och köpintentioner. Ett företag som har gått från en huvudtjänst till flera kundsegment kan samtidigt behöva en ny innehållsmodell där språk, branscher och erbjudanden kombineras utan att varje sida byggs för hand. Fristående speciallayouter gör varje nytt erbjudande dyrt, medan återanvändbara sidtyper med strukturerade fält för målgrupp, problem, bevis och CTA gör publiceringen snabbare och resultaten lättare att jämföra. En renovering räcker däremot ofta när huvudstrukturen fortfarande speglar affären och bristerna främst består av svaga texter, otydliga uppmaningar eller onödiga steg i formulären.

En före- och efterbild av en sitemap där en organisationsstyrd meny med blandade sidtyper ersätts av en behovsstyrd informationsstruktur för tre kundsegment, med tydliga vägar från landningssida till tjänst, kundbevis och konverteringspunkt

Räkna på två års förändringar – inte bara priset för nästa lansering

Jämför alternativen över 24 månader och ta med återkommande utvecklartid, licenser för överlappande tillägg, driftincidenter, intern innehållstid och väntan på att kampanjer ska kunna publiceras. En renovering med lågt lanseringspris blir snabbt dyr om varje landningssida även i fortsättningen kräver specialkod, test av flera mallar och hjälp från en extern utvecklare. Lägg därför verksamhetens planerade förändringar – exempelvis ett nytt språk, en CRM-integration och ett nytt tjänsteområde – i både renoverings- och ombyggnadskalkylen och bedöm om plattformen klarar dem utan kärnmodifieringar. En ombyggnad behöver samtidigt ett konkret migreringsunderlag med exporterade URL:er från sitemap och analysdata, kartläggning av inkommande länkar och organiska landningssidor samt definierade 301-redirects innan den gamla strukturen tas bort. Sätt beslutskriterierna före offertförfrågan: om den befintliga lösningen misslyckas på flera affärskritiska krav blir en ombyggnad lättare att motivera, men om problemen kan isoleras kan stegvis förändring ge lägre risk.

Tre vägar: stegvis renovering, omplattformning eller total ombyggnad

Rätt väg avgörs mindre av hur webbplatsen ser ut och mer av beroenden, informationsstruktur och kommande förändringsbehov. Jämför därför kostnad, lanseringsrisk och intern arbetsinsats över minst två år, inklusive den period då gammal och ny teknik eventuellt måste fungera parallellt.

Strangler Fig Pattern

Med Strangler Fig Pattern ersätts webbplatsen del för del i stället för genom en enda stor lansering. Företaget kan exempelvis börja med formulär eller produktsidor, mäta resultatet och därefter flytta nästa avgränsade funktion.

  • Minskar lanseringsrisken eftersom formulär, sök eller produktsidor kan bytas och mätas separat.
  • Fördelar investering och innehållsarbete över tid i stället för att kräva en stor engångsinsats.
  • Gamla och nya lösningar måste ofta samexistera, vilket kan ge dubbla mallar, integrationer och analysflöden.
  • Löser inte en felaktig informationsstruktur om teamet bara ersätter komponenter utan att ompröva navigation och innehåll.

Passar: En affärskritisk webbplats där vissa delar fungerar bra, men tydligt avgränsade funktioner skapar kostnader eller risker.

Replatforming till WordPress med Gutenberg

En omplattformning flyttar innehåll och funktioner till en modernare WordPress-grund utan att verksamheten måste välja en avancerad, helt frikopplad arkitektur. Egna Gutenberg-block kan ge redaktörerna tydliga byggdelar samtidigt som varumärkesregler och konverteringsmönster hålls samman.

  • Gutenberg och egna block kan ge marknadsteamet större självständighet utan att varje ny landningssida kräver utveckling.
  • Det stora ekosystemet gör det relativt enkelt att hitta kompetens och standardintegrationer för formulär, SEO och CRM.
  • För många tredjepartsplugin kan efter två år ge högre underhållskostnad, säkerhetsrisk och svåröverskådliga beroenden.
  • Migreringen kräver normalt mer innehållsrensning, redirect-arbete och kvalitetssäkring än vad den tekniska offerten först visar.

Passar: Verksamheter där nuvarande CMS bromsar publicering och vidareutveckling, men där behoven kan lösas med en välstyrd WordPress-installation.

Greenfield Rebuild med content-first informationsarkitektur

En greenfield-ombyggnad börjar med kundresor, innehållstyper och affärsmål innan sidmallar och teknik väljs. Metoden ger störst frihet, men kräver att verksamheten fattar fler beslut om innehåll, ägarskap och framtida arbetssätt före utvecklingen.

  • Gör det möjligt att strukturera webbplatsen efter kundresor och affärsmål i stället för att ärva gamla avdelnings- och menysystem.
  • Kan eliminera teknisk skuld och skapa en tydligare grund för nya marknader, språk, tjänster och integrationer under kommande år.
  • Har högst initial kostnad och kräver omfattande beslut om innehåll, ansvar, SEO-migrering och framtida arbetssätt.
  • Big bang-lanseringar innebär större risk; förseningar uppstår ofta när innehållsproduktion och interna godkännanden underskattas.

Passar: Företag där både tekniken och informationsstrukturen motarbetar affären, eller där de kommande två årens förändringar inte ryms i nuvarande lösning.

Välj Strangler Fig Pattern när problemen går att isolera och verksamheten behöver låg lanseringsrisk. Om redaktörsflödet är huvudproblemet är en WordPress-omplattformning ofta rimlig, medan en greenfield-ombyggnad bör reserveras för lägen där struktur, teknik och framtida affärsbehov måste förändras samtidigt.

Så avgör du om webbplatsen ska renoveras eller byggas om

  1. Testa en avgränsad ändring innan du godkänner en renovering

    Be leverantören byta ut en kritisk komponent, exempelvis kontaktformuläret eller sidhuvudet, i en stagingmiljö skapad med WP Staging, Local eller motsvarande verktyg för ert CMS. Följ vilka mallar, stilmallar och integrationer som måste ändras och testa samtidigt andra centrala flöden. Om försöket kräver ingrepp i fler än tre mallar, skapar CSS-konflikter eller slår ut andra funktioner är webbplatsen sannolikt för hårt sammanbyggd för en kostnadseffektiv renovering.

  2. Kartlägg beroenden med en teknisk inventering

    Exportera samtliga webbadresser med Screaming Frog och samla CMS-version, integrationer, formulär, spårningsskript, egna koddelar och tillägg i ett kalkylark. Markera varje del som behålla, ersätta eller avveckla och begär en tidsuppskattning för analys, utveckling och test per beroende. Fler än tio verksamhetskritiska tillägg eller integrationer utan tydlig ägare är en stark signal om att en kontrollerad ombyggnad kan bli säkrare än fortsatta punktinsatser.

  3. Rita om strukturen utifrån kundens uppgift

    Använd GA4 och Google Search Console för att identifiera de 20 landningssidor som ger mest organisk trafik och flest förfrågningar, och följ sedan varje väg till kontakt eller köp. Kontrollera om besökaren möter relevanta tjänster och bevis eller tvingas tolka företagets interna organisation. Om centrala erbjudanden kräver fler än tre klick från startsidan eller ligger under avdelningsnamn bör ni först ta fram en ny sitemap i FlowMapp eller Octopus.do, inte beställa en ny visuell design.

  4. Prototypa navigeringen innan en enda mall byggs

    Skapa en klickbar struktur i Figma och låt fem personer ur målgruppen utföra tre konkreta uppgifter, exempelvis att hitta rätt tjänst, förstå prisnivån och boka ett möte. Testa med Maze eller Lookback och notera var deltagarna tvekar, går tillbaka eller väljer fel menyväg. Om färre än fyra av fem klarar uppgifterna utan hjälp behöver informationsstrukturen justeras innan utvecklingen startar.

  5. Jämför tvåårskostnaden i tre scenarier

    Räkna separat på renovering, stegvis ombyggnad och total ombyggnad med kostnader för utveckling, hosting, licenser, säkerhetsuppdateringar, innehållsmigrering och minst två större affärsförändringar. Lägg in ett riskpåslag på 15–25 procent för äldre kod och använd ett internt timpris för redaktörernas manuella arbete. En renovering för 120 000 kronor som fortsätter kräva åtta timmars extra handpåläggning varje månad kan inom två år bli dyrare än en ombyggnad för 220 000 kronor, särskilt om kampanjförseningar och incidenter också räknas in.

En avslutande tvåårig kostnadsmatris med tre scenarier för renovering, stegvis ombyggnad och total ombyggnad samt rader för utveckling, licenser, driftstörningar, redaktörstid, innehållsmigrering, SEO-skydd och försenade kampanjer

Börja med en teknisk inventering, en teständring och en prototyp av den önskade strukturen innan ni begär fast pris. Då kan leverantörerna offerera samma faktiska omfattning, och ni väljer utifrån två års affärsnytta och förändringskostnad i stället för lägsta lanseringspris.

Ämnen

Fler artiklar