Sajtflytt – det ögonblick då allt kan gå fel
Du har bestämt dig. Ny plattform, nytt CMS, kanske ett helt nytt domännamn. Det känns spännande. Framtiden ser ljus ut. Men under ytan lurar något som kan förvandla hela projektet till en mardröm: den tekniska SEO:n.
Jag har sett det hända. Gång på gång. Företag som investerat hundratusentals kronor i organisk synlighet – bara för att se alltihop rasa samman på en enda natt. Trafiken faller med 40, 60, ibland 80 procent. Och det värsta? Det behövde inte hända.
En sajtflytt är inte bara att kopiera innehåll från punkt A till punkt B. Det är mer som att flytta ett helt sjukhus – varje kabel, varje koppling, varje liten detalj måste sitta rätt. Annars slutar saker fungera. Och i SEO-världen betyder "slutar fungera" att Google tappar förtroendet för din sajt.
Varför teknisk SEO blir så komplicerat vid en flytt
Tänk dig Googles index som ett enormt bibliotek. Din nuvarande sajt har tusentals kort i katalogen – varje URL, varje intern länk, varje redirect är noggrant registrerad. När du flyttar sajten river du i praktiken upp hela katalogen och ber biblioteket att lära sig ett nytt system. Från scratch.
Det handlar inte bara om 301-redirects. Det vet de flesta vid det här laget. Men det handlar om hundratals – ibland tusentals – små tekniska beslut som alla påverkar varandra. URL-strukturer som förändras. Canonical-taggar som pekar åt fel håll. Hreflang-implementeringar som går sönder. Interna länkstrukturer som plötsligt skapar orphan pages. Renderingsproblem i det nya CMS:et som gör att JavaScript-tunga sidor inte indexeras korrekt.
Och allt det här händer samtidigt. På lanseringsdagen. Utan att du märker det förrän det redan är för sent.
Redirect-mappning – grundbulten som alla underskattar
Låt mig vara ärlig. De flesta redirect-planer jag har granskat har varit undermåliga. Inte för att de som gjort dem är inkompetenta, utan för att uppgiften är genuint svår.
En ordentlig redirect-mappning innebär att du tar varje enskild URL på den gamla sajten – och jag menar verkligen varje enskild URL, inklusive parametriserade varianter, paginerade sidor, filtrerade kategorisidor och gamla kampanjsidor som fortfarande genererar trafik – och kopplar den till sin mest relevanta motsvarighet på den nya sajten.
Det räcker inte att skicka allt till startsidan. Google ser rakt igenom det. En redirect från en produktsida till startsidan behandlas i praktiken som en soft 404. Du förlorar länkjuicen. Du förlorar rankingen. Du förlorar kunden som googlade just den produkten.
Men vet du vad som är ännu värre? Redirect-kedjor. När den gamla URL:en pekar på en mellanliggande URL som i sin tur pekar på den nya. Varje hopp i kedjan läcker auktoritet. Tre hopp? Då har du tappat en betydande del av ditt länkvärde. Och om kedjan innehåller en 302 istället för en 301 någonstans på vägen? Då signalerar du till Google att flytten är tillfällig. Vilket den inte är.
Crawl budget och indexeringsproblem som smyger sig in
Här blir det nördigt. Men det är nödvändigt.
Google har begränsade resurser för att crawla din sajt. Det kallas crawl budget. Vid en sajtflytt exploderar antalet URL:er som Google behöver bearbeta – den gamla sajten med alla redirects, den nya sajten med alla nya URL:er, plus eventuella dubbletter som uppstår under övergångsperioden.
Resultatet? Google hinner inte med. Viktiga sidor indexeras inte. Gamla sidor hänger kvar i indexet veckor eller månader efter flytten. Och du sitter där och undrar varför din nya, vackra produktsida inte syns i sökresultaten.
Jag har sett e-handlare med 50 000+ produkter där det tog Google över fyra månader att fullt ut crawla och indexera den nya sajten. Fyra månader av förlorad synlighet. Förlorad trafik. Förlorad omsättning. Och det var med en hygglig redirect-plan på plats.
Lösningen? En kombination av strategisk robots.txt-hantering, optimerade XML-sitemaps som bara innehåller de nya kanoniska URL:erna, och proaktiv användning av Google Search Console för att signalera flytten. Men det kräver precision. Och erfarenhet.
Canonical-taggar och dubblettinnehåll – den tysta mördaren
Canonical-taggar är deklarationer till Google om vilken version av en sida som är den "riktiga". Vid en sajtflytt kan dessa bli fullständigt kaotiska.
Vanligt scenario: det nya CMS:et genererar automatiskt canonical-taggar som pekar på sig själva – vilket i sig är korrekt. Men om den gamla sajten fortfarande ligger uppe parallellt under en övergångsperiod, och den också har canonical-taggar som pekar på sina egna URL:er, då har du plötsligt två versioner av varje sida som båda hävdar att de är originalet.
Google tvingas välja. Och Google väljer inte alltid rätt.
Jag har sett fall där Google fortsatte att ranka den gamla sajten – som vid det laget returnerade 404-fel – istället för den nya, fullt fungerande versionen. Varför? För att canonical-signalerna var motstridiga och de interna länkarna fortfarande pekade mot den gamla domänen i vissa delar av sajten.
Det är den typen av problem som inte syns i en vanlig checklista. Det kräver att någon faktiskt gräver i datan, crawlar sajten med verktyg som Screaming Frog eller Sitebulb, och korskör resultaten med indexeringsdata från Search Console.
JavaScript-rendering och det moderna CMS-dilemmat
Fler och fler sajter byggs idag med JavaScript-tunga ramverk. React. Next.js. Vue. Angular. Och de kan vara fantastiska ur användarsynpunkt. Snabba. Eleganta. Responsiva.
Men Google och JavaScript har en komplicerad relation.
Ja, Googlebot kan rendera JavaScript. Det har Google sagt många gånger. Men det sker i en tvåstegsprocess – först crawlas HTML:en, sedan renderas JavaScriptet i en separat kö. Och den kön kan vara lång. Dagar lång ibland.
Vid en sajtflytt till ett JavaScript-tungt CMS kan det innebära att Google ser tomma sidor under den kritiska övergångsperioden. Inga rubriker. Inga produktbeskrivningar. Inga interna länkar. Bara ett tomt skal. Och vad gör Google med tomma sidor? Precis – de rankas inte.
Server-side rendering (SSR) eller åtminstone dynamic rendering är i princip ett krav om du vill att flytten ska gå smidigt. Men det är inte alltid något som utvecklingsteamet har med i sin plan. De tänker på användarupplevelsen. Du måste tänka på Googlebot.
Strukturerad data som försvinner i flytten
Schema markup. De där JSON-LD-snipparna som ger dig stjärnbetyg, FAQ-dropdowns och produktpriser direkt i sökresultaten. De glöms nästan alltid bort vid en sajtflytt.
Och det är inte bara att de saknas på den nya sajten. Ibland implementeras de felaktigt – med gammal data, trasiga referenser eller i ett format som det nya CMS:et inte stöder. Resultatet är att dina rich snippets försvinner från sökresultaten. Klickfrekvensen sjunker. Trafiken minskar – även om du tekniskt sett behåller din position.
En sak som få pratar om: om du hade FAQ-schema på viktiga sidor och det plötsligt försvinner, kan det innebära en synlig minskning i CTR på 15-25 procent. Utan att din ranking faktiskt har förändrats. Det ser ut som ett rankingproblem, men det är ett markup-problem.
Planering före, under och efter flytten
En lyckad sajtflytt börjar månader innan den faktiska lanseringen. Inte veckor. Månader.
Före flytten behöver du en komplett crawl av den befintliga sajten. Varje URL. Varje statuskod. Varje canonical-tagg. Varje intern länk. Det här blir din baseline – det du mäter allt mot efteråt. Du behöver också en fullständig redirect-mappning som är testad och verifierad i en staging-miljö innan du går live.
Under flytten handlar det om att övervaka i realtid. Logfiler som visar hur Googlebot beter sig. Statuskoder som returneras. Redirect-kedjor som eventuellt uppstår. Det är inte en "tryck på knappen och gå hem"-situation. Det är mer som att övervaka en patient på intensiven de första timmarna.
Efter flytten behöver du daglig monitorering i minst fyra till sex veckor. Indexeringsstatus. Rankingförändringar. Crawl-fel i Search Console. Och du behöver vara beredd att agera snabbt om något inte ser rätt ut.
Vid en sajtflytt kan det vara klokt att ta hjälp av en SEO-byrå med teknisk spetskompetens för att undvika att värdefulla rankingar går förlorade i processen. Det är helt enkelt för mycket som kan gå fel för att chansa – särskilt om organisk söktrafik utgör en betydande del av din omsättning.
De vanligaste misstagen jag ser
Låt mig runda av med de misstag jag stöter på oftast. De som gör mest skada.
Först: att inte involvera SEO-kompetens förrän flytten redan är gjord. Det är som att anlita en arkitekt efter att huset redan är byggt. Du kan fixa saker i efterhand, men det kostar tre gånger så mycket och tar tre gånger så lång tid.
Sedan: att lita blint på CMS-plattformens inbyggda SEO-funktioner. Ja, de flesta moderna CMS har grundläggande SEO-stöd. Men "grundläggande" räcker inte vid en komplex flytt. Du behöver kontroll på detaljnivå – och det innebär ofta custom-lösningar.
Och slutligen: att inte ha en rollback-plan. Ibland går saker fel trots all planering. Servrar krånglar. DNS-propagering tar längre tid än väntat. Oförutsedda konflikter uppstår mellan gamla och nya system. Att kunna rulla tillbaka till den gamla sajten inom minuter – inte timmar – kan vara skillnaden mellan en tillfällig hicka och en fullskalig katastrof.
En sajtflytt är ett av de mest riskfyllda projekten du kan genomföra ur ett SEO-perspektiv. Men med rätt kompetens, rätt planering och rätt verktyg behöver det inte vara en mardröm. Det kan till och med bli en möjlighet – att städa upp gamla tekniska skulder, förbättra sajthastigheten och bygga en starkare teknisk grund för framtiden.
Men det kräver att du tar det på allvar. Från dag ett.