Ett byte av CMS eller webbplattform kan påverka organisk synlighet och affärskritiska flöden, även när domänen, designen och många URL:er ser ut att vara oförändrade. Det räcker inte att innehållet syns i det nya systemet.
Hos oss på TribuSoft kvalitetssäkrar vi den tekniska outputen före, under och efter lanseringen. Vi granskar bland annat sidmallar, metadata, renderad HTML, indexeringssignaler, URL-beteende, funktioner och mätning så att den nya plattformen är redo för både sökmotorer och användare.
Ett CMS-byte är ett förändringsprojekt, inte en ren innehållsflytt. Den nya plattformen kan generera annan HTML, hantera metadata på ett nytt sätt och förändra navigationen utan att skillnaden är synlig för den som besöker webbplatsen i en vanlig webbläsare.
Ett fel i en sidmall kan samtidigt påverka tusentals produkt-, kategori-, artikel- eller tjänstesidor. Det kan handla om generiska sidtitlar, felaktiga canonical-taggar, förlorade rubriker eller länkar som inte går att följa. Därför granskar vi både enskilda viktiga sidor och de mallar och komponenter som styr webbplatsen i skala.
Vår bedömning är att en plattformsmigrering inte är klar när den nya webbplatsen går att publicera. Den är klar när överenskomna krav för SEO, funktion och mätning har verifierats och kritiska fel är hanterade.
Vi kan kopplas in innan ni väljer plattform, under utvecklingen, inför en planerad lansering eller som en oberoende kvalitetssäkring av ett projekt som drivs av ett annat utvecklingsteam. Ju tidigare kraven kommer in i processen, desto enklare är det vanligtvis att undvika kostsamma ändringar sent i projektet.
Arbetssättet passar företagswebbplatser, e-handlar, innehållstunga webbplatser, internationella lösningar och miljöer med flera integrationer. Omfattningen anpassas efter bland annat antal mallar, innehållstyper, språk, marknader, integrationer och tekniskt ansvar.
Sökmotorer behöver kunna hitta, hämta, rendera och tolka webbplatsens sidor. En ny plattform kan påverka varje steg. Exempelvis kan centralt innehåll laddas först efter JavaScript, metadata kan saknas i sidans källkod eller navigationen kan byggas med klickhändelser i stället för vanliga länkar.
Vi bedömer inte ett CMS utifrån dess varumärke. Det avgörande är vad lösningen faktiskt levererar: stabila och åtkomliga URL:er, indexerbar HTML, tydliga interna länkar, korrekta siddata och en fungerande servermiljö.
Även URL:er som ska behållas behöver testas. CMS kan normalisera snedstreck, versaler, parametrar, filändelser eller standard-URL:er på ett sätt som skapar oönskade variationer. Om URL:er ska ändras samordnar vi kontrollen med den bredare migreringsprocessen, men detaljerad URL-mappning och omdirigeringsstrategi hanteras på rätt nivå i projektet.
Vi börjar med att dokumentera vad den befintliga lösningen behöver kunna bevara, förbättra, ersätta eller avveckla. Det skapar en tydlig baslinje inför testning och uppföljning. Vi fokuserar på sidor, mallar och flöden som är viktiga för synlighet, trafik, leadsgenerering, försäljning eller drift.
Sedan omsätter vi nuläget i en krav- och paritetsmatris. Den jämför gammal och ny lösning på mall-, fält- och funktionsnivå. Varje punkt får ett krav, en testmetod, en ansvarig och en godkännare. Det gör det tydligt vad som är ett kritiskt lanseringshinder och vad som kan förbättras efteråt.
En migrering kan föra över brödtexten korrekt men ändå tappa viktiga SEO-data. Vi granskar därför hur det nya CMS:et hanterar både synligt innehåll och de fält som styr hur sidan presenteras och tolkas.
På mallnivå kontrollerar vi exempelvis startsida, tjänstesidor, redaktionella sidor, produkt- och kategorisidor, artiklar, lokala sidor och andra specialmallar. Vi testar att mallarna genererar unika och relevanta värden där de ska göra det, i stället för att ersätta data med generiska standardvärden.
Vi granskar också om den nya innehållsmodellen kan bära befintliga relationer, taxonomier och bilddata. När ett fält saknar en direkt motsvarighet i målplattformen behöver vi fatta ett aktivt beslut om hur informationen ska hanteras. Att inte fatta beslutet är ofta det som skapar regressionsfel efter lansering.
JavaScript är inte i sig ett SEO-problem. Däremot behöver vi säkerställa att centralt innehåll, länkar och siddata är tillgängliga på ett robust sätt. Det är särskilt viktigt i headless- och JavaScript-tunga lösningar.
Vi kontrollerar både den HTML som servern skickar från början och den HTML som finns efter rendering i webbläsaren. En sida kan se rätt ut visuellt samtidigt som rubriker, produktinformation, länkar, canonical eller indexeringsdirektiv saknas eller får fel värde i den tekniska outputen.
När lösningen kräver rendering bedömer vi förutsättningarna för exempelvis server-side rendering, statisk rendering och hydration. Vi granskar också att navigation och komponenter använder vanliga länkar med href-attribut, så att sökmotorer kan upptäcka relevanta sidor på ett tillförlitligt sätt.
Stagingmiljön ska inte indexeras. Samtidigt måste tillfälliga blockeringar i robots.txt, noindex-taggar och miljöinställningar tas bort vid driftsättning. Vi behandlar dessa punkter som uttryckliga lanseringskontroller, inte som antaganden.
Organisk trafik skapar begränsat värde om användaren inte kan skicka formuläret, hitta rätt produkt, använda filtret eller slutföra sitt köp. Därför kopplar vi SEO-kvalitetssäkringen till de funktioner som bär den kommersiella kundresan.
Funktionsparitet betyder inte att varje äldre funktion måste kopieras. Vissa funktioner ska förbättras, ersättas eller avvecklas. Det viktiga är att beslutet är dokumenterat och att affärskonsekvensen är bedömd. Kritiska flöden får testfall och en utsedd godkännare.
Mätning testas separat från den visuella upplevelsen. En webbplats kan fungera för användaren samtidigt som datalagret, taggarna, samtyckesplattformen eller konverteringshändelserna har slutat fungera. Vi validerar att den data ni behöver för uppföljning fortfarande samlas in på ett tillförlitligt sätt.
Direkt efter lanseringen kontrollerar vi att produktionsmiljön svarar som den ska och att viktiga sidor, mallar och flöden fungerar. Vi följer bland annat statuskoder, indexeringssignaler, sitemap, rendering, Search Console, prioriterade landningssidor och konverteringsdata.
Vi jämför utfallet med baslinjen för att upptäcka avvikelser. En tillfällig förändring i trafik eller synlighet innebär inte automatiskt att ett tekniskt fel har uppstått. Däremot gör tydliga kontrollpunkter att vi snabbare kan skilja mellan migreringsrelaterade problem, mätfel och andra förändringar i efterfrågan eller marknadsföring.
Större förändringar bör om möjligt delas upp. Att samtidigt byta CMS, domän, design, struktur och innehåll gör felsökningen svårare. För en bredare process kring olika typer av webbplatsflyttar erbjuder vi SEO-migrering utan onödiga synlighetsförluster.
Vi anpassar uppdraget efter er projektplan och era interna resurser. Vi kan arbeta tillsammans med ert utvecklingsteam, er plattformsleverantör eller en extern webbyrå. Vår roll kan vara rådgivande, kvalitetssäkrande eller mer operativ inom de områden där vi ansvarar för implementation.
En tydlig ansvarsfördelning minskar risken för att SEO-krav hamnar mellan design, utveckling, innehåll och analys. Vi gör klart vem som ska fatta beslut, implementera åtgärder, testa resultatet och godkänna lanseringen.
Vi på TribuSoft arbetar i skärningen mellan SEO, webbutveckling, spårning och konvertering. Det gör att vi kan bedöma en migrering utifrån både sökmotorernas krav och verksamhetens viktigaste digitala flöden.
I vårt publicerade case för Shepherd of Sweden beskriver vi arbete med plattformsmigrering, URL-validering, bevarande av relevanta landningssidor och teknisk kvalitetssäkring. För Opus Bilprovning redovisar vi 20 procent högre organisk trafik och 17 procent högre omsättning efter migrerings- och fortsatt SEO-arbete. Varje migrering har dock egna tekniska och kommersiella förutsättningar, vilket är varför vi planerar och offererar insatsen utifrån det aktuella projektet.
Ja. Ett CMS-byte kan förändra metadata, canonical-taggar, internlänkar, HTML, rendering, robotsdirektiv och andra signaler även när publika URL:er behålls. Därför behöver den nya plattformens output testas före och efter lanseringen.
En plattformsmigrering fokuserar på bytet av CMS, frontend, e-handelsplattform eller teknisk miljö. En domänmigrering innebär att webbplatsen flyttar till en ny domän. Projekten kan ske samtidigt, men riskerna och kontrollerna skiljer sig åt.
Ja, ofta. Samma visuella design betyder inte samma HTML, malllogik, metadata eller interna länkar. Den tekniska implementationen bakom gränssnittet avgör om viktiga SEO-signaler och funktioner faktiskt följer med.
Vi jämför käll-HTML med renderad HTML och kontrollerar att centralt innehåll, rubriker, länkar, canonical-taggar och indexeringsdirektiv är tillgängliga och korrekta. Vid behov bedömer vi även vald renderingsstrategi och hur den påverkar sökmotoråtkomst.
Kritiska mallar, metadata, indexeringssignaler, navigationslänkar, affärskritiska flöden och mätning bör vara testade mot accepterade kriterier. Stagingblockeringar ska också vara hanterade så att de inte följer med till produktion.
Ja. Vi kan ta fram krav, granska staging, prioritera fel och delta i lanseringsprocessen tillsammans med era interna utvecklare, en plattformsleverantör eller en extern webbyrå.
Nej. Ingen migrationsprocess kan garantera oförändrade positioner, trafik eller intäkter. Vårt fokus är att minska risk, bevara viktiga signaler, testa affärskritiska flöden och snabbt upptäcka avvikelser.
Ta in oss innan utvecklingen är låst, inför en kommande lansering eller när ni vill kvalitetssäkra en lösning som redan byggs. Vi bedömer omfattningen utifrån era mallar, integrationer, målplattform och affärskritiska flöden.
Kontakta oss på TribuSoft för en kostnadsfri offert eller för att inleda en dialog om er plattforms- och CMS-migrering.
