Bland de samtal jag helst inte vill få är det här: “vi bytte sajt för sex veckor sedan och nu är trafiken halverad, kan ni hjälpa oss?” Det är ett av de få SEO-problem som både är fullständigt undvikbart och svårt att reparera när skadan väl är skedd. Och det händer ofta — inte för att folk är slarviga, utan för att den som bygger den nya sajten och den som ansvarar för den organiska trafiken sällan sitter i samma rum samtidigt.
Jag har varit inblandad i tillräckligt många hemsidebyten genom åren — som rådgivare innan, som tekniska granskaren under, som den som kallats in i panik efter. Det är samma fem fel som återkommer oavsett bransch, byrå eller plattform. Nedan är listan, och under varje punkt vad man faktiskt gör åt det.
1. Gamla URL:er mappas inte till de nya
Det här är det vanligaste felet och det mest förödande. Den gamla sajten har byggt upp sökauktoritet på sina URL:er under flera år — ibland decennier. Den nya sajten lanseras med en annan struktur, andra sluggar, ibland en helt ny domän. Och ingen har mappat vad som går vart.
Effekten är omedelbar. Varje inlänk från en extern sajt, varje indexerad sida, varje bokmärke en besökare har sparat — allt ger 404. Google vet inte vart innehållet tog vägen. Den auktoritet som ackumulerats på de gamla URL:erna överförs inte till de nya. Den försvinner helt enkelt.
Lösningen heter redirect-karta. Varje gammal URL mappad till sin motsvarighet på den nya sajten med en 301-redirect. Inte “vi redirectar allt till startsidan” — det är nästan lika illa som ingenting. En-till-en-mappning. Det är tråkigt arbete. På en sajt med tusentals sidor tar det dagar. Men det är den enskilt mest värdeskapande insatsen i hela migreringsprojektet.
När jag granskar en migreringsplan och redirect-kartan saknas säger jag åt kunden att skjuta på lanseringen. Det är inte ett förslag. Utan kartan offrar man frivilligt flera års ackumulerat sökvärde.
2. Noindex från staging glöms kvar
Det här är det misstag jag skäms mest å andras vägnar för. Under utvecklingen har staging-miljön en <meta name="robots" content="noindex"> eller Disallow: / i robots.txt. Helt rimligt — man vill inte ha en halvfärdig staging-sajt indexerad. Sen lanseras sajten, någon glömmer att ta bort spärren, och hela sajten glider ut ur Googles index under några veckor.
Jag har sett det här hända på sajter med sexsiffrig månatlig organisk trafik. Ingen märker förrän en kund hör av sig och undrar varför leads-flödet torkat upp. När man till slut upptäcker det är skadan redan djup. Återindexering tar tid. Rankingen kommer inte tillbaka till samma nivå. Vissa sidor återhämtar sig aldrig helt.
Lösningen: en lanseringscheckslista med precis en punkt i fet stil högst upp — verifiera att noindex och disallow är borttagna på produktionsdomänen. Kolla HTML-källkoden. Kolla robots.txt. Kolla HTTP-headrarna (X-Robots-Tag). Kolla på lanseringsdagen och kolla igen en vecka senare. Det tar fem minuter och avvärjer en veckors-återhämtning.
3. Den nya sajten är långsammare än den gamla
Det här är kontraintuitivt men oerhört vanligt. Man tänker att en ny sajt ska vara snabbare — moderna designverktyg, fräsch kod, bättre hosting. I praktiken är det tvärtom. Nya designer kommer med tyngre resurser. Nya JavaScript-ramverk lastar in mer. Custom fonts lägger till renderingsblockerande requests. Hero-bilder i retina-upplösning väger fem gånger mer än den gamla JPEG:en.
Den gamla sajten laddade på 1,8 sekunder. Den nya på 4,5. Ingen märkte under utvecklingen för dev-teamet sitter på 1 Gbit-anslutningar och staging-servern hade ingen reell belastning.
Google har varit tydliga med att hastighet är en rankingfaktor. Men även om man lyfter ut rankingaspekten — användare lämnar. En sajt som tar fyra sekunder att ladda tappar mätbart fler besökare vid varje sidladdning, och multiplicerat med sajtens sessionsvolym blir intäktspåverkan verklig.
Kör prestandatester på den nya sajten innan lansering, benchmarkat mot den gamla. Samma verktyg, samma testplatser, samma anslutningsprofiler. Om nya sajten är långsammare — åtgärda det innan ni går live. Efter lansering får hastighetsproblem konkurrera med alla andra post-launch-prioriteringar, och de vinner sällan den kampen.
4. Interna länkar går sönder i tysthet
Innehållsmigrering är aldrig så prydlig som projektplanen antyder. Sidor omstruktureras, slås ihop, delas upp, tas bort. Själva brödtexten flyttas över, men de interna länkarna i innehållet — länkarna från ett blogginlägg till ett annat, från en tjänstesida till en case study, från ett FAQ-svar till en produktfunktion — går sönder i tysthet.
Ingen granskar interna länkar i innehållet, för innehållet har ju “migrerats”. Sidorna finns. Texten stämmer. Men hundratals interna länkar pekar nu på URL:er som inte längre existerar, eller på URL:er som har ändrat struktur. Den interna länkstruktur som Google använder för att förstå sidors vikt och tematiska relationer är söndersliten.
Crawla den nya sajten innan lansering. Kör en fullständig crawl och kontrollera varje internlänk. Flagga varje 404 och varje redirect-kedja. Fixa länkarna direkt i innehållet, inte bara i redirect-kartan. Interna länkar ska peka direkt på den kanoniska destinationen, inte gå via en redirect.
5. Long tail-innehållet städas bort utan trafikkoll
“Ingen läser det där ändå”-fällan. Under redesignen går någon igenom den gamla sajtens innehåll och beslutar att vissa sidor är föråldrade, off-brand eller irrelevanta. Gamla blogginlägg, nischade produktsidor, detaljerade FAQ-svar — de plockas bort från migreringsscopet. Den nya sajten lanseras ren och fokuserad.
Vad ingen kollade är om sidorna genererade organisk trafik. Ett blogginlägg från 2014 om ett nischat tekniskt ämne kan dra trettio besökare i månaden. Det låter som ingenting. Men stryker man femtio sådana sidor har man tappat 1 500 månatliga besök från väldigt specifika, ofta högintenta sökfrågor. Besökarna visste exakt vad de sökte — din sajt hade svaret. Nu har den inte det.
Innan någon enda sida stryks från migreringen: kolla dess organiska trafik. Har den meningsfull trafik — migrera den. Måste den verkligen bort — redirecta den till det närmaste relevanta alternativet. Att gallra innehåll är bra. Att gallra blint är dyrt.
Granskningen innan lansering
Varje hemsidebyte ska ha en teknisk SEO-granskning innan den nya sajten går live. Inte efter. Inte “vi tar det post-launch”. Innan.
Granskningen täcker: redirect-kartans fullständighet, robots- och indexeringsdirektiv, sidhastighetsbenchmarks mot den gamla sajten, internlänkarnas integritet, innehållsparitet för trafikdrivande sidor, structured data-migrering, XML-sitemap-korrekthet och canonical tag-konfiguration.
Inget av det är komplicerat. Allt är mödosamt. Och det är precis därför det hoppas över — det är inte spännande arbete, det syns inte i designskisserna, det finns inget i feature-demon som pekar mot det. Sex veckor senare syns det däremot väldigt tydligt, när trafikgrafen faller av ett stup och alla undrar vad som hände.
Efter lansering
Även med en perfekt genomförd granskning före lanseringen — räkna med viss turbulens. Rankingen fluktuerar under varje migrering. Google behöver crawla om och bearbeta hela sajten på nytt. Vissa sidor landar på andra positioner än tidigare.
Skillnaden mellan en migrering som återhämtar sig på fyra veckor och en som aldrig gör det är om grundpelarna satt på plats. Redirects, indexering, hastighet, interna länkar, innehållsbevarande — får man de fem rätt är turbulensen temporär. Missar man någon av dem bygger man vidare från en svagare position än den man hade innan bytet.
Står ni inför ett hemsidebyte och ingen på ert team har nämnt någon av de fem punkterna ovan — börja det samtalet nu. Det är värt att ha veckor innan lanseringsdag, inte efter. Är det någon här som kan dela med sig av en migrering där det faktiskt gick bra från första dagen? Jag har sett några sådana men de är fortfarande undantag.